Trembling axes, when FF-Sensor is activated

[PAL123]

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.

[Poil]

Hi,

No problem here I play BFV with my sidewinder ffb on Windows 10

[PAL123]

hey, big thanks for your answer :)

you have used also this 2x1nF ? I do not have these two parts and have ordered them now

[Poil]

Yep :)

[PAL123]

Thanks, I will report as soon as I have the two parts

[PAL123]

I have still this tremble problem. As soon i have my finger on the Sensor, it starts tremble.

@Poil can you check if its the same for you?

[nameless1]

I am having the same jitter problem with the throttle and z rotation, did you ever figure out what the problem was? I am contemplating tearing the circuit apart and rebuilding it if I have to.

[PAL123]

I wish I had found the problem. thought it was only with me

[PAL123]

nobody has an idea why the problem exists?

[caveman-bob]

I'll be building this soon for windows 10. I'll report back how well it works and will try to diagnose any issues.

[PAL123]

i know that there are two versions of sidewinder force feedback. One comes with a gameport to USB adapter and I have one without. Hope it has nothing to do with it.

[isopix]

@PAL123: Are you sure sure there were FFP1 joystick with USB adapter ever? I know there was very similar(but lacking Force Feedback) Precision Pro joystick, that came on updated version, that sported USB adapter: https://en.wikipedia.org/wiki/Microsoft_SideWinder

But as I know, there were only two significiant revisions of Force Feedback Pro 1, there original with noisy fan, that has been replaced very early (because of complaints in reviews), by fanless versions (because FAN was never really needed, but the Microsoft enginers put it on case of...)

On 5/16/20, PAL123 notifications@github.com wrote:

i know that there are two versions of sidewinder force feedback. One comes with a gameport to USB adapter and I have one without. Hope it has nothing to do with it.

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/tloimu/adapt-ffb-joy/issues/23#issuecomment-629641405

[PAL123]

@isopix you are right, this is the Sidewinder Precision Pro. Sorry for confusing this but I definitely have the Sidewinder Forcefeedback Pro

[HotteX]

I can only confirm the issue with my setup (FFB1 without fan): Both axes start to tremble when the sensor is activated (but the stick is untouched). C1 and C2 values dont seem to change anything about that behaviour.

Pity that this wonderful project seems to be abandoned. :(

[PAL123]

bad to read... i still hope that someone will adress the problem

[HotteX]

What I have to add: The tremble is there when I look at the windows setting, but at least in Freespace 2 its not an issue that is detectable ingame, even with a low dead zone.

My problem at the moment is, that the FFB is often lost, when I move the stick quickly (Stick starts flashing green). Sometimes it recovers soon after, sometimes, I have to repower the stick (Not the Teensy/USB!). Behaviour is the same with no Capacitors, with 100 pF and with 1nF. With 10 nF no FFB is possible.

Anyone ever had that? I surely hope that its a bad connection caused by my breadboard and it vanishes as soon as I solder it down, but I have my doubts. Issue gets a lot worse when I connect 4 potis.

[HotteX]

Pal123, do you have a breadboard setup or soldered everything down? in another forum I read about people with that issue saying it went away when all connections are short & soldered versus the usual wire-chaos on a breadboard.

[PAL123]

@HotteX I provisionally soldered it together as in the picture. I cut off the gameport connector before https://i.imgur.com/bB4BO79.jpg

[lucaceriani]

I had the same issues i solved by using a hex file i found online, now the ffb works every time and it is stable. I forked the repo chek it out.

Edit: link to my fork

[PAL123]

@lucaceriani link?

[lucaceriani]

@PAL123 I added the link

[HotteX]

@lucaceriani I have the same issues with your file as well (still Breadboard with rough connections)

[lucaceriani]

@HotteX I have soldered everything breadboard I found are not so stable. I also added the capacitors if that helps.

[marccreal]

I have the same jitter-issue. I don't think it's an issue with the adapter because I connected the joystick to an old computer of mine that still has gameport and is running on WinXP (the joystick is autodetected by windows, no drivers needed). I can see exactly the same jitter issue there.

[DEV-OGRE]

Added a frame buffer and dead zone to accommodate for jitter both in the Z Rotation and Throttle. It's not perfect (as it's just averaging out the last 150 polls), but it definitely smooths out the experience when playing things like MSFS2020.

https://github.com/zduford/adapt-ffb-joy/tree/feature/shift-and-frame-buffer

The hex is in the top level folder if you don't want to compile it yourself.

EDIT: Also forgot to mention I branched off of the 16 button shift at https://github.com/r8dhex/adapt-ffb-joy because I really liked having the shift feature.

2ND EDIT: Removed the deadzone part of code (by fixing the center calc) and more properly calculated the polled average, added a curve to the calc to better help fight latency with velocity.

[DEV-OGRE]

Leaving another comment, added a secondary Hex file to the repository that attempts to reduce jitter on the joystick axis' with a smaller frame pool.

This one's rather subjective, as it will introduce very minuscule (nearly not noticeable) lag when moving the stick from the min point on its axis to its max. I don't notice it at all when playing the games I play but I don't want to lock someone into using it if they do.

Because of that, I left both the original jitter compensated hex (only throttle and Z rotation) and added the new hex with the x and y compensation to the repository.

https://github.com/zduford/adapt-ffb-joy/tree/feature/shift-and-frame-buffer

[marccreal]

Thanks a lot for your efforts! I will try it out as soon as I'm back home. I thought about implementing such a moving average as well but didn't quite get through the code yet.

To get more responsiveness, one could also try to implement a Kalman filter - but I have no experience with thos. Another thing I will try to look at, is the frequency spectrum of the noise. If the noise is in a clear frequency band, maybe one could filter it out more effectively with a band pass.

On the hardware side I looked at the design of the joystick and also opened up my own device. The position and rotation of the stick and also the throttle is detected by a camera, that detects two LEDs fixed at the stick and one at the throttle (nice concept!!). At the moment, I cannot really imagine where this noise comes in, as the position is detected optically and transmitted digitally via the midi channel. I disconnected the ffb-motors from the board and the noise vanished, so the noise seems to be a direct consequence of the motors being active. But I don't see how the noise could be induced by some kind of crosstalk and there also isn't any visible motion noise and even if the motors would induced some when active, this should not have an effect on the throttle.

One other root cause I can think of is that the LEDs brightness goes down when ffb is active and the thereby the optical detection gets noisy. As they are IR, you cannot see anything by eye. It would still be strange if this is really the cause, as the motors have a separate power connection ( the 12V external power supply) while the electronics of the stick are powered by the 5V provided by the Gameport.

Edit: one thing I noticed in your code: if I'm not mistaken, you don't seem to include the most recent position reading into the averaging. This should give a tiny bit of more responsiveness.

Edit2: I'm happy to see, that I'm not the only one who reactivates his ancient Joystick for MSFS2020 ;-)

[PAL123]

first of all thank you for looking for the error.

I tried the hex from @lucaceriani and @zduford. the hex from @lucaceriani tremble as usual and the hex from @zduford a little less. apart from that, it is not only the tremble in the middle position, but generally also when moving.

I think the assumption of @marccreal that maybe something is disturbed is more likely.

tomorrow I will shorten the resistors and the capacitors wire length to a minimum and let's see if that helps, maybe @HotteX is right that the wires should be very short. because the malfunction may arise from the transmission to or from the Teensy 2.0.

And finally I can say that I flew the first time FS2020 with the joystick. Apparently the simulator does not transmit its own force feedback to the joystick :(. I only had the force feedback throughout, which was also used in win 10 as a basis. Is it the same with you?

[HotteX]

Added a frame buffer ~and dead zone~ to accommodate for jitter both in the Z Rotation and Throttle. It's not perfect (as it's just averaging out the last 150 polls), but it definitely smooths out the experience when playing things like MSFS2020.

Thanks man, this really helps a lot with the jitter (and I can live with a slow Axis for those 2)

[DEV-OGRE]

Yeah I'm pretty sure the jitter is due to some joint degradation on the joystick's motherboard, I'm confident reflowing some of the connections would help with the noise but personally I'm terrible at soldering so I'm hoping to find a good solution in code lol.

Good tip on the Kalman filter @marccreal! I'll see if I can find an existing implementation to import into the project later and see if I can use that instead as a good approximation algorithm instead of the rolling average.

[marccreal]

Apparently the simulator does not transmit its own force feedback to the joystick There is no FFB implemented in MSFS. FFB became quite unimportant.

because the malfunction may arise from the transmission to or from the Teensy 2.0. As I posted above, the noise does not come from the adapter! It is also there, when I use the joystick in Windows XP directly (without adapter, Gameport is still supported under XP and there is a built in driver for the FFB Pro under XP).

I'm confident reflowing some of the connections would help with the noise Interesting! I will look into that. I'm quite confident with soldering, recently worked on an old C64 Board. The FFB Pro board also has quite handy dimensions for soldering.

[PAL123]

As I posted above, the noise does not come from the adapter! It is also there, when I use the joystick in Windows XP directly (without adapter, Gameport is still supported under XP and there is a built in driver for the FFB Pro under XP).

So our joysticks all broke over time and have the same error?

I also have a small reflow station and could go through the connections on the board. The only question I am asking is what the exact cause is, because we know that it only tremble when the ffb is active. Perhaps there is leakage current somewhere, or a component is defective?

[marccreal]

So our joysticks all broke over time and have the same error?

Good question... Would be helpful to know, if there are sticks that do not show this problem...

One final thing I would like to check is running the stick with the original drivers under Win98 and see if the problem is apparent there, too. Just to be sure that there is no difference between the original driver and the built-in XP driver (the original one does not run under XP).

As far as I understand, all position data is sent digitally through the Midi Port, right? But there are also two analogue channels (for compatibility?). Could someone check with an oscilloscope, what these outputs do when ffb is active?

[marccreal]

Ok, after some digging, I found this patent, where the technology of the MS joystick is described: https://patents.google.com/patent/US5628686A/en In Fig3b, you see the optical position detection. It seems to utilize some kind of 4-quadrant photodiode/PSD (https://en.m.wikipedia.org/wiki/Position_sensitive_device). This type of diode is good for detecting the center of gravity of a light spot with high repetition rate (with a camera, for that, some potentially slow image processing is necessary). But the position signal is analogue. So this is the point where noise can go into the position detection.

Edit: here the patent where the position detection itself is described: https://patents.google.com/patent/EP0842489B1/ar

[PAL123]

maybe someone can boot up win98 from usb stick? i dont have gameport

[HotteX]

I just bought a PCI soundcard and will have a look as soon as I get the dust off the old hardware

[HotteX]

After diving deep into a dusty attic, trying to setup Windows 98SE, accepting, that my old enormous 80GB Harddrive is too big for booting, finding a fitting driver. Finding out, that the damn driver requests more than 256 colors, fighting the evil spirits of "Address conflict" I can honestly report:

Exactly the same.

Tested with Windows 98SE, DirectX 9c and Driver Version 3.02. As soon as the FF activates, the axes start to tremble a little. It's not very good to see, as Win98 does not have the nice bars of the later controller settings but it is definitely there in the same way. This is not a tinker-issue.

At least now I can enjoy the Force Tester like'em did in the old days (when I could have never ever afforded a FFB Joystick).

@PAL123 Could you change the topic to something like "Trembling axes, when FF-Sensor is activated" for easier orientation, as this seems to be a (maybe aging, maybe even production) hardware issue and not Win10 compatibility.

[PAL123]

sad to read that it leads to the same problems with windows 98

[cbhacking]

Glad I checked the issues page before just forking the project to try adding smoothing on those axes in the microcontroller. I have the same problem with wobble on rotation and throttle. Sidewinder FFP, I have tried both with and without the capacitors, no difference detected (I'm using a pretty cheap breadboard but it sounds like that's not the problem).

One interesting effect is that it's only present when the FFB is actually active. That is, it detects your hand on the stick, and there's either some software commanding a particular effect or no FFB software at all so it's just doing the default centering. If I avoid the front of the stick where the sensors are, or launch ForceTest with no effects specified and then grip the stick properly, the wobble goes away even when the stick moves (aside from some strange behavior on the rotation that I think is unrelated).

[tloimu]

Setting this as not-fixing as this seems to be a feature of the stick itself

[DinhoRjBR]

Deixando outro comentário, adicionei um arquivo Hex secundário ao repositório que tenta reduzir o jitter no eixo do joystick com um conjunto de quadros menor.

Este é bastante subjetivo, pois introduzirá um atraso muito farmacêutico (quase imperceptível) ao mover o stick do ponto mínimo em seu eixo para o máximo. Não percebo nada quando jogo os jogos que jogo, mas não quero obrigar alguém a usá-lo se o fizer.

Por causa disso, deixei o hex original com compensação de jitter (apenas interpretação e rotação Z) e adicionei o novo hex com a compensação xey ao repositório.

https://github.com/zduford/adapt-ffb-joy/tree/feature/shift-and-frame-buffer

@DEV-OGRE I come to ask for help and rescuing the topic. I have the jitter effect in my project with Sidewinder FFB PRO. I tested several .HEX files. I really liked the solution via software with the Frame-Buffer, including on the X and Y axes, but for some games, the Control does not work the FFB. Let me explain better.. With the firmware .HEX below https://github.com/Kreeblah/SidewinderToUSBV2/blob/main/Firmware/adaptffbjoy-r54-JayBee.hex The controller worked in all games. Using firmware with Frame-Buffer some like Freespace 2 does not work any FFB effect. Is it possible to put the Buffer Frame in this Firmware version? "JayBee - So I made a firmware that uses most of the fixes of other firmware (Shift+buttons, joystick name change), disables the debug and serial mode (that were causing issues), and also completely disables the Z, Rx, Ry and Rudder axis for maximum compatibility (now games like Freespace2 or Crimson Skies work perfectly)." https://github.com/JayBee-git/adapt-ffb ... -Clean.hex

For the Hardware, I disassembled the control and saw 4 Electrolytic capacitors on the motherboard. I removed and measured.. the results are:

2x 100uF --> were at 2x 125uF -- 25% 1x 470uF --> was at 1x 496uF -- 5.5 % 1x 2200uF -->was 1x 2465uF --12 %

I haven't bought any other capacitors yet, but I thought they might be responsible for the jitter.

[isopix]

I'm not an electronic. But if capacitors have higher capacity than nominal, isn't that a good thing?

And about removing features, like Z, Rx, Ry and rudder, I think that we could make few switches (and even some postion, where it could be controlled from software, but under linux[I guess that for windows too] there is remapping software, that would be best option, to create some virtual devic(lacking problematic features)

On 2/4/23, DinhoRjBR @.***> wrote:

Deixando outro comentário, adicionei um arquivo Hex secundário ao repositório que tenta reduzir o jitter no eixo do joystick com um conjunto de quadros menor.

Este é bastante subjetivo, pois introduzirá um atraso muito farmacêutico (quase imperceptível) ao mover o stick do ponto mínimo em seu eixo para o máximo. Não percebo nada quando jogo os jogos que jogo, mas não quero obrigar alguém a usá-lo se o fizer.

Por causa disso, deixei o hex original com compensação de jitter (apenas interpretação e rotação Z) e adicionei o novo hex com a compensação xey ao repositório.

https://github.com/zduford/adapt-ffb-joy/tree/feature/shift-and-frame-buffer

I come to ask for help and rescuing the topic. I have the jitter effect in my project with Sidewinder FFB PRO. I tested several .HEX files. I really liked the solution via software with the Frame-Buffer, including on the X and Y axes, but for some games, the Control does not work the FFB. Let me explain better.. With the firmware .HEX below https://github.com/Kreeblah/SidewinderToUSBV2/blob/main/Firmware/adaptffbjoy-r54-JayBee.hex

The controller worked in all games. Using firmware with Frame-Buffer some like Freespace 2 does not work any FFB effect. Is it possible to put the Buffer Frame in this Firmware version?

"JayBee - So I made a firmware that uses most of the fixes of other firmware (Shift+buttons, joystick name change), disables the debug and serial mode (that were causing issues), and also completely disables the Z, Rx, Ry and Rudder axis for maximum compatibility (now games like Freespace2 or Crimson Skies work perfectly)."

https://github.com/JayBee-git/adapt-ffb ... -Clean.hex

For the Hardware, I disassembled the control and saw 4 Electrolytic capacitors on the motherboard. I removed and measured.. the results are:

2x 100uF --> were at 2x 125uF -- 25%

1x 470uF --> was at 1x 496uF -- 5.5 %

1x 2200uF -->was 1x 2465uF --12 %

I haven't bought any other capacitors yet, but I thought they might be responsible for the jitter.

--

Reply to this email directly or view it on GitHub:

https://github.com/tloimu/adapt-ffb-joy/issues/23#issuecomment-1416831231

You are receiving this because you were mentioned.

Message ID: @.***>

[DinhoRjBR]

I'm not an electronics technician either, but electrolytic capacitors have a useful life. We're talking more than 25 years. I read that when capacitors are old, they tend to increase capacitance. Well... the idea is to understand why some controls show jitter and others don't, but only when they "turn on" the FFB engines. As for disabling the axes, I wouldn't have any problem keeping them, but some games simply don't identify the FFB, it doesn't work at all.. With the Firmware I left the link, they all worked. So it would be interesting to have the latest firmware with the Frame-buffer feature to use with jitter control.

[isopix]

I understand problem with old games and proposed switching between diffferent modes, using physical switch. I'ts the easiest solution, and gamepads/joysticks supported that in the past. Even logitech wheels (like G27 or G29) had such switch(above the wheel).

On 2/4/23, DinhoRjBR @.***> wrote:

I'm not an electronics technician either, but electrolytic capacitors have a useful life. We're talking more than 25 years. I read that when capacitors are old, they tend to increase capacitance. Well... the idea is to understand why some controls show jitter and others don't, but only when they "turn on" the FFB engines. As for disabling the axes, I wouldn't have any problem keeping them, but some games simply don't identify the FFB, it doesn't work at all.. With the Firmware I left the link, they all worked. So it would be interesting to have the latest firmware with the Frame-buffer feature to use with jitter control.

-- Reply to this email directly or view it on GitHub: https://github.com/tloimu/adapt-ffb-joy/issues/23#issuecomment-1416841270 You are receiving this because you were mentioned.

Message ID: @.***>

[DinhoRjBR]

There was a DB15 to USB adapter that had 4 switch positions, and depending on the position a type of control worked. This adapter never worked Force Feedback, but the idea would be similar to the firmwares with and without extra axes?

[isopix]

Yes, it's easy to do. simply switch hid descriptor and reconnect joystick. "Different firmwars we currently have are mostly forks one one-two original repos and changes are usually small.

I also have this adapter, but in the past gamepads/joypads switched modes, because gameport had very limited number of shared axes/buttons. There were also joysticks(like famous CH-products and Logitech) that switched between standard gameport mode and some digital mode.

On 2/4/23, DinhoRjBR @.***> wrote:

There was a DB15 to USB adapter that had 4 switch positions, and depending on the position a type of control worked. This adapter never worked Force Feedback, but the idea would be similar to the firmwares with and without extra axes?

-- Reply to this email directly or view it on GitHub: https://github.com/tloimu/adapt-ffb-joy/issues/23#issuecomment-1416847530 You are receiving this because you were mentioned.

Message ID: @.***>

[DinhoRjBR]

I'm rooting if the idea can be implemented. While we don't have it, the version with jitter reduction, Frame-Buffer, would be interesting, on top of the latest firmware that works all the games I tested. The best would be to end the jitter. I'm going to try to buy the capacitors and change them. There are also 5 trimmer resistors on the motherboard. are usually used for some adjustment. But since I can't measure resistance, I'm afraid to move.

[isopix]

Remember to share results.

And why you can't measure resistance? Because you would need to desolder them first?

On 2/4/23, DinhoRjBR @.***> wrote:

I'm rooting if the idea can be implemented. While we don't have it, the version with jitter reduction, Frame-Buffer, would be interesting, on top of the latest firmware that works all the games I tested. The best would be to end the jitter. I'm going to try to buy the capacitors and change them. There are also 5 trimmer resistors on the motherboard. are usually used for some adjustment. But since I can't measure resistance, I'm afraid to move.

-- Reply to this email directly or view it on GitHub: https://github.com/tloimu/adapt-ffb-joy/issues/23#issuecomment-1416851095 You are receiving this because you were mentioned.

Message ID: @.***>

[DinhoRjBR]

Sure... changing the capacitors I inform the result. As for the trimmer resistor, the multimeter did not return a result, as infinite resistance and as I don't know what they are for, I decided not to touch them.

[nhede]

I had this problem too, it is motor noise, and after some experimenting I found a simple working solution. Things needed: krapton tape, copper tape and soldering iron. Maybe this should be in the build wiki, it would be very helpful for people.

[ej113]

Neat! I'd like to try this. Is the kapton tape to insulate the solder pads from the copper? What's the solder needed for?

I was thinking of making a wiki page for mods and repairs to the FFP, with things like button replacements, power connector spec (EIAJ04) etc.