Rotary encoder resolution for MIDI.

I've been thinking about making a MIDI controller, or at least experiment with it in small scale to see how feasible it is. So the idea is to use incremental rotary encoders with led indicators to give visual feed back on position. Now one issue is resolution, most affordable encoders I have seen has something like 36 steps per revolution, but a MIDI value is 7bits so I need at least 128 (preferably more to  get some error margin?).

I'm guessing that I'm missing something here, since you can get say a Behringer BCR2000 with 32 encoders for cheap. Are there any other way to do this, or what kind of encoder would I need to do this?

Fredrik said:

I've been thinking about making a MIDI controller, or at least experiment with it in small scale to see how feasible it is. So the idea is to use incremental rotary encoders with led indicators to give visual feed back on position. Now one issue is resolution, most affordable encoders I have seen has something like 36 steps per revolution, but a MIDI value is 7bits so I need at least 128 (preferably more to  get some error margin?).

I'm guessing that I'm missing something here, since you can get say a Behringer BCR2000 with 32 encoders for cheap. Are there any other way to do this, or what kind of encoder would I need to do this?

Click to expand...

One way to handle this is to measure the speed at which the encoder is turned. If the users turns the knob fast then the value increments (or decrements) by more than 1. In your processor you measure the time between encoder changes. It can be somewhat tricky, so you will have to play with it.

Andy Peters said:

One way to handle this is to measure the speed at which the encoder is turned. If the users turns the knob fast then the value increments (or decrements) by more than 1. In your processor you measure the time between encoder changes. It can be somewhat tricky, so you will have to play with it.

Click to expand...

Interesting, but how would that work with led indicators? Assuming the pot is turned slowly, it would then take 3.5 full revolutions to represent all values. It seems that the typical arrangement is to map the leds to a 270 degree arch to represent an analog pot.

Fredrik said:

Andy Peters said:

One way to handle this is to measure the speed at which the encoder is turned. If the users turns the knob fast then the value increments (or decrements) by more than 1. In your processor you measure the time between encoder changes. It can be somewhat tricky, so you will have to play with it.

Click to expand...

Interesting, but how would that work with led indicators? Assuming the pot is turned slowly, it would then take 3.5 full revolutions to represent all values. It seems that the typical arrangement is to map the leds to a 270 degree arch to represent an analog pot.

Click to expand...

The LED control and the encoder control are completely independent. Your micro detects the rate at which the encoder is turned, and it has to translate that into how many LEDs around the ring to light up or turn off.

I think you want the encoder's position to be like a pot's position. It can be, but it doesn't have to be.

-a

Andy Peters said:

The LED control and the encoder control are completely independent. Your micro detects the rate at which the encoder is turned, and it has to translate that into how many LEDs around the ring to light up or turn off.

I think you want the encoder's position to be like a pot's position. It can be, but it doesn't have to be.

-a

Click to expand...

Yes, but the point is that by using the rate I don't see how you would get a 1:1 mapping of motion to the leds. Looking into this a bit further it seems like encoders that can sense direction use something known as quadrature encoding which is two pulses 90 degrees out of phase, and it's possible to detect both the falling and rising edge of both signals, so in that case a 36 step encoder would give 144 positions?

So I guess a controller would then issue an interrupt on a pin change and either increment or decrement the value depending on direction. A led would be lit when a sufficient amount of steps have been counted using something like this: http://www.ti.com/lit/ds/symlink/tlc5925.pdf

Fredrik said:

Andy Peters said:

The LED control and the encoder control are completely independent. Your micro detects the rate at which the encoder is turned, and it has to translate that into how many LEDs around the ring to light up or turn off.

I think you want the encoder's position to be like a pot's position. It can be, but it doesn't have to be.

-a

Click to expand...

Yes, but the point is that by using the rate I don't see how you would get a 1:1 mapping of motion to the leds. Looking into this a bit further it seems like encoders that can sense direction use something known as quadrature encoding which is two pulses 90 degrees out of phase, and it's possible to detect both the falling and rising edge of both signals, so in that case a 36 step encoder would give 144 positions?

Click to expand...

Well, it depends on the encoder! (They're all quadrature, though.) Some have detents, and then you have to determine how many pulses per detent is has. And then the thing might not behave as you expect. For example, I picked this Bourns encoder, and I noticed that as you turned it through each detent, one phase would change and then the other would change almost (but not exactly) immediately.  So I couldn't count on using both inputs to determine that the encoder moved. You can only look at the leading edge (whichever changed first) and the state of the other signal to determine direction.

So I guess a controller would then issue an interrupt on a pin change and either increment or decrement the value depending on direction.

Click to expand...

Yes, that's the gist of it. Or if your processor doesn't have sufficient interrupt-on-pin-change capability, you could poll the two encoder pins in a timer tick ISR, perhaps at a 1 kHz rate, and determine direction from that.

In your case, you say you are not interested in velocity, so every click of the encoder should increment or decrement the value by 1. But you said you are trying to map a 7-bit MIDI value to the encoder turns, and so you should consider velocity, because your user will hate you for making you spin the damn knob to get it to go from 0 to 127 in a reasonable amount of time.

A led would be lit when a sufficient amount of steps have been counted using something like this: http://www.ti.com/lit/ds/symlink/tlc5925.pdf

Click to expand...

That TI guy is pretty neat. The serial port isn't exactly SPI, which means you'll need to think about how to drive it. If your processor's output pins have enough drive (sink capability) you can connect them directly to LEDs, or the the base of a discrete transistor or MOSFET. The external transistor lets you use a higher voltage for the LEDs.  Alternatively, if you're strapped for port pins you can use an I2C expander like the PCA9555. Lots of ways to do this.

-a

Andy Peters said:

Well, it depends on the encoder! (They're all quadrature, though.) Some have detents, and then you have to determine how many pulses per detent is has. And then the thing might not behave as you expect. For example, I picked this Bourns encoder, and I noticed that as you turned it through each detent, one phase would change and then the other would change almost (but not exactly) immediately.  So I couldn't count on using both inputs to determine that the encoder moved. You can only look at the leading edge (whichever changed first) and the state of the other signal to determine direction.

Click to expand...

I'd look for an encoder without indents I think.

In your case, you say you are not interested in velocity, so every click of the encoder should increment or decrement the value by 1. But you said you are trying to map a 7-bit MIDI value to the encoder turns, and so you should consider velocity, because your user will hate you for making you spin the damn knob to get it to go from 0 to 127 in a reasonable amount of time.

Click to expand...

Yes, but if I take a 36 step, non-indented encoder as an example and use both A and B outputs it should be possible to get 144 steps out of it, so in that case it would be possible to fit 128 values in less than 360 degrees, making it behave much like a analog pot throw by default. In the interrupt handler I would just check if the value is 0 or 127, and if the direction indicates that it's out of bounds, I just do nothing.

I found this: http://www.robotoid.com/appnotes/circuits-quad-encoding.html yesterday which goes into some details on quadrature encoding. One interesting bit is that the author mentions that you can get on-chip quadrature decoders (LS7184  in the example) that outputs the full 4x resolution. It has two outputs, one clock (where you count) and a direction pin that is either high or low to indicate direction. That may help if you want to keep the interrupt handler simple and fast, not sure if it's actually necessary in this case though. Since there are two channels it should be possible to detect direction on a falling edge as well, assuming you have some house keeping on the previous state on each channel.