Incremental Encoder and Arduino

Question

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?

Answer 1

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.

Answer 2

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.

http://en.wikipedia.org/wiki/Rotary_encoder