With Eddystone™, the new beacon format from Google, developers making beacon-enabled apps now have more options than ever. If you’re looking to build a new beacon-enabled app, or if you already have beacon apps, it’s important to understand what Eddystone can do.

What is Eddystone?

Eddystone has significant differences from the other major standards. The first Bluetooth LE beacon type to gain popularity was the Apple-proprietary iBeacon™ standard starting in late 2013. It has since been joined by the open-source AltBeacon standard and the various, closed proprietary systems. Now Eddystone adds yet another open source standard to the mix.

Since all of these beacon types are based on Bluetooth LE, they all have a similar radio range of up to 50 meters. Where they start to differ is in how you use them. All of these beacon types work on iOS, but Apple provides no official support for iBeacon on the Android platform. The AltBeacon standard adds that official support through a beacon standard that is open source and cross-platform.

The new Eddystone standard doesn’t provide the same iBeacon interoperability, because the identifier layout of Eddystone is incompatible with the iBeacon standard. Where both iBeacon and AltBeacon use a three-part identifier that totals 20 bytes, Eddystone uses a two-part identifier totalling only 16 bytes. This can make it tricky to use Eddystone alongside existing or new iBeacon-based systems. This decision, however, allows Google to put some innovative capabilities into Eddystone.

Multi-Beacon Capability

Eddystone supports the concept of telemetry, a special type of beacon transmission that contains metadata about how the beacon is operating. This includes both battery level and temperature.

Eddystone also supports the multi-beacon concept. This means that a single hardware beacon sends out multiple transmissions that can be used independently. The telemetry packet transmission, separate from the main identifier packet, is one example of this. While Google is not the first company to invent multi-beacons (Radius Networks developed an iBeacon/AltBeacon interleaving model over a year ago), it is the first one to combine multi-beacons into a single standard.

The multi-beacon consists of three separate beacon frames:

• Eddystone-UID. This is the main transmission and consists of a two part identifier (10 bytes for the namespace and 6 bytes for the instance) as well as a one-byte transmitter power calibration value, which is used for distance estimates.
• Eddystone-TLM. This contains telemetry information including the packet version (always a one-byte value of 0 for now), the beacon temperature (2 bytes), the beacon battery level (2 bytes), the number of seconds the beacon has been powered (2 bytes) and the number of “PDU” packet transmissions the beacon has sent (2 bytes.)
• Eddystone-URL. This is an alternative transmission to the Eddystone-UID that sends out a compressed 17 byte URL instead of a numeric identifier. The idea is that an app detecting the beacon can go directly to this URL without the app having to convert a beacon numeric identifier to destination web address. This Eddystone frame is the new replacement for the existing URI Beacon, an open standard also sponsored by Google.

In addition to the above, Eddystone actually uses a fourth frame, which is a standard iBeacon frame. The primary purpose of this frame is so Eddystone can leverage the iBeacon standard’s special ability to wake up iOS apps in the background, at which time they can start consuming the three frames above. That said, there’s nothing stopping you from using the iBeacon frame for your own purposes.

Choosing Which Frames to Use

Not all of these frames have to be used at the same time. In fact, beacons based on Eddystone can be configured to turn off some of these frames to save battery power or reduce noise.

The first choice you probably want to make is whether you want to use the Eddystone-URL capability. The main advantage of Eddystone-URL is that it allows you to build your app and then have completely different people deploy beacons that send your app to specific URLs. If this capability matches your use case, then it is a good choice. For more general beacon use cases you probably want to stick to Eddystone-UID.

With that decision out of the way, you can decide whether you want to use telemetry. Eddystone-TLM typically isn’t transmitted as often as the other frames—about once per second. It therefore has less of an impact on battery and radio noise. If you know you won’t be using telemetry, you can always disable it.

Setting Your Beacon Identifiers

Eddystone has a two part identifier that consists of a 10 byte namespace identifier and a 6 byte instance identifier. You typically use the namespace ID to signify your company or organization, so you know when a beacon is yours.

You can generate a namespace identifier with a UUID generator. But because standard UUIDs are 16 byte identifiers and namespace identifiers are only 10 bytes, you drop the middle six bytes from the UUID. This technique is especially useful if you already have an iBeacon Proximity UUID assigned for your company or organization, allowing you to use an equivalent organizational identifier for both formats. Below is an example of such a conversion.

iBeacon Proximity UUID:  2f234454-cf6d-4a0f-adf2-f4911ba9ffa6
Eddystone Namespace ID:  0x2f234454f4911ba9ffa6

Google also prescribes a second technique for generating a UID out of a URL. So you can algorithmically convert a domain name you own like http://www.radiusnetworks.com into a unique namespace id. Because this technique uses a one way hashing algorithm, there is no way to convert the namespace id back to a URL. You can use tools like RadBeacon Android to generate namespace identifiers from both URLs and UUIDs, and configure the field directly into the beacon.

The instance identifier is meant to uniquely identify a specific beacon. You usually will want to put a serial number in each one of these. If you have two beacons, you can give the first one an instance id of 1, and the second one an instance id of 2. Because the field is 6 bytes long (48 bits), there are 2⁴⁸ = 281 trillion combinations. That’s a lot of beacons.

For the purposes of this example, we will assume that the beacon is using a namespace ID of 0x2f234454f4911ba9ffa6 (the Radius Networks default) and an instance id of 1. These are the same identifiers that are pre-configure into the Beacons with ship with Eddystone support.

Getting Beacons

If you want to get started with Eddystone, you can buy a developer kit that includes hardware beacons from our Radius Networks store. These beacons can be configured with our free Android RadBeacon config app, which allows you to set the identifiers and URL (in case you are using Eddystone-URL) and set transmitter power and other options.

Building Apps

To learn more details about how you can build an app with Eddystone, see our companion post Building Apps With Eddystone.

Visit us here to access to more Radius Networks products that support Eddystone.