Triggering off start of Audio Pulse in DAQmx question..

[ChrisK88]

Hi guys,

First off, this is more of a software question than hardware, so I didn't post this specific question in Multifunction DAQ board.. 

So, I am trying to trigger a finite acquisition off of the start of an audio pulse, however I am having problems synchronizing to the audio due to the fact that it may be started before my VI runs. As shown below, the audio is generated and pulsed for 500ms on and 500ms off, and in between those periods, a digital pulse is generated as well (shown in red). I'm having a problem staying in sync due to the fact that I'm taking finite samples for 1 second worth of data, and if the UUT get's faster than me,I may catch the audio pulse midway through instead of at the very beginning. 

I'm triggering off analog edge of a 50mV audio signal, and capturing two audio channels simultaneously and coherently capturing 3 digital channels when they receive the digital edge trigger of the analog input start trigger reference. So digital are slaves and audio is master in this configuration. The point of this is to get a hardware timed delta in times instead of using windows timestamps. 

Like I said, I'm using an Analog Edge Start Trigger to start my acquisition, which triggers the digital task Digital Edge Start Trigger to start as well. How can I ensure I start at BEGINNING of a new audio pulse if I get out of sync, I can't seem to figure out that logic.. Analog edge will just trigger when it passes the specified level, but that might be halfway through the 500ms pulse, so this is where my problem lies..

I need it to be a Start trigger because I am doing 55,000 iterations of this test within a QMH Prod/Consumer pattern and need the trigger to be retriggerable, and Start trigger is only retriggerable one.

[Kevin_Price]

Before spouting off too much, there's some details I need clarity about:

1. Why take full 1 second data bursts when audio is present for only 500 msec?

2. Do digital pulses have predictable and consistent timing relationship with audio?

3. What's your sample rate?  This may be a factor in choosing between a software algorithm and a hardware-based solution.

4. What do you mean by, "if the UUT gets faster than me..."?   Is this a concern about program execution speed?  DAQ task reconfig?

-Kevin P

[ChrisK88]

Kevin,

1) Audio bursts are 500 msec, but there are digital events that happen after audio is removed, i.e. one full "event" cycle is [audio on (t0) + digital events (t1) + audio off (t3) + digital events (t4)]

2) Digital pulses are ALWAYS generated from UUT after audio, never before. Serially it goes like this: Audio On -> Pulse 1 (~60 ms after audio on) -> Audio Off -> Pulse 2 (~ 60 ms after audio off). They are not always 60 ms between audio pulses, but nominally are.

3) Sample rate for audio is 500k Samples/second and 500k samples, digital is 5M Samples/s and 5M samples. Using larger digital due to the 1 microsecond pulse, need at least 2M samples to satisfy Nyquist. Audio isn't as important as I'm just looking for when it turns on and off.

4) The UUT may take for "one cycle" 1.5 seconds on iteration 0, 1 second on iteration 1, and .9 seconds on iteration 2.. so if I'm taking 1 second worth of data, I may capture more than one cycle per read. This is the problem at the moment, the variable UUT cycle time and my finite sample reading. Program execution speed doesn't seem to be an issue as I have parallel while loops and queues to pass data from a fast spinning Read loop to a Parsing loop and logging loop.

[Kevin_Price · Accepted solution]

The timing variability you refer to in points 2 and 4 kinda dictate against the possibility of configuring a precisely hardware-timed re-triggering configuration.  I think you'll need to abandon the idea of doing repeated back-to-back finite sampling bursts and switch over into a mode of continuous acquisition and processing.

To help with that, I'd aim to capture the digital pulse times via counter rather than DIO and be prepared to drop the sound acquisition rate significantly (if needed) since you've stated that your main concern is to distinguish between ON and OFF times.

I would configure the counter to use the digital pulse as a sample clock and use the AI Sample Clock signal as the "timebase", i.e., the signal whose edges will be counted and buffered.  This will give you 2 samples per second instead of 5M and the counter values at those sample points will correspond to the index into your AI data where the pulses occurred.  Pretty neat and clean.  Just be sure to start the counter task before the AI task.  

-Kevin P

[ChrisK88]

Kevin,

Could you please further elaborate on the counter input. Use a normal CI - Count Edges, or something different? I am assuming I would drop a prop node for edge terminal and have that be AI sample clock timebase like you stated and have my pulse, PFI0, be the sample clock for the task? Would my analog task be the same as I described above? Obviously no triggering would be needed considering it's continuous, just having a hard time understand the flow from what you said. 

[Kevin_Price]

To try to keep it clear, here's a snippet of what I had in mind.  Don't consider it complete, you may need to explicitly define some of the things I left unwired.  Two key things:

1. you'll use the AI Sample Clock signal rather than the AI Sample Clock Timebase signal (sorry for the confusion, the "edge count terminal" used to be commonly referred to as the "counter timebase source" back in the old legacy driver where I learned.)

2. You *might* need to deal with the oddly-named "duplicate count prevention" property.  It's meant for situations where you may get consecutive sample clock cycles with 0 new edges to count in between them.  For various devices and driver versions there have been 3 or 4 possible behaviors I know of, thus I always do some test experiments on my device & driver to observe what I'm getting for the True and False setting.  Here are the 4 behaviors:

A. Buffer the most recent count register value.  I think of this as a "duplicate count".  Somehow, when initially introduced as a feature, one had to set "duplicate count prevention" to True in order to *allow* duplicate counts.  I'm pretty that was corrected many years ago.

B. Do not buffer any value at all, i.e., skip sampling.

C.  Buffer a 0 value.  (This might have applied only for period or 1-counter frequency measurements though.)

D. Throw an error.  (This might have been E-series behavior, and possibly only for older driver versions).

- Kevin P