• Home of the RD Le Mans Series by Vesaro
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

FFB Analysis: iRacing vs. rFactor2

Discussion in 'Sim Racing Hardware' started by Pax7, Dec 9, 2012.

  1. Pax7

    LifeOn2 Development

    Hello All,

    I posted the below analysis over at iRacing the other day, and I thought I'd repost it here for anybody not a member over there:


    With ISI releasing the Skip Barber formula car, there is opportunity to compare rFactor2 with iRacing using reasonably similar input. In this post I take a look at the FFB output characteristics of the rFactor2 Skip Barber Regional and compares it to the iRacing Skip Barber RT2000. Both are driven at Lime Rock Park.

    The main purpose of this comparison is to try to demonstrate the rather different FFB output of iRacing (iR) and rFactor2 (rF2) respectively. The difference in feeling is substantial, and it is demonstrated below. In addition to videos, I will also analyze telemetry output from the video recorded runs to try to further shed some light on what is happening and why.

    All tests were carried out using a Leo Bodnar wheel (with a Frex paddle shifter unit attached). The FFB output of the sims are set not to clip. Unfortunately it is not really possible to have a 1:1 match of the effective FFB output to the wheel from iR and rF2 respectively. I did however try to set the FFB torque output so that the generated torque going through corners were of close enough magnitude. The caster of the cars were set to 5.0 (rF2) and 5.2 (iR) degrees.

    In iR, "use linear mode" is enabled, FFB strength = 7.0, damping = 0%, min force = 0.0%. Baseline setup is used.
    rF2 has a rich set of FFB customization options, so I will not list them all here. I have used the default settings (except for "steering torque per-vehicle mult="0.65000"" and where noted), which are in fact mostly aimed for fidelity. The default setup was used for the rF2 Skip Barber. The "steering torque per-vehicle mult" was reduced from 1.0 to prevent FFB clipping. Unfortunately, in rF2 it is not possible to check for clipping like in iR, so 0.65 is a safe-side guess really. Little known btw is that also rF2 has the ability to control the (linearity) function of the FFB output, but the function is AFAIK not known. The parameter that regulates it is "steering torque sensitivity".

    So, with those preliminaries out of the way, let us get going!

    First, we take a look at how the Skip Barber behaves in rF2 when going in a straight line without the driver holding the steering wheel:

    We can observe a few things in the video:

    * It takes about 1.5 seconds from wheel release until the wheel starts to oscillate.
    * The oscillation has a ~fixed steady state frequency and magnitude.

    The reason for the very start of the oscillation is road bumps, but why does the steady state oscillation occur at all? Is it the way it is supposed to be (at least from how rF2 is designed), or is the oscillation a result of that the rF2 FFB output and steering wheel position sampling rates are not fast enough to stabilize the steering (by the self aligning torque effect)?

    To analyze that and come up with a plausible answer, I will have a look at the telemetry data for the above oscillation.

    But first, for comparison, I utilized the rF2 capability to enable a host of different canned effects. I chose to enable the static centering spring effect, which is sent to the FFB wheel controller once and the spring effect is then controlled at a high loop rate by the FFB wheel controller itself. (Only Leo Bodnar can in this case answer the question of at exactly how high loop rate :) )

    I used the following centering spring settings:

    * spring coefficient="0.20000" // Static spring effect rate (-1.0 to 1.0)
    * spring saturation="1.00000" // Static spring effect peak force (0.0 to 1.0)

    The comments give reasonable information on the function of each parameter. The coefficient determines the rate of change (the gradient) in force as a function of the distance the wheel has traveled from spring center. The saturation determines the fraction of maximum force the centering spring effect is allowed to output. These descriptions of course only are true provided the centering spring effect is implemented according to the USB-IF recommendation in the FFB controller.

    The choice of spring parameter values were not carefully chosen for the test; When looking at them now I think they can easily be set for better results. Here is anyway a video with the above spring parameters set:

    We can see that the Bodnar wheel is capable of centering the wheel nicely and prohibit oscillation.

    Let us now take a look at the telemetry output of the oscillation sequence from the first video (click for larger size):

    * Steering angle > 0 is right turn
    * Steering arm force > 0 is pulling the wheel right


    We see that the frequency of the oscillation is pretty constant from start, but that it takes around 1.5 second for it to reach its steady state magnitude. To better be able to analyze, here is a detail view of the last part of the oscillation (click for larger size):


    We can observe a few basic things:

    * The oscillation period is ca. 0.25 seconds (4 Hz)
    * The time from zero to peak steering is ca. 63 ms.

    As the FFB output and steering wheel position sampling is done @400 Hz in rF2 (once every 2.5 ms), it means rF2 is able to read out steering wheel position and update the FFB output around 25 times while the steering wheel goes from zero to peak steering angle in the above oscillation. That means there is plenty of time for the simulator to have the car behave in an orderly fashion.

    So, as it seems the oscillation is according to an ordered state of the sim physics modelling, what happens is probably that the kinetic energy accumulated due to the weight of the car and the fact that it is turning (=accelerating) makes the steering swing over the center from one side to the other. The side forces eventually stops the swing in one direction and starts it in the other. The magnitude of the self aligning torque of the front wheels as a function of steered angle is not enough to counteract this to keep the steering wheel more centered. ...Hm, any proper vehicle dynamics knowledgeable is welcome explain this better... ;)

    Now, let us take a look on how the iR Skip Barber behaves in the same situation as in the first video above:


    * The wheel goes into large magnitude oscillation immediately after wheel release
    * The magnitude of the oscillation does not increase very much after start. Also the frequency seems relatively constant.

    Here is telemetry output of the oscillation sequence (click for larger size):

    * Steering angle > 0 is left turn (opposite of rF2)
    * Steering wheel torque > 0 is pulling the wheel left (consequently, opposite of rF2)



    * The time to full magnitude is indeed lower than in rF2. In iR it is slightly less than one second.
    * The steering angle magnitude bottoms out at 225 degrees (the wheel is set to 450 degrees lock-to-lock range). In rF2, the magnitude is smaller, around 50 degrees.
    * The oscillation period is ca. 0.5 seconds (2 Hz). Notice here though that left and right oscillations are not equal.
    * The time from zero to peak steering is ca. 100 ms for angles > 0 and ca. 160 ms for angles < 0.
    * At large steering angles, the peak torque occurs clearly after the peak steering angle. This I assume is because of the large kinetic energy of the car when oscillating. It is also interesting to compare with the first oscillation of around 45 degrees, where the torque peak is more aligned with peak steering angle. Notice that iR and rF2 behaves pretty equal for similar steering angles, which is good :) (assuming the steering ratio and other car factors are similar)

    As the FFB output and steering wheel position sampling is done @60 Hz in iR (once every 16.7 ms), in the 100 ms zero to peak time iR is able to read out steering wheel position and update the FFB output around six times while the steering wheel goes from zero to peak steering angle in the above oscillation. That is significantly less than the 25 times of rF2, even though the oscillation frequency in rF2 is twice that of iR.

    In iR, we can also see that at peak steering wheel speed, the steering wheel moves as much as 30 degrees between two steering wheel position samples by iR. That is around 20% of the total zero to peak range for the oscillation I looked at.
    We also observe e.g. a torque output change of 11.5 Nm between two consecutive outputs, which is ca. 38% of the total zero to peak range for the oscillation I looked at.
    Comparing this to rF2, steering changes ca. 6% between two steering wheel position samples. The figure for force is 8%.

    For the driver, the lower consecutive change figure for the FFB output in rF2 (8% vs. 38% in iR) results in a smoother feeling. Also the higher FFB output rate of rF2 helps smoothness.

    Now, let us take a look at a sequence of normal straight line driving in both rF2 and iR:

    Notice the difference in wheel movement from center between rF2 and iR. The movements originate from forces generated by hitting bumps in the track. As you can see, these forces are greater in iR than in rF2. One can argue that it is because of more bumps in the iR version of Lime Rock or differences between the cars, but in my experience what the above clip shows is representative for the general difference in steering force generated from bumps between rF2 and iR.

    Let us study the above normal straight line driving by looking at telemetry including the above sequences in rF2 and iR. First rF2 (click for larger size):


    With the red lines I have marked 1: the approx. average force produced by going through the corner leading out on to the s/f straight and 2: the peak force generated by going in a straight line.

    You can see that the peak force of going down the straight is about 25% of the average force produced by going through the corner.

    Now let us study the same in iR (click for larger size):


    As you can see, in iR the situation is radically different; the peak torque of going down the straight is about 135% of the average torque produced by going through the corner. This is just an example of course and not the definite truth, but in my experience it well represents one aspect of the FFB differences between rF2 and iR.


    So, in conclusion, what do the above findings mean then?

    * As shown above, the higher FFB output rate of rF2 gives a smoother FFB output, which can also be felt by less steering wheel jerkiness.
    * In my opinion, rF2 clearly gives the better balance between steering wheel torque going through corners and torque generated by going over bumps.
    * rF2 has a more stable FFB behavior, which was also shown in the oscillation tests above.

    In addition, not shown in the above tests:

    * The advanced tire model of iR gives a very nice elasticity to the tires which can be felt in the FFB. In this area iR performs better than rF2 in my opinion.
    * The framerates in iR were 3-4 times(!) higher in iR than in rF2 while doing the above tests. In addition to that, iR looked (much) better and crisper overall. Here, ISI has massive work to do to be up to par with iR.

    That's it for this little analysis, thanks for reading!
    • Like Like x 8
  2. Kasper Stoltze

    Kasper Stoltze

    That is so great Frederic, very good job!

    In general, I dont like the FFB of iRacing in any manner, it feels like its to slow, and sometimes way to overdone, but in a wrong way in the wrong situations. Take pCars for an example, it not even done yet, and still the FFB is way better than iR. In general I really like the FFB of rF2 though, but the best i have experienced is GSC i think :)

    One of the V8 beast on interlagos, man thats some detailed FFB you get there :)

    Have send you a PM
  3. Awesome job, i was waiting for a "conlcusion" so i could understand what the H it all ment :)

    Btw, that Bodnar wheel looked insane how quick it was.
    Do you by any chance have a "speed-test" with that overlaid with other wheels like T500/CSW etc?
    • Like Like x 1
  4. Pax7

    LifeOn2 Development

    Heh Hampus, good that I manage to write at least some stuff that is understandable ;)

    Regarding the "speed test" of the Bodnar wheel. What I can say is that the type of servo motors e.g. Leo uses are so powerful and fast such speed tests are not that relevant anymore. They are just fast enough ;)

    For comparison, the last generation Fanatecs (the CSR Elite and the CSW) have a terminal speed of some 3-3.5 full revolutions per second (ca. 1200 degrees/sec). The servo Leo uses has a max speed of about 32 full revolutions per second... (some 11500 degrees/sec).
    Leo does not drive the servo at full power though, but it is still insanely fast. What you saw in the videos above was I would guess at 15% of the power available.
    But note, terminal speed does not say everything. Acceleration is e.g. more important, as it is coupled to torque (and inertia).

    PS. I measured the terminal speed of the Fanatec CSR Elite in my review of it almost a year ago, here: http://racedepartment.com/forum/threads/review-csr-elite-vs-frex-simwheel.44906/
  5. Richard Pittam

    Richard Pittam

    That is such a great article, thanks for taking the time out to do it for us Frederic.
    • Like Like x 1
  6. Pax7 wow :) i expected quicker but not 10 times as fast :)

    This wheel is extremely interesting, it´s the last level i guess of the wheel market and i would guess this is the type of wheel F1 teams, race teams etc use for their in-house simulators? (maybe not bodnar´s but using the same concept?)

    I look forward to further tests in the future whatever it might be, thanks :D
  7. Pax7

    LifeOn2 Development

    Yes, I think those types of organizations source simulator steering wheels that use the ~same type of servos, many times in direct drive configuration.

    During my research for my own FFB controller, servo drive and servo motor control, I have made the odd interesting observation on improvements to the above though ;)
    • Like Like x 2
  8. iRacing announced there will be a new steering model in place for the Mclaren, might be something to test out and see what you can find :)
  9. Pax7

    LifeOn2 Development

    Yep, I saw that. It sounds quite promising as it well may be a fix for the issues I highlighted in the analysis above.
  10. Pax7

    LifeOn2 Development

    Hey Folks,

    I had an off line discussion on the iR result where the generated steering torque was very high also going in a straight line. It was proposed to perform a test with FFB off to see what effect that had on the generated steering torque.

    The FFB off test is actually very interesting as we then can observe what effect the bump impacts only have on the generated steering wheel torque. Since there is no torque fed to the steering wheel, there is nothing to upset the wheel and cause steering in either direction. Hence, we can hold the wheel completely straight and avoid to generate self aligning torque from cornering.

    Here is a plot using the very same settings as in the original post, but with FFB set to off in iR:


    The average torque generated by going through the corner is around 7 Nm, and the peak torque generated by bumps going down the straight is around 9 Nm, with many samples of 5+ Nm. Note also the steering wheel angle being very close to 0 degrees going in a straight line. The peak straight torque is 129% of the average torque going through the corner, which is slightly less than in the FFB on case. If we compare the FFB on and off plots, there is somewhat higher general torque generated with FFB on, but the difference is not substantial. Of course two runs like this are not entirely the same, as I probably ran at slightly different speeds and different lines. However, the runs should be similar enough for us to reasonably be able to conclude that the torque generated by going in a straight line is almost entirely due to the impact forces generated when the front wheels collide with bumps in the race track.

    Hopefully the excessive forces generated by hitting bumps will be fixed in future patch(es) to iRacing. In fact, there was an iR staff post on the MP4-12C that gives hope this might already be fixed for that car:

    We'll keep out fingers crossed Tony! ;-)
    • Like Like x 2
  11. Niels_at_home

    Reiza Studios

    Good analysis, and you just can't accept this from iRacing if you ask me. Years and millions, and this is what you get? If Kaemmer is the genious people think he is, others around him surely are messing things up a bit!
    • Like Like x 1
  12. Kasper Stoltze

    Kasper Stoltze

    I Agree Niels! Surely iRacing must be one of the newer racing sims with the highest income, but they sure seems to miss a bit at some points, compared to other! Well, I guess the average simracer cant see beyond the testemonials from real drivers, saying how good it is and without competetion and whatever.

    At what Hz is the FFB Output in GSC? It sure seems a lot better, and Waaaaaaay more detailed than iRacing, and the others sims aswell out there. I like GSC and rF2 the most, in those sims you can feel the car with your'e finger tips.

    Fredric, have you tried the same procedure with GSC 2012? :)
  13. Pax7

    LifeOn2 Development

    Hello Niels,

    I agree this kind of rather significant physics engine issues are surprising to see. One thing that seems natural to look at when evaluating a complete vehicle dynamics model/simulation is the resultant torque at the steering column, but it seems not done (or it is done and this is known but not fixed... :) )

    As I wrote in the iRacing thread, I have a hard time believing that iRacing has gotten the basic physics modelling and simulation of the front suspension and related wrong; I would guess it is something else that is the problem. It might be the NTM, or some inaccuracy in the modelling/simulation. The exaggerated forces are so great it seems to little to talk about inaccuracies though.

    One possible problem source might be lack of modelling of flex in suspension parts, but it seems not likely a completely rigid model would give such a large difference compared to when flex is modeled?

    I assume tire deformation and heat buildup from track surface collision energy is modeled, but there might be some issues with the NTM. Maybe it all is a simple bug where the same energy is BOTH heating up, deforming, etc the tire AND going into the rim as force? :)

    Niels, do you know if rFactor2 (and even rFactor1) model suspension/chassis flex?

    Here is btw a bonus iRacing physics "feature" I reported on a good while back. It is not very pretty either unfortunately:

  14. Niels_at_home

    Reiza Studios

    Wasn't that 'magic 2 foot save hax' (in itself not a bug) still kind of a bug with locked tires too? This does sound a bit like some elementary physics engine problems. Not that I have a clue how to make a physics engine, you just expect one of the highest esteemed physics coders to get that stuff right.

    rFactor doesn't use flex, and I doubt rFactor 2 does. It physically seems the bumps on some iracing tracks are too large, that never felt good to me, even seen in a replay when you don't feel the overdone FFB, so their 'laser scanning' just doesn't seem to work well on the road details level, though I'm sure they nail the elevation and general banking which is so often wrong in other sims..

    Perhaps all their budget DOES go to marketing instead?
    • Like Like x 1
  15. Neils thanks for the detailed testing, I haven't got rF2 yet but after reading through this definitely going to try them . what boggles me is how the hell did the skip stays straight after that oscillation on the first video.
    I really enjoy the fast oscillation on that Leo wheel. could watch that all day replay after replay.;)
  16. Niels_at_home

    Reiza Studios

    Pax7 did all the hard work here! :)
  17. Here´s regarding the steering model on the Mclaren (which feels amazing to drive, although i can´t feel the new steering model)

  18. Pax7

    LifeOn2 Development

    I wrote the following post as a reply to that:

    "Hello Grant,

    very good news on this physics model improvement, and I am happy to see some news on improvements outside the NTM. I think this type of work is needed in iRacing.

    The obvious question your information gives rise to is what else is not modeled regarding suspension and steering? I am somewhat surprised to see that you still use that old, legacy modeling and code in iRacing."
    • Like Like x 1
  19. Pax7

    LifeOn2 Development

    Anyway, on to more digging:

    With the release of the MP4-12C a few days ago, including an updated steering model (the NSM I presume..? ;) ), of course we should have a look at how that car performs with respect to FFB output. On release night, instead of heading out on track for some fun races, I went round, round Lime Rock Park (and some other places) feeling out the FFB and doing some logging!

    Let us immediately look at the now familiar log trace of going through the last turn and out on the s/f straight at Lime Rock (click for bigger):


    Something very nice is immediately clear: the peak torque from bump impact forces are clearly lower than the average torque going through the turn! Average cornering torque is around 8 Nm and peak straight line torque is around 5 Nm (that gives a 63% bump/corner ratio).

    I also drove a fair amount of laps around circuit Zolder, and one thing was very clear from that: Lime Rock Park in iRacing is fantastically bumpy! Lime Rock compared to Zolder is so extremely bumpy is seems not right really. It could be due to Lime Rock being some of the very oldest tracks in iRacing, and maybe the surface map accuracy/resolution leaves some to be desired.

    Another interesting observation, which is valid for all iRacing log traces I have done at Lime Rock, is that there are violent torque transients away from average torque when going through the corner. The most peculiar thing about them is that they go very low and also into negative values a few times during cornering. Lack of tire grip causes torque loss, but at least for the Skip Barber is seems on the much side. Hitting the inside kerb could cause such a transient too, but I am pretty sure I did not hit the kerb that many times ;) Again, this could be due to the extreme bumpyness of Lime Rock, making many bumps basically as large as a kerb.

    Now, we have read that the MP4-12C has been blessed with the NSM and also the latest advancements in NTM tuning:

    But, are we sure the sim update that included the MP4-12C only contained [NSM, NTM] => FFB improvements for the MP4-12C? No, we are not. As iRacing (as usual) does write little to zero details about advancements in the core physics engine, we have to continue to play detectives!

    Have a look again at the original trace for the Skip Barber (from the original post):


    ...and here is the Skip Barber trace from post MP4-12C sim update:


    Oh my, also the Skip Barber (and probably all other cars) seems to have been blessed with stuff improving its FFB! In the post MP4-12C release trace, both the peak bump torque and average cornering torque are around 9 Nm, which gives 100% bump/corner ratio. This should be compared to 135% bump/corner ratio pre MP4-12C release. The result is the Skip Barber is now actually relatively pleasant to drive!

    I really don't understand why iRacing does not inform about these changes in the change log, as it affects also other (all?) cars positively. That is free bonus points from the community missed by iRacing.

    Lastly, we of course still have the issue of the 60 Hz FFB update rate and steering wheel position sample rate. It is (as discussed in the first post) generally problematic and such low FFB update rate does also not work well with the Bodnar FFB wheel.

    I actually spent a few hours the other day calculating a bit on what I believe is the problem with these low update rates and FFB wheels of Bodnar type. It included doing current vs. voltage step response calculations on an RL circuit. But that is another topic really ;)
    • Like Like x 2
  20. Nice work as always Pax!

    It seems like the NTM is bringing more flaws of the iR physics into the light, the more refined it gets. This from a laymans perspective, of course:cautious: