Almost anybody that lives in a decent sized metro area probably has air quality concerns. My city has seen a lot of improvement in the past few years, but we still rank as one of the worst in the country for year round particle pollution, and we still have periodic ozone alerts throughout the summer. The local wisdom says it is especially bad in the “bowl” of a valley in which the city sits. Shortly after Birmingham was founded, it grew rapidly as a steel town. During this period of growth, the pollution in the Jones Valley was terrible. According to many, this pollution led those with money and mobility to move up, and eventually over, Red Mountain. In the 1970s the situation was so bad that a federal judge invoked the first ever use of the Clean Air Act’s emergency clause to have smokestack industry temporarily shut down.
Fast forward to 2017, and I’m looking for a new home. While driving around house hunting with my incredibly patient spouse, we started talking about the advantages of moving from our loft downtown to the “Over the Mountain” neighborhoods and air quality came up as one potential benefit. We’ve both heard how bad it used to be, and that better air may have been one of the reasons people moved where they did. But, is it true? Is the air quality in these neighborhoods any better? Should we even factor that into buying a home in the same general metro area? My wife is a scientist, and we share a desire to make good decisions with data. Unfortunately, the data we have available on air quality in our metro area isn’t granular enough. There are few sensors, and they are quite far apart. This setup is good enough to get regional measurements, but not good enough to test some of our more localized assumptions. To get what we want, we’re going to have to measure it ourselves. Commercial measurement equipment is fairly expensive, and doesn’t easily lend itself to automated capture and logging. Lucky for us, I’ve been having fun hacking on the Arduino platform lately, and there are a ton of great sensors for measuring different aspects of air quality out there for cheap!
No project should start without an end in mind. For this project, the goals are fairly simple:
- Measure the most common components of air pollution as accurately, precisely and discretely as possible
- Capture the time and location of the measurement
- Reliably record all of the measurements in a way that lends itself to easy analysis
- Be able to install as a fixed installation to measure trends over time in a single location
- Portable enough to take on the road to measure data in many locations in a short period of time
- Be able to take the data and use it to drive informed decisions
- Learn a few new things about air pollution, Arduino programming and electronics
The core platform
Logically, there are two separate parts to this project. The first is a sensor platform that needs to be able to connect to the sensors, read data from them, and then send it somewhere. The second part of the project is an aggregation and analysis platform that collects the measurements, stores the data and provides a way to use it to get useful insights. This logical separation frees us to use tools that are well suited for each part of the job. This simple little diagram shows all the pieces and how they fit together:
For the sensor platform I chose an Arduino Mega. Why a Mega? Well, there was one sitting in my parts bin, for one. The Mega has plenty of IO to support a lot of sensors and other modules, and plenty of flash for a big program. The Arduino Mega has more than enough processing capability to read from sensors and push data over a network, while still being low power enough to potentially run off of a solar panel or battery. This is important to meet the project goals. There are plenty of other devices in the Arduino family that could work just fine.
The aggregation and analysis platform was developed on my Macbook, but the final deployment target is a Raspberry Pi 3 rev B. The Pi can easily run the software stack, is also low power so I don’t feel bad leaving it running for extended periods, and has enough GPIO pins to drive some other devices that will respond to changes in the air quality data. One thing to keep in mind is that the Pi is an ARM7 based device, so anything that gets built on another platform needs to be portable to ARM7. Another point in the Pi3’s favor is the built in Wifi.
Sensors and measurements
If you look at “real” air quality measurements from government agencies or other organizations, you’ll see a few things that most of them measure. Particulate matter, ozone, carbon monoxide, VOCs and others are common to see in measurement suites, along with temperature and humidity which affect particle and compound formation. I don’t expect to get absolute PPM / PPB measurements on par with professional gear, but for this use case that isn’t necessary. A relative measurement that can be used to compare measurements taken in different areas is good enough. A little digging on the internet led to a set of sensors that should get measurements that are good enough to compare different areas of town. This list is by no means comprehensive, but these are the sensors chosen for this project.
The MQ-131 sensor measures ozone in the atmosphere. Ground level ozone is known to cause a variety of health problems, and is a regular source of air quality alerts in urban areas. Since my metro area sees multiple ozone alerts each summer, this is one that definitely should be measured.
The MQ-135 sensor is a general air quality sensor that is sensitive to smoke, NOx, CO2, benzene, alcohol and others. It does not differentiate well, but for the purpose of this experiment a relative measurement of miscellaneous stuff you don’t want to breathe in is good enough.
MQ-7 sensors measure carbon monoxide. CO is not something you want to breathe in, and is regulated by the EPA. CO is most worrisome in enclosed indoor environments, but can also be a concern outdoors for sensitive populations.
Sharp’s GP2Y1010AUoF sensor measures particulate matter in the air using an LED to reflect light off of particles which is then measured by a photosensor. Fine particles are a known source of health problems. Typical air quality measurements look at two types of particles; those that are < 2.5 microns in size, and those that are < 10 microns. As far as I can tell the Sharp sensor isn’t sensitive enough to differentiate between the two classes, but for this experiment a total measurement of particulate matter is sufficient.
The DHT-22 is a simple temperature and humidity sensor. Both temp and humidity can affect the formation of particles and compounds in the air, so it’s worth measuring for use in the air quality calculation. Measuring temperature will also allow this experiment to map out the urban heat island effect. This sensor can only be read every 2 seconds or so, but for this project that’s OK.
Connecting to the network
With the sensors selected, connected and happily spitting out data, it’s time to do something with it! I’d like the sensor array to be located independent of the collection server, which means the sensor array should probably be able to send its data wirelessly. The first iteration of this project used a CC3000 based Wifi shield. If you are looking for a reliable wireless connection for your Arduino project, this is NOT it. Nothing against Sparkfun, it looks like a chip level issue and not anything in their design or library. The CC3000 locked up so often that a watchdog timer became necessary to keep the system running for more than an hour at a time. At its worst I measured over a hundred watchdog driven resets in a 24 hour period. No bueno! Switching to a WINC1500 breakout board from Adafruit helped immensely and now the monitor can run for days without a restart.
Inside the Arduino sketch’s loop() function each sensor is read in turn. The data is then formatted as a JSON string, ready to be sent to the collection service.
Collecting and analyzing the data
Now that the sensor array is hooked up to the network and generating data, how can it be collected and analyzed? This turned out to be the simplest part of the project thanks to node.js and Elasticsearch. The sensor array formats the data as JSON and sends it along to a simple REST API built on node.js and Express. This API in turn saves the data out to Elasticsearch for analysis. The combo of node.js and Elasticsearch is lightweight and quite powerful. Using Elasticsearch also gets Kibana as part of the deal, providing an easy way to search, slice and graph the results. Simple and effective. Kibana is great for displaying the graphs, but I also wanted to show running averages, minimums and maximums in an easy to digest way. Another REST API provided by node.js accomplishes this using Elasticsearch aggregations. That API is called by a simple web front end built in Angular. Finally, I feel like this project is fully buzzword compliant! Here’s what it looks like. Not the prettiest thing around (yet), but it is effective!
All of the code used for this project is available on my Github. Right now it is just a dump of the artifacts including the Arduino sketch and a simple node.js + Angular application to get aggregate statistics on the data. In the future this will include Fritzing diagrams and perhaps schematics and board layouts. Oh, and some useful docs that actually explain everything!
The next step for this project is to get a GPS hooked up so location stamps can be added to each reading. As soon as the GPS is working, we’ll take the sensor array for a long drive around town capturing readings as we go. Then it should be straightforward to take all of the captured data and map it out to see if our assumptions about air quality across Birmingham neighborhoods were correct or not. Mappable data also opens the door to other interesting analysis, such as correlating readings with industry, income, etc.
Taken together the Arduino, node.js, Elasticsearch and Kibana provide all the tools an amateur citizen scientist needs to take some basic relative air quality measurements. I hope others find this useful and share their improvements and/or data with others interested in what they are breathing. In the near future I will publish my findings along with more detailed dives into sensor calibration and other related topics. In the meantime, happy hacking!