cdaq 9188 t0 time stamp

[Ben_Phillips]

Hello,

I have 2 cDAQ 9188 chassis's separated by quite a bit of distance, and running any kind of coax or wire between them for clock sharing is not feasible, nor is tight synchronization very necessary.  (Both being read by the same PC & software)

But I am tracking the time jitter between them by simply comparing the t0 time reported on the waveforms produced in the DAQmx read.

My question:  Who is producing/determining that t0 time stamp?  

Is it produced by the PC clock, or some calculation based on when the task started and how many clock iterations have passed?  

Or is it produced solely by the 9188 chassis?  If this is the case, I'm curious if the clock on the chassis is being silently synced to the PC clock at some interval.

If the t0 time stamps are all being produced ultimately by the PC clock, then my little tracking algorithm is pretty useless.  This is okay if it's the case, I would just like to know how confidently I can say that I'm tracking the cross-chassis jitter.

Perhaps I'm missing some other way to track the jitter between the chassis's that I haven't thought of.

(FYI, this can be shown using simulated devices, it seems to act very similar to the actual hardware, so if this doesn't fully make sense I could produce a small set of code that shows what I mean)

On a slightly unrelated note, where are the kudos for daqmx?  LabVIEW gets a lot of love, rightfully so, but this driver is brilliant.  Never hear anyone singing its praise.  Maybe that's because when people talk about it they're usually trying to figure out why it's throwing a fit and refusing to cooperate 😉  But the fact that it can complain lucidly instead of silently failing is yet one more reason it's so good to use.

Thanks in advance,
-Ben Phillips

[Tom_W_[DE] · Accepted solution]

Hey Ben-

The t0 timestamp is referenced solely from the PC clock.  The time on the chassis is not synched with the PC in any way, and the chassis time is not factored in to the calculation of t0.  Truthfully, the t0 value is approximately the time that the task is armed/started and doesn't have a very strong correlation to when the first measurement is actually taken, especially for cases like start-triggered tasks and the like where there might be some significant time between arming the task and taking the first sample.

Perhaps a way to get an approximate idea of the lag would be to ping both chassis from the viewpoint of the shared host.  The roundtrip time to pass a single packet to the chassis back and forth will give you an approximate idea of the lag for single-point applications, assuming that the chassis hardware is started at about the same time (which would require a shared physical trigger connection).

If you're not worried about tight synchronization then I would say go on with your blissful disregard for the timing because t0 probably doesn't provide much meaningful info for the case you're trying to measure.

[Ben_Phillips]

Tom, thanks for the answer, that answers the question perfectly.