Input Delay

[adkin]

I'm trying to measure the phase difference between force and acceleration of a specimen attanched to a vibration shaker. In order to verify the setup I've simply attached a rigid block. The issue I'm seeing is that the phase of the two signals is not 0 as I think it should be in this test case. Furthermore, modifying the sampling rate changes the measured phase.

I'm measuring the signals with two different C Series modules - the force (load cell) is measured using an NI 9237 and the accelerometer with an NI 9230. I have both signals in a single task.

After reading about input delay (who knew!) I tried correcting for it. Since I have two modules with input delay, I'm shifting both back by their respective delays. This is accomplished by performing a dummy read before entering the loop and storing the previous samples in a shift register. 

The equations I'm using for delay are from the two spec sheets:

• NI 9237, Delay = (40 + 5/512)/fs + 4.5us
• NI 9230, Delay = C/fs + 3.0us, where C is based on the decimation rate, 30 for 64x, 29 for 128x, and 28 for 256x

I suspect I'm doing something wrong with the correction, but I'm officially out of things to try. Here's a list of what hasn't worked:

• Shift both signals by their delays
• Shift the NI 9230 signal by the difference in delay
• Empirically shift the NI 9230 signal to 0 phase (after changing the sample rate the phase is no longer 0)
• Shift by the number of samples instead of by time
• Separate into two tasks and try all of the same things

I'd appreciate any help!

[Bob_Schor]

What was the time course of the stimulus?  It might be interesting to use a sinusoidal stimulus waveform (with different frequencies, of course) and look at the Bode plot of Force and Acceleration as a function of frequency.  It would not surprise me if there were "velocity" effects (e.g. "drag"), not just pure "F = ma".

Are you perhaps "overthinking" the problem?

Bob Schor

[adkin]

The stimulus is a continuous sine wave from a function generator so I'm looking at a stable system. The setup with a rigid test peice is to eliminate any phase shift due to the system itself and confirm that the two signals do in fact satisfy the force equation - m = F/a for a known mass. The mass checks out fine within 1-2% error.

I've done a very similar test with a smaller IEPE force sensor that had both signals measured by the NI 9230 so I didn't have any input delay issues.

[Kevin_Price]

Are you also querying a DAQmx Timing property node to retrieve the *actual* sample rate (as shown in all the simple voltage shipping examples)?   I know the 9237 has a relatively small # of discrete *actual* sample rates that are possible and will use the next one higher than whatever unsupported rate you request.  A property node query will give you the *true* rate to be used in your delay calcs using fs.

Meanwhile, please post us more details to work with.

- we need actual code.  Maybe you haven't done the necessary things to sync their start times, which can be a separate source of apparent phase shift.

- real data would also help.  After a run where the data is brought out to a front panel indicator, probably as a graph, do "Edit->Make Current Values Default", then do "File->Save For Previous Version..." back to, say, LV 2018.   Then post it.

-Kevin P

[mcduff]

---

@Kevin_Price wrote:

Maybe you haven't done the necessary things to sync their start times, which can be a separate source of apparent phase shift.

---

Sine the OP combined both DAQs into a single task, that should be taken care of behind the scenes by Channel Expansion.

Don't use the formula, use the property node in this link to get the delay for each channel in the task.

[Kevin_Price]

---

@mcduff wrote:
Since the OP combined both DAQs into a single task, that should be taken care of behind the scenes by Channel Expansion. Don't use the formula, use the property node in this link to get the delay for each channel in the task.

This is better advice than mine on both counts.   It'll still help for you to post code with data.

-Kevin P

[adkin]

Yeah, I am using the property node for the sample rate... I've been bitten by that before too. Sorry, I thought I included a zip of the project, but it doesn't look like it showed up. I'll try again, but here's a snippet of the main code and the correction for one of the signals. There's a second FGV for the other signal with a different delay.

 

 

[adkin]

---

---

---

---

---

---

@mcduff wrote:

---

@Kevin_Price wrote:

Maybe you haven't done the necessary things to sync their start times, which can be a separate source of apparent phase shift.

---

Sine the OP combined both DAQs into a single task, that should be taken care of behind the scenes by Channel Expansion.

Don't use the formula, use the property node in this link to get the delay for each channel in the task.

---

Thanks, didn't know that existed! I'll give it a shot when I'm back in the lab.

Do you happen to know what the difference is from the calculated value? Is the property somehow timed? Or just a simpler, less error prone way of obtaining the delay?

And yes, the single task was used to both synchronize (I thought) the signals and keep the sampling rates the same to make it easy to obtain the phase shift with the Cross Spectrum vi.

[mcduff]

@adkin

I have only examined your VIs quickly due to a lack of time. Sorry. But a few suggestions:

1. Start with the no corrections VI. I made a quick mod to it, and will attach here. It will give you the input delay due to the DSA digitizer.
2. The difference between these two delays should be your phase difference. (This assumes there are no phase shifts through any signal conditioners before the digitizer.)
3. The method of reading a certain block of points is used when your have a SAR module and a DSA module, along with 2 different tasks. It add complications to your method without any benefit. (So ignore the corrected VI)
4. I like reading the delays directly because (1) the formulas are always written in a poor font and sometimes parenthesis are there or not there, not sure what to do, (2) if I read the property then I don't care what module I have plugged in, no need to look for data sheets.
5. The cross correlation does not use the timestamp in any manner, thus a shift t0 change for one of the waveforms will not give you the correct phase shift.
6. If you are saving waveforms and using the t0 timestamp, the simplest way to correct for the phase shift is to change the t0 for one of the waveforms. The delay difference is your adjustment.