pic: Encoder Graph

[vamfun]

Originally Posted by Joe Ross

That is my understanding, although I haven't seen it documented. If it's 4x, it divides by the the time for the next edge on the opposite input. In 1x, it divides by the time for the same edge on the same input.

When JoeHersh, I and others worked on fixing getRate problem last year, I thought we got some improvement in the noise with pulse averaging.

http://www.chiefdelphi.com/forums/sh...1&postcount=90

Maybe this is equivalent to what you are saying. I wonder if it really got into the WPILIB as indicated.

So... looks like we only have about 40,000 cnts/s to play with on the FPGA.
In my experience, when the pulse interval time gets toward the limit, the FPGA method of deriving rate gets less accurate since the clock edge errors enter into the picture. The getRate() comes into its own when the pulses are sparce since it avoids spikes in rate when a pulse comes in.

edit{
The FPGA limit allows the US digital encoders for a shooter since their 250 cnt/rev would limit the speed to 160 rev/s or 9600 rpm. The minimum encoder wheel cnts/rev for the E4 is 100 so this could be increased to 24000 rpm. This should handle anyones shooter requirements. }

So what is everyone using for a 5000 rpm wheel?

Thinking outloud, if the shooter bandwidth is .5 hz we want the sensor bandwidth to be at least 2.5 hz to keep phase errors negligible. A two color wheel and a light sensor at 5000 rpm gives 500 pulses per sec so we would need a 1000 hz sampling rate to capture this with software without interrupts. Perhaps an encoder is easier.