Multirate Synchronization of Two DSA Modules (cDAQ NI 9234)

[CyrilBN]

Hi All,

Following the tutorial Signal-based Synchronization of Analog Input C Series Modules with NI-DAQmx in LabVIEW  and using the code snippets, I cannot seem to obtain synchronization at different rates between two 9234 on the same cDAQ 9188 Chassis (code attached). As the sampling rate difference increases between the two tasks, the offset between the two digitized signals is also increasing: (see below)

Signal acquired: 4Hz Sine wave

Master Task 51200 S/s 12800 Samples per channel, Slave Task 12800 S/s 3400 Samples per channel

Master Task 51200 S/s 12800 Samples per channel, Slave Task 2048 S/s 512 Samples per channel

What is the reason for this difference and is there something I am missing in order to correct this? The code used to acquire the Waveforms is attached (it is a slight adaptation of the snippets provided on the tutorial referenced above.)

Note being a french national, I also read the tutorial referenced in my own language and notice some differences on the origin of the start trigger for the french translation. Also tried that but doesn't seem to solve the issue I am seeing. also would like to know which one is correct (Compare Figure 8 of the two tutorials :Synchronisation des modules d'entrée analogique de la série C avec NI-DAQmx)

https://ni.scene7.com/is/image/ni/5376%20Fig-08_zhs?scl=1

https://ni.scene7.com/is/image/ni/Figure-8-sync-pulse-reset-time-query?scl=1

Any help would be appreciated,

LabVIEW 2019.0.1f3 x32

NI-DAQmx Device Driver 20.1

Regards,

Cyril Bouton

[Kevin_Price · Accepted solution]

I've done a lot with DAQ sync overall, but not much of it with multirate tasks where 1 or more ran on a DSA device.

I know some of the sync examples get into shared Ref Clocks and Sync Pulses.  I've almost never dabbled with either one, so I can't say much more about that part of things.  Just that the whole structure seems overly elaborate when you have 2 of the *same* model DSA devices.  I think you could get by with just sharing your master timebase from one device to the other, then start both tasks off a common trigger signal.

Having said that, I think that *much* (if not all) of the difference you see in your two posted trials can be explained by the filter delay inherent in DSA devices.  The spec sheet gives it as ~(40 / fs) where fs is the sample rate.  The difference between 40/2048 and 40/12800 is around 16-17 msec worth of additional delay.

That's pretty close to the amount of time shift seen from the first trial where there's a small non-zero phase difference to the second where there appears to be about 20 msec of phase shift.

Only a guess now, but I'd suspect that the imperfect sync in the first trial (with the same sample rate) may simply reveal that the method isn't quite perfect.  Specifically, triggering a second task off the sample clock of the first seems like it would *necessarily* delay the second task according to 40/fs, which is about 3 msec.   As I understand it, the sample clock isn't asserted by the first task until after this delay period.  Then the second task is triggered and goes through its own 3 msec delay.

-Kevin P

[santo_13]

I will second Kevin on the Filter delay being a reasonable justification on the DSA synchronization.

I have dealt with a lot of DSA synchronization on the PXI side and I would assume the same for cDAQ. In order to synchronize both cards, you would need to tell the faster card to delay the capture by the filter delay of the slower card.

This snippet tells you exactly what must be done to slow down the faster card to match up acquisition with the slower card. (i got this from your original link - https://www.ni.com/en-us/support/documentation/supplemental/21/signal-based-synchronization-of-analo...)

[CyrilBN]

HI Kevin,

Thank you for your answer and explanation. I think your explanation makes sense with the filter delay of the card (I actually found this KB after reading your post  Synchronized Data Delayed When Using DSA Devices).

Just for clarity, I posted this example to make it simple to understand the issue. The application I am working on will almost never synchronize two of the "same" model DSA...

Thanks again for your time ad answer,

Cyril B.

[Kevin_Price]

Hmmm.  Well, my recommendation for simplifying the configuration was partly *based* on the special case of using identical DSA devices.  When using different devices, I'm not sure the timebases will always be share-able.  As I recall, there's a fairly narrow range of allowed frequencies when using an externally-defined timebase, and there may be device combos that don't allow for this kind of sharing.

I can't speak from experience about syncing the 1st sample from 2 different DSA devices that operate at different sample rates.  I'd listen to Santhosh if he has any further specific advice.

I *do* still think there's a delay problem inherent in that example that triggers one task from the sample clock of the other.  But the delays for various devices are spec'ed and it's at least possible to compensate after the fact.  Some devices support this directly with DAQmx Channel property nodes (AI->General->Filter).  For others, you could calculate the delay to compensate the t0 value from every waveform read.  A bit of a hassle, but not actually difficult.

-Kevin P

[CyrilBN]

Hi Kevin,

Thanks again for bouncing back on this. In the current scope of this application this actually won't be an issue as the Timebase will be share-able between tasks; On a high level it consists in:

- A "high speed" Analog Input Task containing mainly DSA Devices NI 9232,9234,9236....(Multidevice Task)

- A "low speed" AI task containing mostly Slow sampled module such as NI 9219,NI 9213..(Multidevice Task)

The "low speed task" may contain DSA device (thus my question) but both type of devices (DSA and Slow-sampled) allow to share a common master timebase derived from the Master or "high speed" Task. The c-series DSA module don't allow for compensation beforehand using the AI.RemoveFilterDelay property. If the "low speed" Task contains a mix of DSA and Slow sampled module, I will use the Method described in the tutorial (sync pulse) and posted by Santosh, calculate the input delay based on the type of cDAQ DSA used and store it as a channel attribute in the waveform array. That way, I can implement the t0 compensation that you mentioned on the viewing side or in post processing (logged data).

If the Slow sampled modules are slightly off sync using this method, it doesn't really matter as long as the DSA boards are synchronized.

Thanks, again

Cyril