I'm using an Mbed to drive a DC motor which will follow a trapezoidal trajectory. What is the most appropriate way to determine position from the quadrature encoder?

Should I use interrupts, or is there a risk of the trajectory routine (which calculates theoretical position) falling behind?

Alternatively, I could poll/sample the encoder in fixed time steps, but I'd imagine this would miss out many encoder counts.

How is this problem usually dealt with?


It's best if you have quadrature encoder hardware to handle the encoder pulses, unless the speed is very low. Many microcontrollers have at least one such peripheral on the chip.

  • \$\begingroup\$ Can you suggest an MCU that comes with a peripheral and how it would be used? \$\endgroup\$
    – M-R
    Jun 24 '15 at 22:38
  • \$\begingroup\$ Microchip dsPIC micros have QEI (Quadrature Encoder Interfaces), but I would not recommend them if you need more than 15 bit resolution unless they've cleaned up the errata. TI Tiva and Stellaris processors would likely be my choice in 2015 (ARM core) or NXP LPC, of which there are several with QEI. You should have dozens or maybe a couple hundred to choose from. You use it by connecting the QEI A/B inputs and index input (optionally) to the encoder, and the rest is firmware. \$\endgroup\$ Jun 24 '15 at 22:46
  • \$\begingroup\$ Alternatively, could one write their own firmware for an MCU which doesn't include a QEI? \$\endgroup\$
    – M-R
    Jun 25 '15 at 1:07
  • \$\begingroup\$ If the speed is very slow, otherwise (and better) an FPGA could be used. There are also some dedicated chips that won't lose counts. \$\endgroup\$ Jun 25 '15 at 1:20

You have to poll the state of the two Q input often enough not to miss a state transition. How quickly this is depends on how quickly the Q inputs can change, and only you can tell that. The correct way to do the counting is to use a 4-state FSM, which handles bounding and direction changes correctly.

How do you check often enough?

  • as Sphero stated, using Q-decoder hardware is a perfect way, and it will liklely be fast enough for any purpose.

  • you can use a timed or on-change interrupt to tickle your FSM. How fast you can do this depends on your system, and how much of its resources you want to spend on this task.

  • for in-frequently changing Q-inputs you could just poll the inputs.


A very great deal is going to depend on your motor/encoder setup, which you have not specified. Let's say (just as a starting point) the your motor shaft can run at a maximum of 600 rpm (10 rps) and your encoder produces 64 pulses per channel. That is, if you run the shaft at 10 rps, you get a 640 Hz square wave on each channel.

When using a quadrature encoder, you can derive 4 times as many position events, corresponding to both the rising and falling edges of the two channels, for a shaft resolution of 256 points per revolution, or 2560 points per second.

You have not provided a processor board specification, either, but let's say that it allows 4 channels of digital inputs. Then you can look at both your encoder channels, and also a pair of channels which have inverted versions of your encoder lines. Now you can write your software to generate an interrupt on each of the rising edges of the 4 inputs. At each interrupt you examine the two encoder lines and determine the local position. At the same time, you read your real-time clock to determine the time since the last encoder tick, and from that determine the shaft velocity. Can you do that in (let's say) 1/10 of the time between ticks? That's 40 usec. Also, you'll need to find some way to prevent any other interrupts from preempting your encoder routines for more than 400 usec. If you don't, you lose position information, and any process which prevents immediate time interval measurement will screw up your shaft rate calculation.

With only a small about of hardware (a couple of exclusive-OR gates and an RC delay) you can produce a single input which will generate interrupts for all four encoder transitions, so you could get away with 3 digital inputs.

If the transition frequency is low, as Wouter van Ooijen says, you can try simply polling the encoder outputs, but be aware that this will introduce uncertainties in your shaft velocity calculations, especially if your processor is doing anything else which may have higher priority, and any such uncertainty will degrade your ability to hold to a desired velocity profile, trapezoidal or otherwise.

Overall, I'd advise you listen to Spehro.

  • \$\begingroup\$ I have my doubts about that hardware interface for 3 pins when the decoder can bounce and turn backwards. \$\endgroup\$ Jun 24 '15 at 15:46
  • \$\begingroup\$ Mechanical quadrature encoders are very rare. Opticals are easy to condition, and show essentially no bounce, even at low rotation rates. \$\endgroup\$ Jun 24 '15 at 15:48
  • \$\begingroup\$ But even optical ones can stop at the boundary of a 'closure', and show essentially the same behaviour as bouncing. \$\endgroup\$ Jun 24 '15 at 15:51
  • \$\begingroup\$ What is "the boundary of a 'closure'"? I'm assuming a rotary shaft encoder, and those things just go around and around. \$\endgroup\$ Jun 24 '15 at 16:53
  • \$\begingroup\$ I'd assume that they can also be stationary? \$\endgroup\$ Jun 24 '15 at 16:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.