How We Built Our IoT Devices to Track Air Pollution in Delhi

The first week I joined Atlan, 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.

To read more about the theory and reasoning behind the project, check out my previous blog post.

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 opaqueness using an LED, lens, and photodiode. The attached microcontroller can read this opaqueness and calculate the number of particles per .01 cubic feet by reading the LPO (Low Pulse Occupancy) outputted by the sensor.

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 Nodejs, 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.

A 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 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.

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.

Next Steps

This pilot project is currently ongoing. We will release another blog post detailing our learnings and experiences from managing our first hardware deployment once this project is done.

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.