Encoder rate noise

[Joe Hershberger]

Originally Posted by Joe Ross

All that matters is the edge that it is looking for at 1x does not exceed the digital clock rate (It will count and handle direction correctly, but will have horrible rate noise). It doesn't matter if the other edges happen too fast, because it will latch the values on the digital clock.

This is not entirely true. The behavior of the quadrature decoder is not guaranteed if both signals change value on the same clock cycle. For the cRIO, that means if A and B channels both change within a single 6.525 us sampling period on the DIO module, that the count will fail. I don't recall what the FPGA does in this case. If it doesn't count at all, it means there is nothing to measure the time of. If you are seeing glitches where the rate is occasionally close to half of subsequent rate measurements (with averaging off of course) then you may identify this.

Fundamentally, the 1x vs 4x decoding only affects the amount of averaging you can do (by essentially being an average of 4 samples). It also affects how much position resolution you have if you care about that (but exposes you to mechanical inaccuracy as described above). Another difference is simply that there are 12 quadrature decoders in the FPGA... 8 counters (capable of 1x and 2x decoding) and 4 dedicated 4x quadrature decoding units. Bottom line, the FPGA still has to "see" all 4 edges in sequence no matter what the decoding scheme.

Of course if you are running anywhere near the digital I/O sampling rate, then the FPGA's built-in rate calculations are so noisy that they are practically useless. In this situation I recommend that you calculate the rate by reading the number of counts that changed in a fixed time period. This will be far more accurate at these high speeds. You can very accurately get the counts in a fixed time period by using the DMA feature of the FPGA to send the encoder count value at exact intervals measured by the FPGA.