Electronics > Beginners
sound analyzer for automating quality checks?
<< < (3/10) > >>
cdev:
You can get bare piezo discs for less than a dollar (or less in quantity), and wrapped in a small plastic case slightly less suitable for use as a contact mic. but more durable for under $2.
rhb:

--- Quote from: engineheat on December 19, 2018, 12:28:49 am ---

Thanks. Why break it into 100 pieces and take the average? Why multiply the samples with 0 to 1 using the method you mentioned? How would the intensity of the sound (distance from source to microphone) affect the DFT? Only the amplitude will change right?

Do you think it's necessary to do a DFT on the ambient noise as well and maybe filter the ambient noise out first?

--- End quote ---

You average 100 samples to reduce the variance of your estimate.  The reason that most DFTs on DSOs are so bad is because the programmers did not do that. 

The triangular, Bartlett, window is so the spectral peaks are not smeared out.  In the frequency domain it's a (sin(x)/)**2 rather  than the sin(x)/x of a rectangular window.  I've yet to see a DSO that offered a Bartlett window.  Check wikipedia on the subject of window functions.  Install gnuplot, set samples to 10000, plot the two functions and take a look at the sidelobes.

The lower the amplitude the greater the quantization noise component.

I could compensate for the ambient noise, but I suggest you use a sound isolation box instead.  You really don't want to learn that much about DSP or spend the amount of time it would take to code it properly.  It is not trivial. 

Most of a seismic processor's time is spent suppressing noise.  How you do it depends upon what type of noise it is and where it is coming from.  Data acquisition contracts have many pages of stipulations about noise levels and there is a company representative on hand to check them continuously during the entire acquisition.  You can't shoot if another boat is closer than so many miles.  You can't shoot if the waves are higher than some value, etc.

Install Octave and get to the point you can do the steps I outlined previously.  You'll have a much better appreciation of the problem you have posed.  It's very sensible and readily done, but it is not something you do in an afternoon.  In your case, starting from square one it will probably take a week or more of work just to do a proof of concept.

Personally, if I were doing this I'd write a C program.  I'm not impressed by the software engineering of Octave.  I cannot compile it on Solaris.   It claims to be able to read WAV files and I think it will interface to a sound card, but frankly I don't know.  I use Octave from time to time to prototype solutions to problems, but that is all.  Octave/MATLAB are not really designed for solving production problems.  They are research tools.  I only suggested using those because of the complexity and the amount of work a production quality C program would require.

Octave/MATLAB are good enough to produce a proof of concept.  Make WAV format recordings of a good gearbox and a bad gearbox in a quiet environment and compare them using the process I outlined.  A Zoom H1 recorder for $100 will give you a good stereo WAV file to work with.
engineheat:

--- Quote from: rhb on December 18, 2018, 03:29:40 pm ---

Collect about 10 seconds of data at 44.1 KSa/S (standard CD sampling)



--- End quote ---

Thanks for your responses so far. Turns out I cannot collect 10 sec of sound, more like 0.5 sec to 1 sec. This is due to the nature of the existing production line. I can't slow down the rate, nor will they let me. Can 1 sec of sound sample work?

I'm thinking of using Python (with the scikit-learn and pyaudio package). I'm more familiar with Python, and it has a package to interface with the PLC too.  How powerful of a computer do I need for this? The processing must be done in matter of tens or hundreds of millisecond in order to not slow down the production.

rhb:
You can use 10 samples.  The variance of the spectral estimate is 1/sqrt(N) which is why I recommended 100 samples.  Any PC will be fast enough.  An Arduino probably would not.  Also,  with a PC you can save the spectra for each unit.  That will be important for establishing the spectra for good units and bad units.  You can also then compute average spectra on an hourly or shift basis to look for problems caused by changes in the production process, for example ambient temperature.

If you collect 40960 time samples you can use 10  samples  4096 long with 11 Hz resolution or 20 samples 2048 long with 22 Hz resolution or 40 samples with 43 Hz resolution.  The variance of the estimates at 43 Hz resolution will be 1/2 the variance at 10 Hz resolution.

You should record a known good unit and a known bad unit for 1000 seconds and then compute the averaged spectra for the various window lengths to establish how many samples to average and what your resolution bandwidth needs to be.  It would be very desirable to collect recordings from more than one sample unit so that you get some data on the variance of the good and bad gearmotors themselves.

I'm not all that familiar with python, but I'm sure that it has all the features you need.  So if you are comfortable using that, use it.
engineheat:

--- Quote from: rhb on December 21, 2018, 12:31:15 pm ---You can use 10 samples.  The variance of the spectral estimate is 1/sqrt(N) which is why I recommended 100 samples.  Any PC will be fast enough.  An Arduino probably would not.  Also,  with a PC you can save the spectra for each unit.  That will be important for establishing the spectra for good units and bad units.  You can also then compute average spectra on an hourly or shift basis to look for problems caused by changes in the production process, for example ambient temperature.

If you collect 40960 time samples you can use 10  samples  4096 long with 11 Hz resolution or 20 samples 2048 long with 22 Hz resolution or 40 samples with 43 Hz resolution.  The variance of the estimates at 43 Hz resolution will be 1/2 the variance at 10 Hz resolution.

You should record a known good unit and a known bad unit for 1000 seconds and then compute the averaged spectra for the various window lengths to establish how many samples to average and what your resolution bandwidth needs to be.  It would be very desirable to collect recordings from more than one sample unit so that you get some data on the variance of the good and bad gearmotors themselves.

I'm not all that familiar with python, but I'm sure that it has all the features you need.  So if you are comfortable using that, use it.

--- End quote ---

Okay, I think I appreciate your response a lot more now. I first tried to record 1 sec of sound (sample rate =44100) and did DFT on all 44100 samples. The spectrum looked different each time, even as I tried to control the settings the best I can. I then downloaded a FFT spectrum analyzer to my smartphone and it turns out the spectrum is fluctuating quiet a bit.

So if I understand you, I will split the 1 second into ten 100ms chunks, do a DFT on each of those and average the result. I understand this decreases the variance. I do have some background in statistics, it's just the DSP part that I'm weak on. If I have less samples each time, my frequency resolution will be bigger (but this doesn't seem to be an issue), is that right?

Thanks
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod