Category: BatteryUse

Small, Long Battery Life, Long Range Beacon

It’s surprising how many enquires we get asking for small beacons that also have a long battery life and long range. Such things don’t exist. The range and battery life relate to the battery size. Both need a larger battery and hence this implies a larger beacon.

You need to choose what’s most important for your project. If you need a very small device then the iB001M is only 2.6mm thick but has a small CR2016 battery. If battery life and range are more important then look at the larger battery beacons and long range beacons. If you have the possibility of mains (USB) power then you might consider a USB beacon that can be small.

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.