Encoder rate noise

[Ether]

Originally Posted by Bpk9p4

...getting very large noise on the encoder rate

How are you mounting and driving the encoder?

How are you decoding it?

And what speeds.

[Bpk9p4]

Originally Posted by Ether

How are you mounting and driving the encoder?

How are you decoding it?

And what speeds.

It is mounted to an idler sprocket to a gear box. So there should be no slip

I have the encoder running in a 100 ms period task. It is setup how it says in the example

I am getting around 9600 pips per second

[Al Skierkiewicz]

What kind of noise are you experiencing? How fast is it spinning?

[Bpk9p4]

I am seeing about a 33% noise. I attached a picture of my code bellow. The encoder is running at about 1500 rpm

http://www.chiefdelphi.com/media/photos/40706?
http://www.chiefdelphi.com/media/photos/40707?

[Al Skierkiewicz]

Originally Posted by Bpk9p4

I am seeing about a 33% noise.

???

Are you using the S4 ball bearing version? The sleeve bearing lists 100 RPM as max shaft speed. Are you seeing noise on an oscilloscope?

[Aren Siekmeier]

Some of the wires in your VIs are overlapping or hidden, so it's difficult to be sure where they are connected...

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.

Do you know the CPR (counts per revolution) of your S4 encoders? I believe the standard options are 100 and 360.

Can you post a plot of your encoder rate over time? Also make sure there is no load on the gearbox so it can spin freely to ensure a constant speed.

Edit: Thanks for the note, Joe, good to know. Note Joe's later post for more about 1x vs. 4x.

[Aren Siekmeier]

Also, I forgot to mention. There should be a VI in the Encoder palette to set the sample interval. You can call this in Begin.vi on your encoder reference to change the duration of the rolling interval the FPGA calculates the rate over.

[notmattlythgoe]

Originally Posted by compwiztobe

Also, I forgot to mention. There should be a VI in the Encoder palette to set the sample interval. You can call this in Begin.vi on your encoder reference to change the duration of the rolling interval the FPGA calculates the rate over.

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.

[Aren Siekmeier]

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.

edu.wpi.first.wpilibj.Encoder.setSamplesToAverage?

[notmattlythgoe]

Originally Posted by compwiztobe

edu.wpi.first.wpilibj.Encoder.setSamplesToAverage?

Doh >.<

[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

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

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

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

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