I need to add encoders to the 4 motors attached to a "remote" PCB. The remote PCB in question does not have microcontroller on it, but rather is connected to the microcontroller PCB with an I2C connection (yes, using a differential I2C amplifier). Because of limitations in the cabling I only have the I2C connection between these PCBs.

So, I need to read 4x quadrature encoders over I2C. Some options and their associated issues:

  1. Read encoders with microcontroller using interrupts. This seems to be the most common method. However, I don't have a microcontroller on the remote PCB, so this doesn't work.
  2. Use a Quadrature decoder chip like the LS7266R1, LS7267 or other dedicated chip. However, these chips don't seem to be available on any vendor on Octopart, and they are expensive and they don't have an I2C interface.
  3. Build a quadrature decoder out of a D flip-flop and a counter and connect to an I2C IO expander: There seem to be a ton design issues with the build it myself approach: More flip-flops and NAND gates are needed to get full quadrature resolution and counter stability, counters on digikey only come in 4-bit and 8-bit versions (why are 8-bit counters rare and >$10 each?), ... all of this adds up to more cost and complexity than just adding a microcontroller.

Is adding a microcontroller to my remote PCB the best way? Why isn't there an easier way to do this? Given the number of digital encoders in the world, I'm surprised there isn't more available.

  • \$\begingroup\$ Can you define max frequency of output and preferred input method? \$\endgroup\$ – Tony Stewart Sunnyskyguy EE75 May 11 at 15:37
  • \$\begingroup\$ e.g. how critical is latency?, can you accept 4 bit counter states muxed from 4 motors? and how is it Reset? Index? \$\endgroup\$ – Tony Stewart Sunnyskyguy EE75 May 11 at 15:58
  • \$\begingroup\$ For this application there is no reset/ index pulse, the motors are under feedback and the only position that really matters is when the system has reached the setpoint. The max (no load) speed of the motors is 35,000 rpm with an 12 count per rev encoder, so max frequency is 420kHz, although the feedback system will very rarely go full speed. \$\endgroup\$ – Casey May 14 at 12:01
  • \$\begingroup\$ The encoder position is an input to the feedback loop, so latency is of some concern. However, I would think that even muxing several serial counters would be much faster than any of the physical dynamics/ feedback. I'm not sure what preferred input method means, can you clarify? The encoder PCB does the reading and supplies the dual quadrature outputs at 3.3V with 10kohm output impedance. \$\endgroup\$ – Casey May 14 at 12:06

However, I don't have a microcontroller on the remote PCB.

So put one there!
It is exactly for this type of application where tiny micro controllers are great. There are lots of 8 pin chips which are far, far cheaper then the $10 you mention. You can even implement 10, 12 or 16 bits if you want and have a choice of interfaces you can use to send data upstream.


The common mistake is to assume quadrature decoding needs some form of edge detection and counting the edges. It doesn't. You simply need to sample both states twice as often as an edge may occur.

→ Any I²C input chip will do, given the sample rate is high enough.

Do all the computation in your host CPU.

As some people need an example with reasonable numbers:

Let's assume you had four encoders, each one with one division per degree. All your axles rotate with up to 1000RPM. This is 16.67 rounds per second, which gives you 6,000 divisions per second. So you have to sample at 12,000 samples per second.

For example the MCP23008 I²C PIO chip has a continous polling mode which allows you to sample its 8 inputs in just 9 I²C clock cycles. So, to do one sample for four encoders, you need 9 clock cycles.

That means you need an I²C clock of just 108kHz to do that. Feasible? Yes. Uh, and the MCP23008 may be clocked up to 1.7MHz if you happen to need 1° accuracy at 15000RPM.

  • 1
    \$\begingroup\$ no edge detection needed: I fully agree. Use a state machine, that is the (only) reliable approach. But in this case the OP should make sure that he can achieve the reuqired sample rate over I2C. Otherwise a remote UC is the best option. \$\endgroup\$ – Wouter van Ooijen May 11 at 10:17
  • \$\begingroup\$ Stupid question: Use a latch; sample one channel (A) of the encoder on the edge of the other channel (B). Using a separate counter IC triggered on A OR B (diode logic), count the pulses. Bonus: use a counter IC with an input that toggles up- and downcounting; connect that to said flipflop. Use a cheap I²C IO extender IC to interrogate these ICs' states. Feasible? Sure, three chips, two diodes, possibly one pulldown, possibly analog debouncing and three decoupling capacitor sets, but no MCU was used in this case. \$\endgroup\$ – Marcus Müller May 11 at 11:35
  • 1
    \$\begingroup\$ The MCP23008 for example has a continous polling mode and you can sample the 4x2 inputs at 1/9 I²C clock frequency, which may be up to 1.7MHz with this chip. But assuming only a 100kHz clock (remote I²C), this means more than 10000 samples per second, on all four quadrature encoders synchronously. This should be more than enough for most mechanical applications (given you aren't into uranium enrichment). \$\endgroup\$ – Janka May 11 at 11:50
  • \$\begingroup\$ @Marcus Müller: These are all unneccessary complications. Mechanics is so slow the dumb sample method is the only reasonable choice. \$\endgroup\$ – Janka May 11 at 11:59
  • 1
    \$\begingroup\$ @Janka well, sampling I²C at > 5 kHz can get tiresome, and a a rotary encoder at 4div/rot and 1000 RPM will not be easy to do with that, so while, yes, if your number of transitions per second allow that, sample it, I don't see how that'll be applicable for anything fast. \$\endgroup\$ – Marcus Müller May 11 at 12:17

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.