Quadrature Decoder - For Reference

[ehughes]

Hello:

I found this .pdf and posting it here for future archival and reference.    The approach is quite simple and easily implement in an MCU or FPGA with just a few lines of code.   I have tested it personally (using a simple shift register and LUTs) and it is quite robust.   I also have tested with a high speed optical encoder.

All credit goes to the author.

Enjoy

http://www.mkesc.co.uk/ise.pdf

[chris_leyson]

Found the same method used here: https://www.circuitsathome.com/mcu/reading-rotary-encoder-on-arduino/. I used a PIC and interrupt on change and found the method to be very robust.

[FrankBuss]

I didn't know the paper, but the concept is obvious, I implemented it some years ago exactly like described, with 4 bits and a table:

http://www.instructables.com/id/Using-a-Quadrature-Encoder-with-an-ATtiny-2313-and/

See step 3 for details of the microcontroller program.

[MarkF]

This pdf shows the technique I use. No lookup table required.

[Benta]

In my opinion, overengineered.

Using one of the quadrature input signals as interrupt/clock, simply sampling the other input at this point will give you direction information.
The first input will give you relative position and speed.

[hamster_nz]

In my opinion, overengineered.

Using one of the quadrature input signals as interrupt/clock, simply sampling the other input at this point will give you direction information.
The first input will give you relative position and speed.

In an ideal world, where switches never go noisy, and contacts never bounce there are lots of easy answers.

I still like the "sample on a timer" method. It might waste CPU time, but that is very deterministic. A spew of interrupts from a noisy switch sounds like a recipe for strange intermittent behavior in the field. I would far rather that the dodgy encoder doesn't respond to a turn properly (e.g. skips backwards once in a while) than it crashes the H/W.

[KE5FX]

Pro tip: whichever technique you use, read twice and reject any direction pairs that disagree.

[FrankBuss]

In my opinion, overengineered.

Using one of the quadrature input signals as interrupt/clock, simply sampling the other input at this point will give you direction information.
The first input will give you relative position and speed.

The table has the advantage to compensate imperfect encoders. E.g. in my example I didn't increment and decrement for each quadrature step, see the source code (sorry, German comments), which was perfect for the ALPS EC11 und EC12 encoders. And of course, not a good idea to use an interrupt for a probably noisy input signal.

[jesuscf]

In my opinion, overengineered.

Using one of the quadrature input signals as interrupt/clock, simply sampling the other input at this point will give you direction information.
The first input will give you relative position and speed.

I disagree.  Many years ago I tried using one of the input signals as interrupt and the results were poor at best.  The literature on the subject agrees.  This paragraph is from "Linear Position Sensors: Theory and Application", by David S. Nyce ISBN 0-471-23326-9, John Wiley & Sons, Inc. Section 10.7: Quadrature, Page 157:

"Modern circuits that read the A quad B signals from a position transducer do not actually wait for a transition to occur and then count that transition.  Instead, its more common to monitor the states of A and B continuously at a higher sampling rate than the transitions are expected to occur.  With this (state, rather than transition) information and, usually, a microcontroller, smoother operation can be obtained with less likelihood of error."

The problem can be then easily visualized and solved with a finite state machine diagram as shown in the attached pictured and coded using your favorite programming language.

[mikerj]

In my opinion, overengineered.

Using one of the quadrature input signals as interrupt/clock, simply sampling the other input at this point will give you direction information.
The first input will give you relative position and speed.

The timer method is far better IMO.  Using an external interrupt is very prone to failures in the real world e.g. from noisy encoder signals.  This also gives unknown CPU overhead that increases with the speed of the encoder, and especially with noisy encoder signals. 

[ehughes]

Check out this logic.    I have not run a k-map but I *THINK* this is the "table" in a minimal form.

I have not simulated or tested this approach but it looks correct on 1st inspection.




*From fpgas4fun.com

With the fully synchronous version:

[Benta]

In my opinion, overengineered.

Using one of the quadrature input signals as interrupt/clock, simply sampling the other input at this point will give you direction information.
The first input will give you relative position and speed.

In an ideal world, where switches never go noisy, and contacts never bounce there are lots of easy answers.

My apologies for a too brief answer. I imagined it would be obvious to other engineers that only properly debounced signals can be used with this method.

Concerning the "interrupt", I would of course not bang the signal directly into the IRQ pin! But most MCUs have edge triggered I/O ports, which in turn request interrupt service.