What is the Difference Between iBeacon and Eddystone?

iBeacon, a standard developed by Apple, was introduced in 2013 as part of the iOS 7. It’s based on Bluetooth Low Energy (BLE), a power-efficient variant of Bluetooth technology. The strength of iBeacon lies in its background support on iOS devices, which allows for easier detection of beacons.

Google introduced Eddystone in 2015. This protocol for beacons was developed to embrace a broader range of uses. Eddystone offers multiple frame types to cater to various data needs like URLs, unique identifiers and sensor data. One most distinctive feature of Eddystone was the Eddystone-URL, where the beacons could send out a web address. However, this has been limited by the discontinuation of Google Nearby in Android.

Despite the differences in their design and features, both iBeacon and Eddystone share common ground in their use of standard Bluetooth advertising. They send different data in the same standard Bluetooth advertising packets. This shared aspect of technology ensures that they can both communicate effectively to both iOS and Android.

While Eddystone’s versatile frame types and open protocol initially made it appealing, it has seen a decline since the discontinuation of Nearby in Android. Currently, most new systems requiring smartphone applications to detect a beacon opt for iBeacon.

However, when it comes to locating and detection using gateways rather than smartphones, iBeacon vs Eddystone becomes less relevant and the beacons’ Bluetooth MAC addresses are usually used. The advertising packets can instead be used for sensor data, for example, temperature and humidity.

View iBeacon Beacons
View Eddystone Beacons
View Sensor Beacons

Beacon Setup Tip: Advertising Type

Bluetooth beacons are tiny devices that transmit small amounts of data over short distances using Bluetooth Low Energy (BLE) technology. They can operate with different protocols, like iBeacon (developed by Apple), Eddystone (developed by Google), and various sensor beacon protocols.

Despite the fact that it might seem these beacons can advertising multiple protocols simultaneously, it’s not quite the case. What they actually do is advertise these protocols one after the other in a very rapid sequence. This is due to the way Bluetooth works; it’s not technically possible to transmit multiple signals at the exact same moment. Instead, the beacon switches between the different protocols very quickly, which to a casual observer, or a smartphone, might seem simultaneous.

This rapid succession is made possible by BLE’s advertising mechanism. Beacons, in their idle state, continuously broadcast their identity, and potentially other information, in what’s called ‘advertising packets’. When they’re configured to use multiple protocols, they broadcast an iBeacon packet, then an Eddystone packet, then a sensor beacon packet, and so on in a cycle. This is repeated at a very high frequency, many times per second.

However, while this flexibility is advantageous in certain scenarios where various beacon protocols are required, it’s not always necessary and drains the beacon’s battery more quickly. This is because each advertising event consumes energy, and broadcasting in multiple protocols effectively multiplies the number of these events.

Many beacons are set up to advertise multiple protocols by default. If you don’t need this functionality, you can optimise battery life by disabling unnecessary protocols. This is done using a manufacturer-provided app. The exact process can vary between manufacturers and beacon models, but it generally involves connecting to the beacon, accessing its settings and then deselecting the protocols you don’t need.

While multiple-protocol advertising can be useful in certain situations, it’s often more battery efficient to only use the specific protocols you actually need for your application.

Is it Possible To Use One App to Manage All Beacons?

There are lots of brands of iBeacon and Eddystone beacon. Each brand has its own management app. We have often been asked,

“Is it possible to have just one app to manage different brands of beacon?”

While it’s technically possible, there’s no incentive for anyone to create such an app. Creating just one app to manage one beacon brand, across iOS and Android is significant effort in itself.

Google identified this problem and created the Eddystone Configuration GATT Service. The idea is that if manufacturers used just this, apps and beacons would be inter-operable. However, people want to configure iBeacon as well as Eddystone. Manufacturers also want to allow users to configure and read sensor data. Also, using Eddystone Configuration GATT Service software in all future beacons does nothing to help manage the large number of beacons that are already out there.

As of writing this, in 7 years since Eddystone Configuration GATT Service was published, no apps have been published that work with the Eddystone Configuration GATT Service. However, the Nordic nRF Connect app does understand some of the Bluetooth Characteristics to better read these kinds of beacons. There hasn’t been a rush for manufacturers to use Eddystone Standard GATT.

Back to the question. It looks like there will be a separate app per manufacturer for the foreseeable future.

Eddystone URL

Eddystone-URL is a format for Bluetooth Low Energy (BLE) beacon advertisements. It is an open format developed by Google and designed to be transmitted by beacons to nearby devices, such as smartphones and tablets. The format allows beacons to broadcast a URL which can be used to direct users to a specific web page.

In other words, Eddystone-URL is a way for ‘things’ with attached beacons to communicate with nearby devices and provide them with a link to a webpage. This can be used for a variety of purposes, such as providing location-based information, coupons, or other types of content to users. It can be used in a wide range of applications, including retail, transportation and tourism.

Eddystone-URL works by broadcasting a URL in a Bluetooth advertisement packet. When a device with a compatible BLE receiver, such as a smartphone, comes within range of the beacon, it can receive the advertisement packet and decode the URL. The user can then open the URL in a browser on the device.

An app is needed on iOS and Android such as Beaconstac NearBee, the Physical Web Association app or your own custom app. If you create your own app, consider using iBeacon instead of Eddystone URL advertisements for easier processing on iOS (also works on Android). The iBeacon ids can be mapped to URLs in the app. This is often better because the mapping can be changed, for example on a server, rather than having to physically access the beacon to change the URL.

Read about Using Beacons for Marketing

Beacon Signal Stability Observations

As previously mentioned, we perform signal strength and stability tests across beacons. The data feeds into our consultancy work. Here are some high level observations.

The following graph shows the standard deviation of the RSSI @ 1m, for some of our beacons, measured over a 60 second time period:

beaconsignalstability

Smaller bars are better and represent beacons
whose RSSI varied the least over time.

We found that beacons belonged to one or two groups. Firstly those with very stable RSSI and secondly those with an RSSI that had a standard deviation between about 4 and 6 dBm.

Signal stability is more important when you are using the RSSI to infer distance, either directly from the RSSI itself or indirectly via, for example, the iOS immediate, near and far indicators. RSSI varying without a change of distance might cause more spurious triggering. However, you should keep in mind that environmental factors can often cause variation much larger than the 4 to 6 dBm found in this test. Moving obstacles, for example people, will cause significant variation in RSSI.

Bluetooth LE advertising moves pseudo-randomly between radio channels. The channels use different radio frequencies that, in turn, results in fading of the signal at different distances. We experienced and mitigated similar behaviour in our LocationEngine™. Different radio frequencies experience different constructive and destructive interference at different physical locations. Beacons that move more between channels can cause more rapidly varying received signal strength (RSSI).

Adding an IoT Protocol to Beacons

There’s new research by Department Computer Science, Universidad Técnica de Machala, Ecuador on Design and Practical Evaluation of a Family of Lightweight Protocols for Heterogeneous Sensing through BLE Beacons in IoT Telemetry Applications.

The researchers explain how standard beacon advertising works and documents the existing iBeacon and Eddystone protocols.

New protocols, LP4S-6 (for resource-constraint beacons), LP4S-X (for more powerful beacons) and LP4S-J (for beacons able to run complex firmware) are proposed that can be used to allow IoT telemetry systems to discover new nodes and to describe and auto-register the sensors and actuators connected to a beacon.

The paper describes the resultant JSON, shows how a new protocol can be added to an Eddystone beacon and proves how the new latency and power consumption remain low.

Note that updating the firmware of a beacon is non-trivial because it requires the implementation of what’s already on the beacon without access to the original source code.

Google Beacon Platform Shutting Down

Google stopped serving Android Nearby Notifications late in 2018 but kept the Nearby API working for use within apps. Google has now deprecated the Nearby API that allows you to associate beacon ids with arbitrary content such as a link or multimedia data. It will be shut down on April 1, 2021.

No, it’s not an April fool joke but instead another useful thing killed by Google. Apart from Search, Cloud, Gmail and perhaps Android it’s risky to base your business on anything provided by Google. Unless it’s an offering through which Google itself depends for income then you can’t depend on it sticking around. Instead, businesses should look to create their own APIs.

This shows the easy route isn’t always the best route. Think about your project dependencies. It is likely the platform you depend on will exist for the lifetime of your project? How is the platform funded? How is the company that provides the platform funded?

Read about Trigger Data and Beacon Servers

Read about The Advantages of Generic Beacons

Mist WiFi Access Points Broadcast as Bluetooth Beacons

WiFi access points are increasingly supporting the broadcast of Bluetooth beacon signals. The main usecase is to allow for smartphone apps to detect the Bluetooth advertising and provide for location based information and navigation.

We recently learnt that Mist access points support the advertising of iBeacon and Eddystone:

There are also some interesting uses in retail that automatically provision smartphone WiFi access settings based on the detected presence of a beacon.

Waze Beacons in 18Km of Australia Tunnels

We previously mentioned Waze Beacons in Tunnels in New York City. Since then, Waze beacons have been installed in further cities such as Chicago, Paris, Rio, Brussels, Florence and Oslo. The latest installations are by Transurban who manage tunnels in Australia where they have installed over 930 beacons in 18Km of tunnels.

Waze beacons allow uninterrupted location services underground ensuring drivers never miss an in-tunnel exit. They provide navigation underground where GPS doesn’t work.

The beacons advertise Eddystone. The Waze app sees the beacons and uses the known beacon locations rather than GPS. Google is also a partner which allows Google Maps to also see Waze beacons when driving in tunnels.