Frequency measurement on PXIe6614 using two counter method, not accurate as expected

[BoonPing]

Hi all,

I am trying to use PXIe 6614 digital counter to measure a clock frequency (32768Hz). 

The method i am using is "Large range with two counters". According to the manual of the card, The first counter will generate a pulse based on  number of pulses (N) of the input measured signal. and then measure that pulse generated from first counter by a known time based frequency. Which in my case I am using 100MHz on PXI chassis.

In my code, I have define the the N = 1000. 

Based on the formula in the manual, the error around 0.01Hz.

When I start measure, over 10 measurements, I got random 1-4 over 10 measurements has 32.77Hz offset.

From this offset I am suspect the first counter somehow make an additional count over 1000 cycles.

May I know is there a way to synchronize the clock and the first counter and the second counter? Or is there other issue that causing this?

Thanks

Regards,

Boon

[Kevin_Price]

Can you post your code and results?  I'm not sure what you mean by "offset", and 32.77 Hz seems much too large to be explained as quantization error.  I think something else must be wrong, but can't really tell without seeing code.

-Kevin P

[BoonPing]

Hi Kevin,

The code is straight forward. First, define the port, min and max frequency are: 32kHz & 35kHz, division is 1000.

The test result at attachment. I have ran the measurement at different division. The "offset" i mean is the measured frequency shift.

At division = 1000, the huge shift in frequency is around multiple of 32.xxHz.

At division = 5000, the shift in frequency is multiple of 6.4Hz 

Based on the shift trend at different division, my guess if the counter actually return one additional count on the input signal. the measured frequency will shift that much of Hz per count at specific division. Based on the formula given in the 6614 user manual.

[Kevin_Price]

I've done a lot of counter stuff, but never the "Large Range 2 Counter" approach.  So let's see if I follow.

For a division factor of 1000, then T1 = 1000 and the pulse out of the 1st counter is 1000 periods of the input signal.  With an input signal of 32768 Hz, 1000 periods will be 1000/32768 ~= 0.03052 sec.  That should be the duration of the pulse out of the 1st counter.   The 2nd counter measures it by counting cycles of its timebase, presumably 100 MHz.  It should count to ~ 3.052e6.

The calc should produce (10 MHz) * (1000 / 3.052e6).  The smallest value in the calc is 1000, so a quantization error of 1 count would lead to 1 part per 1000 error.  With an actual freq of 32768, it *entirely* makes sense that quantization error could show up as jumps of about 32.768 Hz.

What's not yet clear to me (because I don't have a complete understanding of ho (the "Large Range 2 Counter" method works down in the hardware and driver) is:

• whether the "pulse generation" behavior of counter 1 is designed to *prevent* the possibility of an off-by-1 count error due to such quantization
• how you could sometimes get off-by-2 (or more) errors, as seen in the attached data

One clue I get from the data is that errors are *always* biased on the high side.  This means that the task got its counts over a *shorter* time interval than it should have.  Off-by-1 errors can be due to quantization, if the low-level behavior isn't preventing it (the simple diagram suggests there might be such prevention).  Off-by-2 or more errors cannot be explained this way.

So I start to wonder if your input frequency signal is not entirely "clean".  Try experimenting where you generate a clean stable frequency with one of your other counters, see if you get any such errors.  You can also look into your board's digital filtering capabilities to try to suppress any brief glitches in the original signal.

Sorry, not quite definitive help, but trying.  Further note: your code takes any array of hardware-based freq measurements and averages them.  Why?   Which data is in the file, the raw freq data from the task before this average or the result of this averaging?   If it's the latter, I'd like to see more of the code.  From the portion I can see, I wouldn't expect software averaging to preserve such a distinctly quantized error.  But maybe there's something else somewhere else?

-Kevin P

[BoonPing]

Hi Kevin,

The data is before averaging. 

The problem is this was setup in production test. Every units has the similar effect. We are now trying to measure a known good signal and see if we still see the same issue.

Any guys experience in PXI6614 counter with large range 2 counter method? Just want to confirm that the code has no problem.

Thank you

-BoonPing

[Kevin_Price]

Sorry for the delay, I've been away for a week.

Why was the "large range 2 counter" method chosen in the first place?  It sounds like you have a fixed nominal frequency, not a large range to accomodate.  Maybe you should use a different measurement method!

What are your measurement resolution requirements?  What is the time allowed for making this measurement on your production test system?  How many independent measurements must be made -- are you also collecting statistics?   Note: your answer to each question has implications for the others, it simply isn't possible to get a large number of arbitrarily excellent measurements in an arbitrarily short time period.

In your present setup, your quantization error is mostly based on your divisor.  A divisor of 1000 gives you 0.1% and a divisor of 5000 would give you 0.02% quantization error.

As I said before, quantization error typically comes from an off-by-1 error in an integer count.  Off-by-1 quantization errors are commonplace in many counter measurements, though it's possible (I simply don't know enough to say) that the "large range 2-counter" method is less vulnerable.  However, your data shows cases where your count seemed to be off by 2 or more.  That's *NOT* a commonplace symptom of a quantization error, it's usually something else.  Glitches or transition "ringing" are the two things I've bumped into most.

Summary: the code does not look obviously wrong, but you also may benefit by changing it.  It's quite possible you've chosen the wrong measurement method or are dealing with signal integrity problems.  There are code changes you can make that might help.

-Kevin P

[BoonPing_Lai]

Hi Kevin, 

Thanks for the reply. Our measurements accuracy resolution requirement is +/- 5mHz.

I have tried the other method "high frequency with 2 counters" and the results was even worse compare to large range 2 counters method.

We didn't have very strict time limitation on measurement but hopefully it doesn't require a minute just to measure the feequency.

Thanks for the advise and i will look into the suggestion you gave and try to find the root cause. 

Regards 

BoonPing 

[Kevin_Price]

Wow, 5 mHz resolution on a nominal 32768 Hz signal is less than 1 part in 6.5 million! 

  That's far beyond the precision/resolution I've typically sought.  But your mention of such resolution reminded me to lookup info about an Agilent DMM (34401A) we have a bunch of.  They use a technique they call "reciprocal counting" for which I didn't quickly find a clear and thorough explanation.  They claim a large # digits for resolution *and* a very fast measurement update interval.

I would have expected one of NI's "2 counter" approaches to be an attempt at a similar implementation, but I don't know if that's a realistic expectation.  I've really never explored those 2 counter methods and I might have been missing out on a major feature all these years.

The methods I typically use seem to be called "direct counting" in the Agilent (now Keysight) literature.  With these methods, resolution is based on allowing for a quantization error of 1 count.  This implies that for a count error of 1 to be limited to a 1 part in 6.5 million error, you need a nominal count of 6.5 million.  6.5 million cycles of a 32768 Hz signal would require 200 sec per measurement.  Ouch!  

I'd also be *very* interested in a way to use NI counters to get 0.005 Hz measurement resolution in, say, a second or less on a ~32 kHz pulse train.  I'm going to have to dig around more to learn about Agilent's "reciprocal counting" technique.

- Kevin P