Bluetooth Positioning Using Separate Bluetooth Channels

While we wait for commercial Bluetooth 5.1 direction finding solutions to become available, people are trying to refine traditional locating methods to gain more accuracy. Baichuan Huang, Jingbin Liu, Wei Sun and Fan Yang have a research paper on A Robust Indoor Positioning Method based on Bluetooth Low Energy with Separate Channel Information.

They have observed that the stability of the received Bluetooth signal strength RSSI depends on which Channel 37, 38 or 39 the signal is being received on. This is because the channels slightly overlap the WiFi channels and there can be other Bluetooth devices also using the same channels.

The method analyses the channels over time and chooses those it thinks has least interference and most stable RSSI. This reduces the positioning error by 0.2m, to 2.2m, at a distance of 3.6m.

Read about Determining Location Using Bluetooth Beacons

iOS 13 Location Permission Complexities

Following on from our post on Using Beacons with iOS 13 and Estimote’s post on Get ready for iOS 13: Bluetooth and location changes explained, TechCrunch has an article on how Developers accuse Apple of anti-competitive behavior with its privacy changes in iOS 13.

The gist of the problem is that the ‘Always’ option for allowing the location-tracking permission has become ‘Allow Once’ with the ‘Always’ option being
buried in iOS Settings. People who use location (and beacon) oriented apps, are likely to select the ‘Allow Once’ option and the app will only work correctly once. This will create extra support, customer confusion and general loss of customers. The anti-competitive part comes through Apple’s own in-built apps (currently) not having to live with these restrictions.

To mitigate against the problem we recommend app authors update their apps and online instructions to explain to users to at least initially select ‘Allow While Using App’ and possibly provide more detailed instructions how to set ‘Always’ in Settings.

Bluetooth KNOB Attack is for Classic Bluetooth, not Bluetooth LE

There’s a Bluetooth security vulnerability story doing the rounds that, according to the security researchers:

…affects basically all devices that “speak Bluetooth”

This isn’t true. The vulnerability relates to Bluetooth BR/EDR, so called ‘Classic Bluetooth’, and not Bluetooth LE. It isn’t found in beacons or other devices communicating via Bluetooth LE. It also isn’t found in Bluetooth mesh.

Read about Beacons and the Bluetooth Mesh

Cleaner Staff Tracking with iBeacons

There’s a new solution to track cleaning staff that provides app and web source code to implement a cleaning staff tracking system using iBeacons:

Android screens
Web interface

Manage beacons, buildings, zones and broadcast messages. The web interface shows staff activity and allows staff to be assigned to tasks. Staff can update task status and provide notes from their smartphones.

This solution has been added to the BeaconZone Solutions Directory where you can find more solutions that work with generic beacons.

Bluetooth Mesh, Thread and Zigbee Network Performance

Silicon Labs have a useful web site, webinar and slides on “Benchmarking Bluetooth Mesh, Thread, and Zigbee Network Performance”.

The two main measures of performance are throughput, the rate data transfer that can be achieved (in bits per second) and latency, the time taken for data to cross the network.

With a typical implementation of 6+ hops, throughput converges to a similar order of magnitude for all the protocols:

In real use these protocols only support of the order of low thousands of bits (not bytes!) per sec and should therefore only be used for sending small amounts of data that don’t change very often.

For a small payload with 192 nodes, Zigbee has lowest latency and Bluetooth has greatest variation of latency of 20ms to 200ms:

For a larger payload, the Bluetooth latency has a larger range of up to 750ms:

Whether the variation of latency matters depends on your particular solution. Which technology is best depends on what you need to accomplish. For example, in a Bluetooth lighting scenario you might not want some lights to come on immediately and far ones to come on up to a second later. For sensing, the delay usually doesn’t matter.

You also need to consider other factors such as interoperability, scalability, security, reliability and ease of deployment. For example, Zigbee is less scalable and Silicon Labs recommends a maximum of seven hops otherwise the network becomes congested due to re-tries. Bluetooth has especially good interoperability because it is ubiquitous on smartphones and other devices. It also works reliably in industrial situations and has double encryption.

All protocols can be difficult to deploy due to the lack of off-the-shelf general solutions outside specific verticals such as lighting and home automation.

Silicon Labs have a more specific paper on Bluetooth Mesh Network Performance.

Read about Beacons and the Bluetooth Mesh

Sending Your Own Custom Bluetooth Advertising

We sometimes get asked if it’s possible to send custom advertising. All Bluetooth advertising is based on Bluetooth standards and our post on the Cheat Sheet shows some examples such as iBeacon and Eddystone.

The first question is why you might want to send your own advertising. Using the iBeacon or Eddystone protocol is sufficient in the majority of cases where you just want to a unique id at the Bluetooth LE receiver (usually but not always an app or gateway). The most common case of custom advertising is sensor beacons that need to send their own sensor data.

Nevertheless, some projects use custom advertising that signifies something extra other than a unique id. This is project specific and might, for example, indicate something about location, asset or person. Very few beacons support custom advertising without full re-programming (as opposed to setup). Re-programming involves replacing the SoC firmware and is a significant undertaking. Some of the MeeBlue beacons support setup of a custom channel that can contain any data.

iB003N Supports a Custom Channel

Bettercap for Debugging Bluetooth LE

There’s a useful tool called bettercap that claims to be the “Swiss Army knife for WiFi, Bluetooth Low Energy, wireless HID hijacking and Ethernet networks reconnaissance and MITM attacks”.

While you might want to use it to test Bluetooth LE security, a more interesting use is for debugging Bluetooth LE. If you are scanning for advertising or creating or using GATT, for example with a beacon, it’s sometimes useful to have a separate way of exercising Bluetooth LE.

Bettercap is written in Go and runs on GNU/Linux, BSD, Android, Apple macOS and the Microsoft Windows. However, a bug in Windows and macOS prevents the Bluetooth commands from working. Hence, it’s for Linux or Android only.

Better caps runs in the browser and you can create scripts.

UPDATE: There’s a tutorial on Medium.

Bluetooth Mesh and IIoT in Factories and Warehouses

Dialog Semiconductor, the manufacturer of the SoC chip in some beacons, has an informative article on How Bluetooth Mesh and IIoT are Reimagining Factories and Warehouses. It explains how the recent introduction of Bluetooth mesh has created new opportunities in the Industrial Internet of Things (IIoT).

“The manufacturing industry is absolutely ripe for potential with Bluetooth mesh”

IDC

“Industrial sensors and smart buildings among other use cases, are expected to outpace the overall Bluetooth LE market by 3X through 2022”

Research and Markets

The article mentions preventive maintenance, air quality sensing, asset tracking, robot control systems and traditional air conditioning as possible applications for Bluetooth Mesh. However, a key insight is that once a mesh network is in place it can be used for applications beyond those originally envisaged.

Read about Beacons and the Bluetooth Mesh