iRacing 360Hz FFB with Simucube 2

#1

With the latest update, iRacing added a mode for Logitech wheels that sends 360Hz FFB data at 60Hz intervals and lets the wheel do the reconstruction. It’s basically irFFB without the extra roundtrip (and latency) of going through a separate app.

This is a super exciting feature. Given that iRacing is unlikely to implement “true” 360Hz FFB any time soon, it’s probably as close as one can get to a great experience for those of us who consider iRacing’s standard FFB to be lacking detail, and would like to avoid the extra hassle and latency that comes with irFFB.

In other words, I really wish we’d get this mode for Simucube 2 Pro as well instead of being exclusive to Logitech! David Tucker from iRacing mentioned that various wheel vendors have been contacted about adding support:

https://forums.iracing.com/discussion/comment/313619/#Comment_313619

Could you speak to whether this is something that is planned for Simucube, and when we could expect support?

Thank you!
Martin

3 Likes
#2

"This is a back door that allows us to send that 360 Hz signal to the wheel 60 times a second, then the wheel firmware can play back those samples, with the appropriate delays, to recreate the 360 Hz signal. "

There is no such backdoor in DirectInput as-is, but could easily be implemented with a custom data packet format. In fact, our firmware has such format available, but iRFFB developer never did the interfacing to utilize it. FFB effect code regarding this is also missing, but will be able to be implemented.

I’m waiting to be contacted about this, sounds exciting although it has more lag than the Simucube Reconstruction filter has.

#3

Thanks for the quick reply, it’s excellent to hear that this looks achievable! Here’s hoping you’ll hear from iRacing soon :slight_smile:

Out of curiosity, is the firmware interface you mentioned publicly documented?

FFB effect code regarding this is also missing, but will be able to be implemented.
My understanding is iRacing doesn’t make use of DInput effects, so I would think this isn’t needed for this particular case, right?

#4

I think I may have removed that recently from the firmware, but easy to add back. Depends on how the iRacing implementation is.

A struct that defines it used to be in the (since pulled) open source repository for Simucube 1 Opensource firmware. Some copies might be in Github forks still.

1 Like
#5

It looks and sounds like its a feature of the Logitech TrueForce API; it extends some standard DirectInput calls with some proprietary ways.

Simucube uses the standard Microsoft supplied device driver and such extensions are not possible at the moment.

Sending raw packets to device could be an option, but much harder to implement by the game developers.

#6

The good old byte stream implementation :smiley:

#7

That’s a shame to hear it’s not as straightforward as expected.

Could Simucube offer an API that’s similar (in spirit) to TrueForce? Is that just more work, or fundamentally not possible for some technical reason? Seems like if Logitech can do it, others should be able to as well? :wink:

#8

In my opinion, these vendor-specific API should never be implemented.
The better option would be an open protocol that everyone can and may use.

The best example is the VR headsets. Everyone had their own proprietary protocol and now they have agreed on a standard with OPENXR.
This gives consumers much more choice and developers only have to implement one API.

2 Likes
#9

So iRacing physics internally operates at 360hz but can only send data out at 60hz interval?
Why waste time implementing these kludges instead of doing it right way, esp. with all those money they have from iRenters. :man_shrugging:

2 Likes
#10

They said somewhere (and I’m probably butchering it) that they use the same 60hz refresh rate as real world digital clocks do, and that’s why they are stuck at refreshing at 60 times a second to the wheel base, as oppose to the 360 times refresh they do internally.

I GUESS it has something to do with how the FFB refresh interacts with the netcode refresh for multiplayer, and giving out data at the same refresh rate and intervals?

#11

There are always a million reasons not to do something.

2 Likes
#12

60Hz is just the fixed tick rate of their entire game logic. Then there’s an inner loop that computes 6 physics samples per tick (in one go, i.e. that inner loop doesn’t run at 360Hz wall clock but just simulates 1/360th of a second intervals).

Given their decades old codebase, I have no trouble believing that moving to a higher main tick rate or restructuring things so that FFB samples pop out at higher wall clock rate is a major undertaking. And unfortunately, the motivation to truly tackle that problem on the iRacing side seems limited. From what I can tell that’s partially because it’s so much work and partially because 60Hz is considered good enough (or at least close enough) by the devs. Many users disagree with the latter and wish for more detail in iRacing’s FFB.

That’s why the prospect of getting at least the “pseudo-360Hz” mode (which is basically irFFB behaviro without some of the downsides) is such a juicy carrot dangling in front of us. It’s likely the only chance we’ll see in a very long time to make a fundamental improvement to iRacing’s FFB.

If a TrueDrive-like API for Simucube solves that problem, I’m sure it would find great appreciation among the user base. Not to mention it’s an opportunity for Simucube to add a unique selling point to their product.

#13

Will Simucube implementing support for proprietary protocol help with their “motivation”?
Customers are voting with their feet/wallets, as long as you pay they don’t care how much you whine.

1 Like
#14

The devs are actually frequently helpful and take customer feedback into account. Reasonable feedback on things you’d like to see improved is not the same thing as whining, and it’s usually appreciated by the devs to hear what the community likes/dislikes. Obviously they can’t implement everything anyone asks for.

#15

Sounds like Logitech may be thinking outside the box here and that’s what’s needed. Remember the article(s) written about the FFB-API limitations? Having that API locked up certainly limits progress compared to recent hardware advancements. Perhaps Logitech found a work-around?

2 Likes
#16

I’ve done some POC code development on the firmware side. The thing is that we are limited to the communication methods currently possible in the firmware, but maybe something is possible. Then again, we will not develop anything complex on this firmware platform, as the work to get the wheel base to the completely new platform will bring lots more benefits in long term.

But lets see what we can do…

FFB calculation and dispatching the telemetry streams is what they do at 60 Hz, and they dispatch the FFB command using the very latest 360 Hz calculation result at the beginning of the iteration. The telemetry (what iRFFB is using) contains the 360 Hz values. I guess they are not able to place the FFB dispaching in the higher rate loop as it would mess up the internal physics engine timings too much.

This would be a dream indeed.

#17

Thanks for the update, and thank you so much for investing the time to work on this! Exciting to hear that there might be a possible path to make it work.

Out of curiosity, would you implement the same interface as Logitech or something different that would presumably require changes to iRacing as well?

I hadn’t heard about the new firmware platform. Is there any public information available on it?

#18

Logitech’s interface is not publicly documented. I think their TrueForce API is available only to game developers under a NDA with them. Same goes for the API Fanatec has.

We can only guess what the API does, and I think there is a way to get a good solution for iRacing and Simucube 2 here.

its the completely new servo drive, communications API with PC, the PC software, etc that we have made for the ActivePedal product. It really does not share a single line of code with Simucube 2 or True Drive.

3 Likes