LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

sample rate issues

I am a new user of labview so please bear with me.

 

I have two 9228 cards and one 9218 card attached to a 9174.  I am collecting data from a load cell (9218) and a number of geophones (9228) for simultaneous acquisition. The test is an impact on the load cell and monitoring a vibration response from the geophones.

 

My issue is that I am getting a response from the geophones marginally before the response from the load cell.  This is not physically the case, and I wonder if it is to do with sample rates.

I am aware that the 9218 has a minimum sample rate of 1652(ish), and I am limited to sampling at at least this rate and can only use the onboard clock.  The datasheet for the geophones say they have 2ms sampling (i.e. 500 Hz) and ideally I would sample at this rate.  Although I assume that it doesn't matter if I sample at the faster 1652 rate in terms of the resulting waveform, I have signal processing to do on it anyway. My concern is the vibration response of the geophones appearing marginally before the impact. Is there something I am missing?

 

Thanks in advance.

0 Kudos
Message 1 of 5
(2,356 Views)

The main issue you're running into is an input delay that's an inherent part of the Delta-Sigma converter design.  The two devices don't have the same input delay, thus the data looks out of sync.  You can find or calculate the input delay values from the boards' spec sheets.

 

A way to think about input delay is this:  at the moment a value is converted and delivered to the acquisition buffer, that value represents the signal that was at the physical input terminal a little while ago.  The exact amount of that "little while" is defined by the input delay.

 

You'll need to account for this when you do your post-processing on the data, to make sure you've aligned the parts of the data stream that correlated in time originally.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 2 of 5
(2,341 Views)

Kevin,

 

Thanks for your response. I am certain that you are correct.

Can I trouble you for a little more information?

 

The datasheet for the 9218 card gives an input delay of (40 + [5/512])/fs + 5.3 μs. Can you explain the "fs" in the equation please?

 

Thanks in advance.

0 Kudos
Message 3 of 5
(2,307 Views)

If you have defined your samplerates, you just apply the same signal (a sine?) to all channels. Capture some 100 periodes, use a frequency about (or equal)  a quarter of the samplerate.  Apply a tone detection (vi) on each channel, calculate the phase differences , with sine frequency and phase difference (delay) you can calculate the channel delay. For a synchronous display you can simply adjust the t0 value of the wfrm. 

 

Oh .. both cards should always be synchronised and share the same trigger! 

I don't know your DAQ system, maybe it's always done automaticly.

Test if you get the same delays after each restart..  

 

fs usually means sample frequency

Greetings from Germany
Henrik

LV since v3.1

“ground” is a convenient fantasy

'˙˙˙˙uıɐƃɐ lɐıp puɐ °06 ǝuoɥd ɹnoʎ uɹnʇ ǝsɐǝld 'ʎɹɐuıƃɐɯı sı pǝlɐıp ǝʌɐɥ noʎ ɹǝqɯnu ǝɥʇ'


0 Kudos
Message 4 of 5
(2,302 Views)

Just to expand a little bit on the formula for input delay.

 

The delay consists of the sum of 2 parts.  One part is a fixed # of samples (pretty much the digital filter), the other is a fixed amount of time (pretty much the analog filter and circuitry).  The reason for the sampling frequency fs in the spec sheet is simply to put both parts of the sum into time units.

 

Essentially, you can think of the delay is (40+5/512) samples plus (5.3) μs.  The spec sheet converts (samples/fs) to give units of seconds, useful if looking at the signal on an oscilloscope.  You could also express it in units of samples as  (40 + 5/512) + (5.3e-6)*fs.   This may be a more useful form for software post-processing.  Other times it might be most useful to turn either of those into a phase angle as described earlier by Henrik

 

The key is to grasp that total delay has a fixed # samples portion and fixed time duration portion.  After that, it's clearer how to convert to the units of choice.

 

 

- Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 5 of 5
(2,293 Views)