Building apps using Eddystone : Part 1

This 3 part blog series aims to provide an overview of building apps with the Eddystone open format that Google has recently introduced. This first post gives a little background on iBeacon and BLE 4.0, along with introducing the frame types in Eddystone.


About Bluetooth 4.0

Bluetooth 4.0 has it's roots at a company called CSR (now a part of Qualcomm), a wireless communications industry based out of Cambridge. It was initially called Wibree and was later standardised under the Bluetooth SIG in 2010. It isn't backwards compatible with the previous versions of Bluetooth, and is meant to co-exist with the older standards.

Gotchas

These are some of the important gotchas for Bluetooth 4.0

Speed

The following two tables list the version of the wireless standard and the speed achieved using the same.


Note : More recent versions of both standards do exist

As you can see in the above table, v4.0 of Bluetooth drastically reduced the speed.

Memory

Bluetooth 4.0 devices do not support multiple memory protocols like it's predecessor. Hence it supports very small packets and cannot handle things like audio streaming, transfer of large files, etc.

Connectionless model

In the previous versions of Bluetooth it was assumed that the connections will be persistent for a considerable duration (more than a few seconds). Think about your handsfree headset for example. Hence the time required for the initial overhead of setting up a connection was acceptable. Bluetooth 4.0 doesn't follow this model. In this standard you connect to a device, get or set the required data and disconnect as soon as possible. Hence the time required to setup a connection is very critical.

Battery

The design aims of this standard were low cost, short range and low power. As a result of all the trade offs that the Bluetooth 4.0 standard has made (speed, memory and connectionless model) it has exceptional battery life. A simple beacon could last years on a standard coin cell battery.


Apple & iBeacon : The First Movers

In Apple's June 2013 World Wide Developer Conference (WWDC), it quietly announced the iBeacon.

Introduced in iOS 7, iBeacon is an exciting technology enabling new location awareness possibilities for apps. 
- Apple's Getting Started Guide for iBeacon

The iBeacon protocol

Field Size Description
UUID  16    bytes Application developers should define a UUID specific to their app and deployment use case.
Major  2  
 bytes
Further specifies a specific iBeacon and use case. For example, this could define a sub-region within a larger region defined by the UUID.
Minor  2  
 bytes
Allows further subdivision of region or use case, specified by the application developer.

Google & Eddystone : An Open Beacon format

Google launced the Eddystone open beacon format on July 14, 2015. On comparing the Google and Apple versions of beacons, the Google one is easily the more mature, versatile and obvious winner. This is not surprising as Google took 2 years to sit back and analyse what Apple and it's partners were doing right/wrong with the iBeacon protocol.

The Eddystone open format has presently listed 3 types of frames as opposed to the single frame type of Apple iBeacon :

Eddystone-UID

  • 10 byte namespace ID
  • 6 byte instance ID

Eddystone-URL

  • URL using a compressed encoding format

Eddystone-TML

  • Telemetry information

This includes things like :

  • Battery voltage
  • Device temperature
  • Count of broadcast packets

Note : Provision has been made so that frame types can be added in the future.


Source

  1. Bluetooth Low Energy : The Developer's Handbook by Robin Heydon
  2. Apple's Getting Started with iBeacon
  3. Eddystone Protocol Specification

The iBeacon name and logo are copyright of Apple Inc