October 27, 2017
Recently, thanks to our friends at Fraunhofer, I was able to try out MIOTY, Fraunhofer IIS’s wireless IoT platform.
The kit we’ve got is comprised of the MIOTY M300 base station receiver and a couple of MT101 nodes, including handy battery packs needed to take the nodes out for a walk.
I set out to 1) find what range I could get out of the MIOTY nodes, and 2) build a proof-of-concept MIOTY sensor node and test it out in an environment without other traditional networks available (such as Wi-fi).
At WATTx, we regularly play around with different tools that help us get the job done. Network protocols often play a big part in enabling us to come up with solutions for the problems we tackle.
Snuk, one of our ventures who’s developing an IoT infrastructure platform for smart building applications, is a prime example of how leveraging different communication protocols can generate business value.
Networks such as MIOTY, which can be classed as LPWANs (similarly to LoRa and Sigfox), enable a set of use cases which are otherwise impossible — particularly where other networks have trouble reaching or in cases when only battery-powered devices are usable, making a low power consumption critical.
Initially I spend a few good hours just playing around with the kit. A couple of things stand out: the M300 dashboard, a browser based front-end for the base station, complete with a spectrogram that lights up whenever one of the nodes sends a packet and also a handy Python code example (which I later ended up using); and the serial interface for the nodes, used to talk back and forth with the devices.
For the latter, I turned to CoolTerm. Firing up messages with the nodes is actually a breeze. For example, setting the packet payload is as simple as writing DATA:SET #212DEADBEEF1234, where DEADBEEF1234 is the actual message and #212 are used to mark the beginning of the packet and describe its length. Sending TRIGGER tells the node to fire away the message. The nodes come pre-configured to the base station so the messages immediately pop up on the M300’s dashboard.
Having satisfied my curiosity, I moved on to test the range of the nodes.
To begin with, I had to fetch the packets (i.e., the messages sent by the nodes) coming into the base station. Using the example script, I’m able to set up a TCP socket to the M300 and easily get all the data in neatly packed JSONs.
Besides the actual data payload, the M300 also sends a bunch of useful information. I’m particularly interested in the signalLevel and noiseLevel, which can be used to calculate the SNR value; which in turn is indicative of the radio signal quality reaching the base station.
I’m using the SNR to plot out how the signal degrades over distance. In order to do this, I set up an InfluxDB instance where all the data coming in from the M300 is to be sent.
Then, for visualization, I plug in Grafana a to the database and plot out the values for the SNR.
Here’s how the whole thing looks like.
Architecture of the test setup
Quite simply, the MIOTY node (on the left) sends data to the base station, which is connected over Ethernet to our internal network. Then, a script running on an Intel NUC (a desktop PC with a nice form factor) polls the base station for new messages from the nodes, and forwards them to the InfluxDB database. Grafana is then able to read that data from InfluxDB and plot it.
Lastly, I needed to be able to access Grafana outside of our network to check if the packets were coming in, so I set up ngrok in the NUC, pointing at Grafana’s port.
Having set up the base station by our office window, I set out to test the node’s range.
The nodes come with a handy feature — each time they’re turned on, a test packet is sent on a 5 seconds cycle. This periodic signal makes it perfect to identify when a transmission is not picked up by the base station.
Having set up the base station by our office window I started testing the node’s range. I turned on one of the nodes, walked out of the office and took photos regularly, in order to timestamp locations as I progressed.
Below are the results as plotted out on Grafana. Each dot represents a message sent by the MIOTY node and received by the base station, and each photo matches the location and point in time where the signal was sent.
A plot of the SNR values as distance from the base station increased
Google Maps tells me the total range achieved by the node was 800 meters, albeit with quite a few packet losses at that point.
Considering the lack of a direct line of sight and the amount of buildings between the node and the base station plus the poor weather, the results are pretty decent. There certainly seems to be a lot of room to increase this range by, for example, moving the M300 to a higher point (the building’s roof would’ve been ideal) or changing the antenna.
The next goal was to build a connected temperature and humidity sensor supported by MIOTY, which could be used in a location where we wouldn’t be able to use otherwise.
The location chosen for this test was our building’s basement. This was ideal because 1) our Wi-fi can’t reach the basement so the MIOTY node is actually filling a gap and 2) I could easily power the device.
As the nodes come with a USB interface, the easiest way to build this proof-of-concept was to use a Raspberry Pi.
Then I wrote a simple Python script (let’s call it the Message Pusher) that gets sensor measurements every 5 seconds, packages them for the MIOTY node and triggers a transmission. I’ve also added the script to .bashrc, so it runs every time the Raspberry is booted up, which comes in handy as I can’t really SSH into the Raspberry without a network connection.
The architecture is pretty much the same as before, except with the additional attachments to the MIOTY node.
Here’s how all that looks like.
A plot of the SNR values as distance from the base station increased
And here’s the actual live thing.
The actual live thing.
On the NUC’s side, I adapted the handler in order to unpack the sensor data and publish it to InfluxDB. I then added two charts on Grafana to display both temperature and humidity readings.
Firstly I took some measurements in our office, using the setup next to the base station. I then took it to the basement and let it take more readings for a while. Here are the results from Grafana.
Until around 17.00, while the sensor was still in the office, the readings and the SNR values remained somewhat constant.
At that time, I took the device to the basement and turned it back on. As expected, there’s an immediate drop in the SNR, which then remains fairly constant.
The temperature and humidity sensor takes about 10 mins to ease into the new environment, settling in at 18º C and 54% relative humidity, contrasting the 24º and 39% RH measured inside the office. Predictably, the basement is considerably cooler and more humid.
As a transmitter, the MIOTY node works flawlessly. No packets at all were lost during testing—the gaps shown on the plot in the earlier measurements were due to me rebooting the Pi quite often.
The MIOTY system was delightfully easy to work with and proved to be a viable tool with the potential to fit our tech stack in a lot of use cases, as shown in the examples above.
It poses a very interesting alternative to other LPWANs, as the technology is agnostic to the hardware it runs on (unlike, for example, LoRa, which runs exclusively on Semtech licensed chips). The protocol also boasts superior interference immunity, though that might prove a bit harder to test.
My impressions from the two days I’ve spent at a ‘un’-conference
Innovation - is it an art or a science? We say that it is both....
In this blog article, will go through the most important preprocessing step when analysing time...