Reverse Engineering the Force Feedback Pro

[Reaper36]

I used logic analyzer/scope to capture Button1-4 and X1 signals from Sidewinder Force Feedback Wheel while Control Panel -> Game Controllers -> Properties -> Test tab was open in Windows XP.

Great job!
Since you have the right equipment for the job I guess I can stop messing around with my approach.
Would be amazing if you could try to record the force feedback communication too.

[skoo]

FF Wheel Initialization sequence when starting FEdit:

Signals in pictures from top to bottom: X1, midi, B4, B3, B2, B1

Delays between 330us X1-pulses (pulse, 31.6ms delay, pulse, 17.2ms delay...) :

First pulse:

31.6ms delay, then second pulse:

17.2ms, delay, followed by 5 pulses:

88us, 88us, 88us, 88us, 668us,
Then another 5 pulses (shown also partially in previous image):

236us, 88us, 128us, 88us,

101.6ms delay, then 2 midi bytes are sent (31250Hz, 1 start bit, 1 stop bit, least significant bit first):

0 11001111 1 (f3)
0 10111000 1 (1d)

Then midi line goes idle ("1"). After 64us, 5 X1-pulses are sent with following delays:
(NOTE: X1 scope signal and Button signals are not in sync in the picture, either bitscope bug or "feature")

88us, 392us, 88us, 88us

Then X1-pulses stop and finally following midi bytes are sent:

f1 0e 43 01 00 7d
f1 7e 04 01 3e 4e
f1 1c 45 01 3e 2f
f1 0b 46 01 7d 00
f3 1d
f1 10 40 00 7f 00
f3 6a

Following midi bytes are sent when closing FEdit:

f3 1d

FEdit effects seem to work with wheel the same as with FFP (by quick look the midi commands are same when FFP or FFPW is connected).
The exception is that I have to add two rows of effects to the editor as the first row is ignored by the wheel. Assuming the first row goes for non-existing axis.

[cal]

101.6ms delay, then 2 midi bytes are sent (31250Hz, 1 start bit, 1 stop bit, least significant bit first):

0 11001111 1 (f3)
0 10111000 1 (1d)

[...]

f1 0e 43 01 00 7d
f1 7e 04 01 3e 4e
f1 1c 45 01 3e 2f
f1 0b 46 01 7d 00
f3 1d
f1 10 40 00 7f 00
f3 6a

Following midi bytes are sent when closing FEdit:

f3 1d

The MIDI does seem to be quite different from FFP. FFP only used MIDI commands A, B, C on channel 6 (e.g. 0xA5, 0xB5...) and "SysEx" F0..F7 for transferring effects data.

But for the Wheel, F3 1D and F3 6A seem valid MIDI commands, but are different than FFP as it uses C5 i.e. "Program Change" instead when switching e.g. FEdit to foreground/background. That 0xF3 is "Song Select" in MIDI . The MIDI initialization sequence seems quite different too. For more detailed comparison, the most detailed FFP MIDI data is of course in the source code https://code.google.com/p/adapt-ffb-joy ... runk/ffb.c.

So, you just now need to record all the sequences and deduce what each part means. The initialization sequences, switching application sequences etc. are most likely static data that needs little explanation but only copying. For effects control, you need to understand the content more closely as we need to map USB-effects data into that MIDI porridge. In order to understand what is what and what belongs together, a brief intro to MIDI protocol might help. Google is happy to find you abundant articles on that.

However, those lines starting with 0xF1 worry me a little. They break the MIDI protocol, that in FFP was quite closely followed (well, as closely as any MIDI manufacturer seems to do). Are you sure about the interpretation of the bits there? It would seem odd that MS would follow MIDI on FFP, and even in the Wheel, but not quite so that it might break. Or maybe that 0xF1 (a timing related MIDI message) follows a different standard than I've looked at as it normally should only have one byte parameter following.

[skoo]

I Built 31250 -> 115200 UART "bridge" (midi -> stm32f0 uart2 -> stm32f0 uart1 -> ftdi -> PC) for getting the data.
Wheel works normally by adding single effect, previous problems were probably caused by long cables to logic analyzer.

The initialization data is the one I previously posted, here is midi data for wheel init, effects and shutdown:

Code: Select all

init
f3 1d f1 0e 43 01 00 7d f1 7e 04 01 3e 4e f1 1c  ó.ñ.C..}ñ~..>Nñ.
45 01 3e 2f f1 0b 46 01 7d 00 f3 1d f1 10 40 00  E.>/ñ.F.}.ó.ñ.@.
7f 00 f3 6a                                      .ój            

square
f0 00 01 0a 15 20 03 7f 65 12 00 7f 00 40 7f 00  ð.... .e...@.
00 7f 65 12 7f 74 03 3e 7f f7 f1 01 0e 02 7f 7f  .e.t.>֖...
f2 2d 02                                         ò-.             

stop
f2 3c 02                                         ò<.             

delete effect
f2 1e 02                                         ò.. 

sine
f0 00 01 0a 15 20 02 7f 65 12 00 7f 00 40 7f 00  ð.... .e...@.
00 7f 65 12 7f 74 03 3e 00 f7 f1 01 0e 02 7f 7f  .e.t.>.֖...
f2 2d 02                                         ò-.             

triangle
f0 00 01 0a 15 20 04 7f 65 12 00 7f 00 40 7f 00  ð.... .e...@.
00 7f 65 12 7f 74 03 3e 7e f7 f1 01 0e 02 7f 7f  .e.t.>~֖...
f2 2d 02 

sawtoothup
f0 00 01 0a 15 20 05 7f 65 12 40 7f 00 00 7f 00  ð.... .e.@...
00 7f 65 12 7f 74 03 3e 7d f7 f1 01 0e 02 7f 7f  .e.t.>}֖...
f2 2d 02  

sawtoothdown
f0 00 01 0a 15 20 05 7f 65 12 00 7f 00 00 7f 00  ð.... .e.....
00 7f 65 12 7f 74 03 3e 3d f7 f1 01 0e 02 7f 7f  .e.t.>=֖...
f2 2d 02

spring
f0 00 01 0a 15 20 08 7f 65 12 00 00 7d 3e 4e 3e  ð.... .e...}>N>
2f 7d 00 6f f7 f1 07 08 02 7f 7f f2 2d 02        /}.o÷ñ...ò-.  

Friction
f0 00 01 0a 15 20 0b 7f 65 12 00 7e 61 f7 f1 0a  ð.... .e..~a÷ñ.
05 02 7f 7f f2 2d 02   

damper
f0 00 01 0a 15 20 09 7f 65 12 00 00 7d 3e 3f 3e  ð.... .e...}>?>
3f 7d 00 6d f7 f1 07 08 02 7f 7f f2 2d 02        ?}.m÷ñ...ò-.  

intertia
f0 00 01 0a 15 20 0a 7f 65 12 00 00 7d 3e 3f 3e  ð.... .e...}>?>
3f 7d 00 6c f7 f1 07 08 02 7f 7f f2 2d 02        ?}.l÷ñ...ò-.  

shutdown
f2 1e 02 f3 1d b0 40 00 b1 40 00 b2 40 00 b0 40  ò..ó.°@.±@.²@.°@
00 b0 78 7f b0 7b 7f b1 40 00 b1 78 7f b1 7b 7f  .°x°{±@.±x±{
b2 40 00 b2 78 7f b2 7b 7f b3 40 00 b3 78 7f b3  ²@.²x²{³@.³x³
7b 7f b4 40 00 b4 78 7f b4 7b 7f b5 40 00 b5 78  {´@.´x´{µ@.µx
7f b5 7b 7f b6 40 00 b6 78 7f b6 7b 7f b7 40 00  µ{¶@.¶x¶{·@.
b7 78 7f b7 7b 7f b8 40 00 b8 78 7f b8 7b 7f b9  ·x·{¸@.¸x¸{¹
40 00 b9 78 7f b9 7b 7f ba 40 00 ba 78 7f ba 7b  @.¹x¹{º@.ºxº{
7f bb 40 00 bb 78 7f bb 7b 7f bc 40 00 bc 78 7f  »@.»x»{¼@.¼x
bc 7b 7f bd 40 00 bd 78 7f bd 7b 7f be 40 00 be  ¼{½@.½x½{¾@.¾
78 7f be 7b 7f bf 40 00 bf 78 7f bf 7b 7f        x¾{¿@.¿x¿{  

Also FFP data captured with the same system (c5 01.. so the capture is working correctly):

Code: Select all

Init
c5 01 f0 00 01 0a 01 10 05 6b f7 b5 40 7f a5 72  Å.ð......k÷µ@¥r
57 b5 44 7f a5 3c 43 b5 48 7f a5 7e 00 b5 4c 7f  WµD¥<CµH¥~.µL
a5 04 00 b5 50 7f a5 02 00 b5 54 7f a5 02 00 b5  ¥..µP¥..µT¥..µ
58 7f a5 00 7e b5 5c 7f a5 3c 00 b5 60 7f a5 14  X¥.~µ\¥<.µ`¥.
65 b5 64 7f a5 7e 6b b5 68 7f a5 36 00 b5 6c 7f  eµd¥~kµh¥6.µl
a5 28 00 b5 70 7f a5 66 4c b5 74 7f a5 7e 01 c5  ¥(.µp¥fLµt¥~.Å
01 b5 7c 7f a5 7f 00 c5 06                       .µ|¥.Å.       

Square
f0 00 01 0a 01 23 05 7f 65 12 00 00 00 00 7f 64  ð....#.e.....d
00 10 4e 7f 00 00 7f 65 12 7f 01 00 7f 00 01 01  ..N..e......
2b f7 b5 20 02                                   +÷µ .           
b5 10 02

Inertia                                         µ..             
f0 00 01 0a 01 23 0f 7f 65 12 00 00 65 00 65 00  ð....#.e...e.e.
00 00 00 00 0e f7 b5 20 02                       .....÷µ .       
b5 10 02

Shutdown
c5 01 c5 07 b0 40 00 b1 40 00 b2 40 00 b0 40 00  Å.Å.°@.±@.²@.°@.
b0 78 7f b0 7b 7f b1 40 00 b1 78 7f b1 7b 7f b2  °x°{±@.±x±{²
40 00 b2 78 7f b2 7b 7f b3 40 00 b3 78 7f b3 7b  @.²x²{³@.³x³{
7f b4 40 00 b4 78 7f b4 7b 7f b5 40 00 b5 78 7f  ´@.´x´{µ@.µx
b5 7b 7f b6 40 00 b6 78 7f b6 7b 7f b7 40 00 b7  µ{¶@.¶x¶{·@.·
78 7f b7 7b 7f b8 40 00 b8 78 7f b8 7b 7f b9 40  x·{¸@.¸x¸{¹@
00 b9 78 7f b9 7b 7f ba 40 00 ba 78 7f ba 7b 7f  .¹x¹{º@.ºxº{
bb 40 00 bb 78 7f bb 7b 7f bc 40 00 bc 78 7f bc  »@.»x»{¼@.¼x¼
7b 7f bd 40 00 bd 78 7f bd 7b 7f be 40 00 be 78  {½@.½x½{¾@.¾x
7f be 7b 7f bf 40 00 bf 78 7f bf 7b 7f           ¾{¿@.¿x¿{   

[cal]

Ok. It is so then. Is suspect MS had fixed one user complaint in using 0xFn-MIDI-commands in the Wheel. There were complains from FFP users, that their MIDI musical instruments (e.g. a drum machine) went berserk when they played a game with FFP connected. Which is understandable as FFP used "musical commands" as its control commands. Now in the Wheel, looks like all effect control is now using only these 0xF1, 0xF2, 0xF3 etc. series commands that are considered as "non-musical commands". I would expect this to have helped life of the people with other MIDI-devices connected as they could now leave them on when playing a game.

So. To continue with the command analysis, we can safely assume that even the Wheel conforms to some form of MIDI messaging standard. This helps us to identify the commands and parameters from the binary mess.

You can now assume that all commands start with bytes that have high-bit on. I.e. all those 0xFx:es start a new command. E.g.

The initialization data is the one I previously posted, here is midi data for wheel init, effects and shutdown:

Code: Select all

init
f3 1d f1 0e 43 01 00 7d f1 7e 04 01 3e 4e f1 1c
45 01 3e 2f f1 0b 46 01 7d 00 f3 1d f1 10 40 00
7f 00 f3 6a

has multiple commands in it. I'll break them down on each line

Code: Select all

f3 1d
f1 0e 43 01 00 7d
f1 7e 04 01 3e 4e
f1 1c 45 01 3e 2f
f1 0b 46 01 7d 00
f3 1d
f1 10 40 00 7f 00
f3 6a

and as you can see, we always get the same amount of parameter bytes on each command, which is now comforting in that we are able to understand the "language" bit better. 0xF3 always has one byte parameter. 0xF1 has always 5 bytes of parameter data. 0xF2 has 2 bytes of parameters. Good to see some consistence there.

Then, to understand the parameter bytes, we know from MIDI that they cannot use the high bit. In order to represent numbers larger than 7-bits, they need to be spread to multiple parameter bytes and only using 7 bits from each byte. I.e. with two parameter bytes, we can express 14-bit numbers. In FFP, a "14-bit unsigned int" was calculated with formula simply

Value = Byte1 + Byte2 x 128

and so then a "14-bit signed integer" had values 0x7F00 = +max, and 0x0101 = -max.

I also noted, that in some 14-bit unsigned integer fields, 0x0000 marks infinity.

That "sine" sample (broken down into a command per line)

Code: Select all

f0 00 01 0a 15 20 02 7f 65 12 00 7f 00 40 7f 00 00 7f 65 12 7f 74 03 3e 00 f7
f1 01 0e 02 7f 7f
f2 2d 02

seems to match FFP's use of SysEx (0xF0..0xF7) for sending effect data, but with slightly different header "00 01 0a 15 20" - which is expected as the header indicates the device manufacturer and product IDs for who the given SysEx-command is meant for. After the header, it looks like we have the wave form (byte) 0x02 = sine as in FFP. Then, I'll stop the guess work as the number of bytes won't match the FFP's format. But it is very much likely that as you change each parameter one by one and check what changes in the reports, you can construct a similar table for the Wheel's effects data as we have on the adapt-ffb-joy's MIDI-wiki-page for FFP. I would expect you to find very similar number formatting and some padding bytes there.

About that 0xF2-command. Looks like it controls the effects, as you already noted. First parameter byte seems to be the "command" (e.g. store, delete, start, stop...) and the second is likely to be the index number of the effect. In all your samples, all effects were stored to index 2, but if you would send multiple effects simultaneously, you should see 0x03, 0x04 and so on there respectively. So, my guess is that the sequence "F2 2D 02" means "store the previously sent effect data to effect index 2". And that "stop"-sample "F2 3C 02" could be spelled out as "stop the effect at index 2".

And so on. Now you should find out what effect parameter of each wave form in FEdit is stored in what offset (and in what number type; uint7, int7, uint14, int14...) of the effect data in 0xF0-messages to the Wheel. Get ready for several hours of grinding with pure brute force I hope the above (and the FFP's tables in wiki-page and in that ffb.c-source file) will shorten that task a bit as you should now know what to look for.

We are still missing at least one command. When you modify an effect on-fly, i.e. when it is already playing (e.g. amplitude or frequencey of a sine wave form effect), there should be yet a different command and its parameters for each effect parameter change. It is likely some form of "0xFn + some command + parameter ID/offset + value" and it may contain some padding to accommodate variable effect parameter sizes in a fixed size MIDI-command.

[Scanjo]

The FFB board I am building is now confirmed to work with the 3DP. Grendel says that if it works with the 3DP then it will work with the 3DP Plus as well. I'm taking no chances. Once burned, twice shy. I'm sending a board out to one last tester with a 3DPP to confirm it. I'll start sending boards out to people who have ordered for the FFP, PP, and 3DP again now. I'll post again when the 3DPP is confirmed.

Thanks,
Scott

[skoo]

Basic structures of midi commands (f0, f1 & f2) for sidewinder ff wheel.

f2 command (playing, stopping and deleting existing effect). Always 3 bytes:

Code: Select all

f2
ec          (e) effect command 0x20=play, 0x30=stop, 0x10=delete
            (c) xor checksum of all nibbles.
ii          effect index

example f2 1e 02:

Delete (1) effect index 02. xor of all nibbles f^2^1^e^0^2 = 0. (calculated checksum e = f^2^1^0^2)

f1 command (storing new effect, modifying attributes of stored effects). Always 6 bytes:

Code: Select all

f1
xx         checksum of all bytes, omitting 6th bit (0x40) of attribute byte			
da         default indicator (0x00 when value is default, 0x40 otherwise) | attribute
ii         effect index
nn nn      14-bit value LSB, MSB (some attributes use only LSB, MSB=0)

example f1 1e 40 02 68 07:

Modify duration (0) of effect index 0x02, new value = 68 07 = 0x3e8 = 1000*2ms = 2000ms.
(f1 + 1e + (0x40 & ~0x40) + 02 + 68 + 7) & 0x7f = 0x00.
calculating checksum: (0x80 - (0xf1+(0x40 & ~0x40) + 0x02 + 0x68 + 0x07)) & 0x7f

example f1 01 0e 02 7f 7f: store (e) effect to index 02 (previous command must be 0xf0 for creating the effect).

f0 command for creating effects, common for all effects:

Code: Select all

f0                effect start
   00 01 0a 15 20 header
   xx             effect type
   7f             always 7f
   xx xx          duration in 2ms increments. 14-bits LSB MSB
   xx             direction, not used for all effects
   ...            effect data, content & length depends on effect type
   xx             checksum
f7

example f0 00 01 0a 15 20 08 7f 6e 1e 00 00 7d 3e 4e 3e 3d 45 38 4c f7

checksum: sum all bytes from 6th byte (0x20) to end omitting 0xf7. (0x20+0x08...+0x45+0x38+0x4c) & 0x7f = 0x00.

[BlueMoon]

As for the Wheel USB descriptor, you might actually be fine by using the existing joystick descriptor because at least all the games I know (e.g. FlatOut, Dirt and Trackmania) that supports wheels will also support an analog force feedback joystick. So, the game would see the wheel as a regular force feedback joystick, but you actually have the Wheel in - and that is just fine. You still get the same functionality. Also, it is quite difficult to have one AVR device to dynamically support multiple USB-descriptors. So, I would really encourage to start the Wheel-work by leaving the adapter to look like a joystick to PC and concentrate on determining the Wheel's game port protocols.

I've been trying to use the joystick for example with Dirt 3 and to be honest, this is unplayable! It doesn't recognize joysticks, only wheels but you can USE the joystick. Of course, the FFB send to the joystick is only on the X-axis and none on the Y-axis which doesn't feel as comfortable like playing Monstertruck Madness back in the days...

As I had subscribed myself to this topic, I thought I would receive notifications (emails) on new replies but I didn't. Didn't know you guys had advance that far already! Congrats guys and thanks everybody for helping.

@Grendel: I bought myself another sidewinder ffb wheel with USB. I know you read the usb-descriptor with external tools but do you have any idea to export it without any of those external tools? (I'll receive it around next week)

EDIT: I'll try using this one

[skoo]

Detailed FFB Wheel info as attachments for creating effects (f0) and modifying attributes (f1).

Spring and damper effects modify multiple values when single setting (coefficient, saturation or deadband) is changed, I will not use more time trying to figure them out. There is also many cases where multiple values are modified at the same time, for example changing ramp start value might change end value. Assuming that start value may not be greater than end value, so both are changed etc.

I have Sidewinder Force Feedback Wheel working with adapt-ffb-joy without FF, brake is set to throttle axis and gas as y-axis.
FF is not released when the wheel is detected by adapt-ffb-joy (have to disable it with force button), so FF initialization is not working; probably something wrong with initialization pulse timings.

[BlueMoon]

I have Sidewinder Force Feedback Wheel working with adapt-ffb-joy without FF, brake is set to throttle axis and gas as y-axis.
FF is not released when the wheel is detected by adapt-ffb-joy (have to disable it with force button), so FF initialization is not working; probably something wrong with initialization pulse timings.

How did you manage to get that working? Did you edit any files? (Guess so)

[skoo]

joystick.hex with wheel support (no FF) and patch for adapt-ffb-joy sources in attached zip. Wheel is shown as "LUFA Wheel wFFB" when connected.
There is hat, x/y/z-rotation, wrong number of buttons etc shown with joy.cpl as left overs from joystick descriptors. USB descriptors for wheel need some work, hid usage etc descriptors from USB wheel would help.
FF Initialization works with this version, spring effect is released when the wheel is detected.

[Reaper36]

joystick.hex with wheel support (no FF) and patch for adapt-ffb-joy sources in attached zip. Wheel is shown as "LUFA Wheel wFFB" when connected.
There is hat, x/y/z-rotation, wrong number of buttons etc shown with joy.cpl as left overs from joystick descriptors. USB descriptors for wheel need some work, hid usage etc descriptors from USB wheel would help.
FF Initialization works with this version, spring effect is released when the wheel is detected.

Great work, I am going to try it tomorrow!

[BlueMoon]

joystick.hex with wheel support (no FF) and patch for adapt-ffb-joy sources in attached zip. Wheel is shown as "LUFA Wheel wFFB" when connected.
There is hat, x/y/z-rotation, wrong number of buttons etc shown with joy.cpl as left overs from joystick descriptors. USB descriptors for wheel need some work, hid usage etc descriptors from USB wheel would help.
FF Initialization works with this version, spring effect is released when the wheel is detected.

Been testing it and it works for sure (except the FFB as you stated). The spring effect is indeed released when the wheel is detected. Been using it with Dirt 3 and Grid 2. Now, how to get the FFB in place...?

EDIT: wish that I could do something in the mean time... (waiting for my FFB wheel to arrive so I can extract the usb descriptors)

[Reaper36]

This patch works great. Tested a few games and general input works flawless.
Only "Assetto Corsa" had a serious performance issue when using the wheel,
might have something to do with the not working force feedback.

I converted the old svn repository from "http://adapt-ffb-joy.googlecode.com/svn/trunk/" into a git repository and applied the patch from skoo.
I have no clue if we are allowed to host this git repository public on Github, but I guess it could be useful?
Download adapt-ffb-joy-wheel.7z

[BlueMoon]

The Sidewinder steering wheel from Microsoft with FFB (USB) has arrived and I used this program to dump the USB descriptor. It seems a little bit short to me however, is this enough or do I need to do something else?

[cal]

program to dump the USB descriptor. It seems a little bit short to me however, is this enough or do I need to do something else?

Unfortunately, that's only a small part of the USB descriptor. That program does not output the input/output reports with individual data structures. A minimal FFB control device descriptor is around 1kB in binary format (several kilobytes as text).

Then, earlier, there was a suggestion of using the adapter's current USB descriptor i.e. that it would look like a joystick to PC and there was this answer:

I've been trying to use the joystick for example with Dirt 3 and to be honest, this is unplayable! It doesn't recognize joysticks, only wheels but you can USE the joystick.

Do you mean that driving with an actual joystick is not playable or did you somehow used the actual Wheel with the adapter but displayed as a joystick in the game's settings? If latter, how "unplayable"? A calibration or pedal reading interpretation issues or something else? Some driving games (and some wheels) combine accelerator and break pedals into a single axis. This creates some issues like getting very sensitive to calibration (so that there is no breaking and no accelerating when no pedals are pressed) and also that you cannot break and accelerate at the same time making driving special manouvers a little unintuitive compared to a real car.

It's just that making a single adapter to support multiple USB descriptors gets hard especially in terms of memory usage. The Teensy still has some program and RAM memory left (well, RAM is getting scarse as the FFB requires a lot of it), but not indefinitely.

[BlueMoon]

Do you mean that driving with an actual joystick is not playable or did you somehow used the actual Wheel with the adapter but displayed as a joystick in the game's settings? If latter, how "unplayable"? A calibration or pedal reading interpretation issues or something else? Some driving games (and some wheels) combine accelerator and break pedals into a single axis. This creates some issues like getting very sensitive to calibration (so that there is no breaking and no accelerating when no pedals are pressed) and also that you cannot break and accelerate at the same time making driving special manouvers a little unintuitive compared to a real car.

I remember playing Monstertruck Madness with the Joystick and it was amazing. However, when I try to use the joystick with for example Dirt 3, it becomes unplayable as the ffb effects are only applied to the x-axis. This results in no 'friction' on the y-axis, only on the x-axis (which feels really weird when playing) AND the most awful part: the FFB effects are little shaking effects from left to right. Even on 10% of the strength, it was unbareble! My arm hurts after only 1 round.

The changed code from skoo worked well (without ffb) and I thought we could use the original USB-descriptor for further analysis so we can use parts of it to make the FFB on the teensy work. I'll update this post if I can find the full descriptor.

EDIT: Well, what do we have here! Found a tool to get the full HID Report descriptor! Hooray!

[cal]

I remember playing Monstertruck Madness with the Joystick and it was amazing. However, when I try to use the joystick with for example Dirt 3, it becomes unplayable as the ffb effects are only applied to the x-axis. This results in no 'friction' on the y-axis, only on the x-axis (which feels really weird when playing) AND the most awful part: the FFB effects are little shaking effects from left to right. Even on 10% of the strength, it was unbareble! My arm hurts after only 1 round.

So, if you actually had the Wheel instead of FFP in use - even if it looks like "joystick" to Windows - I would expect you to get normal experience. Good to know.

EDIT: Well, what do we have here! Found a tool to get the full HID Report descriptor! Hooray!

Well, well. The Wheel IS modeled as a joystick there It even allows sending effects to two axis, just like FFP. Of course, the Wheel only has motors on one axis, but still, in the USB-terms, they look very very similar.

[Scanjo]

I wonder if it MUST send 2 axis commands . If X is forward and back on the joystick and Y is side to side, then doesn't it make sense that the wheel is a Y axis and must be sent 2nd? The X axis becomes a dummy command just to take up command space so the Y command can be sent...

[BlueMoon]

So, how can we get the final touch done and make the FFB work? We've never been this far! ^^

[Scanjo]

Cal and Skoo are hard at work and making great progress. My question to you is, would you rather they spend their time making it work or spend their time here posting to us? They're in the middle of figuring out all the FFB commands. Cal has referred to this as "grunt work" and it just takes time. They also want to add some features so they're making sure it all fits together.

Patience grasshopper...

[BlueMoon]

Cal and Skoo are hard at work and making great progress. My question to you is, would you rather they spend their time making it work or spend their time here posting to us? They're in the middle of figuring out all the FFB commands. Cal has referred to this as "grunt work" and it just takes time. They also want to add some features so they're making sure it all fits together.

Patience grasshopper...

Ah, of course I want them not to post here all the time, just wondering what the progress is and even more important: is there any way I (we?) can help? (except from stopping posting )
I feel so useless and such a "user" of their work so I want to help as much as possible. I even bought the USB wheel specifically to get the full HID report

[Scanjo]

If he needs more help, I'm fairly sure he will ask.

Waiting is hard for me too. I don't even have a wheel but I'm still excited for it to be included in the compatibility list.

[Reaper36]

Yeah if there is any way I can help please tell me how.
I have the wheel, the adapter a understanding of c/c++ and a working build environment.

That was my idea behind the git repository, not to force everyone to use git.

[duduke]

Just a side note for anyone not being able to have ForceFeedback: I've been building and rebuilding thinking something was wrong (joystick was working without force).
Apparently, the 2 1nf caps (in my case at least) were NOT optional.

just my 2c.

Thanks for this amazing project, it has revived my love for sims

[Scanjo]

The modified board I am building is now confirmed to work on a Mac Book Air running Mac OS X 10.9.1 "Mavericks".

According to this site: http://at.or.at/hans/research/nime/hid/apis.html and I quote...

"HID Manager is the standard USB HID API on Mac OS X."

From this statement I would assume that if the modified adapter works on OS X 10.9.1 (which it does) then it should work equally well for all versions of Mac OS X.

I have no idea if it will work on any earlier versions of Mac OS before "X".

[NoSuchUser]

Hi, I'm trying to adapt the project for an Arduino Leonardo board and I would be very glad, if someone could help me with my troubleshooting.

I have built the circuit on perfboard with the required resistors and capacitors, and connected a Microsoft Sidewinder FFB Pro Joystick to it.

When I connect the board per USB to the computer, I sometimes see a LUFA ffb joystick appear and quickly disappear in the device manager. After that there is no Joystick found in the device manager or the gamecontroller configuration menu.

This behavior occurs on two different Windows 7 machines (32 and 64 bit). Under Ubunutu linux no Joystick is found.

I have a few different ideas what might have caused the problem:
- I had to shift the different Button signals from PB0-PB5 to PB1-PB6
- The Arduino bootloader might create problems
- My perfboard circuit might have problems

At the moment I'm missing some information that could help me narrow down the problem area. Most importantly: Does the program always present an USB Joystick to the system, or only after I've attached the Sidewinder Joystick? Currently the behavior is the same, whether the DB15 is connected or not. Is this an indicator for a problem with the microcontroller?

If you could point me in the right direction I would be grateful.

[Scanjo]

Hi, I'm trying to adapt the project for an Arduino Leonardo board and I would be very glad, if someone could help me with my troubleshooting.

I have built the circuit on perfboard with the required resistors and capacitors, and connected a Microsoft Sidewinder FFB Pro Joystick to it.

When I connect the board per USB to the computer, I sometimes see a LUFA ffb joystick appear and quickly disappear in the device manager. After that there is no Joystick found in the device manager or the gamecontroller configuration menu.

This behavior occurs on two different Windows 7 machines (32 and 64 bit). Under Ubunutu linux no Joystick is found.

I have a few different ideas what might have caused the problem:
- I had to shift the different Button signals from PB0-PB5 to PB1-PB6
- The Arduino bootloader might create problems
- My perfboard circuit might have problems

At the moment I'm missing some information that could help me narrow down the problem area. Most importantly: Does the program always present an USB Joystick to the system, or only after I've attached the Sidewinder Joystick? Currently the behavior is the same, whether the DB15 is connected or not. Is this an indicator for a problem with the microcontroller?

If you could point me in the right direction I would be grateful.

I am NOT the programmer. I have just been following this thread for quite some time and am building boards to help people out. I am not perfect and have made mistakes in the past. With that said...maybe this will help you.

I make the assumption based on the thread you're posting in that you are using the schematic for the adapt-ffb-joy project, not the 3DP-Vert project.

I run Win7 32 bit. I just did some quick testing here to verify what my board is doing. I never get a LUFA device unless the joystick is attached. If I plug in the board by itself it shows nothing. I can then plug in the joystick and it shows the LUFA device. Unplug the joystick and it goes away (board still plugged into USB). Any attempt from this point on will NOT show the joystick until I unplug the USB and replug. I am using the "adaptffbjoy-r54.hex" firmware. Double checking your circuit would be a good first step. Resistors should be 2@2.2K ohm and 1@220 ohm. Capacitors should be 2@.001uf. The 2.2K resistors should be on DB-15 pin 3, and pin 13 (pins 11 and 13 bridged to be able to use the modified firmware for PP, 3D Pro, and 3D Pro Plus "3DPro32u4-10.hex"). The 220 ohm resistor on pin 12. The 2 lines with 2.2K resistors should have a capacitor to ground on the Teensy (or Arduino) side.

I have no idea what the pins do on the Arduino. On the Teensy, PB0 and PD0 have to be tied together for timing if I'm not mistaken. The Arduino may have other requirements based on pin capabilities. You may not have the option of shifting PB0... If the timing is not right during initialization then the FFP won't enable. There could be other issues with shifting the pins that I'm not aware of.

Hope this gives you something to work with till you get a more in depth answer from Cal or Grendel.

[Scanjo]

At this point, I have only 10 adapter boards left. First come, first served. I have no plans for ordering more parts till at least this fall. My spring and summer is just too busy. Hopefully this will allow enough time to have full support for the FFB Wheel also!

[Scanjo]

Only 5 left...

[Scanjo]

3 left.

[Overkill211]

I still have 3 of my adapter boards available.

[Merl]

I would like to buy 2 of them right away!!!!

[Phoenix]

Overkill I would like to purchase the one you have left.

I have been looking around for just this kind of an adapter. I happened on to the site in my search, as I was skeptical of the ones being sold online.
Hats off to all that have made these possible. Really looking forward to cleaning up my old FFB Pro, spent many a glorious hours in Mechwarrior!

[roid]

is anyone interested in mechanical joystick hacks?
ie: not so much the circuitboards or software, but the actual shape and mechanical movement of the joystick. Gimball design, springs, motor & button placement/feel, etc.

A guy at my local hackerspace has been experimenting with his own joystick designs. http://openjoystick.com/
And i've been noticing some interesting stuff on thingiverse, albiet it's mostly small console-style thumb sticks. Has any of it been of interest to the topic at hand?

[youtube]GIY6-3KwIS8[/youtube]

[Overkill211]

I now only have 2 boards left.

[Ragnvald]

Overkill211, im interested in buying. I have sent you an e-mail via descentBB.

Ragnvald

[Ragnvald]

I now only have 2 boards left.

Im interested in buying, i have sent you an e-mail via descentBB.

Rangvald

[JimRedcliff]

Hi,

I will take one. You have Mail.

Best regards

[Overkill211]

I shipped out my last 2 boards, today. I'm now sold out, unless substantial interest is expressed.
I found it interesting that 4 of the 5 boards I made went international - Netherlands, UK, Sweden, Germany. I would have expected more "local" interest.
To my buyers, a big thank you.