Acoustic Time of Flight Calculation with PCI-6034E

[DB-123]

I'm trying to measure the amount of time sound takes to travel through a specific medium with Labview 7 and a PCI-6034E DAQ card. So far, I have the speaker connected to ctr0 and that generates the specific frequency that I want. I want to have the program run the sound and then stop it when I hit a button and then measure the amount of time it takes for the microphone to stop receiving the sound. I don't know how to use the analog input (from the microphone) to trigger some sort of timing device. This timing needs to be as accurate as possible. Thanks for your help.

[Erin_B.]

If you acquire the signal from the microphone at a rate determined by the 6034E, won't you be able to analyze the signal to determine how long it took for the sound to diminish to a particular level? If you know the rate of the sample clock and how many points you acquired, you can calculate the time. For example, if you acquired 2000 points at 10 kHz and at around the 1000th point the signal level was at 0, you know that it took 100 ms to reach that level.

Hope this helps.

Regards,
Erin

[Tesla1977]

Why dont you use 2 microphones, one near the source of the sound and one a known distance away. You measure these inputs, and send a "peak" sound. You get a peak at the one imput and a little time later, at the second input. Now you can calculate the speed of sound using the time difference between the "peaks" and the distance of the microphones. Use two similar microphones.

[Kevin_Price]

I second themad's suggestion about using two similar mikes at a known separation. When you originally posted your question, there were two things that concerned me:

1. You planned to measure the time from when a user pressed a 'stop sound' button until the microphone stopped receiving sound. There are two problems here:
a). It's difficult to exactly characterize the instant that the sound generation stops, especially if you're doing it from software. You're probably stuck with ~1 msec resolution at best, but worse than 1 msec accuracy.
b). It's also difficult to determine the instant that your mike "stops" receiving sound. In reality, there's liable to be several possible sound paths (think "echo") of varying distances. The s
ound level isn't likely to cut off abruptly, but will attenuate over a finite time.

2. You mentioned generating the sound with ctr0. The average speaker won't want to be driven by such a digital pulsetrain. The average amp won't like it much either. Couldn't you use your soundcard to generate the sound instead? You could then make a gentler sine wave for your speaker. There ought to be some examples here on DevZone.

Good luck!

-Kevin P.

[DB-123]

That is a good suggestion for most situations. However, it won't work for mine. I'm ultimately trying to determine the time of flight of an ultrasonic signal (40 kHz) through a fluid filled container. The container is about 40mm wide and the transducers rest up against the sides. Kevin, you're probably right about the attenuation and echoing; I've been having some trouble discriminating the correct signal (ie. the one that traveled through the fluid). Also, I understand the concepts you guys presented here, but I'm a little shaky when it comes to applying them with Labview and the DAQ card. Thanks a lot for your help.

-Darren

[Kevin_Price]

I don't know what your fluid is, but I just looked up info on sonar which gives a propagation speed of nearly 1 mile/sec in water. That leaves you with <30 microseconds to traverse your 40 mm container.

Soooo...., I don't know if you can do your measurement with a 6034E. It's max sampling rate is 200 kHz or 5 microseconds/sample. I doubt that'll be enough resolution to reliably distinguish the varations in time-of-flight that you're after.

If you're stuck with the 6034E, you'll probably need to perform the measurement with one of its counters and then build a little external interface circuitry. There's several ways, here's one:

Use ctr0 to generate a single high pulse with a duration longer than your worst case time-of-flight. Use ctr0_out to switch on a transistor that allows your ultrasonic stimulus signal to get through to the speaker. ctr0_out should also be NAND'ed with a signal to be desribed in the next paragraph.
Run the mike signal into a comparator and let the comparator's output drive a latch. The idea is to produce a digital rising edge at the instant the mike first receives a significant signal, i.e., your stimulus. NAND this signal with ctr0_out and pass the result into ctr1_gate.
Configure ctr1 for event counting, set to count 'while gate is high'. (Under the newer DAQmx, the terminology is 'pause trigger.') Software select its source to be the internal 20 MHz timebase.

How it works:
Start ctr1 first, then ctr0. On the rising edge of ctr0's pulse, ctr1 will increment once every 50 nanoseconds (i.e., counting cycles of the 20 MHz internal clock). ctr1 will stop incrementing when the mike detects a sound level above the threshold you've set up in your circuit, driving the . The value of ctr1 multiplied by 50 nanoseconds is your time-of flight.
Then, software reset your counters, hardware reset the latch, change or manipulate your fluid, and try again.

There's very likely a simpler solution. Anyone?

-Kevin P.

[DB-123]

Hey Kevin. I like your idea; it seems feasible. However, my supervisor has authorized the purchase of a new NI interface card specifically for this project. What card do you recommend? I'd like to get one that has the highest sampling rate possible because accuracy is very important. Thanks for your help.

-Darren

[Kevin_Price]

Not so keen on the counter-plus-circuitry idea, eh? Fair enough -- you'd be blind to the waveforms that cause the timing signals that way.

So, supposing you'd like to capture those waveforms so you can try out various types of post-processing, I suspect you should consider the high-speed digitizer line, which support analog triggering and simultaneous sampling.
However, my best advice is to talk to your local NI rep with whom you can have a more complete discussion about sampling rate, triggering options, A/D bit depth, and cost.

Oh, and some unsolicited advice: I don't know what sort of budget you have, but think twice before getting the cheapest card that just barely satisfies today's needs. The che
ap one may be just fine, but be sure you (& your supervisor) understand the extra capabilities you are thereby choosing NOT to have for the future.

-Kevin P.

[fluecmic]

Hi DB-123,

I would like to do something quite similar to your work and I have the same problem you had. How did you solve it that time? What kind of NI-card do you use? Can you help me?

Thanks a lot,

fluecmic