FFB Probe release notes

A correction to the default test strength: only the Brunner FFB-G Joystick starts at 75%, and every other Brunner base starts at 35%.

Brunner default strength

• Only the Brunner FFB-G Joystick starts at 75%. FFB-Probe recognises it from the base type it reports over Brunner's configuration channel, whatever grip is fitted, and the Checklist shows "Validated base (Brunner FFB-G Joystick) — default 75%". 1.1.1 had given every Brunner base the 75% default.
• Other Brunner bases start at 35%. The CLS-E, the CLS-P, a rudder and every other Brunner base start at 35%, like any device the tests have not been validated on. As on every device, you can raise the strength yourself up to the 75% limit.
• A base whose type cannot be read starts at 35%. While Simux, CLS2Sim, the Brunner USB Config Tool or FFB-Bridge holds the configuration channel, FFB-Probe cannot read the base type. The Checklist then asks you to close the program and click Re-scan.

You can now choose how strongly the tests drive your device, never above a hard limit, and you confirm that you will operate it safely before a run starts.

Test strength

• A strength slider on the Checklist. Before a run you can set the test strength from 0% to 75% in 5% steps. The value, your device's default and the 75% maximum are shown next to the slider, and FFB-Probe remembers the last strength you chose for each device.
• Defaults by device. Sticks the tests have been validated on start at 75%: the SideWinder Force Feedback 2, the SideWinder FFB Pro USB adapters (03EB:2056, PicoWinder CAFE:4004), the Logitech G940, Force 3D Pro and WingMan Force 3D, and every Brunner base. Every other device, including MOZA flight bases and hardware FFB-Probe does not know yet, starts at 35%.
• 75% is a hard limit. 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 once share the strength you chose, so together they never exceed it; the saturation test now splits it across its three forces, 25% each at 75%.
• Brunner bases are no longer held to 35%. With their DirectX gains raised for the run, they now start at 75% like the SideWinder FFB2. At 35% the tests felt too weak to judge.
• MOZA flight bases can be raised. They still start at 35%, FFB-Bridge's ceiling for that hardware, but you can now raise the strength yourself. The earlier fixed 35% cap is replaced by the default and the 75% limit.

Safety acknowledgement

• A safety notice before every run. The Checklist always explains that force-feedback devices can move suddenly and with real force: keep a hand resting lightly on the grip, keep fingers, cables and objects clear, and stop with Esc or Stop at any time. "Arm probe" stays disabled until you tick "I understand and accept responsibility".
• An extra warning above the default. If you raise the strength above your device's default, the notice adds a warning that strong direct-drive bases can hit their end stops hard.

Reports

• The strength is recorded. Every report records the test strength and whether you changed it. The HTML report shows "Test strength: 75% (default)" or "Test strength: 50% (chosen by tester)", and the shared data carries a new run object with strength_pct and strength_source. The report format is still schema: 1.
• The two-axis test has one name. It is now reported as Two-axis diagonal — diagonal instead of Two-axis diagonal — diagonal (X=75%, Y=75%), so an adjustable strength does not split it into a separate entry per strength. The website merges the old name into the new one.
• Notes stay private. Your typed notes remain private and never appear on the public device page.

Command line

• --magnitude sets the test strength. Values outside 0..75 are clamped instead of refused. Without it, the device's default (75% or 35%) is used; earlier builds used 75% on Windows and 50% on Linux, or 60% when launched by the app. The console and the debug log state the strength used and whether it was the default.

A hardening release: a finished test run is no longer lost at the Share step, results reaching the public database are more accurate, and Brunner and MOZA flight bases now work out of the box.

Brunner bases

• CLS2Sim mode is detected. Brunner bases ship in CLS2Sim mode, which has no force-feedback interface, so earlier builds found no device. When no force-feedback device is found, FFB-Probe now checks for a Brunner base and offers "Switch to DirectX mode"; nothing is switched without that click.
• Switching back is automatic. "Switch back when finished" is on by default: the base returns to CLS2Sim mode after the run, when you close FFB-Probe, or on the next start after an unexpected exit. Only the USB-mode setting is written, and if any step fails the base is put back the way it was.
• Full-strength effects. The base scales every effect by gains it stores itself (50% from the factory), so effects reached the motor at about a quarter of their strength. For the live tests FFB-Probe sets FX master and the effect gains to 100%, restores your values afterwards, and notes your stored gains in the report.
• Programs holding the base are named. If Simux, CLS2Sim, the Brunner USB Config Tool or FFB-Bridge holds the base, FFB-Probe names it and tells you how to close it. On Linux, if access to the base's configuration interface is denied, FFB-Probe shows the udev rule line to add.
• Rotated directions are recorded as measured. The 90° turn in directions you may feel in DirectX mode is how Brunner's DirectX mode maps its axes; FFB-Probe records it as measured.

MOZA flight bases

• Readiness is checked before a run. FFB-Probe reads, without changing anything, whether a MOZA AB9, AY210, AB6 or AY90 will actually play force-feedback effects. A base in MOZA Cockpit's Telemetry mode, or with force feedback disabled, torque output inhibited or game gain at 0, moves nothing; earlier builds reported that as "did nothing", and reports from such a base now say it was not ready.
• Optional base preparation. "Prepare base for testing" switches the base to DirectInput mode and opens its force-output gates after saving your settings, and "Restore my MOZA settings when finished" (on by default) puts them back afterwards. Travel limits, calibration and Force Sensing are never touched.
• A safe strength ceiling. MOZA flight bases and Brunner bases run the effect tests at no more than 35% strength, FFB-Bridge's ceiling for that hardware, so an unheld stick is not driven into its end stops.

Other programs using your device

• Conflicting programs are flagged. The Welcome screen warns when a program that can take your device is running: FFB-Bridge, MOZA Cockpit / Pit House, Brunner's tools, Logitech G HUB or a flight simulator.
• Clear exclusive-access errors. When another program holds the device exclusively, FFB-Probe says which one instead of failing with a generic error; on Linux, the processes holding the device are named. These program names are shown to you only and never added to the shared report.

Sharing never fails on a valid run

• No more lost runs. One long note or one extra chip used to make the website reject the entire report. Every field is now held to the website's limits before sending: selecting every chip works, very long notes are shortened, and placeholder device names such as "test" become Unknown force-feedback device vvvv:pppp.
• Better path scrubbing. File paths are removed from error messages more thoroughly, including Windows paths with spaces in the user name.
• Support code and device link after sharing. Both are shown in the app and on the HTML report's Share button.
• Same format, same privacy. The report format is unchanged (schema: 1), and your typed notes remain private and never appear on the public device page.

More accurate results

• Signed motion measurement on Windows. The probe now measures how far and which way the stick moves during every effect on Windows, as it already did on Linux. Readings are signed, for example X peak +25.1%, so they show the direction.
• Effects stop on time. Each effect stops as soon as its playback window ends instead of when you answer. Some firmware, such as Brunner's, kept a 5-second force running about a second longer.
• Autocenter stays out of the way. The device's own autocenter spring is switched off during the live tests and restored afterwards, so it no longer fights or masks the effect being tested. On Brunner bases it blocked every effect.
• More answers reach the report. Ramp answers are now included instead of discarded, and polarity, two-axis and saturation results appear in the public diagnostics.
• Device class is recorded. Reports record whether the device is a joystick, flight stick, wheel or gamepad, so the public database can tell flight hardware apart from wheels.
• Correct effect parameters. Autocenter tests exercise the autocenter property (earlier builds used the wrong property id), and spring, damper, inertia and friction use the coordinate convention DirectInput expects. Unknown devices report their real driver name again on Windows.

The app

• The live readout follows the device under test. It used to show the first game controller Windows listed, so on a rig with more than one controller it did not move.
• Stop works everywhere. Stop works at every point of a run, Esc stops a run, and closing the window during a run stops the effects and releases the device first. Only the selected device is tested, and the probe engine stops if the app closes.
• Easier to use. Answers can be skipped, the window can be resized, and the text is easier to read.
• Better-timed update offers. Updates are never offered while a run is in progress, and beta builds are not offered to people on the stable release.

Linux

• Repeating a test works. "Run test again" now plays the effect again.
• Kernel autocenter is handled per effect. It is switched off while each effect plays and restored between effects, and never touched on the Logitech G940, whose driver ignores the setting.
• Fewer files per run. Normal runs write just the HTML report and the share JSON; the legacy support files are written only when FFB_PROBE_KEEP_LEGACY=1 is set.

Device naming

• New and corrected names. MOZA 346E:1002 is now named the MOZA AB6. Added: MOZA AY90 (346E:1003), Brunner FFB-G / FFB-H, the PicoWinder SideWinder FFB Pro adapter (CAFE:4004) and Adapt-FFB-Joy (03EB:204E).

A report-sharing fix for Linux distributions that describe themselves with a distribution pretty name instead of a kernel-style Linux string.

Report sharing from Linux

• One coarse os.family token. The submission payload's os.family is now always one of Windows, Linux, macOS, or Unknown. On .NET 8 and later, Linux reports the distribution pretty name — Fedora Linux 42 (Workstation Edition), for example — which earlier builds forwarded verbatim, and the website rejects values over 32 characters with os_family_invalid.
• Pretty names resolve through the running platform. Distribution names that never contain the word Linux, such as Ubuntu's, now resolve through the platform the probe is running on instead of the OS description, so they no longer fragment the public database's per-OS capability snapshots.
• Existing installs keep sharing. The website also normalises legacy values at intake, so reports from older builds share successfully without updating first.

Automatic updating arrives on Windows and Linux, carrying forward the measured-motion and hardware-identification work published earlier the same day.

Automatic updates

• A private startup check. 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.
• Windows can complete the upgrade. 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.
• AppImage installs can update themselves. 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.
• Safe fallback for other installs. 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.

Hardware and Linux improvements included

• Measured motion during Linux effects. Live tests now sample the device axes while a force plays, recording objective displacement alongside the tester's answer.
• MOZA AY210 guidance. The AY210 (346E:1001) has a canonical name and pre-flight guidance for the vendor settings that can mask externally commanded forces.
• Correct, consistent hardware names. MOZA 346E:1002 is identified as the shared AB6/AB9 base PID, and the adapted SideWinder Force Feedback Pro at 03EB:2056 uses one cross-platform name in the app and public database.
• More robust Linux discovery. Driver-path and HID-descriptor resolution are more defensive, and autocenter is written only when the device advertises that capability.

Upgrade note

• One manual update for existing users. Versions through 1.0.6 do not contain the updater, so they must install 1.0.7 manually once. Releases after 1.0.7 can then be installed from inside the app.

A hardware and Linux evidence release that was superseded by 1.0.7 before the website download channel advanced.

Linux measurement

• Axis telemetry joins subjective answers. The Linux worker records measured displacement while effects play, helping distinguish a working effect from an incorrect 'did nothing' response.
• Safer device setup. Input-event paths and HID report descriptors resolve more reliably, while FF_AUTOCENTER is touched only on hardware that exposes it.

Hardware identity

• MOZA AY210 added. The AY210 (346E:1001) receives a canonical name and MOZA Cockpit preconditions before testing.
• MOZA AB6/AB9 PID corrected. The shared 346E:1002 identifier no longer implies only one of the two compatible base models.
• Adapted SideWinder name normalized. 03EB:2056 now aggregates under one Windows/Linux name. This was a naming correction, not a new actuation-support claim.

Linux packaging

• User-scoped AppImage installation. The AppImage gained built-in --install and --uninstall desktop integration for the user's Applications and XDG directories.

A Windows actuation fix for firmware that starts in its own spring mode and otherwise accepts Probe commands without producing physical force.

Fixes

• A clean device state before live effects. After acquiring the device and setting global gain, the Windows worker sends a best-effort DirectInput STOPALL before the live test sequence begins. This clears firmware-owned default forces so uploaded FFB Probe effects can take control from the first test.
• No destructive reset. The fix deliberately avoids DISFFC_RESET, preserving the device effect table and reserving a full reset for crash recovery.

Who benefits

• Default-spring and DIY firmware. The change targets devices—including Fino-derived DIY yokes—that report successful Create and Play calls but remain held by a startup spring until STOPALL is issued.

A focused interface release that keeps every required action reachable inside the fixed-size wizard window.

Checklist layout

• Unknown-device naming no longer covers the controls. When the extra 'Name this device' card appears, the checklist cards scroll while the Arm probe, Back, and progress controls stay pinned and visible.

Test-answer layout

• Long private notes stay contained. The answer area can scroll and the multi-line notes box has its own height cap, so Continue and Run test again remain reachable regardless of note length or selected chips.

Regression coverage

• Problem layouts are covered by screenshots. The screenshot harness now renders both an unknown-device checklist and a long multi-line answer, guarding the layouts that regressed.

A metadata and device-identification hotfix that keeps public hardware rows clean and makes unknown devices explicit before sharing.

Consistent submission metadata

• FFB Probe versions use stable SemVer. Uploads now send values such as 1.0.1 without an SDK source-revision suffix, so the public database does not split one release into multiple build strings.

Device names

• A shared 138-entry VID:PID catalog. Windows, Linux, the GUI, and the website gained a much broader force-feedback name table, including MOZA AB9 and Logitech G940 identifiers.
• Unknown hardware must be named. The GUI pauses at the checklist for a manufacturer/model name, interactive CLI runs prompt, and automation can pass --device-name. Generic placeholders are rejected before upload.
• Useful platform names remain available. Non-interactive runs retain a meaningful sanitized OS name when one exists, otherwise they use an explicit Unknown force-feedback device VID:PID fallback.

Website coordination

• App and database names now match. The website received the same normalized catalog, so old and new submissions aggregate under stable names.

The first stable public release of the standalone FFB-Probe diagnostic for Windows and Linux.

Guided hardware testing

• A complete tester-focused wizard. FFB-Probe detects a connected force-feedback device, presents a safety checklist, plays short live effects, and records what the tester felt after each one.
• Broad effect coverage. The test suite checks constant, conditional, periodic, spring, damper, inertia, and ramp behavior, with diagrams and section-aware progress.
• Windows and Linux from day one. The Windows DirectInput worker and Linux evdev worker ship behind the same cross-platform Avalonia interface.

Reports and sharing

• Human-readable and machine-readable output. Every run writes an HTML report and the exact JSON submission payload locally, so testers can inspect the evidence before deciding whether to share it.
• Sharing is opt-in. Nothing uploads automatically. The result screen and saved HTML report expose the share action only after the tester can review the collected fields.
• Public facts, private notes. Hardware capabilities, effect answers, and closed-vocabulary diagnostics can support the public database, while free-text notes remain private for support triage.

Release packages

• Self-contained releases. The public release includes a per-user Windows installer and a Linux x86-64 AppImage with the .NET runtime bundled.
• Signed Windows distribution. Stable Windows binaries and the installer are produced through the release workflow under the Rohsam publisher identity.