Science Experiment: A Semi-Technical Lowdown on Working with iBeacons

There’s a lot of buzz surrounding Low Energy Bluetooth Beacons, also known as iBeacons. They’re the first mainstream technology to provide indoor location information to phones, and they’ve opened up an explosion of possible applications for nonprofits.

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.

To keep things simple, I’ll 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 the apps you have installed on your phone that can use your location information, not the beacons. You can also turn off the Bluetooth or location services 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-0.7 feet), near (0.5-6.5 feet), or far (6.5 – 230 feet).

Science Experiment

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

metalinterference.jpgMost 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 that we intended to use 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. (See image above, our metal interference).

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.

Average Signal Strength Reading by Distance and Interference Type

avgsignalstrength_distanceinterference.p  

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.

Average Signal Strength by Distance and Device

avgsignalstrength_device.preview.png  

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.

recordingbeaconstrengths.png  

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:

Raw Signal Strength

rawsignalstrength.jpg  

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 7 seconds in which the phone read the 15-foot beacon as being closer.

3 Second Rolling Average

3secondrollingavg.jpg 

Here we’re using a rolling average of 3 seconds. The signal looks a lot less jittery. There were only 3 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 reduces 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.

Potential nonprofit applications

Working with the beacons has been exciting. The technology is young, but it feels like the first steps towards an important breakthrough in using technology to connect people to the world around them. There’s an endless number of potential beacon ideas for nonprofits. Here are some of my favorites:

  • Museums & Art Galleries
    There are already apps that provide audio tours and additional content for museums, but many of them require users to press numbers or following a rigid path to know where they are. Not anymore! Beacons have the possibility to take these apps to a new level.

    A beacon-based app could show users where they are in the museum, and use that to guide their audio tour or provide extra content. The app could even incorporate challenges to encourage users to explore the entire museum.

    Because of the issues I talked about earlier, there isn’t the level of accuracy required to determine exactly which piece of art the user is standing in front of, but they can certainly determine the region or room.

    I’ve had the opportunity to build a prototype of just such an application. It’s called “Exhibit” and the source code can be found here. Feel free to take a look.

  • Volunteer check-in
    One feature I haven’t mentioned is that any device that can read a beacon also has the ability to become a beacon.

    A great application of this could be a two-way volunteer check-in application. The organizer’s device would become a beacon that would act as a volunteer check-in point. This would enable hassle-free check-in for volunteers while still verifying that they’re at the site.

These ideas are just scraping the surface. 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 for nonprofits? Have you worked with beacons and have anything to add? Let us know your feedback!

Shane Russell
Software Developer Consultant
ThoughtWorks