we could build a db meter that interfaces to the pi rather than using a mic and sound card if that is more acceptable. Shouldn’t be too hard.
Did you guys still plan to meet tonight?
Sorry got caught up with other projects tonight, we are planning on meeting this sunday @ 3:30 to start assembling and setting up the Pis
It would be very useful indeed, if the air quality and dB metering could be tied to some form of visible warning (large lights, LED, something) that could warn people (especially in the woodshop) to put on dust masks and hearing protectors.
There are a couple types of db sensors out there. The key factors to consider are volume, duration, and frequency. Our ears are tuned to 2-4k (human speech articulation), so these frequencies are most damaging. This is what a dBA rating will tell you (vs dBC).
Basic rule, anything over 80dBA sustained can cause damage over time. The higher the volume, the lower the time. Simple 
Concussive volumes can cause immediate damage that may not show up immediately.
OSHA stuff here: https://www.osha.gov/pls/oshaweb/owadisp.show_document?p_table=STANDARDS&p_id=9735
1 Like
We got the 3 sensors assembled and mounted around DMS, the software isn’t done yet, but I can deploy that remotely.
3d printed a mount that snaps into the back of the cases we ordered
3 Likes
Any ideas on how to get a rough calibration of decibels?
Continuously sounding an air horn of a known volume would probably annoy other members during testing, was thinking just play some continuous sound and use highly scientific phone db app and compare data captured by the usb mic. Current plan is to just average the 44.1khz 16bit mono data for so many seconds and log that number (scaled by something to get a very approximate db).
2 Likes
Got the new code updated and deployed, checked into the v2 branch
One big change is that instead of taking a single sample every 4 minutes, it will take readings from both the microphone and dust sensor over 3 minutes, then uploads the average from that timespan. This will miss high frequency signals, but this is more concerned with large trends throughout the day anyway than very small spikes.
One of the Pis froze during setup so it will have to be power cycled, also I neglected to record any identifying information on the Pis during setup, so I don’t know which one is which, will have to go around unplugging them to see which then still respond to pings. Here are the two new ones that are running:
https://m2x.att.com/catalog/7a8c0ddb57d5afee446c8ec052427ab6
https://m2x.att.com/catalog/0349cdda9597ff4a8f1d5773c0d1859b
Would anyone be interested in creating an html dashboard or page that pulls the data from m2x to create a user friendly display / summary, the m2x service can generate relatively simple graphs, but does annoying things like giving each stream its own axis instead of plotting values with the same units on a combined axis.
Wow, I think the mic might actually be working, I think this is from the fume extractor or angle grinders in metalshop.
Here is a static graph of data from that range, the red line is the data from the microphone. The blue line is the 10 micron reading. So you can see the red line plateau (some power tool operating steadily) and the particulate in the air climb up to a peak, then when the sound stops, the particular matter drops back down.
6 Likes
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), https://dallasmakerspace.org/air/
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