ffb(engine): band-limit the inertia estimate, let the levels pass 100 - #103
Merged
Merged
Conversation
FF_INERTIA was fed this tick's velocity minus the last one, which on a quantised encoder is an impulse train: a rim turning smoothly reads as a burst of full-count accelerations for one tick and nothing the next, and that came through as grain (#89, where the author of another engine had met the same thing and suggested the cure). The estimate is now the gap between the velocity and a 50 ms one-pole chasing it. The gap of a first-order lag behind a ramp settles at slope times tau, so a steady acceleration reads exactly as before and the effect's scale is untouched, while a one-tick blip becomes a bump of a fiftieth the height that decays over tau. It runs every tick on the held velocity, so a wheel reporting every 2 ms is filtered at the same rate as one reporting every tick, and a stop after the hold decays instead of arriving as one tick of minus the velocity. Fixed point in 1/256ths so sub-count accelerations survive the division, with a snap to the velocity within one step so a parked wheel reads exactly zero. Five effect-math tests cover the steady state, the quantisation case, a step, rest and symmetry. spring_level, damper_level and friction_level accept up to 400 instead of 100, and inertia_level joins them. The engine's gains sit below what the firmware renders by amounts owners have measured (damper at 0.61 of the firmware on a G923 Xbox edition, #87; 2.25x damper and 4x spring on a G PRO, #89), and the cap left no way to try those numbers without a rebuild. The fields widen to u16; the summed force is clamped to the wire range after every effect, so a large level saturates. Defaults are unchanged. Builds clean against 7.2.4 with clang.
mescon
enabled auto-merge
September 14, 2026 21:22
3 tasks
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
For #89 (and the calibration in #87).
FF_INERTIAis fed a band-limited acceleration: the gap between the velocity and a 50 ms one-pole chasing it (hidpp_dd_accel_filterin the effect-math header). A steady acceleration reads exactly as before, so the 4096 scale is untouched; the encoder's quantisation blips become small decaying bumps instead of full-count spikes. Runs every tick on the held velocity, so the G923's 2 ms reports are filtered at the same rate.spring_level,damper_level,friction_levelaccept 0..400 (was 0..100) andinertia_levelis new, so the gains owners measured against the firmware can be tried without a rebuild. Defaults unchanged.make -C tests/effect-math runand the texture-merge suite pass; the module builds clean against 7.2.4 with clang.Not felt on hardware: no wheel is attached here tonight.