Hello All, here is some info I have gathered in relation to my FFB controller project (this: http://isiforums.net/f/showthread.php/8250-The-LifeOn2-FFB-Wheel-Controller ): The last few days I have spent (a lot of) time analyzing rFactor2 FFB output data to understand more about how the rF2 FFB works. I have asked some basic questions about rF2 FFB in this forum before, but did not get any real answers. So, I decided to take a deep dive into the FFB data output by rF2 to understand more and to end the uncertainty. So, what is a deep dive you might wonder? Well, I have gone through almost 50 MB of rF2 FFB data, equating to some 100000 FFB events. Fun stuff, but it got a bit much at the end I did learn quite a few interesting details, and thought I would share a few non-protocol bound info with you - not least as FFB is always a hot topic of discussion and as we have not known much about the rF2 FFB before. So: * EDIT: feedback from ISI developers have given that the FFB command rate is a fixed 400 Hz. The probable reason for my original observations is timing inaccuracies/latency, either in the log tool or in the USB sub system or in the FFB wheel driver. This could be due to OS scheduling and/or OS wait states. Original text: rF2 does not update FFB to the steering at a fixed rate. Instead, rF2 has varying output rate, with what seems to be a lower bound. Probably the rF2 output rate depends on CPU/core load, how fast the physics engine can output the data needed for FFB, and any varying synchronization timing. It might be the case ISI uses different degree of complexity physics modelling schemes in different situations, which would give varying FFB output rates. * rF2 outputs FFB commands at rates between 400 Hz and all the way up to 1000(!) Hz. The normal, "steady state" case seems to be in the 400-500 Hz range though (at least on my sim rig, an i7 2600K @4.6 GHz). * rF2 has support for canned effects going over kerbs. This support is turned off by default, and ISI relies on constant force output. However, rF2 interestingly enough uses a canned effect command to output a constant force via a rather ingenious method; they basically disable all canned components of the canned effect to just let the canned effect play a static force = what a constant force command does. I did also find what to me seems like a bug (or at least a feature ) related to steering wheel spring force (yes, rF2 has support for the spring canned effect too). In the rF2 controller.ini you have the following line regulating steering wheel spring canned effect: Steering spring coefficient="0.00000" // Static spring effect rate (-1.0 to 1.0) As you can see, in my case the coefficient is set to 0. That should mean the spring effect is turned off. However, there is also the following line: Other spring coefficient="0.20000" // Static spring effect rate (-1.0 to 1.0) for any other FFB-capable controllers Here, the spring is set to 20%. Looking at the actual FFB commands output by rF2 to the FFB wheel I used, this spring of 20% actually overrode the 0% setting above, giving me a 20% static spring effect without me knowing about it. So, if you don't want the spring effect, set Other spring coefficient="0.00000" and see if it makes a difference with your wheel (there could be a difference depending on how your particular wheel model reports to Windows). Lastly, as we obviously have ISI developers here, please feel free to chime in an perhaps give some facts to complement all observations and theories in this post
The non-fixed input rate for ffb, probably explains why people report much better driving feeling (to the point where some have thought the physics improved) when they have very high fps (60-120, or even higher).
How are you measuring these updates? I assure you that rF2 updates the constant force at precisely 400Hz, and it is very consistently distributed through time (almost always within 1ms of the intended time). Perhaps your particular device driver is changing this in some way. For example, Logitech's G25 & G27 drivers usually sample at 500Hz (or was it 512Hz, can't remember at the moment). Perhaps they always update at that minimum rate, but also add a sample if they get a new command that's not within 1ms of their most recent update or something. It's just a crazy theory I'm throwing out there, but I can guarantee my first sentence. And we do not change the complexity of the physics for different situations; there's no "special low-speed tire model" or any of that sort of thing in rF2. Less importantly, the reason we don't use the constant force command is because there are, or at least used to be some very odd behaviors from different drivers. The method we currently use is fairly consistent across drivers, except for the fact that they haven't settled on which direction is positive yet! I'll investigate the claim that "Other spring coefficient" affects or could affect the wheel. With the wheel on my desk at the moment, it definitely does not. On the other hand, I have to manually tell this wheel to turn off its default centering spring; it ignores rF2's command to do so. My experience is that FFB drivers are on the flaky side.
It occurred to me that Pax may be counting effects other than our normal steering 'constant force' effect. For example, if you enable the canned rumble effect, then yes we'll update that occasionally - specifically when you are on a rumblestrip. Another example is collision jolts. CdnRacer - I will say this: a lot of hardware companies have had trouble grasping the fact that even if their actual hardware is competitive, it needs good software to fully realize its potential. And I'm not just talking about steering wheels.
The old addage "crap in, crap out" comes to mind there Terence I am talking about the drivers, not the rF2 output hehe
Hello Terence, and thank you for engaging in the discussion. Right, I have to say I was somewhat surprised to see that rF2 did not seem to use the "conventional" method of synchronous FFB updates at a fixed rate. However, as I had an enormous amount of data to go through, I did not analyze in detail whether the FFB commands I observed was sent from rF2 directly, or if it could be an effect of some other component. Now when I have the fact that rF2 indeed transmits at a fixed 400 Hz, I will go through this data again and see what info I can gather about its origin. I am travelling right now and don't have access to the logs, but my theory now is that the extra FFB commands are the result of resends due to USB transmission failure. Such failure could come from interference on the USB bus, or that the FFB wheel device has signalled that it temporarily cannot accept more input data. Unfortunately I do not have access to the lowest level USB signalling, but it might be possible to infer that some of the FFB data is in fact resends. And no, I have only looked at the constant force output and not any canned ruble strip FFB or collisions.
Also remember, physics sampling rate and ffb output rate are 2 differed things. You probably know this, just a friendly reminder
Hello again, I have now had a look at a few logs and especially a number of entries that showed a FFB command rate of >>400 Hz. These commands were not re-sends (they all reported different force values), so the only explanation for them is timing inaccuracies/latency, either in the log tool or in the USB sub system or in the FFB wheel driver. This could be due to OS scheduling and/or wait states of some kind.
Good stuff Pax! Your work inspired me to add a detailed log to the rF2 Pedal Overlay Plugin. Version 7 can be found here: http://isiforums.net/f/showthread.php/7546-rF2-Pedal-Overlay-Plugin?p=198126&viewfull=1#post198126 This outputs a csv of all commands send to the wheel, along with detailed timing for each send. This should allow anybody with Excel or similar to produce graphs such as yours (example attached).
Attached are some graphs showing the FFB force output and timing as measured with a high resolution timer inside the rF2 Pedal Overlay Plugin. The zoomed in timing graph is interesting. Whilst the average rate is 400Hz (2.5ms) the actual times alternate between 2ms and 3ms very consistently. The noise in the top force output graph is also interesting. This was logged whilst sitting in the garage and turning the wheel (G27) from lock to lock once.
Very interesting. I wonder if it has something to do with the fact that (i presume) your wheel is at 500hz and the rf2 ffb update is 400hz is out of sync. 1/400hz = 2.5ms rf3 ffb ffb timing...which is the average on the graph with wheel ffb timing alternating between 2ms and 3ms.
I don't think so, rF2 is attempting to run at a fixed 400Hz irrespective of the rate the wheel drivers communicate with the wheel itself.
Here's a wild theory... maybe the FFB timing loop is using an integer rather than a float? That would mean it can only 'count' in whole milliseconds and the only way to manage 400Hz when counting in whole milliseconds is to alternate between 2ms and 3ms. I'm sure Terence will be along later to explain that I'm way off the mark!
Would a "position feedback" (as discussed by Leo Bodnar) plugin for RF2 be possible and a different mode to your drivers added to stop the oscillating feedback shown in your youtube videos while going straight?