Picture this: there’s someone walking around with an iPad held up to their face, in a similar way to somebody else who is about to step in front of a bus. Meanwhile, another is frantically clicking refresh in his browser like he’s trying to buy tickets to see Madonna. You wouldn’t guess that they are pushing the limits of the cool new technology on the block, Apples iBeacon.
The above quite accurately describes what was going down in our offices last week during our latest hackathon. We set out to learn more about Apple’s newest innovation: iBeacons. They are like little lighthouses that help an App position itself within its’ environment. By using the unique identification number the iBeacon broadcasts (called a UUID) the App can check where it is in the world. The iBeacon specification identifies three states of proximity: immediate (within half a meter), near (a couple of meters), far (between a couple of meters and approx. 30 meters) and unknown (close enough to detect, but unable to measure with confidence).
iBeacon is based on Bluetooth Low Energy (BLE), which has been used in devices since the iPhone 4S and iPad 3, as well as on some Android devices that run Android 4.3 and later. In this way there is nothing in essence stopping an Android device from detecting an iBeacon and joining the party. Companies like the one that produce the Estimote are already offering a hybrid solution that supports both the iBeacon protocol and custom implementations running on BLE. As mentioned before, distance to the iBeacon comes in three flavors as handled by the iOS SDK, but it’s also possible to tap into the raw measurement of the signals’ strength where you then end up with an approximate distance to the iBeacon in meters. It occurred to us that given three of these measurements we could calculate the users’ position through trilateration (that’s essentially what GPS does). The idea for the hackathon was thus born and all there was left to do was rolling up our sleeves and get cracking.
Setting up our iBeacon Hackathon
Getting started, we first cordoned off an area of the office and laid down a grid on the floor with tape. We then put iPads in three of the four corners, which were running an app we created to let them pretend to be iBeacons. After noting their exact position relative to the grid we could start work on our front- and back-end implementation.
The idea is simple enough: have an App detect iBeacons, measure signal strength and send this information to a back-end. The back-end in turn must take these values and calculate a position inside the grid for this user. To visualize it all we build a basic web page that can query the back-end and display the location of every user.
Lies! Damned lies and signal strength…
It became clear quite quickly that BLE signal strength is very erratic. At least at the scale we were working on (an area roughly 7×7 meters) the readings jumped up and down, drifted left and right, in short they behaved exactly as the laws of physics dictate inside the electromagnetic soup we call our office. We hoped that Apple’s usual magic may have had a more profound positive effect in this matter, but alas. So remember, it isn’t your haphazard implementation, it is not your fault. Knowing this, we figured the magic should come from the back-end in terms of smoothing the readings. But before getting there we needed to focus on trilateration in general. Trilateration means that you can determine your position when you know your distance from three points, as shown in this image.
Knowing the distance from just one point means you can be anywhere on a circle around that point. Add another point and you could be at either intersection between two of such circles. A third point is needed to create a single intersection, and thus a definite position. Combine this with inaccurate measurements and you need to put some nifty formulae to work to get a sensible result. In our frenzy to get this working we connected the back-end to the Mathematica toolset which can make this calculation as a convenient one-liner. Ultimately, we dropped Mathematica from our solution because interfacing with the toolset was proving more cumbersome than we had hoped. Instead we focused on doing the calculation ourselves.
Works like a charm… if you’re an astronaut
However if you live on the same planet as we do with pesky colleagues, walls, plants, furniture and devices all interfering, it does not deliver what was promised on the box. It isn’t the missing link in indoor location with 2 inch accuracy but can give you a general idea if you’re close, near or far when used in a real life scenario. It is however useful for indoor geofencing in large spaces.
Going forward we will see many forms of iBeacon pop-up: the vanilla iBeacons by Apple, the hybrid type such as Estimote and many more companies will no doubt follow suit. These all operate on the ‘passive’ principle, which means they only send their UUID but are not programmed to react to the users’ device in any way. Contrast this with an ‘interactive’ principle where the device posing as an iBeacon can be made to do something based on the actions of the user. Be it activating a light, or maybe changing its’ UUID so that the users’ App can react differently at the same location. It looks like we have only begun to scratch the surface of what is possible with this new set of technologies. Apple putting their weight behind this is a sure sign that ‘the world’ is finally ready to put it to practical use on a wide scale. We have every intention to keep at the forefront of this development. Follow us on twitter and we’ll be sure to keep you posted.