Missing counts in the encoder

[altenbach]

---

@Abbishek94 wrote:

Can you elaborate on the pulse rate of the encoder? If I am not misunderstanding, the resolution of the encoder is 5000 pulses per revolution.

---

So what is the typical RPM range? How quickly can the RPM change? The setup needed can vary significantly depending on hardware and requirements. For example the turbine of a hydroelectric plant typically changes speed slowly and angular position is unimportant, but for a weather vane we really only care about the current angle while rotation speed is unimportant.

All electronic has limits! You will not be able to measure gazillions of pulses per second using typical hardware.

Also, remember that pulses alone cannot determine direction of rotation. Do you measure the pulses in quadrature using two channels or are there guarantees that it can only rotate in one direction? (If you are using just a single encoder, some stray vibrations could register as a fake high speed.)

There is also an uncertainty principle. You can get instantaneous angular position (within ~1/5000 of a full rotation) accurately by just counting pulses from a known starting angle and rotation direction. OTOH, to calculate rotation speed, you need at least two pulses, but if you want accuracy, averaging over many pulses is needed.

Do you have a list of requirements?

[Abbishek94]

Hi Kevin,

Sorry for the late response. Previously I was configuring a separate sample clock to sample the encoder signals. The problem with that is if there is a sample taken in between the edges of the TTL pulse, the same rotation angle as the previous pulse is recorded. Calculating the rpm based on that gives a zero rpm if the angle is not changing. How do we avoid this issue by using a sampling rate?

Thanks

Abbishek

[Kevin_Price]

I'm beginning to suspect you're hung up on some conceptual problems regarding encoders, counters, and sampling.  It's not uncommon.

I've been in many threads where the core issue was that the OP was assuming that they needed to consider the Nyquist criterion for their counter measurement task.  So if they had an incoming pulse train at 20 kHz, they were assuming they needed a sample rate >= 40 kHz.

This is not only untrue, it's often a very bad idea.  You're kinda running into that with your question about sampling between encoder edges and getting the same count value back twice in a row.  With counter tasks, *quantization error* is often the driving consideration for sample rate and it pushes in the *opposite* direction as Nyquist.

Instead of using Nyquist to plan a sample rate >= 2x the pulse rate, one should instead think like this: "If I want <= 1% quantization error, I need a sample rate <= 1/100 of the pulse rate."

If I recall from other threads, you're syncing your encoder measurement with analog acquisition and camera via a shared clock, right?  So you might not be free to lower it to <= 1/100 of the pulse rate.  In that case, you can smooth out your point-by-point finite-difference-based RPM measurement by feeding it through the a moving average function (such as the point-by-point Mean).  That'll end up having the same kind of effect.  The average RPM from 10 finite differences will be the same as you'd have gotten with a single finite difference at 1/10 the sample rate, but a little more precise because the average gives you fractional resolution where raw counts must be integers.

-Kevin P

[Abbishek94]

Kevin,

I understand your point that while doing counter tasks, the sampling rate is not exactly the same as that of the analog acquisition. And yes, I need the encoder acquisition to be synchronized with analog and camera with a shared clock. My question is that if we pass the encoder signals having those zero rpm cases, how effective will a moving average filter be? The reason I am asking this is that this filter will reduce the fluctuations or noise. However, the zero rpm case because of getting the same angles again and again, which I think is not the noise but the actual data itself. So, how will the moving average filter help with that? Also, if we use the moving average filter, it will be used while post processing the data or while acquiring the data itself?

Thanks

Abbishek

[Abbishek94]

Kevin, 

I would be grateful if you can elaborate on the queries I asked on Saturday with respect to the moving average filter and encoder acquistion.

Thank you

Abbishek

[Kevin_Price]

I'm trying to figure out what you do and don't understand about encoders, counters, sampling, quantization, etc.  I think it'll be most helpful if I can talk through a specific scenario based on a sample rate and encoder pulse rate that represent reality in your app.

What kind of sample rate do you intend for the shared clock that drives sampling for your analog signals, your camera frame grabs, and your encoder position?   What are the typical encoder pulse rates you can expect?

And then further: what's the specific usefulness of both angular position data and also RPM data?  Do you need to know either in near-real-time in order to have the program react?  Or is it ok to calculate things after the fact in post-processing?

As to the moving average itself, here's a specific example:

Let's suppose you capture the following 21 encoder counts at 10 kHz:

0,0,1,1,1,  2,2,3,3,4,  4,4,5,5,6,  6,7,7,7,8,  8.   

Now let's turn those into 20 forward finite difference delta counts:

0,1,0,0,1,  0,1,0,1,0,  0,1,0,1,0,  1,0,0,1,0

That looks like it's about to turn into your feared 0 RPM situation.  But let's look at what happens when we do a moving sum across sets of 10 delta counts, starting at the 10th:

                             4,  4,4,4,5,4,  5,4,4,4,4

That's much smoother, and that's the kind of thing you'll get by sending your finite-difference-based RPM calculation through a moving average.

-Kevin P

[Abbishek94]

Hi Kevin,

Let me answer some of the questions you asked for better clarification:

1. For the analog signals, the sampling rate that is intended will be of the around 5000 - 10000 Hz. For synchronization with the camera, the sample rate will be set to a maximum of 900 Hz. The encoder we have gives 5000 pulses per revolution (a quadrature encoder, so it will be 20000 counts per revolution). So, if we are rotating at lets say 3 RPM, it would be 15000 pulses per min (250 pulses per second). That's the kind of pulse rate we are expecting. The RPM will vary somewhere between, let's say 1-10 RPM.

2. The angular position data is used to feed into our images to extract the images at a particular angle. However, with the RPM data itself, it is just needed to get the motion profile, which will include the acceleration, steady state case and deceleration. And yes, it is ok to calculate the things after in post-processing.

3. For the moving average, I understood what you are mentioning about getting the RPM by just doing a finite difference of the raw data that we are collecting from the encoder. When you are saying moving average, we are still passing the encoder counts through it. So, the counts you had mentioned (4, 4,4,4,5,4, 5,4,4,4,4) also repeats itself. So, if we do finite differencing on this, we will still get the zero rpm case right? So, this is where I am confused.

4. Additional query is that would I was approaching this problem with synchronizing encoder and force data which is acquired at 10000 Hz. This you explained that there would be a lot of quantization of the encoder data. So, I was thinking that would it be better to start the acquisition of the encoder and force data together but then acquire both the data at different sampling rate. Would that be a better approach rather than going through the hassle of moving average and all?

Regards,

Abbishek

[Kevin_Price]

1. Ok, so per your example, the expected encoder rate is approximately 250 pulses per sec or 1000 counts per sec.  The camera can handle no more than 900 Hz.  Are you sure it's important and useful to sample analog at 5-10 kHz?

2. Ok, position data is for the sake of correlating images to angular positions so you can "look up" the image that corresponds to a particular angle.  Got it.   I'm not clear what the velocity profile is used for.  But more on this down below.

3. The list of 4's and 5's already *were* count differences totalled across 10 sample intervals.  There's no need to do another differencing operation.  The moving averages would just be these count differences divided by 10.

4. No, I wouldn't use different sample rates.  Sync will be much simpler if analog and encoder tasks share the same sample clock.  Yes that will lead to a lot of quantization, but you can handle that in post-processing.

And now the new thing.  X-series devices support a mode I've never personally used but which *ought* to be helpful for you here.  There's a mode that lets you take frequency measurements at a fixed, constant sample rate.  So you could measure and sample the encoder motion 2 ways at once with 2 distinct tasks -- one for angular position and the other for speed.

-Kevin P

[BertMcMahan]

You seem scared to use the moving average filter. Why is that? Use it. Having a 0-RPM case is unavoidable, and is a consequence of the encoder using integer spacing where you want fractional spacing.

Just smooth it out with a single VI (moving average) and be done with it. Unless you have a really great reason this won't work, just throw it in there. It's infinitely simpler than changing up all of your sample rates to get something else.

The reality is, if you're seeing, say, 10 encoder count changes over 20 samples, then some samples will be duplicated since an encoder can't read fractions. Each point might be a little off, but the average will be spot on. Even the frequency measurement task concept will give you some delay as well. You might just read a sample, but if no new encoder pulses have occurred since the last time you read a sample, you'll still see the old value, not the "current" value. Unfortunately, this is impossible to overcome since you're not moving through multiple encoder pulses between sample periods.

[Abbishek94]

Kevin,

1. It is important to sample the analog signals at much higher sampling rates since these signals are from a force transducer, we don't know what if we use a lower temporal resolution, will we be able to capture all the features.

2. The rotation rate is important to get the motion profile itself.

3. Would it be good if we oversample the encoder at high acquisition rates and then take the data where ever the edge count is changing in post-processing? In this case, we can get the time of the sample based on the sampling rate. So, we can extract that particular time as well where the edge count changes right? Will this be a better option to do if using two different sampling rates is a bad idea?

Regards,

Abbishek