So funktioniert FFB Probe

Der geführte Lauf

FFB Probe ist um eine kurze Testerreise herum organisiert: Landen Sie auf dem Value-Prop-Bildschirm, erkennen Sie den Stick, bestätigen Sie die Sicherheitscheckliste, spüren Sie jeden Live-Effekt, beantworten Sie, was passiert ist, und bewahren Sie dann den resultierenden Bericht auf oder teilen Sie ihn. Jeder Bildschirm konzentriert sich auf die jeweilige Aufgabe, sodass Tester immer wissen, was als nächstes zu tun ist.

Schritt 01

Land

Der erste Bildschirm erklärt, was FFB Probe testet, was Sie erhalten und warum es die öffentliche Hardwaredatenbank gibt. Bis Sie fortfahren, wird die Hardware nicht angesprochen.

Schritt 02

Erkennen

Der Willkommensbildschirm identifiziert das Force-Feedback-Gerät, seine VID:PID und unterstützten Effekte und zeigt eine Live-Anzeige des Sticks, bevor irgendeine Kraft wirkt.

Schritt 03

Vorbereiten

Die Checkliste legt die Teststärke fest, fordert Sie auf, den Sicherheitshinweis zu akzeptieren, und bestätigt, dass andere Software geschlossen ist und der Stick Bewegungsfreiheit hat.

Schritt 04

Fühlen

Jeder Effekt läuft für ein festes Zeitfenster, während der Bildschirm den Abschnitt, das erwartete Signal und einen Countdown zeigt. „Stop run“ bleibt sichtbar, und Esc stoppt den Lauf jederzeit.

Schritt 05

Antwort

Tippen Sie nach jedem Effekt jeden Chip an, der zu dem passt, was Sie gespürt haben. Chips sind öffentlich; das optionale Notizfeld bleibt privat. Mit „Continue“, „Run test again“ oder „Skip“ geht es weiter.

Schritt 06

Behalten oder teilen

Der Bericht wird zuerst auf Ihrem Computer gespeichert. „Share my results“ sendet die geschwärzten Daten; danach zeigt die App einen Supportcode und einen Link zur öffentlichen Seite des Geräts.

Willkommen: Erkennung und andere Programme

Der Willkommensbildschirm sucht nach Force-Feedback-Geräten und zeigt das Gerät, das getestet wird, mit seiner VID:PID, der Anzahl unterstützter Effekte und einer Live-Anzeige des Sticks. Nur dieses Gerät wird getestet. Re-scan wiederholt die Erkennung, nachdem Sie etwas angeschlossen oder ein anderes Programm geschlossen haben.

Läuft ein Programm, das das Gerät belegen kann, etwa ein Flugsimulator, FFB-Bridge, MOZA Cockpit oder Pit House, Brunners Tools oder Logitech G HUB, nennt eine bernsteinfarbene Karte Other software running das Programm und erklärt, wie Sie es schließen. Die Warnung blockiert den Lauf nicht; klicken Sie nach dem Schließen des Programms auf Re-check.

Brunner-Basen werden im CLS2Sim-Modus ausgeliefert, der keine Force-Feedback-Schnittstelle bietet. Wird kein Force-Feedback-Gerät gefunden, sucht FFB-Probe nach einer Brunner-Basis und bietet Switch to DirectX mode an; ohne diesen Klick wird nichts umgeschaltet. Switch back to CLS2Sim mode when finished ist standardmäßig aktiviert, sodass die Basis nach dem Lauf, beim Schließen von FFB-Probe oder – falls FFB-Probe unerwartet beendet wurde – beim nächsten Start in den CLS2Sim-Modus zurückkehrt. Geschrieben wird nur die USB-Modus-Einstellung, und zwar erst, nachdem Ihr ursprünglicher Modus gesichert wurde; schlägt ein Schritt fehl, wird die Basis in ihren ursprünglichen Zustand zurückversetzt.

Belegt Simux, CLS2Sim, das Brunner USB Config Tool oder FFB-Bridge die Basis, nennt die Karte das Programm und bittet Sie, es zu beenden – auch im Infobereich der Taskleiste –, bevor Sie auf Re-scan klicken. Firmware ohne DirectX-Modus wird gemeldet, und es wird nichts geschrieben.

Checkliste: Stärke, Sicherheit und Bereitschaft

Test strength legt fest, wie stark jeder Effekt das Gerät antreibt, von 0 % bis 75 % in Schritten von 5 %. Sticks, auf denen die Tests validiert wurden, starten bei 75 %: der SideWinder Force Feedback 2, die USB-Adapter für den SideWinder FFB Pro (03EB:2056, CAFE:4004), der Logitech G940, Force 3D Pro und WingMan Force 3D sowie der Brunner FFB-G Joystick, erkannt am Basistyp, den er über Brunners Konfigurationskanal meldet, unabhängig vom montierten Griff. Alle anderen Geräte, einschließlich anderer Brunner-Basen, MOZA-Flugbasen und Hardware, die FFB-Probe noch nicht kennt, starten bei 35 %. Belegt Simux, CLS2Sim, das Brunner USB Config Tool oder FFB-Bridge diesen Kanal, lässt sich der Basistyp nicht lesen; die Basis startet dann bei 35 %, und die Checkliste bittet Sie, das Programm zu schließen und auf Re-scan zu klicken. FFB-Probe merkt sich für jedes Gerät die zuletzt gewählte Stärke.

Der Hinweis Safety wird immer angezeigt: Force-Feedback-Geräte können sich plötzlich und mit echter Kraft bewegen. Lassen Sie daher eine Hand leicht auf dem Griff ruhen, halten Sie Finger, Kabel und Gegenstände fern und stoppen Sie jederzeit mit Esc oder „Stop run“. Arm probe bleibt deaktiviert, bis Sie I understand and accept responsibility ankreuzen und jeden Punkt der Checkliste bestätigen. Wird die Stärke über den Standardwert des Geräts angehoben, erscheint zusätzlich eine Warnung, dass starke Direct-Drive-Basen hart in ihre Endanschläge schlagen können.

Die Checkliste passt sich dem Gerät an. Beim SideWinder FFB2 und beim Logitech G940 kommt ein Punkt zur Handerkennung hinzu, weil ihr Griffsensor die Motorleistung abschaltet, wenn niemand den Stick hält. Bei einer VID:PID, die nicht in der Hardwaretabelle der App steht, werden der tatsächliche Hersteller und das Modell abgefragt.

MOZA-Flugbasen

Bei einer MOZA AB9, AY210, AB6 oder AY90 fügt die Checkliste eine Karte MOZA BASE hinzu. Sie liest, ohne etwas zu ändern, aus, ob die Basis Effekte tatsächlich wiedergibt: Eine Basis im Telemetriemodus von MOZA Cockpit oder mit deaktiviertem Force Feedback, gesperrter Drehmomentausgabe oder einer Spielverstärkung von 0 nimmt jeden Effekt an und bewegt sich nicht.

Ist die Basis nicht bereit, listet die Karte die Gründe auf und bietet Prepare base for testing an: Damit werden Ihre Einstellungen gesichert, die Basis in den DirectInput-Modus geschaltet und ihre Sperren für die Kraftausgabe geöffnet. Restore my MOZA settings when finished ist standardmäßig aktiviert und stellt die Einstellungen nach dem Lauf oder beim Schließen von FFB-Probe wieder her. Wegbegrenzungen, Kalibrierung und Force Sensing werden nie verändert. Belegt MOZA Cockpit, MOZA Pit House oder FFB-Bridge den Einstellungsport, nennt die Karte das Programm; schließen Sie es und klicken Sie auf Re-check.

Testlauf: spüren, antworten, stoppen

Der Lauf ist in vier Abschnitte gegliedert: Constant, Periodic, Condition und Ramp. Jeder Effekt läuft für ein festes Zeitfenster – unter Windows fünf Sekunden, unter Linux zweieinhalb – und wird gestoppt, sobald dieses Fenster endet. Danach fragt die Antwortkarte, was Sie gespürt haben: Tippen Sie jeden passenden Chip an, fügen Sie optional eine private Notiz hinzu und wählen Sie Continue, Run test again oder Skip.

Stop run ist in der Kopfzeile und neben dem Countdown sichtbar, und Esc stoppt den Lauf jederzeit. Wird das Fenster während eines Laufs geschlossen, werden zuerst die Effekte gestoppt und das Gerät freigegeben. Was vor dem Stoppen gemessen wurde, wird lokal gespeichert.

Ergebnis: aufbewahren, teilen und nachverfolgen

Der Ergebnisbildschirm zeigt, wo der Bericht gespeichert wurde, mit Show in folder und See my results. Share my results sendet die geschwärzten Daten; ansonsten wird nichts hochgeladen. Nach dem Teilen zeigt die App einen Supportcode und einen Link zur öffentlichen Seite des Geräts; die Schaltfläche „Share“ im HTML-Bericht zeigt beides ebenfalls an. Bewahren Sie den Code auf, falls Sie später Fragen zur Einsendung haben oder sie entfernen lassen möchten. Über ein optionales E-Mail-Feld können Sie Neuigkeiten abonnieren, etwa wenn FFB-Bridge Ihren Stick unterstützt.

Hat ein anderes Programm das Gerät exklusiv belegt, nennt das Ergebnis dieses Programm und erklärt, dass der Lauf nichts vom Gerät gemessen hat. Eine für den Test umgeschaltete Brunner-Basis oder eine dafür vorbereitete MOZA-Basis wird wiederhergestellt, sobald die Probe-Engine beendet ist.

Was die Sonde von der Hardware verlangt

Windows gruppiert die Live-Tests in die Abschnitte Constant, Periodic, Condition und Ramp. Linux zeigt die entsprechenden evdev-Effekte an, die das jeweilige Gerät meldet. Die genaue Anzahl hängt auf beiden Plattformen von Treiber und Hardware ab.

Teststärke und die Grenze von 75 %

Jeder Effekt läuft mit der in der Checkliste gewählten Teststärke. Nichts, was FFB-Probe wiedergibt, überschreitet 75 % des Vollausschlags – auf keinem Gerät und in keinem Test, einschließlich der Befehlszeilenoption --magnitude und der Diagnosemodi. Gleichzeitig laufende Effekte teilen sich die Stärke, sodass sie zusammen nie darüber liegen. Jeder Bericht erfasst die Stärke und ob Sie sie geändert haben.

Autozentrierung und Stopp-Zeitpunkt

Die geräteeigene Autozentrierfeder wird während der Live-Tests ausgeschaltet und danach wiederhergestellt, sodass sie dem getesteten Effekt weder entgegenwirkt noch ihn überdeckt. Jeder Effekt wird gestoppt, sobald sein Wiedergabefenster endet, und nicht erst, wenn Sie antworten. Die Ausnahme ist der Logitech G940 unter Linux: Sein Treiber ignoriert die Autozentrier-Einstellung, daher lässt FFB-Probe sie unverändert und vermerkt, dass die Hardware-Autozentrierung aktiv war.

Gemessene Bewegung

Während jeder Effekt läuft, tastet die Sonde unter Windows und Linux die X- und Y-Achse des Sticks ab und erfasst die Spitzenauslenkung als vorzeichenbehafteten Prozentsatz des halben Bereichs jeder Achse, zum Beispiel X peak +25.1%, Y peak -0.8%. Das Vorzeichen zeigt die Richtung und macht so aus einer Richtungsantwort einen überprüfbaren Nachweis. Die Bewegung wird ab der Position gemessen, in der der Stick beim Start des Effekts ruhte, daher kann ein außerhalb der Mitte ruhender Stick mehr als 100 % zeigen. Condition-Effekte wie Feder und Dämpfer bewegen einen zentrierten Stick nicht, daher ist bei ihnen keine Bewegung aus der Ruhelage zu erwarten. Die Messung bleibt im privaten Antwortnotizfeld und wird auf öffentlichen Geräteseiten nicht angezeigt.

Brunner-Basen

Eine Brunner-Basis multipliziert jeden DirectX-Effekt mit selbst gespeicherten Verstärkungen, ab Werk 50 %. Für die Live-Tests setzt FFB-Probe FX master und die Effektverstärkungen auf 100 % – nie höher und ohne die globale Dämpfung anzutasten – und stellt Ihre Werte danach wieder her, auch wenn Sie einen Lauf stoppen. Im DirectX-Modus ordnet die Basis ihre Achsen um 90° gedreht zu: 0° zieht nach rechts, 90° nach vorn, 180° nach links und 270° nach hinten. Das ist ein Verhalten der Brunner-Firmware; FFB-Probe erfasst es so, wie es gemessen wurde, und korrigiert es nicht.

Die beiden Dateien werden jeweils geschrieben

Berichte werden unter Windows in %LOCALAPPDATA%\Programs\ffb-probe\Results\FFB-Probe-<timestamp>\ und unter Linux in ~/.local/share/ffb-probe/Results/FFB-Probe-<timestamp>/ gespeichert. Jeder Lauf schreibt zwei Dateien: den HTML-Bericht und das JSON zum Teilen. Das HTML bettet das JSON in einen <pre>-Block ein, sodass der lokale Bericht und die Upload-Nutzlast aus denselben Bytes bestehen. Die älteren Text-, README- und Support-ZIP-Dateien werden nur geschrieben, wenn FFB_PROBE_KEEP_LEGACY=1 gesetzt ist.

Windows-Installation und Überprüfung des Herausgebers

FFB Probe wird von Rohsam Inc. herausgegeben. Das Installationsprogramm installiert pro Benutzer – kein Administratorkennwort erforderlich, keine UAC-Eingabeaufforderung. Es platziert die Binärdatei unter %LOCALAPPDATA%\Programs\ffb-probe und schreibt eine Desktopverknüpfung und einen Start Menu-Eintrag. Die Verzeichnisauswahl ist ausgeblendet, sodass Sie nicht versehentlich an einem seltsamen Ort installieren können. Stabile Windows-Releases sind signiert; vergewissern Sie sich, dass Windows Rohsam Inc. als Herausgeber anzeigt, und überprüfen Sie den SHA-256 auf der Download-Seite, bevor Sie es ausführen.

Wenn Windows Rohsam Inc. nicht als verifizierten Herausgeber Ihres Installationsprogramms anzeigt oder wenn der Hash nicht mit dem veröffentlichten Manifest übereinstimmt, führen Sie diese Datei nicht aus.

Das Release-Manifest ist die maßgebliche Quelle für Dateinamen, Größen und Hashes. Das Windows-Installationsprogramm und das Linux AppImage sind beide Opt-in-Downloads; das Ausführen des Probes hält Berichte weiterhin lokal, bis Sie Share wählen.

AppImage plus evdev-Berechtigungen

Die Linux bauen Schiffe als eigenständige AppImage. Markieren Sie es als ausführbare Datei, führen Sie es aus und halten Sie den Stick mit Strom und Bewegungsfreiheit:

chmod +x ./FfbProbe-*.AppImage
./FfbProbe-*.AppImage

Das AppImage kann direkt ausgeführt werden; alternativ fügt ./FfbProbe-*.AppImage --install eine benutzerspezifische Desktop-Integration unter ~/Applications hinzu. Mit --uninstall entfernen Sie die installierte Kopie und ihren Menüeintrag.

Die Erkennung kann mit schreibgeschütztem Zugriff funktionieren, Live-Effekte benötigen jedoch Schreibzugriff auf den /dev/input/event*-Knoten des Joysticks. Wenn der Assistent Berechtigungsfehler meldet, korrigieren Sie die Ereignisknotenberechtigungen des Geräts einmal, anstatt den gesamten AppImage mit sudo auszuführen.

1. Suchen Sie den Ereignisknoten

Der Bericht oder Fehlertext nennt es normalerweise so etwas wie event=/dev/input/event2. Sie können auch die symbolischen Links zu Joystick-Ereignissen überprüfen:

ls -l /dev/input/by-id/*event-joystick

2. Versuchen Sie es mit einer temporären Berechtigung

Ersetzen Sie event2 durch den Knoten für Ihren Stick. Dies dauert so lange, bis das Gerät vom Stromnetz getrennt oder die Maschine neu gestartet wird, und ist daher eine sichere Möglichkeit, das Problem zu bestätigen:

sudo setfacl -m "u:$USER:rw" /dev/input/event2
./FfbProbe-*.AppImage

3. Machen Sie es mit udev dauerhaft

Fragen Sie udev nach den USB-IDs des Sticks:

udevadm info -q property -n /dev/input/event2 | grep -E 'ID_VENDOR_ID|ID_MODEL_ID|NAME'

Verwenden Sie diese kleingeschriebenen Hex-IDs in einer gerätespezifischen Regel. Dieses Beispiel gilt für einen SideWinder FFB2, VID:PID 045e:001b:

sudo tee /etc/udev/rules.d/70-ffb-probe-045e-001b.rules > /dev/null <<'EOF'
# FFB Probe: allow the active desktop user to open this joystick's event node.
SUBSYSTEM=="input", KERNEL=="event*", ATTRS{idVendor}=="045e", ATTRS{idProduct}=="001b", TAG+="uaccess"
EOF

sudo udevadm control --reload-rules
sudo udevadm trigger --subsystem-match=input

Ziehen Sie den Stick ab und wieder ein und führen Sie dann den AppImage normal aus. Die Regel gilt pro Gerät und ist daher sicherer als das Hinzufügen Ihres Benutzers zur breiten input-Gruppe.

4. Brunner-Basen: die Konfigurationsschnittstelle

Um eine Brunner-Basis zwischen CLS2Sim- und DirectX-Modus umzuschalten und ihre Verstärkungen für den Lauf anzuheben, verwendet FFB-Probe die hidraw-Konfigurationsschnittstelle der Basis, auf die standardmäßig nur root zugreifen kann. Wird der Zugriff verweigert, zeigt FFB-Probe die hinzuzufügende Regel an. Die udev-Regel von FFB-Bridge enthält sie bereits; andernfalls legen Sie diese Datei an und stecken die Basis neu ein:

sudo tee /etc/udev/rules.d/71-ffb-probe-brunner.rules > /dev/null <<'EOF'
SUBSYSTEM=="hidraw", KERNEL=="hidraw*", ATTRS{modalias}=="usb:v25BBp*in01", TAG+="uaccess"
EOF

sudo udevadm control --reload
sudo udevadm trigger

5. MOZA-Basen: der Einstellungsport

Die MOZA-Bereitschaftsprüfung und Prepare base for testing kommunizieren mit der Basis über ihren seriellen USB-Einstellungsport /dev/ttyACM*. Kann FFB-Probe den Port nicht öffnen, schlägt es die Gruppe dialout vor; melden Sie sich nach dem Hinzufügen ab und wieder an:

sudo usermod -aG dialout "$USER"

Eine gerätespezifische Regel gewährt denselben Zugriff nur dem aktiven Desktop-Benutzer:

sudo tee /etc/udev/rules.d/70-ffb-probe-moza.rules > /dev/null <<'EOF'
SUBSYSTEM=="tty", KERNEL=="ttyACM*", ATTRS{idVendor}=="346e", TAG+="uaccess"
EOF

sudo udevadm control --reload-rules
sudo udevadm trigger --subsystem-match=tty

Wenn ein anderes Programm das Gerät belegt

Vor den Tests öffnet der Linux-Worker den Event-Knoten einmal. Ist der Knoten belegt (EBUSY), nennt FFB-Probe die Prozesse, die ihn halten, ermittelt über /proc/*/fd. Wird der Zugriff verweigert (EACCES oder EPERM), verweist es auf die obigen Berechtigungsschritte. Prozesse anderer Benutzer oder von root lassen sich ohne entsprechende Rechte nicht auflisten; die Meldung weist darauf hin.

Die Kernel-Autozentrierung wird während jedes Effekts ausgeschaltet und zwischen den Effekten wiederhergestellt. Beim Logitech G940 wird sie nie verändert, da dessen Linux-Treiber die Einstellung ignoriert und immer mit voller Stärke zentriert.

Der Linux-Assistent verwendet evdev-Force-Feedback-Effekte anstelle von DirectInput. Das gemeinsame Berichtsschema ist das gleiche wie bei Windows, sodass Linux-Übermittlungen in derselben öffentlichen Datenbank und Betriebssystemaufschlüsselung angezeigt werden.

Zustimmungsbasierte Updates unter Windows und Linux

Die GUI liest beim Start ein kleines Stable-Release-Manifest. Es werden keine Installations-IDs, Abfragen zur aktuellen Version, Geräteinformationen oder Testergebnisse gesendet. Offline- und fehlerhafte Antworten bleiben stumm.

Während eines Laufs wird nie ein Update angeboten, und ohne Ihre Zustimmung wird nichts installiert. Stabilen Builds werden nur stabile Releases angeboten; einem Beta-Build werden neuere Betas und das stabile Release angeboten, das sie ablöst.

Nach ausdrücklicher Zustimmung lädt FFB-Probe das Installationsprogramm herunter, überprüft seine genaue Länge und SHA-256, erfordert eine gültige Windows-Signatur von Rohsam Inc., führt das benutzerspezifische Installationsprogramm im Hintergrund aus und startet den neuen Build neu.

Ein ausgeführter Linux AppImage kann den neuen AppImage herunterladen und überprüfen, seinen benutzerbezogenen Installationshandler aufrufen, den Desktopeintrag und die Symbole aktualisieren und die installierte Kopie starten.

Entwicklungs-Builds, extrahierte AppDirs, Distributionspakete und andere Nicht-AppImage Linux-Installationen werden niemals überschrieben. Die Eingabeaufforderung verweist stattdessen auf die Download-Seite und diese Versionshinweise, und jeder Benutzer kann eine Version zurückstellen oder überspringen.

Bekannte Probleme und Wiederherstellungsschritte

Die Literalbytes sind die Prüfoberfläche

Ihre Berichtsdateien bleiben lokal, sofern Sie nicht auf Share klicken. Beim Teilen wird die JSON-Datei per POST an /submit gesendet; es sind dieselben Bytes, die unten im HTML-Bericht eingebettet sind. Unabhängig davon führt die GUI die oben beschriebene kennungsfreie Manifestprüfung beim Start aus, sendet dabei aber niemals Berichts- oder Gerätedaten.

Die öffentliche Hardwaredatenbank zeigt eine zusammengefasste Ansicht je VID:PID. Sie zeigt niemals responses[].notes; dieses Feld kann optionalen Testertext und die von der Sonde gemessene Bewegung enthalten. Auswahlbezeichnungen, die Geräteklasse, die Teststärke (run), Fähigkeitsflags, unterstützte Effekte, Ergebniscodes, fehlgeschlagene Effekte und Ausführungsfehler können auf der Geräteseite erscheinen.

Die Warnung des Willkommensbildschirms zu anderen laufenden Programmen und die Meldung zum exklusiven Zugriff sehen nur Sie; die darin genannten Programmnamen werden nie in den Bericht übernommen.

Lesen Sie die vollständige Datenschutzvereinbarung → · Öffnen Sie den hochgeladenen Beispielbericht →