Encoder rate noise

[Ether]

Look at the datasheet for the tolerance specs on symmetry and quadrature delay for this encoder. These also affect the max speed the FPGA can handle.

Using 4X decoding with no sampling is likely to be very noisy, given the above-mentioned tolerances on symmetry and quadrature.

Free play between the encoder shaft and whatever it engages can exacerbate the noise, especially if using 4X decoding with no sampling.

[Joe Ross]

Originally Posted by compwiztobe

What happens if you switch 4x decoding to 1x? You lose direction sensitivity, but it only counts one edge of one channel, instead of both, so it may be able to keep up better.

Switching to 1x decoding does not lose direction sensitivity. It still uses the B channel for direction, but only 1 transition of the A channel.

1x decoding helps reduce noise beyond just reducing counts to within the limit of the FPGA. It also allows additional digital samples between each count, effectively acting like averaging 4 samples at 4x. It also ignores manufacturing tolerances between the different signals, like Ether mentioned. For the S4 encoder, B lags A by 90 degress +/- 60 degrees (max).

[Joe Ross]

Originally Posted by notmattlythgoe

I really hope they make this available in C++ and Java without having to modify the source in this next year's version of the API.

Like Aren pointed out, this was added prior to the 2014 season. http://wpilib.screenstepslive.com/s/...d-known-issues

[Aren Siekmeier]

Originally Posted by Joe Ross

Switching to 1x decoding does not lose direction sensitivity. It still uses the B channel for direction, but only 1 transition of the A channel.

1x decoding helps reduce noise beyond just reducing counts to within the limit of the FPGA. It also allows additional digital samples between each count, effectively acting like averaging 4 samples at 4x. It also ignores manufacturing tolerances between the different signals, like Ether mentioned. For the S4 encoder, B lags A by 90 degress +/- 60 degrees (max).

Ah, thanks for that, good to know. I'm guessing 2x behaves similarly, skipping the falling edge of each channel and using it as a second sample to smooth things out relative to 4x.

[Aren Siekmeier]

Originally Posted by Bpk9p4

Thanks for all of the great replies. It is amazing the support you can get on this website.

I am using the sleeve bearing (not sure on part number) so you could be correct and i am exceeding the max speed. however i still get a lot of noise at low speed

I will add the config timer tonight when i get home and try reducing it to x1 to see if that helps. I am currently running it with no load already. i will also post a plot of the encoder values and noise and more information about which encoder i have


edit:
Gear box: VexPro 3 cim ball shifter with 2.16 ratio and we are mounting the encoder to the gear box with an idler sprocket
encoder: us digital s4 with 256 cpr

Are you driving the encoder using the press on plastic gears on the backside of the gearbox (near the shifting cylinder)? The larger of these gears is known to sometimes have a sloppy press fit, you could superglue it in place if this is the case to ensure no slip between the ball shifter output shaft and this gear that drives the encoder gear.

[Aren Siekmeier]

Originally Posted by Joe Ross

1x decoding helps reduce noise beyond just reducing counts to within the limit of the FPGA. It also allows additional digital samples between each count, effectively acting like averaging 4 samples at 4x. It also ignores manufacturing tolerances between the different signals, like Ether mentioned. For the S4 encoder, B lags A by 90 degress +/- 60 degrees (max).

What if the FPGA cannot keep up with all of the counts it would be averaging at 1x? Does it still properly count every 4th tick, even though the 3 in between go by too quickly? And then adds in the extra samples (and direction sensing) provided 3 intermediate ticks, provided they are slow enough to capture? Sort of nitpicking...

[Joe Ross]

Originally Posted by compwiztobe

Ah, thanks for that, good to know. I'm guessing 2x behaves similarly, skipping the falling edge of each channel and using it as a second sample to smooth things out relative to 4x.

2x uses the rising and falling pulse of channel A (since those are 180 degrees apart).

[Joe Ross]

Originally Posted by compwiztobe

What if the FPGA cannot keep up with all of the counts it would be averaging at 1x? Does it still properly count every 4th tick, even though the 3 in between go by too quickly? And then adds in the extra samples (and direction sensing) provided 3 intermediate ticks, provided they are slow enough to capture? Sort of nitpicking...

All that matters is the edge that it is looking for at 1x does not exceed the digital clock rate (It will count and handle direction correctly, but will have horrible rate noise). It doesn't matter if the other edges happen too fast, because it will latch the values on the digital clock.

[Bpk9p4]

thanks you very much for all of your suggestions. I put the config timer in the begin file and it cleaned up a lot of the noise. what number of samples do you normal avareage

[Al Skierkiewicz]

I would still like to know what you refer to as "noise".

[Iaquinto.Joe]

We used a Low Pass filter of 20% to reduce the noise of our drive encoder rates. I've linked to the code below. Key note: The Low Pass filter code I linked needs to be executed as a preallocated clone reentrant because data is stored for more than 1 iteration. Go to vi properties>execution for this setting. You can tune LPFilt to whatever works best.

Context:
http://puu.sh/9ADYL/292687bb80.png
LPFilt.vi:
http://puu.sh/9ADVq/5b0cc41731.png

[Joe Hershberger]

Originally Posted by Joe Ross

All that matters is the edge that it is looking for at 1x does not exceed the digital clock rate (It will count and handle direction correctly, but will have horrible rate noise). It doesn't matter if the other edges happen too fast, because it will latch the values on the digital clock.

This is not entirely true. The behavior of the quadrature decoder is not guaranteed if both signals change value on the same clock cycle. For the cRIO, that means if A and B channels both change within a single 6.525 us sampling period on the DIO module, that the count will fail. I don't recall what the FPGA does in this case. If it doesn't count at all, it means there is nothing to measure the time of. If you are seeing glitches where the rate is occasionally close to half of subsequent rate measurements (with averaging off of course) then you may identify this.

Fundamentally, the 1x vs 4x decoding only affects the amount of averaging you can do (by essentially being an average of 4 samples). It also affects how much position resolution you have if you care about that (but exposes you to mechanical inaccuracy as described above). Another difference is simply that there are 12 quadrature decoders in the FPGA... 8 counters (capable of 1x and 2x decoding) and 4 dedicated 4x quadrature decoding units. Bottom line, the FPGA still has to "see" all 4 edges in sequence no matter what the decoding scheme.

Of course if you are running anywhere near the digital I/O sampling rate, then the FPGA's built-in rate calculations are so noisy that they are practically useless. In this situation I recommend that you calculate the rate by reading the number of counts that changed in a fixed time period. This will be far more accurate at these high speeds. You can very accurately get the counts in a fixed time period by using the DMA feature of the FPGA to send the encoder count value at exact intervals measured by the FPGA.

[Ether]

Originally Posted by Joe Hershberger

For the cRIO, that means if A and B channels both change within a single 6.525 us sampling period on the DIO module, that the count will fail.

...because you can't tell which edge came first, so you don't know the direction.

Of course if you are running anywhere near the digital I/O sampling rate, then the FPGA's built-in rate calculations are so noisy that they are practically useless.

Unless you setup the FPGA to do averaging over a large enough sample size?

You can very accurately get the counts in a fixed time period by using the DMA feature of the FPGA to send the encoder count value at exact intervals measured by the FPGA.

Are there code examples how to do this in all 3 supported languages?

[Joe Hershberger]

Originally Posted by Ether

...because you can't tell which edge came first, so you don't know the direction.

Correct. Also for noise rejection. If you get a bounce or even a little electrical noise around a transition, you may count that edge more than once (you could use digital filtering, but that drops the max rate even further).

Originally Posted by Ether

I suppose it could just assume the direction hasn't changed, and go ahead and use the data. But I can imagine scenarios where that might be fraught with peril.

That would break noise rejection and could also be an invalid assumption. The point is the decoder simply doesn't know.

Originally Posted by Ether

Unless you setup the FPGA to do averaging over a large enough sample size?

Perhaps, depending on your requirements. Generally it is the wrong approach for very fast encoder signals.

Originally Posted by Ether

Are there code examples how to do this in all 3 supported languages?

Not that I'm aware of. I don't even know that DMA was implemented at the API level in WPILib for C++ and Java.

[Ether]

Originally Posted by Ether

...because you can't tell which edge came first, so you don't know the direction.

I did a little math about this about 10 months ago:

http://www.chiefdelphi.com/forums/sh...34&postcount=7

Originally Posted by Joe Hershberger

Not that I'm aware of. I don't even know that DMA was implemented at the API level in WPILib for C++ and Java.

If there's anyone reading this thread whose team has successfully implemented Joe's DMA recommendation, would you please share your code.