I think this might be 30 detents, 15 pulses, not 30 pulses. I was trying to find a 30 pulse today and all I could find was 32 pulse and it is quite expensive. Could be wrong but encoder descriptions can be a bit confusing between detents(position) and # of pulses.
I love this solution. Just looking through this thread and appreciate the authorās responses to questions. Very clever work to do this in my opinion. Iād love to have a wheel to change altitude on autopilot especially the Caravan!
1 Like
You could do that for about the same price.
Maybe. But it looks exactly like mine and mine has 30 impulses and cost less than 1$. In Poland you can buy like 5 different types with 30. Sellers are saying it is 30 impulses, so not positions. All are cheap. On AliExpress is easy for refund if seller is saying 30 impulses and you will get only 15. But in this case it is saying that is has 30 positions, so seller might not refund, but I think he will. They donāt want dispute for such small money.
edit: I just found encoder which looks exactly like mine with only 20 pulses, so judging by look is not good.
Change of altitude might be problematic and need different approach because you can assign only keys to it. It needs:
- external software which will connect to FS and will be updating altitude read from Arduino
or - Arduino should emulate key press with every impulse of the wheel. I tried this solution with trim and it worked but was jerky. Maybe later if will try this with autopilot. Maybe it will work better. Problem with this solution is that fast rotation of encoder is causing that not all key presses are registered. Before I tried this with keyboard emulation. Now will try with joystick button emulation. Maybe will be faster.
1 Like
You donāt usually buy these type of encoders by impulses. I wonder if this is a translation thing. They are specified in detents per pulse. There are generally either 1, 2 or 4 detents per pulse at this price point. The best way to communicate what you have is to count the number of clicks for a full revolution. You can get an encoder that has no detents/clicks which may or may not be better for this application. When I build my trim wheel I think Iāll experiment with both types.
Mine encoder which I bought in electropark (link somewhere in this thread) has 30 positions/clicks and 30 changes in A/B per revolution, so I am assuming it is 30/30?
What about 30 detents and 15 pulses? Wonāt those have 30 clicks and only every second click will generate a new A/B state? So ācount the number of clicks for a full revolutionā wonāt be true? Just asking because I have only basic knowledge of encoders. I was thinking that clicks=detents and impulses/pulses are A/B state changes. Is that correct?
If somebody want to check real resolution of his encoder then just enable println (remove /* and */) in my code. You should see in Arduino IDE console rotation values.
Itās an interesting subject. This has got me thinking, so what is the best encoder to use, the real top of the line one? I imagine nearly everyone is using EC11 types.
Cheap EC11 for 1$ with 30 real positions is really nice to use. I am using such and mine brother too. We donāt want upgrade to something better. I think that 15 positions would be bad. Would feel to clicky and angle of one step would be too big. But 24 positions maybe would be OK. If somebody canāt find real 30 then should give a try to real 24 and post here a report. BTW report should be send after wheel mount because with wheel, which has weight, encoder feels different.
FYI: āReal 30ā means that encoder has 30 steps (clicks) per revolution and it will report 30 different positions (so should be 30 changes of A/B states).
I tested using wheel on AP altitude and it feels bad. Problem with this is that AP altitude can be only bind to keys/buttons (no analog). With keys only bind there are two easy solutions and both are bad and one proper which is most complicated. Those solutions will be valid to any usage of wheel when there are only keys/buttons bindings.
Bad1: Rotating the wheel will generate short button/key press. Problem with this solution: it will lost a few presses when wheel will be rotated fast and will lost a lot of presses when wheel will be rotated very fast.
Bad2: Rotating the wheel will generate button/key press until wheel stops rotating. Problem with this solution: speed of wheel rotation doesnāt matter. Rate of updating instruments will depends of FS implementation. For example trim wheel in FS will speed up (long press) but user will be rotating his physical wheel at constant speed.
Best1: External software is required which will be connected to FS via simconnect and will be directly updating sim with data from Arduino.
Thanks a lot for the detailed reply. Iāll have a look at a few other solutions. Take it easy.
Thanks for giving a nice project to try. Unfortunately for me, it definitely isnāt working well at all. Only encoder I could get in the uk without waiting months for shipping was 24 pulse 24 position. Tried this just now and I donāt know if itās dodgy components or some compatibility issue with the code, but even in joy.cplā¦ it takes an absolute age to get the axis to move in any direction at all. Like from middle to top is probably around 100 full turns or moreā¦ also turning one way works worse than the other, so it takes about 200 full rotations to get it back to the middle and another 200 to get it to the bottomā¦ when I turn it in this direction, itās like some turns move it correctly and others move it back up in the wrong direction.
So think Iām gonna admit defeat and say that this project is a bit over my head. Thanks for the ideas though, still a fun little thing to try.
No worries it is probably the code. Looks like encoders are different. This would explain why I tested three different source codes from internet and all worked different and wrong, so I wrote mine own code. It should be 255/24 = 10,5 full rotation to go up from center.
Try replace first RotDir = 1; to RotDir = -1; and second from -1 to 1. Do not change third and fourth. When I replace this I got same results as you, so this should fix yours problems 
To check what is exactly going on you can enable println (remove /* and */) in the code. You should see in Arduino IDE Serial Monitor (enable it in Tools) rotation values. Enable it only for tests because later if might delay performance.
If this doesnāt work I will post a code to get flow of encoder. With those values it will be very easy to fix it.
thanks, iāll give this a go after work later
ooops, Iāve also just realised, the board has ground pins on either sideā¦i might have plugged it in to the opposite side by mistake? does this matter?
Just tested. Either of 2 ways can fix the bad response.
Either swap the 1 and -1 as you said, or swap the ground pin used.
Once I swapped the ground pin to be the same side as the other 2 pins, I didnāt need to swap the values in the code. It works fine.
Now to work out how the hell Iām gonna mount it all and then how to add a second rotary encoder.
Iāve been using the logitech multipanel trim for elevator trim and it actually works pretty well, so I might try and set up this home made kit for rudder and aileron trim wheels.
Devices with native support from the sim will be always the best. When any system will change the trim then device is updated with new value directly by the sim. This is biggest problem of home made devices to receive synced feedback from the sim.