If you add Damper (not Dynamic one) you will have it when car is moving as well.
Same as in AC when you change min damper in CM
or by modifying DAMPER_MIN_LEVEL
in Steam\steamapps\common\assettocorsa\system\cfg\assetto_corsa.ini
1 Like
Good point. AC is what was used originally. A long day froze my brainā¦
ā¦ and Damping is re-tuned now. Next, Friction effect. It goes unstable too easily.
3 Likes
Iām testing something and it occurred to me these settings in the PLR are intended to be used with Damping and Friction disabled in TrueDrive unlike what the TD profile I attached probably had.
Added this note to be clearer about how to test
Fyi I finally tested Jolt Magnitude zero for its effect on the wheel losing center when hitting obstacles or cars when DirectInput Effects are enabled and I donāt think it had an effect. Itās not always a contact thing.
I still get subtle but obvious loss-of-center behaviour from the wheel when making contact with things. Oddly, it randomly corrects after some movement, or more contact, or time, Iām not sure which.
Edit: To be clear, sometimes I can just go around a corner and coming out of it the steering is biased to the way the wheel was turned. Like, it doesnāt go back to center completely.
I do use a custom center via TD > Overview > Reset Center: Itās adjusted by about -1.25deg.
If I could unset the custom center Iād test again to see if thatās involved but Iām not sure where I can do that.
Edit: I tried resetting to 0.00deg (which due to my slightly crooked setup āfeelsā off-center) and the problem still happened.
if the center point reported by True Drive also shifts, then something is physically happening - either the QR is slipping on the motor shaft or the encoder is slipping.
Any ideas on which game would be best to tune the friction effect with?
I donāt know about ābestā game but since the problem happens reliably on the old SimBin titles Iād recommend those, particularly GTR2.
Iāll check in TD next time
I have reached satisfactory fresh implementation for the friction effect. However if there is a game that has different friction coefficient for left/right directions, or a deadband, I could not find such. Deadband is also not well documented for this effect - is it with regards to adjusting friction stiffness or with regards to the center point? If former, thenā¦will need test with such game and if latter, then also offset still needs to be accounted for.
1 Like
The Dead Band is related to the CP Offset. Here is a quote from the PID specification:
The region around CP Offset where the condition is not
active. In other words, the condition is not active between Offset
ā Dead Band and Offset + Dead Band. This value is Normalized.
Condition Block Parameters - p.12-13
Here is also the MS documentation for reference:
https://docs.microsoft.com/en-us/previous-versions/windows/desktop/ee416601(v=vs.85)
Iāll capture some DirectInput logs from the games I have, and will let you know if there are any using inertia/friction. IIRC the PC1 had inertia setting in the FFB parameters, but not sure whether it used the actual DI effect, or the DI Constant force effect (as part of the regular FFB). Donāt have this game installed, though.
You are correct. But that chapter, if you look closely, does not mention friction effect at all. But friction clearly is a conditional effect. So what is to be used as metric for itā¦
Current implementation is that once the rotation speed is high enough (to not cause unstable effect), it will ramp up a torque to resist the rotation, but in a way that is not dependent on speed itself (like damping is).
I think the correct method in this regard is to take cpoffset and deadband into account with regards to axis position, but it is no specifically mentioned that friction effect should work that way 
Yea, sorry didnāt see there is no mention for the friction metric.
In this msdn article they talk a little bit for the friction effect:
https://docs.microsoft.com/en-us/previous-versions/windows/desktop/ee416335(v=vs.85)
Friction. The force is applied when the axis is moved and depends on the defined friction coefficient.
And then some more in the Offset description:
The offset from the zero reading of the appropriate sensor value at which the condition begins to be applied. For a spring effect, the neutral point - that is, the point along the axis at which the spring would be considered at rest - would be defined by the offset for the condition. For a damper, the offset would define the greatest velocity value for which damping force is zero. Offset is not normally used for inertia or friction effects.
The way I see it, the metric for friction should be constant and then it all depends on the given negative/positive coefficient, with the resultant force cropped to the negative/positive saturation value. The effect gain should also be considered.
I agree, although they mention the offset is usually not used, but if there is one, it should probably be treated that way.
1 Like
now when I think of the friction,
the metric is axis rotation speed,
and when there is any speed, it should give force output equal to negative/positive coefficient.
But as the rotation speed is likely in the original USB PID spec told as axis units per millisecond, it will become difficult to tune effect as the output magnitude would depend on the lock-to-lock steering range. The stability of the output would need to be generally tuned - it was not important on low-end game controllers or game pads, but is very important on strong direct drive servo motors. Therefore to output suitable result on something that is not dependent on any other setting on the wheel base, there needs to be something else used, and the degrees per second is used instead.
However, there needs to be some magical scaling factors to get some believable friction and damping outputs. And, how should one then take the saturations into account, as the output is something else than what was intended? I have an idea for this, but so far havenāt seen any game that would use them either.
So, condition effects seem to be a bit of black magic, and having had a look at some available implementations on Github, it seems that our firmware is not the only one that has some difficulties in this regard.
Sometimes a good idea turns out to be difficult, even impossible to realize. From time to time one is waking up in the morning and has the perfect solution. And there is stuff there is no solution.
With a good steering wheel (that is made for a car class like F1, rally, GT), and simulations that deserves this title, the Simucube 2 product line is almost perfect. Itās sure the best DD at the moment.
TD should be clean and puristic. If we get titles with FFB made for wheels TD doesnāt need much functions.
I myself would prefer to have dynamic fine tuning effects that are working situationally, but itās better to have them when the suit, instead of having some even you donāt really understand.
Paddock looked like a good idea. But presets made for the same title include settings so contradictory, I doubt it is helpful, more the opposite. This is not your fault.
Hang in there, you doing a great job
I am wondering if there is some reference implementation of the FFB driver using all these effects, or SDK examples from Microsoft.
Like this DI Spring testing project which seems like based on āexample from Microsoftā
All consumer wheel manufacturers including the cheapest ones seem to figure out all these effects long ago, the whole DirectInput is an ancient API.
Please keep trying. It might be tough but it does seem odd that the SimuCube seems to be the odd one out that doesnāt support DirectInput Effects. Iāve had a G27 and an AccuForce and they just worked out of the box.