Bluetooth 5 Beacon Implementation Tradeoffs

We previously wrote about Bluetooth 5 and beacons. Now that more technical articles are available, we have been looking deeper into Bluetooth 5 and and how it might affect beacons, particularly in terms of compatibility and battery life.

Bluetooth 5 achieves a greater range without necessarily using more battery power. How? There’s an informative article by Martin Woolley that explains how range is more to do with how far the radio signal reaches and is still intelligible as opposed to how far the signal reaches. With current Bluetooth 4, the signal is actually going further than the working range but there’s noise in the signal such that the data can’t be reliably read. Bluetooth 5 (optionally) adds extra information to the data to allow error correction to be performed. This allows the data to be intelligible at a longer range. There are various PHY ‘modes’ that Bluetooth 5 can use with different capabilities:

LE 1M is what we have at the moment and will provide backward compatibility. The new LE Coded modes add error correction at the expense of a lower data rate. The LE 2M provides twice the data rate but actually less range than with Bluetooth 4. It can be seen that the ‘headline’ of Bluetooth x4 range and x2 speed are mutually exclusive. Bluetooth 5 is better than Bluetooth 4 but you can’t have everything. Bluetooth implementations will need to choose whether range, or speed is important. As beacons transmit very little data and speed of that data isn’t that important, we expect new beacons to use the coded PHY modes.

However, what about compatibility? If beacons need to remain backward compatible with current Bluetooth 4 phones then they will need to transmit LE 1M. There will be a tradeoff between long range needs and compatibility with today’s phones. Some beacons might do timeslicing between long range Coded and LE 1M advertising with a consequent significant degradation of battery life.

Another aspect that will affect battery use is that Bluetooth 5 allows a maximum transmit power +20dBm rather than +10dBm as at present. However, as now, higher output power will be under user (initial configuration) control.

In terms of using the new, larger Bluetooth advertising data size, this will need the iBeacon and Eddystone specifications to evolve. This is reliant on work by Apple and Google. Larger data sizes imply longer transmission time, about x2 to x8 the current transmission time. Most current beacons transmit for about 1ms (1 millisecond) every 100ms to 1000ms. New beacons will transmit between 2ms and 8ms again every 100ms to 1000ms. The transmission time has a direct, almost linear, affect on battery use.

[As an aside, if a beacon uses use LE 2M, without the longer range, then the transmission time will be cut by about a half. As most beacons are expected to support the longer range, in most cases there’s going to be a corresponding increase in battery use.]

It can be seen that for ‘Beacons 2.0’, compromises will have to be made. There are tradeoffs between long range, high speed, legacy (today’s) phone compatibility and efficient battery use that mean no beacon will have all these desirable attributes. There’s likely to be an even larger range of beacons and/or configuration parameters that tradeoff range, speed, compatibility and battery life. This is likely to complicate evaluation and rollouts.

Beacon Trajectory Smoothing

The problem with using RSSI for detecting location is that raw data contains lots of noise. Also, this noise becomes more prevalent in the viewed data when location samples are taken less often. There’s a useful new article at InfoQ on Processing Streaming Human Trajectories with WSO2 CEP.

The idea uses Kalman filtering to smooth noisy human trajectories.

Before and after filtering

This method is particularly useful for large realtime IoT rollouts because it uses a very small memory resource, is very fast and the calculation is recursive, so new values can be processed as they arrive.

Machine Monitoring Using Bluetooth Beacon Sensors

There’s a new article at RFID Journal BLE Eavesdrops on Machine Health With Augury System that describes how Bluetooth LE sensors can be used to monitor machine health. Such systems can be used to detect when machines have been working, when they weren’t working and the ‘big data’ can sometimes be used to predict failure. Such events can trigger real-time alerts.

This scenario is an example of Beacon Proximity and Sensing for the Internet of Things (IoT). This isn’t limited to monitoring machines. It can be used to monitor people, animals, plants, stock assets or just about anything.

Beacon Compatibility

We previously wrote a lot about beacon compatibility where we concluded that phone compatibility is more of an issue than beacon compatibility and that you might choose an Apple MFi certified beacon if you wanted additional assurance. However, what does MFi mean?

Certified beacons meet Apple’s beacon specifications. There was a time that these specifications were secret and only available to MFi partners. However, these have since become available after you have ok’d an agreement. If you wish to view them, go to the iBeacon for Developers web page and click on Download Artwork and Specifications.

Chrome, Eddystone and the Omnibox

There are some posts on Twitter and articles talking about how Eddystone appearing in iOS Chrome’s Omnibox might transform proximity notification scenarios. So what is this and what does it look like?

This came about due to the Physical Web/Chrome teams experimenting with new ways to show Eddystone notifications:

At the moment, notifications appear at the end of the ‘Today’ view. They get a bit lost because you have to swipe down get the notifications, swipe left and then scroll to the bottom:

BeaconZone Eddystone notification at the bottom

Noone is going to see this unless they know it’s there and are trying very very hard. Even though Eddystone detection is designed to be ‘pull’ rather than ‘push’, it’s a bit too difficult to find local Physical Web beacons.

With Google’s experimental Omnibox implementation, beacons come up when you go to do a Chrome search. At the moment, to try it out you have to enable an experimental flag by visiting chrome://flags:

After you do this, local physical web beacons appear when you start a search:

It’s far more likely people will see this rather than the Chrome widget at the bottom of the notifications Today panel.

It’s unknown whether this will find it’s way into future versions of Chrome without having to set the flag or whether it might appear on Android. Android has more visible Eddystone detection as it’s built in Android itself (Play Services to be more specific) and appears near the top of the notifications panel.

UPDATE: As of October 2017, Google removed Eddystone detection from Chrome on iOS and Android. Only Android can provide notifications.

Google’s Proximity Beacon API

Most beacon platforms are fairly limited in that they are designed around retail marketing scenarios. If you are creating a non-retail marketing solution you might want to look into Google’s little publicised Proximity Beacon API. It allows you to register beacons and have arbitrary data, called attachments, associated with them. What’s more, it supports the registration of iBeacon as well as Eddystone beacons and you can use it free of charge.

The usual usecase is setup via Google’s console followed by update from apps detecting beacons. Android and iOS example are available.

It’s not always apps that are used to detect beacons. For example, you might have a single board computer such as the Raspberry Pi or Bluetooth-WiFi gateway detecting beacons and a web front end managing and monitoring the beacons. Google also provides example scripts that show how other entities can be used to register, list and filter beacons. Alternatively, other entities might even call these scripts.

The storing of arbitrary data allows the proximity Beacon API to be used for scenarios beyond retail marketing such as sensing with sensor beacons and real time locating (RTLS).

Beacon Locator Android App

A growing number of people are using beacons for personal use. Today, we added the Beacon Locator Android app to our Solutions Directory. It allows you to set up action types such as opening a URL, broadcasting an Android intent, starting an app, changing the sound profile and running tasks via Tasker in response to detecting or losing a beacon signal.

What’s especially interesting about this app is that it’s open source allowing you to extend it to a multitude of personal and business scenarios.

Paper on Using Eddystone Ephemeral-ID (EID)

There’s a recent paper by Debasis Bhattacharya Mario Canul and Saxon Knight of the University of Hawaii on the Impact of the Physical Web and BLE Beacons (pdf). The paper is based on a project that uses Eddystone Ephemeral-ID (EID). The paper is more a backgrounder and description rather than providing new insights. Nevertheless, it provides a useful description of some security issues with beacons that include tracking of beacon locations, forgery and showrooming.

New Real-time Locating Systems (RTLS) Article

We have a new article on Using Beacons for Real-time Locating Systems (RTLS). It explains how beacons can be used with apps or gateways to automatically identify and track the location of objects or people. It also mentions how RTLS systems can be implemented using IoT platforms.

RTLS created with an Open Source IoT Platform

Areas where organisations have used BeaconZone beacons for RTLS include manufacture, warehousing and the tracking of equipment and people. The latter segment has included people on campus, lone workers and evidence based working (e.g. evidence based policing).

BeaconZone at IoT Thames Valley Meetup

We were exhibiting at the IoT Thames Valley Meetup on Wednesday:

Our stand at IoT Thames Valley Meetup

Here’s what happened with a few insights from the presentations:

Richard Fargus, Managing Director, Voytech Systems spoke about ‘Commercial Deployment of IoT solutions in Building Monitoring
and Control’. He mentioned how, using TCPI/IP over cellular is very inefficient. For example, 2 bytes of data can balloon up to 5000 to 1000 bytes which can be costly.

Richard Kinder, VP, Head of Product Marketing, Wirepas covered ‘Industrial IoT requires fit for purpose connectivity’. He spoke about wireless mesh networking. He mentioned how increasing the Lora power in an urban environment gives negligible improvement in range.

Nick Baker, Director, Adaptive Wireless Solutions gave ‘Wireless IoT – lessons learned from industrial implementations’. He spoke about 2.4GHz mesh networks used for various clients. He emphasied the need for solutions to be reliable and easy to implement. He also mentioned (the recurring theme) that there’s no one vertical market or solution.

Richard Foggie, Executive Knowledge Transfer Network, spoke about IoT networking and funding opportunities from the Government KTN.

Mike Bartley, CEO T&VS gave a talk on ‘Avoiding the Internet of Insecure Things’ via test and certification.

Leonard Anderson, Kemuri Limited, presented his IoT Power Sockets.

Graham Kitteridge gave a lightening talk on Think Engineer, who create custom hardware prototypes.