read more: FFB Tweaks

I've worked with x4fab to add a new feature to the Custom Shaders Patch (as of 0.1.51) and the description is fairly brief so I thought it's worth going into a bit more detail about what this does.

7hNkrdT.png


Gyro Implementation

[ ] Active check to enable
Strength 25% adjust effect strength
AC has an "Experimental Gyro" FFB effect whose purpose was adding gyroscopic effects to the steering. It never lost the experimental tag and all it's generally recommended for is damping down oscillations on direct drive wheels.
This is that, developed slightly further based on my understanding of the nature of gyroscopic forces. I have a pretty solid case for making this change, and I believe this force exists in actual cars, and AC's original experimental gyro does not.

The developed version still suits the purpose of damping oscillations, but more importantly it decouples the body from the front wheels - so if the front wheels are pointing in a direction and the body moves around them, no gyroscopic precession happens, and no force is generated. Concretely, what we're talking about here is oversteer - on the original experimental gyro, the force acts counter to self-alignment during oversteer. With this new implementation, self-alignment is allowed to occur freely, or, if the oversteer is so quick that the wheels can't self-align, it'll actually push in the direction of alignment.

25% is simply equivalent to the original force multiplier used on experimental gyro when merging it with other FFB forces. Ultimately, the same as the other amplification ffb effects like road and slip effect, the slider is available to magnify it if your hardware's limitations are obscuring the effect.
As of CSP 0.1.53 the strength slider is outdated. A calculation using the suspension geometry now provides the right precession-based force for each car.
The description is a little bit misleading; this replaces "Experimental Gyro" so disabling it is superfluous, if this is Active, experimental gyro is not. Still, it won't hurt to disable experimental gyro and be certain it's off.

Now that I've said what the intent is, I will also note the following: this changes FFB in pretty much every dynamic situation. It's not just an improvement for drift cars or for vintage cars that oversteer constantly; any time the car moves around on the tires it feels slightly different from before. To me, it's a positive change, it's clearer what the car is doing, and I have heard similarly positive comments from testers. Nonetheless, I am not omniscient, I have not driven all these cars in real life, it's up to you to decide whether it improves your game or gives you better sim feeling the rubber or what. Modifying games to improve the FFB is a fine tradition starting with some extremely thorough efforts in rfactor1, and this is no different (maybe a bit easier to install).

I will note that it slightly increases max forces when cornering so if you have stuff set up to barely clip, you'll need an adjustment downward in global ffb mult.

Range Compression

Range compression 100% - 100% is the "default off" of this effect
[ ] Range compression assist - check to convert cars' "steer assist" into range compression.

New FFB Tweak available as of 0.1.53. The name comes from the audio world, where dynamic range compression means bringing up the quiet sounds while leaving loud sounds at their original volume. This is a much more second derivative friendly version of the Gamma effect.

The percentage is straightforward: Set it to how much you want to multiply small forces. Or adjust it in sync with your overall gain if you want to maintain the level of small forces and change large forces. For example, 200% compression + 50% gain = original 100% on small forces, larger forces decrease. If you're curious, the curve at the point of maximum force is simply the inverse, 200% compression will cause large forces 50% of the original delta in force. But in combination with 50% gain, you're moving the original maximum force downward and the ceiling before the game clips is much higher.

Think of this like power steering: you only want it to assist the heavy forces and give you maximum feel of the light forces.

This is very much an "adjust to taste" thing, it operates smoothly enough that you're safe running it upward of 300%, and I have seen IRL data indicating that manufacturers effectively go as high as 600% in power steering systems, when they want to bring 20+N forces down to a comfortable 2-3N.

Steer assist is a built in per-car feature of AC that applies a gamma function to that car's FFB. If you check Range compression assist, then FFB Tweaks will calculate an appropriate range compression adjustment, and disable steer assist. This should give you a far more normal FFB feeling (no weird bumps around center) while retaining the original goal of giving high downforce cars enough low-speed FFB to be drivable.
 
Last edited:
Since there are quite a lot of ffb gurus here, since the CSP 1.80 preview 218 I'm getting constant crashes to desktop as soon as I open the pause menu.
The error I get is not always the same but often it's this one and I think it has something to do with my ffb?

If anyone has any idea how to fix this or has the same issue since the latest CSP update, please let me know. It's driving me crazy :D

00007FFCFC87DD0A (DWrite): (filename not available): DWriteCreateFactory
AC\directinput.cpp (107): DirectInput::forceFF
AC\game.cpp (275): Game::render
AC\dicarcontrol.cpp (535): DICarControl::sendFF
AC\physicsdrivethread.cpp (246): PhysicsDriveThread::run
00007FFD974AD24C (MSVCP120): (filename not available): std::_Pad::_Release
00007FFD7C514F7F (MSVCR120): (filename not available): beginthreadex
AC\game.cpp (126): Game::onIdle
00007FFD7C515126 (MSVCR120): (filename not available): endthreadex
00007FFDA8467614 (KERNEL32): (filename not available): BaseThreadInitThunk
00007FFDA9EA26F1 (ntdll): (filename not available): RtlUserThreadStart
AC\game.cpp (210): Game::run
AC\acs.cpp (477): wWinMain
f:\dd\vctools\crt\crtw32\dllstuff\crtexe.c (618): __tmainCRTStartup
00007FFDA8467614 (KERNEL32): (filename not available): BaseThreadInitThunk
00007FFDA9EA26F1 (ntdll): (filename not available): RtlUserThreadStart
 
Since there are quite a lot of ffb gurus here, since the CSP 1.80 preview 218 I'm getting constant crashes to desktop as soon as I open the pause menu.
The error I get is not always the same but often it's this one and I think it has something to do with my ffb?

If anyone has any idea how to fix this or has the same issue since the latest CSP update, please let me know. It's driving me crazy :D

00007FFCFC87DD0A (DWrite): (filename not available): DWriteCreateFactory
AC\directinput.cpp (107): DirectInput::forceFF
AC\game.cpp (275): Game::render
AC\dicarcontrol.cpp (535): DICarControl::sendFF
AC\physicsdrivethread.cpp (246): PhysicsDriveThread::run
00007FFD974AD24C (MSVCP120): (filename not available): std::_Pad::_Release
00007FFD7C514F7F (MSVCR120): (filename not available): beginthreadex
AC\game.cpp (126): Game::onIdle
00007FFD7C515126 (MSVCR120): (filename not available): endthreadex
00007FFDA8467614 (KERNEL32): (filename not available): BaseThreadInitThunk
00007FFDA9EA26F1 (ntdll): (filename not available): RtlUserThreadStart
AC\game.cpp (210): Game::run
AC\acs.cpp (477): wWinMain
f:\dd\vctools\crt\crtw32\dllstuff\crtexe.c (618): __tmainCRTStartup
00007FFDA8467614 (KERNEL32): (filename not available): BaseThreadInitThunk
00007FFDA9EA26F1 (ntdll): (filename not available): RtlUserThreadStart
I don't think it has anything to do with the ffb. I'm not an expert but that log reads more like the whole package, which contains the inputs, physics, ffb and the general game, crashed.
These error logs aren't that useful tbh.
The best way to debug thinks, in my experience, is to:
1. Use a standard Kunos track and standard Kunos car. Madza mx-5 cup at Silverstone
-> check for buggy content

2. use daytime, standard clear weather, most standard weather you can find
-> check for SOL, weather script causing issues

3. disable CSP completely by switching "Enable" off in the "General" tab of CSP
-> check for CSP as a whole being the issue

4. If disabling CSP helps, switch it back on and disable one extension after another to find out which one it is

If that doesn't help, there's a corrupt file somewhere.

5. Try using the standard launcher (with CSP disabled in CM before! Yes, CSP is still being used when using the standard launcher. You just can't configure it)

6. If that doesn't help: rename your Assetto Corsa folder in your documents. This will cause AC to create a fresh one with all default settings. And renaming doesn't need to copy/backup that folder

7. If that still doesn't help, there's something wrong in your Steam assettocorsa folder:
-> rename that folder and download the whole game again (and delete the freshly created folder in your documents too from step 6.).
-> DON'T use the uninstall via Steam. This won't delete CSP stuff or mods!
-> You could also do an integrity check via Steam, but this will overwrite sound mods, replaced clouds etc.
-> So either rename + fresh download OR copy the whole assettocorsa folder and then do an integrity check. Never do the integrity check without making a back up first!
 
I don't think it has anything to do with the ffb. I'm not an expert but that log reads more like the whole package, which contains the inputs, physics, ffb and the general game, crashed.
These error logs aren't that useful tbh.
The best way to debug thinks, in my experience, is to:
1. Use a standard Kunos track and standard Kunos car. Madza mx-5 cup at Silverstone
-> check for buggy content

2. use daytime, standard clear weather, most standard weather you can find
-> check for SOL, weather script causing issues

3. disable CSP completely by switching "Enable" off in the "General" tab of CSP
-> check for CSP as a whole being the issue

4. If disabling CSP helps, switch it back on and disable one extension after another to find out which one it is

If that doesn't help, there's a corrupt file somewhere.

5. Try using the standard launcher (with CSP disabled in CM before! Yes, CSP is still being used when using the standard launcher. You just can't configure it)

6. If that doesn't help: rename your Assetto Corsa folder in your documents. This will cause AC to create a fresh one with all default settings. And renaming doesn't need to copy/backup that folder

7. If that still doesn't help, there's something wrong in your Steam assettocorsa folder:
-> rename that folder and download the whole game again (and delete the freshly created folder in your documents too from step 6.).
-> DON'T use the uninstall via Steam. This won't delete CSP stuff or mods!
-> You could also do an integrity check via Steam, but this will overwrite sound mods, replaced clouds etc.
-> So either rename + fresh download OR copy the whole assettocorsa folder and then do an integrity check. Never do the integrity check without making a back up first!
Thanks for the great reply Rasmus! Funny thing is that I did disable every option in CSP to test if any of the options was causing this, but still had the crashes.

Stupidly.. after I posted this I realized the only thing I left on was the FFBTweaks options.
After some experimenting, I think I figured it out - I disabled the new 'soft lock' options and also disabled 'additional postprocessing script - soft lock' .

I just tested this for 2 hours, constantly paused the game, and so far not a single crash! Since this option is new in preview 218 - that probably also explains why I didn't have this issue with the former version.

But your reply is really great - I'll refer people to it when I see someone else having similar weird crashing issues :)
 
Thanks for the great reply Rasmus! Funny thing is that I did disable every option in CSP to test if any of the options was causing this, but still had the crashes.

Stupidly.. after I posted this I realized the only thing I left on was the FFBTweaks options.
After some experimenting, I think I figured it out - I disabled the new 'soft lock' options and also disabled 'additional postprocessing script - soft lock' .

I just tested this for 2 hours, constantly paused the game, and so far not a single crash! Since this option is new in preview 218 - that probably also explains why I didn't have this issue with the former version.

But your reply is really great - I'll refer people to it when I see someone else having similar weird crashing issues :)
I get crash very often with new CSP versions. In this case I downgrade to the last working version and wait for the next one. I found that sometimes I need to wait for two or three different versions, but recommended ones are working without major glitches.
 
I get crash very often with new CSP versions. In this case I downgrade to the last working version and wait for the next one. I found that sometimes I need to wait for two or three different versions, but recommended ones are working without major glitches.
The 218 preview had two issues for me - crashes when using the soft lock option and crashes when I did an AI race with 'avoid sides when raining' on in the AI settings.
The latest version seems very stable, the only issue I have with that one is that grass and bushes are clipping completely through my car in VR. Still figuring out what could cause that.

BTW do make sure you also have the latest versions of CM, SOL and Pure installed
 
Last edited:
Hi everyone!

I’m here asking for guidance and help with managing my setting in AC (with CM and CSP) and in VRS software.
I do have the 20Nm DD and want to set it up as best as I can to prepare myself for upcoming big race this year.
Gonna drive the RSS cars from GTM class (yeah, the GT3s). I didn’t pick the exact one yet.

As of now I have “ticked” the experimental physics in Drive menu in CM - should I untick it? Does it even matter with these cars? Does it change the FFB in some way (maybe wrong way)?

Apart from that I have these setting in the CM/CSP and VRS software.

Regarding CM - I set everything on 0, so it’s 100% and it’s not amplifying any effect. I set global gain on 30%. Is the global gain setting affected by CSP settings?

Regarding CSP settings - recently I ticked the box with “output real forces…” and set it for 20Nm as my wheelbase. Is that correct? Is this affecting the global gain from CM? Is this a good setting to use with these cars (the gt3; what about mx5?)?
The rest of CSP - I left that as it was without changes.

Regarding VRS settings - not much to do but still I’m not sure if I did that right. That was my 1st profile for AC. Yesterday I did my second one (don’t have SS sorry):
Damping 12;
Friction 6;
Inertia 3;
Spring 0;
Same filter - responsive 1;
Static force reduction 15;
Rest is also the same.

And I’m using 100% in VRS software as I’m learning the car and the track, to have everything a little bit exaggerated and that I could feel more when I do a mistake. In the race I’ll dial it down to conserve my stamina.

Could you please help? Thank you :)
 

Attachments

  • image.png
    image.png
    746.7 KB · Views: 150
  • image.png
    image.png
    989.5 KB · Views: 155
  • image.png
    image.png
    35.2 KB · Views: 146
  • image.png
    image.png
    32.5 KB · Views: 147
I use road effects, just gives a bit more of a real feel, I don’t think you can exactly quantify wheel profiles.
People can and do race at the top level with no feed back, so that tells me that it is more to do with personal taste.
I also drive every car, mostly , at 540 degrees. If I put it at 1080 I just can get no reaction I want from the way the car steers. That would a big no no for most.

I am of the opinion that is evident from the above there is no right or wrong within the broad spectrum of sensible.

Not much help, but that is the exactly what I meant it too be, if your settings are perfectly acceptable to you then that is correct.
 
Sim wheels generally offer too much "roadfeel" anyway, although I guess for development it can be good to have.

Turn the MacPherson strut tweak on, if you have it off, any Cphys cars with realistic strut geometry (ie: mine) will have wrong FFB. The mechanical trail line is from STRUT_CAR to LBJ IRL, not from strut top to bottom like KS coded it.

It won't do anything to cars that have the LBJ and STRUT_TYRE aligned ie: vanilla cars, cars where the strut bottom and LBJ are merged etc.
 
@RasmusP

I just bought a Logitech DD GPRO wheel which has 11Nm of Peak torque and have been fiddling with both Wheel drivers and AC ControlManager FFB setting but not completely there yet
this part of your post is a good insight, the chance with my wheel is that it has ON DISPLAY Live torque so this in addition to the FFB clipping widget from AC will help me I think
thanks again for sharing


It's the same for ALL ffb wheels on the market.

I call this "Nominal Torque" vs "Peak Torque".
50% menu + 80% in-car + 100% TM panel = 0.5*0.8*1.0 = 0.4 = 40% nominal torque, 100% or 12 Nm peak torque

80% menu + 50% in-car + 100% TM panel = 0.8*0.5*1.0 = 40% nominal torque, 100% peak torque


80% menu + 100% in-car + 50% TM panel = 0.8*1.0*0.5 = 40% nominal torque but only 50% peak torque (and probably some clipping).

PS I had been using Gyro effect in AC for years (25%), even before ControlManager had it implemented, on both Gear and belt driven wheels and it was quite noticeable.
I guess this is a thing from the past now
Hi,

Have you found what settings for Logitech Pro wheel works for you?
 
Hi,

Have you found what settings for Logitech Pro wheel works for you?
What TM stands for? Torque Manager, like True Drive for a Simucube, the software one adjusts the torque level from the Direct Drive?
If so, could you explain the point with clipping? The difference between the 2 settings are the 100 percent/50 percent you changed in TM, which will cause clipping
 
80% menu + 50% in-car + 100% TM panel = 0.8*0.5*1.0 = 40% nominal torque, 100% peak torque

80% menu + 100% in-car + 50% TM panel = 0.8*1.0*0.5 = 40% nominal torque but only 50% peak torque (and probably some clipping).

Because this is fundamentally wrong. Clipping is based from in-game settings. You can't have clipping from lowering torque at the hardware. Clipping is always from force settings in the game, always!!!!

if in-game, for example 80x100 is too much force feedback signal, then you have clipping at 0.1,0.5, 1,2, 3 up to 11Nm (doesn't matter if you 500Nm torque available, it simply will clip).
 
What TM stands for? Torque Manager, like True Drive for a Simucube, the software one adjusts the torque level from the Direct Drive?
If so, could you explain the point with clipping? The difference between the 2 settings are the 100 percent/50 percent you changed in TM, which will cause clipping
TM is Thrustmaster, wheel manufacturer. Their wheels (T300, T500 anyway) aren't advised to run at 100% because it makes it less linear.
 
Last edited:
80% menu + 50% in-car + 100% TM panel = 0.8*0.5*1.0 = 40% nominal torque, 100% peak torque

80% menu + 100% in-car + 50% TM panel = 0.8*1.0*0.5 = 40% nominal torque but only 50% peak torque (and probably some clipping).

Because this is fundamentally wrong. Clipping is based from in-game settings. You can't have clipping from lowering torque at the hardware. Clipping is always from force settings in the game, always!!!!

if in-game, for example 80x100 is too much force feedback signal, then you have clipping at 0.1,0.5, 1,2, 3 up to 11Nm (doesn't matter if you 500Nm torque available, it simply will clip).
Well, apparently your reading skills are fundamentally flawed.
Sorry for the harsh response, couldn't resist.
You completely ignored the 50% in-car vs 100% in-car. The menu gain and in-car/per-car gain are multiplied and THEN the game clipping meter clips off anything above 100%.

So the first equation has 80% * 50% = 40% gain before the clipping meter, the second equation has 80% * 100% = 80% gain before the clipping meter.
From my experience with different cars, clipping starts to become an issue for normal driving at about 65% gain before the clipping meter.

My example was about having the same torque with both settings BEFORE clipping happens.
But the first settings will then go up to 2x the torque of the second settings.
 
Last edited:
Well, apparently your reading skills are fundamentally flawed.
Sorry for the harsh response, couldn't resist.
You completely ignored the 50% in-car vs 100% in-car. The menu gain and in-car/per-car gain are multiplied and THEN the game clipping meter clips off anything above 100%.

So the first equation has 80% * 50% = 40% gain before the clipping meter, the second equation has 80% * 100% = 80% gain before the clipping meter.
From my experience with different cars, clipping starts to become an issue for normal driving at about 65% gain before the clipping meter.

My example was about having the same torque with both settings BEFORE clipping happens.
But the first settings will then go up to 2x the torque of the second settings.
I am Swiss, my first language is Swiss German (a dialect no one understands). Official languages are Proper German, French, Italian and Rumantsch (an old language related to Catalan). So I speak a language, but I write and read in a different one. English is my 4th language, Spanish, which I'm not really good at, is number five then. i had to search for "flawed"., and you are right, but also a bit wrong.

The way you calculated the torque is a bit miss understandable. In game FFB gain is Fe in Assetto Corsa in percents, So we know that it is 100 percent, but we don't know how much Nm it is. Simucube software, True Drive, does state the force applied from the Direct Drive in percents and NewtonMeters.

And because you calculated all in one calculation it was not clear for me if you are aware of that clipping is a follow of the in game FFB settings, these parts here:

80% menu + 50% in-car
80% menu + 100% in-car

Whatever you set in the Thrustmaster app is, wen we talk about clipping, not relevant. I see more people not understanding this than actually understanding it.
 
I am Swiss, my first language is Swiss German (a dialect no one understands). Official languages are Proper German, French, Italian and Rumantsch (an old language related to Catalan). So I speak a language, but I write and read in a different one. English is my 4th language, Spanish, which I'm not really good at, is number five then. i had to search for "flawed"., and you are right, but also a bit wrong.

The way you calculated the torque is a bit miss understandable. In game FFB gain is Fe in Assetto Corsa in percents, So we know that it is 100 percent, but we don't know how much Nm it is. Simucube software, True Drive, does state the force applied from the Direct Drive in percents and NewtonMeters.

And because you calculated all in one calculation it was not clear for me if you are aware of that clipping is a follow of the in game FFB settings, these parts here:

80% menu + 50% in-car
80% menu + 100% in-car

Whatever you set in the Thrustmaster app is, wen we talk about clipping, not relevant. I see more people not understanding this than actually understanding it.
Ah, ja ich bin aus Hamburg :D Aber dazu kommt nur täglich Englisch und vor 14 Jahren in der Mittelstufe Französisch.

You're totally right, that way too many people have no clue about this all, so thanks for pointing out that it's too easy to understand incorrectly!
My equations are too easy to misunderstand, I totally agree. Your tone seemed a bit rough, so I responded as rough, hehe.

But yeah, we both know how clipping etc. works, so it was just a misunderstanding.
In other threads, I always mention the Nm too.
If we do that here:

(80% menu * 50% in-car) * 100% TM panel (max torque ~5 Nm):
=> (0.8*0.5 = 40% overall gain (no clipping) * 1.0 max torque = 40% nominal torque, 100% peak torque;
2 Nm nominal torque, 5 Nm peak torque


(80% menu * 100% in-car) * 50% TM panel (max torque ~2.5 Nm):
=> (0.8*1.0 = 80% overall gain (some clipping!) * 0.5 max torque = 40% nominal torque but only 50% peak torque due to clipping;
2 Nm nominal torque, 2.5 Nm peak torque
 
I'm having the same problem.

The CSP gyro implementation causes some crazy wrist breaking oscillations. I have tried for two days experimenting with settings in CM/CSP and my DD's driver settings. I have not been able to find a compromise that feels good. So far the only thing that works is disabling the "Physically accurate gyro implementation" and enabling the experimental gyro in the AC/Controls menu. No more crazy oscillation. An added bonus with that gyro is that I do not have to run a excessive amount of damper/friction/intertia to the point that it kills much of the detail.

I hope the developers will implement something similar to ACC's Dynamic Damping into CSP's settings.
I can confirm this issue exists at least on Moza R9. The oscillation is gone after disabling the CSP gyro. That said, I still enable it because I like how the FFB feels when it's on. I use 120% range compression to compensate.

Easiest way to replicate the issue is driving F2004 at very high speeds like 330+ km/h.

On Moza discord some people recommend a fix on Moza settings which changes the FFB curve so that the low forces is dampened, kinda like the opposite of the usual gamma setting, but the rest of the curve is linear. Here is how it looks.
moza_oscillation_fix.jpg

I'm sharing this so that it may give an idea. Could it be that the gyro effect generates too much "return to center" force for the very tiny movements of the wheels at high speeds?
 
Could it be that the gyro effect generates too much "return to center" force for the very tiny movements of the wheels at high speeds?
Almost. The main cause of oscillation in regard to gyro is that it generates too much centering force for your wheel driver to keep up with. You'll note that if you turn the FFB down, the oscillation disappears. If the wheelbase was able to be more responsive, oscillation would decrease.

A good practical example of this (which can be tested by simucube owners) is to increase the amount of filtering (via reconstruction filter or just the low pass filter) and see how the oscillation actually gets worse the more filtered the signal gets. Filtering essentially slows down the response of the wheelbase, thus making it further behind the desired signal, thus causing more oscillation.

The root of the problem is that the inputs and outputs in the control system aren't directly linked. That is, the wheel sends its position to the sim, which then sends the wheelbase what torque it should be producing at that instant. The torque the wheelbase produces is a reaction of the torque the sim is producing, there is no direct interaction, so the torque and wheel position in the sim are directly linked, but the torque of the wheelbase and its position are not (as the torque response of the wheelbase cannot be instantaneous ). That's (mostly) why oscillation happens.
 
  • Deleted member 197115

A good practical example of this (which can be tested by simucube owners) is to increase the amount of filtering (via reconstruction filter or just the low pass filter) and see how the oscillation actually gets worse the more filtered the signal gets. Filtering essentially slows down the response of the wheelbase, thus making it further behind the desired signal, thus causing more oscillation.
Recon and other constantly operating SC2 filters are extremely low latency.
Oscillation and violent SAT snap back happens because wheel is too fast, not slow, reason why consumer belt driven or over dampened DD wheels are not affected by this.
 
I can confirm this issue exists at least on Moza R9. The oscillation is gone after disabling the CSP gyro. That said, I still enable it because I like how the FFB feels when it's on. I use 120% range compression to compensate.

Easiest way to replicate the issue is driving F2004 at very high speeds like 330+ km/h.

On Moza discord some people recommend a fix on Moza settings which changes the FFB curve so that the low forces is dampened, kinda like the opposite of the usual gamma setting, but the rest of the curve is linear. Here is how it looks.
View attachment 719666
I'm sharing this so that it may give an idea. Could it be that the gyro effect generates too much "return to center" force for the very tiny movements of the wheels at high speeds?
How much range compression were you using with the gyro enabled?
For me, the "new" gyro always only calmed the wheel down, like it should.
But range compression adds "gain" so when using values above the neutral 100%, you need to lower the gain to not get oscillations.
The effect is pretty massive. If my wheel is not oscillating at all when driving straight and taking my hands off, even 110% range compression can make it instantly oscillate wildly on straights.

You're then countering this via the moza ffb curve (which is an awesome feature imo).

I would recommend to lower your gain, put range compression back to 100%, enable the new gyro and then boost the first 2 points of the ffb curve a little bit to make the center tighter and go in a smooth, almost straight line towards 100% in the curve.
Move the first point a bit around until your straight line feel is tight and the wheel is moving a bit when taking your hands off and maybe even starting to oscillate, but bit wildly/violently.
 
Recon and other constantly operating SC2 filters are extremely low latency.
Oscillation and violent SAT snap back happens because wheel is too fast, not slow, reason why consumer belt driven or over dampened DD wheels are not affected by this.
Had some time, so this is a pretty lengthy response.

You are getting a bit mixed up with what latency means in context, I will elaborate in the next paragraphs. Re: input filtering; I have tested at length. Any filtering adds latency (by definition, really) and the frequency cutoff of the reconstruction filter (even the fast one) is observably not very high, meaning that it is not going to be of negligible latency. I actually find it to have worse time response than the simple low pass, even at the "Fast" setting. In any case, both types of Simucube filters add latency, and at high ffb ramp rates, both observably make oscillation worse. IER has 3 very different in-house sims with SC2s and there are 3 other sims we have built for clients with the same.

The filters mentioned above modify the input ("goal torque") signal. This introduces a phase delay which can perpetuate oscillation, as the original input to the wheelbase (which is the sim's torque output, ~proportional to current wheel position when on a straight) now no longer lines up with what the wheelbase is trying to do; the wheel's goal torque is delayed vs. the sim's output (and remember, it's not a linked control system, any delays are very important). This directly causes oscillation, as now the polarity of wheel position does not necessarily have to oppose the polarity of torque (as would be the case with the direct signals from the sim), thus it is not an inherently self-centering system.

The reason that e.g. belt driven wheels are somewhat less affected (and for the record, they are definitely still affected) is because of output response, *not* input response. Among other things, the motors on those wheels are generally fairly highly geared and can thus suffer from slow torque output response (in simpler words, low slew rate). This slow response causes phase delay, but at the output side only, not input, and only in some situations; what the wheelbase is *trying* to do is still aligned in phase with the sim. This is an important distinction, as the input's integral controllers are generally what cause non-vibratory oscillation in this context. For a similar effect, try reducing slew rate in SC2 driver and seeing what it does to oscillation. To save you the trouble, the best oscillation characteristics happen with zero input filtering and low slew rate (but there's a limit; below a certain point, it will cause slow oscillations). Since slew rate is a linear limiter, you don't actually get any phase delay from signals that are below the threshold of the limit, which is why it's more stable than input filtering (which generally adds some phase delay everywhere and additionally causes the bad integral controller response that creates feedback oscillation). I'm using the terms input and output a bit loosely here, but they are intended to mean "pre power stage" and "at power stage" (ie torque controller vs. current controller); it's a bit arbitrary, but I think simplest to get point across.

Furthermore, there is not really such a thing as "too fast" in the way you wrote it, but there is such a thing as underdamped or too fast for the hardware. A perfect wheelbase outputs exactly what the sim is sending to it, instantaneous response is the unequivocally correct response. A wheel with instantaneous response would not perpetually oscillate at all (all tire forces are self centering on a normal car, the wheel would return to center quite quickly). Again, just turn down FFB and you'll find that oscillation goes away; the wheel is able to keep up linearly at the lower torques and is too slow at higher torques. If a wheelbase's PID is tuned to overshoot the torque response (e.g. 2nd+ order system, where overshoot would mean the system is underdamped) to increase perceived response/slew rate (without necessarily decreasing settling time), that is not "too fast", it's overshoot/underdamping. Any wheel with overshoot (or undershoot, or any non linear response at all) will oscillate.

It gets more complicated when you get into FFB sampling and USB communication rates, but the basic idea is as-presented above.


TL;DR the torque integral controllers on a wheelbase are important, so where you do the filtering matters a lot. Limiting power stage (e.g. slew rate) doesn't have the same effects as limiting input signal (e.g. low pass filter, etc) due to PID staging. That's why belt wheels are different than DD, etc. A wheelbase that responded without any delay would not perpetually oscillate at all (which is observably the case, as when you lower FFB, you also get less/no oscillation, as the wheelbase driver is then able to keep up with the input request).
 
Back
Top