Most Internet of Things (IOT) products are associated with using very efficient protocols such as MQTT over a special purpose radio link like LoRa. However the IOT solution we are building in the Pollution Guardian project is quite different for the following reasons:

• As a consumer device we need interaction locally in real time.
• Our aim was to produce hardware which could be purchased for the minimum cost to the consumer and so offer benefits to as many people as possible. This meant a minimized UI on the device itself.

These drivers brought us to the following decisions: we would build a device which reaches the internet via a smart phone bridge. We would therefore use Bluetooth Low Energy to communicate between the device and the phone.

We have chosen to build our prototypes using Android as this offers a lower cost to start up than using IOS in terms of devices and computing facilities, we have been careful however throughout the project not to lock ourselves into Android-only infrastructure solutions.

As a roadmap we realized that we needed two versions of the application: first an ‘engineering’ application optimized for our testing in laboratory and in technical field test and second a ‘consumer’ application which would deliver the experience design for a real customer.

The engineering application was the first target since it was the means to learn about our sensor package and how it reacted to changes in pollution conditions. Even for this application we have stuck to the principle of cloud data storage as the most effective means to leverage the value of the data collected – so no memory cards or local only databases were to be implemented. Because our background was in device-side development rather than infrastructure, Firebase Real Time Database emerged immediately as a very good candidate for data storage.

Further benefits of using Firebase emerged for authentication with code snippets available for sign-on and sign-up. Firebase also handles ‘beneath the hood’ all the buffering, reconnecting and error handling needed for practical operation with a mobile device where connection to the internet may or may not be available at any moment in time.

For the engineering phase, extraction of measurement results files for further offline analysis is essential and Firebase’s admin API library enabled this in a python environment. The data could then be further analyzed with data science tools in Jupyter notebooks.

So far we have extracted data from hundreds of miles of road-test and hours of static testing – the tool set works well and extremely reliably for us. Future posts will share more about the Engineering App and how we further developed our application and cloud designs.