How FFB Probe works

The guided run

FFB Probe is organized around one short tester journey: land on the value-prop screen, detect the stick, confirm the safety checklist, feel each live effect, answer what happened, then keep or share the resulting report. Each screen focuses on the task at hand so testers always know what to do next.

Step 01

Land

The first screen explains what FFB Probe tests, what you get, and why the public hardware database exists. Nothing touches the hardware until you continue.

Step 02

Detect

Welcome identifies the force-feedback device, its VID:PID and supported effects, and shows a live readout of the stick before any force is played.

Step 03

Prepare

The checklist sets the test strength, asks you to accept the safety notice, and confirms that other software is closed and the stick has room to move.

Step 04

Feel

Each effect plays for a fixed window while the screen shows the section, the expected signal and a countdown. Stop run stays visible, and Esc stops the run at any point.

Step 05

Answer

After each effect, tap every chip that matches what you felt. Chips are public; the optional notes field stays private. Continue, Run test again or Skip moves on.

Step 06

Keep or share

The report is saved on your computer first. Share my results sends the redacted payload; afterwards the app shows a support code and a link to the device's public page.

Welcome: detection and other programs

Welcome scans for force-feedback devices and shows the one it will test, with its VID:PID, the number of supported effects and a live stick readout. Only that device is tested. Re-scan repeats detection after you plug something in or close another program.

If a program that can take the device is running, such as a flight simulator, FFB-Bridge, MOZA Cockpit or Pit House, Brunner's tools or Logitech G HUB, an amber Other software running card names it and says how to close it. The warning does not block the run; click Re-check after closing the program.

Brunner bases ship in CLS2Sim mode, which has no force-feedback interface. When no force-feedback device is found, FFB-Probe looks for a Brunner base and offers Switch to DirectX mode; nothing is switched without that click. Switch back to CLS2Sim mode when finished is ticked by default, so the base returns to CLS2Sim mode after the run, when you close FFB-Probe, or at the next start if FFB-Probe was closed unexpectedly. Only the USB-mode setting is written, after your original mode is recorded, and if any step fails the base is put back the way it was.

If Simux, CLS2Sim, the Brunner USB Config Tool or FFB-Bridge holds the base, the card names it and asks you to quit it, also from the system tray, before you click Re-scan. Firmware without DirectX mode is reported and nothing is written.

Checklist: strength, safety and readiness

Test strength sets how strongly every effect drives the device, from 0% to 75% in 5% steps. Sticks the tests have been validated on start at 75%: the SideWinder Force Feedback 2, the SideWinder FFB Pro USB adapters (03EB:2056, CAFE:4004), the Logitech G940, Force 3D Pro and WingMan Force 3D, and the Brunner FFB-G Joystick, recognised by the base type it reports over Brunner's configuration channel, whatever grip is fitted. Every other device, including other Brunner bases, MOZA flight bases and hardware FFB-Probe does not know yet, starts at 35%. If Simux, CLS2Sim, the Brunner USB Config Tool or FFB-Bridge holds that channel, the base type cannot be read, so the base starts at 35% and the checklist asks you to close the program and click Re-scan. FFB-Probe remembers the strength you last chose for each device.

The Safety notice is always shown: force-feedback devices can move suddenly and with real force, so keep a hand resting lightly on the grip, keep fingers, cables and objects clear, and stop with Esc or Stop run at any time. Arm probe stays disabled until you tick I understand and accept responsibility and confirm every checklist item. Raising the strength above the device's default adds a warning that strong direct-drive bases can hit their end stops hard.

The checklist adapts to the device. The SideWinder FFB2 and the Logitech G940 add a hand-presence item, because their grip sensor cuts motor output when nobody is holding the stick. A VID:PID that is not in the app's hardware table asks for the real manufacturer and model.

MOZA flight bases

For a MOZA AB9, AY210, AB6 or AY90 the checklist adds a MOZA BASE card. It reads, without changing anything, whether the base will actually play effects: a base in MOZA Cockpit's Telemetry mode, or with force feedback disabled, torque output inhibited or game gain at 0, accepts every effect and moves nothing.

If the base is not ready, the card lists the reasons and offers Prepare base for testing, which saves your settings, switches the base to DirectInput mode and opens its force-output gates. Restore my MOZA settings when finished is ticked by default and puts them back after the run or when you close FFB-Probe. Travel limits, calibration and Force Sensing are never touched. If MOZA Cockpit, MOZA Pit House or FFB-Bridge holds the settings port, the card names it; close it and click Re-check.

Running: feel, answer, stop

The run is split into four sections: Constant, Periodic, Condition and Ramp. Each effect plays for a fixed window, five seconds on Windows and two and a half on Linux, and is stopped as soon as that window ends. The answer card then asks what you felt: tap every chip that matches, add an optional private note, and choose Continue, Run test again or Skip.

Stop run is visible in the header and beside the countdown, and Esc stops the run at any point. Closing the window during a run stops the effects and releases the device first. What was measured before the stop is saved locally.

Result: keep, share and follow up

The result screen shows where the report was saved, with Show in folder and See my results. Share my results sends the redacted payload; nothing is uploaded otherwise. After sharing, the app shows a support code and a link to the device's public page, and the HTML report's Share button shows them too. Keep the code if you may want to ask about or remove the submission later. An optional email field signs you up for news, including when FFB-Bridge supports your stick.

If another program held the device exclusively, the result names the program and explains that the run measured nothing from the device. A Brunner base switched for the test, or a MOZA base prepared for it, is restored once the probe engine has exited.

What the probe asks the hardware to do

Windows groups the live battery into Constant, Periodic, Condition, and Ramp sections. Linux presents the equivalent evdev effects that each device advertises. Exact counts vary by driver and hardware on both platforms.

Test strength and the 75% limit

Every effect plays at the test strength chosen on the checklist. Nothing FFB-Probe plays goes above 75% of full scale, on any device and in any test, including the command-line --magnitude option and the diagnostic modes. Effects that play at the same time share the strength, so together they never exceed it. Every report records the strength and whether you changed it.

Autocenter and stop timing

The device's own autocenter spring is switched off during the live tests and restored afterwards, so it neither fights nor masks the effect being tested. Each effect is stopped as soon as its playback window ends instead of when you answer. The Logitech G940 on Linux is the exception: its driver ignores the autocenter setting, so FFB-Probe leaves it alone and notes that hardware autocenter was active.

Measured motion

While each effect plays, the probe samples the stick's X and Y axes on Windows and Linux and records the peak movement as a signed percentage of each axis's half range, for example X peak +25.1%, Y peak -0.8%. The sign shows the direction, which turns a direction answer into checkable evidence. Movement is measured from where the stick rested when the effect started, so a stick resting off-centre can show more than 100%. Condition effects such as spring and damper do not move a centred stick, so no motion at rest is expected for them. The measurement stays in the private response-notes field and is not shown on public device pages.

Brunner bases

A Brunner base multiplies every DirectX effect by gains it stores itself, 50% from the factory. For the live tests FFB-Probe sets FX master and the effect gains to 100%, never higher and without touching global dampening, and restores your values afterwards, also when you stop a run. In DirectX mode the base maps its axes rotated by 90°: 0° pulls right, 90° forward, 180° left and 270° back. That is Brunner's firmware behaviour; FFB-Probe records it as measured and does not correct it.

The two files each run writes

Reports save to %LOCALAPPDATA%\Programs\ffb-probe\Results\FFB-Probe-<timestamp>\ on Windows and ~/.local/share/ffb-probe/Results/FFB-Probe-<timestamp>/ on Linux. Each run writes two files, the HTML report and the share JSON. The HTML embeds the JSON in a <pre> block, so the local report and the upload payload are the same bytes. The older text, README and support-ZIP files are written only when FFB_PROBE_KEEP_LEGACY=1 is set.

Windows install and publisher checks

FFB Probe is published by Rohsam Inc. The installer is a per-user install — no admin password required, no UAC prompt. It places the binary under %LOCALAPPDATA%\Programs\ffb-probe and writes a desktop shortcut and a Start Menu entry. The directory chooser is hidden so you can't accidentally install somewhere weird. Stable Windows releases are signed; confirm Windows shows Rohsam Inc. as the publisher and verify the SHA-256 on the Download page before running.

If Windows does not show Rohsam Inc. as the verified publisher for your installer, or if the hash does not match the published manifest, do not run that file.

The release manifest is the source of truth for filenames, sizes, and hashes. The Windows installer and Linux AppImage are both opt-in downloads; running the probe still keeps reports local until you choose Share.

AppImage plus evdev permissions

The Linux build ships as a self-contained AppImage. Mark it executable, run it, and keep the stick powered with room to move:

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

The AppImage can run in place, or ./FfbProbe-*.AppImage --install can add user-scoped desktop integration under ~/Applications. Use --uninstall to remove that installed copy and its menu entry.

Detection can work with read-only access, but live effects need write access to the joystick's /dev/input/event* node. If the wizard reports permission failures, fix the device's event-node permissions once instead of running the whole AppImage with sudo.

1. Find the event node

The report or error text usually names it as something like event=/dev/input/event2. You can also inspect joystick event symlinks:

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

2. Try a temporary permission

Replace event2 with the node for your stick. This lasts until the device is unplugged or the machine reboots, so it is a safe way to confirm the problem:

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

3. Make it persistent with udev

Ask udev for the stick's USB IDs:

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

Use those lowercase hex IDs in a device-specific rule. This example is for a 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

Unplug and replug the stick, then run the AppImage normally. The rule is per-device, so it is safer than adding your user to the broad input group.

4. Brunner bases: the configuration interface

To switch a Brunner base between CLS2Sim and DirectX mode, and to raise its gains for the run, FFB-Probe uses the base's hidraw configuration interface, which is root-only by default. If access is denied, FFB-Probe shows the rule to add. FFB-Bridge's udev rule already contains it; otherwise create this file and replug the base:

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 bases: the settings port

The MOZA readiness check and Prepare base for testing talk to the base over its USB serial settings port, /dev/ttyACM*. If FFB-Probe cannot open the port, it suggests the dialout group; log out and back in after adding it:

sudo usermod -aG dialout "$USER"

A per-device rule gives the same access to the active desktop user only:

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

When another program has the device

Before the tests, the Linux worker opens the event node once. If the node is busy (EBUSY), FFB-Probe names the processes holding it, found through /proc/*/fd. If access is refused (EACCES or EPERM), it points to the permission steps above. Processes run by other users or by root cannot be listed without privileges, and the message says so.

Kernel autocenter is switched off while each effect plays and restored between effects. It is never touched on the Logitech G940, whose Linux driver ignores the setting and always centres at full strength.

The Linux wizard uses evdev force-feedback effects rather than DirectInput. The shared report schema is the same as Windows, so Linux submissions appear in the same public database and OS breakdown.

Consent-first updates on Windows and Linux

The GUI reads a small stable-release manifest at startup. It sends no install ID, current-version query, device information, or probe results; offline and malformed responses stay silent.

An update is never offered while a run is in progress, and nothing is installed without your consent. Stable builds are only offered stable releases; a beta build is offered newer betas and the stable release that supersedes them.

After explicit consent, FFB-Probe downloads the installer, verifies its exact length and SHA-256, requires a valid Windows signature from Rohsam Inc., runs the per-user installer silently, and restarts the new build.

A running Linux AppImage can download and verify the new AppImage, invoke its user-scoped install handler, refresh the desktop entry and icons, and launch the installed copy.

Development builds, extracted AppDirs, distro packages, and other non-AppImage Linux installs are never overwritten. The prompt links to the download page and these release notes instead, and every user can defer or skip a version.

Known issues and recovery steps

The literal bytes are the audit surface

Your report files remain local unless you click Share. Sharing POSTs the JSON file to /submit; those are the same bytes embedded at the bottom of the HTML report. Separately, the GUI performs the identifier-free startup manifest check described above, but it never sends report or device data as part of that check.

The public hardware database renders an aggregate view per VID:PID. It never displays responses[].notes, which can contain optional tester text and the probe-measured motion. Chip selections, the device class, the test strength (run), capability flags, supported effects, result codes, failed effects, and run errors can appear on the device page.

The Welcome warning about other running programs and the exclusive-access message are shown to you only; the program names in them are never added to the report.

Read the full privacy contract → · Open the sample uploaded report →