DAQmx large range 2 counter frequency measurement 1 count off error

[pdeboer]

I'm using a NI PXI-6229 to measure a 32.768kHz RTC ref clock.

I'm setup in MAX with a task using the largerange2 counter frequency  measurement, as I need a very precise measurement.

Every say, 1 in 30 measurements comes back wildly out of value compared to the baseline.

ie. 32950.1287968 Hz with a divisor of 181.  

When it fails it always is 32950.XXXX when the divisor is 181.  Otherwise  seems very accurate.

This value is 181/180 * the value.

I figure that one extra trigger in the sample pre divisor might be the problem, but scoping the signal I don't see any glitches.

Is there a way to filter higher frequencies.

Any ideas?

[pdeboer]

So, the missing cycle is probably quantization error.

But, increasing the divisor to get a smaller error drifts the value higher until it fails my test.

[Kevin_Price]

What do you mean about "drifting the value higher?"

I've almost exclusively used the 1-counter version of period measurement for these things.  If you set up a buffered measurement with Implicit timing, you'll be able to capture a stream of consecutive periods.  This sets you up with a set of raw data you can post-process flexibly to trade off between error and effective sample rate.

For any 1 single interval, your quantization error will be in the order of 80MHz/32.95 kHz or around 1 part in 2400.  If you decimate by averaging across sets of 10 samples, you'll reduce your error to 1 part in 24000 while reducing your effective sample rate to about 3.3 kHz.  Decimate across 100 samples and your quantization error goes to 1 in 240k with sample rate around 330 Hz.  And so on with any other decimation factor you may want to explore.

-Kevin P

P.S. Please note that there will also be an *accuracy* error due to the (assumed) independence of your data acq board's timebase and that of the RTC.  Many NI boards' timebases are spec'ed for something like 50 parts per million.  Realize that the discrepancy between the nominal RTC freq and what you measure is the *SUM* of the two timebases' inaccuracies.  It isn't all measurement error, some of it is error in the RTC freq.