Quadrature Decoder - For Reference - Page 1
Forum section: electronics / general

author: ehughes
author_rank: Frequent Contributor
timestamp: February 08, 2017, 02:48:35 pm
content: 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.Enjoyhttp://www.mkesc.co.uk/ise.pdf

author: chris_leyson
author_rank: Super Contributor
timestamp: February 08, 2017, 04:17:48 pm
content: 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.

author: FrankBuss
author_rank: Unknown
timestamp: February 08, 2017, 04:31:59 pm
content: 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.

author: MarkF
author_rank: Super Contributor
timestamp: February 08, 2017, 06:10:03 pm
content: This pdf shows the technique I use. No lookup table required.

author: Benta
author_rank: Super Contributor
timestamp: February 08, 2017, 09:35:05 pm
content: 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.

author: hamster_nz
author_rank: Super Contributor
timestamp: February 09, 2017, 12:37:08 am
content: Quote from: Benta on February 08, 2017, 09:35:05 pmIn 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.

author: KE5FX
author_rank: Super Contributor
timestamp: February 09, 2017, 01:37:55 am
content: Pro tip: whichever technique you use, read twice and reject any direction pairs that disagree.

author: FrankBuss
author_rank: Unknown
timestamp: February 09, 2017, 03:11:21 am
content: Quote from: Benta on February 08, 2017, 09:35:05 pmThe table has the advantage to compensate imperfect encoders. E.g. in my example I didn't increment and decrement for each quadrature step, seethe 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.

author: jesuscf
author_rank: Frequent Contributor
timestamp: February 09, 2017, 06:42:01 am
content: Quote from: Benta on February 08, 2017, 09:35:05 pmI 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.

author: mikerj
author_rank: Super Contributor
timestamp: February 09, 2017, 09:48:18 am
content: Quote from: Benta on February 08, 2017, 09:35:05 pmThe 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.

author: ehughes
author_rank: Frequent Contributor
timestamp: February 09, 2017, 02:45:51 pm
content: 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.comWith the fully synchronous version:

author: Benta
author_rank: Super Contributor
timestamp: February 09, 2017, 05:17:24 pm
content: Quote from: hamster_nz on February 09, 2017, 12:37:08 amMy 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.