Could we have un-accelerated multiplier for encoder?

I tried acceleration (to speed up rotation of HSI_Sel_CRS) as described in but it results in jerky movement for my (amazon B07DM2YMT4 20-detents encoders) . It feels as if some knob turns are accelerated but some are not.

Single turns work okay but attempts to rotate an indicator 180 degrees at "+++" acceleration "as fast as I can" results in the turns moving a only bit faster than usual snail pace (38 turns needed at "+++" vs 52 for acceleration "No"). "Slow turns" result indeed in 10 knobs needed turn, but are weird for fine tuning (for example: turn right then left results in the indicator going wildly off).

Of course a mechanical multiplier would be ideal but that's beyond my mechanical skill :-) and not sure if I'd have space between knobs.
closed with the note: arch
3 weeks ago in Digital Inputs by

2 Answers

- Any encoder (any cheapest one) should work smoothly and with with any acceleration in SimVim.
The full 360 degrees you should run with just 2-3 fast turns.
- No "mechanical" multiplier needed (why and how?)
- Make sure you use a "barebone" encoder, no any breakout board.
3 weeks ago by
With no acceleration: 9 full turns to make 180 degrees, or 40 seconds. It is cheap 20-detent encoder

Here's how it looks like connected directly to the board as on the video. With acceleration it just feels weird.
- Make sure you have pressed "Save/Reconnect".
- You should see new file in the plugin folder, named as "devices.prf" that keeps all input devices preferences.

Here is the video with the same encoder:

You see  - in +++  I have one finger move for all 360 deg.


Did you get it working as it is described?
Where the problem was?

What you're describing is what I have experienced as well. Upon closer examination, the encoder is just skipping when turned quickly. If you move it really fast, it may not register any change in the sim at all. Using acceleration you only have to turn the knob a little faster, you don't have to rotate it really fast. It's likely not a software/algorithm issue, but I have not yet tested it just using the Arduino IDE. I've been trying to explain this here.

3 weeks ago by

OK, I will try to explain:

The "multiplier" code was considered and tested, and it was bad. It doesn't allow you to get good speed and having the precision one-step movement. The used code is developed (I wrote a tens of various algorithms for encoders since 2012, one was worked in ArdSimX pretty fine and  suits most needs for ArdSimX, but not SimVim), and this algorithm allows to have any speed and fine precision at the same time.

- Case 1:  The encoder state reading program  is used this simple "direct" way -" read the state -> send the state to the plugin".  NOTE: assume it is a stand-alone code, for reading encoder only (no other  hundreds of input, no outputs), etc.

In this case the firmware fix the next encoder state change and activates the "send to plugin" protocol.
The plugin can receive this one change in the same moment, but most likely with some delay defined by X-Plane FPS.

Why? Because the X-Plane (any plugin) can send or receive data only in the end (or start) of the X-Plane work cycle.
If the FPS = 40 for example, the plugin can receive next change only after 25 ms.

You cannot to exchange data between plugin and external controller faster than X-Plane frame rate,
That's mean that if you will rotate the encoder a bit faster the plugin will not receive every step.

- Case 2:  The firmware program reads and saves cumulative state changes in every X-Plane frame, then sent the data as number of increment steps for the plugin. This will work better, but  don't allow you to accelerate the movement. The problem is, to make it work in massive data exchange system, with various encoder types, system speed and synchronization.

 Case 3 (the SimVim protocol):

As you cannot to exchange data between plugin and external controller faster than X-Plane frame rate, the firmware program  monitors every encoder state change between frames (along with hundreds of other inputs), count them as in case2,  but with additional function to calculate speed, acceleration, depending on X-Plane frame rate and controller loop time.


I had inkling it was some software stack problem like that ;-)

Could precision could be maintained by coding "if encoder says one tick then degree then move 1 degree, otherwise apply multiplier"? It would be picewise-linear curve in the chart above approximating accelerating profile. Maybe try and post video (knob+dial; turn left and right; slow and fast) if it is pain to release all changes?

I wanted to test optical encoder I extracted from an old printer, or maybe even buy an optical encoder as below - would this work? Has anyone tried such thing? (I spent hour on ali looking for compact optical encoder in shape similar to "cheap shafted encoder" to no avail).  Given they use it to position printer heads they must be good, no?

Have a multi-turn pot been ever tried (second link below)? Based on my brief search they are cheap, have a shaft, are absolute, linear, easy to read at 1024 (arduino's) precision! Size for ex 3690 Burns is 22mm wide/18mm deep. Shaft is 6mm for a guitar style knob.,searchweb201602_,searchweb201603_,searchweb201602_,searchweb201603_

FYI my setup at the moment is cheapest 20 tick encoder, no breakout to Arduino on 12cm cable (have no equipment to check signal quality; that seems hard anyway). It's a draft project as I am beginner Arduino hacker...

An encoder is incremental input device, and it never used as absolute position control by its definition.

As for using analog input - no problem, we can add the analog input assignment for the trims, but either you have a simple pot or multi-turn pot you can't get the same precision as encoder allows (due the analog input noise, as I said before it give you no more than 1/100 or 1/200 of full scale if you will care about stable reference voltage, shielded short cables, etc.)\