And now for the Wheel...

[ej113]

So I've been playing Assetto Corsa (AC) with the gameport Sidewinder Wheel and full force feedback function!

I set myself the goal of getting it working in AC to start with for a number of reasons:

• AC has very good force feedback despite only using a very limited repertoire of force feedback effects and effect updates. It uses damper when stationary which fades out at ~10km/hr and then only constant force above this.
• The streaming of constant force from the physics engine at up to 333Hz is a real test of the adapter & wheel capabilities.
• It has a similar force feedback implementation to a number of other racing sims/games. There's a good chance the same minimal implementation will also work in Assetto Corsa Competizione, iRacing, some of the F1 series and KartKraft based on evidence from this list and this thread, but only if they are using exactly the same set of DirectInput commands.
• Early games with force feedback (like Need For Speed III) tend to use layered "canned" effects with a wider variety of DirectInput effects and parameters, rather than just streaming forces. These will take more effort to get working.
• Finally my aging PC just about meets the minimum spec!

I only had to implement the commands for:

• constant force with a variable signed magnitude, adjustable on-the-fly
• damper with variable positive and negative coefficients, adjustable on-the-fly

But I also got working, because it was straightforward:

• Spring and inertia with variable positive and negative coefficients - these effects have the same formulation as damper
• All device control commands
• Device gain

The framework for SysEx handling, effect modification and effect control commands for the wheel were already written by Skoo. Also effect duration. Not to mention that It wouldn't have been possible to get this far without his notes in the Wiki and the DescentBB thread, since I don't have a Win98 PC with gameport.

The one puzzle I had to solve was in understanding the bit flag 0x00/0x40 which Skoo referred to as a "Default" indicator. It turns out this is not optional and is actually related to the checksum. If (256 < sum of all bytes <=384) then 0x40 else 0x00. This took me quite a while to figure out and sent me off on the wrong track a few times, since some effect modifications would work and some formulated the same way would not. I do not know why Microsoft made it this way. My best guess is that it was a fudge to avoid interfering with other MIDI devices, but it may just be obfuscation…

Device Control and Device Gain

These are the only other additions to record for now since everything else I've used is consistent with the wiki.
0xf3 0x1d Reset (stop all effects; free all effects; reset device gain to 0x7F; enable actuators; enable auto spring centre)
0xf3 0x2e Enable actuators
0xf3 0x3f Disable actuators (but time stepping continues for effects)
0xf3 0x48 Pause (time stepping is paused)
0xf3 0x59 Continue (resume paused effects)
0xf3 0x6a Stop All (including stop auto centre)

The last nibble is checksum from xor'ing the first 3 nibbles. Note 4 and 5 are swapped relative to the joystick.

Device Gain is a 6 byte 0xF1 modify message form with effect id = 0x00, address 0x-0 and value 0x00 to 0x7f in the LSB. e.g. 0xf1, 0x10, 0x40, 0x00, 0x7f, 0x00 for max gain

USB Descriptors, Axes and Buttons

I have not fiddled much with the descriptors to change the axes/buttons etc. I have fixed the report outputs so the FORCE toggle does not show up as a button and there are no spurious hat switch outputs. There is a bug not yet fixed that means the descriptors have to be the same number of bytes for the joystick and wheel so not much scope to customise this at present. This may result in compatibility issues with some games that aren't very flexible with controller assignments.

At last some firmware:

I've put four firmware files here, options for both Teensy and Micro, with and without virtual serial port logging. These are alpha1 version since I've not done extensive testing. I'm also thinking to keep this out of the main repo until there is a good hardware solution for the backpowering issue #49.

See here for Teensy wiring and note for Micro/Pro Micro PB6 is swapped for PB0.

If you pick a LOG version you will always need to have a terminal open to the COM port as per #50. You will be able to record the force feedback messages being received and sent over USB and MIDI. Performance doesn't seem to be noticeably worse.

In AC I needed to tick the "Half FFB Update Rate" box because the adapter doesn't seem to handle the default update rate of 333Hz. You get a "99% CPU Occupancy" warning in the game when it is not keeping up.

There are guides around on how to configure AC FFB for old wheels. I set steering gamma to 1.5 for stability with the limited rotation.

And a Warning:

I believe there is potential to damage the Atmega or even the wheel if the adapter is connected to a powered wheel without usb power. See #49. So far mine have survived despite several prolonged periods in this condition. USE AT YOUR OWN RISK

Observe the following connection sequence:
Pedals can be connected at any point

1. Connect usb cable to adapter and check board LED is flashing ~3 times a second
2. Connect 12V power to wheel and wait for it to complete the initialisation - wheel stops turning. If you connect to adapter too early the wheel will be off centre.
3. Connect gameport plug to adapter. You should then get solid LED until the USB "ping" and the LED turns off.

When stopping, always remove 12V power before USB. I recommend not leaving 12V power attached in case your PC stops providing USB power.

Next Steps

In order to get to a more complete PID implementation like for the joystick it would be necessary to understand how to translate the formula for spring/damper/inertia effects from coefficients, saturations, deadband and offset, into the different representation in the wheel MIDI effects.

There are a few other unknown parameters to discover. Does the wheel have e.g. an explicit effect gain or triggerbutton?

There is a mystery modify message sent by the drivers after each effect is defined by SysEx e.g.
f1 01 0e 02 7f 7f for periodics. This isn't essential to get effects to play. Perhaps it exposes some additional parameters?

I'm intending to record any further developments on wheel FFB in this thread.

[You69Man]

That' great news! I dug out my steering wheel, put it back together with my teensy breadboard that I built a few years ago, and tried two old forcefeedback test programs, WheelCheck.exe and ForceTest.exe. And voila - the device is recognized as "LUFA Wheel wFBB".
And there is actually some force feedback effects working, at least much more than with the version that i had back then!

I'd like to do some more experiments, maybe try some real game. Can you recommend programs or some free game for testing? I don't want to buy a game as long as I don't know if I will be happy with it. 25 years ago my favority game was Sega Rally in Windows 95, but I'm afraid there is no chance for a revival of this great game, not even on Steam or on an emulator...

[ej113]

Glad it's working for you. As I said it is really a very limited implementation "proof of concept" targeted at one game and with the possibility that others have near identical force feedback implementations. Keys for Assetto Corsa are pretty cheap these days, but it is a sim more than a game. (I have no particular preference but it was the way to get the most complex force feedback with the least effort on the firmware). It won't behave correctly with older or arcade style games that make more use of canned effects rather than try to simulate the physics.

Re: Sega Rally, it looks like there are people who have got this working with modern FF wheels...

[ej113]

For three of the conditional effects, Spring, Damper and Inertia (but not Friction), the response curve in MIDI is set using four pairs of coordinates (xi, yi), with one byte per value. The default is 0x007d 0x3e3f 0x3e3f 0x7d00. This corresponds to a linear response to position, velocity or acceleration respectively:

A position of 0x3f = 63 appears to be about centered
A force level of 0x3f = 63 seems to be about neutral i.e. zero force applied by the motor.
I'm not sure whether it is more correct to use the full range of values to 0x00..0x7f rather than ..0x7d. Perhaps the original drivers were rounding or it was intentionally reduced. 0x7f works as you would expect but it's difficult to tell whether it results in any more force than 0x7d.

Positive and negative coefficients, saturation, offset and deadband can be altered with the coordinates.
e.g. 0x1450 0x2f3f 0x3f0x3f 0x6b1b

Extrapolation is flat so that e.g. position inputs below x1 result in a constant force of y1. So the curve shown above saturates.

By manipulating the coordinates a variety of effects can be generated that are not supported in the USB standard. For example a wall effect where the force goes from zero to maximum over a very short travel.

This doesn't reflect any recent work, but something I figured out a while ago and hadn't got round to appending here. If I recall, most of the remaining parameters are well explained in the Wiki and worked when I tested them. I don't think there are any significant further unknowns to complete an implementation to the same level as the joystick.

[kalimahhh]

Hi, I don't know basically nothing about coding but I would like to start playing with my wheel that I own since I bought it 98 or something... I Would like to help in some way giving some feedback on the firmware.
Should I buy a teensy 2.0 to start and follow the diagram? Thanks for the effort!
I don't want to to throw my sidewinder wheel in the garbage!...

[ej113]

Feedback is welcome although note the scope of the wheel implementation is limited so far!

I would suggest USB-C Pro Micro or perhaps Adafruit Itsy-Bitsy 32u4 - 5V 16MHz rather than the Teensy 2.0 unless you have one already, since clones of the Teensy won't have the original proprietary bootloader. But you will need to pay attention to the pinout. There is a wiring diagram for the Pro Micro in this repo https://github.com/juchong/adapt-ffb-joy

[BrainRadioactivity]

Just wanted to comment that i tried Asseto Corsa with your new patch and it worked perfectly. It's so wonderful to see my old wheel alive again on a recent OS. I had the exact same experience you described, with needing to set "Half FFB Update Rate" to avoid the "99% CPU Occupancy" warning, but otherwise a very pleasant experience in the game.

I'm gonna keep an eye on this topic, just know that your work is very appreciated ! If you need anything (beta testing, ...), just ask.

[You69Man]

I also want to report, that I'm using Teensy 2.0 with the alpha1 binary successfully with Asseto Corsa now, after I have recognized that I need to tick the "Half FFB Update Rate" option! Otherwise my PC had a total hang up.
Is there already any experience with WRC 9?
Thanks again to all who still support our old wheel! Mine is 26 years old meanwhile, and I'm very happy that I kept it so long!

PS: @ej113 Can you tell me which branch/commit in your repo was the base for the alpha1 binary (I guess it's been the micro_pinout_wheeltest2_LOG, right?)?
And is there any chance for a newer version?