Category: GATT

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, rather than just listens, 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.

Configuring Bluetooth Beacons

The configuration of a Bluetooth beacon can vary depending on the manufacturer and the specific use case. However, in general, the configuration includes iBeacon settings such as the beacon’s UUID (Universally Unique Identifier), major and minor values, transmit power, advertising interval, and other parameters that define the behaviour of the beacon.

  • UUID: This is a 128-bit value that uniquely identifies the beacon. It can be used by an application to identify a beacon among many others in the vicinity.
  • Major and Minor values: These are 16-bit values that can be used to group beacons into different categories or to identify specific beacons within a group.
  • Transmit power: This setting determines the strength of the signal transmitted by the beacon. A higher transmit power will increase the range of the beacon, but will also consume more battery power.
  • Advertising interval: This setting determines how often the beacon broadcasts its signal. A shorter interval will provide more frequent updates on the beacon’s location, but will also consume more battery power.

These settings are configured using smartphone apps. These use Bluetooth GATT (Generic Attribute Profile), a protocol used to define the way that data is exchanged between Bluetooth devices. Some beacon manufacturers also publish how they use Bluetooth GATT’s services and characteristics to update these settings so that you can also update them via your own apps or from other Bluetooth devices.

Working with GATT on Android

Most of the time, beacons transmit and the receiving software such as apps on iOS and Android or applications on single board computers (SBC) only read the advertising data. There’s no connection to the beacon. However, for programmatic setup of beacon parameters or accessing some sensor data, applications might need to connect via what’s known as Bluetooth GATT.

There’s an article on How to Work Properly With BT LE On Android. It provides some useful pointers such as not performing scanning and GATT connection simultaneously, avoiding auto-connect and not blocking GATT callbacks.

GATT can be unreliable on Android. While scanning for advertising data usually works very well, we have found that GATT connections fail all the time on about 5% of devices. This is due to poorly implemented OS Bluetooth software. This means beacon manufacturer-supplied configuration apps sometimes can’t connect. The only solution is to use a different phone (or the iOS version of the app on iPhone).

Beacon Advertising While Connected

We have had enquiries asking whether beacons can advertise while they are connected to. Beacons usually just advertise. However, when you setup via the manufacturer configuration app or in special cases, devices (or apps) fetching beacon values requires a (Bluetooth GATT) connection. During this time, beacons stop advertising. This means that, during this time, other devices, and hence apps, can’t see the beacon and can’t connect.

Bluetooth GATT Connection

Beacons are based on standard Systems on a Chip (SoC) provided by one of four manufacturers : Dialog, Nordic, Texas Instruments and NXP. These manufacturers provide standard base software/firmware that is used by the beacon manufacturers. There was a time when the base software didn’t support advertising during connection. More recently, advertising during connection has been become possible but no beacons, we know of, support this yet. Note also that even when beacons do eventually support this, devices, and apps, won’t be able to connect if a connection is already in progress. The advertising will be set as non connectable.

Capacitor Plugin for Bluetooth Low Energy (BLE)

There’s a new Capacitor plugin for Bluetooth LE. Capacitor is new way to build web apps. Capacitor’s native plugin APIs allow easy access to common functionality, such as Bluetooth, across multiple platforms.

The plugin supports the web, Android and iOS. It allows scanning, GATT connecting, reading, writing and notifications. The source code is available on GitHub.

Understanding Bluetooth LE UUIDs

When connecting to Bluetooth devices such as beacons via GATT, APIs are used to connect to specific Bluetooth Services and Bluetooth Characteristics. Services and Characteristics are identified by 128-bit UUID values written as 00000000-0000-1000-0000-000000000000 where each digit is a hexadecimal number. For example, an app might connect to a Service with id D35B1000-E01C-9FAC-BA8D-7CE20BDBA0C6 and then read and write to a Characteristic with id D35B1001-E01C-9FAC-BA8D-7CE20BDBA0C6.

In practice, an interface usually uses similar UUIDs that only change in the xxxx part of the UUID: D35Bxxxx-E01C-9FAC-BA8D-7CE20BDBA0C6. There’s usually a base UUID such as D35B0000-E01C-9FAC-BA8D-7CE20BDBA0C6 and only 16-bits values are provided in the interface documented description.

Here’s an example from the Meeblue beacon documentation:

The Meeblue base UUID is D35B0000-E01C-9FAC-BA8D-7CE20BDBA0C6. When it’s said the UUID is 0x1000, the actual UUID is D35B1000-E01C-9FAC-BA8D-7CE20BDBA0C6.

Read Using Bluetooth Low Energy (LE)

New Python Library

Most use of Bluetooth LE and beacons only looks at the transmitted advertising containing identification and sensor information. More advanced use requires connection to the device using GATT to write, read and be notified of changes in values (Bluetooth Service Characteristics). The most common use for connecting is to set configurable settings as in the case of device manufacturer smartphone apps.

Some solutions need to manipulate Bluetooth Service Characteristics programmatically. Barry Byford has a new Pyton library BLE-GATT for Linux based devices. It’s based on the BlueZ D-Bus API, features a small number of dependencies and can be easily installed without sudo privileges.

Exercising Bluetooth LE GATT

Beacons send most of the time periodically advertising the same data. For setup, apps usually connect to them to set settings such as the advertising period, unique id and power level. The connection is performed using standard Bluetooth GATT.

Bluetooth LE devices connect to others via GATT. Devices such as fitness trackers and our social distancing beacons are regularly connected to, to download data. It’s also common to connect to sensor beacons to extract sensor data.

GATT is usually used via compiled code and it can be time consuming to test GATT devices and/or subsequently use the GATT interface in a flexible way. Should you need to do this, take a look at Bleak GATT client software capable of connecting to Bluetooth LE devices acting as GATT servers. It provides an asynchronous, cross-platform (Windows 10, Linux, Mac) Python API to connect and communicate with Bluetooth devices.

Bluetooth Low Energy in Noisy RF Environments

Michael Spork, Carlo Alberto Boano and Kay Romer of the Institute for Technical Informatics, Graz University of Technology, Austria have a recent paper on Improving the Timeliness of Bluetooth Low Energy in Noisy RF Environments.

The paper looks into the affect of radio frequency (RF) noise on connection based Bluetooth LE communication and provides a mechanism that significantly improves the time taken to send a message in noisy environments. To be clear, beacon-related scenarios rarely use GATT connection based communication and instead use connection-less communication repeatedly broadcasting short packets on 3 advertisement channels (37, 38, and 39). Connection tends to be used only to set up beacon parameters or for more advanced scenarios where a device such as a smartphone connects to the beacon for bidirectional data transfer to get real time data, for example, more timely motion detection.

The authors distinguish their research as experimentally derived as opposed to analytic (just using calculations). They show how the Bluetooth Adaptive Frequency Hopping (AFH) algorithm allows Bluetooth devices to blacklist interfered channels and re-transmit packets on different frequencies until interference is avoided.

The paper shows how the AFH algorithm mitigates the effects of Wi-Fi interference near a Bluetooth master by blacklisting channels. An interesting insight is that the master is unable to detect Wi-Fi interference near the Bluetooth slave and is unable to adapt resulting in UDP messages being significantly delayed.

“Our experiments show that BLE connections are eventually able to successfully transmit all data packets, even under heavy Wi-Fi or Bluetooth interference”

The authors demonstrate that by lowering the connection interval in response to changes in the link quality, an application can reduced the average number of packets delayed from 6.18% to 0.54%.

Read about Bluetooth LE on the Factory Floor