Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

Accuracy of the frequency reading - too 'noisy' reading

Ceties,

 

I think you got it right. Because of manufacturing precision of mechanical parts of encoder itself, even with very constant velocity you can see differences in speed. I was thinking about your implementation for a while, and I just wasn't sure if it is the best to use encoder as speed measurement - because to measure speed should be enough to use 1 pulse per revolution. Then the speed measurement should be much better. I wasn't sure, because lately I saw couple of application where people were using encoder to measure speed instead of position.

 

regadrs,

stefo

Certified-LabVIEW-Developer_rgb.jpg

0 Kudos
Message 11 of 15
(3,106 Views)

One pulse per rev wouldn't be enough - I am also interested in the speed oscillations during one revolution.

Thank you both guys!

LV 2011, Win7
0 Kudos
Message 12 of 15
(3,104 Views)

I began to dig little bit more into this. I really thought that it is the accuracy of the IRC. I even found that in the data sheet of the encoder it says  Dynamic accuracy at 10,000 1/min (signal delay) is 0.02 deg. That with 0.1 resolution gives the possible deviation of 20% between two pulses...

 

Nevertheless, I thought since it is sort of noise if I average it over few revolutions I should get smoother curve - synchronous filtering. But I didn't. So I plotted five revolutions overlayed and now I am a bit scared. If it was just the limitations of the IRC accuracy I would expect it to be kind of random. But as can be seen the "peaks" occur at same location in each revolution. And it always happens at every 10th sample. How to interpret this? That every Nth window in the IRC was manufactured worse? Is it problem of the algorithm of the IRC multiplier that is used to obtain higher resolution - x4 method...I have no clue. Do you anybody have any idea what is going on?

LV 2011, Win7
Download All
0 Kudos
Message 13 of 15
(3,013 Views)

Your data is both interesting and suspicious.  It's too repeatable for the spikes to be random noise, while the detail view shows a kind of bi-modalness that isn't normal for manufacturing defects. (Pun on the word "normal" not originally intended.)  The spikes are large in relative amplitude and seem to alternate between + and - deviations.  Overall, it has more the feel of an electronic or numerical anomaly than a physical one.

 

You referred to some kind of electronic multiplier -- that's where I'm placing my bets.  My guess is that the regular spikes every 10 samples are when the algorithm makes adjustments based on its observations over the recent past.  That combines with some quantization (I'm guessing) such that those spikes represent one quantum of change somewhere in the system.

 

During the 9 near-constant measurements between the spikes, there appears to be a smaller variation.  Again, just guessing, but I'll venture that the electronic multiplier is generating a constant freq there but measurement quantization toggles between 2 measured values.  Meanwhile the 1 in 10 spike is an adjustment or quantization generated by the multiplier.

 

If you're stuck measuring after the multiplier, can you average across at least 10 or 20 intervals?

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 14 of 15
(2,997 Views)

Hi Kevin and thanks for your insight. This is not an issue related to NI hardware so I appreciate it even more. 

I will repeat the measurements in 2 months so I will try the averaging (now I have only 5revs available). Meanwhile, I decided to contact the manufacturer of the IRC (Kistler) to see if they can shed some light to that.

Thanks again 

LV 2011, Win7
0 Kudos
Message 15 of 15
(2,987 Views)