Would anyone like to participate in building and deploying raspberry pi based air monitoring sensors throughout DMS? The board approved funding to build 3 devices for $300. Setting up the sensors is only half the project, then we need to do interesting things with the data being collected.
I would like to also volunteer to help. How about adding CO as well? It could detect malfunctioning heating systems, assuming the space is using gas, as well as keeping track of how long people run their autos inside with the doors shut.
I’m interested! I’ve done things with Linux, the Pi, and Python in the past if that’s of any help. I haven’t done much with sensors and logging though, that’s the stuff I’m most interested in learning about.
An interesting discussion will be complaints about the microphone running even though it is only going to sample a few seconds, analyze magnitude to get rough decibel level, then delete the audio data every few minutes
There are various sources, or potential sources, of carbon monoxide in the 'Space. Many of our tools (for instance, the laser cutter) are likely to produce at least some when operated in particular ways.
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.
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).
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:
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.
Concussive volumes can cause immediate damage that may not show up immediately.
