Electrical Engineering Stack Exchange is a question and answer site for electronics and electrical engineering professionals, students, and enthusiasts. It only takes a minute to sign up.
Sign up to join this community
I am currently working on a MIDI based project and would like to use rotary encoders. However, due to the nature of my project I need to multiplex a total of 64 encoders with 8:1 multiplexers.
Is this possible or will an encoder just not work in this way due to pulses possibly being missed while the code is scanning elsewhere?
If you're trying to use 64 encoders as "frob knobs", the more typical way of doing this is to use each encoder for multiple purposes, and have some way of controlling which purpose the knob is serving at any given moment. Otherwise, I'd probably urge you to throw a microcontroller at each encoder, or at least have more than one microcontroller, each servicing as many individual encoders as it can without multiplexing -- you're already throwing more money at a problem than would typically be used, just keep going down the same path to make the device you want.
Alternatively, you might consider absolute encoders, so you don't need to worry about missed pulses.
That's the best I can offer without knowing more about what you're trying to accomplish (hence, "XY problem", as my comment says).
Yes, but...
Yes, they can, it is simply a question about the sample rate.
You have to perform some calculations. You have to determine the maximum speed for which you want your encoders to function. Then you have to figure out how fast the signals will change. This depends on the number of pulses per revolution that your encoder has.
You now need to scan all encoders fast enough not to miss a single of these state changes.
I suggest that you draw this out on a piece of paper to figure out if it makes sense for your particular choice of MCU.
...it is unlikely to be the best option
Today you can buy a microcontroller for the same price as a multiplexer (well, close enough). Just set a microcontroller for each group of 4 or 8 rotary encoders, and have the controllers report back over a shared I2C or SPI. They will offload your main MCU and present a nice absolute or relative integer.
It is a typical 'Nyquist' problem: As long as your sample frequency is twice the signal rate you are safe. So how fast can you rotate a knob and how fast can you scan them.
Beware that some encoders can have 'noise' during operation just like normal switches can 'bounce' and need de-bouncing.
I prefer shift registers to multiplexers, but would think it would be practical to feed 64 encoders into sixteen 8-bit shift register chips (e.g. 74HC597) and have a small ARM poll those and repeatedly output the resulting counts (perhaps via MIDI system-exclusive events or other means). If the shift rate is 2mbit/second, that would yield a polling cycle of about 15,000Hz which should be adequate. At a 16Mhz CPU clock rate, that would allow about 64 cycles per byte, which would keep the CPU quite busy but be should be workable with clever code.
A key trick to getting good performance would be to use "sideways computations". If variable A0 holds the first input from each of 32 encoders and B0 holds the second input from each encoder (in the same sequence), and one performs the computations:
delta = B0 xor A1 xor B1
A1 = A1 xor (delta and A0) // Same sampled value must be used here and below.
B1 = B1 xor (delta and not A0)
then B1:A1:A0 will hold 32 three-bit grayscale counts. If one then performs the computations:
delta = B1 xor A2 xor B2
A2 = A2 xor (delta and A1)
B2 = B2 xor (delta and not A1)
The approach may be extended to arbitrary depth, but a key observation is that one need not process later stages as often as the earlier ones. One could thus maintain arbitrarily long counters without having to increase the amount of computation work per scan cycle.
You can use this boards https://hackaday.io/project/27611-i2c-encoder
You can make a 4 chains of 16 encoders and use a I2C multiplexer for read all the encoders with only one I2C peripheral
It depends on how you plan on using the encoders.
If you need to keep track of the exact position of each encoder I would strongly advise against multiplexing them. Using small cheap dedicated micros for each would be a far better solution.
However, you should understand that keeping track of a quadrature encoder is not a trivial task even with a dedicated micro watching it full time. The tracking algorithm in fact needs to be quite complex. The issue being encoders have undefined states when the edge of the encoder disk is exactly over the sensor. This can and will result in a meta-stability condition with multiple edges being generated which need to be handled appropriately. Note this is should not be confused with bouncing. The signal edges you are receiving is telling you the encoder is hovering around the edge and is pertinent position information.
If however, these are simply soft volume controls with no absolute position dependency then there is another way to use them.
You can scan numerous encoders to read their "velocity" or "rate of change" rather than their absolute position. These velocity numbers can then be used to increment or decrement appropriate stored values which can be applied for whatever purpose they are intended. The scanning then looks for cycles in the encoder rather than edges.
The scan rate needs to be fast enough that the cycle time is significantly less than the maximum cycle speed of the encoder and produces as small a latency in the velocity measurement as possible. How many you can track at any given time is therefor limited.
I would personally recommend using a couple of small CPLDs or FPGAs to track all the encoder states directly, providing counts via I2C or SPI. This should be much more reliable than software based tracking over that many encoders.
In my case the issue is caused by the nature of the system which I cannot divulge unfortunately. (I had no other choice) It was found that multiplexing the encoders was nowhere near fast enough to pick up the transitions reliably, even on a simple test rig, before being integrated with the rest of the code.
AVOID DOING THIS IF YOU CAN!
