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.
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:
Bluetooth 5 advertising extensions – This allows advertising of more data, that takes longer than the typical 1 to 2 ms and hence increases congestion.
Bluetooth longer range – This transmits further thus effectively increasing the number of beacons advertising in a given area.
Bluetooth Mesh – This works by having relay beacons listen and re-transmit advertising, usually several times, to improve reliability.
Bluetooth direction finding – This also has longer advertising to send a constant tone extension (CTE) that is received by AoA hardware. However, of more affect is advertising more frequently. While beacons on assets used to advertise typically every second or longer, direction finding tends to use faster advertising to improve latency.
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.
Lower the transmit power so that beacons cover a smaller area. You can fine tune this using nRF Connect to measure the distance you need rather than needlessly advertising further. This will also conserve battery life.
Increase the advertising period to make collisions less likely.
Increase the receiver scanning period to make detections more likely.
Seek out and remove unwanted devices advertising too frequently, such as fitness devices, smartphones, displays and even cars.
The paper describes the various types of communication:
The paper includes a description of Bluetooth LE including advertising and the different physical layer modes.
There’s an experimental evaluation of the new, more-robust, long-range radio mode when used in smart cities scenarios. The I2V scenario is evaluated, where reception is measured against variation in distance and vehicle speed. The I2P scenario is evaluated against interference from WiFi and classic (non LE) Bluetooth.
The researchers found an overall packet loss of 20–30%, regardless of mobility speed, compared to the static scenarios. The classic Bluetooth 4 mode was found to be more immune to coexistence with the WiFi protocol than any BLE 5.x mode. The researchers say this is because Bluetooth 5 extended advertisements 1) make use of more than one channel and 2) have longer data are both can cause more susceptibility to interference. Nevertheless, the updates introduced with Bluetooth 5 allow broadcasting over much longer distances.
The paper concludes the maturity and low cost of the technology could enable fast, easy deployment in smart cities compared to other solutions.
Some platform providers claim beacons can transmit multimedia data which isn’t strictly true. A beacon sends a small amount of data that typically contains a unique id. When an app sees an id it shows information, such as an image, that is typically obtained from a server.
But what about beacons actually transmitting images? Chong Shao, Shahriar Nirjon, Jan-Michael Frahm or the Department of Computer Science, University of North Carolina has a paper on “Years-Long Binary Image Broadcast using Bluetooth Low Energy Beacons” (pdf). Again, don’t be misled, they don’t mean it takes years to send an image but instead that a beacon might transmit for a long time (which most do).
The researchers have found that with suitable compression schemes, a set of 2–3 beacons is capable of broadcasting high-quality images (75%–90% structurally similar to original images). The image quality improves when more beacons are used.
How might you get the data into a beacon? Well, some beacons such as the M52 Plus and iB003N allow arbitrary data to be set in the advertising data.
The images are necessarily very simple but nevertheless this provides a great example of what can be achieved when you attempt the seemingly impossible.
BLE applications can be found in a wide range of domains, e.g., smart home, smart cities, smart health, smart agriculture, or Industry 4.0. BLE is enabling the interaction between humans and smart objects, as well as between smart objects themselves. BLE has also been leveraged for innovative location-based applications, opportunistic data collection and crowd-sensing.
All the papers are available free of charge under open access:
The signal level and interference vary change depending on the position of the sender and receiver. They also vary depending on the surrounding environment. The signal level (RSS) is affected by reflection, shielding, and diffraction by surrounding objects, walls and the ground. Instead, testing requires known signal level and interference values.
The paper describes a software-implemented BLE controller, BluMoon, that calculates the received signal strength for each frame and imitates radio interference. The emulator replaces the controller with the HCI as the boundary.
BluMoon performs BLE communication emulation frame by frame and is implemented on Linux using the BlueZ Bluetooth stack.
In most cases, it’s possible to use beacons without knowing the exact data format of the advertising. It’s usually possible to specify only a few values such as iBeacon UUID, major and minor and the devices and listening apps work together. In some instances it’s necessary to know Bluetooth LE packets formats, for example, to implement your own code.
Many gadgets and IoT devices need to connect to the Internet via WiFi. The problem is getting the WiFi credentials to the device when it isn’t connected yet. It’s a ‘chicken and egg‘ situation in that you need to connect to the device in order to set the WiFi settings but you can’t connect because you aren’t WiFi connected.
The usual, but complex, way to solve this is for the device itself to initially act as a WiFi router in ‘station mode’ while the user on a phone, laptop or desktop connects and uses a web interface to set the WiFi settings and then reboot. After rebooting, it’s not in station mode and instead connects to the assigned access point. The assigned local network DHCP IP address isn’t known to the user so they have to examine router settings or use some other contrived method to work out the URL to further administer the device.
None of this is simple for most users so alternative mechanisms are preferable. We previously mentioned Android WiFi Direct via Bluetooth and now there’s a new open standard, Improv, for setting up Wi-Fi via Bluetooth LE.
For Improv, the client (web or mobile) application sends the Wi-Fi credentials to the gadget via a defined Bluetooth LE Service (00467768-6228-2272-4663-277478268000). The device connects to the WiFi and returns a URL on the network that can be used to further administer the device.
Under the hood, a Bluetooth Characteristic is used to send a RPC Command to set up the Wi-Fi settings.
We now have the INGICS iGS03E Bluetooth to Ethernet gateway in stock. This differs to the iGS02E in that it includes Power over Ethernet (PoE) without having to have an external PoE splitter.
Gateways look for Bluetooth LE devices and sends their advertising on to a server via TCP, HTTP(S) or MQTT including AWS IoT. If you use with sensor beacons, this provides a quick and easy way to provide for IoT sensing.
The iGS03E is one of the first gateways to also support Bluetooth 5 in Long Range mode (LE Coded PHY), although very few advertising devices support this yet.