Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

Frequency measurement accuracy for NI-PCIe6351

Hello,

I have a problem with a frequency measurement accuracy of an 8MHz signal, using internal base clock, measurement is made using the counter section of a NI-PCIe6351 card. Frequency measurement acceptance limits are 8MHz +/-25ppm.

I am suspecting a problem with measurement accuracy due to internal base clock accuracy which device specifications indicates that is 50ppm.

I am looking for a formula to calculate absolute accuracy for frequency measurement, something similar with analog output accuracy equation described  on device specification document. Considering how well is documented accuracy calculation for the analog measurement / generation section, I was surprised to see how little official information is available in the same document regarding accuracy calculation for frequency measurement / generation using counters, in respect.

Any information on this topic would be appreciated. Thank you !

0 Kudos
Message 1 of 4
(1,216 Views)

First things first.  Not everyone using the word accuracy means the same thing.  It sounds like you're onto the correct definition, but let me just lay out some distinctions.

 

Accuracy - the 50 ppm spec tells you *most* of what's relevant about absolute accuracy.

 

Repeatability - whatever timing measurements you take, you'll get results that are much more *repeatable* than 50 ppm.  Speaking from experience (so this isn't truly science, just observation, you'd probably be in the single digits of ppm for repeatability.  Most of this *variation* in accuracy is caused by temperature variations.

 

Quantization - this will often be the biggest source of discrepancy until you take extra care to account for it.  Measuring a single 8 MHz interval with a 100 MHz timebase yields a nominal 12.5 cycle interval.  Since counters are integer-based, you'll get a long series of intervals alternating between 12 and 13 cycles of the 100 MHz timebase.  Those turn into apparent frequencies of 7.69 and 8.33 MHz, right around 4% error or 40000 ppm.

    One would usually reduce quantization error for high frequency signals by using one of the 2-counter methods.  For example, you could count cycles of the 8 MHz signal during a 0.1 second interval where you'd expect a nominal 800000 counts.  The absolute count error due to quantization is still +/- 1, but your relative error is just a little over 1 ppm.

 

Bottom line: if you need better than 25 ppm in true absolute accuracy, you need different hardware.  The 6351 isn't spec'ed for it.  I know NI has had dedicated counter devices based on oven-controlled oscillators that have accuracy specs rated in the parts per *billion* (because they're less than 1 ppm), but the ones I'm aware of are PXI-based. 

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 2 of 4
(1,170 Views)

Hello Kevin,

 

Thank you for your answer !
I was expecting that internal reference accuracy might not be enough for this application.
However, after investigating a little more, it seems that counters are configured to use an external reference of 10MHz, with far better specifications that on board one, with +/-100ppb frequency calibration, +/-5 ppb temperature stability, +/-1ppb/day daily aging, +/- 300ppb liftetime tolerance etc.

I am not sure if this reference choice is a good one for this measurement, I would have chosen a 100MHz value as you also indicated. It is possible to configure NI-PCIe6351, to use this 10MHz external reference that is supplied to the board, to generate an internal 100MHz that would be used as reference for counters ?

0 Kudos
Message 3 of 4
(1,141 Views)

Here's what I *think* to be true but only with ~70% confidence.

 

1. The 10 MHz Ref Clock that can be supported *by* the device is not generated *on* the device.  You would need to supply your own highly accurate 10 MHz clock source and configure your device / task to use it.

 

2. In the PXI realm, such a clock is provided across the backplane of the chassis (probably with varying accuracy specs for different models) and most boards automatically use it to phase lock their own internal timebases.  At least on PXI, that makes the individual boards phase-lock on the reference clock.  Thus if you were to make use of a device's 100 MHz timebase, you could know it was phase-locked to the externally-supplied highly-accurate 10 MHz Ref Clock, giving you almost all of the accuracy benefit of that Ref Clock (give or take the generally marginal impact of signal propagation jitter and PLL error).

3. I think the same kind of thing can be done on PCIe boards, but you have to do more of the work manually.  I've only done explicit Ref Clock configuration once I think, many years ago and it was a specialty device on a PXI system that didn't do it automatically. 

   I can't help a lot with details, but I think you may find there's some special rules / limitations.  For example, it may need to be configured by the first task to be started on the device, or possibly in a device-wide context outside of any tasks before any are started.  That kind of thing.

 

Myself, if I had an accurate clock source available, I might just use it directly as my timebase for counter measurements.  As I illustrated earlier, *quantization* error is likely to be the driving factor when you need highly accurate frequency measurements.  So that's already likely to push you into a 2-counter method where you gain resolution by using longer intervals to determine the frequency.

   Once you're in that 2-counter mode, an accurate 10 MHz clock can give you the same resolution as a 100 MHz clock if you collect for 10x the duration.  For example, in 0.01 sec, you could get quantization error down to 10 ppm with a 10 MHz clock.  (At 100 MHz, you'd only need 0.001 sec).

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 4 of 4
(1,134 Views)