This blog post is a synthesis of two articles I originally wrote for the SocialCops engineering blog. Check them out here - Tracking Air Pollution in Delhi, One Auto Rickshaw at a Time, How We Built Our IoT Devices to Track Air Pollution in Delhi
*
The Most Polluted City On Earth
Delhi is one of the largest and fastest growing cities on the planet. Home to over 24 million people, one of the unifying challenges for this huge and diverse population is also one of the most basic necessities for life: clean air. Delhi was recently granted the dubious title of the “World’s Most Polluted City” by the World Health Organization.
Air pollution has major health consequences for those living in heavily polluted areas. High levels of particulates and hazardous gases can increase the risk of heart disease, asthma, bronchitis, cancer, and more. The WHO estimates that there are 7 million premature deaths linked to air pollution every year, and the Union Environment Ministry estimates that 80 people die every day from air pollution in Delhi.
How it Started
The first week I joined SocialCops, I was given a “hack week” project to present to the rest of the company. My project was simple and open-ended: “build something cool”. As a newcomer to Delhi, I was concerned by the infamous air pollution continually hovering over the city. I decided to build two IoT air pollution sensing devices (one for our office balcony and one for inside our office) to determine how protected we were from the pollution while inside. Over the following weeks, this simple internal hack turned into a much more ambitious project — monitoring air pollution throughout Delhi by attaching these IoT devices to auto rickshaws.
Air Pollution Sensors + Auto Rickshaws
Traditional particulate matter measurement devices use very advanced scales and filters to measure the exact mass of ambient particles below a certain size. As such, these devices are prohibitively expensive (₹1.1 crore or $165,000) and fixed in a single location.
We took a different approach.
Autorickshaws at the Saket Metro Station
Auto rickshaws are a very popular source of transportation in Delhi. Popularly called “autos”, these vehicles can be found all over Delhi at all times of day and night, making them an ideal place to deploy our sensors. Unlike traditional air quality readings that sample from one location repeatedly, the sensors deployed for this project sample data for air pollution in Delhi directly from traffic jams, markets, and residential neighborhoods all over the city.
The Internet of (Air Pollution Monitoring) Things
We have developed a custom internet-connected device to attach to take pollution readings from autos. Each device contains an airborne particle sensor, a GPS unit, and a cellular antenna to send the data over 2g networks in real time; we were able to construct each device for about ₹6,500 ($100) each. The greater mobility and reduced cost of these devices comes at a cost: the particle sensor we are using is less accurate than those used by traditional pollution monitors. The reason is that our sensor determines the number of airborne particles by reading the ambient air opaqueness, instead of measuring the precise mass of the collected particles.
Our solution for this drop in precision is to increase the sample size. A lot.
Each device takes two readings per minute. With five devices deployed, the pollution reading for each hour is an average of 600 data points, and the AQI for each day is calculated from almost 15,000 distinct readings. The up-time for each device is not 100%, as the auto-rickshaw drivers generally drive for 12 hours per day, and we are not always able to transfer the device to another auto driver between shifts. However, the resulting data has still proven sufficient for our experimental purposes.
SocialCops Delhi Air Pollution Dashboard
Hard Decisions Over Hardware
We chose the hardware for this pilot project based on ease of construction, cost, and hackability. There were a few decisions to confront first: what data to collect, how to collect it, and how to retrieve it for further analysis. We decided to focus on collecting data for particulate matter (PM) concentration since this is the primary pollutant in Delhi. There are other factors that influence air pollution, such as humidity, but we can pull most of this data from established external sources and integrate it with our primary data.
To track devices and analyze data in real time, we decided to send data via 2G networks using a GPRS (General Packet Radio Service) antenna and SIM card. We decided to go with the LinkIt One development board for the initial deployment, due to its compatibility with the Arduino IDE and firmware libraries and its included GPS and GPRS antennas. (We originally intended to also use its included battery but decided not to, as explained later in this post.)
For the pollution-sensing module, we decided to use the Shinyei PPD42NS because of its low cost and general dependability and durability. This sensor measures the ambient air opacity using an LED, lens, and photodiode. The attached microcontroller can read this opacity and calculate the number of particles per .01 cubic feet by reading the LPO (Low Pulse Occupancy) outputted by the sensor.
The prototype hardware, mid-assembly
This sensor module is relatively imprecise, as are all dust sensors in this same price range. That’s why one of our main goals with this experiment is to determine whether aggregating a large enough number of readings from this type of sensor can provide pollution data that is as (or more) accurate than the data from traditional air pollution stations. The stations cost ₹1.1 crore ($165,000) each. The final cost of our hardware package, including the case and external power bank, was about ₹6,500 ($100).
Firming up the Firmware
The firmware for this experiment was written in C/C++ using the Arduino IDE, which the LinkIt One is designed to be directly compatible with. The basic flow of the firmware is simple: sample data from the pollution sensor for 30 seconds, calculate the particles per .01 cubic foot from these values, retrieve the GPS location, upload the data to the server, and repeat.
One scenario we needed to prepare for was the IoT device being temporarily unable to connect to the cellular data network. To account for this, we implemented a caching system — if the device can’t connect to the server, it logs current readings to its local 10 MB of flash memory. Every 30 seconds, the device takes a reading and attempts to upload that data to the server. If it is able to connect, then it also scans the local filesystem for any cached data; if there is locally stored data, it is uploaded and deleted from the local storage. This feature allows the device to operate virtually anywhere, regardless of connectivity, and also provides interesting insights into cellular dark zones in Delhi.
With the firmware functionality complete, one of the immediate problems was that the device would occasionally crash while uploading readings. Unlike debugging a more traditional software program, there was no stack-trace to look through to find the cause. The only clue we had was that the light on the microcontroller would turn from green to red, and the device would stop uploading data. Like most microcontrollers, the LinkIt One has very limited SRAM, leading us to suspect that the crash may be due an out-of-memory error. The first optimization we made was using the F() macro to cache constant strings in flash memory during compilation instead of storing them in virtual memory at runtime. This optimization simply required replacing, for example, Serial.println(“string”) with Serial.println(F(“string”)).
This optimization was a good practice, but it still did not solve the device crashes. To further optimize the memory usage, we focused on the largest variable being stored in virtual memory during runtime: the JSON string storing the data to be uploaded to the server. By allocating memory more carefully for this string and ensuring that only one instance of this string existed in SRAM at any time, we were able to close any remaining memory leaks and solve the problem of unpredictable device crashes.
Backend and Security
To store the data being uploaded by each IoT device, we built a backend and API using Node.js, Express, and MongoDB. Beyond standard server-side security protocols (cryptographically secure login, restrictive firewalls, rate limiting, etc.), it was also important to build endpoint-based authentication and field verification for incoming device data.
Autorickshaws at the Saket Metro station.
A unique cryptographically secure key value is hard coded into the firmware for each IoT device. When a reading is uploaded to the server, this key value is included along with the device ID and authenticated against a corresponding key value on the server for that device. This technique of hard coding a password directly into the firmware provides a high degree of security that ensures our database is not corrupted with unauthorized data.
Power Problems
One of our major obstacles was figuring out how to provide enough power for the device to ensure that it would transmit data 24/7. Since the device uses GPS and GPRS antennas and the PPD42NS dust sensor requires constant back-to-back readings to compute an accurate value, the device is power hungry for a microcontroller-based project.
The LinkIt One comes with a rechargeable 1000 mAh battery. In our testing, this battery was only able to power the device for about three hours of operation. Even worse, the battery often had difficulty re-charging or holding a charge once it had been fully discharged, leading us to believe that the battery was becoming over-discharged and damaged by being run for too long. Further compounding this problem, the LinkIt One does not have the capability to programmatically trigger a shutdown, making it impossible to prevent this damage from occurring.
Having discarded the included battery as an option, we began testing the IoT device using low-cost mobile power banks designed for smartphones. These power banks generally come in capacities between 3000 mAh and 15,000 mAh (1-5x an average smartphone battery) and can be purchased for under $20 each. One battery we tested included a solar panel for recharging, but unfortunately, the solar panel wasn’t able to recharge the battery quickly enough. We ended up settling on a reputable 10,000 mAh rechargeable battery, which can run the device for 33 hours straight.
Brawn Over Beauty
Delhi is not a forgiving environment for hardware devices, especially when they are mounted in auto rickshaws in the height of summer when the temperatures regularly top 40℃ (104℉) or 45℃ (113℉) during heat waves. During our initial prototyping phase, the devices were encased within cardboard boxes, which made it very easy to quickly adjust the component placement and encasing structure (wire hole locations, etc).
One of the devices after being deployed for a week.
One order of 100 x 100 x 50 mm enclosure boxes and a power drill later, we assembled our new pilot encasings. Protected by white hard plastic with the dust sensor component mounted externally for unrestricted access to ambient air, the device is not pretty. It is, however, durable enough to survive extremely demanding operating conditions, and looks rough enough to reduce the risk of theft that comes associated with shiny new electronics.
From the Lab to the Streets
Beyond the core technology, one of the most difficult aspects of this pilot project was the logistical challenge of actually deploying these devices on auto rickshaws. Our priority for the deployment was twofold — to keep the device hardware safe and to have the IoT devices transmitting data 24/7 for the duration of the experiment.
Recruiting drivers was easy. We simply went down to the nearby metro station and asked the auto drivers if they would be interested in participating in the pilot project. By paying a modest daily and weekly stipend, we are giving the drivers a supplemental source of income and financial incentive to keep the device safe. Since the battery only lasts for 33 hours, the drivers have to return to our office every day to collect their pay and to swap out their battery for a fully charged one.
The SocialCops team preparing the first device for deployment.
To keep track of the devices and the incoming data, we built an administrative dashboard. This dashboard enables us to view incoming data, as well as a live map of device locations. Since we have drivers’ phone numbers, we can contact drivers if we see a device malfunctioning on the dashboard.
Moving Forward Against Air Pollution in Delhi
This experiment could be deployed at a greater scale in the future, with 100 sensors deployed across a city, for example. The base cost of the required hardware would still be considerably less than acquiring the traditional equipment used to measure air pollution. With 100 sensors deployed, the average pollution level for each day could be calculated from over 250,000 individual readings, and the sensors could be deployed to a wider area of the city.
For the next iteration of these pollution sensors, we already have a few concrete goals in mind. Our first priority is creating a sustainable and scalable system for powering and managing the IoT devices while they are deployed. Replacing five batteries per day is manageable for this deployment, but we want to scale up to having 100+ devices on the streets at the same time. One option is powering the devices from the autos themselves, the same way you could charge a cellphone in a car. The complication here is that auto rickshaws are generally turned off while the drivers are parked and waiting for customers. We would still need to include a power bank that (unlike the current power solution) supports pass-through charging to power the device and charge the battery simultaneously.
Another goal is to perform further research on alternative carriers for the devices like buses and cabs. Minimizing the recurring costs (the drivers’ stipends) will be essential in forming a sustainable system for deploying these devices. Finally, it would be best to move away from DIY-focused prototyping hardware such as the LinkIt One, and to form partnerships with hardware suppliers to produce and encase each device scalably with more standardization and lower variable costs.
New technological capabilities enabled by the Internet of Things have the potential to transform how we assess and alleviate some of the world’s most pressing problems. By further developing and refining these low-cost air pollution sensors, we hope to establish a sustainable model for collecting relevant and detailed public health data in hard-to-reach areas.