That is great information. I checked the camera, and there was indeed someone working in the Metal Shop during that time.
Created an initial page with @AlexRhodes help, its just showing the built in m2x widgets (where I canāt control things like axis or color, so you can see each graph has different colors and ordering of lines), Air Quality Sensors ā Dallas Makerspace
4 Likes
Would anyone be interested in meeting one night to improve the sound level logging algorithm? Would need to take sample recordings with various tools running, get a db reading via phone at the sensor, then analyze waveform and develop some high pass filters to make the recorded db level more useful.
Right now itās just averaging the log of the sample values over 3 minutes.
Here is a wav sample from the metalshop (it isnāt normally recording anything, I had to remote in and manually record a sample), I think the low frequency sound is probably the AC vibration coming through the wall.
To be pedantic it should do the averaging and then take the log of the result. May not make a noticeable difference depending on the levels but log(avg(X)) is not the same as avg(log(X).
1 Like
I donāt know how you are connecting the microphone to the Pi, but if your goal is to measure āsound levelsā what you want is to measure the peak voltage, not various samples of the waveform.
You need a circuit like this between the microphone and the Pi;
With this you can estimate the decibels above ambient room noise. To do this you start by determining what the average voltage from the above circuit in the room when it is completely quiet. You then use the ratio of this output voltage to the voltage when noise is occurring and you can calculate the db difference.
If the quiet peak voltage is 1v and the noisy voltage is 4v, then the db difference would be
20 log (4/1) ~= 12dB louder
You can get away from using the external peak detection circuit, but only if you can sample the sound about 96 thousand samples per second and then calculate the peak (or RMS) voltage from those samples. But the little input circuit is much simpler.
I think you could get away with sampling at a slower rate since you only really care about sound in the hearing range. Say 45 ksamples/sec.
Also if we donāt care about frequency information which, since heās averaging Iām guessing he doesnāt, then you could just accept the aliasing and sample much slower. Everything will alias into the first Nyquist zone and you can pick off the peaks in software.
While you could get by with 40-45ksps, you do need to avoid aliasing. The primary reasons is that different frequencies will have different effects how loud the sound is. Human hearing is not a flat response across our hearing range and āloudnessā is very dependent upon frequency, or so I have been taught.
In either case, the simple diode/capacitor arrangement removes the need for high speed sampling, which the Raspberry Pi isnāt really suited for. That way you can sample a few times a second to a few hundred times second and obtain a good average sound level.
In general yes but in this case I think the aliasing could work in your favor. Iāll have to think about that more since I spend so much of my life trying to avoid it.
Edit: Yep, should work. Yes you do lose frequency information but you lose that with the peak rectifier too.
Itās using the cheapest USB mic I could find, then reading the raw 44.1 khz mono 16bit data coming from that device, thanks for the info about only taking the log after averaging, I will update the code
That was probably me sandblasting 
If you are measuring sound for hearing loss and protection issues, then peak dB and duration become important. At certain thresholds, transients of less than a second can cause damage. Look up OSHA standards for excruciating details.
Also, the distance from the sound source is highly important since sound pressure drops off at the inverse square of distance (spherical radiation model). Something that reads 90dB but is 20 feet away from the source (which can be highly directional) is a lot different than a person operating the machine and only a few feet from the noise (think when operating Joiner or Table Saw which is about 108dB)
2 Likes
One interesting use for the sound data will be to see how often things like woodshop, lasers, metalshop are actually in use. Itās easy to see the spikes in woodshop that likely correlate to the dust collection being on.
I noticed that at night with no activity some sensors are recording a minimum of ~65 while some are recording ~45, some noise reduction / high pass filtering should improve data capture to make the data cleaner (not to mention just better calibration and understanding of what the cheap mics are actually picking up).
I guess I donāt understand or am not sure of the purpose for which your collecting the data. If it is related to hearing loss/protection issues then the specific type sound characteristics is what should be sought - again see the OSHA standards they give detailed explanations of type and what to measure. Particularly transients.
Also, have you done any sort of testing for directionality and drop off of microphone? E.g.a constant sound, constant radius sweeping across field microphone: Right-Left, Up-Down? You may a cone or elliptically shaped cone where there are clear drop offs. In looking the microphone placement up in corner, that is acting a reflecting surfaces back towards the microphone - just like our ears direct sound into the ear canal. Is there any type sound isolation for the mounting to the wall (thin foam) and the microphone in case (low frequency noise transmission more an issue but if you arenāt discriminating across hertz bands then itās all going to register as sound. Low cut-off filters for below 20hz are probably a good idea since this is getting into the area of tactile vibratory detection, e.g. trucks passing, doors closing etc.
Look at the better microphone is Digital Media and the efforts they go to to isolate the microphone.
If there are battery powered, take each one, hold it near where a tool operatorās ear would be with a tool operating and being used. That will give you a basic baseline to work with. Since the inverse square law and the method that dBs are cumulatively added, since dBās are a logarithmic scale, your chart algorithms could show actual reading and and calculated localized user reading.
Not easy stuff for analysis. I know the factory we worked at the EHS folks did hold the dB meters at the location of operators ears as well as random reading throughout the shop. We could use or own ear muffs unless they had an approved sticker on them verifying they were at least -25dB. Ear buds were verboten of use on the shop floor. You could get muffs that had speakers but there max output was 85 dBās taken about 1 inch from speaker.
If the goal is just clean looking data sets and charts, then do whatever that takes. But to later try and do any sort of analysis and inferences related to hearing loss/protection ā¦ not sure data set is of much use as your reading all tend to very much under estimate the actual sound pressure. But do record the number of high transients with duration of say 130bD (algorithm distance compensated) of more than 0.1ms. That would be useful.
This is an interesting project - but data input is important. Iād be willing to help you do some of these measurements observations. Not just snipe.
1 Like
It seems rather complex to measure sound pressure from a single point in a room and then try to predict the sound pressure of an individual that is somewhere else in the room. This is especially true if there are multiple sound sources in the room that may be on or off. Since sound pressure decreases with the square of the distance from the source, the pressure at an individual could be significantly different than the pressure at the point of measurement. It seems to me that the sound measurements are interesting information but only by comparing measurements over time to detect trends (e.g. the wood shop is suddenly much louder than last month, maybe we need to take manual readings on the newly introduced tool); calibration doesnāt seem to be important if just trending variations over time.
1 Like
Right now Iām just collecting data to make an interesting looking graph, but having a better understanding of how good the data is would be nice. When would be a good time to meet to do some sound testing?
Iāll be at the Space on Sunday for sure. First for Finance, then some afternoon classes. Then throughout the week. Weāll see other. Try to get some baseline measurements. Youāre about to learn what gage R&R study means!
But in the end, you can have the basic charts you have for trending purposes as well something that is may be useful and informative. We might get the Digital Media folks involved as they play around a lot with sound and might have so mettering that will help us cross check. Going to be a fun project or could be!
See ya soon.
I updated the sensors to record the RMS average over 3 minutes instead of the previous nonsensical math it was doing, Can see that currently the main sound that gets picked up when nothing is happening is the AC running (sound correlates with temperature going up and down). Currently Iām adding 90 to the average just to keep graph in similar range to initial data, actual average is in the ~-50db to 0db range, where 0 would be the microphone sample being at max 16bit value
I have an old RadioShack analog decibel meter you can use if youād like to calibrate the microphones on the monitors. A cell phone isnāt an accurate measurement device.
2 Likes
Do we have a DMS anechoic chamber?
Seems like the Pi mounted over laser is having issues, itās still logging data, responding to pings, and I can ssh into it, but it hangs after entering password. Which seems like an odd failure mode (the very high pings responding on internal network are probably a bad sign)
Edit: Looks like 3 of the 4 pis are showing the same issue, ssh freezing after a short time, I wonder if the built in wifi(they are pi 3s) is going over usb like the ethernet is