It’s all over the news now! Google recently introduced a new beacon format and tools for working with BLE beacons.
The new format is called Eddystone. And in case you are wondering how ‘Eddystone’ got its name – it is named after a lighthouse on the Eddystone Rocks in England. Let’s get into the finer details now…
What is Eddystone?
Eddystone is an open BLE beacon format that takes the primary capability of beacons – their ability to broadcast a unique number via short-range Bluetooth signals – and extends it to a greater degree.
It is cross-platform and capable of supporting Android, iOS or any platform that supports BLE beacons. It is available on GitHub under the open-source Apache v2.0 license, for everyone to use and help improve.
What are the differences between Eddystone and iBeacon?
The most significant differences include:
a) iBeacon is Android and iOS compatible, but native only for iOS
b) iBeacon was introduced in June 2013, Eddystone in July 2015
c) Eddystone is Android and iOS compatible, and may be a native part of the upcoming Android M release
d) iBeacon broadcasts one advertising packet and a unique ID number ( this comprises of the UUID, Major and Minor numbers)
e) Eddystone broadcasts three different packets: a unique ID number, a URL address, and sensor telemetry
Apart from these, Eddystone also includes a way for beacons to communicate privately with select individuals. Beacons typically communicate with devices by broadcasting a unique identifying code that is publicly viewable. But Google has created a system, called ‘Ephemeral Identifiers (EIDs)’ that allows beacons to broadcast a signal that is only identifiable to ‘authorized clients’. This thus lowers the risk of privacy leaks by encrypting the ID, so that only authorized clients can use them.
What are the three different packets that Eddystone broadcasts, and what do they mean?
1. Eddystone-UID: This is the main transmission. Whereas the iBeacon identifier is composed of three parts: UUID, major number and minor number, and is 20 bytes long, Eddystone-UID is 16 bytes long and split into two parts: 10 bytes for the namespace and 6 bytes for the instance
2. 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 UriBeacon, an open standard also sponsored by Google.
3. Eddystone-TLM: Eddystone-TLM, as in ‘telemetry’. This packet is broadcast alongside the Eddystone-UID or Eddystone-URL packets and contains beacon’s ‘health status’ (e.g., battery life). This is mainly intended for fleet management, and because of that, the TLM ‘service’ packet is broadcast less frequently than the ‘data’ packets.
While Google entering the beacon space is something we all welcome, it doesn’t really change a whole lot for businesses deploying beacons already.
iBeacon (though unofficially) has been supported on Android since the very beginning. Thus, businesses looking to run beacon campaigns on Android devices needn’t necessarily use Eddystone. Also, with beacon platforms such as Beaconstac, fleet management has been part of the offering and works independently of whether you’re using iBeacon or Eddystone.
Businesses currently using iBeacon standard and iBeacon compliant beacons can now choose to incorporate Eddystone beacons into their fleet based on the use-cases, and use a platform like Beaconstac to seamlessly manage both kinds of beacons.
Adoption of BLE and beacons is in an exciting phase right now, and it will be interesting to see how businesses leverage opportunities like these to add more context to the real world.
If you are planning an Eddystone beacon pilot, take a look at Beaconstac, that includes everything you need to kickstart your campaign in under 15 minutes. Using Beaconstac you can set up your own campaign, without a developer’s help!