Encoder resolution on fast turning shafts

[Tom Line]

There was a very lengthy discussion about jitter, sampling, and RPM calculation in 2012. To make a long discussion short, if you are using the period function in LabVIEW, you may actually be better off with a 1 count per rotation encoder to maximize the period and make your RPM calculation more accurate. We used it very successfully in 2012, and 2013. This will also eliminate any worries you may have about loading the roborio.

This is somewhat counter-intuitive if you are thinking about calculating RPM using "number of ticks" divided by time.

[jhersh]

Originally Posted by Tom Line

There was a very lengthy discussion about jitter, sampling, and RPM calculation in 2012. To make a long discussion short, if you are using the period function in LabVIEW, you may actually be better off with a 1 count per rotation encoder to maximize the period and make your RPM calculation more accurate.

While much of that discussion still holds to some extent, much of it is not all that applicable given the roboRIO's vastly faster DIO, unless you have a blindingly fast encoder signal.

Originally Posted by Tom Line

We used it very successfully in 2012, and 2013. This will also eliminate any worries you may have about loading the roborio.

The roboRIO and the cRIO does / did all quadrature decoding in the FPGA. It incurs no more or less load on the system sitting unswitched vs. switching quickly.

[Thad House]

Originally Posted by jhersh

While much of that discussion still holds to some extent, much of it is not all that applicable given the roboRIO's vastly faster DIO, unless you have a blindingly fast encoder signal.



The roboRIO and the cRIO do / did all quadrature decoding in the FPGA. It incurs no more or less load on the system sitting unswitched vs. switching quickly.

Joe, do you know exactly what the pulses per second rating for encoders/counters in the FPGA is? I remember that the cRIO was right around 40,000, and I remember hearing that the RoboRIO was in the realm of 100,000, but I would like to know for sure. It would also be nice to have this documented somewhere if possible.

EDIT: Nevermind. I didn't see the 25ns number above. Does that mean that that the RoboRIO can take 40,000,000 edge to edge pulses per second, or am I screwing my math up somewhere. That number just seems incredibly high, but I could see it being that high.

[Ether]

Originally Posted by Thad House

EDIT: Nevermind. I didn't see the 25ns number above. Does that mean that that the RoboRIO can take 40,000,000 edge to edge pulses per second

It means the roboRIO samples the edges at 40MHz, and timestamps them with a 40MHz clock (25ns resolution) when detected.

So no, you wouldn't get a usable reading at 40M edges per second.

Note: back in 2012, the cRIO FPGA took samples at only 153KHz, and timestamped them with a 1MHz clock. That's why we had all the discussions back then.

[jhersh]

Originally Posted by Thad House

Joe, do you know exactly what the pulses per second rating for encoders/counters in the FPGA is? I remember that the cRIO was right around 40,000, and I remember hearing that the RoboRIO was in the realm of 100,000, but I would like to know for sure. It would also be nice to have this documented somewhere if possible.

EDIT: Nevermind. I didn't see the 25ns number above. Does that mean that that the RoboRIO can take 40,000,000 edge to edge pulses per second, or am I screwing my math up somewhere.

If you look at "roboRIO Specifications" linked from here, in the Digital I/O section on page 4, it references "minimum pulse width". That's the hardware limit. The FPGA implementation uses a 40 MHz clock as the timebase to run the decoder logic and the I/O logic. That means the FPGA is the limiting factor by a small margin. There are complications (discussed earlier) with respect to the sampling and ensuring no two edges are detected in the same sample period. To ensure that is avoided, divide the rate by 2. That means 20,000,000 edges per second should be guaranteed to decode. That edge rate would mean 5,000,000 rising edges on the A encoder output per second (assuming very small phase error in your encoder both A to B and rising to falling).

Originally Posted by Thad House

That number just seems incredibly high, but I could see it being that high.

Originally Posted by jhersh

...the roboRIO's vastly faster DIO...

It is incredibly high... by comparison to the previous system anyway.

[Qormix]

Hello My team is trying to use the VersaPlanetary Integrated Encoder to reach about 12000 rpm. The documentation on vex pro says 15000 rpm max but looking at the talon SRX software documentation says 10000 rpm max and we seem to be maxing out the rpm.

[ozrien]

Originally Posted by Qormix

Hello My team is trying to use the VersaPlanetary Integrated Encoder to reach about 12000 rpm. The documentation on vex pro says 15000 rpm max but looking at the talon SRX software documentation says 10000 rpm max and we seem to be maxing out the rpm.

The mag encoder spec says 15000rpm, not 10000rpm. Section 1.4 in Mag Encoder User's Guide.

The 10000RPM in section 7.5.4 in SRX Software Reference Manual is a typo. I'll fix it soon.

And also...
http://www.chiefdelphi.com/forums/sh...63&postcount=6

[Qormix]

Thanks, still can't seem to get it work are current using java and have set the feedback device to ctre mag relative and are unable to read an rpm above 5000 we are using java any suggestions

Edit.

We updated the firmware and it worked. *facepalm*