problem synchronizing two daq devices

[high speed data logging]

Hi there

I have two NI Data acquisition boards; NI 9233 and NI 9215 (usb DAQ)

I have a code in matlab which triggers both boards and acquires 20 seconds of data at a sampling rate of 6250 Hz

for some unknown reason the data readings from the two boards are not synchronized, by that I mean that there is a 0.02 to 0.08 sec time lag between the readings for each board.

I checked the absolute time for both boards , they have been triggered at the same time and the relative times are also exact same.

both readings consist of 125000 samples and start and stop at the same time.

I have attached my matlab code for your reference

Could you please help me find out whats is going on ?

thank you

Siamak

Initialization code: %------------------------------------------------------------------------------------------------------

DataPoints = 6250;

%daq cards cannot read more than 7000 samples per iteration,

Fs = 6250;

%Sampling Rate (Samples per second)

Duration = 20;

%seconds

%Devchans + 1 ... is the number of channels for each device

Dev1Chans = 3;

Dev2Chans = 2;

NumDataPoint = Duration*Fs;

%total number of samples to be taken

fig1 = init();

%starts figure one

%format long

ai1 = analoginput(

'nidaq','dev1'); %add device one (IEPE) as the first analog input dev.

ai2 = analoginput(

'nidaq','dev2'); %adds device two (V DIFF) as the second analog input dev. %define the sample rate for each device

ai1.SampleRate = Fs;

ai2.SampleRate = Fs;

%define Channels:

addchannel(ai1,0:Dev1Chans);

addchannel(ai2,0:Dev2Chans);

%define number of samples to be taken

ai1.SamplesPerTrigger = NumDataPoint;

ai2.SamplesPerTrigger = NumDataPoint;

%define AI Object

ai = [ai1,ai2];

%define logging mode to be done in memory , can be set to disk if %desired

ai.loggingmode =

'memory' ;%'disk'

ai1.LogFileName =

'ai1.daq';

ai2.LogFileName =

'ai2.daq'; %set trigger manually using start(ai) command:

ai.TriggerType =

'manual';

start(ai);

%end of initialization code ------------------------------------------------------------

%data acquisition code:

ai1 = ai(1);

ai2 = ai(2);

pause(2);

addreport(hObject,handles,

'Acquiring now......');

trigger(ai);

t = clock;

while (strcmp(ai1.running,'On'));

pause(1);

[CurrentData] = PickData(SensorNum,DataPoints,ai);

[xx,yy] =size(CurrentData);

DisplayError = DisplayData(SensorNum,CurrentData,DisplayType,hObject,handles,Fs,0);

etime(clock,t);

GG = ai1.samplesacquired/NumDataPoint;

GG= fix(GG*100);

report = [

'Samples Acquired; AI1:' num2str(ai1.samplesacquired) ' AI2:' num2str(ai2.samplesacquired) ' ' num2str(GG) '% Completed' ];

addreport(hObject,handles,report);

end;

wait(ai,100);

[data1,time1,abstime1,events1] = getdata(ai1);

[data2,time2,abstime2,events2] = getdata(ai2)

%--------------------------------------------------------------------------------------

could you please help me with the problem?

[T_Marsh]

Hello High Speed,

The problem that you are encountering is a common problem due to the nature of the all DSA cards, inlcuding the 9233 board that you are using.  This board uses a Sigma Delta ADC which automatically filters out higher frequency components but also introduces a certain delay in the signal.  This delay is always going to be a certain amount of time.  You will have to delete a certain number of samples from the other acquisition in order to synchronize the readings.  The number of samples you have to delete depends on your sample rate.  The easiest way to figure out how many samples to delete is to just try it out with one signal wired into both inputs.  You can refer to these links for more information. 

Why Is My Data Delayed When Using A Digital Trigger With My DSA Device?

Synchronization with Dynamic Signal Acquisition (DSA) Products with DAQmx

[high speed data logging]

Hi , Thanks for the Reply

it seems other than sampling rate, this delay also depends on something else, since every time i start logging, different number of delays appear. I read the two links you'd sent me , and apparently it also depends on some voltage which I don't know what it is.

do you have any idea what this voltage might be?,

Unfortunately this is an automated process involved in processing hundreds of matrices and I need to somehow automate this truncation algorithm.

PS it seems the lags vary from 0 , to more than 250 for a sampling rate of 6250 Hz

Thank you

Siamak

[T_Marsh]

Hello High Speed,

I’ve had another idea after you mentioned that the number of samples that you miss varies so much.  I went back and looked at your code and from what I can tell it looks like you have software timing.  Now is the appropriate time for the Disclaimer:  We did not write that code and we do not officially support any of the higher level code that you’re using.  It looks to be code from another vendor.  We support the board and the drivers that we’ve written, but for official support of that code and exactly what it does you might have to contact the people who wrote it.  That being said I have a pretty good guess on what is going on and I’d like to help to the best of my ability.

First, I want to confirm that you are indeed using the USB 9215 and the USB 9233.  They are probably each in a separate carrier and each have their own USB cord.  The other alternative is that they are both in a USB Compact DAQ chassis.  If they are both USB versions, then there is bad news, because there is no way to synchronize these devices besides in software, which has the obvious limitations that you’re running into now.  If they are in the Compact DAQ chassis it is possible to synchronize them to within a set number of samples because they share timing and triggering lines.  There are still a few difficulties because one is a DSA card and one is a standard AI card, but those difficulties can be overcome as mentioned in the above KBs.  

Right now you’re basically doing software timed acquisition.  That means that one task is going to start and then the next is going to start.  There is no hardware trigger connecting the two cards, and in fact I don’t think the 9233 even supports triggering.  There are ways of getting them reasonably close, and it looks like you’ve taken those measures already.  Besides making sure to call both start tasks right in a row there is not a lot you can do to increase the timing.  Everything is at the mercy of the operating system to execute the actions as quickly as possible one after another.  It’s unlikely that they’ll ever start at exactly the same time.  If you do need synchronous results then you’ll have to look other hardware.  I would recommend cDAQ because you would be able to reuse the modules that you’ve already bought and would only need the chassis.  It would also keep the flexibility of USB for you.

If you are in fact using cDAQ and still having difficulties, please let me know.  If you are triggering the start of the acquisition with cDAQ there should be a deterministic delay between modules rather than a variable delay between the modules that we are seeing now.

Regards,

[high speed data logging]

Hi Travis

Thanks for the reply 

I am using these two devices using separate USB cables and as u mentioned I don't think there is a way to synchronize them using hardware, however the thing I don't understand is that why do I have the same trigger absolute times. But the data from the two DAQs have somewhere between -50 to 300 samples delay. And yes, I have negative delays too , which I cannot explain (my impulse is sometimes after my response).  Shouldn't my absolute trigger times be different if the two devices are starting trigger at different times?

Thanks again

Siamak

Here is an example of the absolute timing of the two devices, taken from their event logs:

event log for the second device:

eventlog2.Data

ans =

      AbsTime: [2006 9 23 17 13 13.1222]
    RelSample: 0

ans =

      AbsTime: [2006 9 23 17 14 25.9589]   <<---- trigger absolute time
    RelSample: 0
      Channel: []
      Trigger: 1

ans =

      AbsTime: [2006 9 23 17 14 45.9967]
    RelSample: 125000

event log data for the first device:

eventlog1.Data

ans =

      AbsTime: [2006 9 23 17 13 13.1086]
    RelSample: 0

ans =

      AbsTime: [2006 9 23 17 14 25.9589]   <<------ trigger absolute time for the first device
    RelSample: 0
      Channel: []
      Trigger: 1

ans =

      AbsTime: [2006 9 23 17 14 45.9976]
    RelSample: 125000

[T_Marsh]

Hello Siamak,

Again I can’t be positive of exactly what the code is doing, but here is my suspicion.  I think the timestamping information is coming from the computer and is put into the data after the fact.  Basically the timestamp is being inserted by software instead of taking any sort of hardware timestamp.  For these cards that you’re using that is basically the only way to get a timestamp like you’re seeing.  The boards themselves do not have any sort of atomic clock and are not receiving a GPS signal so they cannot have anything resembling and absolute timestamp.  

Since the timestamps are coming from the operating system, it would be easy to see how you could get two identical timestamps because a timestamp is taken once and then applied to both of the sets of samples.  Unfortunately this gives us no indication of when either task actually started.  Ideally the function calls would be setup in this order.  Start task 1, timestamp 1, start task 2, timestamp 2.  In that way we could get more accurate and useful timestamps.  They still would not be perfect though since we’re relying so heavily on a non-deterministic operating system to perform the actions.  

As far as why you could get negative delays.  It could be that it does not always start the tasks in the same order each time.  Again, this may be something you would have to discuss more with the people who wrote the functions that you are using.  This could also be related to using USB for the communication which is also non-deterministic and could take longer sometimes to transmit the information, or longer to communicate with one card than another.

I hope this helps clear up some things.