I recently upgraded to a VRS direct force pro DD wheelbase, and I am having a strange issue that when the wheel turns to the right everything is normal, and when the car starts rolling the wheel wants to naturally go back to center. However if the wheel turns to the left just a tiny bit the FFB seems inverted and the steering wheel just goes straight full lock to the left and keeps going to the left.

I searched the forum and there was another user who had the same issue with Thrustmaster wheelbase, but he also said his issue was gong with a patch. My LFS is the latest version and it was running fine with my previous wheel a Fanatec CSL.

VRS team told me it could be that LFS is recognizing my wheelbase as a joystick rather than a wheel. I checked the CFG file but didn't find something particularly useful. Is there a way to fix that?

Bump... Still searching for a workaround...

I used to have this problem with a Thrustmaster base, but only managed to fix it by reinstalling windows. I have no idea why it happened or if there's a proper fix for it.

This sounds like a standard problem with wrongly choosing a signed or unsigned integer, which simply gets overflown.

example: a) int16_t, 16bit, -32767 to 32767 (0 center)
b) uint16_t, 16bit, 0 to 65535 (32768 center)

This is defined in the HID, or firmware of the device. Usually for wheel controllers, the steering axis is a signed integer, for example (a), where the raw value of 0 is a wheel center and this is used to calculate the FFB. In that case, bits 0 to 14 are the value, while the last bit15 is a sign. Giving this variable a value of 32768 will cause it to overflow and give a result of -32767. The same goes for an FFB magnitude value, which if not defined correctly may cause the same issue. The LFS is simply reading whatever is reported by the device in HID descriptor.

To check this, I would suggest you try one of the following programs capable of reading raw values from USB joysticks or wheels: DIView, DXTweak2
The best would be: WheelCheck which can generate FFB effects as well.

See attached pictures of DXTweak. For some reason, I got device names reversed while printscreen. My DIY Arduino wheel is -32k to 32k and Thrustmaster wheel is 0 65535 in X axis. Both wheels are working normally in LFS with the correct FFB.

Hej guys, another VRS DFP owner with the similar issue. I checked my wheel with DIview and this is what i get *(see attached). the "normal" data and raw data differ by half a measure, i guess this is what is confusing LFS. I tried playing with calibrations, but no success, only wierd results. What can be done?

Hi guys, after some time, I think I was able to replicate this issue on my homemade Arduino FFB wheel firmware.

The same behavior is happening if I enable 2 FFB axes (X and Y) in my firmware. LFS is only sending negative values of FFB, there are no positive values. However, if I reconfigure my firmware to only have 1 FFB axis (X only) all is fine.

The weirdest thing is that my Thrustmaster T300RS has 2 FFB axes defined in its firmware and it still works normally in LFS.

I do not know if this will help anyone but I just wanted to share my findings.

Interesting, thanks rane! The VRS guys havent looked into this yet, but maybe there is an easy workaround, maybe turning one axis off in the ffb tweaks. ill teport back when i get a chance to test.

It really needs to be done in the PID descriptor part of the firmware, which defines the number of FFB axis and other properties. If VRS guys didn't make this configurable, there is nothing you can do from the outside.

A good example of this is done by guys that are developing openFFB firmware, where you can select up to 3 FFB axes from their configurator software. Maybe in the future, they are able to reconfigure their firmware for wiring to be the same as in mmos, then you would be able to just upload openFFB firmware in your hardware and have it working.

https://hackaday.io/project/163904-open-ffboard
https://github.com/Ultrawipf/OpenFFBoard

Another update, I tested openFFB firmware on stm32F407 microcontroller.

I could replicate the same issue by selecting only 1 FFB axis in their configurator. LFS would only send one-sided FFB. If however, I set 2 FFB axis, LFS had no problems with that and FFB was correct, with both sides. Seems quite opposite to what I have in my Arduino FFB firmware, but it does not matter. I guess that this pinpoints the issue for developers of both FFB wheels and LFS.

This is an interesting topic, as I am looking to invest in a VRS set (base + pedals).
Has anybody (devs included) sorted this out?
Or is it better if I stay away from the setup, despite it being reasonably affordable and with great performance?

Thanks

well, as it is now, the devs did nothing to solve this problem yet, but the plan is to start working on new physiscs, so ffb interface might be revisited and you may be able to use that wheel in lfs

Hi guys, I just wanted to bump this thread since I found what was the cause of this problem and was able to fix it by adding one line of code in my Arduino FFB wheel firmware. However, the problem is in how LFS handles the FFB protocol and there is one small issue there.

The problem only occurs on FFB devices that report 2 or more FFB axis via HID descriptor. A constant force effect (the only FFB effect that LFS is using) is always sent to the wheel as 2 parameters. One is the magnitude of the force and another is the direction. I have checked, LFS does correctly send one more piece of information when doing the Set Effect Report and that is the axisEnable byte. The 3rd bit of this byte (value of 0x04) is representing direction enable information, which tells the FFB device to also include direction value in force calculation. If this is not implemented in the device firmware, then calculated constant force will only have positive values because the magnitude is always positive and direction value which is a force sign in this case is neglected. As a result, you get one-sided FFB on your wheel. A device is allways reporting the logical and physical ranges for each parameter of FFB effect. If a device reports the magnitude for CF effect to have range of -10000 to 10000, then a game should use it always in the full range, regardless of how many FFB axis are reported. Some recently apeared FFB wheel manufacturers, even if this is a 1 FFB axis device, just copy pasted the HID descriptor for Microsoft Sidewider Joystick which has 2 FFB axis, and forgot to implement the direction into calculation. In principle LFS does send all required information and that is why I was able to adapt my fimrware for it, but I doubt that any new manufacturers in the direct drive FFB wheel market will do this.

I propose the following solution that Scawen has to implement in LFS's FFB protocol if he wants to expand the support for practically all DirectInput devices including most of the commercial FFB wheels and FFB joysticks.

Solution - when you do the Set Effect Report for constant force effect, send both positive and negative magnitudes for this effect (use a full range that the device reported) and change the axisEnable byte to 0x01, to indicate usage of only the X-FFB axis to the device.

for reference, I provide a piece of my code for the FFB protocol (that follows the DirectInput documentation from Microsoft), where one can see all the parameters that an application has to communicate with the FFB device when setting up any FFB effect.

Thank you for this. I am trying to get my head around it but I'm not quite there yet!

I have the following code, which is copied from example code and edited a bit. I can't find any mention of axisEnable.

Here is a link where I've found a version of the original example code, posted by Chuck Walbourn:
https://github.com/walbourn/directx-sdk-samples/blob/main/DirectInput/FFConst/ffconst.cpp

See the function at the bottom "SetDeviceForcesXY" - when setting cf.lMagnitude it results in the same as my abs(nXForce).

So I'm a bit torn here as I'm reluctant to diverge from the proper way of doing things, to try to somehow make LFS compatible with bugged wheel drivers. It seems that something could go wrong. But I realise my understanding is incomplete.

LFS code:

Dear Scawen, thank you very much for taking the time to understand this issue, I appreciate it very much. For more details, I have attached a reference document from Microsoft that deals with PID part of HID descriptor which is implemented on the device side (FFB wheel), but the application has also to follow this protocol.

To save you some trouble, you can have a quick look through pages 6-10 and page 44.

Looking at your code, I can see that your struct DIEFFECT eff; is missing some parameters. Have a look at page 35 for "Set effect output report". There is no need to implement all of them, but byte 9 is the AxisEnable byte. The interesting thing is that LFS does send this byte correctly and sets it for 2 FFB axis devices at 0x04 (bit2 = 1 -> direction enable) and also for 1 FFB axis devices to 0x01 (bit0 = 1 -> X axis enable).

In principle fast fix is simply:
cf.lMagnitude = abs(nXForce); -> cf.lMagnitude = nXForce;

If you have any questions about this please ask, I spent the last 4 years of my life reading through this stuff while developing firmware for Arduino FFB wheel.

OK I think I have a solution. Luckily I have an old FF joystick to test.

I tried your proposed fast fix: abs(nXForce) -> nXForce

But that doesn't work properly - it resulted in reverse force when steering left.

So I tried keeping the change you suggested but also set the direction to 'right' always. This seems to work.

CODE:

This seems to have the same result on the FF joystick and I guess it would work on your wheel.

The fix is available for testing in Test Patch C4: https://www.lfs.net/forum/thread/98309

my lord.. This was driving me nuts trying to run the 7A patch because of lazy compatibility.. I suppose this is goodbye for good lazy at least now I know my wheel isn't broken

Quote from Silvio Tavares :

my lord.. This was driving me nuts trying to run the 7A patch because of lazy compatibility.. I suppose this is goodbye for good lazy at least now I know my wheel isn't broken

What do you miss from LFSLazy that isn’t available in other InSim apps or in LFS natively?

Quote from Flame CZE :

What do you miss from LFSLazy that isn’t available in other InSim apps or in LFS natively?

I'm not aware of other apps that do that sort of thing. Can you give me directions please? Natively I miss the race order and gaps to other drivers the way it is displayed on Lazy.. I miss other info like PB, delta, engine damage, laps remaining for the fuel load, max speed for each gear in setup.. what I can think of from the top of my head.

I was getting sorted to join FM's events and they host the 7A patch on their servers because of lazy I believe..

Help me with those other apps m8

bar the race order, detect & monitor does all that.
it doesn't work with test patches though but does with 7D

and yes, you're correct FM along with MRc host 7A servers preceisely because of Lazy

Quote from johneysvk :

bar the race order, detect & monitor does all that.
it doesn't work with test patches though but does with 7D

and yes, you're correct FM along with MRc host 7A servers preceisely because of Lazy

thanks m8.. I haven't driven LFS for a few months so I've missed all this recent development. I'm learning this stuff just now.

Quote from Silvio Tavares :

I'm not aware of other apps that do that sort of thing. Can you give me directions please? Natively I miss the race order and gaps to other drivers the way it is displayed on Lazy.. I miss other info like PB, delta, engine damage, laps remaining for the fuel load, max speed for each gear in setup.. what I can think of from the top of my head.

I was getting sorted to join FM's events and they host the 7A patch on their servers because of lazy I believe..

Help me with those other apps m8

Engine damage, laps remaining for fuel, max speed for each gear in setup is now available in LFS if you use the test patch:

Quote :

Changes from D to D21:

New display in F9 / F10 views shows estimated laps given fuel use
Engine health (with colour code) is displayed in F9 / F10 views
F9 / F10 extra displays are now switchable (Options - Display)
Speed at redline is displayed beside each gear ratio in setup

Quote from Flame CZE :

Engine damage, laps remaining for fuel, max speed for each gear in setup is now available in LFS if you use the test patch:

thanks a million brother! Will definitively check it out