Question Encoder Desync?

Hey Everyone,

I'm working on a DIY wheel using an stm32 board and MMOS FFB. Everything has been going pretty good so far except for the fact that I cannot get the encoder to stay synced as in having a constant center position. I'm thinking that it is a problem with my wiring or how I have my encoder attached to the wheel shaft. I have my encoder attached using a belt, I haven't noticed any slipping going on though. I have my wiring setup on a bread board and the only thing I can think of is that some of the wires may not always be in contact with each other. Most importantly, I'm wondering if anyone else has faced this issue as I've found no other forum discussing it.

Thanks for all of your help!

Is it a toothed belt with toothed pulleys? I think smooth belts do tend to slip.

I have it attached with a smooth belt temporarily, however I plan on directly mounting the encoder to the wheel shaft. I don't think it's an issue with the belt slipping though because it occurs even when I rotate the wheel slowly without FFB on. Also I forgot to say that I'm using a CALT GHS38 2000 ppr 3 phase encoder, I made sure to enable use encoder index in the force feedback application.

This is such an issue out there. The thing is not with slacks in mechanical connections to encoder. Or the index issue, due to that encoder may have only AB channels too. Or the lack of power, stm powering encoder, motor driver etc.


There may be due to the non-direct stm connection to PC, through the usb hab. Or bad usb hab. It's said as if to better use the hab with stand alone power supply units. That's a one thing.


And another, main thing that it's some issues besides it. Don't know the real reasons to it, weather soft config or the stm itself, but it can be set with on/off the stm board, and check the behavior. Pay attention when you switch configs or so. Does it change to normal operation. That should help. So it can be settled by that at least) As example, you switch on, it is working good, then you switch the config or so, and then comes the encoder pranks)

And a good thing will be naturally to connect properly all the encoder wires.

Bay the way. Never encountered such encoder issues with the arduino and EMC soft.

Yeah, I'm starting to suspect my wiring is the problem. I started on an arduino leonardo with EMC pro and had the same issue which is why I ended up swapping to the stm32. I guess I will have to pull out the soldering iron and see what my results are. Just to confirm, I should be using 4.7k resistors from power to the A, B, and Z wires from the encoder, I would like to make sure before I solder it all and possibly have more issues.

Nint, it's more than just bad wire connections. Tested.

4.7 kohm are wrong choise too. Don't know the reason EMC guidelines are with them, but it works good only when 12 volts are given to pull ups. Better use from 50-600 ohms. 4.7 k are too much if 5v are taken from controller board.

Well that's odd, is there anything more about the guidelines that I should know about?

Alright well, I've soldered up my circuit where I can test different resistors and I have to say I think my problem has been solved. I have only done a little bit of testing, however the results seem promising so far. Thanks for your help Sieben!

No, I don't know, it's seriously may do have some questions indeed. But can be explained, as far it were checked that way. I'll describe it like that. I surveyed with DXtweak the wheel axis slider and it do have lags. When noticed that things. The connection were rechecked and it was fine. Then by using the mmos default profile, by turn off/turn on the board, just set the force sliders etc, for the sake not to mess up with saving loading/profiles. The x axis slider goes well in dxtweak. Check properly it in a game. All is fine. Then switch to previously saved profile, and here goes a prank.

May be it deflects somehow due to the switched off encoder, and then loading profiles saved before it has another records on it etc. The hit to center wheel do set new center, but doesn’t solve the “lags” after all. Smth like that) So just good connections, and presumably better no disconnections of encoder, with switched on board, and all should be fine.