Seeing the Light with BLE Beacons

By Mark Duncombe, Field Applications Engineer III

Bluetooth Low Energy (BLE) beacons are becoming ever more popular since Apple introduced its iBeacon specification. But there is far more to BLE beacons than just Apple’s iBeacon. A beacon in general BLE terms is simply a device that broadcasts a BLE advert that can provide location context for mobile device applications.

iBeacons are currently the most well-known form of BLE. However, an iBeacon is ultimately just a BLE advert delivered in an Apple-specific format that complies with the existing BTv4.0 specification. Therefore, all iBeacons are BLE adverts, but not all BLE adverts are iBeacons. Other beacon formats include AltBeacon by Radius networks, URIBeacon from the Physical Web project, and Eddystone™, an open source beacon format from Google. Any developer considering beacons in their application would be advised to consider other beacon types alongside Apple’s iBeacon. In particular, Eddystone deserves special attention as it adds considerable functionality and flexibility to beacon applications.

iBeacons

iBeacons consist of a BLE-enabled device that sends out Apple’s Manufacturer Specific Advertising Record in a BLE advert.

The Bluetooth specification requires that the manufacturer specific data consists of 4 or more octets. The first octet is the overall length. The second octet shall always be 0xFF. The third and fourth octets are the manufacturer assigned Company ID for Apple Inc., and the rest is the iBeacon data. Apple’s iBeacon specification defines that the rest of the octets must be grouped as: [Datatype] [Length] [UUID] [Major] [Minor] [Calibration Power], where the UUID is 16 octets long, Major and Minor are 2 octets long, and the rest all single octets as shown below.

iBeacon Example

Let's take a simple example of how an iBeacon might be used.

UUID

The first important field for a developer working with iBeacons is the UUID. This is a number that identifies the beacon application and therefore all iBeacons related to the same application will have an identical UUID.

For example, let’s imagine a network of iBeacons in a supermarket. iBeacons installed throughout a store and indeed throughout the entire chain of stores will share a common UUID, since they share the same application. The major value of the UUID might indicate the branch of the supermarket in which the iBeacon has been installed, and the minor value might be used to indicate the location within the store of each individual beacon. The UUID (major and minor) can be thought of as lookup codes: they do not contain human recognizable information but rather a code that a smartphone application uses to look up the location, typically over the internet. Beacons can pass location data to a suitable app on a customer’s phone as they move around the store, giving the user relevant information. It is important to realize that the iBeacons are just broadcasting the location information; they are not collecting information from the customer’s phone. However the app on the phone may well be taking the location information from an iBeacon and passing it on to the supermarket’s servers.

Ranging

Also included in the iBeacon is a tx or calibration power value. Before an iBeacon is deployed, a measurement of its signal level is taken at one meter, taking into account any enclosure being used. This calibration allows a mobile device to estimate the distance to an iBeacon using the received signal strength. However, this distance should only be considered an estimate to determine if the beacon is far, near, or in the immediate vicinity, and the actual range in meters can vary due to many factors.

Eddystone™

As previously mentioned, there are other types of beacons in addition to iBeacons. Eddystone, an open source beacon from Google, expands on the location information provided by an iBeacon by using three distinct frame formats Eddystone-UID, Eddystone–URL, and Eddystone-TLM.

• Eddystone–UID - This frame format is used in a very similar way to an iBeacon. It contains an application identifier in the form of a 16 byte UUID as well as a 10 byte namespace and 6 byte instance to provide location information that can trigger an action in a mobile device app.
• Eddystone-URL - This frame format allows for a URL to be included in the beacon, albeit in a compressed form due to the advert packet size restrictions. The benefits and uses of this frame format are obvious; on receiving the beacon the mobile device can then choose to visit that URL. For example, the beacon could include a URL such as http://tiny.cc/fzd67x.
• Eddystone–TLM - This frame format allows for data about the beacon to be broadcast such as battery voltage, temperature, etc.

The three different frame types of Eddystone can be used individually or in combination with each other. Remember, just like an iBeacon, Eddystone beacons are just broadcast BLE adverts that are compliant with the Bluetooth core specification.

Use Cases

The potential use cases for beacons are endless, sometimes obvious and sometimes surprising.

The key to developing beacon applications is thinking of the beacon as a trigger that causes some action to happen on a mobile device when a user moves into a particular area. This action is only limited by your imagination and the apps on the user’s mobile device.

Laird’s Bluetooth Low Energy modules can be easily configured as any kind of beacon, including iBeacons and Eddystone beacons. The BL6xx and BT9xx series modules from Laird run smartBASIC, our structured event driven programming language, and can be used standalone without the need for an external host. In addition, LSR’s SaBLE-x provides another Bluetooth Smart solution from Laird to address low-power IoT applications that leverage BLE beaconing.

Check out these additional resources for more information:

Beacons for smartBASIC – BL600 and BT900

BL600 and BL620 smartBASIC Application Walkthrough

Specification for Eddystone  – GitHub

iBeacon for Developers