Introduction to Eddystone, and how it compares to Apple’s iBeacons
iBeacon was the in-thing in 2013 when it was launched by Apple, but its growth hasn’t quite been what was expected out of such an innovative concept. This could be associated to the fact that Apple has been very protective of the iBeacon standard, considering it had forced companies like Radius Networks to scour their work linking Android devices and iBeacon standards. It’s this peculiar market situation which brings Google’s Eddystone into limelight.
For those who are not quite comfortable with all these techie talk, let’s lay down the basic things first. Bluetooth Low Energy or BLE is a smarter version of our ordinary Bluetooth wireless technology. It means BLE is basically Bluetooth, which takes very less power to operate, costs lesser, has high security and is compatible with all major operating systems, all this coupled with an operating range of up to 100 meters. iBeacon is Apple’s version of BLE, which is used to provide location based services to iOS devices. Now that we are clear on the context, let’s get on with Eddystone.
Eddystone is the new open Bluetooth Low Energy beacon standard unveiled by Google. It is Google’s rendition of iBeacon. It is a protocol specification that defines a Bluetooth low energy (BLE) message format for beacon messages. It designates several different frame types that may be used individually or in combinations to create beacons that can be used for a variety of applications. According to Google, it’s named after the Eddystone Lighthouse in the UK. The concept is that it beacons users and apps in the real world the same way lighthouses guide ship captains in the night.
Bluetooth beacons are tiny transmitters, which constantly beam out a signal to nearby devices, transmitting information about some point of interest. These signals are intercepted by user’s mobile devices. In Eddystone, two location APIs are available (Eddystone-UID and Eddystone-URL) that can find a nearby beacon and send information when you are in a specific location range. Developers can either set up apps in user devices (both Android and iOS) which look out for beacons and perform certain functions (using Eddystone-UID frame) or in the absence of relevant apps in listening devices, push URLs which opens browsers and displays contents in user devices (using Eddystone-URL frame).
There is also a frame type for Telemetry Data (Eddystone-TLM) for companies that need to manage vast fleets of beacons. The telemetry frame type would send diagnostic data and remaining battery power to the appropriate IT person, so that they could track the faulty beacons and fix them.
|1||Apple’s intellectual property||Open source and available on GitHub under the Apache v2.0 license|
|2||Works only on iOS devices||Works on both iOS and Android devices. Android support is built into Google Play Services’ “Nearby API”. This can be used via a library on iOS as well.|
|3||Supports only one advertising data packet type.||Eddystone is designed to support multiple data packet types, starting with two for advertising: Eddystone-UID and Eddystone-URL|
|4||No option to monitor beacon condition||A third type of packet: Eddystone-TLM, as in “telemetry.” is broadcasted to indicate beacon’s “health status” (e.g., battery life). This is mainly intended for fleet management and is broadcasted less frequently than the “data” packets.|
iBeacon provides two API methods for apps to detect iBeacons devices: ranging, which works only when the app is active, and provides proximity estimations; and monitoring, which works even if the app is not running, and provides a binary “in range” and “out of range” information.
Eddystone support in the Estimote iOS and Android SDKs is based on a single method at this time: Eddystone discovery, which is similar to iBeacon’s ranging. It provides proximity estimates and works only when the app is active.
Google Eddystone addresses privacy and security concerns using Ephemeral Identifiers (EIDs). The EIDs can only be decoded by ‘authorized clients,’ so activities like tracking luggage can be done securely. Google is yet to disclose further details about this.
Eddystone can enhance our interaction with the world around us, using beacons to intercept our location and its implication. Smartphones currently rely on QR codes, Wi-Fi networks or an active GPS location to track device users. This data is used by your phone to know your location and its significance – to know when you’re in your house, in your car, or sightseeing at the Eiffel Tower, so that it can respond accordingly.BLE beacons can change the way mobile devices alert you to something of interest.
For example, a beacon placed inside a shop can push out trending offers to devices within its range. Embed a BLE beacon in a bus stop, and it can offer you a timetable when you stop there for, say ten seconds. Mount a beacon inside a restaurant, and it could offer you the menu on your phone when you walk in. Or install one in a museum, so it could send you information about the exhibit you are standing in front of.
Eddystone has the potential to grow up to expectations, since it is open source and can benefit from the huge amount of freelance / corporate work imminent to be done on it. Current beacon devices could work with Eddystone with just a firmware update. While it’s all looking good, please also be informed that while Eddystone, the beacon format remains open source, Google’s recommended methods of receiving these frame formats is not. Google Play Services, the Nearby API, and the Proximity Beacon cloud service are all proprietary. Another limitation is that you won’t be able to run iBeacon and Eddystone at the same time from a single beacon.
But there is no doubt – this is one of the best things which will redefine our world and advance it to tomorrow!