Slew Rate Formula / FFB Signal

[Purple_Red]

this refers to the post from Alfye20.

Simucube 2 True Drive Paddock - Feedback and suggestions

That is my formula to calculate Slew Rate Limit: Overall Strength / Game signal refresh rate (1000ms / game Hz) = Slew Rate Limit Examples: Iracing: 17Nm / 16.666 (1000/60) = 1.02 @SRL 25Nm / 16.666 (1000/60) = 1.50 @SRL 32Nm / 16.666 (1000/60) = 1.92 @SRL Assetto Corsa 17Nm / 3.003 (1000/333) = 5.66 @SRL (Not possible to reach 17Nm every 3ms with only 4.8 @SRL on the Sport so it is mandatory to lower overall Strength if we want to reach full acceleration) 25Nm / 3.003 (1000/333) = 8.32…

Aloha, let’s get started. I will definitely not be able to answer all of the questions, but I can still clear up a few things. But I am sure that some of you will have more questions at the end than before. That is normal. It was no different for me! I’m only informed by chance. Started with the bass as a teenager … Equlizer … Compresoren ;-). then afterwards home recording with Cubase, that’s how I understand it. The whole topic with DSP, DAW, VST and FFB can be just painful. Anyway …

“Overall Strength / Game signal refresh rate (1000ms / game Hz) = Slew Rate Limit” First of all, these are not 1000ms but just 1000, which have nothing to do with the game signal refresh rate. The standard formula is (1 / f) and you get the wavelength in seconds. However, if you divide 1000 by the frequency, you will get the result in milliseconds … is simply more practical!
The next thing then is that you can’t apply the slew rate to the wavelength, at least not with our little formula. Instead, you only have to apply the whole thing to one flank. So you have to divide the wavelength again by 4, so: ((1000 / f) / 4)) Then we come to the frequency. The frequency of the signal is not the sample rate and vice versa. They have the same unit namely Hertz (Hz) and have a lot to do with each other. But don’t mix up the siblings! Fortunately, the conversion is relatively easy: SampleRate / 2 = f With Iracing, I think that the Hertz data refer to the sample rate and not to the frequency of the FFB signal, i.e.: 60Hz / 2 = 30Hz

IRacing FFB Signal - Check at which frequency the Signal ends!

Iracing example:
17Nm/((1000/30Hz)/4)=2,04Nm/ms
25Nm/((1000/30Hz)/4)=3,00Nm/ms
32Nm/((1000/30Hz)/4)=3,84Nm/ms
AC example:
17Nm/((1000/333Hz)/4)=22,65Nm/ms
25Nm/((1000/333Hz)/4)=33,30Nm/ms
32Nm/((1000/333Hz)/4)=42,65Nm/ms

Then we come to the last 2 points. For the 30 / 180Hz IRacing signal, the 200Hz Rfactor signal and the 333Hz AC signal, no 17/25 / 32Nm amplitudes are generated at the end of the frequency band !! That means the required slav rate drops dramatically! You can expect the most pressure between 0-10Hz, as you can see from the screenshots… Curbs on Spa in Iracing GT3 are around 31/32 / 33Hz, with rfactor2 curbs are around 40-45Hz. However, then with amplitudes that are satisfied with just under 4Nm / ms. Regarding AC, I have to say that I have no insight into the signal, so I don’t know whether the 333Hz is the sample rate or the frequency of the signal, I’ll guess the sample rate! And just on the road, nobody seriously wants 333hz in their signal, that’s garbage!!!
Nevertheless, from my experience with Rfactor2, I can say that there is not much output above 150Hz!

RF2 Signal - 150hz and above there is not much left in the signal

The last point is that our formula applies to a triangle signal. If you work with Motec it will be important at some point! I think the formulas should be right.

PS:yes it is not a sawtooth signal, but a triangle signal.
@ Alfye20 And I’ll come back to the specific iRacicing problem in a moment.

[Mika]

If one looks at the signal samples only, it is well possible that some hard kerb hits have following samples (where 10000 is the maximum):
0
0
500
2000
5000
10000

which immediately goes against your formulas.

iRacing FFB is still 60 Hz. We can disregard the Nyquist theorem as the intention is not at all to try to accurately reproduce things at the wheel anyway.

[Purple_Red]

Yes, exactly!
I don’t like that with the formulas either. Also doesn’t often fit what Motec calculates. But for a rough direction, with two eyes closed …

Wait a minute … let’s assume you measure the IRacing signal with an oscilloscope and not with Motec. Do you also find, for example, 50Hz components?
That would be interesting for the equalizer setting.

[Mika]

You can find all frequency components up to infinite frequency, as FFB signal is a short of step wave signal. Its just that if there are any higher than 30 Hz actual torque signals present, you will find them aliased into the 0…30 hz area in spectrum analyzer.

[Alfye20]

Let me correct my formula. As shown on TrueDrive: Slew Rate limit ( Nm / ms) so
SRL = Overall Strength (Nm) /Game signal Refresh rate (ms)

Just in search of servo acceleration, 0 to 100% force in X ms, nothing about signal amplitudes

[Purple_Red]

So the engine also calculates higher frequencies for the FFB signal, but then these frequencies are summarized in a 30Hz signal and can therefore no longer be made separately visible on the FFT. In other words, the 50Hz frequency “blurs” with another frequency between 0 and 30Hz and thus still has an influence on the 30Hz signal. Is that correct?

[Mika]

That is correct, aliasing works in that way.

[Purple_Red]

No, the formula is not really useful. Both yours and mine.

I reduced the signal from me to your 4.1Nm and had the slew rate calculated for it. However, a GT3 vehicle is required. At least this will give you a more precise clue.

I would set the slew rate to 0.16Nm / ms. But doesn’t really make a difference either!

[Purple_Red]

@Mika

That is correct, aliasing works in that way.

Impressive! Really cool.
Smarter every day!
That’s something I didn’t have to deal with when recording.

I have two other questions. I had the slew rate calculated in Motec. Then, as in the True Drive software, I “programmed” the slew rate as a controllable “effect” in Motec in order to make the influence visible.

1Row: FFT without SlewRate - 2Row: FFT with SlewRate

1Row: SlewRate - 2Row: FFB-SIGNAL // Red: Signal without S.R. -
Blue: signal with S.R.

The FFB SIGNAL is distorted in Motec when it is converted back into an FFB torque signal (2 row blue). That is why the signal took on this waveform. This is only in Motec and a general problem with this function, in-game there is no effect!

Since then I have been using the slew rate as a threshold, something I know from my bass amps. Quasi a compressor, a strange compressor but a compressor. For this, I specifically give the FFB signal less slew rate than the signal actually needs. Which takes away the dynamics of the signal. On the other hand, by increasing the torque at the same time, a lot of details in the lower torque range can only be felt. So it becomes more detailed, clearer and much more understandable in the border area. In rFactor this is a game changer!

Because the workflow is just as simple as in music, compress the signal and then pump it up, I ask myself: Have you found any atypical audio disadvantages at GD in this regard? Namely, I don’t feel any, on the contrary and I can prove that with other practical examples / driving situations with Motec.

Why don’t you advertise with it, the competition from Fanatec, TH, VRS, Simagic & co is a joke against your functionality?

[martino_cesaratto]

Very interesting discussion, I’d actually make a small correction to your formula:
You should double the max-force figures, as the maximum slew rate will be required when the game goes from -100% FFB to +100%, so it’d be a 34Nm difference in an SC2 Sport, 50 for the pro, and 64 for the ultimate.

Also, as for Nyquist, you’d only be able to reconstruct correctly the frequencies below half the sampling frequency (FFB hz from the game), and i think that’s also made a bit worse from the fact that USB will resample it at 1000hz introducing some extra error for iRacing signal (AC and rF2 are sampled at integer divisors of 1000 so no problem there).

I think that the reconstruction filter also tries to extract some details about the dynamics above half sampling frequency (if not, Mika please PM me, i might have some interesting ideas about how to do that), it should then apply some sort of lo-pass filter to only keep the correctly reconstructed signal, but it *may" not do so to keep it more dynamic (not sure how it actually works).

So in the end I’d put the max slew rate at about (2 x max torque) / (0.5 x FFB frequency) if I had to use it, but assuming the presence of a low-pass filter in the motor driver i wouldn’t actually use it anyway unless i want a smoother signal.

EDIT: am i correct assuming no lo-pass filter is actually applied, but the torque bandwidth limit acts as one? If so, would be interesting to experiment with it set at 470/680 hz to at least cut at half the USB frequency (not sure why 500hz option is missing tho).