Is There a Beacon That Works Without Bluetooth On?

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 Technology for Linux Developers Study Guide

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.

Managing Bluetooth LE Advertising Congestion

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.

Bluetooth LE advertising (from Bluetooth SIG)

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.

Instead:

  • 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.

Need more help? Consider our consultancy services.

Bluetooth LE in Smart Cities

Researchers from Spain have a recent paper on Experimental Application of Bluetooth Low Energy Connectionless in Smart Cities that considers the increased range and improved robustness provided by Bluetooth 5.x.

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.

Transmitting Images via Bluetooth LE?

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.

beaconimageprocessingpipeline

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.

Special Issue Bluetooth Low Energy: Advances and Applications

The MDPI has a special issue of Sensors Journal with a collection of papers related to Bluetooth LE.

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:

Detecting Proximity with Bluetooth Low Energy Beacons for Cultural Heritage

Optimizing the Bluetooth Low Energy Service Discovery Process

Empirical Study of a Room-Level Localization System Based on Bluetooth Low Energy Beacons

Bluetooth Low Energy Interference Awareness Scheme and Improved Channel Selection Algorithm for Connection Robustness

Obstruction-Aware Signal-Loss-Tolerant Indoor Positioning Using Bluetooth Low Energy

Efficient Communication Scheme for Bluetooth Low Energy in Large Scale Applications

Experimental Evaluation of 6BLEMesh: IPv6-Based BLE Mesh Networks

Energy Modeling of Neighbor Discovery in Bluetooth Low Energy Networks

Bluetooth 5.1: An Analysis of Direction Finding Capability for High-Precision Location Services

Bluetooth Low Energy Emulator

Researchers from Japan have created a Bluetooth Low Energy Emulator for testing devices. Their paper, BluMoon: Bluetooth Low Energy Emulator for Software Testing BLE emulator called BluMoon for testing software systems using BLE (pdf), explains how it can be difficult to test how receiving Bluetooth devices’ behave when encountering other Bluetooth devices with varying signal level and interference.

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.

Bluetooth Low Energy Packet Formats

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.

The Bluetooth packet formats are defined by the Bluetooth specifications but specifications aren’t always the fastest and easiest to understand. There’s a new presentation on SlideShare on Bluetooth Low Energy (BLE) Packet formats.

Winfred Lu from STMicroelectronics describes Link layer, advertising, data channel and physical channel packets.

Read about Using Bluetooth Low Energy (LE)

Bluetooth LE Learning Resources

Bluetooth LE development is getting very popular with an increasing number of learning resources. Here are some that have appeared recently:

Erik Hellman, a developer, has two useful articles Bluetooth LE for modern Android Development part1 and part2. He covers Android versions, Bluetooth GATT, PHY, Android Device Manager, pairing and bonding.

Litum have a new article What is Bluetooth Low Energy (BLE)? How does BLE work? that’s higher level and less technical covering Bluetooth LE device discovery, differences to Classic Bluetooth, how positioning works, Bluetooth range , usecases and industries.

Zephyr, the embedded systems OS have also recently updated their Bluetooth documentation.

Setting Up Wi-Fi via Bluetooth LE

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.

How it works

Under the hood, a Bluetooth Characteristic is used to send a RPC Command to set up the Wi-Fi settings.

The code area of the Improv site has an SDK for JavaScript using Web Bluetooth and an SDK for Android. There’s also a device side library for ESP32 devices.