Eddystone Beacon Explainer: An Interview With Google’s Chandu Thota

On July 14, Google announced a new developer initiative called Eddystone. It’s a new open format for Bluetooth low energy (BLE) beacons. It’s open-source, flexible, cross-platform and will equally support iOS devices.

In order to better understand how Eddystone works and Google’s perspective on its benefits and applications, I conducted an email interview of Google Engineering Director Chandu Thota. My questions are in bold, and Thota’s answers follow.

What makes Eddystone different or unique vs. other Beacon approaches (Is it merely the platform agnosticism or other things, too)?

Eddystone is an open Bluetooth low energy beacon format published by Google on Github. There are three key differences that Eddystone offers developers and hardware manufacturers:

• Open: the specification is published on Github under the Apache 2.0 license so that manufacturers and developers can access, comment and contribute to it.
• Robust & extensible: supports multiple types of frames to carry payloads of different forms, making it possible to extend use cases without complicating a simple, out-of-box experience. Example: The Eddystone-URL frame supports URL payloads which are used by the Physical Web project.
• Cross-platform: published on the Web and driven by the community; Eddystone is capable of working across Android, iOS or any platform that supports BLE beacons.

Who will distribute/install the hardware, third parties such as Estimote? Is Google creating any incentives for them to build it into their beacon hardware? Does Google plan to do any of its own hardware distribution?

Yes, a combination of third-party beacon hardware providers and businesses will distribute and install the hardware. You can see a list of the early hardware partners we worked with here. I think the incentives for why beacon hardware partners should support Eddystone are aligned with the differentiators we outlined above (Open, Robust/Extensible and Cross-platform).

Eddystone’s extensible frame formats allow hardware manufacturers to support multiple mobile platforms and application scenarios with a single piece of hardware. An existing BLE beacon can be made Eddystone compliant with a simple firmware update. At the core, we built Eddystone as an open and extensible protocol that’s also interoperable, so we’ll also introduce an Eddystone certification process in the near future by closely working with hardware manufacturing partners.

Google does not have any plans to get into the beacon hardware business.

Will Eddystone work in beacons that also utilize the iBeacon standard, or are they mutually exclusive?

No, hardware manufacturers can definitely include both iBeacon and Eddystone formats on their beacon devices. They are not mutually exclusive. In fact, many of the partners we worked with do include both formats in a single piece of hardware.

Please explain the differences between the Nearby API and Proximity Beacon API and their intended uses.

The Nearby API for Android and iOS makes it easier and more battery efficient for apps to find and communicate with nearby devices and beacons, such as a specific bus stop or a particular art exhibit in a museum, providing better context. And the Proximity Beacon API is cloud API that lets developers associate semantic location (i.e., a place associated with a lat/long) and related data with beacons.

You can learn more about the Nearby API on our blog post. And here is more info on the Proximity Beacon API.

There have been various nearby use-cases/scenarios discussed (e.g., transit information integration with maps). Can you describe a mobile search example that might utilize the Eddystone-beacon network? What about a Google Now instance?

Google Now is a great example of how we can use beacons for more contextual experiences. Soon, Google Now will be able to use this contextual information to help prioritize the most relevant cards a user sees at a specific location. For instance, imagine how we can help users order food or view menus at their table when they are inside of a restaurant.

Will Eddystone and related efforts accurately locate users and permit indoor navigation (via trilateration)?

As part of improving location and indoor navigation efforts in our mapping products, we continue to work on various indoor related features. As part of this, we continue to avail any signals that are available including bluetooth low energy beacons. We will share more as we develop some of these experiences further.

Do you seen this a primarily about indoor location or is it equally about outdoor/IoT applications?

Eddystone is by design extensible. Which means that we plan to cover a broad range of verticals and scenarios: Proximity, Location, IoT, etc. From location perspective, we think there are use cases for both indoor and outdoor experiences. For instance, a great outdoor example is the current pilot program we’re doing with TriMet in Portland, whereby they’ve installed beacons at transit stations in order to provide real-time transit updates on Android devices. Similarly, URL and TLM frame formats of the spec are good examples of how Eddystone can be extended to IoT.

Anything else important to understand about Eddystone or the APIs?

The most important thing about Eddystone is that it can be extended by the ecosystem partners and the community. We are seeing great momentum across hardware partners, developers and businesses since we have launched. Many chip manufacturers are now officially supporting Eddystone as part of their offering. We are going to work closely with our developer, hardware and business partners as we continue to evolve this new format.