SimuCUBE Open Source Firmware Development Update Thread 2

You mean the maximum usb polling rate in the usb interface descriptor?

Yes the usb polling rate.

Why should that help anything… Can it be adjusted in any other wheel base?

There are many things that simucube does and other wheels do not. I guess i should not have asked. Thank you for your fast answer.

1 Like

I’m sorry if I sounded ignorant, I certainly didn’t mean to. I would like to understand why the maximum rate should not be the maximum allowed in the USB specification, keeping in mind that it is the maximum rate. Is there a use case for this setting, or an example where (and how) it would help?
If there is, then certainly we would include it.

Wait… I don’t get one thing. USB standard offer 1000Hz max, so what is the best frequency to set in SimuCube to get the best FFB and why? A 1000Hz or more? Maybe unlimited? Or less then 1000Hz? AC offer 333Hz FFB max, iRacing only 60Hz but AM2 720Hz… etc. So maybe we we should set 333Hz in SimuCube if we play AC??

This is a completely different thing than the low-pass FFB filter that is in the device, and also a completely different thing than the FFB update rate from the simulator.

Answer is “all wrong” to all your suggestions.

The USB polling rate is a rate that that device can be requested new updates from via USB. Its kind of a promise on how fast the device promises to process USB commands. 1000 Hz is maximum, but as there is usually lots of other stuff happening on the USB bus, the rate is usually less than 1000 Hz anyway. You can monitor this if you use a USB packet sniffer or similar debugging device.

Then there is the FFB update rate from in-game. It is the rate the actual FFB updates are send from game to the device via USB. They must fit in to the 1000 Hz transfer slots on the USB bus.

Then there is the FFB signal itself. Even if you have a 1 Hz signal, it can have unlimited bandwith. That will be the case in the FFB case, where the signal is a step signal - in digital signal processing, that requires an unlimited number of frequencies to represent an ideal result, thus its bandwidth is unlimited in analog world. If one uses a low-pass filter (like our torque bandwidth filter) you will get smoother transitions between the steps in the FFB signal.

image

4 Likes

Please no last minute feature implemantation that delays the release even further. :innocent:

It already did, I could have done something useful instead of the writing the previous post…

2 Likes

Sorry for taking your time Mika, wow… I thought your answer will be very very short, e.g unlimited working the best because this and this. One short sentence is enough. In my PC one USB controller working with only 505Hz speed, other 720Hz, extension PCI-E - USB 3.1 card 950Hz… hmm.

Unlimited will give you a raw signal. The frequency content of the signal and the update rate of the signal are completely different things, and you shouldn’t be at all interested in the underlying update rate, just use filters to get desired feel.

1 Like

@Mika sorry that my question caused you so much trouble.

Any updates on the new firmware for simucube 1?

Last work on that was yesterday :smirk:

7 Likes

There were reports that bumpstops were acting in a buggy way in 0.50.4 and caused e.g. ripped USB cables.

I’ve now taken a look at the code from Simucube 2, and will also include the improvement&fixes to Simucube 1.

We are now very close to a release, and I will have time for the next 14 days to support the release of the firmware. :sunglasses:

20 Likes

This, btw, means that Simucube 1 will likely get improved bumpstop effect ease-of-use with less parameters before Simucube 2. :slight_smile:

15 Likes

That’s great news!!!

Excellent news there