Impact Testing-Time Delay Between Channels?

[mcduff]

My use of channel expansion has been somewhat limited:  same devices or a small mix of different devices that have the SAME input task, for example they all measure voltage, not mixed like the current application.

The caveats of channel expansion say it cannot account for DSA delays from multiple DIFFERENT DSA devices which is not the case here. If possible and I am allowed to go to work onsite, later this week I'll try to test a DSA and SAR module with a square wave input to ensure the delay is accounted for. However, even with a square wave the waveforms will look different for each device; the DSA low-pass filters the signal so you have Gibb's overshoot, the SAR device does not, so you have a sharp edge as higher frequencies contribute to the signal.

mcduff

[mcduff]

As usual @Kevin_Price is correct.

I need to write reports, so I cannot test his possible solution, hopefully this Friday I will be able to, but a quick test in a cDAQ-9174 chassis.

A 9234(DSA) and 9233(SAR) synced together

They are synced together, there is no rolling BUT a constant phase shift between the two.

Two DIFFERENT 9234(DSA) and 9234(DSA) synced together, same model but Slot 1 and Slot 3

Synced together. I made one plot only have points otherwise they line up on top of each other

A 9234(DSA) and 9231(DSA) synced together

They are synced together, there is no rolling BUT a constant phase shift between the two.

mcduff

PS I am hoping Kevin's solution works.

[mcduff]

Will be studying this link later

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P8toSAC&l=en-US

Main Point

his phase shift or delay is typically the result of the group delay of the anti-aliasing filters common on the front-end of Dynamic Signal Analyzer devices.

You can compensate for this group delay in several ways:

Option 1: Channel Expansion
If the two devices can be used in a single task using Channel Expansion and the devices supports Filter Delay Removal, driver will compensate for the delay automatically. The caveat is that the modules will need to sample data at the same rate.

Using Channel Expansion with devices that don't support Filter Delay Removal like C Series devices, PXI-4461/4462 or PXI-447x modules will synchronize the devices, but will not remove the filter delay.

[Kevin_Price]

Because the spec sheet seemed to calculate the filter delay using a constant (# samples?) divided by the sample rate, I had always just figured that was the digital filter stage.  I guess I don't know much at all about how the analog stage of filtering works on those DSA devices.  My earlier speculation that the analog delay would approximate 1/sample_rate is seemingly wrong (assuming the linked article is right, which I'm inclined to do, but also know that mistakes have slipped through before.)

Another way to try to sync the 2 devices is to have separate tasks, export the sample clock from the DSA device (the 9237), use it as the sample clock for the SAR device, and then start the SAR task before starting the DSA task. 

   What I do *not* know offhand though is exactly when the first DSA clock asserts.  Hopefully, it's at the end of the filter delay, immediately as the first sample is finalized.  But I don't know and am not around any hw that would allow me to test.

-Kevin P 

[Dave_Jr]

Thanks for the help everyone!

Kevin and Mcduff,

We ran a couple more tests at various Impact velocities at the 50Ks/s rate. And the data lines up perfectly every time as long as I removed .8 ms worth of force data from the beginning of the set.

If I have to, I might try to integrate that delay equation in, so it will work with other sample rates. A majority of the useful data we get takes place in about .1 seconds so I don't need the data to be lined up in a live view, and a post processing method might be easier.

If I can use that equation and feed the sample rate into it, and get a delay value I should be able to look at the time column and count the data points until it reaches the calculated delay time. Once I have this I should be able to cut the beginning of the force data by however many data points and rebuild the data set.

I did try using the AI.filterDelay removal, but after further investigation this is not supported on C-Series devices apparently.

[Kevin_Price · Accepted solution]

Tidbit: the delay equation is configured to tell you the delay in *seconds*.  You can multiply the whole thing by the sample rate to put in units of *samples* directly.  Then it's:

(40 + 5/512) + (4.5e-6)*sample_rate = # samples worth of delay

On the other hand, adjusting by an integer # samples will get you close, but won't be exact.  When graphing both signals vs. time, you could adjust the t0 field of one waveform to compensate exactly on the graph.  But I'm not sure if this adjustment would also improve your XY graph.

If you need your logged numeric data to "line up" closer than the remaining fraction of a sample, you could interpolate your position data to line it up with the force data sample times.  (It's better to do the interpolation on the well-behaved position data.)   I'd recommend logging both the original raw position data *and* the resulting aligned interpolated data.

-Kevin P

[mcduff]

Glad you found the cause and solution. Too bad about the C-Modules.

One other possible solution, not sure if you explored it,

Option 4: Using Analog Triggering with DSA Devices
If you are using analog triggering to start the DSA device task, the filter delay will not be observed, since the analog trigger circuit comes after the anti-aliasing filter; this prevents aliased components of the analog signal from firing the trigger.

Can you trigger on your force module? Not sure if it supports it or is feasible for your system.

mcduff