iBeacons
What is it?
iBeacon is an extension to Apple’s Location Services that provides a measurement of the proximity of the IOS device to a device that is broadcasting its presence with Bluetooth LE.
So before we continue with iBeacons, we need to take a step back and discuss Bluetooth LE.
Bluetooth LE
Bluetooth LE is a an extension to the overall Bluetooth protocol which is intended to enable devices to be able to transmit small payloads with Low Energy (LE) requirements. By low energy, we mean devices that can potentially operate off a coin battery for up to 4 years.
Bluetooth LE is able to achieve this energy efficiency by keeping payloads small, using “connectionless” broadcasting of advertising packets (similar to normal Bluetooth discovery mode), and enabling lightweight (3ms) handshakes when connections are necessary.
This protocol allows devices to broadcast small bits of information. Possibilities are endless, but here are some examples:
| Sensors Broadcasting Readings | Devices Broadcasting Status | Controllers Issuing Commands |
|
|
|
This isn’t necessarily a new concept. The ANT+ protocol has provided a low energy data transmission protocol that has been used for years. For example, companies like Polar and Garmin have for several years used ANT+ to transmit heart rate from a coin battery operated sensor that athletes where on a chest strap to a watch, bike computer, or ... smart-phone.
Bluetooth LE is likely to displace many such ANT+ implementations, due to the simple fact that many devices (such as mobile phones) already have Bluetooth antennas and radios, while ANT+ radios and antennas are generally add-ons.
Often the data being broadcast by these low powered devices will be useful to aggregate by web services into servers and databases in the Internet cloud. But since these low energy devices can’t directly communicate to those web services, IOS devices (and other Bluetooth-enabled devices that also have wired or wireless internet connections) will inevitably act as gateways to between these low energy devices and the larger Internet.
Back to iBeacons
As mentioned above, iBeacon is Apple’s implementation of Bluetooth LE for proximity. And although it’s Apple’s implementation, it’s worth noting that there’s not really anything closed or proprietary about it, and thus Android and other development platforms that have Bluetooth LE stacks can also implement fully compatible receivers of iBeacon proximity broadcasts.
In many ways, iBeacon is Apple’s answer to NFC. With greater range and flexibility, together with the fact that no additional hardware needs to be deployed in the device (since that Bluetooth radio and antenna is already present), any folks surmise that iBeacon might be an “NFC-killer” … at least in the Apple’s eco-system.
So an iBeacon is simply a device that broadcasts in Bluetooth LE. But unlike all the examples of payloads mentioned above, these devices simply broadcast their existence and identity.
“iBeacon E2C56DB5-DFFB-48D2-B060-D0F5A71096E0 here!”
“iBeacon E2C56DB5-DFFB-48D2-B060-D0F5A71096E0 here!”
“iBeacon E2C56DB5-DFFB-48D2-B060-D0F5A71096E0 here!”
An iBeacon will repeatedly broadcast the same advertising packet over and over. More specifically, it will broadcast 31 bytes that break down like this:
| Sample Data | Description |
| 02 01 06 1A FF 4C 00 02 15 | Fixed iBeacon prefix (note: 1A indicates LE General Discoverable Mode; 4C 00 is Apple’s company identifier) |
| B9 40 7F 30 F5 F8 46 6E AF F9 25 55 6B 57 FE 6D | Proximity UUID |
| 00 49 | Major (available for developer use) |
| 00 0A | Minor (available for developer use) |
| C5 | TX Measured power (2’s complement) |
We used 2 different UUIDs to establish two different kinds of iBeacons (so that we could range and monitor them differently) and then used the Major/Minor number to distinguish between individual iBeacons. But more on that later.
The TX Measured power is a value that indicates the strength of the signal at a 1 meter distance from the iBeacon. The receiving device (IOS device) then compares this to the measured signal strength, and is then able to estimate the distance between the iBeacon and the IOS device. A signal value that is weaker than the TX value would suggest that distance is greater than 1 meter, and an approximation can be calculated. Apple abstracts this calculation in their iBeacon Stack, exposing a simple scale with “Immediate”, “Near”, “Far”, or providing a estimated distance value in meters.
It is important that the iBeacon device is calibrated to determine the appropriate TX value. Apple AirLocate app can assist with calibration by allowing you to physically stand 1 meter from the iBeacon and measure the signal strength. In our experience, there could be several factors affecting calibration (but we haven’t been able to verify this):
- Brand/model of Bluetooth radio/antenna
- Nature of surroundings (inside vs. outside, type of materials in the area)
- Density of surroundings (it seemed like open space was different than a room full of people)
IOS Device Support
Here are the requirements for iBeacon support on IOS devices:
- iOS 7 or later
- iPhone 4s or later
- iPad (3rd generation) or later
- iPad mini (1st generation) or later
- iPod touch (5th generation) or later
A Few Words about iBeacon UUIDs
As noted above, iBeacons are identified by UUIDs. We used some generic UUIDs that are often used in sample code and other developer tools (such as Apple’s utility app Air Locate). We used a total of 8 iBeacons and set them up as two different UUIDs (so that we could range and monitor them differently on the IOS device):
- Claim Beacons:
E2C56DB5-DFFB-48D2-B060-D0F5A71096E0with Major/Minor 1-6 to further distinguish - Bar Beacon(s):
5A4BCFCE-174E-4BAC-A814-092E77F6B7E5with Major/Minor number not used
Here is a list of the 8 “developer” UUIDs:
E2C56DB5-DFFB-48D2-B060-D0F5A71096E05A4BCFCE-174E-4BAC-A814-092E77F6B7E574278BDA-B644-4520-8F0C-720EAF059935112ebb9d-b8c9-4abd-9eb3-43578bf86a4122a17b43-552a-4482-865f-597d4c10bacc33d8e127-4e58-485b-bee7-266526d8ecb244f506a4-b778-4c4e-8522-157aac0efabd552452fe-f374-47c4-bfad-9ea4165e1bd9
It was helpful to use “developer” UUIDs because we could use other tools (like Apple’s AirLocate) to assist with testing, calibrating, etc. In fact, this became very helpful when we submitted the app for Apple’s review, because they were able to test our app without us having to send them iBeacon hardware. For normal commercial use, however, it is expected that devlopers would use their own UUIDs ... and we also hope that Apple relaxes the app review process, because sending them iBeacon hardware to test with seems quite onerous.
More on UUIDs: A Registry?
While we were developing, we thought it would be helpful to have a iBeacon registry - similar to DNS - that would enable the following:
- iBeacon deployment can be made “public”, by essentially advertising where they are (and what type of information they broadcast)
- Enable developers to streamline UUID management (rather than hardcode, which is what we would up doing)
- Enable developers to write applications that leverage what will undoubtedly by a growing population of deployed iBeacons
Since iBeacons can be used for very different things, such a solutions are likely to evolve in a vertical manner. An obvious vertical that many pundits are anticipating is Retail Merchandising.
But here at Objectlab, we’re really hoping for a registry of all the venues with Bar Beacons!
Raspberry Pi as iBeacon
So when we began our Holiday Party Game project, we originally looked at buying prefabricated iBeacons from a company such as Estimote, which sells them for as little as $10 each. But the lead time for delivery was too long for our purposes.
Meanwhile, a few of us had the Raspberry Pi ($40), and we soon learned that it was relatively easy to add a Bluetooth dongle ($10) and configure it to be an iBeacon. We even ordered up a Raspberry Pi from Radius Networks that came pre-configured to be an iBeacon.
For those of you who may not be familiar with it, the Raspberry Pi is a low cost computer originally designed for educational purposes. But it’s also very useful for prototyping or simulating devices that will increasingly become the “Internet of Things”. And so we set about the other 7 Raspberry Pi computers as iBeacons.
Fortunately, configuring a Raspberry PI to be an iBeacon is both simply and fairly well-documented in a few blogs online. Rather than regurgitate that here, I will merely summarize and offer some links to more detailed references.
The steps included:
- Flash a SD Card with Rasbian
- Install BlueZ drivers (to support Bluetooth)
- Start BlueZ Bluetooth
- Establish a config file with the UUID, Major/Minor numbers (and a default TX value)
- Instruct the BlueZ drivers to begin advertising the iBeacon packet
- Use Air Locate (on IOS device) to measure signal strength at 1 meter
- Modify the config file with the new Tx value)
- Add the iBeacon advertising startup command to the boot script
Now we had Raspberry Pi devices that can be plugged into a wall or any battery pack capable of 5V (USB) power, and within 30 seconds it will be a live iBeacon.
References: