In a recent collaborative research project, I have been applying the use of iBeacons to narrative apps that detect the position of a user within a museum. This is what I’ve discovered so far.
What is an iBeacon?
iBeacons are small hardware devices that emit a radio signal that can be detected by iPhones and iPads running iOS7. The signal adheres to a particular flavour of the BTLE (Bluetooth Low Energy) Protocol, which has been adopted and customised by Apple.
The devices are really quite small (no more than a couple of inches long), cheap, and use very little power, meaning they can last for up to two years using a small coin battery like those found in wristwatches.
By making an iOS device able to detect the proximity of an iBeacon, Apple has enabled developers to add context-specific events to their apps. The primary sector for this is retail. Shops can now produce apps that deliver specific information about products as you wander around their stores.
Instead of retail, I’ve been working with researcher Emma Whittaker on a way to apply the use of iBeacons within the culture and heritage sectors. Doing so allows us to produce interactive narrative experiences within museums and public buildings that previously required the installation of intrusive specialist equipment.
What We’re Doing With Them
Emma is developing virtual sound environments and tying these into a game that can be played inside the museum, using visitor’s own mobile phones. What we’ve been looking at is getting an app to detect which room of the museum the visitor is currently in, in order to trigger certain events within the game.
The technology is quite new, and getting hold of beacons right now that work directly with Apple’s protocol is not as easy as you’d think, although more and more manufacturers are popping up out of the woodwork. I got mine by joining a group on LinkedIn and asking if there was anyone local who wanted to sell me some. In the end I went with a guy called Jose at Metavurt who has been very responsive, reliable and helpful.
Here’s what they looked like when they arrived. Not exactly pretty, but they work just fine:
Setting Them Up
You configure iBeacons over-the-air using an app on your phone. There are a few out there, I used one called LightBlue which a lot of people seem to recommend.
There are three main parameters that you can set – ‘UUID’, ‘Major’ and ‘Minor’.
UUID stands for Universally Unique Identifier (an oxymoron if ever I heard one) and is used to associate all your iBeacons with your business or organisation. It’s 32 characters long and you have to generate one using a terminal command on your computer. This prevents other people from messing around with your iBeacons for their own dark purposes I guess. When programming the app, you also have to use the UUID to state which iBeacons you are looking for.
Major and Minor are numbers that you can use to create a hierarchy within your iBeacons. A suggested use for this is that Major can be used to specify a particular building and Minor would identify rooms within that building.
LightBlue lets you set all these, although everything is displayed in hexadecimal (even though Major and Minor are specified using plain old decimal when programming the app), which takes a bit of getting used to.
I found this website useful for converting ‘normal’ numbers to hexadecimal.
Once this has been done, you can develop an app that does things when it gets near any of your beacons, a particular building, or an individual room.
As well as transmitting UUID, Major and Minor identifiers, there are a couple of other things that can be read in relating to proximity: ‘RSSI’, and ‘Proximity’.
RSSI is the raw ‘Received Signal Strength Indicator’, in other words the strength of the radio signal being picked up by your device. The nearer you get to the iBeacon, the stronger the signal becomes, although it is in reality quite erratic and effected by all sorts of environmental factors.
Proximity uses an algorithm that attempts to filter out some of the idiosyncrasies of RSSI and give you something a bit more concrete to work with. What you end up with are three states – ‘Immediate’, ‘Near’ and ‘Far’. Immediate tends to get triggered when the device is touching the iBeacon, Near relates to standing next to it, and Far has a much wider radius.
These can be used to prioritise between beacons if you are picking up more than one at a time, or make proximity-based events (Using Immediate as a trigger has obvious parallels with NFC)
The following is based on initial sessions that took place in Plymouth City Museum and Art Gallery, using the beacons mentioned above, on an iPhone 5.
I was hoping that RSSI could be used to detect a fairly specific location within a room by placing a grid of beacons at 1m intervals. It turns out that this isn’t really possible as the readings fly around all over the place. Proximity is too slow and unresponsive for this purpose as well. People have looked into trying to position the user using trilateration (what your phone does outside using Wifi hotspots and phone masts when there is no GPS available) and for the same reason, this doesn’t work either.
The proximity property has about a five second lag between you actually moving and the change being detected on the device. This is presumably because the algorithm takes a sample of RSSI readings and then works out an average. This might be fine for someone entering a shop (they would arguably need a few moments to take in their surroundings) but not so good if you need a more speedy response.
Immediate is almost touching the iBeacon. Near has a radius of approximately 1 metre . Far is much larger; about a 10 metre radius. If these increments are no good to you, then you would have to write your own algorithm using the raw RSSI.
The signal can be partially blocked by solid objects, including people, which alters the RSSI and proximity readings.
Even when using proximity, the readings would drop out and jump around from time to time. So these states are good for detecting periodic events, but not so good for continual monitoring without some sort of further filtering.
Curiously, the signal is also affected by height in relation to the device. The least accurate readings were given if the iBeacons were placed on the floor. Placing them within cabinets at waist height (where you would normally hold your phone when in use) gave the best readings. Putting the iBeacons higher up also seemed to be okay, but not as good as waist height. Something to do with the placement of the BlueTooth receiver in the device perhaps?
Using iBeacons on a room-by-room basis was by far the most successful outcome. A fair bit of trial and error was needed to find the perfect spot to place each beacon, dependent on size, shape and contents of room.
Although not quite as versatile as I’d first hoped, there is still quite a bit of scope in terms of what iBeacons could enable within indoor mobile experiences. In particular, the fact that they are cheap, can be installed with a minimum of fuss and work with phones that people carry about with them by default, means that even small organisations can consider using them as part of their visitor ‘package’.
How are we planning to use them in particular? Well… here is a screenshot of an early app prototype: