[Ether]

The FPGA has a 40 MHz clock.

The digital inputs are sampled every 261 cycles of the 40 MHz clock:

40MHz/261 = 153,256.705 samples per second per digital input.

If edge transitions (rising and falling) occur faster than this on any given input channel, the FPGA sampling will not be able to detect and count them properly.

Furthermore, for quadrature decoding, cross-channel edge transitions must be greater than 1/153,256.705 = 6.525 microseconds apart or the FPGA will not be able to determine which edge came first.


Example:

A US Digital 360 CPR E4P encoder outputs 2*360 = 720 total edges (360 rising + 360 falling) per rotation on each channel. So for each channel, an edge transition occurs every 1/720 of a rotation, if the symmetry is perfect (see attached excerpt from datasheet).

When using just a single channel of this encoder as a counter, and assuming perfect phase symmetry, speeds greater than (1/720)/(6.525e-6) = 212.9 rotations/sec = 12,771 RPM would cause a problem for the FPGA¹.

But the symmetry is not perfect. According to the datasheet, the symmetry across the range of recommended mounting tolerance can be off by as much as 75 electrical degrees. So instead of being (1/720) of a rotation apart, some of the edges in a channel could be as close as (1/720)*((180-75)/180) of a rotation apart. So speeds greater than (1/720)*((180-75)/180)/(6.525e-6) = 124.2 rotations/sec = 7,450 RPM would cause a problem for the FPGA.

Assuming perfect phase alignment between channels A and B, the cross-channel edges are (1/720)/2 of a rotation apart. So for quadrature decoding, speeds greater than ((1/720)/2)/(6.525e-6) = 106.4 rotations/sec = 6,386 RPM would cause a problem.

However, for this model encoder, the phase tolerance of the the 2 channels is rather sloppy. According to the datasheet, the quadrature delay across the range of recommended mounting tolerance can be off by as much as 60 electrical degrees. So instead of being (1/720)/2 of a rotation apart, some of the edges across 2 channels could be as close as ((1/720)/2)*((90-60)/90) of a rotation apart. So speeds greater than ((1/720)/2)*((90-60)/90)/(6.525e-6) = 35.48 rotations/sec = 2,129 RPM would cause a problem for the FPGA.

So as Mark and Joe mentioned in earlier posts, for measuring shooter wheel speed it may better to use just only one channel of the encoder (depending on the encoder and its tolerances).

To reduce the signal noise, you should also consider setting the FPGA sample averaging as discussed here.


¹the electronics in the 360 CPR E4P are limited to 10,000 RPM