Re: Encoder rate noise
 

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.

Re: Encoder rate noise
 

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).

Re: Encoder rate noise
 

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

Re: Encoder rate noise
 

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.

Re: Encoder rate noise
 

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.

Re: Encoder rate noise
 

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...

Re: Encoder rate noise
 

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

Re: Encoder rate noise
 

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.

Re: Encoder rate noise
 

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

Re: Encoder rate noise
 

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

Re: Encoder rate noise
 

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

Re: Encoder rate noise
 

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.

Re: Encoder rate noise
 

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

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

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

Re: Encoder rate noise
 

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).

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

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

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.

Re: Encoder rate noise
 

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

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


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