daqmx read waveform: absolute time (t0) is incorrect?

[Pianne]

Hi all,

In my LV 2012 application, I continuously read Analog inputs from a NI DAQ device (NI PCI-MIO-16E-4, DAQmx driver 9.5.5)).

All available samples are read every 100ms, at 1kHz this results in 100 samples per read action.

I expect the t0 value of the output waveform to be 100ms ( 100 samples * 0.001s dt ) earlier than the actual time of reading. However, this is not the case,I notice a difference of about 23 seconds between the actual time and t0 of the waveform.

Attached is a screenshot of the block diagram with a probe window, showing the actual time and the t0 value of the waveform.

I must add that this application was running for a few days when this screenshot was taken.

Any ideas on why this happens?

I know I could work around this problem by calculating t0 from the current timestamp but I'm curious about why this occurs.

Thanks in advance,

PJ

[GerdW]

Hi Pianne,

I must add that this application was running for a few days when this screenshot was taken.

I don't know the internals of DAQmx driver, but maybe this driver keeps it's own timestamp counting based on sample rate/sample count. That way you could notice a mismatch between PC time (with it's own deviations) to DAQmx time.

Maybe someone from NI can elaborate on this topic…

[Pianne]

After some more digging, I found this:

http://digital.ni.com/public.nsf/allkb/5D42CCB17A70A06686256DBA007C5EEA

It seems that the DAQ card only reads the system clock once, the first time the read function is called. After that, all absolute times are derived from that first t0.

I'm surprised that there would be so much drift over a few days.

I guess I'll have to calculate t0 myself, for each read as

t0 = CurrentSystemTime - (NoOfSamplesRead * 1/SampleFrequency)

[GerdW]

Hi Pianne,

so this linked app note supports my assumption…

I'm surprised that there would be so much drift over a few days.

Well, PC system clock isn't that accurate.

Samplerate isn't always exactly at the requested value, depending on used hardware and it's limitations.

You might correct the timestamp by your approach, but this will result in short "breaks"/"jumps" of your datastream looking similar as missing samples. You should anyway collecting all measurement data on just one time base…