Why not always use an X4 decoder?

[senmurv76]

Hello All -- When using a quadrature encoder when is is benefitial to use a X2 decoder rather than X4 even though an X4 decoder offers double the angual resolution? Is the existance of X1, X2, and X4 decoders becuase of the limitation of some DAQs which are not compatible with say X4 decoding and therefore the use has no choice but to use X2 decoding? Thanks!

[KathrynTheGreat]

Hi Senmurv76,

Off the top of my head, I could think of a situation where using X2 encoding might be useful- what if you had a system that needed to trigger only off of rising and falling edges of channel A inside of the encoder, instead of both A and B? If you used X4 encoding, you’d have to add extra logic to get the system to ignore every other pulse, where with X2, the only pulses the system would receive would be the ones that you care about.

For X1, what if you wanted to count up one tick for each click of the encoder? With X4, each click would increment your counter 4 times, instead of 1, which would require you to divide the overall answer by 4. Although this isn't difficult, it's an extra step that could be avoided by using X1 encoding in this application.

[Kevin_Price · Accepted solution]

An answer from the wayback machine:

One of my early ventures in learning data acq with LabVIEW was to take encoder measurements to characterize motion.  The state of the art NI boards at the time were E-series that did not accept quadrature encoders natively.  We needed an external quadrature decoder circuit that would put out a pulse and direction pair that the E-series could handle.

The decoder had a DIP switch to select between X1 and X4 decoding.  It turned out that the motion quality measurements showed better signal-to-noise in X1 mode than in X4 mode.  Further investigation revealed some significant non-uniformity in the AB channels.  The phase angle between A & B signals was not terribly close to 90 degrees and their duty cycles weren't terribly close to 50%. 

X4 decoding produced 4 pulses per cycle, but they weren't uniformly spaced.  This manifested as a very high frequency apparent velocity fluctuation that added to the noise floor of the region we cared about.  For position measurements, we still used the X4 mode b/c despite the systematic phase and duty cycle errors, it still gave us *some* more info than X1 mode.

I don't believe I've ever chosen to use X2 mode, but I could see its usefulness where an encoder's duty cycle error is low but phase error is high.

-Kevin P

[senmurv76]

Thanks Kathryn and Kevin! 

[Kevin_Price]

Just a brief followup for clarity.

Note that my little story is not usually applicable to newer NI data acq boards that incorporate quadrature decoding internally.  I was measuring time intervals between quadrature states and was fairly directly impacted by the physical manufacturing tolerances that caused phase and duty cycle errors.

When measuring encoder position with newer boards that support quadrature, I routinely use X4 decoding.  I'm having a hard time thinking of a reason I'd choose otherwise.  The time interval thing would never come into play.  

The only thing I can come up with is that X1 decoding would allow four times as much continuous rotation before the internal count register rolled over.  Honestly, I'm not even sure it would matter because I don't know how rollover is handled with "normal" DAQmx programming.  The way I habitually program for encoders is decidely not normal.  In the early days of M-series I tried using the built-in position scaling features but kept bumping into various quirks, ambiguities, and (I believe) bugs.   Ever since then I've just stuck with my old habit of always reading the count register as an unsigned integer, and dealing with rollover, sign changes, and scaling manually.

-Kevin P

old-schooler, getting his curmudge on