I would love to see a hardware quadrature decoding breakout board; say 8 channels or something in that range. I do mean several channels because that is where the Arduino won’t be able to keep up gievn the latest articles relating to decoding quadratic sensors even with the new super simplified i/o read library.
It would be very nice to be able to read the channels that are hardware decoded independently by one of the specialized quadrature decoding ICs out there. And of course a OpAmp inputs so we can interface the breakout board straight to the optical sensor.
quadrature decoding is pretty easy. it takes very few instructions to determine direction and count clicks. I suspect the biggest problem is the arduino run time environment. If you use interrupts, you should be able to do a number of them. Maybe use a timer interrupt to sample the lines at a fairly high rate (>2X the max expected rate of qe output).
This could be done with a dedicated micro, you just need to have 2 I/O pins per encoder.
Philba:
quadrature decoding is pretty easy. it takes very few instructions to determine direction and count clicks. I suspect the biggest problem is the arduino run time environment. If you use interrupts, you should be able to do a number of them. Maybe use a timer interrupt to sample the lines at a fairly high rate (>2X the max expected rate of qe output).
This could be done with a dedicated micro, you just need to have 2 I/O pins per encoder.
I wonder how easy it is when trying to handle some odd situation. Let me explain. It’s simple to use one edge of one detector to clock in the other (direction) detector. Depending on the state of this detector you increment or decrement a counter. Voila, an integrating position/rotation/whatever system. But wait there’s more…
What happens if you use such a simple system when the position hunts around a clocking transition ? Well when going in one direction, as the position moves past the clocking point, it counts as it should. Then if the position moves back immediately, the system doesn’t count, up or down, as the clocking edge is the wrong sense. Then reverse direction, back to the original, and as the stripe/etc crosses the boundary the systems records yet another increment even though that’s not truly the case. You’ve gotten 2 “forward” increments counted when 1 only happened (in aggregate). Now have the system oscillate back and forth across a “clocking boundary”. You either need the noise/dither/limit cycle be > the resolution or ???
Seems to me you need a “smart” clocker that remembers the last direction that was clocked in and then detects any clocking edge and now uses that prior info to decrement/increment as needed (or not). Still not that hard to encode I think, but trickier than it might appear at 1’st thought.
Might be worth looking at the ARM CPUs, the LPC175x,6x,7x,8x all have QEI dedicated hardware. They do position sensing, velocity measures, and more while allowing the CPU to do other things.
I remember HP had a chip a while back that took care of the quadrature decoding for you. From what I remember there were 14 (yes fourteen) flip-flops that the signal went through to take care of any metastability issues. With todays faster logic I am sure you do not need as many flip-flops.
