This is the second article out of a series of four, in which we explain how we built the IoT sensor network. Have a look at article one. The topic was presented at the Google Developers DevFest Switzerland 2018 conference. Watch the talk online.
by Wicher Visser and Dieter Niklaus
In our first article we wrote about the idea of a community of technology experts at ERNI building a dust measurement network. We shaped the idea into a product vision, came up with a minimum viable product (MVP) and organised ourselves into teams in a holacratic structure.
Application Architecture
One of our first goals was to come up with a rough architecture for our dust measurement network. The design needed to support modularity and be broad enough to allow easy extensibility, yet remain minimal enough to fit in the MVP scope and budget.
The architecture had to be as broad as necessary, yet as narrow as possible.
As before, during the product vision workshop, we first went through a discovery phase in which we looked at the full product vision and identified the components and aspects that would be necessary to fulfil the whole scope. These were reduced to their essence during the design phase. We analysed the core architecture of our design and identified those elements that were necessary to fit the scope and budget of the MVP. The architecture had to be as broad as necessary, yet as narrow as possible. We followed the SOLID open/closed principle: the architecture should be open to extension, whilst we should not need to change components when we increase the product scope.
The dust measurement network consists of an IoT device that measures particulate matter. The device is connected to a cloud service through The Things Network (TTN). The raw measurements are aggregated on our backend with weather data. A prediction service using a model created with Machine Learning generates pollution forecasts. The actual and predicted pollution levels are rendered on a map in the browser.
Hack & Hike Community Event
Each year the ERNI community meets at a Hack & Hike event on a Swiss mountain to work together on a project. Naturally the theme for this year was the dust measurement network. Our colleagues from Slovakia joined the event. A cable car took some of us up the mountain while others enjoyed the challenge of the hike uphill.
Like any proper ‘hacking’ event, a lot of designing, modelling and programming happened. The days were fun; the nights were short. The weekend was kicked off with a recap and goal definition by the project coordinator. The teams went about their business, coordinating at sync points and when the need arose. Our sleepy bodies and minds were refreshed on a hike around the nearby mountain peak the next morning. The weekend proved to be great for team spirit and productivity.
One of the teams, under the inspirational leadership of Dieter Niklaus, dedicated itself to building the IoT system.
Building the Hardware
The detector hardware is built with a microcontroller (MCU) and a particulate matter (PM) sensor. The detector device also measures the ambient temperature and the relative humidity. All these sensor data is sent to a time series database (InfluxDB) over an IoT network. It is important to choose a low-power radio frequency network, so the detector can be deployed independently and with minimal maintenance. With LoRaWAN we get good network coverage and low power consumption.
In order to measure the air quality at any point, we needed a battery powered device with a sensor that is affordable while proven to be accurate enough for our endeavour. Looking at projects with similar purposes (such as luftdaten.info), we learned that Nova’s SDS 011 fit quite well. It has a serial interface and easily connects to a microcontroller UART.
We chose the Adafruit’s Feather M0 LoRa as the MCU (Microcontroller Unit) because this module combines a LiPo (Lithium Polymer) battery charger, a LoRa RFM (radio frequency module) and a decently performant CPU core (ARM Cortex-M0) in a design with low power consumption.
With LoRaWAN we get good network coverage and low power consumption.
Device-specific security keys and configuration data must be kept in a non-volatile memory, so that the data is still available after a device restart. We added FRAM (ferroelectric random-access memory) to the design to cover this requirement.
The following block diagram shows the hardware design overview for the detector device.
Boxed Detector
The detector device needed to be placed outside and withstand any kind of weather. The housing was required to provide protection against intrusion according to IP44 (avoid foreign solid substances ≥ 1mm and splashing water from entering).
The first housing prototype needed just to enclose the hardware and protect the electronics against impact. Holes were made to provide space for the Micro USB connector that would be plugged into the device in order to charge the battery, to update the latest firmware, to access debug console and to load security key data during device production. Another hole provided the dust measurement air intake of the sensor. The last opening was added to act as the sensor’s air exhaust.
The detector device needed to be placed outside and withstand any kind of weather.
The prototype housing was designed and 3D printed by a portable 3D printer during the Hack & Hike weekend.
The Things Network
The Things Network (TTN) is an open community-driven network that enables its members to deploy their own LoRaWAN-based IoT applications. Its architecture is built on the LoRaWAN standard, which is defined by the LoRa Alliance, of which TTN is also an active member. LoRaWAN is a media access control (MAC) protocol for wide area networks. It is designed to allow low-powered devices to communicate with internet-connected applications over long-range wireless connections. In most cases, LoRaWAN uses LoRa modulation. LoRa modulation is based on Chirp spread-spectrum technology, which makes it work well with channel noise, multipath fading and the Doppler effect, even at low power. The LoRa Radio Frequency link operates in an ISM band (i.e. in Europe between 863 MHz and 870 MHz).
The network topology has 4 components: end notes, gateways, network server, and application server. The following figure illustrates the network topology of The Things Network:
The end nodes are the “things”. Our detector is such a node. The end nodes can send data packets through the LoRa Radio Frequency uplink channel randomly at any time. The packets are received by the gateways within radio link range. The same packets can be captured by multiple gateways at the same time. The duty cycle with which an end node sends packets shall not exceed 1% to ensure fair radio frequency channel usage.
The Things Network is an open community-driven network that enables its members to deploy their own LoRaWAN-based IoT applications.
The Gateways receive the data packets from the nodes and send them to the TTN Network Server. The more gateways are available near the area where the nodes are located, the better the network coverage will be. If a spot of interest does not support any coverage, any TTN Community member is able to add a gateway. This enables not only the owner of the new gateway to access the network but also adds more TTN coverage for all community members.
The Network Server routes messages from the nodes to the right application. The Application Server provides the bridge to the user’s cloud application. The messages are handled by an MQTT broker, to which the application will be subscribed.
TICK in the Cloud
We chose to use the TICK stack as our cloud application. The TICK stack is a time series platform that is designed to handle metrics and events. It consists of four independent systems that can work in concert with each other.
For our purpose, we used the time series database InfluxDB. It is capable of storing large amounts of time-stamped data coming from our detector though The Things Network. It has a built-in HTTP API to which our TTN gateway connects. It is hosted in a Docker container so that it can be easily deployed in any cloud environment.
With the hardware built and an IoT network able to store data in the cloud, we were ready for the next step. In part 3 of this series, we shall address how we use the sensor data along with other information to predict air quality using machine learning techniques.
This article is the second in a series on how a community of technology enthusiasts developed a dust measurement network to gauge and predict air quality.
Credits
Thanks to the following people for helping to make this project a reality: Adrian Beffa, Alain Zoja, Andreas Schöpfer, Angus Long, Barbora Feketeová, Caroline Jakob, Christian Schluep, David Krauer, Esther Studer, Gunther Dobratz, Halina Cardini, Isabelle Rüthemann, Ján Neščivera, Joel Sommer, Marek Linka, Marty Michael, Matej Pivarči, Michael Huber, Michal Dorner, Michel Meyer, Nathan Lauener, Nicolas Friberg, Ondrej Kollár, Reto Zumbühl, Ján Režnák, Simon Matter, Soňa Pochybová, Thomas Kägi, Dieter Niklaus
