DSM and SAR Syncronization

[an123]

Hi All,

So i was trying to configure two modules ( the NI 9218 and the NI 9205) using the CDAQ 9174 as the chassis.

This setup is one of DSM and SAR as per the example from:

http://www.ni.com/tutorial/5376/en/#toc8

in the Figure 10: Synchronizing a Delta Sigma Module and SAR/Slow Sampled Module section

I am using Slot 1 for the 9218 and slot 3 for the 9205. I am also using Channel 0 for both modules for the acquisition, and have correctly wired everything physically. My issues comes from the results that I am seeing. I am acquiring the data in continuous waveform ( 1 channel N samples waveform output). However the data appears to be phase shifted (if you look at the provided image). This seems impossible because even if one had started (i know the DSM has some adc reset delay) later or earlier than the other, they should still see the data coming in at the same time. For my test I am generating a square wave, which is being split into both modules to test synchronization. So they should still see the data at the same time. Can someone take a look at the example and image, and offer some guidance as to why this is occurring. Thank you!

[Kevin_Price · Accepted solution]

The Delta Sigma delay means that at the moment the first sample gets buffered, it represents the signal level that was happening at the terminal a little while in the past.  The exact delay has a "# samples" component (due to a digital filter) and a fixed time component (due to an analog filter) that you'll be able to find in the device manual.  The # samples component is generally dominant.   Here's another thread I was in that discusses things more.

If, for example, the delay were 40.1 samples worth and you wanted to capture 1000 *meaningful* samples from both devices, you could configure your DSM task for 1040 samples and ignore the 1st 40.  The remaining 1000 will represent the signal *as seen at the wiring terminal* at (nearly) the same time as the 1st 1000 samples from the other device.  In this example, they'd still have 0.1 sample worth of apparent phase shift.

My first encounter with this time delay phenomenon of Delta Sigma modules came in an app needing to hw-sync several high speed output devices in a PXI chassis.  There, phase shift mattered quite a bit so I had to compensate as much as possible for the fractional sample part of the delay as well.  Trust me when I tell you that as much as this may be a hassle on input signals, the consequences are even larger on output signals!

-Kevin P

[an123]

Hi Kevin , this make sense to me. But how do I find that calculation?

Is it the following one:

Input delay = (40 + [5/512])/fs + 5.3 μs which i found in the datasheet for the 9218

It didn't say the units, so Im guessing that based on what you were saying, this is the number of samples correct?

[Kevin_Price]

I totally made up the 40.1 samples # from the clear blue sky.   Weird how close that ended up being to the datasheet spec.  The datasheet as written is spec'ed in units of time.  (40 + 5/512) is a constant-samples component.  Dividing by fs (in units of samples per second) converts it to seconds for a given sample rate.  The 5.3 μs is a constant-time component.

To put it in units of samples, it'd be (40 + 5/512) + 5.3e-6 * fs.  At 1 kHz for example, that'll be (40 + 0.0098) + 0.0053 or about 40.015 samples.

-Kevin P

[an123]

---

Okay, thank you so much for your help. NI did a good job with the synchronization help , but the delay was kind of hard to find and not super clear so now my application should be good to go. Ill reply tomorrow and see if that fixes all of my woes. Also yeah weird coincidence with the 40.1.!!!