NI 9232 module is not synchronous on cDAQ 9178 chassis

[CHMc]

I am testing a cDAQ 9178 chassis with some NI 9229, 9234 and 9232 modules by connecting them to the same sensor (accelerometer) and tapping it. Only one IEPE current is being supplied by one 9234 module, the others are measuring voltage. The modules are being plugged into the same chassis, so should synchronise automatically.

The synchronisation works with the 9234 and 9229 modules. However, the 9232 modules are consistently about 12 samples ahead. That is, a spike appears 12 samples earlier in a time plot. This is also consistent over different sample rates, from 2 kHz to 50 kHz. So for lower sample rates the time error is larger. It is a similar offset on the two 9232 modules I have.

Any idea what is going on? Or how to fix it?

Note, I also posted this on the matlab community board, before it occurred to me to check the fault with signal express. The same thing happens on signal express and matlab data acquisition toolbox. Screen dump from signal express attached.

[Kevin_Price · Accepted solution]

You're running into an inherent property of the Delta-Sigma converters used by those devices.  They have filtering in the signal path that induces a delay which is defined in their respective spec sheets.  There's a small delay from the analog filter and a generally much larger delay from the digital filter.

It so happens that the 9229 and 9234 have almost identical input delay specs, differing only by 700 nanosec in the analog stage.  The 9232 has a similar analog delay, but its digital delay differs from the others by 10-12 samples depending on some "decimation" setting.  (I'm not personally familiar with that module.)

Note: the digital delay for the 9229 and 9234 is stated as (40 + 5/512) / fs.  The numerator represents a # of samples, dividing by the sample rate fs converts to units of seconds to match the units of the analog delay.  The digital delay for the 9232 is stated as either 30,29, or 28 / fs, making your 12 sample discrepancy make a lot of sense. 

It's up to the programmer to use knowledge of these delay specs to compensate.  Here's some more info.

- Kevin P

[CHMc]

Thanks Kevin. If I use the same settings, including sample rate, is it safe to assume that the offset will always be the same? If so I can work around it easily enough, or just ignore it.

My main concern was the possibility that the offset will drift, so that if I am logging for a long period of time the time offset increases.

[Kevin_Price]

Yes, the offset should remain constant.  All the modules will be getting their sample clocks from a common souce in the chassis, so there won't be any further skew over time.  Just the constant fixed delay difference you've already seen.

-Kevin P

[CHMc]

Thanks again Kevin.

[mcduff]

Don't know how the Matlab nor the Signal Express toolkits work, but, in LabVIEW you can combine all three modules in a single task, with the same sampling rate, and they are synchronized if they are in the same chassis.

In Matlab don't make separate tasks, make a single task that contains all three boards.

mcduff