There’s a lot of buzz surrounding Low Energy Bluetooth Beacons (also known as iBeacons, but we’ll get to that later). They’re the first mainstream technology to provide indoor location information to phones, and they’ve opened up an explosion of possible applications.
But don’t get too excited.
They’re far from perfect, and have some important limitations. Over the past two weeks, a small team of us built a real-world demo iPhone app using the beacons. We wanted to share our experience with how well they perform, and how best to work with them.
Getting the terminology straight
The terminology involving these things is a bit of a mess, so I wanted to clear things up before we move on. The beacons run on Bluetooth 4.0, a cool new specification of Bluetooth. Bluetooth 4.0 introduced a feature called Bluetooth Smart, which enables light connections that use a lot less energy than traditional bluetooth connections and don’t require a cumbersome pairing process. That’s why the feature usually just goes by Bluetooth LE (Low Energy).
Apple has affectionately branded its Bluetooth LE Beacon system as iBeacon. Apple hasn’t released any hardware beacons (yet?), and “Bluetooth Low Energy Beacon” is a mouthful, so people are calling all beacons that can interact with iOS “iBeacons” – which is misleading, because Android phones can interact with them too. To make matters worse, there are a handful of different beacon manufacturers, so sometimes they’re referred to by manufacturer name. For example, we were working with Estimote Beacons.
Enough with the lingo though. I’ll keep things simple and refer to them as beacons for the rest of the article.
How do these things work?
The beacons themselves are quite dumb. They don’t do any processing, and they only periodically emit a small signal containing some unique information about themselves. What makes them special is that apps can be built to sense and react to them.
This is important because it alleviates some of the privacy concerns people have about them. It’s only apps you have installed on your phone that can use your location information, not the beacons. You can also turn bluetooth or location services off on the iPhone to prevent apps from using beacon information.
Apps use the signal strength of beacons to gauge approximately how far away they are. They can only measure proximity, though, not the direction of the beacon. The accuracy for measuring proximity is imprecise, too - the signal strength fluctuates wildly and physical objects (most importantly, bodies) have a pronounced effect on it. Estimote acknowledges this and seems to promote the idea of lumping the distance measurement into 3 tiers: immediate (0-2 feet), near (3-20 feet), or far (20+ feet).
We decided to dig a tad deeper. We ran an experiment to test how signal strength measurements responded to a variety of distances, devices, and interference levels. Here’s what we discovered:
The recorded RSSI values ranged from -50 to -99 on the iPhone, and down to -110 on Android phones. Lower RSSI values correspond to a higher predicted distance between the beacon and the device. For the sake of readability, I reversed the signal strength axis on the graphs to better match this relationship.
Interference matters
Most of the time, the beacons are going to be used in a place with a lot of physical interference. We were building a retail app intended to be used in a busy store. In your average store, people are moving around, and metal walls and shelves are everywhere. We wanted to test the effect these things had on beacon readings.
We measured signal strength (RSSI) recordings over the course of a minute under three different conditions: 1) no interference, 2) a person walking between the beacon and the phone, and 3) a thin metal plate between the beacon and the phone. We found that recordings taken under interference registered around 10 feet further away at close distances.
We used this to our advantage. We strategically placed the beacons against metal walls to “guard” the signal from regions they didn’t represent.
Not all phones read beacon signals the same
Android support for the beacons is far less mature than in iOS, but it’s still possible. We tested signal readings on two Android devices, the Nexus 4 and Samsung S3, as well as the iPhone 5.
Our readings for the two Android phones was far less stable than for the iPhone. The two Android phones didn’t always read a higher signal strength as the beacons got closer, which isn’t good. The Samsung S3 recorded weaker signal strengths across the board. A signal strength to distance conversion that’s consistent across Android devices appears to be a difficult task at the moment.
Additionally, our team had some trouble working with the Estimote Android API. Their API is closed source and has only been available for a few months, so there is a big difference in the functionality available to Android developers compared to iOS developers. Estimote was open to answering our questions, but we found that another beacon development company, Radius Networks, had recently released their own open-source API. We were able to port a beacon demo application Estimote developed so that it worked with Radius Networks’ API. Our app worked well with the Estimote beacons we had, and we plan to contribute to the open-source API in the future.
Smoothing the signal
If the signal fluctuates so much, is it even possible to get a more accurate reading? Enter the realm of signal smoothing. We decided to start off with a simple approach.
We started with the technique of using a rolling average. Instead of relying on just the current reading, you take into account your past readings as well. This will make rogue readings a bit less drastic. I’ll try and illustrate it with an example:
These are the readings from a beacon 10 feet away and a beacon 15 feet away over the course of a minute. In a perfect world, the reading for the 10 foot beacon would always be higher than the 15 foot one. As you can see, it’s not. There are seven seconds in which the phone read the 15 foot beacon as being closer.
Here we’re using a rolling average of three seconds. The signal looks a lot less jittery. There were only three seconds in which the 20 foot beacon registered as closer. That’s over 50 percent more accurate!
Unfortunately, there’s a tradeoff to using a rolling average. It introduces a delay when the device is moving. The more time computed in the rolling average, the longer it will take to correctly update the distance. We played around with the algorithm until the delay and accuracy of our application felt right. We landed on using a weighted rolling average of 5 seconds. Weighted rolling average is a tweaked version of the algorithm that reduce the delay by weighting newer readings more heavily.
Another way to get a more accurate reading is to use multiple beacons to define a region. This allows your readings to gain the benefits of rolling average smoothing, without the delay. It also allows your regions to take on larger and more irregular shapes. The downside is that it requires more beacons. We were in short supply, so we didn’t end up pursuing this technique.
No fancy stuff works in the background
There’s one caveat to all this fancy signal smoothing stuff. It requires the device to be ranging the beacons. When a device is ranging, it’s reading information about all the beacons around it every second. On iOS, ranging is only possible when the app is active, and for good reason. It’s a draining operation, and quite taxing on your battery.
The operation iOS devices can perform in the background is called monitoring. While a device is monitoring a beacon, it will activate the app in the background for around 5 seconds when the device enters or exits the range of the beacon. The range of the beacon can be altered slightly by tweaking their power level, but it’s a far cry from the accuracy you can get when ranging. The trigger isn’t immediate either, we found that it can be delayed up to 10 seconds after entering the range of a beacon.
Wrapping up
Working with the beacons has been exciting. The technology is young, but it feels like the first steps towards an important breakthrough in connecting people to the “Internet of Things”. There’s an endless number of applications for beacons. Now that you know more about how they work, you’ll have a better idea of what is and isn’t currently possible.
Have any ideas for beacon-based applications? Have you worked with beacons and have anything to add? Let us know in the comments.
Huge thanks to the iBeacon team (Vivian So, Aubrey Chipman, Elisa Cutrin, Greg Dutcher, Jeff Siver, Susana Rodriguez, James Courtois, Anastasia Belozertseva, Jered Philippon).
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.