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.

Using Beacons For a Library Tour

There’s an interesting article at code4lib on Creation of a Library Tour Application for Mobile Equipment using iBeacon Technology by Virginia Tech. It describes a project where a QR code driven library tour was updated to use beacons.

Some insights include how attractive beacons can become ‘lost’, the problem of replacing batteries, limited battery life due to the iOS requirement for beacons to advertise every 100ms and challenges physically fixing beacons.

As mentioned in our article on Choosing an Advertising Interval, it’s possible to set the advertising interval to between 300ms and 600ms while maintaining a reasonable detection time. Also, had the library chosen Android tablets they could have used a much longer advertising interval. 100ms is an artificial thing set by Apple for very quick detection on iOS devices. On Android, the scanning is more controllable,you can scan for longer and hence have beacons that advertise less often and have much longer battery life.

Bluetooth Power Consumption in Phones

A growing use of beacons is for continually monitoring using sensor beacons. However, one concern is how continually reading a Bluetooth sensor beacon might affect phone battery life.

There’s a recent research paper by Kleomenis Katevas, Hamed Haddadi and Laurissa Tokarchuk of Queen Mary University of London, UK on Power use : SensingKit: Evaluating the Sensor Power Consumption in iOS devices. It looks into Bluetooth beacon (phone) power use and, as a baseline, compares this to phone battery power use by sensors in the phone. They evaluated beacon broadcasting and scanning modes separately and together.

Very few scenarios use the phone to broadcast so the pink dotted line probably has less relevance. Looking at the scanning test it can be seen that it consumes power of the same order of magnitude as other sensors in the phone itself. Bluetooth LE scanning isn’t especially power hungry. Nevertheless, the 25hrs hours operation time on battery might be a limitation for most sensing scenarios.

An omission in these tests is that they only considered scanning rather than connecting. Some beacons need to be connected to via Bluetooth GATT, to obtain sensor data, that uses more phone battery power because it requires the phone to transmit to the beacon instead of just listening to the advertising scan data.

In practice, sensing projects are often better served by using a WiFi gateway or a phone/tablet permanently plugged in rather than a user’s battery-powered phone. This allows the device receiving sensor data to be mains powered removing concerns regarding device power use.

GATT Connections and Battery Life

Our battery use power testing uncovered some cases where the battery current use during advertising was such that the battery would last longer than manufacturer specification. What was going on?

After contacting the manufacturers, it turned out that some of them include a degree of configuration activity in their battery life estimates. If you only measure the current during advertising then you haven’t taken into account the extra current used during configuration. Configuration via manufacturer apps connects to the beacon via Bluetooth GATT. GATT connections consume significantly more power. For one off configuration this will be negligible but if you are in the habit of repeatedly changing the beacon configuration then the battery life will be impacted.

The same goes for platforms/apps that periodically connect to beacons to read, change or monitor beacon parameters. The battery won’t last as long. It’s also for this reason, it’s preferable to read sensor beacon sensor data in advertising data rather than via GATT when this is supported by the beacon and your scenario can cope will less frequently reported data.