Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Hardware Advice for measuring sound

0 views
Skip to first unread message

Kamilan

unread,
Aug 10, 2008, 5:10:05 PM8/10/08
to
Hello,

My masters project has taken a turn and now I am using the speed of sound.
There are two arguments that have arisen. One from my supervisor who says that LabVIEW
is used in industry and that it is a real-time environment, meaning I would be
able to measure the time taken for sound to travel x metres (minimum 0.5m and 7m
maximum).


 


On the other hand the Labview guru on
campus has suggested that using a USB interface, and the fact that Windows XP
is not a real time environment would not return true times and there are other priorities
that Windows has to handle firs giving erroneous times.

Which argument is true, and which solution should I take.

Firstly, should I using a microcontroller with dedicated timers to time the
sound by starting a counter at 1.2MHz and take start value and finish value and
then working backwards to get the time, with the obvious hard part of setting
up communications with Labview through serial.

Or should I purchase some sort of serial/USB interface for Labview that would
be able to handle the job. If this option is best suited, are there any recommendations
for hardware? I'm using the SCB-68 which can only be used on a desktop
computer. I need something that is either Serial or USB as the final product
will be controller via laptop.

Cheers

G Lo

unread,
Aug 11, 2008, 2:10:12 PM8/11/08
to
Kamilan,
There is truth in both statements but it depends on the testing being done.  NI has a LabVIEW Realtime Module which can be used to respond to events in a deterministic fashion.  Software processing on a Windows XP machine will not be deterministic but will be on a real time operating system such as Pharlap.  On the other hand, acquiring data will be deterministic because it will utilize the DAQ Hardware and its clock.  The important note to make is that the software processing will not give you deterministic behavior if you are not using a real-time operating system.
In terms of the acquisition, I believe that you may just want to start your microphones simultaneously and then post process the data to find the change in time.&nbsp; The other option would be to start your data acquisition devices simultaneously and then post process the data.&nbsp; It sounds as if this will run only once and then the data is viewed.&nbsp; The counter method would also be feasible and would only require one additional software processing step: # of counts/timebase used.&nbsp; If you need a USB DAQ device then I might recommend the 621x series or a card such as the <a href="http://sine.ni.com/nips/cds/view/p/lang/en/nid/203092" target="_blank">USB-6218</a>.&nbsp; The final design will depend on&nbsp;the&nbsp;equipment available to you and if devices can be started simultaneously.

Kamilan

unread,
Aug 11, 2008, 5:10:08 PM8/11/08
to
Hello,
I will take all that you said into consideration. I was talking to my Dad about the problem and an idea popped into my head. Its a combination of both solutions. I figured that I could build an external&nbsp;square wave oscillator. Instead of using a software timer, have Labview&nbsp;read rising edges. When I tell the robot to make the beep, Labview will start counting rising edges, and then when the "received" signal is received, stop counting.
This way, if we know the frequency, the time can be calculated. The higher the oscillator frequency,&nbsp;the higher the resolution. What do you think? Will this USB interface be able to handle high clock speeds?
Cheers
K
&nbsp;

G Lo

unread,
Aug 12, 2008, 12:10:13 PM8/12/08
to
Kamilan,
Looks like a good starting place.&nbsp; The maximum detectable frequency of a counter is going to be the timebase utilized / 4.&nbsp; You are correct to assume that a higher frequency means better resolution, though.&nbsp; You could also configure a pulse width measurement with the counter on your daq device.&nbsp; <a href="http://zone.ni.com/devzone/cda/tut/p/id/2875" target="_blank">This</a> developer zone provides a little more insight into this application.&nbsp; Basically, you could provide a signal to your gate which will tell how long the signal is traveling.&nbsp; (while traveling the signal is high)&nbsp; The source will be your internal timebase and you can take your count and find the time.&nbsp; Hope this suggestion helps!

Kamilan

unread,
Aug 12, 2008, 7:40:19 PM8/12/08
to
Hello,

&nbsp;

I'm just testing if I can use an external oscillator to timer. I'm using a NI-PCI 6229 and a SCB-68 interface box. I'm having trouble with the connections. Any advice for using the DAQx?

&nbsp;

The is not wiring diagram, so I?m not sure where to put the signal in.

&nbsp;

Cheers

&nbsp;

K&nbsp;

G Lo

unread,
Aug 13, 2008, 12:40:09 PM8/13/08
to
Kamilan,&nbsp;The pinouts of the PCI-6229 can be found on page 22 of the PCI-622x <a href="http://www.ni.com/pdf/manuals/371290g.pdf" target="_blank">manual</a>.&nbsp; The wiring will depend on the exact application that you wish to achieve.&nbsp; For example, if you would like to count the number of pulses from the external oscillator then you would need to place your oscillating signal in the source of a counter.&nbsp; I have also included an image which shows what the pinouts of the 6229 correspond to.&nbsp; Hope this helps.


6229 pinout.JPG:
http://forums.ni.com/ni/attachments/ni/40/6661/1/6229 pinout.JPG

0 new messages