I measured FFB update rate using various methods

[ker2x]

I did some measurements (as i'm coding a "lean & clean" kind of "LMU FFB App"):

1. using WaitForSingleObject() on LMU_SHARED_MEMORY_EVENT -> 50hz update rate
2. using a ~25khz "busy loop" with the LMU SDK (if ffb data not changed -> thread::yield) -> 100hz
3. using the same busy loop but on the RF2 Shared memory plugin -> 100hz (NOT 400! The 400 only works with the actual rF2 i guess)
4. using USB data rate it's a bit more complex and i didn't want to do any serious reverse engineering and i'm not sure which channel is which it's either
   1. a fixed data rate of ~400hz
   2. a variable data rate the seamed to correlate with how hard i shake the car that peak at ~360hz (that a measurement from PC to Wheelbase.
      1. From device to pc : My wheelbase is apparently sending data at a rate up to 1Khz but there might be multiple type of packet sent, so it could be half that. don't care so i didn't dig.

And that's it really. There is no legit/known way that i know of that would allow to get more than 100hz. Even RF2 plugin which is supposedly getting 400hz only see 100hz of useful data. (you can still read at any rate you want, but you'll just get duplicated data and only 100hz of useful data).
It's also unclear if it actually 400hz (or 360?) hz of "usefull data" or if doing something as useless as sending duplicate, but that's very(!) unlikely.

My bet is that it really update FFB at 400hz (or 360hz).
We can only get 100Hz from a plugin. And the likely cause is that plugins are only allowed to run at 100hz. I could try to code a plugin to actually measure that but... meh.

So if you REALLY want to get your 400hz, the only way i can think of is to actually develop a "virtual" FFB device driver that can passthrough the data to the actual device +/- whatever you want to do with that 400hz FFB data. That's A LOT of pain. (eg: vJoy)

 

[leppie]

You got your source code up somewhere?

 

[ker2x]

You got your source code up somewhere?

It's still a POC and it doesn't include the benchmark data: https://github.com/ker2x/KALMUA/
I'll push the latest version (cleaned up a bit) later today

 

[ker2x]

pushed to github
As far the USB data rate measurement: I used Wireshark with USBcap + the graph tools

 

[Lazza]

rF2 plugins 'get' data by having UpdateScoring(), UpdateTelemetry() and ForceFeedback() called. You don't choose how often to get that data.

ForceFeedback comes in at 400Hz.

My bet is that it really update FFB at 400hz (or 360hz).

400Hz, yes. The internal update rate (calculation rate) is 2400Hz, so every 6th cycle gets output for FFB.

rF1 ran at up to 90Hz telemetry output (dependent on frame rate) with FFB (and physics, I think) at 360Hz, rF2 ran at constant 100Hz telemetry output with 400Hz FFB, LMU is the same as rF2 so far.

 

[ker2x]

rF2 plugins 'get' data by having UpdateScoring(), UpdateTelemetry() and ForceFeedback() called. You don't choose how often to get that data.

ForceFeedback comes in at 400Hz.



400Hz, yes. The internal update rate (calculation rate) is 2400Hz, so every 6th cycle gets output for FFB.

rF1 ran at up to 90Hz telemetry output (dependent on frame rate) with FFB (and physics, I think) at 360Hz, rF2 ran at constant 100Hz telemetry output with 400Hz FFB, LMU is the same as rF2 so far.

Too bad we can't get the 400hz from the telemetry
That make my nice app that complements a missing feature (change FFB scale per car) almost useless :/

 

[Sander]

100Hz is 10 milliseconds, plenty fast to catch a slide

 

[Lazza]

That make my nice app that complements a missing feature (change FFB scale per car) almost useless :/

If that's your main aim, there's probably a better way to do it. Assuming you can access the REST interface and adjust the game FFB strength based on the car currently selected.

 

[ker2x]

If that's your main aim, there's probably a better way to do it. Assuming you can access the REST interface and adjust the game FFB strength based on the car currently selected.

do you have any tips or exemple or api doc ?

 

[Lazza]

do you have any tips or exemple or api doc ?

Sorry, not something I've done myself.

 

[leppie]

@Lazza slightly OT but do you know the intended behavior for

virtual bool ForceFeedback( double &forceValue ) { return( false ); } // alternate force feedback computation - return true if editing the value

When changed, does this only alter the value sent to ffb device? (bar some filters etc)

If so, this could be a solution, but probably not your desired one. (code is code, plugin or app, meh)

 

[Lazza]

@Lazza slightly OT but do you know the intended behavior for

virtual bool ForceFeedback( double &forceValue ) { return( false ); } // alternate force feedback computation - return true if editing the value

When changed, does this only alter the value sent to ffb device? (bar some filters etc)

If so, this could be a solution, but probably not your desired one. (code is code, plugin or app, meh)

The comment is leftover from rF1 (yes, circa 2008 or so) where you could send a new value to the game. rF2 never used it, neither does LMU.

 

[ker2x]

100Hz is 10 milliseconds, plenty fast to catch a slide

Latency wise, yes. But you lose all the high frequency event.
I tried everything i could. Now i'm not even using my own plugin anymore because i lose so much info due to the 100hz limitation.

 

[Botmeister37]

If 100hz was enough than iRacing would have not have been upgraded to 360hz last year, the RF2/LMU engine would not use 400hz and the new engine Last Garage wouldn't be in development reaching a 1000hz rate. Or in other words, if Daihatsu was enough to drive from A to B we wouldn't need Mercedes but here we are

 

[ker2x]

If 100hz was enough than iRacing would have not have been upgraded to 360hz last year, the RF2/LMU engine would not use 400hz and the new engine Last Garage wouldn't be in development reaching a 1000hz rate. Or in other words, if Daihatsu was enough to drive from A to B we wouldn't need Mercedes but here we are

It's not even a matter of "is it enough" or not. When i started to write my plugin, I wanted to add some minor improvement to the ffb, not to make it worse. We lived on 60Hz iracing FFB for more than a decade

 

[ker2x]

If 100hz was enough than iRacing would have not have been upgraded to 360hz last year, the RF2/LMU engine would not use 400hz and the new engine Last Garage wouldn't be in development reaching a 1000hz rate. Or in other words, if Daihatsu was enough to drive from A to B we wouldn't need Mercedes but here we are

btw, Daihatsu made some pretty serious race car

 

[TonyRZ]

I think people is mixing FFB and physics.
The 1000 Hz is for physics.
Then THAT physic is transposed into FFB behavior, which can't be at same rate.
The higher the physics rate, the better the FFB adapts to it.

Modifying the FFB by checking actual FFB value is not the best way to "refine" FFB.
Check physics with telemetry, with the best latency, and adjust actual FFB accordingly.
I'm pretty sure that's what is doing LMU FFB App.

By going too far on that, you would gain time by developping your own game instead of trying to modify an existing game

That's surely why Offermans developped The last garage. He propose a new physics engine to anyone wanting to do a proper simracing game with highly "refinable" FFB helped by high frequency physics.

 

[ker2x]

I think people is mixing FFB and physics.
The 1000 Hz is for physics.
Then THAT physic is transposed into FFB behavior, which can't be at same rate.
The higher the physics rate, the better the FFB adapts to it.

Modifying the FFB by checking actual FFB value is not the best way to "refine" FFB.
Check physics with telemetry, with the best latency, and adjust actual FFB accordingly.
I'm pretty sure that's what is doing LMU FFB App.

By going too far on that, you would gain time by developping your own game instead of trying to modify an existing game

That's surely why Offermans developped The last garage. He propose a new physics engine to anyone wanting to do a proper simracing game with highly "refinable" FFB helped by high frequency physics.

I didn't know about The Last Garage and Project Chrono. Thanks for the tips. I worked on making my own simulator (and gave up as i quickly found out that it would take years by myself).

This is gold to me: https://github.com/projectchrono/chrono/tree/main/src/chrono_vehicle/wheeled_vehicle/tire

 

[Lazza]

I think people is mixing FFB and physics.
The 1000 Hz is for physics.
Then THAT physic is transposed into FFB behavior, which can't be at same rate.
The higher the physics rate, the better the FFB adapts to it.

Modifying the FFB by checking actual FFB value is not the best way to "refine" FFB.
Check physics with telemetry, with the best latency, and adjust actual FFB accordingly.
I'm pretty sure that's what is doing LMU FFB App.

By going too far on that, you would gain time by developping your own game instead of trying to modify an existing game

That's surely why Offermans developped The last garage. He propose a new physics engine to anyone wanting to do a proper simracing game with highly "refinable" FFB helped by high frequency physics.

The FFB is at the same rate, but obviously this being the LMU forum we're getting quite sidetracked here...

@ker2x remember you can get every single FFB output from LMU via plugin (ie 400Hz).

 

[ifusiionzz]

The FFB is at the same rate, but obviously this being the LMU forum we're getting quite sidetracked here...

@ker2x remember you can get every single FFB output from LMU via plugin (ie 400Hz).

I do not know what to say about this as most of the studios don't talk about their engines, but you usually have several fixed time steps depending on the physics you compute. I would probably say that the only thing that runs at 400Hz are the forces applies, as it is what is outputted to the DD, everything else could run a lower or higher rate depending on the time that it needs to compute.

Do you know if there is any document out there that talks about how their physics engine work for the different subsystems? Tires, suspension, rigid bodies, aero, etc.