# Choosing a position sensor (encoder) and obtaining velocity from it

How do I know how many counts per revolution I need for an encoder for my application?

I need to be able to accurately capture a 1000 Hz signal on an input side running from 1-133 rev/sec (60-8000 RPM) and a 1000 Hz signal on an output side with gear ratio 1:100, so speeds are .01-1.33 rev/sec (.6 - 80 RPM).

Here is the math I have but am not sure if it is correct:

For a 1000 Hz signal, it takes .001 sec for one period. But if I want to accurately capture this and accurately obtain velocity from this position data, I need 100 counts (is this a good assumption? what would be a better value?). Hence, I need 100/.001 = 100,000 cts/sec. Now, if I divide this by my rev/sec, I'll get cts/rev which is what encoders are rated at. Assuming input is running at 10 rev/sec, I need 100,000/10 = 10,000 cts/rev. Assuming output is running at .1 rev/sec, I need 1,000,000 cts/rev.

I strongly suspect my math is incorrect however because the best encoders that meet the speed requirement of my application are 1024 cts/rev for input and 72,000 cts/rev for output. Would these cts/rev actually be good enough for my application then?

For context, I need to obtain the Bode plot of a gear drive and hence plan to give sinusoidal inputs to my motor. I do not expect this the bandwidth of my gear drive to be more than 1000 Hz, but since I am not sure what it's exact number is, I would like my design to be capable of accurately measuring a 1000 Hz signal. This sinusoid will be in terms of velocity which is why I want to obtain velocity data. Also, I know it may seem odd that I am using position first and then getting velocity rather than getting velocity directly, but my client would like this system to be capable of positional control.

TLDR: How many position counts are needed to get an accurate velocity reading? How many position counts per revolution do you need to capture velocity changing at a frequency of 1000 Hz?

• Are you trying to monitor a gear drive that has a sinusoidally pulsing speed? I have found that the RPM measurements I get from using a small number of pulses are way off since little variations in the time between a single pulse get extrapolated across all the other encoder positions and I get wild RPM readings. It is not clear what you mean by a "1000Hz signal" and how it relates to the RPM being 1-133rev/sec. – DKNguyen Feb 19 '19 at 5:57
• There's a difference between an accurate velocity reading and an up-to-date velocity reading. I found that my most stable readings were when I just took one pulse per revolution, but then those readings only get updated once per revolution which can be a problem and I get increasingly wild RPM readings as I use fewer pulses. I suspect it's because small variations of the time of a single pulse get extrapolated as if the same thing was happening over every single count in the revolution. If you do plan to measure clk ticks between each encoder pulse, you need a fast clock or fewer pulses. – DKNguyen Feb 19 '19 at 6:00
• I guess you mean 1000 pulses per revolution, not 1000Hz. Because 1000Hz makes no sense unless you are referring to the maximum pulse frequency of the encoder, in which case the rest of your question makes no sense. – Edgar Brown Feb 19 '19 at 6:03
• @Toor: that is exactly what I want to do. Do you know how many pules you found to be "good enough"? The RPS (rev/s) range is the varying speeds I expect to input. Toor and Edgar Brown, I anticipate the output to vary rapidly (hence I assume 1000 Hz) and want to accurately model that. – Hasan A. Feb 20 '19 at 2:01
• You're saying you want to measure velocity with a bandwidth of 1000Hz? That seems real excessive since there is inertia that dampens things out. But if you want a BW of 1000Hz, you need at least 2000 samples/sec as per Nyquist. So you need enough counts to get that when turning at your minimum RPM. But to measure the time interval between counts at your fastest RPM, you will need a very fast clock. At the faster RPMs you might not be able to calculate the velocity everytime a count comes in so frequently in software. – DKNguyen Feb 20 '19 at 2:24