rFactor2 FFB Technical Analysis

Discussion in 'General Discussion' started by Pax, Aug 16, 2013.

  1. Pax

    Pax Registered

    Joined:
    Dec 28, 2011
    Messages:
    44
    Likes Received:
    7
    Hello rFactor2 users and ISI staff,

    Using my own developed FFB controller I made a detailed rFactor2 analysis back in March (build 156) - but I did not get around to post it here, where it really should be (I had to split the post into multiple parts due to forum size rules):

    -------------------------------------

    Hola FFB-aficionados,

    I thought I’d share a little update on what I have been fiddling with lately:

    As you know from above posts, I have added an I/O module to my FFB controller which I can use to output arbitrary data from the FFB controller to a PC host.

    I have added some code to the FFB-controller that outputs the actual force level sent to the steering wheel power electronics, together with a time stamp. This info can be used to visualize and analyze the actual FFB signal produced by simulators. This capability is especially interesting in conjunction with rFactor2, which:

    1. Does not allow to via telemetry show the actual force ratio produced (this is possible with iRacing).
    2. Does not allow to read out telemetry data any faster than 100 Hz, which is considerably slower than the actual 400 Hz FFB update rate. This makes e.g. Motec not possible to use to accurately show the force output to the steering wheel.

    With my FFB controller, I am now able to address both the 1 and 2 issues, plus more.

    In addition to the code added to my FFB controller, I have also written a number of Python scripts which arrange the data and make further calculations on it. The script outputs are fed to a data set visualization and analysis SW. Below I present some results of this.

    400 Hz FFB output - Overview and Update Rate Analysis

    Let us start by looking at what two laps in rF2 at Croft in the C6R look like (first lap is the out lap) (you can click on all diagrams for a full size version):

    [​IMG]

    I had the rF2 FFB multiplier at 0.7, but still you see some clipping. If zoomed in, one can also see some extreme variations, where output force goes from -max to +max (and vice versa) in one physics engine tick(!)

    One can also see periodic, high frequency oscillations around a force offset. Those oscillations can clearly be felt in rF2 when driving, as intermittent high frequency “buzz” in the steering wheel. It is probably some artifact due to instability/resonance in ISI’s physics engine/model. These oscillations can be seen even more clearly in diagrams below.

    ISI forum post addition:

    I just did a session in build 240, and the oscillation/resonance is still there. It is felt quite clearly in the C6R, but not much at all in some other cars I tested.
    Here is a detail graph showing resonance within the red ellipse (taken from build 156):

    [​IMG]

    /ISI forum post addition

    Let us also look at a zoomed in detail of the FFB output:

    [​IMG]

    As you can see, the time delta between two consecutive updates from the PC host varies between 1 to 4 ms. This variation is due to PC host variation in FFB output frequency on the USB bus, caused by Windows 7 task scheduling, event servicing and probably other variations present in a “rich” OS like Windows.

    Let us analyze the host update rate variation further. Here is a histogram showing the time delta distribution of updates for the entire captured range of two laps.

    [​IMG]

    The lowest bar you can disregard, as that is the very first output in the log. It is interesting to note that there are two stray outputs at 8 and 17 ms respectively, caused by hiccups somewhere in Windows 7.

    As you can see, the distribution is quite symmetric around 2.5 ms, and if you calculate the average consecutive output delta, it is almost exactly 2.5 ms = 400 Hz.

    From the histogram it looks as if the distribution is evenly spread between integer ms, but that is (naturally) not the case. No output is farther away from an integer ms than 0.1 (the resolution is 0.1 ms for this test, so I could not see smaller time spans), which is expected due to the “strict” USB channel timing and the ~deterministic nature of the FFB controller.
    In fact, I am somewhat surprised to see that the variations actually can be as large as 0.05 <= variation < 0.15 ms.

    Below is a very interesting visualization of consecutive output time deltas vs. time:

    [​IMG]

    The variations between 1 to 4 ms come in bursts at 1-2 sec intervals, with steady periods of the expected 2-3 ms deltas in between. These bursts are probably due to periodic Windows 7 system activities and scheduling.

    You can also see very regular little 0.1 ms variations, also those most probably due to the PC host and what mostly seems to be irregularities in the USB bus timing. The “little” variations are remarkably large though.
     
    Last edited by a moderator: Aug 22, 2013
  2. Pax

    Pax Registered

    Joined:
    Dec 28, 2011
    Messages:
    44
    Likes Received:
    7
    Force Output Level Variation Analysis

    Another area interesting to look into is how much the force output level varies between two consecutive FFB outputs. Here is a plot showing that vs time (bottom), with the actual force output as reference (top)

    [​IMG]

    As you can see, most deltas are in the 0-4% range, with a number of clear exceptions. We will come back to this in the end of this report.

    Another way of looking at the output force variation over time is to transform the force output signal from the time domain to the frequency domain. By doing that we, can see the sinusoids with their frequencies and amplitudes that make up the “sampled” force output signal.

    Here is a spectrogram showing the amplitude and frequency distribution over time (bottom) with the signal over time as reference. In the spectrogram, brighter color is higher amplitude.

    [​IMG]

    We see that the higher amplitude sinusoids are generally in the sub 2 Hz range. We can however see that the frequency and amplitude resolution for lower frequencies is limited in the spectrogram.

    Another way of visualizing the amplitude and frequency distribution is to generate a spectral density diagram, which shows the amplitude of the sinusoids that make up the signal.

    [​IMG]

    The spectral density diagram allows us to more clearly see the low frequency amplitudes, which shows that the sub 0.4 Hz amplitudes are very dominant compared to the high frequency amplitudes.

    It is important to note however that the above two transforms require a constant “sample” rate, in this case 400 Hz, to be entirely correct. As we have seen, that is not the case as the interval vary over time. Nevertheless, the transforms should be accurate enough to convey the general frequency/amplitude trend.

    EDIT2:

    I would like to add some to the initial frequency domain analysis, which was very brief in what I first wrote.

    Unlike in the frequency domain analysis I made of FPS output of an SLI Surround vs an Eyefinity system almost two years ago, the FFB output does not have any clearly unwanted characteristics. Instead, the FFB output should have both low and high frequency and magnitude components, as that is what is in the real world, non simulated counterpart.
    (If anything, very high magnitude and frequency components approach the limit of what the sim engine can handle, which is a problem in itself)

    So, what we can do is to manually look at the entire time domain FFB output and see if the frequency domain spectral density diagram looks reasonable.

    First observation is that the time domain FFB output shows a general tendency of having large magnitude shifts with a period of some 5-15 seconds. These are of course from turning corners. This then give frequencies of 0.2-0.07 Hz.
    Looking at the spectral density diagram, we indeed see large magnitude frequencies from around 0.25 Hz and below, so it seems reasonable (the _very_ low frequencies are less obvious to read out though).

    Then we have the high frequencies. Looking at the time domain FFB output, we easily see that we have much small magnitude high frequency oscillations. This corresponds well to the spectral density diagram.
    Less obvious are the large magnitude high frequency components we have in the time domain FFB output. These are found as parts of the abrupt changes due to turning into and out of corners, plus surface impacts.
    We do however not see any individual, high magnitude sinusoids in the spectral density diagram. So, the large magnitude high frequency components we have in the time domain FFB output should then (partly) be the result of superpositioning of many lower magnitude sinusoids.

    Another important factor here can also simply be that I have stated a 400 Hz sampling rate, whereas in reality the sampling rate often is higher than that (< 2.5 ms between FFB outputs). This results in frequencies higher than what our frequency domain analysis above is capable of revealing.

    /EDIT2
     
    Last edited by a moderator: Aug 16, 2013
  3. Pax

    Pax Registered

    Joined:
    Dec 28, 2011
    Messages:
    44
    Likes Received:
    7
    FFB Update Rate - Impact Analysis

    Lastly, let us look at the very interesting topic of how the force output is affected by output update rate. We know rF2 runs at 400 Hz, and iRacing at 60 Hz. What would the rF2 output we have used above look like if it was output at 60 Hz instead?

    As you might know, rF2 has the option to reduce FFB update rate, and we are e.g. able to reduce it to 57 Hz - which is the closest to 60 Hz we can come. I have written a Python script that uses the same simple technique rF2 uses to reduce the FFB output range, and applied it to the 400 Hz output data set used above.

    Below are a few detail diagrams showing the full 400 Hz output (top) vs. the 57 Hz version (bottom).

    [​IMG]

    [​IMG]

    [​IMG]

    We see that, as expected, much higher frequency information is lost, and you have some distortion both in amplitude and time.
    In the 400 Hz output, we can also see the (artifact) high frequency oscillations mentioned above.

    It also seems reasonable to expect that generally, the force output level delta between two consecutive FFB outputs is higher at 57 Hz output rate than at 400 Hz output rate.

    Here are two histograms showing the force output level delta for 400 Hz (top) and 57 Hz respectively (0-100%, 1000 bins):

    [​IMG]

    As we can see, the difference is clear but not very large. For 400 Hz output rate, no force delta bin > 3.8% has more than 0.1% of the total number of outputs. For 57 Hz the spread is larger; no force delta bin > 6.7% has more than 0.1% of the total number of outputs.

    Another view of this is to look at the number of outputs in each bin instead of percentage:

    [​IMG]

    The total number of outputs @400 Hz are ca. 80000, @57 Hz ca. 11000. One can see that the 57 Hz output has few outputs >50%, probably because the sample rate is too low to capture the large and fast transients we see in the 400 Hz output.
    Note also that the 400 Hz output has 5 100% deltas(!)

    Yet another way of looking at the force level delta is to calculate its average over all outputs. This tells the same story: we have 0.76% in average for 400 Hz and 1.53% for 57 Hz.

    The above indicates that rather than large force output level deltas being a major issue at 57 Hz, the long time each force level is in effect at low update rates is a major issue. This can create a step-wise, non-analog feel at the steering wheel rim. Also the time distortion of the signal might be an issue at this low update rate.

    EDIT1:

    I have updated one of the Python scripts to calculate the share of force output level deltas that are larger than a certain threshold level.

    For a delta threshold level of 5%, 1.01% of the deltas were larger @400 Hz. @57 Hz the figure was 4.36%.
    So, there is a clear difference between 400 Hz and 57 Hz, to the disadvantage of 57 Hz.

    /EDIT1

    Let us not forget though that the mechanical and electronic characteristics of the wheel used very much affects what is actually felt at the steering wheel. But, with a high performance FFB wheel/system, the overall percepted difference in quality between 400 Hz and ~60 Hz is very evident, and the above visualization and analysis support that subjective impression.


    There you have it, a little rF2 FFB analysis!
     
    Last edited by a moderator: Aug 16, 2013
  4. Pax

    Pax Registered

    Joined:
    Dec 28, 2011
    Messages:
    44
    Likes Received:
    7
    Reserved 3
     
  5. C3PO

    C3PO Registered

    Joined:
    Aug 31, 2012
    Messages:
    1,087
    Likes Received:
    86
    Excellent read. rF2 FFB is the best in any sim. Interesting to actually see why now.
     
  6. Bart S

    Bart S Member

    Joined:
    Oct 5, 2010
    Messages:
    851
    Likes Received:
    104
    Does this mean your controller is ready for use? Great read BTW that's some real high level frequency analysis. Hope its also useful to isi to improve things better if they can.
     
  7. DrR1pper

    DrR1pper Registered

    Joined:
    Apr 29, 2012
    Messages:
    3,294
    Likes Received:
    36
    A thoroughly enjoyable read Pax. Thanks!

    Can someone post the ffb update rate of the different wheels? I'm curious as to the leap from the g25/27 to a t500 or csr-e/csw in this regard.
     
  8. Ricknau

    Ricknau Registered

    Joined:
    Nov 12, 2011
    Messages:
    778
    Likes Received:
    39
    I'm not seeing the 1-4ms variance in update intervals. Judging from the graph all I see are 2 and 3 ms intervals. In fact I see total regularity in that it alternates 2 3 2 3 2 3.. etc. Am I not reading it right?
     
  9. SPASKIS

    SPASKIS Registered

    Joined:
    Sep 7, 2011
    Messages:
    3,155
    Likes Received:
    1,426
    Very interesting post pax. I will take a closer look from my pc. I am particularly interested in those resonance problems you mention. Could it be possible to know at which frequency they appear?

    Enviado desde mi GT-I9505 usando Tapatalk 2
     
  10. DrR1pper

    DrR1pper Registered

    Joined:
    Apr 29, 2012
    Messages:
    3,294
    Likes Received:
    36
    Yep, that's exactly what i was after thanks. So 2ms latency (500hz) on the t500.

    Anyone know for the g25/27 and csr-e/csw?
     
    Last edited by a moderator: Aug 18, 2013
  11. datanode

    datanode Registered

    Joined:
    Oct 23, 2012
    Messages:
    457
    Likes Received:
    0
    The fanatec wheels say in one particular update of firmware an update rate of 500hz.

    Don't know about the csw or csr-e, but it should be at least 500hz
     
  12. datanode

    datanode Registered

    Joined:
    Oct 23, 2012
    Messages:
    457
    Likes Received:
    0
    Maybe this helps:

    http://f-wheel.com/reviews/csr-elite-wheel-benchmarked

    (See this part though, they made a mistake)

    And:

    http://www.911wheel.de/?q=node/8543

    As the test is old, t500 is at 500hz, as are the logitechs and despite a mistake the fanatecs also.

    The second link gives you a full list of fanatec wheels that can use the 500hz firmware.
     
    Last edited by a moderator: Aug 19, 2013
  13. DrR1pper

    DrR1pper Registered

    Joined:
    Apr 29, 2012
    Messages:
    3,294
    Likes Received:
    36
    thx datanode.
     
  14. datanode

    datanode Registered

    Joined:
    Oct 23, 2012
    Messages:
    457
    Likes Received:
    0
    More than welcome, I have been doing lots of stuff with my old GT3 RS V2 (which isn't even that old) but old enough to have missed out on the new clubsport pedals and csr elite :) one day! :)

    I think a graphics card upgrade is well overdue first :)
     
  15. Terence Groening

    Terence Groening Registered

    Joined:
    Oct 13, 2010
    Messages:
    169
    Likes Received:
    0
    Pax, excellent work! This data is quite interesting and useful.

    One question for you: do you know if those intense force level variations happen to correspond to quick changes in steering angle? It's too early to say, but we may have a possible improvement in the pipeline for those and the oscillations.

    Thanks for any additional info.
     
  16. Bart S

    Bart S Member

    Joined:
    Oct 5, 2010
    Messages:
    851
    Likes Received:
    104
    Thats it, I wanna Pax wheel, where do I sign....
     
  17. Atle Dreier

    Atle Dreier Registered

    Joined:
    Jan 14, 2012
    Messages:
    84
    Likes Received:
    2
    Excellent analysis. I love these posts! :)

    terence, it sure looks like the +1/-1 snaps occur at polarity changes in the force, which usually occur as the vehicle change direction. I'm pretty sure I've felt those as a 'ping' in my wheel (T500RS).

    [​IMG]
     
  18. Rik

    Rik Registered

    Joined:
    Oct 5, 2010
    Messages:
    1,174
    Likes Received:
    9
    agree! if not too expensive ;)
     
  19. Pax

    Pax Registered

    Joined:
    Dec 28, 2011
    Messages:
    44
    Likes Received:
    7
    I swear I saw some 4 ms in there when I looked at it :)

    Anyway, if you look at the delta timing histogram you see there are quite a few 4 ms intervals over the entire sample range.
     
  20. Pax

    Pax Registered

    Joined:
    Dec 28, 2011
    Messages:
    44
    Likes Received:
    7
    Hello Terence,

    and thanks for having a look at this! If any work of this kind can help make rF2 (and rF3 ;) ) better simulators, it is even more inspiring to spend time on it!

    I had a look at the raw log data from the session I used above, and I did not log steering wheel position unfortunately. With the FFB controller logging solution I used above I am limited in log data bandwidth while keeping a 1000 Hz deadline, which is what I use for steering wheel position reporting to the Windows host.

    I could modify my new FFB controller device code to include more logging if you wish, but it should on the other hand be very simple for you to extract the needed data directly from rF2, along with other interesting physics data too!

    ...Or you can kindly ask for the source of this from TecAde :) : http://isiforums.net/f/showthread.php/7546-rF2-Pedal-Overlay-Plugin?p=198126&viewfull=1#post198126

    BR,
     

Share This Page