Understanding Bluetooth LE Reliability

We have previously written about Bluetooth LE on the Factory Floor and Why Bluetooth LE Scanning Doesn’t Always See Devices (the First Time).

There’s a new informative paper by Martin Woolley of the Bluetooth SIG on How Bluetooth® Technology Makes Wireless Communication Reliable. It describes in detail how radio collisions, multi-path propagation, time-dispersion, transmitter-receiver synchronisation, signal strength, receiver sensitivity and buffer overflow can collude to make radio communications unreliable.

The paper explains how Bluetooth modulation schemes, CRC checks, multiple channels, coded PHY, adaptive frequency hopping, flow control and the ATT protocol work to make Bluetooth LE reliable.

The paper also takes a look how Bluetooth Mesh has been designed to achieve reliable communication.

Why Bluetooth LE Scanning Doesn’t Always See Devices (the First Time)

Bluetooth devices such as beacons periodically advertise data according to a pre-defined format such as iBeacon or Eddystone. The advertising is very short, of the order of 1ms. Listening devices such as apps or gateways scan for a defined time, the scan window, periodically every scan interval. The scanning scan window is usually less than the scan interval to conserve power because scanning is power intensive.

While scanning nearly always sees a nearby device, there can be times when it isn’t seen due to physical and technical reasons. Radio signals can get blocked and reflected in ways that cause them not to be received. Also, if two Bluetooth devices happen to advertise at the same time then the received radio signal is corrupted. It’s also possible that because scans stop and start, the advertising happens when the scan isn’t running.

In practice the chance of non-detection happening is small. The chances of it happening again, the next scan, are very unlikely. If a beacon isn’t seen on the first scan it’s usually seen on the second (or third) attempt.

Bluetooth has some mitigations to help reduce the occurrence of the above mentioned situations. The advertising and scanning happens on multiple channels (frequencies) 37, 38 and 39 to reduce the affect of interference from other devices. Also, the advertising interval isn’t fixed and varies by a random amount, the advertising delay, for up to 10ms, to prevent two (or more) devices’ advertising continually colliding.

The consequence of scanning possibly not seeing beacons (the first time) is that solutions using apps or gateways must not rely on only one scan to make decisions on the absence of a beacon.

Advanced Bluetooth on Android

Martin Woolley of the Bluetooth SIG was a recent speaker at Droidcon EMEA where he spoke about Advanced Bluetooth for Android Developers (slides).

Android Bluetooth LE Stack

Martin covered scanning, GATT, how to maximise data rates, speed vs reliability and using different PHY for enhanced range or data rates. The second part of the talk covers Bluetooth Mesh and proxy nodes.

One thing not mentioned in the slides, to be careful of, is that connection via a proxy node is relatively slow because it’s limited by the GATT connection. Proxy nodes are good for controlling (sending small amounts of data into) a Bluetooth Mesh but poor if you want to use the connected Android device as a gateway for all outgoing data.

Martin also has a blog where you can also learn about his past talks and he will be part of the new Bluetooth Developer Meetup.

Read about Beacons and the Bluetooth Mesh

Bluetooth Developer Meetup

There’s a new (virtual) Bluetooth Developer Meetup group.

Developers will share their knowledge and tell their stories of working with everybody’s favourite low power wireless communication technology

The first event will be on 15th October 2020 at 17:30 UK time (UTC+1) and will include the following speakers:

  • Jacky Cheung, Google
  • Kevin Picchi, Samsung
  • Thea Aldrich, Foundries IO
  • Martin Woolley, Bluetooth SIG

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.

Understanding Bluetooth LE Advertising

There’s a new video of the Nordic Semiconductor webinar on Everything you need to know about Bluetooth LE advertising. It covers the basics of Bluetooth LE including advertising and data formats. It explains how to use the nRF Connect SDK API and provides a demo. It also shows how to use nRF Sniffer to examine Bluetooth LE data packets.

Bluetooth LE Advertising Channels

The presentation and Q&A are also available.

The video mentions advertising extensions. These are only in Bluetooth 5. Most current devices only support Bluetooth 4.2 legacy advertising. Growth in numbers Bluetooth 5 devices has been limited due to the non-compatibility with the majority of smartphones. It’s for this reason that devices that are Bluetooth 5 usually communicate using, backward compatible, legacy advertising. Extended advertising is also an optional feature of Bluetooth 5.

Developing for Bluetooth LE

If you are developing code for Bluetooth LE, a great place to start is the GitHub bluetooth-low-energy topic.

GitHub currently lists 877 public repositories that cover every operating system. This includes programming with Java, Javascript, C, Python, C++, Swift, Kotlin, C# and Objective-C.

In many cases it’s best to use the repositories to see how to do things rather than use the libraries themselves. Most, but not all, libraries are thin layers over operating system APIs. Most libraries don’t get updated and it’s otherwise easy to later get trapped into dependencies you don’t need, particular ways of working or old ways of using the underlying OS.

App cross platform frameworks are another source of problems when programming Bluetooth LE. They also aren’t updated often nor provide optimal Bluetooth APIs. If you wish to ease Bluetooth LE development and retain flexibility for future changes then use the native programming languages and libraries.