[Edit: started this in response to your initial question. By the time I posted, you had followed up with the same solution I arrived at. So I'll endorse your method and leave the rest of the post below to give future readers some more context for the thought process behind it.]
-------------------------------------------------------------
Short answer: your intution is right, there IS a lurking issue with time disagreement between DAQmx and your PC's time-of-day clock.
There's not a simple perfect fix, but you can do some very very good approximations. However, there's some things to know before you navigate toward your preferred solution.
1. How DAQmx deals with t0, dt:
The initial t0 is established one time only when you make your first DAQmx Read. Based on the known sample rate, the # of samples acquired so far, and a one-time query to the real time-of-day clock of your PC, a best estimate for an initial t0 is established. After that, all subsequent t0's are calculated from a combo of the initial t0 and the known dt.
2. Accuracy of DAQmx's t0, dt:
t0 will normally be quite good. No specs or guarantees here, but I suspect we're talking sub-millisec realm. dt is also quite good with many common devices spec'ed to 50 ppm timing accuracy. At the spec limit, this is 3 msec per minute which leads to about 5 seconds per day. Any actual devices I've checked out have appeared to be less than 1/2 of this.
Generally speaking, dt will be *very* consistent. If slightly inaccurate, it will generally be a consistent inaccuracy. There are small temperature dependencies, but long-running tests tend to be near-steady-state for temp.
3. Accuracy of PC's real time-of-day clock:
Absolute time will be quite good. The clock itself is subject to the same kinds of inaccuracies as DAQ devices under DAQmx, but modern-era OS'es have things like NTP to prevent long-term timing drift (assuming a network connection). The local clock is regularly kept in alignment with a trusted network time source.
The "dt" of this clock is less consistent as it regularly gets tiny corrections to stay in sync with the time server it finds out on the network. The magnitude of this variation will be quite small but it's prone to change (slightly) pretty often.
Note: I was around in the old days of DOS (and early Windows too I think) where network connections were not ubiquitous, and it was commonplace for PC clocks to drift noticeably over the course of weeks & months. Back then, we all regularly saw the issues of cumulative inaccuracy and drift. Nowadays, it's largely hidden away and many aren't even aware. So good job anticipating this!
4. Hardware vs software time
The PC's real time-of-day clock must be queried by a software call. DAQmx's sample clock is a hardware pulse train derived from a fixed-frequency crystal oscillator.
Each individual query of the real time-of-day clock carries a little jitter in both t and dt as a consequence of the software query. t itself is prevented from cumulative error over the long run via NTP.
Under DAQmx, dt has very little jitter but it's small inaccuracy *does* accumulate over the long run. And this shows up in each waveform chunk's t0 value which is *calculated*.
5. Suggested practical solution:
During your 100 hours, treat the waveform t0 and dt as though perfect. Don't mess with them or adjust them. Just store your data and act like you believe them.
However, *also* be sure to carefully query the real time-of-day clock at both the beginning and end of the acquisition. Do this *very* carefully, thinking about dataflow, execution sequence, and possible "off by one" errors when assigning that specific time to a specific sample. Then you'll have a 2nd measure of the delta time for the entire test and a known number of sample intervals between them. Now you can calculate an *actual* average acquisition dt and also store *this*.
If you were careful enough, this measure of dt is likely just a little bit more accurate than what you got from DAQmx over the course of a 100 hour test. (The method wouldn't be such a great idea for shorter tests where the non-cumulative jitter of software timing could be larger than the cumulative DAQmx clock inaccuracy.)
During subsequent post-processing, use your better estimate of dt in place of the one from DAQmx.
Final thought: don't read this as an indictment of DAQmx or the data acquisition clocks. They're inherently pretty much on par with the PC clock for accuracy. It's just that the PC gets extra help by getting regular adjustments to align with a network time server. Which makes sense for an overall PC in a way that it *doesn't" make sense for a data acq device. A lot of data processing algorithms assume and depend on consistent sample intervals. So a data acq device needs its clock to operate at a regular and consistent rate and *not* try to adjust it mid-stream.
Hey, it's the real world, where "good enough" is often a more useful target to aim for than "exactly correct."
-Kevin P
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
