More detailed FFB (360Hz) in iRacing from 24S2
Norbert Rebelski
Member
According to video from SimuCube devs, iRacing has released alpha build with 360Hz FFB.
According to them it will result in more detailed FFB, which is very welcome :)
Simucube team is already working on creating API to take advantage of that in iRacing.
Do anyone of you know if Fanatec is working on 360Hz api for their wheel bases (I am using CSL DD)?
The interesting bit starts from 29:53s
https://www.twitch.tv/videos/2063468467
Here is also an interesting comment of one of Simucube developers working on 360Hz api for iRacing.
"iRacing still calculates FFB and does some other things at 60 Hz. At this rate it communicates the latest FFB value via DirectInput, but it also calculates 360 Hz samples retrospectively and makes that available in the telemetry memory map.
Its up to hardware developers like us to offer an API that allows to send a batch of samples in the 60 Hz call that would otherwise be a standard call to DirectInput. This is now being implemented in Simucube 2 wheel base and it looks promising that we'll be able to get it included in the 24S2 update.
Compared to iRFFB's 360 Hz mode, we are really at 16.67 ms delay. IRFFB reads the data from the memory map where the data is available later than via direct FFB call from iRacing, and also iRFFB needs to spin a threads of its own to communicate individual samples at 360 Hz rate. This results in total of around 29 ms delay in the iRFFB.
I will do some FFB stability testing, but regarding that the 360 Hz mode is not a magic bullet. There is some additional FFB detail."
Comments
They take months or in some cases even years to just fix the bugs in the drivers, so i wouldn't count on it anytime soon.
https://forum.fanatec.com/discussion/comment/119299#Comment_119299
The 360 Hz FFB is not new, Logitech also implemented it.
It is planned to support it at some point but not soon as it requires a LOT of work and ressources are extremely limited atm.
However, ideally iRacing would implement this natively into their Code so it is not up to wheel manufacturers to write a special API Code for it.....
@Maurice Boschen - it seems you don't know what you are talking about.
Since with Directinput you can achieve maximut 20-30Hz updates, then each game developer and each wheel vendor need to write an API to communicate between each other (if they want to have higher frequency than 30Hz).
Here is the quote of David Tucker (iRacing developer working on FFB)
"So this allows us to send multiple samples to the wheel in one call, for playback at a higher frequency. This removes the timing constraint of us trying to push the samples across very quickly without adding in jitter. It really should be a built in call in DirectInput. The benefit here is that we can let much higher frequency signals pass on through to the wheel. With straight DirectInput calls were limited to around 20-30 Hz max, and with this call we can generate frequencies up to around 120-180 Hz. The vast majority of signals are below 20 Hz, but this still helps in dynamic situations, like when hitting a curb.
This does not improve stability, that can only happen with a rewrite of our physics engine, and that is not something we can pull off in one season. It basically does what irFFB does, but in side the wheels firmware, so with much more precise timing. In theory that means the wheel can do better filtering as well, since the incoming signal has more high frequency data to work with.
Right now it is only available on the Logitech PRO wheel, and Simucube is now close to complete. It is working great on a dev build, but there is a bit of polish that needs to happen before it can go out to members. I'm not sure if we will release this next season, or in a later patch/season, but we are very close. I have to say Simucube did an excellent job on this, the signal passes through very cleanly with no transients or noise. It works very well."
I'll withold judgement until iRacing stops beating around the bush and finally admits their core engines are long overdue for a total overhaul if not rewrite. High Hz physics/FFB signalling has been a user request for at least a decade, this is a nice gesture but still something of a stopgap measure. irFFB method, even API-firmware direct, is going to have drawbacks/latency penalties regardless due to the inherent latency/mismatch between core physics and telemetry.
Til then, Fanatec's Interp setting that's come along from the DD units is at least as good or better. In a basic sense of operation there is practically no difference in this iracing method and a native firmware interpolation.
rFactor2 is on 400Hz for years and www.thelastgarage.com is developing on 1000Hz.
Computer-mouses has much higher frequencies then iRacing FFB signal and are working over directinput.
Seems legit this is a iRacing issue.