Shooter Sampling Rate and Counter Averaging

[Tom Line]

I'd like confirmation that my understanding of how the different methods of getting rates from encoders work.

The 'getrate' command from the encoder VI only looks at period between the last two ticks. This results in a very noisy measurement if you are using a high-count encoder. Low count encoders that still count at least once per sampling period work best with this.

The 'counter' VI, using the # of samples to average mode outputs an average of all the samples. This should be better than a team calculating their own because this method shouldn't have jitter because it measures the periods from edge to edge. The drawback is that you'll have to make a comprise on how many samples you average. One choice of sample size won't be the absolute 'perfect' choice.

Calculating your own. This has the benefit of being more accurate as you get more samples, however you will have jitter because you may be part way between ticks when it executes and calculates. (counts from last cycle / time from last cycle).

So say I'm using a 3500 rpm shooter. That's 58.3 rps. Using a 128 count counter, that's 7466.7 counts per second, or 7.5 counts per millisecond. If I put it into a timed loop of 5 milliseconds, I will get around 35 counts per period. So if I were to use the counter VI and pick a samples-to-average of 25, I should have a pretty accurate rate calculation at 3500 RPM.

If I were to calculate my own using the microsecond RT timer, then my jitter would be around 1/35, or approximately 2.8% (worst case).

Am I thinking through this correctly?