Guide: Optimal FFB settings for rFactor 2 - The key to being in the "Zone" :D

Both of those (Mysta and Acoutsa) sound right. I would not expect anyone to be using more than 0.10-0.15 with a g25/27 or lower ffb wheel.

 

Excellent. I will try balance it up. Thanks very much!

 

Welcome. Let me know how you get on.

 

The G25/27 has a 'built in' center deadzone,it is so the motors do not fight each other.
Logitech made it this way.
They could if they wanted release a new firmware that removes it but they said they won't.

 

+1

Yup, I even emailed logitech support twice about this, and I even phoned them. I got the same answer everytime. Unfortunately,I went through the process of wasting my time trying 3 different G25s because I literally thought they were broken - having the FFB essentially disabled until you turn the wheel a few degrees to the left or right just seemed like the product was broken, to me.

The "FFB is essentially off until you move the wheel a couple degrees to the left or right" completely killed my straightline-grip feeling especially feeling threshold brake lockup (front or rear), chassis jolts (too small or big of a downshift blip), the rear getting light under straight line, or pretty much anything else while keeping the wheel straight like for example feeling bumps, road texture/"noise", vibrations (eg. engine), uneven road surfaces like the cobblestone road at Lienz, etc.

It's the reason why I was, and still am, faster with the Logitech Momo wheels (Logitech Momo Racing [black], and Logitech Momo Force [red]) and any wheel where the FFB does not disable while in a straight line (Eg. Thrustmaster T500RS, Fanatec CSR, etc.) than with the G25/G27. If I remember correctly though, the G27's centre area of no-FFB is smaller than the G25 (you have to turn it left/right a smaller amount before the FFB activates), however it still exists.

 

@DrR1pper

I now have 0.35 Multi, 0.100 Steering Torque Minimum and 5 Smoothing and this seems to be a really nice blend.

A little oscillation in pit lane but really not much. I feel the vibration on the straight if bottoming but again feels acceptable.

Thanks man!

 

Your welcome Nick.

Did you use some "steering torque sensitivity" as well or not?

 

Currently:
"Steering torque sensitivity":1,
"Steering torque sensitivity#":"Sensitivity curve applied to representable torques: 0.0=low 1.0=linear 2.0=high",

 

ok, so no then. Default = 1 (linear).

Point being that if you'd still like some more strength in the low end forces, you can try increasing the "steering torque sensitivity" (STS) a little (which you'll need to lower the STM value for too if you do so).

Here is how STS effects the ffb response curve (though not accurately portraying how the values affect the linearity of the ffb response curve in rf2 however, just an example picture):



You could get a really nice compromise with this or maybe not, I've never tried. In theory it looks like it could work really well provided you don't use too much which could induce an ffb clipping like effect in the high force range (as shown in the red curve). I don't know how much and STS of 2.0 (max value) makes the curve non-linear so it's impossbile to guess what would be a good compromise value. You would need to do some tests, set an STS value and check if low end forces feel better and then check ffb fidelity in the high end forces whilst driving at the limit around fast speed corners. If all is ok, increase the STS again in small intervals, test, rinse and repeat. You may want to take of STM completely whilst doing this because the limiting factor will be when the high end forces feel compromised to you at some STS value. And once you've found that sweet spot STS value, you can then repeate the STM test to find the right value for your wheel and choice of profiler and rf2 ffb settings. Heck, if the STS value increases the low end dramatically enough without compromising the high end, you may not even need any STM (but my guess is you still will but could be reduced a lot).

Sorry can't be more definitive help than that. Finding the truly most optimal settings possible for anyone's specific hardware is both an art and a science.

 

Can I condensate this with : more powerful is your wheel FFB, lower your STS should be?

 

1. DrR1, is there anything you have discovered, FFB wise, to help with the feel of car under braking? I have tried all sorts of FFB settings (including Paul's, which are generally very nice in terms of steering and rear-end rotation, but that's never been a problem for me even with junk wheels and junk FFB) and yesterday, while ending a run (classic F3), I was braking to a stop and I literally had no idea my tyre was locked and scrubbing besides me having to visually look at the tyre on my monitor, or sometimes I will get a locking feeling but it's only while the wheel is turned and the feeling happens suddenly by the time it's too late without any threshold-on-the-limit, or approaching-the-limit, feel/warning.

I can't get constant FFB information telling me all sorts of slip angles, especially during the vital straight-line braking phase and how you transition that over to the very initial turn-in. Having no sense of leaning on the front tyres during braking, and approaching that locking limit, hitting that limit, going over that limit, and then backing off just the right amount to be unlocked but without over-backing-off (which would cause you to under-brake for a half-second or so and run-wide) is really killing me relative to how I can feel this in rFactor 1, Game Stock Car, etc. It also makes the sim much less enjoyable when braking is a guessing game and a different wild experience every lap (if pushing hard, of course you can lap slightly slower and not suffer issues, but then you're under driving your limit and that makes racing pointless).

2. Also, I don't have a "gritty", rough, road feel in the wheel (sort of what you experience all around you when in a race car). It may not be technically felt from the steering wheel in real-life, but it is sort of felt all around you through the seat, the chassis, through your whole body. My brain feels this is missing in rF2 (fine in rF1, GSC, etc.) and that road-texture grittiness makes a difference in feeling the friction as you turn into the corner. Do you know of any way to improve upon this? My brain can sense this is missing from the overall experience of racing a car. It may make the steering action less glossy and smooth, but my brain needs this and without a motion sim the FFB is the only way to send these physically to my brain (not a problem with rF1, GSC, etc.).

 

For this reason I should be using the 'drift' setting on my CSR Elite?

DRI (default = OFF)
The "Drift Mode" reduces the overal resistance of the wheel and let you turn the wheel more easy. It almost works like a power steering. It reduces the basic dampening of the wheel and makes the wheel turn faster. If the values is set too high (or if the games FFB interferes with this feature) you might experience some oscillation. If that happens - reduce the value or turn DRI "OFF" again.

 

Before i go further, if reading just this then I don't agree and here's why. I'm not saying one should raise the STS value so high that it over oversaturates the high end forces like shown in my mock up representation of the extreme ends of STS values could do. But let's say someone did use a high enough STS that produce a way over saturated ffb response curve with a severely plateauing high end (which is effectively the same as inducing high end ffb clipping) but they also found the strength of the low end forces was an improvement to them (where they could not feel anything before, then also lowering the ingame ffb multi to avoid the clipped high end forces caused by the high STS value, in my mind this can be a solution to weak/non-existent low end forces.

The problem with doing the reverse and using a low STS value is that it reduces the strength of the low end forces sent to the ffb wheel and this will also increases the intial ffb deadzone of you wheel (and dramatically so if we took an example of a 10% initial ffb deadzone for some arbitrary ffb wheel with a linear ffb response curve, STS = 1 used, vs a lower STS value that hypothetical produced the green response curve in my graph the initial ffb deadzone would become 53%...ofc you could remove this with STM as so it won't be an issue). And you are right in saying that you would then need to increase the ingame ffb multi to increase the strength of the low end forces (as well if you didn't use the STM option to remove the much enlarged initial ffb zone by using a lower STS value) but doing so then induces early onset ffb clipping which is a big problem in of itself ofc. Even if this did cure a problem for you in the low end forces (as you describe later on in great detail), raising the ffb multi above the optimal value seems to produce another problem in it's place.

Ok, the bit in bold is not what the graph represents. The graph is simply a pictorial representation of how the percentage of max ffb torque calculated at the virtual steering wheel by rf2's physics engine is correlated with the percentage of max ffb torque output by your wheel. That is all. So for the same percentage of max ffb torque calculated at the virtual steering wheel, lowering the STS will reduce it's corresponding percentage torque output at your ffb wheel.

Ok i think we're actually in agreement here but i think you may have mistaken my graph to be a representation of the physics torque vs virtual steering wheel torque. I understand and agree that the physics torque and virtual steering torque and one and also linear (because they are in fact the exact same thing ofc), my graph is a representation of physics/virtual-steering wheel torque to ffb steering wheel torque.

I agree.

And this is where i'm a little stumped on because i feel like i understand what you saying and describing (though i've not had any real-life experience to use a reference to know if the feeling is supposed to be correct or not) but i don't understand how it can be the ffb wheels fault. This issue of equilibrium between the moment force from car rotation and the opposing self-centring moment force from the front wheel caster is purely confined within the rf2 physics engine and is therefore a closed/isolated system. And if you are finding that the self-centring moment is greater than the car rotation moment should be based on your real-life experience, i can't see it being the ffb wheels fault. In fact it sounds like what you've done to try to alleviate this problem you see with the car behaviour in these types of cornering situations (presumable only happens in the low end force regions of cornering?) is by numbing them out completely (hence lowering the STS). I can see how numbing them out would then produce the illusion of the equilibrium between these two forces in those situations but if i've understood everything correctly it doesn't change the fact your problem is actually with rf2's physics behaviour in those situations.

I understand what you're saying but doesn't seem right that the ffb wheel should be in the loop of what your describing which should be isolated to the physics engine.

Those are some very interesting observations and fantastic food for thought. Again i think i've experienced what you describe based on memory but i also think i've remembered plenty of times where the wheel does go completely light when i've attacked the corner well and the forces are in equilibrium but i can't be 100% certain. Which makes me wonder if there is possible another variable that is causing your observed problems, possibly other ffb variables/settings that you've changed and used differently to me?

I'll try to test your settings but may likely not be able to since i've moved homes temporarily and don't have the space to setup properly. Then i'm moving to Hong Kong in Jan/Feb for 6-12 months. But i'll try to just no promises.

Not at all, didn't remotely sound like an attack at all. And i welcome hearing any view opposite to my own...freedom to inquire, question and be questioned are required to get to the truth of things, doesn't mean i always agree with an opposing view but every now and again after hearing them i realise that i was wrong in my thinking. But you can't be afraid to make mistakes and it's only really a mistake if you don't correct it.

Your post definitely took me time to digest and provided me with many instances of cognitive dissonance.

I'm not 100% sure i'm right and i could be completely wrong and the ffb wheel is the cause of the problem and if so it could be linked with the very thing Leo Bodhnar is describing in https://dl.dropboxusercontent.com/u/17548791/FFBdontwork.pdf.

Or perhaps our mainstream ffb wheels are just too slow in transient response times (which is certainly the case due to the use of small weak ffb motors that need very large gear/transmission ratios to increase torque output at the severe cost of transcient response time which induces lag). And if it is a lack of a PID controller problem as descirbed by Leo causing/contributing said problem, then only a better more powerful ffb wheel will help but only up to a point.

 

Sorry Spinelli, i don't know of anyway to improve this (if even possible). I don't play rf2, GSC or others but from the few times i've karted, i understand what your saying and in keeping with realism of how and what forces should felt through the ffb, it would seem rf2 is keeping it 100% realistic, so no artificial sensations through them to convey to you the longitudinal traction of the front tyres. Something that as you rightly say is felt predominately through your body but perhaps there are some ffb details to tell the driving about the front tyre but perhaps they are too low for our weak mainstream wheels to successfully convey to us. Perhaps wheels such as the bodhnar do not have this issue.

 

2 Main Kinds of Clipping, FFB Signal Clipping & FFB Power Clipping

I have no idea how valid the following is, but I'm posting this because I thought of this thread when I read it:

Source --> comment by user "jubuttib" from about 2 weeks ago @ https://www.youtube.com/watch?v=XQPWsvO1EPA

 

I think this is a good theory. The more i think about it, you may be right it's down to the wheel but still not 100% sure and if true whether that stops with more powerful wheels.

 

That's all 100% correct and i think a better explanation than my own in the OP.

And Paul, I'm started to really think strongly that it's the weakness of our ffb wheels that maybe the cause of the issue you've described. But you i need to ask, is the problem you describe happening in all ranges of forces or predominantly in the low end forces (without STS applied)?

 

(firstly, you attachment picture doesn't show and i would love to see it )

All very interesting Paul and i think i can see what your saying but i'm still not 100% sure i've understood you correctly.

Can we start from the beginning and clarifying a few things to make sure there is no misunderstanding?

You're saying that STS is not an ffb response curve linearity function but in fact a transient response time (rate of change) function? So lower STS increases time it takes for the motor to build up to the required torque output at the wheel? Which is essentially just reducing the acceleration rate of the motor to reaching the same torque output?

And if i've understood this correctly, have you by any chance been able to confirm this is 100% true perhaps with one of the devs? And if not, it's perhaps worth checking with a dev to be sure despite how convincing it has been from your experience. It's just that i've had an instance when talking to a dev in the past that gave me a very strong impression that it was a linearity function but i could have totally misunderstood. < One of the examples of cognitive dissonance i was having with your post, lol, because you made a lot of sense and even the name is "steering torque sensitivity" seems it agree more with your description but i have that one instance of remembering being told differently.


edit: But the more i think about what you've said and your description of how STS really works and your experience and the name of the function is starting to make more logical sense to me. And lower the transcient response time (i.e. lower "rate of change" by lowering the STS) can help to reduce overshoot problems which can cause oscillation (equivalent to an under damped suspension) instead of a critically damped system which is what we ideally want.



Btw, i spoke to Leo about 6 months ago over the phone to talk about his article and like what you've written here it provided me plenty of cognitive dissonance. After two calls i sort of half understood and half forgot what we was trying to convey but after looking and considering transient response of our motors as a factor to explaining what you seem to be describing, this may very well be what he was talking about. Because a sim with ffb setup to work with a PID controlled servo motor ffb wheel could give us the perfectly critically damped responses of the ffb motor for every torque target desired without overshoot (or undershoot by being underdamped). But this is not achievable with current ffb wheels and any sim because A) most wheels do not have a true servo motor (with PID controller) & B) no racing sim has ffb working like this and so even if you wheel has a true servo motor it cannot and does not take advantage of it. The way the feedback loop between ffb wheel and sim has always worked is the game sends the wheel a force signal and wheel sends back a position signal and this is not actually correct with how it works in real life. The sim should be sending the wheel a position target and the wheel sends back a force signal (that the driver is exerting onto the wheel. Because the driver does not actually input a new steering position to turn the car but actually applies a force/torque to the steering wheel to upset the equilibrium of forces on the front wheels in an attempt to change the direction of the front wheels to his/her desire. This is essentially the distinction he was trying to get across between how all ffb wheels and sims work vs how the feedback loop works in the real life and the associated problems with the current method. And i think one of the problems this causes is that torque response of ffb wheel are most of the time under-damped when what we want and need for a realistically responding ffb wheel is a critically damped response each and every time. Assuming all the above is true, lowering STS could certainly reduce the occurrence of under-damping and provide critical damping. The only pitfall being however that a slower transient response induces lag in the ffb output response (as can be seem between the green and blue curves).

I think you've just helped me understand what Leo was saying completely now. Thanks!

Please feel free to tell me if you think i'm wrong though, lol.

 

Sorry paul, I really don't understand this and the graphs are identical. Are you saying that regardless of the difference in STS value, an ffb signal of 50% sent from the sim to the wheel equals the same 50% ffb torque output at the ffb wheel (and the same goes for another other arbitrary ffb signal value sent to the ffb wheel)? So in real world number say that 50% equates to a measured constant torque of 10nm at the ffb steering wheel with an STS of 1, lowering (or raising) the STS value to any number will still produce the same 10nm or the same 50% ffb signal sent from the sim to the ffb wheel?

Ok, i was going to write a better explanation with step-by-step description of the difference between the two feedback loop models and explain why the PID controller with positional target in and measured net torque at the ffb wheel would be much better but it would be very length and time consuming but i'd be happy to give it a try if you'd like me to give it another crack. It will also most likely never happen because a new type of ffb wheel that is both more complex (which means costly) and more be powerful (at least leo bodhnar level of powerful at minimum) and sims must rethink their ffb method to account for such a system as it's completely incompatible with the current method. In summary though, what you would get from such an ffb system is more accurate torque reproduction that can account for the added inertia that someone places on the ffb steering wheel just by holding it and more so the tighter they grip it. The ffb wheel position would track as close to perfect as possible with the rotational response not acting like it's under-damped or over-damped but instead always critically damped possible by the ffb motor. And lastly, the ffb response of the motor would always be in sync with the ffb/physics engine rather than lag behind by at least 1 refresh interval of the ffb/physics engine (which can be quite a lot when you consider it's only 60hz for rf2 which is 16ms lag and that lag is also fed back into the loop as feedback which only compounds the issue further).

I want to try to explain it but it's too late atm so i'll try again tomorrow.

It's not a question of the position signal not being needed but rather that no ffb wheel on the market and sim has been designed to use it in the ffb feedback loop. You would need to use a servo motor ffb wheel to make use of it and you would need a new ffb method to take advantage of it (which i believe there is a massive one to be had based on leo's article which i now believe to be correct.) And yes, with a servo motor and using it's PID controller you can get a perfectly matching steering wheel position to what it should be in the virtual world and also without the inherent lags caused by using the conventional ffb loop method and the associated lag(s) that can build up quite a nasty amount of error (especially in mainstream ffb wheels) which also contributes to under/overshooting of the correct rotational position the steering wheel should have moved to after 1 refresh of the ffb/physics cycle (a problem that the existence of servo motors were designed to solve). Unfortunately, even though the leo bodhnar wheel is a complete servo wheel with a PID controller onboard, it goes completely unused because a) no racing sim's ffb loop works this way of sending the wheel a position target and receiving back a net torque at the ffb wheel shaft and b) even though the leo bodhnar is a servo motor wheel, it does not have the technology to measure the applied torque at the ffb wheel shaft by the sim-driver (however i could be wrong and this could be completely unrequired as thinking about it you should be able to calculate through the PID controller by simply working out the net torque on the ffb wheel by double integrating the rotational position change to get the rotational acceleration rate and you can then work out the net torque from that, then simply subtract the input torque from the ffb motor to work out the sim-drivers torque input. Feed the sim-drivers torque back to the sim and solve the net forces at the steering wheel at the net ffb/physics cycle and sent the ffb wheel it's next position target by by next ffb/physics cycle...rinse and repeat.)

In theory i agree but in practice it is not and can't be because with that order of input and output used, there is an inherent lag caused by this method and inherent under/overshoot problem that cannot be removed which causes problems like you've described to me. I'd really need to explain the differences in detail to show you how and why i think leo's alternative method is better. This isn't meant in a condesending way whatsoever but i was in you exact same shoes for a good few months thinking exactly as you do now until the pieces started to fit together over time and i began to understand what leo was saying and came to realise his logic was in fact correct (or at least i believe so...could be wrong ofc but i don't think i am).

It's very late here an i've got to get up early to help some friends out so i'll likely not reply until the evening.

 

If I hold the wheel still and the motor needs to apply 5 Nm of torque, how does it know when it has reached it's target?