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.
These are some of the important gotchas for Bluetooth 4.0
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.
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.
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.
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
|| 16 bytes
||Application developers should define a UUID specific to their app and deployment use case.
|Further specifies a specific iBeacon and use case. For example, this could define a sub-region within a larger region defined by the UUID.
|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 :
- 10 byte namespace ID
- 6 byte instance ID
- URL using a compressed encoding format
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.
- Bluetooth Low Energy : The Developer's Handbook by Robin Heydon
- Apple's Getting Started with iBeacon
- Eddystone Protocol Specification
The iBeacon name and logo are copyright of Apple Inc