Measuring rpm - counter freezes

[ceties]

I will add sort of solution of the problem. I can use the 3rd method - wide range of freq with 2 counters. If I use the lowest possible divider = 4 I end up with 900 points. It's not super good but the error won't rise. And as I still hope I can use the 3600 points in another parallel loop for DAQ - that shouldn't be a problem. Now the best thing. I just discovered that I can manually route two signals on BNC 2110 to one user input/output. To be more concrete I routed PFI3 and PFI4 to User1. This way I can programatically decide what method to use without manually changing the counter inputs (both methods use different counter inputs) so the cable with TTL from IRC remains still in User 1.

[ceties]

I have one more question.

The crystal oscillator used on the PCI-6120 is rated at 100 parts per million (ppm) stability over temperature. 100 ppm means that for every 1 million Hertz, the frequency can be off by ± 100 Hz. For a 6120 board, which has a 20 MHz oscillator, the error due to crystal used could be up to (± 100Hz / 1 MHz) · 20 MHz = ± 2000 Hz

What are actually those 2000Hz?
Does it mean that if I use the first method (one counter, low range) I can be 33rpm off for each single reading just by the crystal error plus there are the method measurement errors to take into account?

I hope I am not asking too dull questions
Thanks

[John_P1]

Hi ceties,

Let's start by taking into account the accuracy of the measurement method you are using.  Here's a chart that shows the accuracy of the various counter methods (taken from the more recent X Series User Manual).  In the chart, fx is the frequency to be measured, while fk is the timebase frequency (both in Hz):

I'm not sure how much error in RPM you will see since I still do not know the max rate of your input signal.  The higher the frequency of your input, the more error you could potentially experience. 

I'm not sure how you calculated 33 rpm error from just the timebase alone, but when measuring frequency the 100 ppm accuracy of the timebase is not going to make a significant difference in your measurement (compared to the measurement uncertainty).  We can go through some numbers for an example:

Let's say we're on the 3600 ppr encoder rotating at 2500 rpm and using the single counter method.

The pulses would be coming in at 150,000 Hz (6.67 useconds per period). 

During each pulse, we would expect to count 133 or 134 ticks of the 20 MHz timebase depending on the relative phase between the timebase and the encoder signal.

If the timebase was 20002000 or 19998000 instead, we would still expect 133 or 134 ticks in this case.  I believe we would have to count at least 10,000 pulses at 100 ppm to generate a whole extra pulse during the frequency measurement.

This would give a period measurement of either 6.65 or 6.7 useconds.  The driver then inverts this to receive frequency measurements of 150376 or 149254 Hz.  Both numbers are within the maximum frequency error of ~1133 Hz calculated from the formula in the table above (20 MHz timebase, 150 kHz frequency to measure).

So, for the vast majority of frequency measurements using the single counter method you can essentially ignore the timebase accuracy since its contribution to accuracy is vastly overwhelmed by the uncertainty of the measurement method.

Best Regards,

John

[ceties]

Thank you John! It's clear to me now!

[ceties]

Hi John, hopefully the last thing I would like to ask is how many pulses it will actually count in the example you posted. 133, 134 - those I understand but couldn't it count also 132? Thanks

[John_P1]

Hey ceties,

Sorry for the delay, I've been out of the office for the last week and a half.

To make things easier, let's simplify the numbers.  Let's say we were trying to measure a pulse that is between 2 and 3 ticks wide.  If we barely miss one timebase edge, we should still pick up the next two.  We might also possibly measure 3 ticks if the first timebase tick occurs towards the beginning of the pulse:

 

If the signal's duration is approximately an integer multiple of timebase ticks (say, 2) then we now have another possibility.  We might have a scenario where we catch 1, 2, or 3 edges:

With the numbers I mentioned in my last post we were measuring a signal with a ~6.6667 u second period. 133 ticks of the 20 MHz timebase would only be 6.65 u seconds, while 134 ticks would be 6.7 u seconds.  The signal is safely in between the two counts, so I would expect to only see the two possible outcomes.  For other values there may be 3 possible options if there is an integer number of timebase ticks in one period of the signal (accounting for jitter of the signal and of the timebase).

Best Regards,

John