Eddystone – A Briefing Note on Google’s New Beacon Format

Warning This article was written over six months ago, and may contain outdated information.

Yesterday Google announced ‘Eddystone’, a new open Bluetooth beacon format which works on Android and iOS. I’ve been doing a bit of reading about it to understand the technology and its potential, and I put together a briefing note about it for my colleagues. I’m a believer in maximising returns on my content, so it seems like a good opportunity to republish that briefing note here.

This is a very rapid and shallow look into beacons, and I’ve no doubt made some omissions or inaccuracies, so apologies in advance for that. If you think I’ve made any huge oversights or errors, please feel free to let me know in the comments.

In a Nutshell

Eddystone is, as mentioned, an open Bluetooth beacon standard. It works on Android and iOS. It does all that some current formats – namely iBeacon and Physical Web – do, plus more. It comes with associated APIs and libraries that make it very extensible and powerful.

Branding

Although this is a Google-led initiative, they very much want this to be seen as an open standard. So the branding is just Eddystone, without mention of Google. Fun fact: It’s named after the UK’s Eddystone Lighthouse.

Opportunities

Anything based around immediate location. Google have recently run a project around live transport information in Portland, and are talking about pushing hyperlocal information into Google Now. Think about beacons in shopping centres, museums, art galleries, markets… anywhere you need passive information about the things immediately around you.

Comparing Format Standards

  • iBeacon is an Apple-only standard which transmits a single Unique Identifier (UID). Apps can use this to trigger an action.
  • Physical Web Google-led open initiative which transmits a single URL. Apps can present this to the user or look up related information from metadata.
  • Eddystone Google-led open initiative which combines features of both, plus more. Has a UID, a URL, plus Ephemeral Identifier (EID) and Telemetry (TLM) data – details on these below.

Here’s a quick comparison:

Beacon Payload Platform
iBeacon UID iOS
Physical Web URL Android, iOS
Eddystone UID, URL, EID, TLM Android, iOS

NB: Physical Web will continue as an initiative, but using Eddystone’s URL as a foundation instead of its own UriBeacon format.

Unique Features

As mentioned above, in addition to the UID and URL there are two payload features unique to Eddystone:

  • Ephemeral ID is an ID which changes frequently and is only available to an authorised app, not broadcast generally. It’s intended for short-term use; the use cases mentioned are for finding luggage when travelling, or finding lost keys.
  • Telemetry is data about the beacon or attached sensors: e.g. battery life, temperature, humidity.

APIs

Along with Eddystone, Google announced a handful of new / extended APIs:

  • Proximity Beacon associates beacons with data in the cloud, allowing for very rich information, including latitude and longitude co-ordinates, and an association with the Places API (similar to Facebook BLE Beacons).
  • Place Picker is an extension of Places, showing beacons / places in your immediate vicinity.
  • Nearby uses a combination of Bluetooth, WiFi and ultrasound to make it really easy for devices to find, and communicate with, each other.

Although Eddystone requires these Google APIs to be useful at the moment, the fact that it’s an open standard means that anyone will be able to make open alternatives in the future.

iOS devices require an extra library to work with Eddystone.

The Bigger Picture

Eddystone is part of Google’s push further into the ‘Internet of Things’. These also include:

  • Brillo, a lightweight version of Android for low-powered devices;
  • Weave, a secure home devices protocol for device-to-device or device-to-cloud communication; and
  • Thread, an alternative to Bluetooth for direct communication (not a Google project, but they are a member of this consortium).

Beacons

Unlike iBeacons, which must be approved by Apple, anyone can make an Eddystone-compatible beacon. Current beacon manufacturers include Estimote, Kontakt and Radius Networks.

Further Reading

3 comments on
“Eddystone – A Briefing Note on Google’s New Beacon Format”

  1. “It does all that some existing (and proposed) standards – namely iBeacon and Physical Web – do, plus more.”

    Google has since updated their Physical Web spec, it’s now running on top of Eddystone (or it always was and this is just a rebranding of sorts).

    https://github.com/google/physical-web/blob/master/documentation/technical_overview.md#ble-format

  2. Thank you, Hugh; I’ve tweaked the text, and it mentions the change later in the post. Hope it makes a bit more sense now.

  3. […] To try out the Physical Web for yourself you’ll need some beacons and a smartphone. I recommend this Beacon Dev Kit from Radius Networks for the former, and for the latter you can install the app for Android, or set up Chrome on iOS. The Physical Web uses the Eddystone protocol, on which I previously wrote a briefing note. […]