I have wired a 600 p/r incremental encoder to an Arduino Uno.

My question is this:

Given that the Arduino has a clock speed of 16Mhz and I really do not want to miss a single pulse I am creating a CMOS hard copy of the logic. I have:

Inc Encoder -> firing edge trigger (by propogation delay) through xor and nxor cmos (acting as clock) -> 16bit binary up/down counter -> d flop register

The inc encoder also has a logic block which denotes which direction it is turning (it sets the up/down pin of the binary counter.

My problem is this - how would you deal with the Arduino reading the current count. I do not like directly reading the counter as it can change during read i.e. if it is 9, the arduino reads LSB and during time taken to read next the counter increment to 10 then I could end up with a reading of 19. I thought about a buffer but if I use the edge trigger logic then it appears that by the time the counter has done its logic the flip flop register will have read the revious value.

I am looking at async Preset with data hold but this type of d-flop / other flip-flop are rare(ish)

Any other scheme I should think about?


This one is easy. Even if you don't want to throw a microcontroller at this, I would most definitely NOT reinvent the wheel by making a hardware quad encoder system, especially as if you're designing for the UNO, you're probably not talking about production.

Use a purpose-built IC, like the HCTL-2022. As you've realized, you've just hit a bugaboo having to do with how the output is latched for a read. Before you're done, you'll hit three or four more, maybe having to do with something like noisy transistions. These purpose-built ICs are pretty good. I've used them and recommend them.

| improve this answer | |
  • \$\begingroup\$ Thanks Scott. Excellent chip recommendation and will use (but I will also attempt wheel re-invention on the side as an excercise). I assume the noise issue I will hit can be taken care of with schmitt triggers - I'll have a play around and see what comes of it. Cheers for chip advice :) \$\endgroup\$ – Paul Sullivan Mar 11 '14 at 6:51

You shouldn't have a problem if you can sample at 16MHz. That translates to: 16Mpulses/s * 60s/1min * 1rev/600pulses = 1.6 Million RPM. Virtually anything mechanical will explode at that speed, and yet this is what your upper limit in measuring is at a 16 MHz sample rate. Even if you can't sample at the max clock frequency of 16MHz, a more moderate 10kRPM speed would need 100kHz sampling rate to be accurate.

To mitigate the encoding issue that you mention you should look into Gray encoding from the inc encoder. Alternately, if it uses binary encoding, perhaps it would be possible to read from MSB down to LSB to mitigate the encoding issue.


| improve this answer | |
  • \$\begingroup\$ Gray codes aren't used in incremental encoders, just absolute encoders. If you're talking about using the new circuit to generate a Gray, I'm not sure what that buys you. They're used to eliminate false transitions when two bits may change at nearly simultaneous times. \$\endgroup\$ – Scott Seidman Mar 10 '14 at 22:10
  • \$\begingroup\$ Also, I wouldn't be too sure about the numbers. 600 lines on an encoder wheel means 2400 transitions per motor revolution. A simple gear reducer can result in MANY transitions per rev. I've used small motors with 240:1 gear reducers. \$\endgroup\$ – Scott Seidman Mar 10 '14 at 22:17
  • 1
    \$\begingroup\$ Thanks Horta - bit of an issue though i.e. If I have a modest amount of code in the interrupt routine AND I have a lot of encoders then the 16MHz sample rate does not apply really. I also think you misundertood about the encoding - I have no problem reading the encoding of the wheel. Thanks though for effort. \$\endgroup\$ – Paul Sullivan Mar 11 '14 at 6:46

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.