Synchronizing data acquisition with NI 9220 and 9234

[LReck]

I created a tick counter (counting off the 40MHz cRIO clock i believe) in the SCTL responsible for synchronization and passed that value as a local variable to both the deltasigma and the SAR loops. 

They start on the same tick count (e.g. 19846868), but then the SAR acquires a data point around every 3125th tick (which agrees with the threshold of 1024 samples of the 13.1072MHz clock). Later this changes to 3136 & 3072 alternating between samples.

This is the same for the Deltasigma so i don't really care about this minor shift as long as they acquire data at the same time. Now, between the first sample of the DSA, which occurs at the same time as the first SAR sample, and the second one are 417492 ticks. This corresponds to roughly 133 samples at my sampling rate. Again, this isn't much of a problem to compensate for.

The thing is just that now the data is not taken on the same tick, instead the second sample of the DSA is delayed. (1254 ticks after one SAR point, 1870 before the next)

This delay is more of less constant throughout the measurements. Any idea on how to compensate for this?

[mcduff]

Sorry for the late reply, I've been out of town.

1. Get rid of the error wires going through the case structures. Because of them you are losing parallel processing. Disconnect/unwire/delete the error cluster going from your case structure to Analog Input Mods. Do this for both loops that you have shown in you figure.

No ERROR wire between structuresNo ERROR wire between structures

1. In your bottom loop You need to connect the occurrence with taking the data. Right now they are not connected, you are waiting for an occurrence, but it is not connected to your data acquisition. See below.

Wait for occurrence to grab dataTimeout - then error

See if this makes yours delays better behaved.

mcduff

[LReck]

So i removed the error wires from the main loop almost entirely and connected the Wait on Occurrence in my SAR loop to a case structure.

Now when i record data (both should sample at 12800Hz), i get for the DSA over 100 times as many data points as for the SAR. So my SAR now samples at about 100Hz instead. The tick counter (U32 type, converted to SGL before being fed into the FIFOs) in my counter/occurrence loop now passes weird values to its Local Variables as well. The first value looks fine for both modules. But then the SAR reads values like 

20046932

0.000225067138671875
0.00735664367675781
0.000132560729980469
0.000298500061035156

before giving 20046932 again once. It looks like a very nice sawtooth signal, with a high value every 5th count (constant) and otherwise close to zero, except i would like to just have an up-counting.

The DSA starts at 19853112, goes to 20046932 and outputs that same value 371 times. It does not show a clear pattern like the SAR but later mostly shows near-zero values as well.

Apparently neither of the loops stop as they keep gaining more and more data points.

I must accidentally have changed something else apart from the error wires because at least the counting was working fine before.

[mcduff]

Can you post some screen shots when you get a chance?

mcduff

[LReck]

Thank you by the way for using so much of your time for helping me.

SAR acquisition in Main loopOccurrence generator in Main loopDSA acquisition in Main loop

Apparently the Stop condition in the SAR loop gets triggered when i run the program. This happens regardless of whether i specify a timeout of 0ms or 100000ms. (The TRUE case in the SAR loop outputs a TRUE for stopping the loop).

It records 190 values for the DSA (the first 51 show a very nice "current tick count", then  just negative values) and 55 values for the SAR (every 5th tick count value looking good). At first i thought it was of the FIFO but why would that be affected by removing the error wires?

[LReck]

Okay it was really due to the FIFO, so that is solved....but now i'm back to seeing the same delay as before. 133 samples of SAR more than of DSA and a shift of 1264 when the DSA starts recording again.

[mcduff]

Still not sure what is going on, but you want your data acquisition to be tied to the occurrence in the SAR loop, right now, you have it so your FIFO is tied to the occurrence. That case structure should be around the Analog Input not the FIFO. See what happens when you change that.

mcduff

[LReck]

corrected SAR loop

Taking a proper look at your picture would have saved me some time ...

Anyways, i still see that fixed delay:

Current tick count start            Current tick count catch-up point

The left column in both tables shows the "Current tick count" for the DSA (344468 total samples), the right column shows "Current tick count" for the SAR (344601 total samples).

If i plot the development of the difference in tick counts between a sample from the DSA and the SAR i get the following picture:

difference in "Current tick counts" over time

[mcduff]

Attached is a 2015 version of what I used; I have no idea if it will open correctly, but it may help more than pictures.

You should have a delay through your delta sigma module of about 3ms for 12.8kSa/s, not sure if that is what you are seeing. What about when you input a signal, is the delay constant?

mcduff

[LReck]

Firstly, thank you for the vi you send, it helped me out.

I recorded the signal from a function generator i simply output to both the DSA as well as the SAR. I started data acquisition and afterwards turned on a 500Hz, +-1V Sine wave. The measurements from both channels (without any delay-compensation) is shown below:

Uncompensated signal zoomed in to first acquisition of the sine wave

On the x-axis are simply the amount of samples. Therefore the SAR acquired a bunch of data before the DSA acquired data. That is as expected. The delay is between 93 and 94 samples. This equals ~7ms. Expected were 40 samples, or 3ms, as you stated. If i now compensate for the 94 sample delay (by either delaying the SAR by 94 iterations or simply deleting the first 94 unnecessary samples) i get the following picture:

Aligned signals

This looks like a very nice fit! When checking over the duration of the measurement i don't see a drift either. Yes, the measurement point do not exactly coincide but for our purposes i believe this will be fine. So, hurray!

Unfortunately, when i now add the whole 32 SAR inputs and the analog output loop i previously used to my VI, my compilation (Local Compile) fails after about 1 hour due to running out of memory....but that is a different problem.

Thank you so much for your help over the last few weeks! I might send an update here once i acquired actual sensor-data with all 32 channels. 🙂