When working with Bluetooth beacons and/or gateways and looking at raw Bluetooth data it can often become confusing which device is which. When setting up beacons using manufacturers’ apps, it’s a common occurrence for our customers to mistakenly connect to smartphones or fitness trackers rather than a beacon and wonder why the connection doesn’t work.
RaMBLE is a useful Android app that helps decode the Bluetooth devices around you. It attempts to classify devices so you can identify them:
The scanning runs in background and also logs advertising so that the data can be exported for analysis.
There’s lots of activity around using Bluetooth to provide coronavirus contact tracing. Traditional, manual, contact tracing depends on memory recall. Often people can’t remember everyone they have been in contact with and/or don’t have their contact details. Contact tracing is automatic recording who comes into contact with who and then later using this information if one of the people becomes infected. Some solutions use phone to phone interaction while others use beacons. Solutions also vary in that they either have local (usually company), national or global reach.
For national tracing, the Singapore Government was one of the first to have an app, TraceTogether, that already has over 1 million users.
…uses received signal strength indicator (RSSI) values to measure the signal strength between phones. Calibrated RSSI values are used to estimate approximate distance between users during an encounter
The app assigns each user a random id that’s advertised over Bluetooth. Unfortunately, as mentioned in the TraceTogether FAQs:
If you are an iOS user TraceTogether works best in the foreground
The more reliable and battery efficient way to detect Bluetooth in iOS, in background, is to use the iBeacon protocol.
In the United Kingdom, NHSX, the health service department driving digital transformation of health and social care is reported to be developing a contract tracing app together with VMWare and University of Oxford’s Nuffield Department of Medicine. Wired has an article where they mention that it’s being considered whether the app might be extended to monitor social distancing measures and alerting users if they have been spending more than one hour out of their homes. While useful, this might undermine trust and cause people to not use or uninstall the app. An article ‘NHS phone app holds key to lifting lockdown’, in the 12th April Sunday Times (behind paywall) says the UK Government is looking into incentives to install the app, perhaps linking to resumption of work and normal activities.
Meanwhile, Approov has a white paper describing a potential approach for using Bluetooth for privacy preserving proximity matching. It provides a private anonymized approach to tracing and suggests a P6 Protocol, based in iBeacon, for improving reliability on iOS.
With all these approaches and solutions, the contract tracing problem needs to be put into perspective:
Solutions are only useful when the majority of people participate. Those most likely to have the illness longer, the elderly, are less likely to have smartphones.
Solutions are more useful at the start or end of a pandemic when there’s fewer infections and less data to be acted on.
Solutions are only useful when there are people who are acting centrally on the contact alerts and following up on the data.
Solutions don’t help trace contacts for situations where the infection is by touching something rather than human to human contact.
iOS solutions are inherently limited by Apple’s crippled Bluetooth functionalty.
Both on iOS and Android, recent privacy and battery saving features that have made normal apps more difficult to develop will have the knock on affect of stymieing efforts in developing contact tracing apps and cause some people to turn off permissions that prevent the app working properly.
Any solutions based on Bluetooth signal strength (RSSI) can’t determine exact distances and are affected by blocking.
Update 10 April: Apple and Google have announced a global solution, available May 2020, that includes application programming interfaces (APIs) to assist in enabling contact tracing using Bluetooth. In time, they will build contact tracing into iOS and Android to make it “more robust”.
Today’s Bluetooth devices use advertising, GATT connection and mesh. Advertising occurs over three channels to reduce the affects of wireless interference. When more than one device advertises at the same time, the data is lost. However, advertising takes of the order of 1ms so the chance of collision is usually small.
In contrast, BlueFlood uses concurrent transmissions (CT) that purposely synchronise transmissions such that if colliding packets are tightly synchronised and have the same contents, the resulting signal might be distorted, but highly probable that they do not destruct each other. This is used with the Glossy flooding protocol and 40 rather than 3 advertising channels.
CT-based protocols achieve enormous performance gains in terms of end-to-end reliability, latency and energy consumption even under harsh interference conditions
Concurrent transmissions are challenging using Bluetooth because transmissions need to be synchronised down to 250ns. Nevertheless, the researchers show this is possible using standard Bluetooth PHY and commercial Nordic SoCs. They achieved an end-to-end loss rate below 1% and managed to receive the signals on a standard smartphone. While the mechanism was fragile it was found to be viable.
Silicon Labs is a Bluetooth module manufacturer and solutions provider. Over the years they have created a large number of useful technical notes. They have just created a master list that allows easier access to the notes. Here are some that more general, less proprietary and not specific to Silicon Labs’ modules:
We have a new article Using Bluetooth Low Energy (LE). It explains how beacons use Bluetooth LE. We provide a high level description how other Bluetooth LE devices such as smartphones, gateways and single board computers communicate with Bluetooth devices such as beacons.
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%.
Bluetooth beacons use Bluetooth LE, a low power version of Bluetooth to repeatedly send out a short amount of data typically up to 50m but in some cases hundreds of metres. The data usually includes an identifier in various standard formats such as iBeacon or Eddystone. It can also include sensor data.
The beacon advertising can be picked up by other Bluetooth LE devices such as smartphones, WiFi gateways to send to a server and single board computers such as the Raspberry Pi.
The key features are:
Low power and hence can work for up to years on battery power
Interoperability with a large number of other Bluetooth LE devices
The Bluetooth SIG, who create the specifications for Bluetooth, have a new Bluetooth Range Estimator that takes into account the environment, transmit power, antenna gain and received gain to provide an estimated range.