View source for Logitech USB steering wheel

==Overview==

[[File:Logitech_wheel.jpg|240px|right|Logitech Wheel and Dongle, with optional BusPirate]]

The Logitech Speed Force Wireless Wheel system uses a USB dongle to connect to the wheel using a propriatory 2.4GHz wireless link. The wheel is intended to sit on one's lap and is powered by a 'wall wart'. The wheel has a 270 degree 'swing', has D pad plus 7 buttons on the front and 2 analogue paddles on the rear of the wheel for brake and accelerator.

Supported games are (reputed to be):
* F1 2009
* Speed Zone
* Dirt 2
* Need for Speed Undercover

This wheel is currently (Sept 2010) on clearance for less than $10, an obvious attraction to the hard-core hacker. This wheel is extremely similar to the PS2/PS3 Driving Force Wireless wheel, so the information is expected to apply to that too.

==Hardware==

The dongle contains a Cypress micro controller and nRF24L01 transceiver, the circuit is similar to [http://download.ourdev.cn/bbs_upload482478/files_14/ourdev_435383.jpg this].

The switch on the rear of the dongle is used to trigger a re-bonding, although the wireless link is not active until configured. The LED flashes initially to indicate 'not bonded' and then goes out when the link is established, it flashes briefly as data is received from the wheel.

The wheel hardware contains the nRF24L01, a ATMEGA micro, and a PWM/Full-bridge driver for controlling the motor. The micro scans the [[:File:Logitech_usb_buttons.pdf|buttons]] mounted on the wheel, digitizes the wheel/accelerator/brake positions and sends the data to the PC/Dongle.

==USB HID Joystick==

The dongle is a standard USB HID device. The feature port is used to configure the dongle/wireless link, the in-port reads data from the wheel and the out-port is used to send Force Feedback commands.

The dongle has the USB ID 0x046D:0xC29C, the HID descriptor is (unfortunately) corrupt. 

<code>
 05 01 09 04 A1 01 A1 02 95 01 75 0A 15 00 26 FF
 03 35 00 46 FF 03 09 30 81 02 06 00 FF 95 02 75
 01 25 01 45 01 09 01 81 02 95 0B 19 01 29 0B 05
 09 81 02 06 00 FF 95 01 75 01 09 02 81 02 05 01
 75 08 26 FF 00 46 FF 00 09 31 09 32 95 02 81 02
 C0 A1 02 06 00 FF 95 07 09 03 91 02 C0 0A FF FF
 95 08 B1 02 C0
</code>

Under Windows XP the device is seen as a HID device with a combined X/Y axis, Z axis and 11 buttons. Under Linux the device is seen as HID device with X, Y and Z axis, but no buttons.

The solution (on Linux) is to re-write the descriptor on the fly, after that the axis/buttons are recognized correctly (even though the wireless link is not active yet).
<code>
        if ((quirks & LG_WIIWHEEL) && rsize >= 101 && 
                        rdesc[41] == 0x95 && rdesc[42] == 0x0B &&
                        rdesc[47] == 0x05 && rdesc[48] == 0x09) {
                dev_info(&hdev->dev, "fixing up Logitech WiiWheel button "
                                "descriptor\n");
                rdesc[41] = 0x05;
                rdesc[42] = 0x09;
                rdesc[47] = 0x95;
                rdesc[48] = 0x0B;
        }
</code>

==Configuration==

The Wheel/Dongle are configured by writing to the feature port of the USB dongle. This allows the control of the 'on-air' features, such as initiating the wireless link, controlling the RF channel/hooping sequence and RF addressing (sub-channel coding).

When first plugged in the wireless link between the dongle and the wheel is not active, the link can be 'brought up' with writing the '0xAF Command' followed by the '0xB2 Command'.

The commands take some time to action, this can be confirmed by reading back the feature port, when the command completes the MSB of the first byte will be cleared. For most commands the same data that was sent is returned, some commands return different data.

; Configure RX/TX Address?
: Byte 1 - 0xA9
: Byte 2 - 2nd and 4th Address/Sub-Channel Bytes
: Byte 3 = 3rd and 5th Address/Sub-Channel Bytes
: Note 1st Sub-Channel byte is always 0xAE

; RF Test Mode
: Byte 1 = 0xAC
: Byte 2 = Test Mode
:: 0 - Normal Mode (LED flashes on/off as normal)
:: 1 - Constant TX (LED on), RF channel in 'P3' (can kill WiFi ;-)
:: 2 - Pulsed TX (LED flashes long-on/short-off)
:: 3 - Receive Only? (LED off), RF channel in 'P3'. Continually polls nRF24L01 status and clears
: Byte 3 - RF Channel/Frequency

; Initialise communications
: Byte 1 - 0xAF
: Byte 2 - Hopping Sequence (0x00..0x0F)

; Change RX/TX Address
: Byte 1 - 0xB2
: Byte 2 - 2nd and 4th Address/Sub-Channel Bytes
: Byte 3 = 3rd and 5th Address/Sub-Channel Bytes
: Note 1st Sub-Channel byte is always 0xAE

The following commands do not cause SPI activity to the nRF24L01

; Check Status?
: Byte 1 - 0xA8
: Returns RX/TX Address bytes in Byte 5 and Byte 6
: Returns whether the 'button' pressed in Byte 7 bit 5
: Returns something in Byte 7 bits 4..0 related to 'LED mode' (not a direct map)
: Returns something in Byte 8 which depends on Byte 2 sent

; LED Mode
: Byte 1 - 0xAA
: Byte 2 - changes the way the LED flashes, unknown what is actually happening

; Unknown
: Byte 1 - 0xAE
: Doesn't clear Byte 1 bit 7, like the other commands. Perhaps it is waiting for something...
: Returns 0x14 in Byte 5 and 0x00 in Byte 6

; Active Address?
: Byte 1 - 0xB3
: Only clears Byte 1 bit 7 if Command '0xAF' is issued first
: Returns values in Byte 5 and Byte 6 which are the values from Command '0xB2' Bytes 2 & 3

==Force Feedback==

There are a number of force feed back codes which can be written to the USB out-port, some of these are know/understood but assistance is required to further reverse engineer the rest.

Multiple effects can be active at any time, it would appear that multiple forces are added by the wheel up to the maximum force possible.

=== Commands ===

An effect can be written to one or more slots with a single write, the selected slot for an effect is encoded into the upper nibble 1st byte of the 'command'.

: 0x1_ : Slot 1
: 0x2_ : Slot 2
: 0x3_ : Slots 1 + 2
: 0x4_ : Slot 3
: 0x5_ : Slots 3 + 1
: 0x6_ : Slots 3 + 2
: 0x7_ : Slots 3 + 2 + 1
: 0x8_ : Slot 4
: 0x9_ : Slots 4 + 1
: 0xA_ : Slots 4 + 2 
: 0xB_ : Slots 4 + 2 + 1
: 0xC_ : Slots 4 + 3
: 0xD_ : Slots 4 + 3 + 1
: 0xE_ : Slots 4 + 3 +  2 
: 0xF_ : Slots 4 + 3 +  2 + 1

Other 'commands' are:
: 0x_0 : Turn off effect (although it still sends following bytes)
: 0x_1 : Set effect
: 0x_2 : Maximum force to the right
: 0x_4 : Change mystery byte to 0x03
: 0x_5 : Change mystery byte to 0x02
: 0x_C : Set effect
: 0x_E : Set simple Autocenter (strength and relative proportions)

=== Effects ===

The type of effect is encoded in the second byte of the out-port write, with specific settings for the effect in the further bytes. The upper nibble of the effect is OR'ed with 0x80 before it is transmitted, it doesn't appear that it makes any difference in the effect



; Constant Force
: Byte 2 - 0x_0
: Byte 3 - Force clockwise and anti-clockwise (0x00..0xFF - 00x00 is to right, 0x80 is zero force, 0xFF is to left)
: Byte 4..7 - No effect, set 0x00

; Auto/Anti Center (Complex) : This is similar to a spring force, but force is constant towards/away from angle points. Multiple of these can be stacked in different slots to emulate a spring and any angle.
: Byte 2 - 0x_1
: Byte 3 - Clockwise angle, nominally on left (0x00..0xFF - 0x00 is fully left)
: Byte 4 - Anti-Clockwise angle, nominally on right(0x00..0xFF)
: Byte 5 - L/R Proportion force, upper nibble clockwise + lower nibble anti-clockwise (each 0x0..0xF)
: Byte 6 - Reverse Direction; upper nibble clockwise + lower nibble anti-clockwise (each 0x0..0x1)
: Byte 7 - Force (0x00..0xFF)

; Friction Force
: Byte 2 - 0x_2
: Byte 3 - Clockwise force (0x00..0x0F)
: Byte 4 - Clockwise Resist = 0x00, Assist = 0x01..0x0F
: Byte 5 - Anti-clockwise force (0x00..0x0F)
: Byte 6 - Anti-clockwise Resist = 0x00, Assist = 0x01..0x0F
: Byte 7 - No effect, set 0x00.

; Auto/Anti Center (Complex) : Is this any different to '0x11'?
: Byte 2 - 0x_3
: Byte 3 - Clockwise angle, nominally on left (0x00..0xFF)
: Byte 4 - Anti-clockwise angle, nominally on right(0x00..0xFF)
: Byte 5 - L/R Proportion  force, upper nibble clockwise + lower nibble anti-clockwise (each 0x0..0xF)
: Byte 6 - Reverse Direction; upper nibble clockwise + lower nibble anti-clockwise (each 0x0..0x1)
: Byte 7 - Force (0x00..0xFF)

; De-associate : this is probably unintentional, the result of not correctly understanding the proper operation of the wheel.
: Byte 2 - 0x_F
: Byte 3, 4, 5, 6 & 7 - anything (set 0x00)


The 'simple autocenter' is not written to a slot, instead it has it's own special slot at the end of the data frame

; AutoCenter - fixed position spring, force gets stronger the larger the displacement
: Byte 2 - 0x_D
: Byte 3 - Proportion of force anti-clockwise (0x00..0x07)
: Byte 4 - Proportion of force clockwise (0x00..0x07)
: Byte 5 - Force (0x00..0xFF)
: Byte 6 & 7 - No effect, set 0x00

==On Air Data==

The Force Feedback configuration is sent continuously over the wireless link, which takes the form of a 31 byte payload. These are seen on the SPI bus as they are sent to the RF24L01 output buffer (register 0xA0). 

<code>
 [0xA0(0x0E)0x2F(0x00)0x1B(0x00)0x40(0x00)0x03(0x00)0x00(0x00)0x7D(0x00)0x00(0x00)0x00(0x00)0x00(0x00)0x00(0x00)0x00(0x00)0x00(0x00)0x00(0x00)0x00(0x00)0x00(0x00)0xFF(0x00)0x00(0x00)0x7F(0x00)0x7F(0x00)0x77(0x00)0x00(0x00)0x7F(0x00)0x00(0x00)0x00(0x00)0x00(0x00)0x00(0x00)0x00(0x00)0x00(0x00)0x33(0x00)0x5A(0x00)0xC0(0x00)]
</code>

The format is as follows:
: Bytes 1..2 - Negotiated SubChannel Address
: Byte 3 - Packet Ack 'dongle->wheel' (0x40 saw packet, 0x80 missed packet, 0x20 awaiting sync, 0x07..0x04 sync received, 0x10 sync now).
: Byte 4 - Unknown Mystery Byte (game logs show 0x00, can set to 0x02 and 0x03)
: Bytes 5..10 - Effect Slot 1
: Bytes 11..16 - Effect Slot 2
: Bytes 17..22 - Effect Slot 3
: Bytes 23..28 - Effect Slot 4
: Bytes 29..30 - Auto Center
: Byte 31 - Hopping RF Chanel Delta (0xC0 gives sequence 0x33, 0x13, 0x42, 0x22)

The Joystick data from the wheel is returned to the micro. These are seen on the SPI bus as reads from the input buffer (register 0x61).

<code>
 [0x61(0x40)0x00(0x00)0x00(0x04)0x00(0x00)0x00(0x00)0x00(0x77)0x00(0xFF)0x00(0xFF)]
</code>

The format is as follows:
: Byte 0 - 0x40 Flag showing data in receive buffer
: Byte 1 - 0x00
: Byte 2 - Lower bit of position?
: Byte 3 - button bit field
: Byte 4 - button bit field
: Byte 5 - Wheel position
: Byte 6 - Acc Paddle
: Byte 7 - Brake paddle

==Testing/Hacking==

A patch for enabling these wheels (with basic force feedback) is in the mainline kernel (2.6.37rc1 and above). For those using Debian/Ubuntu you can find a pre-built kernel and headers [http://www.mungewell.org/Logitech_Wii_Wheel/ here].

I managed to get some time on a Wii with Dirt2 and get some captures of the SPI traffic to the nRF24L01 ([http://www.mungewell.org/Logitech_Wii_Wheel/ get them here]). Fairly disappointing game, as they don't appear to be doing much in the way of FF.

Looking at the data structures, they seem to be using specific 'slots' for each effect:
* Slot 1 - Constant Force
* Slot 2 - Friction
* Slot 3 - Spring
* Slot 4 - <nothing>
* Auto-Center turned on at fixed throughout the whole of the game.

Apparently there is a port of LibUSB to Windows, it may be possible to produce a small application which would enable the wireless interface without the need to write a full Windows driver. Interestingly though the dongle/wheel remain bonded through a reboot, so the dongle can be enabled in Linux and then the wheel will work under XP (with the corrupted axis mapping).

[[Category:Peripherals]]