LabVIEW
Sampling rate-dependent signal delay
- last edited on by
NI_Community_Su
Dear Sir or Madam,
in our test field we have carried out a test in which pressure and strain (with strain gauges) were measured with two different measuring cards. Both signals arise simultaneously and should reach at the same time the measurement system. The following measurement configuration was used:
Measuring chassis: cRIO-9040
Analogue input card: NI 9220 (16Ch) for pressure and other variables.
DMS card: NI 9237
Temperature measurement module: NI 9213
The data acquisition is done with LabView using NI-DAQmx (see screenshot).
After recording and evaluating the measurement data, a delay of approx. 8 us of all strain gauge signals regarding to the pressure signals was determined. The sampling rate was 5 kHz.
In order to examine the problem more closely, a manual interruption of the measuring signals (DMS-C and pressure C) was done via an electrical contactor. Several measurements were carried out at different sampling rates. After a manual evaluation of the measurement data in Diadem (see Figure 1), a sampling rate-dependent signal delay could be proven. Table 1 shows the results of this dependence. As the frequency increases, the time delay decreases.
The only delay we know in our measurement chain is that of the used pressure transducer. According to the data sheet: settling time <1ms (built-in analogue preamplifier).
Could you please look at the problem from your point of view? It will help us to perform our measurement series with maximum accuracy at all sampling rates.
Table 1. Delay of the strain gauge measuring signal by the NI-9237 measuring card
|
Sampling rate |
5 Hz |
12,5 kHz |
16,67 kHz |
25 kHz |
50 kHz |
|
Signal delay |
8,6 ms |
3,7 ms |
3,1 ms |
2,55 ms |
1,45 ms |
Figure 1.: a) and b) Determination of the time delay due to signal interruption; c) Time-delayed curves of the measured variables
Figure 2. Screenshot LabView
Thank a lot in advance!
V. Slavov
cDAQ modules can typically be used in Channel Expansion, provided that you don't need the modules to run at different sample rates.
Your delay is due to having a DSA device. Delta-Sigma ADC use anti-aliasing filters to remove frequency components above the Nyquist frequency, which impart some amount of phase distortion to the filtered signal, which typically shows up as a delay or phase shift. The exact amount of delay depends on which device is being used along with the sample rate.
There is a DAQmx Property that will tell you the Filter Delay. You can this use this value to post process the data to remove the delay.
Some PXI devices can remove this filter delay, but cDAQ modules do NOT support this property. So, even if you use Channel Expansion, you will have this problem.
As @Kevin_Price mentioned, another method is to use a trigger to try and align signals. As he stated, t0 is a software trigger.
DAQmx cards are not synchronized to the computer’s system clock and do not output timestamp data. The timestamp in the waveform acquired is based on the system clock; however, it is a software time value because it is based on when the operating system retrieves the data values from the buffer of the DAQ card after the DAQmx Read VI is called and the samples are available.
For a test, I digitally triggered two PXI cards, each with its own task, and looked at the t0 timestamps. I got t0 time differences between 1-11ms. So using t0 as an absolute time is NOT recommended.
Below are some plots for a PXI system that has a DSA card and a SAR card, similar to what you have in a different form factor. A square wave burst was digitized by both cards, and a common TTL trigger started acquisition for both cards. So, the data should be completely aligned and coincident, however, if you just looked at the plots you could not tell. Here, two tasks are used as Channel Expansion is not supported with this combination of devices. Cards are synchronized by the reference clock in the PXI back-plane. (Relative time sets t0 to a value of 0, and there is no absolute timestamp.)
