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
  • Temperature
  • Humidity
  • Tire Pressure
  • Blood Pressure
  • Barometric Pressure
  • Altitude
  • Weight
  • Ready
  • Waiting
  • Locked
  • Processing
  • In Error
  • Play
  • Stop
  • Unlock
  • Change Channel
  • Dehumidify
  • Dim lights

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):

IOS Device Support

Here are the requirements for iBeacon support on IOS devices:

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):

Here is a list of the 8 “developer” UUIDs:

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:

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:

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: