Last week we tried to do continuous acquisition in combination with time-stamping. For our seismological application, we need to know the time at which an event (= earhquake/seismic wave) arrived at our sensor. For this we have a PCI GPS-card.
An easy implementation would be to start a scan of all channels at a trigger of the GPS-card at 100 Hz (our prefered sample-rate), but the GPS-card does not support this. However, it can take a timestamp given an external trigger.
So the idea is to do simultaneous AI and AO and use the AO to trigger the time-stamp-capture of the GPS-card.
So much for the introduction. We have been looking at how synchronous the AI and AO actually is. We generate a signal using the AO and feed it into the AI. First we tried starting the AI, then starting the AO. This gives a delay of about 0.25 msec between the signals.
First starting the AO and then the AI gives a delay of about 40 msec!! (this last sequence is recommend by NI)
This was not acceptable.
(Before I forget, we use NIDaqBase on a Linux workstation and the M-series 6225, sampling at 100 kHz )
starting the AI and AO tasks via an external trigger gave exact synchrone starts of acquisition. So this is probably the solution that you need.
What we saw however was that the AO and the AI use a different convert-trigger! (I would like to have a comment on this by an NI-engineer!)
every now and then, it seems that the AI trigger frequency speeds up, and then the frequenct AND phase!! of the two triggers become synchome again! This happens 4 times in this (reproducable) 1000 samples test.
I have attached to images of the same data sequence. (appologies for the poor image quality) One in which the 4 events are visible and onother image, showing the frequency-speed-up and re-phasing in detail.
We look forward to any replies!
Tim