Synchronizing data acquisition with NI 9220 and 9234

[LReck]

Hello everyone!

I am currently trying to acquire acceleration data from a sweep using both the NI 9234 for an IEPE-sensor and the NI 9220 for an analog MEMS in a cRIO 9036. The data should simply be called on the FPGA side using the same FPGA I/O Node, put into an array and fed into a FIFO.

Inititally the whole procedure seemed to be working fine but when take a more detailed look at the data i see a time drift between the two modules. They start at the same point but then show an increasing large difference before returning to no difference again. So when i multiply the time values of the NI 9220 with 10001/10000 i get a nice fit again. Unfortunately, I would like to solve this problem on the programming side instead of the data manipulation side.

I've read these two articles:

http://zone.ni.com/reference/en-XX/help/373197L-01/criodevicehelp/synchronizing_multiple_modules/

http://zone.ni.com/reference/en-XX/help/373197L-01/criodevicehelp/923x_understanding_loop_timing/

I understand that the NI 9220 has a (SAR) ADC and the 9234 has a delta-sigma ADC. I have specified the 9234 as the master timebase but the 9220 still uses the 40MHz onboard clock of the cRIO, correct?

In the second article i posted above it is stated that:

• If the rate at which you can acquire data from the other module is as fast or faster than the data rate configured for the module with an internal master timebase, you can read from both modules in the same loop.
• If you use the same FPGA I/O Node to read data from all modules, the FPGA I/O Node does not return data for the other module until the module with an internal master timebase acquires data

For the NI 9234 i have specified a data rate of 2048kS/s which is also the rate i see in my measurement files. The datasheet of the 9220 shows a sample rate of 100kS/s/channel which is much higher (i only use 3 channels at the moment but plan to use all 16).

In the first article it is stated that i should create a seperate loop for each module with different data rates. So i should create a loop for the NI9220 and include a Loop Timer for 1/2048 s? Is that the only way? I understood it originally in the way that putting it on the same FPGA I/O Node would only be a problem if the NI 9220 had a slower data rate than the NI 9234.

Thanks already for any answer!

Lukas

[LReck]

To further specify the questions:

Where does the time drift come from? Is it really due to the different master clock rates?

How could i solve this problem?

[LReck]

Okay after some more searching i found an additional articles that pretty much seems to cover my problem:

Synchronizing DSA with SAR C Series Modules in FPGA

Here it is mentioned that my problem is most likely cause by the DSA delay (ground delay) of my 9234. The input delay of it is given by (40 + 5/512)/fs + 2.6 μs.

This results in a delay of ~0.0195s which corresponds to ~40.015samples.

Now i added a Discrete Delay to my FPGA. This only leaves me with two questions:

1. How could i compensate for the non-integer delay of the NI 9234?

2. In the example of the article above, the data is called from two separate FPGA I/O Nodes but from what i read it would be better if i read from only one Node instead. Which is better?

[LReck]

Moving on, the ground delay obviously only compensates for the initial difference in the signal. In the pictures you can clearly see the drift when comparing measurements after 300k samples and after 1.1m samples. Both are taken from the same measurement lasting 900s.

In this article by Salvador Santolucito of National Instruments, he talks about the Clock Drift Error when Synchronizing SAR and Sigma-Delta ADCs.

He states that:

"One method of overcoming the drift is to trigger the SAR conversion on the data ready signal of the sigma-delta ADC. This will synchronize the two measurements and prevent them from drifting apart over time. Depending on how this is done, jitter may be introduced into the SAR conversions. If the system (running off of the system clock) samples the data ready signal and drives the convert pulse, there will be jitter on the convert pulse on the order of one system clock period. This is because the data ready signal is coming from the oversample clock domain.

A better way to synchronize the sigma-delta and SAR ADC is to use the same clock for both ADCs. This way, the timing engine that drives the SAR conversion will be synchronous to the oversample clock going to the sigma-delta ADC. However, this solution has several downsides. The clock speed needed for the sigma-delta is often much slower than what is needed for the communication and timing engine for the SAR ADC. To get around this problem, you may be able to use an FPGA to phase align the two clocks, but this is a complex and difficult design that is only needed if you require precise synchronization."

It would be greatly appreciated if you could point me towards a solution on how to implement this for my program. I need precise synchronization because we plan on doing modal analysis for which the input (acquired via NI9234) and the output (via NI9220) of system need to be closely correlated.

[LReck]

I've looked into this further and found that the group delay (obviously) only affects the initial shift between the measurement values. In the pictures below taken from the same 900s measurement you can clearly see an additional drift between the NI9234 and the NI9220 data.

In the cRIO Guide (http://www.ni.com/pdf/products/us/fullcriodevguide.pdf) in the chapter Synchronizing Delta-Sigma and Scanned (SAR) Modules it is stated that i should not have a shared FPGA I/O Node, which answers one of my questions. 

Also it is stated, that 

The best way to synchronize delta-sigma with
SAR modules is to design your application for delta-sigma timing (...) and then add your I/O blocks for the SAR modules as a separate I/O node as shown in Figure 6.13. This requires synching your SAR modules to a delta-sigma module clock. 

Now i would like to know how exactly i can synch my SAR modules to my delta-sigma module clock.

[mcduff]

Don't have LabVIEW here, so trying to remember what I did, will post later after some meetings. This is how I remember I synchronized a SAR and DSA card in FPGA.

Look for the "Binary Counter" function that can be reconfigured with a built in reset.

Using that function in a SCTL you can count pulses of the master clock for the Delta-Sigma module. Use this counter to generate an occurrence every Nth cycle to start data acquisition on the SAR module in another loop. You will still need to compensate for delay, but since the modules are using the same clock, they should drift together. So your SAR sampling rate will be some integer multiple of the master clock, which may or may not correspond to the sampling rate of your DSA module.

I will try to post some images later today when I am in the office.

mcduff

[mcduff · Accepted solution]

Here are some pictures that will hopefully help you.

In the the figure below, I have a SCTL that is counting pulses from one of my DSA Sample clock. The sample clock for the DSA runs at 12.8MHz. I am counting 16 cycles of this clock, such that I am generating an occurrence at 800kHz. (12.8MHz/16 = 800kHz) (Note I wanted my modules to run at different rates, but be synchronized.)

I have another loop that has all of my DSA modules, see below. These modules are synced to the "Current" sample clock. They are running at a much lower rate than 800kHz.

Next I have two loops for my SAR acquisition. Since I am acquiring data at a high rate, I am using the Sample Pulse method. For lower rates this is probably not needed. Note that the pulse that starts sampling for the SAR module are tied to the occurrence. You will need to do something similar for your application. Have a separate loop where the sampling waits until the occurrence.

Note the delay is still needed, as there is a delay for each channel acquisition.

Hope this helps.

mcduff

[LReck]

Thank you so much mcduff!

I will try implementing that tomorrow but this looks very promising.

(In fact, i was thinking about writing a private message to you due to your comment on another forum post where you mentioned a downsampling of your SAR acquisition.)

[LReck]

Now i still have another question:

since i want to acquire 32 signals from my SAR, is such a sequence of FIFOs as in your last picture still viable? My 9220 has a data rate of up to 100kS/s/ch, so much lower than yours. Will putting the SAR data into an array and delaying that by 40 samples work as well? I would like to avoid putting 32 FIFO writes into a loop. I am also not quite firm with how overhead would then affect my system. And i also have to take a better look at the DSCounter and the available options it gives me.

[mcduff]

At a lower rate, a loop should be acceptable. In the pictures I showed, the data for the DSA modules was all in a loop.

The delay for the SAR will depending on the sampling rate of your DSA modules. If the delay occurs for the array that should also work, instead of each individual module.

Post some pictures of what you are doing.

mcduff