tloimu / adapt-ffb-joy Goto Github PK

FFB Pro joystick, Win10.

Moving the stick forward and back slightly affects the Z-axis rotation (forward decreases rotation as though twisting counter-clockwise, pulling back increases as though twisting clockwise). Left and right movement of the stick also has some effect, though much subtler (forward-right corner shows approximately the expected rotation value, but center-right is only very slightly higher than expected).

The forward-center movement is the most dramatic in terms of impact on the Z rotation, changing it by upwards of 20% (enough to induce noticeable yaw unless I set a very large dead zone). Other directions are smaller effects, though still visible. This change happens whether or not FFB is active, including when it is unpowered and I'm simply pushing the stick with one finger (not gripping it at all). When gripping, I can override this rotation, but it does require fighting the spring force. I can also still move through the entire Z rotation range by twisting the stick the appropriate direction, so it's usable for flying, but not great.

It's possible, of course, that this is simply due to the age of the stick and has nothing to do with the adapter or its firmware. However, I'd like to see if this can be fixed in the adapter firmware. I don't have either another version of this stick or any PC with a native gameport to test with.

At least the following effect parameters are not being correctly set in OUT 
reports from the host to the device:
 - direction
 - duration
 - attack and fade time

the values sent to device are always the same regardless what is actually set 
in the effect definition on the host side.

It is likely to be a HID issue or an issue in the install time protocol i.e. 
that the device might not respond correctly to all host's control requests 
during device install time (i.e. first time plug-in).

Original issue reported on code.google.com by [email protected] on 14 Feb 2012 at 11:52

1. What is it that the new feature will do or allow?

Return to zero position when force feedback is not used.
In the very old Win98 support tool it was also possible to to configure the 
strength of the "spring" moving to neutral position.

2. Who would primarily use or benefit from the new feature?

Gamers.

3. How would one use the new feature?
Everyone playing games with no force feedback support.

Original issue reported on code.google.com by [email protected] on 6 Mar 2014 at 2:44

I think is not a real bug, but I saw many people with is bad behaviour.
This old game use "rudder" HID definition instead of "throttle" HID, and this game don't permit to change the slidder assignment.

So, I have modified the source code in order to have the game functional :

• HID definition modification : rudder only instead of rudder & throttle
• remove of Z, Rx, Ry,
• joystick slider data send to rudder instead of throttle

I can give the source code modified.

Thank you to the different teams about the great adapter which permit me to play with my old MS Sidewinder Force Feedback Pro.

1.Full USB conversion for the CH Force FX stick - with full force feedback, 
just like can be achieve with the current setup with a MS FFB Pro stick.


2. Those to benefit are ones with old serial port CH Force FX sticks.  Gamers, 
and sim pit hobbyists.  I have two new CH Force FX sticks - still boxed new.

Original issue reported on code.google.com by [email protected] on 30 May 2014 at 10:02

output channels as PPM signal, to be fed into rc transmitter trainer port.

I tried to use the additional trimpot-axes. Trim1 ("Ry") works, but the others to not (at least not Trim2 and Pedal1, did not try Pedal2 yet). I used the same Trimpot, so it is no issue with the pot (it works on Ry=trim1).

There is some signal recognized because the signal of the axes is either in the middle position or at zero (or max) when you turn the trimpot to max.

Hi! I was checking the different force feedback devices and it seems like there's not much being created. I currently have a MSFFB2 which I love but I was looking at future options.

It seems like Brunner has created a Force Feedback (CLS-E) base but they don't support DirectX. From what I have been investigating VJoy can only use one effect at a time. I have also been checking multiple projects for this and it seems like this project is the most mature and it should be possible to instead of sending Midi commands, create an interface with the Brunner base and send the commands to it.

Do you think this would be doable? Thanks!

Hi,

Common knowledge claims it was not USB compatible and there were no USB adapter provided by Microsoft (unlike for non-force feedback version)

But this seller claims otherwise:
https://www.ebay.pl/itm/114603270740

He even sent me reply, will cite fragment of it there:

The game controller came in origin with this adaptor, it was built for use with the old game port and with the new USB port (new in 80/90’ years). I used both and they worked smoothly. And it’s still working. The controller is heavy, rock solid and 100% working with USB port

If it's true, then it would be nice to reverse-engineer the original adapter (maybe firmware is dumpable).
If it would be multiple times cheaper, I would buy it. But it's not :-/

The adapter can be recognized as a joystick, but the inputs are all wrong. In the attached picture I didn't press any button.
My inputs also don't register at all.
The firmware version is r54. I tried my adapter on Win10 Win7 WinXP but it just doesn't work.
My adapter is correctly assembled, and the flight stick is known fully functional.
The serial number of the stick is 96755, and it has a fan.
Any help would be appreciated.

saldsj3 reports, that:

"For Sine, and Square waves, 46-50 doesn't work. For triangle waves, 46-50 do 
work. For all periodic effects, wavelength 84-100 don't work.

I also had issues with magnitude, it seems certain attack levels / fade times 
are necessary to get the joystick to react to a lower magnitude value,  A fade 
time of 0 seemed to always result in a full force effect."

The non-functioning frequencies are because of the joystick itself. The adapter 
needs a new feature that converts the non-functioning frequencies to some 
useful frequency value for the joystick in order to avoid completely missing 
effects.

Original issue reported on code.google.com by [email protected] on 24 Jul 2012 at 6:47

FFB Pro, Win10. The throttle slider is marked on the case as increasing with clockwise rotation (this is also just what you'd expect; throttle forward should be "more"). However, the throttle axis shows as inverted in Windows; max clockwise (forward) is -64, and counter-clockwise (back) is +63,

I can correct for this in games that allow inverting the throttle axis, but it seems like it would be better to do that in the microcontroller.

Additionally, the throttle range seems to be truncated; roughly the top eighth and bottom eighth (so, 1/4 of the total movement range) of the controller doesn't affect the output at all. Obviously this could be due to things like the joystick being decades old or possibly it was always like that, but it seems a shame to waste that much of the throttle's movement range (and also makes minute corrections harder within the remaining range).

It's possible I've got some wires crossed somewhere on my breadboard, but I don't think so; I was pretty careful and double-checked.

What steps will reproduce the problem?
1. Plug in teensy with adaptffbjoy-r54.hex loaded
2. run fedit
3.

What is the expected output? What do you see instead?
Expected to see a new device in device manager. Nothing added, not even unknown 
device. Teensy simply flashes rapidly.

What version of the product are you using? On what operating system?
adaptffbjoy-r54.hex. New teensy 2.0 (dec 2012), windows 7 ultimate 64 bit.

Please provide any additional information below.

Teensy works with other software (serial etc), shows up in device manager.

Original issue reported on code.google.com by [email protected] on 21 Jan 2013 at 3:19

Hi Sir

i saw your project Gun4IR(http://forum.arcadecontrols.com/index.php/topic,161189.0.html) and very like this project and want try to build it by myself
where/How i can support Gun4IR project and get the GUI licenses

I flash chip with "adaptffbjoy-r54.hex" and it not work! Device not recognized, no device in device manager.
But arduino bootloader work perfectly, this means that the board is working.

Hi!

This will adapt an old gameport sidewinder wheel to work in windows?

I bought an adapter with the optional pots installed and it works well in the Win10 Control Panel.
I play space sim games like IWAR2 and the 'throttle' on the joystick is not recognised - instead the 2 'slider' pots are the throttle.
This cannot be configured in game, so I removed the pots from my adapter - but I'm guessing they need disabling in firmware since the game still has no throttle.
Can anyone help to make a firmware that only enables the standard joystick features?
Thank you in advance.

Hi

I broke my FFBs gameport plug, and want to resolder it to a new one ,.
Does anyone know the color code? Meaning which color wire goes to which pin of the gameport?

i wired everthing up according to https://github.com/juchong/adapt-ffb-joy all the steps in there but i cant seem to get it recognized. (the joystick itself works fine)

On connection finds 2 HID drivers fine, but not the lufa joystick wffb driver,

Tested on 32 bit works fine..

Searched for a physical driver, none available.

Connect FFP to a real game port while having the MIDI

1. FFP does not listen to FFB commands sent to it via MIDI pin (e.g. by a 
microcontroller)
2. Start e.g. FEdit (or any other application that uses FFB)
3. Now FFB listens to FFB commands sent to it via MIDI pin (e.g. by a 
microcontroller)

How to reproduce what a real game port and Windows drivers (e.g. in XP or 
earlier) does to switch the FFP into "FFB mode"? It is not in that mode by 
default when the joystick starts up and the command is not coming via MIDI pin 
since the above works even when the joystick's MIDI pin is disconnected from 
the game port's MIDI pin.

Original issue reported on code.google.com by [email protected] on 22 Jan 2012 at 1:18

The beta works great apart that the FFB effects are not working anymore when reconnecing the (Teensy) from https://www.yard2usb.de/joomla/index.php/sidewinder-usb to usb again. It just works directly after programming the teensy. With the firware from https://github.com/JayBee-git/adapt-ffb-joy it works even when reconnecting the USB adapter. Not sure what is the issue here.

The autocentering works but no effects are triggered by the ForceTest tool.

please.

-andreas

The wheel is powered differently to the FFP joystick and is able to back-power the adapter through the signal pins.

The joystick processor is not powered independently:

1. When the 12V power cable is connected on its own the green LED at the base of the stick does not light up.
2. When the gameport cable is connected on its own (with power through the adapter) the LED flashes, the adapter is able to connect to the stick and everything works except for the force feedback motors.
3. When the gameport and 12V power cables are connected the LED is steady and the motors also provide feedback.

The wheel processor is powered independently:

1. When the 12V power cable is connected on its own the green LED behind the "FORCE" button flashes. The wheel motor performs an initialization from one side back to the center - presumably to self-calibrate.
2. When the gameport cable is connected on its own (with power through the adapter) there is no response and no LED. The adapter cannot connect to the wheel.
3. When the gameport and 12V power cables are connected the LED and feedback motors can both be toggled on and off with the FORCE button and the adapter can communicate with the wheel.

However when the adapter USB cable (which provides power to the adapter MCU) is then removed the adapter continues to be powered and the wheel behaves as if it is still connected. This apparently can occur when there is a voltage on the input pin(s) and current is drawn through the internal protection diodes to the VCC rail.

I guess it's possible my wheel is malfunctioning, but I did also find an image of another wheel LED lit despite the gameport cable disconnected.

I have measured the voltages on the wheel gameport pins with a multimeter with respect to Ground (Gameport Pin 4).
Pin 1: 0V (VCC)
Pins 2,3,7,10&11: 4.9V (X1,X2 and all buttons)
Pin 12: 4.7V (MIDI out)

Also when back-powered I measured the voltage between adapter GND and VCC as 3.3V

According to the datasheet for the Atmega32u4 under Absolute Maximum Ratings:
Voltage on any Pin except RESET and VBUS with respect to Ground (8) . . . . . . . . -0.5V to VCC +0.5V

So this condition has potential to damage the adapter MCU. If the current is sufficient it could be bad for the wheel as well.

The option to ignore this and try to always ensure the adapter is connected to USB first is risky and has a number of drawbacks:

• It's easy to forget - I've made the mistake already a few times while testing it. It doesn't help that the LED can already be off and the power cable port is well hidden behind the wheel.
• The ideal initialization sequence appears to be to connect power first then gameport/USB. When the adapter connects too quickly the self-calibration aborts and the wheel is off-centre. Maybe this can be fixed in firmware.
• To reset the adapter requires two connectors to be unplugged then replugged.

There appear to be a number of alternative solutions using basic components (e.g. resistors, diodes, tri-state buffers) that would all involve modification to the adapter circuitry. Note there are 6 powered pins so the MCU would need to be protected from voltages on all of these. I'm not well enough versed in Electrical Engineering to predict what would be the simplest/cheapest solution and which might also cause issues with communications. Any ideas?

Teensy board, working good with previous release 0.3.0.
Upgrading to 0.5beta joystick correctly recognized as MS FFB Pro but only centering spring work, no FF at all.
Same circuit (no trimmers)

What steps will reproduce the problem?
1. Play IL2 and fly
2. Fire machine guns or cannons

What is the expected output? What do you see instead?

The game freezes for a second or so before the effect starts and the game 
continues.

Also some other games have been experiencing similar and even worse stutters.

Please use labels and text to provide additional information.

Original issue reported on code.google.com by [email protected] on 15 May 2012 at 8:19

What steps will reproduce the problem?
1. Use the adapter with a M$ Force Feedback Pro joystick in XP and probably any 
other OS
2. Open "Control Panel" -> "Printers and Other Hardware" -> "Game Controllers", 
click "Properties" on the "LUFA Joystick wFFB" and go to the "Test" tab. 
3.  Try using the 9'th button (the shift arrow) and it will trigger by itself 
as button 9, and not shift the other buttons to the remaining stubbed out 
button entries 10-16. 

What is the expected output? What do you see instead?
I expected to button 9 to not trigger a press by itself, but for button 1-8 
pressed in conjunction to read as button 9-16 respectively.

What version of the product are you using? On what operating system?
I'm using the M$ Force Feedback Pro with the adapt-ffb-joy latest svn firmware 
(downloaded 11/08/2014) and installed on a self-made adapter with a teensy 2.0. 

I managed to fix it in the code, but am not sure if it's more than just a hack 
or should be fixed other places.

I changed this line in Joystick.c:
outReportData->Button = ((sw_report[4] & 0x7F) << 2) + ((sw_report[3] & 0xC0) 
>> 6);

to these lines:
        if ((sw_report[4] & 0b01000000) == 0b01000000)
        {
            // button 9 (shift) is held down
            sw_report[4] &= 0b10111111;     // Lift up button 9; it's not to be used alone.
            outReportData->Button = ((sw_report[4] & 0x7F) << 10) + ((sw_report[3] & 0xC0) << 2);
        }
        else
            outReportData->Button = ((sw_report[4] & 0x7F) << 2) + ((sw_report[3] & 0xC0) >> 6);


And it does exactly what I wanted.  I'm a bit surprised and proud of myself 
since I haven't ever edited code to a hardware device before and was successful 
so quickly.  I know I should have applied it in patch format, but as I'm on 
windows right now I don't have diff easily available.  I'm attaching the fully 
modified Joystick.c file.


Thanks if you decide to include this in future releases,

  Lucas

Original issue reported on code.google.com by [email protected] on 7 Mar 2015 at 11:13

Attachments:

• Joystick.c

Clicking on the link for the circuit diagram goes to a 'not found' page.

http://adapt-ffb-joy.googlecode.com/files/adaptffbjoy-circuit.png

Located on https://github.com/tloimu/adapt-ffb-joy/blob/wiki/HowToBuild.md

What steps will reproduce the problem?
1. Uninstall the device (e.g. with USBDeview) if it was installed and remove 
all registry entries of it (mainly the key that has the "OEMForceFeedback" key)
2. Plug-in the device
3. Start FEdit

FEdit should recognize the device as FFB device, but it does not.

Only after modifying the registry. See

http://code.google.com/p/adapt-ffb-joy/wiki/USBFfbHid

for details.

Original issue reported on code.google.com by [email protected] on 14 Feb 2012 at 11:47

pity, have it as in the picture connected. but as soon as I hold the joystick with my hand and the sensor is activated, the yaw and the thrust axis tremble.

What steps will reproduce the problem?
1. Connect the adapter to PC
2. Wait that it appears to COM-ports in System Management control panel
3. Attempt to open the COM-port to device e.g. with a terminal program

What is the expected output? What do you see instead?

The COM-port should open successfully, but quite often it takes several 
restarts of the adapter and some Voodoo to make a successful port opening. It 
helps to plug the adapter AND the joystick's power chord off and wait for a 
while before reconnecting. But even that does not always succeed.

The COM-port DOES always appear to Windows when connecting the device, but 
actually opening that port fails quite often. If it can be opened once, it can 
always be reopened. It is that first open that is the issue.

Original issue reported on code.google.com by [email protected] on 8 Jan 2014 at 1:07

Hi there, i have been trying to get my dads old sidewinder ff pro working again for a while now and have yet to be successful... i bought an gameport to usb adapter but its not "working" and while i was trying to troubleshoot that i stumbled across this lovely project. Now after reading through it i wanted to see if some of the "smarter" people here could help me get it working on my hardware

I installed r54 from the google code a while ago onto my MS Force Sidewindewr Feedback Pro with a teensy 2.0 ATmega32U4

Does this version supersede that ? and is it supported on my teensy ?

add new macro, if its enabled:

instead of sending input of 2 trim pots as Rx Ry HID joystick axis, shift force feedback autocenter to x,y position of those trim pots

Why it would be cool: to use joystick as trimmed joystick in FPV rc aircraft setup

Make a better name so that users can find the joystick/wheel easier from the 
Game Controller control panel. If possible, the name should be different when 
FFP joystick is connected than when the Wheel is connected.

Original issue reported on code.google.com by [email protected] on 8 Jan 2014 at 12:58

I spotted this while logging effect data from Assetto Corsa with the joystick to get the wheel working.

There are two parts to this.

The first is that effect default values set in FfbproCreateNewEffect() are for waveforms, not conditionals (spring, damper, inertia, friction). This means that e.g. the default pitch offset is set to 0x4E 0x00 rather than 0x00 0x00. This should be fixed by setting defaults depending on effectType.
Normally this does not matter because the default values are overwritten when two Condition Block reports are received over USB, one for each axis. However the PID specification allows for only one Condition Block and specifies how it should be handled:

If the number of Condition report blocks is equal to the number of axes for the effect, then the first report
block applies to the first axis, the second applies to the second axis, and so on. For example, a two-axis
spring condition with CP Offset set to zero in both Condition report blocks would have the same effect as
the joystick self-centering spring. When a condition is defined for each axis in this way, the effect must
not be rotated.

If there is a single Condition report block for an effect with more than one axis, then the direction along
which the parameters of the Condition report block are in effect is determined by the direction parameters
passed in the Direction field of the Effect report block. For example, a friction condition rotated 45
degrees (in polar coordinates) would resist joystick motion in the northeast-southwest direction but would
have no effect on joystick motion in the northwest-southeast direction.

So the second part is that the "single Condition report block" case is not expected by the adapter and is not handled correctly. Assetto Corsa indeed sends only one Condition report block and sets the Direction field to 90 degrees. This happens to match the first axis and so the effect does play in the correct direction, but only by coincidence.

The adapter ought to handle a single Condition block by selecting the applicable axis based on the Direction field. The FFP only supports conditional effects in cardinal directions (N,S,E,W), so for intermediate angles, e.g. 30 degrees, it would have to either a) apply the effect to the closest axis or b) apply it to both axes by sine and cosine of the angle, effectively creating an oval shaped rather than a diagonal line conditional response.

It's not clear what is supposed to happen if a second Condition report block is received after a Set Effect block report or while the effect is playing. This is probably undefined behaviour.

I know it's currently not supported but has any investigation being done on porting it to a RP2040 device as they're cheap and readily available. I'm not a fan of the Pro Micro as find the micro usb ports rip off easily. Something like an RP2040-Zero with USB C would be great for this project, but many other RP2040 devices exist in various formats (lots with usb c). Drag and drop flashing is nice too with no software needed.

https://www.waveshare.com/wiki/RP2040-Zero

would it be possible to add support for the start delay parameter?

this parameter makes the effect start a certain number of milliseconds after the effect is played. This is used for example in the ForceTest.exe test script for playing the grooves effect which is basically feeling a bump with a certain frequency

What steps will reproduce the problem?

Some games experience lag with some effects when using the FFB joystick. The 
exact effect(s) causing the lag has not been identifier.

The adapter might be slow (or too quick) to respond to PC on some messages. 
Then Windows halts until timeout or response comes, which causes the lag.

Original issue reported on code.google.com by [email protected] on 21 Mar 2015 at 1:57

Hi is there anyone who make work the .hex on arduino pro micro ?

it work for me found the issue and solution the 1nf condensator on PB5 is mandatory with my ffb1 96755. If not present the mode "digital" is not decteted during initialisation by the stick and effect are not taken in consideration.

more info on init process here : https://www.descentbb.net/viewtopic.php?f=8&t=19061

history of what i have done :

the pinout is not the same on the board so i just "moved" the connection with same name beetween the two boards

i dont have the PB0 on the pro micro board so i didnt make the PB0-PD0 connection may be my mistake then desolder the smd resistor on TX led i use the pad has PB0 pad and solder it with PD0 as need. No FFB even with that.

Note for other guys who can have issue like me :
PD0 look to have two différents places pin3 and pin14 based on https://cdn.sparkfun.com/datasheets/Dev/Arduino/Boards/ProMicro16MHzv1.pdf

--> ok i found the answer PD0 is on PIN3 for my micro pro check with 32u4 pinout to confirm.

I use the old ffb1 sidewinder 96755 i noticed that if i just plug the 12v adapter on the stick but no connected the gameport
i have no reaction of the stick no self centering and no resistance it look to be the normal behaviour
i was thinking that plug the power will center the stick if not connected to a PC but that is not the case.

First try my stick was well detected by windows but reading value and force produced eractic value reading are very unstable.
Pov bouton is always "on" for one direction :

**found the issue it was because i didnt connected all the wire after adding pb2 and pb3 the reading value where correct and stable. Only Z is a bit eratic.

I used adaptffbjoy-r54-Clean.hex found here : https://github.com/JayBee-git/adapt-ffb-joy/tree/master/downloads

Flashed with avrdude who came with ide arduino ( took the line code from verbose flash log in ide and changed the name of the HEX to my. You need to reset the arduino micro just before flash by but gnd on "reset" pin for short time just before : the com port is not the one see by default on IDE this is normal... keep the same from verbose log of your arduino ide when you flash .ino from ide

example :

C:\Users\drepou\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/bin/avrdude -CC:\Users\drepou\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/etc/avrdude.conf -v -patmega32u4 -cavr109 -PCOM6 -b57600 -D -Uflash:w:C:\hex/adaptffbjoy-r54-Clean.hex:i

Arduino micro is not detected by window after flash if no joystick is connected on it i confirm that too !

I have checked the midi output on pin 12 ( gameport ) look that the protocol is correct no idea why the stick not react :

Sample of Constant force send with Force Editor :

Time [s],Value
-0.000032000000000,PatchChange Channel: 5,0xC5
0.000288000000000,InstrumentNum Channel: 5 [0x01],0x01
0.077033250000000,PatchChange Channel: 5,0xC5
0.077353250000000,InstrumentNum Channel: 5 [0x01],0x01
0.147097250000000,ContinuousController Channel: 5,0xB5
0.147417250000000,ControllerNum Channel: 5 [0x01],0x7C
0.147737500000000,ControllerValue Channel: 5 [0x01],0x7F
0.148057500000000,Aftertouch Channel: 5,0xA5
0.148377500000000,Key Channel: 5 [0x01],0x7F
0.148697500000000,Touch Channel: 5 [0x01],0x00
0.149017750000000,PatchChange Channel: 5,0xC5
0.149337750000000,InstrumentNum Channel: 5 [0x01],0x06
3.351471250000000,BeginSystemExclusiveMessage,0xF0
3.351791500000000,orphanedData Channel: -2 [0x01],0x00
3.352111500000000,orphanedData Channel: -2 [0x01],0x01
3.352431500000000,orphanedData Channel: -2 [0x01],0x0A
3.352751500000000,orphanedData Channel: -2 [0x01],0x01
3.353071500000000,orphanedData Channel: -2 [0x01],0x23
3.353391750000000,orphanedData Channel: -2 [0x01],0x12
3.353711750000000,orphanedData Channel: -2 [0x01],0x7F
3.354031750000000,orphanedData Channel: -2 [0x01],0x7B
3.354351750000000,orphanedData Channel: -2 [0x01],0x17
3.354672000000000,orphanedData Channel: -2 [0x01],0x00
3.354992000000000,orphanedData Channel: -2 [0x01],0x00
3.355312000000000,orphanedData Channel: -2 [0x01],0x00
3.355632000000000,orphanedData Channel: -2 [0x01],0x00
3.355952000000000,orphanedData Channel: -2 [0x01],0x7F
3.356272250000000,orphanedData Channel: -2 [0x01],0x64
3.356592250000000,orphanedData Channel: -2 [0x01],0x00
3.356912250000000,orphanedData Channel: -2 [0x01],0x10
3.357232250000000,orphanedData Channel: -2 [0x01],0x4E
3.357552250000000,orphanedData Channel: -2 [0x01],0x7F
3.357872500000000,orphanedData Channel: -2 [0x01],0x00
3.358192500000000,orphanedData Channel: -2 [0x01],0x00
3.358512500000000,orphanedData Channel: -2 [0x01],0x7F
3.358832500000000,orphanedData Channel: -2 [0x01],0x7B
3.359152750000000,orphanedData Channel: -2 [0x01],0x17
3.359472750000000,orphanedData Channel: -2 [0x01],0x7F
3.359792750000000,orphanedData Channel: -2 [0x01],0x01
3.360112750000000,orphanedData Channel: -2 [0x01],0x00
3.360432750000000,orphanedData Channel: -2 [0x01],0x7F
3.360753000000000,orphanedData Channel: -2 [0x01],0x00
3.361073000000000,orphanedData Channel: -2 [0x01],0x00
3.361393000000000,orphanedData Channel: -2 [0x01],0x00
3.361713000000000,orphanedData Channel: -2 [0x01],0x6A
3.362033250000000,EndSystemExclusiveMessage,0xF7
9.501357000000000,ContinuousController Channel: 5,0xB5
9.501677000000001,ControllerNum Channel: 5 [0x01],0x20
9.501996999999999,ControllerValue Channel: 5 [0x01],0x02

Last action add the optional condensator make the FFB work !!!! GREAT thanks to all Develloper

What steps will reproduce the problem?
1. Play IL2 game and fly a plane to that it stalls

What is the expected output? What do you see instead?

The force feedback effect of the turbulence/stall shake on the joystick feels 
wrong and pulls the stick erratically. Make the planes unflyable. Also some 
other effects related to flying seem not to work properly even if all effects 
can be played with FEdit without a problem.

Please use labels and text to provide additional information.

Original issue reported on code.google.com by [email protected] on 15 May 2012 at 8:17

While testing in FEdit I noticed that there was a very nonlinear response when varying constant force and sine. Below about 30% the effects are not perceptible at all. Crossing 50% there is a big jump in output response. This means that subtle effects in games, such as engine vibrations, pavement bumps, gear shifts and pre-stall flutter are not felt unless the effect gain can be adjusted high in the game menus.

The cause is a bug in CalcGain that results in an effect magnitude of 0-50% to be mapped to 0-25% force and 50%-100% to be mapped to 75%-100%. This function is used for constant force magnitude, sine magnitude and effect envelope attack and fade.

Current code in ffb.c:
uint8_t CalcGain(uint8_t usbValue, uint8_t gain)
{
int16_t v = usbValue;
return (((v * gain) / 256) >> 2 ) & 0x7f;
}

v needs to be modified to an unsigned integer in order to avoid an overflow when multiplying two 8 bit unsigned integers
Then >> 2 is equivalent to division by 4. The output needs to have a range of 0x00 to 0x7f (=128) so this should be >> 1.

I've tested the following:
uint8_t CalcGain(uint8_t usbValue, uint8_t gain)
{
uint16_t v = usbValue;
return (((v * gain) / 255) >> 1 ) & 0x7f;
}

And suddenly those subtle effects are there.

Note: I also found with the modified code that I get about a 1s lag on stick response and Windows freezes every time a message is sent to the stick. This is obviously unplayable. But I have debug enable and it only happens when I do not have a terminal open monitoring the USB COM port. With the terminal open it works fine. I'm not certain whether this was the case with the previous hex - I haven't gone back. I can't see why the change would make any difference but I saw in the commit log there was a 5ms delay introduced when responding to USB, so maybe there is a timing sensitivity - too fast or too slow? So needs some testing still.

First, I am aware that this might not be the right place, as it isn't directly about the ffb software this github repository is about.
But I think, to reach the right audience, it might be helpfull to do it this way.

After a lot of work, doing photogrammetry and editing in blender.
I created a printable left hand joystick handle for the sidewinder joystick.
thingiverse project link (yes my name is Laika in there)
Have fun with it.
I also made a modified version of simFFB tool, that supports both joysticks at once.

1. What is it that the new feature will do or allow?

Allow writing applications on PC that can control the joystick's force effects 
directly by sending the effects data and commands directly to the virtual 
COM-port instead of using DirectX or the FFB USB-protocols.

2. Who would primarily use or benefit from the new feature?

Developers of the PC software that do not want to face the complexity of 
DirectX, but want to control the joystick directly.

Here's the description from the original source of the request "Joseph":

"My project is called 'Tourist' it's a non-violent fps style exploration VR 
type of game to help the ill to relax basically. A child could play it.
BlitzBasic3D has a really IFFY ff module, so I'd prefer to attack this problem 
via serial com port and/or a slave app. I have other input devices also."

3. How would one use the new feature?

Once the joystick is connected, an application could open the virtual COM-port 
to the joystick and start sending effects data and thus be able to fully 
control the joysticks force effects in a much simpler way.

This feature might also help adapter developer to run unit tests on the adapter 
software without the need of writing complex DirectX code.

Original issue reported on code.google.com by [email protected] on 29 Dec 2013 at 2:03

1. What is it that the new feature will do or allow?

Add support to Sidewinder Force Feedback Wheel.

Original issue reported on code.google.com by [email protected] on 8 Jan 2014 at 12:30

For builds that include the USB serial COM port, any force feedback commands sent to the joystick cause a ~1s stutter in the Windows application. This makes games unplayable.

The workaround is to open a connection to the USB serial COM port in a terminal program. This prevents the lag. (Or use a build without the serial port)

Related to #16.

I built one of these adapters for my Force Feedback Pro. Under Windows, it seems to work fine, both the joystick and the force feedback effects. Under Linux, however, I have only been able to get the joystick working. Force feedback does not seem to work. Even if I can't get full force feedback support working, it'd be nice to be able to turn on auto-centering.

I'm guessing this is more an issue with the Linux force feedback drivers, since adapt-ffb-joy presents itself as a standard USB HID device, but I figured I'd raise the issue here in case other people are having the same issue.

Running fftest, I get the following:

Force feedback test program.
HOLD FIRMLY YOUR WHEEL OR JOYSTICK TO PREVENT DAMAGES

Device /dev/input/by-id/usb-Dean_Camera_LUFA_Joystick_wFFB-event-joystick opened
Features:
  * Absolute axes: X, Y, Z, RX, RY, RZ, Throttle, Hat 0 X, Hat 0 Y, 
    [7F 00 03 00 00 00 00 00 ]
  * Relative axes: 
    [00 00 ]
  * Force feedback effects types: 
    Force feedback periodic effects: 
    [00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ]
  * Number of simultaneous effects: 0

Uploading effect #0 (Periodic sinusoidal) ... Error:: Function not implemented
Uploading effect #1 (Constant) ... Error: Function not implemented
Uploading effect #2 (Spring) ... Error: Function not implemented
Uploading effect #3 (Damper) ... Error: Function not implemented
Uploading effect #4 (Strong rumble, with heavy motor) ... Error: Function not implemented
Uploading effect #5 (Weak rumble, with light motor) ... Error: Function not implemented
Enter effect number, -1 to exit

When I look at a list of supported devices under Linux, it looks like these are all hardware specific, rather than a generic USB device. I don't know how accurate this list is. I haven't been able to find anything that specifically mentions Linux support for USB HID force feedback.

Even if Linux doesn't support this, I've seen some mentions on this repo of a serial port that can be used to configure the adapter. Is it possible to use this to at least turn on auto-centering mode?