Consumer grade optical rotary encoder

[npelov]

Long time ago the PC mice were made with optical rotary encoders and they were cheap. Even the cheapest ones worked well (at least the rotary encoder part). Now everyone switched to mechanical rotary encoders. They are nasty to debounce - if you do it too much, you loose speed. If you don't - you loose/gain additional pulses. There are probably good onces which are expensive, but they'll still wear out and I heard of very expensive ones that failed.
I need a cheep rotary encoder like this one, but optical. Well it doesn't have to be $1-2. $5 is still a good price for optical one (that's the price of a cheap mouse). It doesn't have to be high precision like the ones used in industrial CNC machines. I need it for knob, not for location.

[Howardlong]

I looked into this about three or so years ago, and didn't have any luck, at least not for a volume product.

In the end, as well as trying some expensive (tens of dollars) units, I sourced some via aliexpress or similar for about $3 a pop. When they arrived they turned out to be ex-equipment: they worked, but were spec'd at 5v, that may not be a problem for you, but my device was battery powered and didn't have a 5v power domain, although they did work at 3.3v, just. They are also reasonably bulky.

I am fairly sure that almost all consumer grade rotary encoders use mechanical contacts.

One further thing I was looking for was heavy, reasonably large sized knobs that look like they're not form the 50s. Like cheap optical rotary encoders, nice looking large shiny knobs are hard to find (ooh er missus*).

* Widely used response to a double entendre in the UK.

[electr_peter]

I have just recently tested some cheap mechanical encoders and optical ones (CNC type with 100 steps). Short conclusion - just use anything optical if you can, cheap mechanical ones are horrible.

Mechanical encoders bounced like there is no tomorrow - whatever low pass filter (analog or digital) you implement, you are guaranteed to miss some pulses (especially at higher momentary turn speed). Turn knob faster and you don't even know whether waveforms could possibly come from an encoder. It is barely good enough for simple UI.
On the other hand, optical encoder provided very clean waveforms with no glitches and bounces - very easy to decode at any speed. I would strongly recommend using these if you fear about missing pulses or going in reverse direction (when knob is turned faster).

I used no name optical encoders (named "CNC 100 pulse encoder", ~50mm diameter), these go for $10-15 and use ~80mA at 5V DC. I can't suggest something cheaper and smaller, you have to look around. By the way, I can sell one these for lower price if you are interested in a knob only.

[ZeTeX]

http://www.ebay.com/itm/Rotary-Encoder-400P-R-6mm-Incremental-Optical-Shaft-Working-Measurement-5-24V-/171640123948?hash=item27f68c722c:g:90sAAOSwHmhV8Te8

[Howardlong]

http://www.ebay.com/itm/Rotary-Encoder-400P-R-6mm-Incremental-Optical-Shaft-Working-Measurement-5-24V-/171640123948?hash=item27f68c722c:g:90sAAOSwHmhV8Te8

That looks exactly like the ones I boughht a few years ago. The ones I had had varyng cable lengths, leading me to believe they are either ex-equipment or new old stock configured for a particular job.

[wraper]

Mechanical encoders bounced like there is no tomorrow - whatever low pass filter (analog or digital) you implement, you are guaranteed to miss some pulses (especially at higher momentary turn speed). Turn knob faster and you don't even know whether waveforms could possibly come from an encoder. It is barely good enough for simple UI.

Low pass filter is not very useful for this purpose. You used a wrong tool to solve the problem.

[electr_peter]

Low pass filter is not very useful for this purpose. You used a wrong tool to solve the problem.

Care to elaborate? I thought all improvements to mechanical encoder performance had came from low pass filter in analog or digital domain.

My problem with mechanical encoders that bounce is that they can skip pulses or go in reverse - and there is little you can do about it (at least without very high sample rate or specialised IC). This issue is especially anoying when quick turn (meaning that you do not take care to turn it slowly and consistently) of knob creates strange results in UI.

Optical encoders at least guarantee (up to a point, of course) that it will not skip pulses or go in reverse.

[tesla500]

Use a sin/cos hall sensor like MLX90316, and mount a magnet to the end of your knob shaft. You should be able to get resolution equivalent to a many hundred line encoder, and there are no contacts, rubbing parts, or optical paths to get blocked up with dirt.

[mark03]

Use a sin/cos hall sensor like MLX90316, and mount a magnet to the end of your knob shaft. You should be able to get resolution equivalent to a many hundred line encoder, and there are no contacts, rubbing parts, or optical paths to get blocked up with dirt.

A bit pricey, but at least there are some (from ams) that operate at a convenient voltage instead of 5V.  Power consumption is high while actually reading, but it looks like you can get < 100 uA for a reasonable cadence of ~ 10 Hz.  And you get absolute position for free.

Where do you find knob/shaft combos with bearings and a suitable "feel" to mount the magnet onto?

[wraper]

Low pass filter is not very useful for this purpose. You used a wrong tool to solve the problem.

Care to elaborate? I thought all improvements to mechanical encoder performance had came from low pass filter in analog or digital domain.

This debounce algoritm works great for any bouncing contacts http://auto.teipir.gr/sites/default/files/debounce_kuhn2005_1.pdf
But the most important for encoder, proper state machine which accepts only valid state changes should be used.
http://www.buxtronix.net/2011/10/rotary-encoders-done-properly.html

[linux-works]

https://www.amazon.com/gp/product/B00Y9KDDCY


a project I used that in (it works great):

[electr_peter]

Low pass filter is not very useful for this purpose. You used a wrong tool to solve the problem.

Care to elaborate? I thought all improvements to mechanical encoder performance had came from low pass filter in analog or digital domain.

This debounce algoritm works great for any bouncing contacts http://auto.teipir.gr/sites/default/files/debounce_kuhn2005_1.pdf
But the most important for encoder, proper state machine which accepts only valid state changes should be used.
http://www.buxtronix.net/2011/10/rotary-encoders-done-properly.html

Thanks, I will look into this a bit more more and compare with my current algorithm implementation.
Still, I do not expect to completely eliminate missed steps or wrong direction with mechanical encoder.

[darko31]

What's your price limit on a single encoder? There are bunch of cheap-ish chinese industrial encoders available for a reasonable price, as shown in previous posts, although nowhere near as cheap as mechanical, and they are rather bulky.

[npelov]

Well, I forgot to get back to this thread. I've read everything and I found out optical encoders for UI control are no longer a thing. Industrial incremental encoders have too much steps - like 400 per rotation. Also I don't know if they have well defined stops to avoid a stop between the steps (which can cause backward jumps). What I need is 24 step encoder.

The hall effect sensor seems like a nice idea to play with. There could be a problem if you need more than one knob close together. Also mounting can be a problem. the magnet has to be in the center of the axis for best results. An existing mechanical encoder can be used for the stops. May be if 2 magnets are mounted at 180 deg. from each other, one N facing down, one S facing down and the sensor is in the middle behind the mechanical encoder (maybe on the back of the PCB).
Here is a cheaper chip that could (probably) used for the same purpose:
http://www.digikey.com/product-detail/en/infineon-technologies/TLV493DA1B6HTSA2/TLV493DA1B6HTSA2TR-ND/5887140

[retrolefty]

Well, I forgot to get back to this thread. I've read everything and I found out optical encoders for UI control are no longer a thing. Industrial incremental encoders have too much steps - like 400 per rotation. Also I don't know if they have well defined stops to avoid a stop between the steps (which can cause backward jumps). What I need is 24 step encoder.

The hall effect sensor seems like a nice idea to play with. There could be a problem if you need more than one knob close together. Also mounting can be a problem. the magnet has to be in the center of the axis for best results. An existing mechanical encoder can be used for the stops. May be if 2 magnets are mounted at 180 deg. from each other, one N facing down, one S facing down and the sensor is in the middle behind the mechanical encoder (maybe on the back of the PCB).
Here is a cheaper chip that could (probably) used for the same purpose:
http://www.digikey.com/product-detail/en/infineon-technologies/TLV493DA1B6HTSA2/TLV493DA1B6HTSA2TR-ND/5887140

 One thing you might check into is using small (cheap) stepper motor as an magnetic encoder. It does require a little analog signal processing but has been done. Don't have a link handy but perhaps google can find something on this.

[Dave]

Thanks, I will look into this a bit more more and compare with my current algorithm implementation.
Still, I do not expect to completely eliminate missed steps or wrong direction with mechanical encoder.

I recently wrote a state machine for reading a mechanical encoder. I wrote it so that it only registers a valid step when the knob reaches the second detent. If any of the pin states is skipped during a cycle, the step is ignored and it waits for the knob to reach a detent before continuing. The polling of the pins is done at 1kHz, which seems to work very well.

It does occasionally skip steps if you flick the knob real quick, but it never registers steps in the wrong direction.

[Someone]

Well, I forgot to get back to this thread. I've read everything and I found out optical encoders for UI control are no longer a thing. Industrial incremental encoders have too much steps - like 400 per rotation. Also I don't know if they have well defined stops to avoid a stop between the steps (which can cause backward jumps). What I need is 24 step encoder.

The hall effect sensor seems like a nice idea to play with. There could be a problem if you need more than one knob close together. Also mounting can be a problem. the magnet has to be in the center of the axis for best results. An existing mechanical encoder can be used for the stops. May be if 2 magnets are mounted at 180 deg. from each other, one N facing down, one S facing down and the sensor is in the middle behind the mechanical encoder (maybe on the back of the PCB).
Here is a cheaper chip that could (probably) used for the same purpose:
http://www.digikey.com/product-detail/en/infineon-technologies/TLV493DA1B6HTSA2/TLV493DA1B6HTSA2TR-ND/5887140

Alps have their smaller/lower cost magnetic encoder EM11B16140A4, you should see reasonable pricing in volume when ordering directly.

[mubes]

Based on a brilliant little article from http://www.mkesc.co.uk/ise.pdf , call the _check function from a pin interrupt or on a regular basis;

Code: [Select]

const int32_t _moveTable[] = {0,-1,1,0,1,0,0,-1,-1,0,0,1,0,1,-1,0};

volatile struct
{
uint32_t ab;
int32_t psn;
} _p;


void _check(void)

{
    _p.ab = (_p.ab << 2)
         | (Chip_GPIO_GetPinState(LPC_GPIO_PORT, GETGPIOPORT(ROT_A), GETGPIOPIN(ROT_A)) << 1 )
         | (Chip_GPIO_GetPinState(LPC_GPIO_PORT, GETGPIOPORT(ROT_B), GETGPIOPIN(ROT_B)));

    _p.psn += _moveTable[(_p.ab & 0xf)];
}


[Fungus]

Based on a brilliant little article from http://www.mkesc.co.uk/ise.pdf , call the _check function from a pin interrupt or on a regular basis;

No, don't. Interrupts garantee that you'll pick up every last bit of switch noise and create lots of potential software bugs/race conditions.

or on a regular basis;

Much better idea. A 1ms polling function usually works perfectly.

[npelov]

Alps have their smaller/lower cost magnetic encoder EM11B16140A4, you should see reasonable pricing in volume when ordering directly.

16.60 EUR is a bit on the high side (farnell). Ordering directly from the manufacturer might save from the product price, but what about shipping? I buy from farnell using local distributor and I think they add 5% or 10%. If I want to buy 2 to 3 encoders it'll still be cheaper to order locally through farnell.

[npelov]

Guys, making a better filter (analog or digital) or any other approach of improving the readings of an mechanical encoder is a battle that you'll eventually loose. These things age and oxidise and do all kinds of horrible stuff. mechanical switches are not supposed to work at these frequencies. When I turn a pot I'm not careful how fast I turn it. A low pass filter won't hurt the performance of a pot noticeably. So I do use a pot when possible, but when you have too many values to change and too little space on the box you have no choice. So unless you use insanely expensive encoder with thick gold plating mechanical is not the way to go. They put more gold in a $5 multimeter range switch than in a $2 rotary encoder.
I remember beating the crap out of cheap old mouses and they still go. Sometimes the photodiodes get misaligned and I have to push them back in alignment. One would thing that technology will improve and they will make these encoders smaller - in form factor of today's mechanical encoders or maybe a bit bigger, but not.

Well I ordered a few sin-cos magnetic sensors and I'll see what I can achieve with them.

[LaserSteve]

If you need a lot of them, try US Digital, but again, you need to order many, many, many parts to get the price down.

http://www.usdigital.com/

Steve

[LaserSteve]

The low cost one:

http://www.usdigital.com/products/encoders/incremental/rotary/kit/E4T

Steve

[mubes]

No, don't. Interrupts garantee that you'll pick up every last bit of switch noise and create lots of potential software bugs/race conditions.

Much better idea. A 1ms polling function usually works perfectly.

Yup. As it happens I do use this function under interrupt but with an optical quad encoder and never have problems.  If you're intending using it with a mechanical encoder then deffo take precautions, although the state machine implied by the bitshift will protect you to a limited degree.

...not sure I agree about your bugs/races though, all depends how you use the output..the above is obviously very pared down, and polling is the devils spawn when you're trying to save power.

DAVE

[viperidae]

Why not use the encoder from a mouse, like you already said? The scroll wheel in a modern mouse is still an optical quadrature encoder.