Can I rely on DAQmx timing?

[Kevin_Price]

Been meaning to get back to this so I took a few minutes after the end of the work yesterday to do a little experimenting with two PXI-6361 devices that shared a sample clock.  This guaranteed that the *actual* first sample times should be the same (give or take some nanoseconds of signal propagation delay to get out of one board, across the PXI backplane, and into the other.)  I would then check the difference in t0 values reported by DAQmx on the first read repeatedly in a loop.

Initial attempts seemed to show a lot of differences quantized very near to 1 msec increments.   A little more tinkering and thinking brought me to a version that was consistently very much better, typically differing by only 10's of microseconds.  Later I had difficulty replicating the case where 1 msec diffs were common.  Not sure why, but I think I had not yet saved the vi when I first saw that result -- maybe that played a role?

For anyone interested, take a good close look at (and maybe try out) the code and the screencaps of run results.  The summary is: DAQmx's t0 values typically agreed to within well below 100 microsec.  Here's one result to pique your interest:

Overall, the best results came when the pre-read msec wait was bypassed (see runs #3,4) and any waiting to accumulate samples came within the call to DAQmx Read.  Runs #1,2,5 used the msec wait to be sure all the requested samples would have already been captured before DAQmx Read was called.  In these, I tried the default DAQmx wait mode of Interrupts and also the allegedly more responsive wait mode of Yield without noticing appreciable differences.

Not exactly sure why mcduff and I got such different results.  The prudent course would seem to be for those who are concerned to do some testing on their own specific platform.

For more official info from NI on DAQmx and t0, see this KB article.

-Kevin P

[mcduff]

@Kevin_Price Cool Results!!

Not sure for the discrepancy, on travel would need to find the VI I used for the test, but I do know it was a small modification of the "Synchronization" Examples in the example finder. There are some differences between your test and mine:

1. I used the Reference Clock (10/100 MHz) to sync a X-series and DSA module.
2. The cards had different sample rates.
3. Hardware or software triggering gave similar results.
4. The Wait before Read was not utilized; that is an interesting result.
5. Curious now whether I tinkered and did not save the VI and got larger results as you did.

I still believe if you need to know the absolute(GPS/1588) time for your acquisition you will need to adjust the t0 values because they are software based; not insurmountable but needed. For most cases the small t0 differences are probably not a problem unless you are doing RF work, optical work, etc.

Some cDAQ chassis and FieldDAQs can sync to a TSN(Time Sensitive Network) network. Using a compatible chassis and a TSN network they can have a "time" trigger. The accuracy of the TSN network is supposed to be on the order of microseconds or less. So in that case both sampling rates and t0's can be synced.

[Kevin_Price]

Yeah, yours was a more challenging case for the t0's, and the t0's didn't do so great at meeting that challenge.  My case was about the simplest possible with nothing but "normal" DAQ devices.  It actually did better than I expected, but I wouldn't want to generalize from an N=1 test.

At this point, I think the OP has moved on but for the sake of future searchers, maybe a little summary is in order?  I'll need some help on the parts I don't know enough about though (1588, TSN).

Timing Reliability Rankings, least to most:

Preamble: focusing here on the accuracy of the timestamps associated with individual DAQ samples.  With DAQmx waveforms, this depends on both the accuracy of the initial t0 *and* the accuracy of the dt sample interval.  I don't know details about other methods (1588, TSN, etc.).  I hope someone will follow up to explain their usage and some pros and cons.

    Now then on with the rankings, starting with least reliable working toward most.

1. Use software timing to query individual samples and individual timestamps.

2. Use hardware timing and rely on DAQmx's waveform t0 using a standard DAQ device.  My experiment showed that it *might* be quite good, in the 100 microsec order of magnitude.  mcduff's different hardware and test condition showed that it *might* be fairly poor, perhaps in the 10 millisec order of magnitude.

    Also take note that it can be very *very* much worse in certain circumstances.  One example: a finite sampling task that completes long before you call DAQmx Read to retrieve the data.  The t0 will be calculated based on when you *read* the data, not when it was originally accumulated.

    Also realize that all subsequent t0's you get from future DAQmx Read calls will be *calculated* from the first one and the nominal "dt" sampling interval of your task.  This can skew from a real time-of-day clock by a few msec per minute, which is also few seconds per day.

3. The skew of dt can be greatly improved using a device with an oven-controlled crystal oscillator (OCXO), as recommended earlier by santhosh.  Then the skew could be msec per day or fewer.  But I would still apply the other caveats from option 1 above.

4. Real, true, long term accuracy will require special-purpose hardware related to GPS, the 1588 timing standard, and/or Time-Sensitive Networking equipment.  I'll leave details and preferences to others (please?) as I have no personal experience with the methods needed to correlate their accurate time-of-day with to the t0 and dt of a DAQmx waveform.

-Kevin P

[mcduff]

---

@Kevin_Price wrote:

3. The skew of dt can be greatly improved using a device with an oven-controlled crystal oscillator (OCXO), as recommended earlier by santhosh.  Then the skew could be msec per day or fewer.  But I would still apply the other caveats from option 1 above.

---

One data point - Colleagues using three USB-6366's each in a separate location, different laptop, and took data for 2 weeks continuously. Each system had a different drift rate: +0.8s/day, +0.4s/day, and -2s/day; most likely due to temperature differences.

Possible Solutions:

1. Share a sample/reference clock. When the systems drift at least they drift together. If too far apart to share a reference clock use a GPS conditioned 10MHz reference clock for each system. 10MHz clocks won't be perfect but they should be phase aligned (1PPS GPS Conditioned) every second, so should stay relatively in phase. Or you can share a 1 PPS fiducial between systems; you know that it occurs every second on the absolute second and use that to post process your data and adjust dt.
2. Time sensitive network. I have not tried this yet, but looks promising. Hopefully in the next few weeks I will have a system ready to test. Basically just plug in Ethernet lines to modules and TSN takes care of the rest. (Some cDAQs, FieldDAQs, and cRIOs currently supported, no PXI yet.) Biggest con, still relatively new, limited hardware, capable network switches, media converters.

There are two time synchronizations in my mind:

1. Modules sampling coherently in phase
2. Modules synced to the absolute time

Both are important and different. Each user needs to decide what they need; sometimes it is both. Number 1 is relatively simple to do with DAQmx although there may be some channel to channel skew between modules. DAQmx does not support TCLK. (TCLK allows modules to start with minimum skew between modules.) Timing becomes more important in the optical/RF world. My guess is that most DAQmx digitizers do not meet the high sample rates needed for those applications, so it may be less important.

Number 2 is a bit harder because except for TSN modules. I will do a time trigger with the system when I set it up to see if the recorded t0 agrees with the trigger. I am curious.