Recording output voltage signal

[evanhorn]

I am performing some acoustic testing by generating band-limited white noise and recording the response on several microphones. I have a 200 ms time delay between when I begin generating the white noise and when I start recording data, then stop the excitation once I have finished recording the data (as indicated by the "DAQmx Wait Until Done" VI). I would like to record the record the excitation for the time the rest of the data is being recorded only. I currently have the output signal wired into a voltage input but was wondering if there was a way to this with a VI?

Thanks,

Eric

[Gregory]

Hi evanhorn, I cannot picture your code, can you post it please?

[BertMcMahan]

It sounds like you have Excitation signal A, which starts, then 200 ms later, Response Signal starts to be recorded, and you want to have both Excitation Signal A *and* Response Signal recorded, but you only want Excitation Signal to be recorded while Response is being recorded, so you throw away the first 200 ms. Right?

If you have the two inputs synchronized somehow (like with a trigger or something) then you can just throw away the first 200 ms of samples. If it's more of a "fuzzy" 200 ms, like sometimes it's 180 ms and sometimes 240 ms, then your way of rerouting the excitation signal to a second voltage input signal is a good way to do it.

AFAIK, you can't get the value being generated on the analog output port RIGHT NOW from any property nodes- there's some buffering that goes on and I don't think it'll work. Kevin_Price may know a way, but I've tried to do some of that in the past and synchronization has been a problem. Even if it was available on a property node, it's hard to measure the exact time between when your AO starts and when the later AI starts.

[Kevin_Price · Accepted solution]

---

@BertMcMahan wrote:

... AFAIK, you can't get the value being generated on the analog output port RIGHT NOW from any property nodes- there's some buffering that goes on and I don't think it'll work. 

---

Agreed.   Here are 3 ways I've approached this over the years:

1. Physically loop back a wire from the AO to an AI channel.  The OP already knows this one and is looking for alternatives.

2. Sync the AO and AI tasks, probably with a shared sample clock, and retain your knowledge of the data you wrote to the AO task buffer.   Then for any AI sample # you can do a lookup for the corresponding AO value.

3. Measure AO *without* any physical wiring.  Right-click on a DAQmx "physical channel" control or constant and choose "I/O Name Filtering...".  Then check the box for "Internal Channels".   Now you'll be able to choose channels like "_ao0_vs_aognd" without any physical wiring.   See snippet below.

-Kevin P

[evanhorn]

From what I gather, my current approach is correct, but I am including my code in case there is any additional insight. I know it is pretty messy...

As an explanation, I generate a uniform white noise waveform, low-pass filter and rescale it, then start it. After a 200 ms delay, I start recording. "Impedance Tube" is a task recording the 8 sound pressure inputs (dynamic pressure transducers) and three voltage inputs (excitation, static pressure, and flow rate). The recorded data is lowpass (antialias) filtered and resampled relative to the frequency of interest. In my actual code data is written to shared variables, but that has been omitted here.

Please let me know if you have any suggestions!

Thanks,

Eric

[Kevin_Price]

Brief suggestions:

1. Wire up all those error outs and error ins!  

2. The 200 msec delay is subject to Windows timing fluctuations and is not going to be incredibly repeatable.  You may need to revisit this with a method that gives repeatable hardware timing, but then again you may not since you're just generating noise.

3. Due to issues raised in #2 above, configure the AO noise generation task to do continuous sampling rather than finite.   Then you won't have an unfortunate Windows timing hiccup that causes AO to finish generating noise before AI finishes its measurements.

-Kevin P

[evanhorn]

Kevin,

Thanks for the suggestions.

Regarding 1, I generally do wire error out/ins for program flow control, but have had cases where errors are somewhat obscured if I propagate the errors forward, particularly when I am just developing/troubleshooting. What are the benefits to always wiring the error in/outs?

I will change the noise generation to continuous. The exact timing, i.e., 200 ms, and repeatability are not important as long it is sufficient time to remove any transient decays and the actual signal during the duration of the test is recorded. The 200 ms delay is a holdover from a predecessor and is really overkill, but in this case longer is better than too short, so I kept it the same. I don't know how much variability there is with Windows timing, but I would hope that 200 ms is sufficient to account for that variability and damp out the transients.

Thanks again for your help,

Eric

[Kevin_Price]

If you propagate errors in order, you should get informed of the "farthest upstream" error.  There may be some downstream errors waiting for a chance to assert themselves which show up after you resolve the farthest upstream one.   So yes, in a way it obscures issues downstream but it really is a feature, not a bug.  One key point: if ever you use "Merge Errors" to combine previously-independent error chains, precedence goes top-to-bottom.  So wire appropriately.

    (I recall an annoying long-ago problem in an HP instrument driver where an incoming error would prevent proper operation, but the driver vi would then *substitute* its own error code at its output.  This was really hard to resolve at the time but taught me to be fairly skeptical about mfgr's provided instrument drivers.)

The Windows-based 200 msec wait will wait *at least* 200 msec.  Timing variability might make it wait longer, but not shorter.  It will usually be quite close to 200, but will probably occasionally be larger by 10's or possibly even 100's of msec.  But I see how this variability isn't such a concern because your stimulus is just noise.  If 200 msec is enough to damp out your transients, you can be confident you'll have *at least* that much delay.

-Kevin P

[evanhorn]

OK, thanks for the feedback! I'll be sure to remember these tips in the future.

Eric