iBeacon, Eddystone, Bluetooth, IoT sensor beacons, apps, platforms
There’s a useful new article at Stormotion on how to use Bluetooth LE with React Native. The article explains the difference between Bluetooth LE and Classic Bluetooth and details the differences between the two main libraries when integrating Bluetooth LE into React Native apps.
The article also provides information on what apps to use to test Bluetooth LE and has insights on how to avoid the common problems.
There’s new research from University of Washington on BLE-Doubt: Smartphone-Based Detection of Malicious Bluetooth Trackers University of Washington (PDF).
Stalkers can hide Bluetooth beacons on targets’ clothing or in vehicles so as to monitor their locations. The researchers created an open-source method of detecting maliciously deployed Bluetooth beacons.
The algorithm detects malicious devices within a few minutes. The software scans for Bluetooth advertisements and stores a history so that an alert can be created if a beacon is following the same route as the user.
iBeacon, Altbeacon, Eddystone, Tile, Chipolo, Spot, and AirTag are all detected with AirTags the greatest challenge due to rotation of their MAC addresses between every two hours and once a day and their erratic and unpredictable advertising.
The app doing the scanning causes heavy smartphone battery use. The smartphone lost between 5% and 10% of its battery per hour during active scanning.
Need to decode a Bluetooth advertising packet? reelyActive have an online web form that decodes wireless advertising packets:
It’s also open source so you can use the code in your own projects.
There’s a useful recent Webinar at Nordic Semiconductor on Measuring distance with the Nordic Distance Toolbox. The Nordic Distance Toolbox (NDT) provides ways to measure the distance between two Nordic SoCs. An SoC (System on a Chip) is the main chip found in beacons and Nordic is one of the main manufacturers.
The webinar covers the theory of distance measurement based on radio phase, RSSI, Round Trip Timing (RTT) and processing such as Inverse Fast Fourier Transform (IFFT). Practical performance is measured and the conclusions are:
The presentation PDF is also available.
Using the SoC radio to determine distance is power-hungry, relatively complex to develop and, as the above shows, doesn’t result is very good accuracy. If you want to measure distance it’s simpler, more accurate and more battery-efficient to use a dedicated hardware-based distance sensor. For example, the IBS03R uses a dedicated time of flight (TOF) sensor to achieve accuracy of +-25mm and a battery life of 1.8 to 2.8 years.
There’s a new book Develop your own Bluetooth Low Energy Applications by Koen Vervloesem. It introduces Bluetooth Low Energy and shows how to programming with Python and the Bleak library on a Raspberry Pi or PC, with C++ with NimBLE-Arduino on Espressif’s ESP32 development boards and with C on Nordic Semiconductor’s nRF52 boards.
Koen has a blog where you can read an abridged version of the book. He explains Bluetooth Low Energy, the Bluetooth stack, advertising and connecting. You can also view the samples on GitHub.
Barry Byford has a new blog post on D-Bus and Bluez. It documents his experiences creating a BLE central client on Linux. Barry deliberates over dbus-python and pydbus. He then provides an example how to create a Bluetooth GATT connection, converting D-Bus typed data to python types and interacting with a BBC micro:bit.
While you are on Barry’s site, read his notes from workshops and further notes on using Bluetooth.
The Bluetooth LE specifications are very technical and not very approachable for those wishing to use, rather than create, devices using Bluetooth. Bluetooth SIG, who manage the Bluetooth specifications, have a new document by Martin Woolley titled The Bluetooth® Low Energy Primer. This is the definitive guide to better understanding Bluetooth LE.
This free document covers the history of Bluetooth LE and explains the various layers in the Bluetooth stack. It describes the protocols and profiles that make up Bluetooth LE. It also provides pointers to study guides, papers, hands-on resources and formal specifications for further reference.
We sometimes get asked if it’s possible that smartphones can detect beacons without Bluetooth being on. All beacons are based on Bluetooth LE that, in turn, relies on Bluetooth being switched on in the phone to scan for beacons. There’s no magic underling operating system mechanism on iOS nor Android that allows you to use Bluetooth without the user having Bluetooth on.
More users are leaving their Bluetooth on due to the proliferation of connecting with other devices such as cars, Bluetooth headphones and smart speakers. If you are writing an app you should take steps to detect if Bluetooth is on and prompt the user appropriately.
The phone and beacon industries need to better educate users that Bluetooth is no longer the heavy battery drainer it was in the early days of smartphones.
The Bluetooth SIG has a new Bluetooth Technology for Linux Developers Study Guide. It explains how Bluetooth is implemented in hardware as part of the main board or added using a USB dongle. The Bluetooth stack runs as a system service using BlueZ. BlueZ is accessed via inter-process communication (IPC) via D-Bus, a message-based system service. Applications use D-Bus and hence BlueZ.
While the study guide is helpful, we suggest you also explore the Bluetooth APIs available from your chosen programming language. We have never had to program at the D-Bus level. Take a look at the Node, Javascript, Arduino, c, c++, Rust, Python and Java Bluetooth APIs and libraries.
Bluetooth LE advertising congestion happens when there are too many Bluetooth devices in an area. As we will show, this rarely happens but with new Bluetooth technologies this situation is becoming more likely. We provide some ways to mitigate congestion.
Bluetooth LE advertising transmits periodically the period of which is configurable from typically 100ms to about 10 seconds.
If two Bluetooth devices happen to transmit at the same time, it’s like two people shouting at the same time. The signal is corrupted, the receiver can’t make sense of the signal and it is lost. This usually doesn’t matter because it’s likely the signal is seen the next time it is sent. The random advDelay in the above diagram ensures that the two sends don’t clash again. It’s very unlikely advertisers clash in the first instance because the transmit duration is very small compared to the advertising period. The above diagram isn’t to scale. Here’s an oscilloscope trace showing some real timing:
The advertising duration is very small, of the order of 1 to 2 ms (milliseconds). Advertising is also sent three times, on three different radio frequencies, so that if one is blocked, the radio signal might be heard on one of the others. All this means that advertising collisions rarely occur.
However, there are some newer Bluetooth protocols that as they are starting to roll out, are making collisisons more likely:
You can check how many devices are advertising by using a scanning app on Android. We recommend Nordic Semiconductor’s nRF Connect because it can decode the latest Bluetooth protocols. Use Android for full visibility because Apple made the poor design decision to obfuscate iBeacon advertising to coerce developers to only use the Apple iBeacon-specific APIs. Apple also hides devices’ MAC addresses making them more difficult to physically identify.
If you have a problem with congestion you might be tempted to increase the transmission power or advertise more often to increase the chances of being seen. However, this is counter-productive because you will be increasing congestion, especially if your devices are the main contributor to the congestion.
Instead:
Need more help? Consider our consultancy services.