NI 9225 and 9205 synchronization

[Digio]

Hello,

I have a cDAQ 9188 chassis, NI 9225 and NI9205 modules. I have to synchronize these two modules to acquire voltage signals. To test the setup and the code I'm sending the same signal to both elements. There is a delay between the acquired signal and this is due to the delta sigma converter of the NI 9225. I tried to solve the problem by pre-reading the signal conveied by the NI 9225 (http://digital.ni.com/public.nsf/allkb/F989B25FF6CA55C386256CD20056E27D ) but anyway i see the signals slowly shifting on one another. Maybe it's a buffering problem or it's due to the sample clock. I'm sending the code and a screenshot of the shift.

If you had the same or similar problem or if you have any suggestion please let me know, it will be really appreciated.

Thanks in advance

Davide

[Kevin_Price · Accepted solution]

1. For good sync, tasks need to share hardware timing signals.  In your code, you're asking each module to generate its own sample clock.  You've queried the 1st task for its actual sample rate (good), but there's no guarantee the 2nd task can actually match it from its own internal timebase.  This could explain the slow shift over time.

2. Your code also doesn't sync the start of the two tasks.  From run to run, the apparent initial phase shift probably varies, right?

I don't know the capabilities and limitations of cDAQ hardware very well, but I'd be trying to:

- use the DSA module as master.  Export its sample clock (maybe to a terminal block pin?).  Start it last.

- use the other module as slave.  Use the DSA board's sample clock signal as an external sample clock.  (This *might* require screwdriver and wire, not sure.)  Start it first.

-Kevin P

[Digio]

Thanks Kevin_Price for the answer. 

I'm using the actual sample rate of the DSA board as reference because it's limited to a discreet number of frequency allowed, whereas the 9205 has not such limitation (or at least on the data sheet it's never mentioned). Actually you're right, the initial phase varies from run to run. I would exclude "hardware manipulation" because i do not have the possibility to do so. I was thinking of using the PFI0 exit to export the sample clock of the DSA  board and send it, through the PFI1, to the 9205. This way It's seen as an external source and there should not be a conflict error. Do you think this could work? 

Thank very much

Davide

[Kevin_Price · Accepted solution]

- your 9205 sampling rates would be only *slightly* limited in that the clock rate must be an integer divisor of the internal timebase it uses.  An example to illustrate: a 1 MHz timebase would not allow for a 3.000000 kHz sample rate.  The nearest integer divisor rule would make it produce a 3.003 kHz sample rate.

   The difference from nominal is small, but it's the kind of thing that would produce the slow drift over time you mentioned.

- exporting the sample clock from the DSA and having the 9205 use it as an external sample clock should indeed work.  The divisor stuff above becomes irrelevant as the clock signal is used directly to set timing.

-Kevin P

[Digio]

thank you very much, you've been extremely helpful.

Davide

[AndreiC]

It's a shame this is not documented better. It's a common enough use case that we should have more easy to find documentation on it. 

Here's what you need to do to make it work reliably, every time:

You configure the DSA module to export its sample clock. 

After you do that, it's sample clock can be used as a sample clock for the self-timed module (9205). Configure the 9205 to use the DSA's sample clock. This will solve the drifting apart problem

Start acquisition of both modules at the same time. You can put them in the same task or just branch out an error wire to each of the start commands for each module. This will fix the inconsistent start phase problem.

The DSA has a larger group delay that the self-timed module, so to properly synchronize the modules, you need to compensate for that. Look at the DSA's data sheet for a specification called "input delay". It will be a number of samples (ODR) plus a fixed delay (for the 9225 it's 38.4 ODR plus 3us). You need to discard the first 38 samples from the acquired 9225 waveform. This will synchronize the 9225 to the 9205 to 0.4 samples (this will vary with your selected sample rate) + the difference in analog group delays (that will be a couple of microseconds). If that delay is significant for your application, you can compensate for it in your measurements. It can be converted to phase if doing phase measurements, or just subtracted out if doing delay measurements.

[Digio]

I totally agree with you on the lack of documentation. It should be implemented better. 

1) I'm trying to export the sample clock of the DSA with the DAQmx export signal  but I constantly occurr in a conflict error. It says that source and input of the signal are the same device. In particular, wich source should I chose for each element (daqmx sample clock of the DSA, daqmx export signal of the DSA and sample clock of the 9205)?

2) I'm compelled to open two different task because I have to read the surplus samples of the DSA, so (I think) they must be separated. 

3) As far as the input delay problem, on the data sheet of the 9225 there is a function of the sample rate ===> input delay= (200/512)/fs+3.6 us, where fs is the sample rate. On a dimensional point of view, isn't the input delay a time? If not, why are they adding samples to seconds? How did you get 38.4 samples and 3 us? 

Thanks a lot and please let me know

Davide

[REaymane]

Concerning your last question, this thread is very helpful.