LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

microphone frequency response function

Solved!
Go to solution

Hi all,

 

I am trying to do an impact test with 3 types of sensors to investigate surface properties of a material.

 

The first sensor is the sensor in the modal hammer.

 

The second sensor is a geophone , whilst the last sensor is an air-coupled sensor in the form of a microphone.

 

Aside from the microphone which is directly connected to the laptop by USB, the instrumented hammer and the geophone is connected to the NI 9233 which is connected to the NI USB-9162 which finally connects to the laptop.

This hardware doesn't support analog triggering therefore software triggering is used.

 

I am using a vi example from http://www.ni.com/example/28438/en/ 

 

I have successfuly setup the LabVIEW VI to read the raw data coming in from all the sensors and to obtain the frequency response of the geophone due to stimulus signal created by the impact hammer.

 

I have tried to obtain the frequency response of the microphone due to the modal hammer however no results show up in the graph for the frequency response of the microphone.

 

My question is this, what is going on and how do I fix this so that I may obtain the frequency response of the microphone?

 

I have attached my vi for your consideration.

 

 

 

 

0 Kudos
Message 1 of 7
(4,434 Views)

I do not have DAQmx or the SVFA toolkit, so these comments are more general than specific.

 

It appears that the DAQmx Read and analog triggering occur in a loop which must complete before the Acquire sound can run. Therefore, the signal from the microphone will never capture the same impact that the DAQmx Read gets. You need to have those running in parallel, not sequentially.  You should also probably do something similar to the analog triggering on the sound signal. You have no way of synchronizing the   two hardware devices, so you do not know exactly when the desired signal will appear in the sound signal.

 

Next, consider the Producer/Consumer architecture. It separates data acquisition from the analysis and file operations, so that the timing requirements do not depend on the timing of unrelated tasks. Perahps this is not critical for your hammer operations, but it is a good tool to have in your kit.

 

Lynn

0 Kudos
Message 2 of 7
(4,404 Views)

Hi Lynn,

 

Thank you for taking the time to answer the question. 

I am trying to get the signal from the microphone to capture the same impact that the DAQmx Read gets.

 

But I am not sure how to set the analog triggerring on the sound signal. 

 

I've tried to set the analog trigerring on the sound signal by placing the Acquire Sound express vi in the same while loop with the SW analog trigger vi. However the triggerring doesn't work.

MovedMic.png

 

In addition, I've also tried to merge the data from the microphone with the data from the DAQmx Read which then gets read by the SW analog trigger vi. However this too doesn't work.

 

Merging DAQmxAndMic.png

 

Would you kindly show me how to fix this vi please?

0 Kudos
Message 3 of 7
(4,388 Views)
Solution
Accepted by topic author HammerTimer

I cannot fix your VI because I do not have DAQmx or the SVFA toolkit. What I have attached is a simulation which shows some of the concepts.

 

The left side simulates acquisition of two channels (hammer and geophone) via the DAQ device and one channel of sound (microphone).  Don't worry too much about the details. I just threw this together quickly. The hammer signal is a square pulse, the geophone signal is one cycle of a sine wave with noise, and the microphone signal is one cycle of a triangle wave plus noise. Each of the pulses is dleayed from the start of the acquisition by different amounts to represent the trasmission delays of the sound and vibration.  The values chosen are arbitrary and do not simulate any physics.

 

I used the sampling rate, block size, and duration controls from your VI, so the numbers of samples and the sampling rates should be the defaults from your VI. The three graphs one the left show the three signals as generated. Note that the Microphone graph has X-axis autoscaling turned off. Also the data is all in waveforms or arrays. I avoid the use of the Dynamic Data Type produced by Express VIs because it effectively obscures the data structure.

 

The right side shows one way to do the triggering. I used Basic Trigger Level Detection.vi from the Waveform Monitoring palette and the Get Waveform Subset.vi from the Waveform palette. Note that there are separate trigger VIs for the DAQ channels and the sound channel. Because they are not started at the exact same time and they do not have the same dt (= 1/sample rate), the waveforms cannot be combined to use a single trigger. The geophone signal is synchronized with the hammer signal so one trigger from the hammer can be used to get both subsets.

 

Note that with the default delays the microphone pulse occurs 30 ms after the geophone pulse but in the subsets it occurs about 4 ms before the geophone. This is due to the independent triggering.

 

Since you do not have a common signal or trigger for both devices (DAQ and sound), you cannot know exactly what the timing relationship is between them. On every run the differences in the start times will vary. So you will need to do some kind of calibration to determine the time delays.  I am thinking of some kind of periodic stimulus which will produce several pulses to both the geophone and microphone. The first pulses will have indeterminate delays but subsequent pulses should have reproducible delays. The relative spacing and directions during the calibration runs should be the same as the hammer position for the real experiment.

 

Lynn

Message 4 of 7
(4,358 Views)

Hi Lynn,

 

Thanks for this. It looks good.

 

The data that I'm interested in happens within milliseconds of the strike so as it is just now with the microphone measurement starting after the geophone and the hammer, it is very likely that I might miss the recording of the important data.

 

Hence is it possible to set up the microphone to read the samples before the triggering begins though? 

 I would like the microphone to be able to record the pre-trigger samples in order to account for the delay in the microphone's recording. 

 

0 Kudos
Message 5 of 7
(4,302 Views)

I would run both acquisitions continuously and process the data separately. Presumably the hammer is operated manually and you apply a single impact during a given test. So you could start the continuous acquisition with a front panel button, swing the hammer, stop the acquisition  from the front panel, and then do the analysis.

 

Lynn

Message 6 of 7
(4,291 Views)

Ok thanks for your help Lynn.

0 Kudos
Message 7 of 7
(4,262 Views)