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?

[Tom Line]

Ether - I'm not sure why you deleted your posts. The first one pointing to the paper helped me. Once upon a time when you first put that out I planned to throw it in excel and show my controls members how it worked. I did that last night, and with a couple tweaks found solutions that work with my 128 count encoder for both 3500 and 7500 with resolutions of +/- 2 and 4 rpm each at 10ms loop timing.

-Edit: Just saw your update that said there was a problem with your calculations. I look forward to the update so I can recheck my numbers.

[Ether]

Originally Posted by Tom Line

Ether - I'm not sure why you deleted your posts. The first one pointing to the paper helped me. Once upon a time when you first put that out I planned to throw it in excel and show my controls members how it worked. I did that last night, and with a couple tweaks found solutions that work with my 128 count encoder for both 3500 and 7500 with resolutions of +/- 2 and 4 rpm each at 10ms loop timing.

-Edit: Just saw your update that said there was a problem with your calculations. I look forward to the update so I can recheck my numbers.

Hi Tom,

I'm working on it. Short story: I believe the calculations as shown are correct for a given true rpm but: small variations of the true rpm around the given value can cause the jitter pattern to change and affect the jitter you would actually see in real life. I took the paper down because I did not explain this clearly and didn't want to mislead. I need to provide more graphs and explain them better.

[Tom Line]

Originally Posted by Ether

Hi Tom,

I'm working on it. Short story: I believe the calculations as shown are correct for a given true rpm but: small variations of the true rpm around the given value can cause the jitter pattern to change and affect the jitter you would actually see in real life. I took the paper down because I did not explain this clearly and didn't want to mislead. I need to provide more graphs and explain them better.

Ok. If it's only a question of small variations then I'm not terribly worried. When I compare our plan this year with the setup we used last year, there is an order of magnitude improvement in jitter.