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

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

Yes­ter­day Google announced ‘Eddy­s­tone’, a new open Blue­tooth bea­con for­mat which works on Android and iOS. I’ve been doing a bit of read­ing about it to under­stand the tech­nol­o­gy and its poten­tial, and I put togeth­er a brief­ing note about it for my col­leagues. I’m a believ­er in max­imis­ing returns on my con­tent, so it seems like a good oppor­tu­ni­ty to repub­lish that brief­ing note here.

This is a very rapid and shal­low look into bea­cons, and I’ve no doubt made some omis­sions or inac­cu­ra­cies, so apolo­gies in advance for that. If you think I’ve made any huge over­sights or errors, please feel free to let me know in the comments.

In a Nutshell

Eddy­s­tone is, as men­tioned, an open Blue­tooth bea­con stan­dard. It works on Android and iOS. It does all that some cur­rent for­mats – name­ly iBea­con and Phys­i­cal Web – do, plus more. It comes with asso­ci­at­ed APIs and libraries that make it very exten­si­ble and powerful.

Branding

Although this is a Google-led ini­tia­tive, they very much want this to be seen as an open stan­dard. So the brand­ing is just Eddy­s­tone, with­out men­tion of Google. Fun fact: It’s named after the UK’s Eddy­s­tone Light­house.

Opportunities

Any­thing based around imme­di­ate loca­tion. Google have recent­ly run a project around live trans­port infor­ma­tion in Port­land, and are talk­ing about push­ing hyper­local infor­ma­tion into Google Now. Think about bea­cons in shop­ping cen­tres, muse­ums, art gal­leries, mar­kets… any­where you need pas­sive infor­ma­tion about the things imme­di­ate­ly around you.

Comparing Format Standards

  • iBea­con is an Apple-only stan­dard which trans­mits a sin­gle Unique Iden­ti­fi­er (UID). Apps can use this to trig­ger an action.
  • Phys­i­cal Web Google-led open ini­tia­tive which trans­mits a sin­gle URL. Apps can present this to the user or look up relat­ed infor­ma­tion from metadata.
  • Eddy­s­tone Google-led open ini­tia­tive which com­bines fea­tures of both, plus more. Has a UID, a URL, plus Ephemer­al Iden­ti­fi­er (EID) and Teleme­try (TLM) data — details on these below.

Here’s a quick comparison:

Bea­con Pay­load Plat­form
iBea­con UID iOS
Phys­i­cal Web URL Android, iOS
Eddy­s­tone UID, URL, EID, TLM Android, iOS

NB: Phys­i­cal Web will con­tin­ue as an ini­tia­tive, but using Eddystone’s URL as a foun­da­tion instead of its own UriBea­con format.

Unique Features

As men­tioned above, in addi­tion to the UID and URL there are two pay­load fea­tures unique to Eddystone:

  • Ephemer­al ID is an ID which changes fre­quent­ly and is only avail­able to an autho­rised app, not broad­cast gen­er­al­ly. It’s intend­ed for short-term use; the use cas­es men­tioned are for find­ing lug­gage when trav­el­ling, or find­ing lost keys.
  • Teleme­try is data about the bea­con or attached sen­sors: e.g. bat­tery life, tem­per­a­ture, humidity.

APIs

Along with Eddy­s­tone, Google announced a hand­ful of new / extend­ed APIs:

  • Prox­im­i­ty Bea­con asso­ciates bea­cons with data in the cloud, allow­ing for very rich infor­ma­tion, includ­ing lat­i­tude and lon­gi­tude co-ordi­nates, and an asso­ci­a­tion with the Places API (sim­i­lar to Face­book BLE Bea­cons).
  • Place Pick­er is an exten­sion of Places, show­ing bea­cons / places in your imme­di­ate vicinity.
  • Near­by uses a com­bi­na­tion of Blue­tooth, WiFi and ultra­sound to make it real­ly easy for devices to find, and com­mu­ni­cate with, each other.

Although Eddy­s­tone requires these Google APIs to be use­ful at the moment, the fact that it’s an open stan­dard means that any­one will be able to make open alter­na­tives in the future.

iOS devices require an extra library to work with Eddystone.

The Bigger Picture

Eddy­s­tone is part of Google’s push fur­ther into the ‘Inter­net of Things’. These also include:

  • Bril­lo, a light­weight ver­sion of Android for low-pow­ered devices;
  • Weave, a secure home devices pro­to­col for device-to-device or device-to-cloud com­mu­ni­ca­tion; and
  • Thread, an alter­na­tive to Blue­tooth for direct com­mu­ni­ca­tion (not a Google project, but they are a mem­ber of this consortium).

Beacons

Unlike iBea­cons, which must be approved by Apple, any­one can make an Eddy­s­tone-com­pat­i­ble bea­con. Cur­rent bea­con man­u­fac­tur­ers include Esti­mote, Kon­takt and Radius Networks.

Further Reading

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

  1. “It does all that some exist­ing (and pro­posed) stan­dards – name­ly iBea­con and Phys­i­cal Web – do, plus more.”

    Google has since updat­ed their Phys­i­cal Web spec, it’s now run­ning on top of Eddy­s­tone (or it always was and this is just a rebrand­ing 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 men­tions the change lat­er in the post. Hope it makes a bit more sense now.

  3. […] To try out the Phys­i­cal Web for your­self you’ll need some bea­cons and a smart­phone. I rec­om­mend this Bea­con Dev Kit from Radius Net­works for the for­mer, and for the lat­ter you can install the app for Android, or set up Chrome on iOS. The Phys­i­cal Web uses the Eddy­s­tone pro­to­col, on which I pre­vi­ous­ly wrote a brief­ing note. […]