rFactor2 FFB output - technical analysis

Discussion in 'General Discussion' started by Pax, Oct 31, 2012.

  1. Pax

    Pax Registered

    Joined:
    Dec 28, 2011
    Messages:
    44
    Likes Received:
    7
    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 :)
     
    Last edited by a moderator: Nov 2, 2012
    Pocisk, PLAYLIFE and KeiKei like this.
  2. CdnRacer

    CdnRacer Banned

    Joined:
    Feb 4, 2011
    Messages:
    1,894
    Likes Received:
    31
    Very interesting. Thanks. I usually don't read long posts. :p
     
  3. Ball Bearing Turbo

    Ball Bearing Turbo Registered

    Joined:
    Jan 11, 2012
    Messages:
    17
    Likes Received:
    2
    Excellent post & thread; looking forward to the exposition.
     
  4. Zephyr RU

    Zephyr RU Registered

    Joined:
    Apr 2, 2012
    Messages:
    85
    Likes Received:
    9
    Thanks.it is nice report.
    :)
    Very useful for everybody.
     
  5. SLuisHamilton

    SLuisHamilton Banned

    Joined:
    Jan 22, 2012
    Messages:
    860
    Likes Received:
    20
    chessus an o the r thing
     
  6. Spinelli

    Spinelli Banned

    Joined:
    Jan 28, 2012
    Messages:
    5,290
    Likes Received:
    32
    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).
     
  7. Terence Groening

    Terence Groening Registered

    Joined:
    Oct 13, 2010
    Messages:
    169
    Likes Received:
    0
    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.
     
  8. CdnRacer

    CdnRacer Banned

    Joined:
    Feb 4, 2011
    Messages:
    1,894
    Likes Received:
    31

    Especially fanatec!!
     
  9. Terence Groening

    Terence Groening Registered

    Joined:
    Oct 13, 2010
    Messages:
    169
    Likes Received:
    0
    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.
     
  10. Gearjammer

    Gearjammer Registered

    Joined:
    Jun 11, 2012
    Messages:
    1,823
    Likes Received:
    24
    The old addage "crap in, crap out" comes to mind there Terence :) I am talking about the drivers, not the rF2 output hehe
     
  11. Pax

    Pax Registered

    Joined:
    Dec 28, 2011
    Messages:
    44
    Likes Received:
    7
    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.
     
  12. Spinelli

    Spinelli Banned

    Joined:
    Jan 28, 2012
    Messages:
    5,290
    Likes Received:
    32
    Also remember, physics sampling rate and ffb output rate are 2 differed things. You probably know this, just a friendly reminder :)
     
  13. Pax

    Pax Registered

    Joined:
    Dec 28, 2011
    Messages:
    44
    Likes Received:
    7
    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.
     
  14. TechAde

    TechAde Registered

    Joined:
    Oct 13, 2010
    Messages:
    606
    Likes Received:
    38
  15. TechAde

    TechAde Registered

    Joined:
    Oct 13, 2010
    Messages:
    606
    Likes Received:
    38
    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.
     
  16. DrR1pper

    DrR1pper Registered

    Joined:
    Apr 29, 2012
    Messages:
    3,294
    Likes Received:
    36
    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.
     
  17. TechAde

    TechAde Registered

    Joined:
    Oct 13, 2010
    Messages:
    606
    Likes Received:
    38
    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.
     
  18. DrR1pper

    DrR1pper Registered

    Joined:
    Apr 29, 2012
    Messages:
    3,294
    Likes Received:
    36
    oh ok, fair enough.
     
  19. TechAde

    TechAde Registered

    Joined:
    Oct 13, 2010
    Messages:
    606
    Likes Received:
    38
    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!
     
  20. 2tyred

    2tyred Registered

    Joined:
    Aug 22, 2013
    Messages:
    22
    Likes Received:
    0
    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?
     

Share This Page