I’ve added a poll on how to set up endstop effect settings.
not bugs, but noticed a few things in testing:
- i can run a much higher TBW now (from 220->1000) when using the reconstruction filter, even at low values of 2-3. with the old firmware i used to get a lot of “marbles” feeling in the wheel and “mechanical” noise in the servo (akm)
- when sitting in the skippy in the pits, the reconstruction filter produces oscillations. if i turn the reconstruction filter off, the oscillations stop
- the config tool needs a more obvious “simcube” icon. at the moment, it looks like a generic “app”
Does the oscillations happen with all filter settings 1-10? What type of encoder do you have?
Our graphics guy has a todo list, I actually made him one almost two weeks ago. They are coming, but not on top of the list 
i’m running a 40k cpr encoder on an akm53
the oscillations happen at all reconstruction filter settings, but they differ in behavior.
at 1 - they are high frequency, start with a small amplitude and increase slowly
at 10 - they are a lower frequency, start with a larger amplitude and increase extremely rapidly. after two or three swings i have to hit the e-stop
a setting of 5 is somewhere in the middle.
Add some dampening if you haven’t that will solve the oscillations with the skippy. a small amount probably 1-2% should completely get rid of the oscillation at lower reconstruction filter settings. The higher number reconstruction filter does get unstable at times and this is one of the areas that we are working on as far as how far is too far with the reconstruction filter and what settings are best and/or most usable.
Some oscillations do come naturally from the way force feedback works especially when sitting still. Oscillations come from the feedback in that the wheel turns off of it’s intended position (either by just not being positioned perfectly at stand still or you touch the wheel) and then the system detects this off center and sends a signal to correct for this. It will then pass to the other side of center and get an opposite signal and then it slowly increases in strength as the signal is increased at each subsequent overshoot. Dampening helps to stop this overshoot and is needed to stabilize the wheel… Cars without power steering such as the Skippy and the DW12 or Indycar are more prone to this because the steering systems are more direct…
Dampening slows and tried to stop this movement over center quelling oscillation… This information will also be part of the next User Guide update. to some degree this information is in the current version of the guide as well. But it does work a bit differently (in ranging not manner) when the Reconstruction filter is enabled.
Glad to hear you are further exploring the inner workings of the force reconstruction filter. Most appreciated if you can share simulated measures how the filter behaves, it would help us testing by knowing what to expect and aim for when changing filtering values. Following pondering is based on my assumptions I got when testing beta firmware and reading posts here and in iRacing forum. Feel free to correct if these aren’t how things are implemented or comment if you have different opinions. And just to clarify, I’m enjoying things as they are in the beta phase, thank you guys for the hard work you’ve done, just tossing ideas around.
New force reconstruction filter is great for what it’s made for. It very effectively smoothens the feeling from stair step like FFB-signal games are providing while maintaining expected force curves. With MMOS, stair steps were clearly felt in steering wheel if run without huge amounts of filtering. This was most obvious in iRacing with 60hz FFB update rate, but the same was true to some extend with every other sim with MMOS. While offering smooth feeling with fast filtering, new force reconstruction filter also gives more “lively” steering which is great in some cases, but also comes with shortcomings in certain scenarios. My biggest worry is overshooting nature of predictive/extrapolating filtering because now filtered force values exceed raw values calculated by game. While it doesn’t look quite so bad with relatively low frequency triangle wave, overshooting can be seen in simulated force curve Tero posted some time ago. I’m guessing this is with filter setting 1, it would be nice to see simulation with other filtering setting values too.
I assume overshoot gets quite vicious when we have sharper changes in raw FFB signal than shown in triangle wave example. If we take for example sharply oscillating FFB forces where raw signal is changing from -50% force to +50% force within one sampling period (50% force pulling towards left, then rapidly 50% force pulling to the right), at the peak overshooting filter will give us briefly a force of 100% pulling to the right. 50% forces come from raw values, then added with 50% from prediction/extrapolation as previous sample change was 100 units (from -50% to +50%). Result is filtered force being momentarily twice the force calculated by the game. Such rapidly swinging forces probably shouldn’t be created by sim in the first place, but at least in rFactor 2 instant and large FFB value changes are occurring in normal driving situations. Higher force reconstruction filter values than 1 will supposedly take more samples in account when calculating filtered force curve, but won’t remove the overshooting, only somewhat average it out. This is of course only my understanding how current filter works based on that one graph and would gladly hear from you guys if this is anywhere accurate assumption.
Theory aside, new filter feels great in iRacing and Assetto Corsa, as their raw FFB signal is quite smooth and won’t induce much forces prone for overshooting. It might even be that overshooting nature of the reconstruction filter is the key why we can now use more damping while retaining good amount of detail as filter can exaggerate sharp forces which would otherwise be deadened by damping.
Most problematic game for me with beta firmware has been rFactor 2 as its FFB signal is lot spikier than in iRacing or AC. Without enough filtering the FFB is very harsh, almost like driving with steel tires. Some car/track combinations also produce very strong and high frequency vibrations (e.g. Radical in Matsusaka pit lane with TBW 1000hz or higher, ingame or simcube filtering <7). With too much filtering cars feel bouncy like having overinflated tires. I think this is due in-game filter retaining the overall amount of energy in short FFB spikes, but spreading the force over longer period of time and force reconstruction filter’s tendency to maintain force in short FFB bursts is not playing nicely with in-game filtering. Best combination seems to be leaving in-game filtering to zero, force recon filter to 4-7 and lowering TBW to 470-680hz. This gives quite nice rubbery feel and feels more direct (=less latency) than what I used in MMOS (in-game filtering at 5-8 and MMOS filter at 5).
Now reasoning what would allow even less filtering and more direct feel in games like rF2, I think there’s two components. One is limiting filtered force values to at maximum the same as raw values, i.e. no overshooting. Below is a mock-up graph showing the idea what would proposed signal filtering look like. MMOS’s moving average filter was something like this I guess.
This probably would deaden the feeling in games where FFB is not very lively to begin with, but would allow using overall higher FFB levels without hitting extreme forces in short bursts with games like rF2.
Second component of the filter would be implementing faster filtering when forces are decreasing. This is based on the concept that increasing FFB forces are usually felt through relatively soft tires which are flexing when e.g. hitting a bump or cornering, thus forces shouldn’t be so rapid and in some games we need increased filtering to get that rubbery feeling. But when the tire catches air after a bump or otherwise loses grip, force release should be almost immediate. If force release follows the same slow reacting filter than force increase was set in order to have rubbery feeling, it feels like there’s “residual” forces even after steering should have loosen up. This is most easily felt in rF2 with stiffer cars and bumpy roads, like F2 and Sao Paolo (T1-T2 and T11). If filtering is set high enough to get rid of mechanical feel and noise from motor, bumpy sections on the road feel like they’re covered with large speed humps. I assume that filter which would smoothen the spikes by rounding FFB curve’s ramp ups without overshoot and not spreading total “impact” energy over a longer time period, would offer improved feeling allowing less overall filtering while still taming excessive vibrations and sharp forces. Below is an illustration where increasing forces are filtered over three previous samples and decreasing forces only over one previous sample.
I know proposed filter wouldn’t be optimal by any means. Overall amount of forces are lowered from raw values and some information is lost. Even if it might help coping with rF2’s FFB (and I’m not 100% sure even about that), it most probably won’t provide best results with all the games. But since we are already creating special filters to improve suboptimal FFB signals offered by different games, I think alternative filtering methods to choose from would make good case for further development. Even MMOS-style simple moving average filter would be nice addition to Simucube’s repertoire as it’s got some positive qualities too and might come in handy with some games. I know if any new filters are to be implemented, they’d need to be translated into mathematical functions and I don’t currently have any clue how that’s done. But if new kind of filters are possible to implement and in anyone else’s interest, I’m willing to dig in more into this.
To wrap up, three main thoughts:
- It would be nice to have more information on how Force Reconstruction filter works, particularly with higher filter values than 1.
- Force Reconstruction filter being excellent as it is, could it still be possible to implement more filters to choose from?
- My impression is that less energetic filtering might do good things to rF2’s FFB signal: no overshooting (no prediction/extrapolation) and faster filtering for decreasing forces.
4 Likes
Tero’s picture was with the setting at 5. Lower settings have significantly less oveshoot, where as 9-10 are really bad and the spike has >20ms lag also.
We are doing other types of filters too, sometime in the future.
Different filter algorithms for signal directions might be difficult to get working reliably.
Important thing to note is that filter types in your pictures 2 and 3 already have unwanted general lag. We don’t want that
And based on the general feedback from current filter, the small spike/overshoot doesn’t seem to matter too much. I think that on lower settings 1-4,much of it gets filtered by wheel/servo naturally.
[quote=“bsohn, post:194, topic:43”]
Add some dampening if you haven’t that will solve the oscillations with the skippy. a small amount probably 1-2% should completely get rid of the oscillation at lower reconstruction filter settings.[/quote]
I am running dampening at 2%, friction and inertia at 1% each, in both cases (recon filter enabled or disabled)
i can increase the dampening values (and yes, i know that sitting in the pits is not the focus), but the reason i posted the “when sitting in the skippy in the pits, the reconstruction filter produces oscillations. if i turn the reconstruction filter off, the oscillations stop” feedback, was to point out that the oscillations only occur when the reconstruction filter is enabled. when it’s off, i have no oscillations.
i was thinking that behavior might be interesting or useful information.
Its useful information for sure. I wonder if it is a combination of that high-end servo and good encoder, or what does it…
New poll about how to present value for endstop angle (separate from steering angle).
Still, not sure to handle how to handle user changing steering angle suddenly from 900 to 10, for example. If endstops are enabled, this could result in rather wild spinning wheel. So, need to check for wide range of user hardware damaging possibilities for this, or just to disable changing steering angle if e-stop is not pressed.
Suggestions?
I’d suggest a function to automatically disable endstops as soon as there is any change to the wheel angle
Like a reset
Normally it wouldn’t make any sense to change the wheel angle and not change the end stops accordingly
The problem with this is that users requested auto-applying settings, so if endstop just gets disabled (its very doable), the moment user checks the enable endstops again, auto-apply would again enable them. I could implement some default “gentle” settings to endstop to be applied whenever user enables them via the checkbox, but this would result in user losing the previous settings.
But even when auto applying settings ( which only makes sense if you change sim and car), wouldn’t it be possible to first reset the endstops, then change the angle and then reapply endstops?
Automaticity has to be through a setting file, so it should be possible to just read it out on the fly an apply settings step-by-step ?
Yeah, but must somehow prevent applying settings that would cause wheel to fly towards center in unexpected ways.
I might even take auto-applying settings out for now, because of safety.
What about auto Apply only works with in 10 degrees of center.
What is the advantage of auto-apply of changed settings if you can just save the settings by just clicking one button?
For me, auto-applying settings is not a necessity.
It is useful but it is also useful to see if there is a reasonable fix as … For me I have dampening 5.5% with nothing else and TBW Unlimited and no oscillations up to 5 haven’t tried anything else though higher yet. I posted the comment because there are some inherent factors that cause oscillations so not all can be corrected out as easily as with a filter. One of the reasons why it shows up with the reconstruction filter and not the normal filter off is that filter off is sending the FFB signal into the SimuCUBE system at 60hz where the reconstruction filter takes that signal filters it to be more accurate to intended and then updates it to the system at a far greater number (I’m not sure of the exact but 2000Hz or so) with this any small movement off position can start the feedback oscillation loop.