Wednesday, March 2, 2016

The previous
post was about a low-cost Bluetooth Low Energy sensor (really,
one sensor unit that includes the BLE-enabled microcontroller too
costs less than 15 USD and that's just a single prototype, economies
of scale come on top of that) and its accompanying Android app that
allows obtaining sensor reading manually. That's not bad but
manually reading data is sort of inconvenient. If you want to know,
what the temperature and humidity was in the dawn, you have to be
awake in that early hour. Personally, I prefer to sleep then so I
decided to automate the whole process.

So what can we expect from this new app? In case of the app that
came with the sensor in
the previous post, you started a manual scan and if the sensor
was in range, you got the humidity/temperature data. The new app
scans and stores data in the background. Once it is started, it sets
up a periodic timer (default timeout is 1 hour but can be changed in
the settings menu) and when the timer fires, it makes a scan. If it
finds a BLE node whose advertisement fits our criteria (e.g. it
advertises services with the UUID I allocated) then it extracts the
measurement data from the advertisement message and stores it in a
database on the device. This variant does not yet upload the data to
a server, that may come later. However, it can visualize the
measurements on simple graphs, hence the dependency on GraphView.
Like this:

Let's see the interesting bits of this app.

First and foremost, it is an interesting feature of this application
that the BLE layer is used in such a way that reading the sensor is
not an extra cost for the sensor. As the measurement data is
embedded into the advertisement packets that the device broadcasts
anyway, it does not matter if 1 or 1000 phones read and store data.
So this sort of sensor network can grow into an entire ecosystem -
the more phone users install and use the app, the more precisely the
measured quantity will be available once the phones upload their
catch to the server.

If you observe, how the data is stored
(DHT22SensorDataProvider.java), you can recognize an important
shortcut that I made: the database structure depends on the sensor
being used. This provider depends on the fact that DHT-22 (the
actual measurement device) provides temperature and humidity data in
the same reading. A different sensor (like the Bosch BME280 sensors
sitting in my drawer waiting for their turn) will require a new
provider and also a modification of the visualization part. So
there's significant development potential in making the app more
flexible when it comes to adding a new sensor type.

The actual sampling of the service happens in BLESensorGWService
using the AlarmManager to trigger the scan. Now getting the device
awake if it was just sleeping is not a simple business. Observe in
the list below, that even though there's always an hourly reading,
there's a significant variation when the reading happens.

In case of
our weather reading, it was not a problem but some sensors may have
more variable data. A large number of devices reading and uploading
would solve the problem of reading time variations.

GraphMeasurementActivity is the activity that depends on Jonas
Gehring's GraphView. The graphs are very simple so if you have
another favourite graph view component, just replace it there.

So we are at the point that we added sensors to our Android device
using Bluetooth Low Energy and created an application that samples
them producing nice weather-related data series. The next step will
be the integration of a cloud-based data analysis. I am still
thinking, which one to go for.

And finally, the picture of the sensor, in its "weather-resistant"
box.

About the blog

This blog is a personal diary about my adventures with the Google Android platform. I write it in the hope that others may find my experiences useful but please, beware. The blog is created as I gain experience about the platform myself so errors, omissions, etc. may be found in the entries.