You need to install the drivers for FFB to work properly, just look for the version prior to G hub.
Last edited by rane_nbg, .
Hi, I would warmly recommend uninstalling G Hub, since it does your wheel no good. It is suited for mice, keyboards, and headphones with RGB lighting mostly. It has absolutely no available settings for the wheel itself.
Previous versions of drivers are much much better. I have G29 and I tried G Hub when it came out. I was happy that there was an update, but only for a short time. I got instantly disappointed in how crappy it is for the wheel and the lack of any settings the previous version had. Do not be fooled with new looks, there is nothing new in it for the G29/G920 in the firmware or FFB side of things.
I've heard from some guys who installed it that they even completely lost FFB in LFS.
Previous versions of drivers are much much better. I have G29 and I tried G Hub when it came out. I was happy that there was an update, but only for a short time. I got instantly disappointed in how crappy it is for the wheel and the lack of any settings the previous version had. Do not be fooled with new looks, there is nothing new in it for the G29/G920 in the firmware or FFB side of things.
I've heard from some guys who installed it that they even completely lost FFB in LFS.
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.
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.
Last edited by rane_nbg, .
LFSW name: rane_nbg
In-game name: AA™| rane
Full team name: Air Attack
Nation: Serbia
In-game name: AA™| rane
Full team name: Air Attack
Nation: Serbia
signup
LFSW name: rane_nbg
In-game name: AA™| rane
Full team name: AirAttack
Nation: Serbia
In-game name: AA™| rane
Full team name: AirAttack
Nation: Serbia
FGED GREDG RDFGDR GSFDG