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.

[Ether]

Originally Posted by vamfun

their 250 cnt/rev would limit the speed to 160 rpm.

160 rev/sec. = 9600rpm.

[Joe Ross]

Originally Posted by vamfun

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.

It looks like it's in c++ but not java. I don't have access to LabVIEW right now to check.

It does appear that an enterprising java user should be able to use the c++ patch as a guide to modifying the java library.

[vamfun]

Originally Posted by Ether

160 rev/sec. = 9600rpm.

@#$$&(*^dang! Good catch... I fixed the post. Looks like the 250cnt/rev USdigitals are still in the running. For sure you would run them x1.

I was about to go out and buy some magnetic encoders.

[Joe Ross]

Originally Posted by Joe Ross

It looks like it's in c++ but not java. I don't have access to LabVIEW right now to check.

To follow up, it looks like LabVIEW does not set the timer averaging either, so c++ is the only language the benefits at the moment (without modifying the library).

[vamfun]

Originally Posted by Joe Ross

To follow up, it looks like LabVIEW does not set the timer averaging either, so c++ is the only language the benefits at the moment (without modifying the library).

Thanks Joe,
It seems every year a few of us try to get this function functional and it never quite makes it for everyone.

This thread gives me deja vu with an older thread. I think the noise levels have improved for the x2 and x4 but have yet to see a good set of data.

I regret not having written a good encoder user manual last year when we disected the getRate() routine in this long thread where JoeHersh spilled the secrets of the internals of how this funcion is really coded. Anyway, the info is still there if you can get by a lot of my sidetracks. Unfortunately, I've forgotten half of stuff so I would have to wade through it again too....maybe someday.