Analyze myRIO Audio Input to Identify Material

[dkong1321]

Hello all,

I'm a college student working on an engineering project that implements labview. My team's project is meant to sort plastic, aluminum and glass bottles. It differentiates between bottles by acquiring sound data. Basically, we drop the bottles through a chute, and record the sound at the bottom with a microphone.

Generally speaking, our approach is:

1. Constantly record audio from a microphone, which will periodically pick up sound spikes from the bottles hitting a surface
2. Use this input to pull out a frequency, and identify the material
3. Activate actuators to sort the bottles according to material designation

As of now, we are having trouble with step 2. We attempted to make a VI to analyze our sound data with the attached "sound-spectrum.vi". However, we need to implement our system with the myRIO-1900. So, we created a myRIO VI ("soundVI.vi") that is also attached.

We are having trouble getting useful or consistent data, so we are hoping to get any feedback on our code, or alternative methods to analyze our sound data.

Thanks!

Darren

[Bob_Schor]

I'm uncertain whether your difficulty lies with LabVIEW, with myRIO, or with acquiring and processing Sound Data.  So I'll discuss each of these ...

• Seeing Express VIs always worries me, as it suggests that you are taking the "canned" (or Over-simplified, Limited Option) route to Data Acquisition and Control.  Have you ever learned about DAQmx?  Have you used MAX to "test out" your Data Acquisition System?  Have you built a Task in MAX and run that task from within MAX?  And if the answer to all the preceding questions is "Yes", then have you ever tried stringing DAQmx Start Task, DAQmx Read, and DAQmx Stop Task (or Clear Task) together with your MAX Task as the Task Input and seen how easy DAQmx makes taking data?
• Definitely even worse than Express VIs is the Evil Dynamic Data Wire, which hides and obfuscates the nature of the acquired data.  Use Waveforms or Arrays.
• Do you know about LabVIEW Project?  If you are going to do anything with myRIO, you need to use LabVIEW Project.  In particular, if you want us to look at a myRIO Project, you need to attach (... ready for this? ...) the myRIO Project!  The easiest way to do this is to (in Windows) Compress the File that holds the Project and its associated VIs and Controls, and attach the resulting .ZIP file.
• I tried out your Sound-Spectrum VI, which takes a second of data.  When I ran it, it was taking data from my Web Cam, so I clapped three times after hitting "Start", and see three Sound Bursts on the first Graph, and a pretty meaningless Power Spectrum on the second graph (so the code at least does something ...).
• Think about what you want to do.  Pretend that I'm not an engineer (I'm definitely not an engineer) and you want to tell me how you are going to make your Bottle Sorter work.  Did anyone ever write for the School Paper?  Forget "Who", but "What" do you want to do, "When" do you want to do it, "Why" are you doing it that way, "Where" will you put the sensors, and when you understand and can tell me all of those, then worry about "How" you will do it.

Of the "journalism" questions I raised, above, a key one you might have overlooked is "When".

Bob Schor 

[dkong1321]

Hello sorry if it was unclear before. I have attached a zip with my myRio project and vi. For the myRio vi I am using a 3.5mm mic input to gather sound to the myRio. I placed the read within a timed while loop with a 1MHz Clock and a Period of 75 us. This loop runs for 13333 iterations before it stops. This is done so that we may acquire sound for a second. the values are pulled out and used to create a wave form which we then put into an extract tone VI to gain an amplitude and frequency from the recorded sound wave. 

The premise of our method is that we want to record sound for a second and then analyze that sound wave to see if the amplitudes or frequencies within that wave correspond to the sound of a glass, plastic or aluminum can hitting an object.

The issue we are having now is that the detected frequency reads approximately 60 regardless of the sound input. We are wondering if there is an issue with the sampling rate of sound made in the timed while loop. Or if the method we are approaching our project is wrong. 

Please let me know if anything is unclear.

Darren Kong

[Bob_Schor]

Well, I can't see your data, but I know a little bit about Fourier Analysis.  You've taken one second of data, and have done an FFT of these data.  As I understand what you wrote, the major signal is at 60 Hz.  You think that you are recording a sound (that lasts how long?  occurs when during the 1-second window?), but how do you know?  What do you know about the environment in which you are taking your data?  What does 60 Hz bring to mind?

Bob Schor

[dkong1321]

The 60 Hz you are referring to is what our mic seems to be picking up from the ambient noise, but we want to analyze the sound spikes that occur from the collisions of our bottle. We know that our VI will capture it within the 1 second snip because we have it recording under a while loop. Here is an image of the waveform graph before and after we snap our fingers (which has a similar shape to when a bottle collides):

Before (ambient noise)

After (Snap)

Notice that the "amplitudes array" activates because the amplitude exceeds a threshold of .04. So there is a definitive deviation from the ambient noise. And clearly, the waveform graph does indeed detect this. However, the outputs of the Extract Single Tone VI ("detected amplitude" and "detected frequency") seem to stay relatively the same.

Now, here is an image when we play a recorded piano note, which has a longer sound pattern (the audio is attached):

As you can see, the frequency and amplitude have a noticeable change here. And this is fine, but seeing as the noise of a bottle hitting a surface will be more rapid, we need our VI to capture short, quick sound data as well.

Our theory as to why it won't work with short sounds is because it is a transient signal, which is not picked up by the Extract Single Tone's FFT. We are not sure how we would be able to solve this problem.

[Bob_Schor]

Well, as a non-engineer, I'd reason as follows:

• The "sound" in question is "bottle hitting the bottom", which should generate a very brief sound.
• "Brief" = small time, implying 1/(small time) = high frequency.  Therefore I would sample at the highest frequency I could manage (40KHz, maybe).
• "Brief" = small time, so I would sample for a short total time, say 10 msec.  At 40KHz, that's 400 points.  From my understanding of sampling and signals, I would expect to have data on 200 frequencies, from 100 Hz to 20KHz.
• What I'd really like is to identify when the Sound occurs and start sampling at that time.  This is a "hard problem".  Is there a way to reduce this to an "easy" (or "easier") problem?
• Most of the time, no "sound of interest" is occurring.  As a First Approximation, I'm going to assume that in a 2 second "window", there will be one sound that is of interest.
• If I record 10msec samples, I have 10 msec (a fairly long time) to decide if the sound occurred.  If so, I might want to take the next 10msec sample (giving me 800 points, with the 400 points I want somewhere in the middle of that) that I can "export" for more processing.  What I might want to do is figure out where the sound starts, get my 400 points from there, and do my more sophisticated processing (FFT, for example).
• Do you know about LabVIEW's ability to do parallel processing?  You can do one task that is driven by timing (such as a sampling Loop, sometimes called a "Producer") and while the hardware is waiting for data, use the remaining CPU cycles to run a processing task (sometimes called a "Consumer") that analyzes the previously-collected Producer data.  This is called a Producer/Consumer Design, very common in LabVIEW Data Acquisition Projects.

Bob Schor