cDAQ module synchronisation

[Neil.Pate]

Hi All,

I am trying to do something I thought would be relatively simple. What I want to do is synchronise the starts of the AI of two different cDAQ modules. Both will run at the same sampling rate.

Attached is my attempt. The code works, but the two modules are clearly not synchonised. The time difference between the two modules seems to vary each time I run the code. Can anybody provide some insight into what I am doing wrong?

Neil

[John_P1]

Which modules are you using?

[B-Money]

Hi Neil,

My name is Ben and I'm one of the Applications Engineers working at National Instruments and I'll try and take on your request.

From my understanding, it seems you need to have both analog inputs share the same start trigger. I have found a link which implements this method in a master/slave fashion.

Synchronise continuous acquisition of multiple analog input devices

https://decibel.ni.com/content/docs/DOC-12182

Please let me know if this does not solve your problem.

All the best,

Ben

[Neil.Pate]

Hi guys,

Sorry for taking so long to get around to replying.

John, I am using a NI 9242 and a NI 9220.

Ben, I have tried pretty much every combination of triggers and master/slave etc. In the end I have gone with the most simple configuration of putting both channels into the same task as it is my understanding that DAQmx is able to best figure out the synchronisation?

Sorry there are no sensible markers on the x-axis in the included picture, but for reference the square wave is 50 Hz (so 20 ms period). You can see the sync error very clearly. The 9242 is always lagging the 9220.

Is there some kind of filter or something on the 9242?

[John_P1]

---

@Neil.Pate wrote:

Is there some kind of filter or something on the 9242? 

---

I actually haven't used this module (I think it's relatively new...), but it's common for delta-sigma modules to have a digital delay.  Looking at the specs, it appears the delay is (40 5/512) / (Fs) + 1.5 us, which should be roughly 4 ms at your 10 kHz sample rate.  This delay should be consistent from run to run though.

Best Regards,

[John_P1]

---

This delay should be consistent from run to run though.

---

This assumes the modules are using the same timebase (as in your most recent attached image).  The image from your first post however shows a shared start trigger between modules, but the 9242 derives its sample clock from its own internal 12.8 MHz oscillator whereas the 9220 derives its sample clock from the 80 MHz oscillator on the chassis.  So I would expect drifting if the code is configured as in the first image but not the second image.

[Neil.Pate]

John, thanks for your insight.

I did see that calculation in the spec, and you are correct the delay as I have measured is just a bit over 4 ms. It is also very consistent from run to run.

How do you get 4 ms from the equation though? (40*5/512)/10000 + 1.5us = 40.56 us?

To work around this for now I am performing a bit of a nasty software delay on the channels from the other modules. I have seen there is a DAQmx read property where I can set the Offset and Relative To, do you think these would help in my situation?

[Neil.Pate]

I have just re-tested the two scenarios, and your expectations are indeed correct. I get drifting when the two separate timebases are used, but with both channels in the same task the drift seems to not be present.

[John_P1]

---

How do you get 4 ms from the equation though? (40*5/512)/10000 + 1.5us = 40.56 us?

---

It is not 40*5/512, but rather 40+5/512 (it's written as a mixed fraction... don't see that too often in specs documents).  So the result should be 4.00248 ms.

---

To work around this for now I am performing a bit of a nasty software delay on the channels from the other modules. I have seen there is a DAQmx read property where I can set the Offset and Relative To, do you think these would help in my situation?

---

I guess the idea would be to read the data at two different read positions (one with the delay and one not)?  It could be done but I think it is more complicated than the alternative solutions.  

If you're just interested in plotting the data together you could modify the t0 on a subset of the returned waveform data (either decrease t0 on the 9220 channels or increase it on the 9242 channels).

If you want the samples to line up as you are reading back the data, I think it would be easier to create two tasks.  On the 9220 task, read and discard the first 40 samples (rounding off the 5 / 512 of a sample and the 1.5 us... if your application needs to account for this remaining delay you'll have to use a counter task to delay the sample clock going into the 9220).  The synchronization (without accounting for the fractional sample delay) should look something like this:

So the 9242 exports a "sample clock" that can be used by non-delta sigma modules (like the 9220).  This should work (the synchronization method is described here under the section Synchronizing between Sample Clock and Oversample Clock Timed Devices) but I don't have the hardware to verify.

Best Regards,

[Neil.Pate]

John, really many thanks for your insight here.

The equation for the delay is very poorly documented!

Your solution is very similar to one I had tried earlier, but then discarded because I thought it was not working properly. Pre-reading the number of delay samples though is a stroke of genius. That link for synchronisation is excellent, I googled for many hours and did not come across that one previously.

Now I only wish I had not given the hardware back to a colleague today and then I could test your solution.