MobiFlight Community Support

Hello, I have been trying to implement rotary encoders into my project. I have about 20+- EC12s.

The problem i hit is that my encoders are bouncing quite a lot. (yes everything is connected/grounded properly.
They are standard EC12 20-detent encoders.

I have tried connecting about 7 of them and they all seems to be having the issue.

When I run mobiflight offline, and i do the standard text editor test.
I have assigned
Left: A
LeftFast: X
Right: B
RightFast: Y

Just by doing standard constant slow rotations, I can see the opposite direction pop up once in a while "AAAAAAAABAAAAA"

If I spin it and then suddenly stop, usually the end gets noticed as the opposite direction: "BBBBBBBBBA"

If I try to spin it longer to get to the fast action, I can still sometimes observe opposite directions being registered, both slow and fast. "AAAXAXAAXXYXXABAAA"


Has anyone else experienced bouncing ? I know that arduino sometimes bounce when using interrupts for encoders and the solution is to poll it in loop, but this can not be applied for MF as it uses its own firmare.

Any suggestions/tips?

Thank you

We know this .
Sebastian means the only way to get this perfectly would be using the interupts. But then "freedom" is missing. this will reduce the number of Devices and also the posibility to set the encoder to each Pin you like. If we change then only some pins are useable for the encoders.

About the problem.

In a longer testing Stephan, Sebastian and myself come to the point (in our testing situation) the number of wrong data is "verry" small and with a "normal" speed of turning the number is nearly zero.

A Latching switch taht bounce will occure in a missing event and a non sync situation..... But a Encoder ??? If you turn it 10 detents. Who cares about if you send 10,9 or 8 Commands ? Also who care about if 6 Commands are correctly INC and 2 were DEC by fault..... Important is if i turn right and got more INC as fault DEC then my value grow up.

To fine tune the value ( e.g. to hit exactly 220° on the heading) we figure out if you turn it slowly like 1-2 detents per second with a little delay between each detent then 100% of commands recived by the sim.

The real extreme problem with missing of >50% of commands or more faults as correct inputs only happen for us if we turn the Encoder "unrealistic" fast that never happens also in a real cockpit.

*******************
Summary: We think this situation is not perfect.... Interupts would be better but have disadvantage, too. Finaly if user take care for a "normal" speed of turning the issues are acceptable i think.
If you like..... Send us a example video.... So we can see what happen and can "define" your turning speed as "normal" or as "crazy"

I see the issue.

The flexibility is important part of this. But would it be possible to detect an encoder in an interrupt-capable pin, and just enable the interrupt for that encoder, so it would just work more reliably?

Maybe....

Please make a Official Request in Bitbucket or contact Sebastian personaly via Discord!

Hi, I wanted to add my my .02. First the work here is really good especially for low speed. The fact that you were able to build a solution that works with all sorts of different HW is impressive. I understand you are dealing with a lot of random crappy hardware, I'm using some myself. I find that if I turn the rotary just fast enough to trigger the fast bit i.e. 3 vs 2. I will start to get bounces. The encoder always bounces with a high speed 1 in the other direction. I would think a small state machine on the last X values would help out here. If the last 2-3 values were high speed and then very next one is a high speed in reverse this should get dropped once. If it is a low speed in the reverse direction (0) take it. I'm turning at a rate to generate an event at 50-100ms which seems within reason.
20:04:39.044 -> 6,SR_TRIM,2;
20:04:39.091 -> 6,SR_TRIM,2;
20:04:39.185 -> 6,SR_TRIM,3;
20:04:39.278 -> 6,SR_TRIM,1;
20:04:39.325 -> 6,SR_TRIM,3;
20:04:39.372 -> 6,SR_TRIM,3;
20:04:39.467 -> 6,SR_TRIM,3;
20:04:39.511 -> 6,SR_TRIM,3;
20:04:39.558 -> 6,SR_TRIM,1;
20:04:39.652 -> 6,SR_TRIM,3;
20:04:39.699 -> 6,SR_TRIM,3;
20:04:39.792 -> 6,SR_TRIM,3;
20:04:39.839 -> 6,SR_TRIM,3;
20:04:39.933 -> 6,SR_TRIM,1;
20:04:39.981 -> 6,SR_TRIM,3;
20:04:40.075 -> 6,SR_TRIM,3;
20:04:40.122 -> 6,SR_TRIM,3;
20:04:40.215 -> 6,SR_TRIM,3;
20:04:40.309 -> 6,SR_TRIM,3;
20:04:40.356 -> 6,SR_TRIM,3;
20:04:40.450 -> 6,SR_TRIM,3;
20:04:40.495 -> 6,SR_TRIM,3;
20:04:40.588 -> 6,SR_TRIM,1;
20:04:40.635 -> 6,SR_TRIM,3;
20:04:40.682 -> 6,SR_TRIM,3;
20:04:40.776 -> 6,SR_TRIM,3;
20:04:40.823 -> 6,SR_TRIM,3;
20:04:40.917 -> 6,SR_TRIM,3;
20:04:40.963 -> 6,SR_TRIM,1;
20:04:41.044 -> 6,SR_TRIM,3;
20:04:41.091 -> 6,SR_TRIM,3;
20:04:41.185 -> 6,SR_TRIM,3;
20:04:41.232 -> 6,SR_TRIM,3;
20:04:41.325 -> 6,SR_TRIM,3;
20:04:41.372 -> 6,SR_TRIM,3;
20:04:41.467 -> 6,SR_TRIM,1;
20:04:41.557 -> 6,SR_TRIM,3;
20:04:41.604 -> 6,SR_TRIM,3;
20:04:41.698 -> 6,SR_TRIM,3;
20:04:41.792 -> 6,SR_TRIM,3;
20:04:41.839 -> 6,SR_TRIM,2;
20:04:41.886 -> 6,SR_TRIM,3;
20:04:41.981 -> 6,SR_TRIM,3;
20:04:42.028 -> 6,SR_TRIM,3;
20:04:42.121 -> 6,SR_TRIM,3;
20:04:42.168 -> 6,SR_TRIM,1;
20:04:42.262 -> 6,SR_TRIM,3;
20:04:42.356 -> 6,SR_TRIM,3;
20:04:42.403 -> 6,SR_TRIM,3;
20:04:42.496 -> 6,SR_TRIM,3;
20:04:42.578 -> 6,SR_TRIM,3;
20:04:42.671 -> 6,SR_TRIM,3;
20:04:42.718 -> 6,SR_TRIM,3;
20:04:42.812 -> 6,SR_TRIM,3;
20:04:42.859 -> 6,SR_TRIM,1;
20:04:42.989 -> 6,SR_TRIM,3;
20:04:43.083 -> 6,SR_TRIM,3;
20:04:43.130 -> 6,SR_TRIM,3;
20:04:43.224 -> 6,SR_TRIM,3;
20:04:43.270 -> 6,SR_TRIM,3;
20:04:43.317 -> 6,SR_TRIM,3;
20:04:43.364 -> 6,SR_TRIM,3;
20:04:43.411 -> 6,SR_TRIM,1;
20:04:43.467 -> 6,SR_TRIM,3;
20:04:43.561 -> 6,SR_TRIM,3;
20:04:43.607 -> 6,SR_TRIM,3;
20:04:43.701 -> 6,SR_TRIM,1;
20:04:43.748 -> 6,SR_TRIM,3;
20:04:43.842 -> 6,SR_TRIM,3;
20:04:43.889 -> 6,SR_TRIM,3;
20:04:43.988 -> 6,SR_TRIM,3;
20:04:44.035 -> 6,SR_TRIM,3;
20:04:44.081 -> 6,SR_TRIM,1;
20:04:44.175 -> 6,SR_TRIM,3;
20:04:44.269 -> 6,SR_TRIM,3;
20:04:44.316 -> 6,SR_TRIM,3;
20:04:44.410 -> 6,SR_TRIM,3;
20:04:44.496 -> 6,SR_TRIM,3;
20:04:44.590 -> 6,SR_TRIM,2;
20:04:44.637 -> 6,SR_TRIM,2;
20:04:44.731 -> 6,SR_TRIM,3;
20:04:44.778 -> 6,SR_TRIM,1;
20:04:44.871 -> 6,SR_TRIM,3;
20:04:44.918 -> 6,SR_TRIM,3;
20:04:45.012 -> 6,SR_TRIM,3;
20:04:45.059 -> 6,SR_TRIM,3;
20:04:45.152 -> 6,SR_TRIM,3;
20:04:45.246 -> 6,SR_TRIM,3;
20:04:45.293 -> 6,SR_TRIM,1;


All sort of documentation out there for software solutions (https://www.best-microcontroller-projects.com/rotary-encoder.html). I'm thinking I might look at building a few ICs with an ELM401 or something like this: https://hackaday.io/project/162207-hardware-debounced-rotary-encoder

There is a bug in the actual firmware of the Arduinos which will lead to one steo into the opposite direction after a number of steps of an encoder. The bug is an overflow of a variable inside the encoder routine. The overflow will happen after 32758 divided by EncoderSteps per detent if turning slow, but if turning fast internally the steps will be increased depending on the speed encoders are turnes. By fast turning an oppsite step can happen down to <10 detents for a 4 step encoder. Sebastain already fixed this within the firmwarre, but I don't know if this is already released at least for the beta software.
With this bugfix it could still happen, that some encoder stepsare not recognized during very! fast turning. But an step into the opposite direction will not occur, and the missing step(s) will mainly not be recognized.
Using an PinChangeInterrupt for reading the encoders is not a good idea, as this can lead to very high processor load and eventually a disturbance of the serial connection. Using a TimerInterupt for reading the Pins of the encoder could improve the situation for less encoders, but with a lot of encoders it is highly probably that the serial connection will also be interrupted.

In my opinion this can only be avoided by using a faster processor where reading all Encoder Pins <1ms. I checked this on a Teensy4.1 where even with a TimerInterupt of 1ms and only one encoder steps could be missed. But again, you habe to turn really fast to come into this situation.

So I think it would be the best to wait for the next firmware release to see if your problem still exists (I believe not).

Regards

Ralf

Just for Information.....

The Fix of this Problem is currently NOT in the Beta !
Beta State ( a.t.m.) is 8.0.2.9 ...... the Encoder Part is done later.

Normaly we would release a new Beta (8.0.2.10) BUT as i know Sebastian is shortly before a new release ( 8.1.0) So it seems he not make another Beta for now and the Encoder Part will directly come live next days.

If you like to test today.... You need to download the MASTER State from Bitbucked ..... https://bitbucket.org/mobiflight/mobiflightfc/src/master/

Whatever.... If you be able to do this.... Then download it. If not simply wait some days for official release ( or another BETA) .... then you not need to do this by hand !

Cool yes I downloaded the _10 fw and can verify that this is fixed on my Mega Pro. Why the extra print to the serial?
19:16:34.838 -> 6,SR_TRIM,2;
19:16:34.885 -> 11
19:16:34.885 -> 6,SR_TRIM,2;
19:16:34.932 -> 19
19:16:34.932 -> 6,SR_TRIM,2;
19:16:34.979 -> 35
19:16:34.979 -> 6,SR_TRIM,2;
19:16:35.026 -> 53
19:16:35.026 -> 6,SR_TRIM,3;
19:16:35.026 -> 67
19:16:35.026 -> 6,SR_TRIM,3;
19:16:35.073 -> 67
19:16:35.073 -> 6,SR_TRIM,3;
19:16:35.119 -> 67
19:16:35.119 -> 6,SR_TRIM,3;
19:16:35.166 -> 67
19:16:35.166 -> 6,SR_TRIM,3;
19:16:35.166 -> 67
19:16:35.166 -> 6,SR_TRIM,3;
19:16:35.213 -> 67
19:16:35.213 -> 6,SR_TRIM,3;
19:16:35.260 -> 67
19:16:35.260 -> 6,SR_TRIM,3;
19:16:35.260 -> 67
19:16:35.260 -> 6,SR_TRIM,3;
19:16:35.307 -> 67
19:16:35.307 -> 6,SR_TRIM,3;

The extra serial prints seem to have broken the encoders in game. I'll dig around in the source to see where they are coming from looks like non final states on the encoder.

After spending some time looking through the code try to find the extra serial spew, I ended up recompiling everything App and FW. The spew is gone and I've been using the new FW for a little while now. I'm very happy with the changes and the lack of any reverse bounce on any of my encoders. Nice work!

Love that the project is open source and if there is something I really need I can just add it.