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): 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): /ISI forum post addition Let us also look at a zoomed in detail of the FFB output: 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. 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: 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.