Beacons-in-motion and a microlocation service. Interesting connection of both. We have given it a try and made an experiment. How did this work? Let's see!

Beacons are nothing new, right?

Chances are that you have already heard about the beacon standard. It has already been on the market for some time. The whole thing is based on devices using the Bluetooth Low Energy 4.0 standard and broadcasting signals which can then be received by other devices located nearby. Beacons open up a variety of use cases that have not been available so far at that cost and scale.

We have already used beacons in a way they were designed for - our implementation was a mobile application processing signals from beacons at a conference venue. You can read about the case on our blog (3DP Raspberry Pi and iBeacon voting machines for Confitura 2014 and iOS/Android iBeacon app for Confitura 2014). SoftwareMill has even organized an internal hackaton during which we were playing with iBeacon devices.

Recently, we have been working on a microlocation service based on beacons moving around and having receivers put in fixed places.

Hardware used

In the experiment, we used three different beacon devices. We were curious how they work and simply wanted to check which one bests suits a given scenario. The devices were a Card Beacon from kontakt.io, an Estimote Sticker and an Estimote location beacon.

The location was computed in a rather small office with 4 rooms. Every room was equipped with a Raspberry Pi 3 device. It has built-in support for BLE so there was no need to add an external bluetooth receiver or dongle.

What is the location, anyway?

And here is a demo of location detection:

How it works

In terms of the algorithm, keep in mind that a beacon signal can be reached at a distance of up to 100 meters. In an office it is less due to walls, doors and other obstacles like cats and - obviously - people. The human body blocks Bluetooth radio signals quite well, because it is mostly made up of water.

On the other hand, though, the signal is strong enough to be received by all four Raspberry Pi devices due to the small dimensions of the office. That makes it a little bit more difficult to determine in which room a beacon is present at a given moment.

The algorithm was based on a fixed time window, which in our case was 4 seconds. During that time we collected the beacon signals from all Raspberry Pi devices. The signal readings were stronger from a closer RPi device and weaker for the other RPi devices. After that period, we counted the average strength of the beacon signal received by each RPi device. The device with the highest average was the one we chose to present on the map as the current beacon location. This simply translates to highlighting the room where the given RPi device was placed.

A further improvement to this algorithm was the computation of a moving average instead of a plain one. Again, we collected all the signals, but this time we applied weighting factors to them when summing up. Older signals got a penalty, whereas newer signals were promoted. As a result, the location of a beacon was calculated more accurately when moving from one room to another.

However, we still had to tackle various behaviours of beacon devices which were a bit hard to embrace with a single, unified algorithm. Variations in the behaviour, presented in the next section~, resulted from different signal characteristics of the devices. Is it bad? Not at all. This simply means each device type should be used in a scenario where a given signal characteristic is suitable.

Going back to our improved results, we still see more tweaks that could be employed at this stage. One of them is adjusting the power of a beacon broadcast signal. The other one could be the use of trilateration or even neural networks as described by Adam Warski in Inverse beacon positioning.

Beacon devices types

The Estimote location beacon and Kontakt.io’s card beacon transmit several signals per second, more or less at a constant rate. Therefore, our algorithm with weighted factors performed just great in determining the beacon's location. Especially moving from room to room gave us good numbers resulting in smooth updates in the user interface.

We tested Estimote Stickers as well and the device turned out to be a quite interesting one. Typically it sends a signal every 10 - 13 seconds, but sometimes it waits even longer, up to 50 seconds. However, if you move it, a built-in accelerometer will trigger the sender and during the next 2-3 seconds we receive 2 signals. This means that it is perfect for the use case when you have something that you expect to be stationary most of the time. You can attach it e.g. to a drip in a hospital and get notified when it starts to move.

The fact that the signal characteristics of various devices used in our location experiment are different, shows that each of them is suitable for slightly different use cases. See specific examples in the summary below.

It is cool!

A few years ago, employing beacons as static signal broadcasters opened plenty of possibilities in retail or gastronomy. We think that changing beacons into moving devices attached to humans and/or movable equipment gives way more opportunities and makes this technology even more interesting than it seemed a couple of years ago.

So, where could beacons-in-motion be useful:

• indoor location detection may be a good fit for the healthcare area (e.g. hospitals or nursing homes) and all three beacon types we have tested in our experiment could be used there,
• kontakt.io and sticker beacons could be applied in a warehouse location system - the staff working there could wear cards, while every equipment used by them would have stickers attached,
• indoor security is yet another example where kontakt.io cards could be useful in terms of tracking a path passed by a guard, sending notifications of places to check, and, thanks to embedded RFID, access control to restricted areas.

And your idea of course. Do you have something in mind? We will make it happen. Just contact us!