Category: Bluetooth LE

Bluetooth Beacon Advertising Protocols

We recently came a cross a very useful diagram, from a research paper, that clearly shows the main Bluetooth LE advertising formats for Bluetooth 4.2, used by beacons:


This clearly shows how the formats, iBeacon, AltBeacon and Eddystone, all sit within a Bluetooth LE advertising protocol data unit (PDU). i.e. They are all use standard Bluetooth LE. Notice also that the advertising data is always short which is partly why it doesn’t use much transmit power and battery. Advertising is sent periodically, every 100ms to 10 seconds, depending on the beacon settings. It only takes of the order of 1ms or 2ms to send the advertising which means the beacon can sleep most of the time, another reason for the low power use.

View All Beacons

Anchor-based Bluetooth Low Energy (BLE) 5.0 Positioning

A recent new paper, BLE-Based Indoor Localization: Analysis of Some Solutions for Performance Improvement, focuses on improving the performance of indoor localisation using an anchor-based system based on Bluetooth Low Energy (BLE) 5.0 technology, specifically employing the Received Signal Strength Indicator (RSSI) for distance estimation. Different solutions to enhance this localisation technology’s performance are explored, with an emphasis on combining various approaches to identify the most effective one. These solutions include different RSSI signal conditioning, anchor–tag distance estimation techniques and methods for estimating the unknown tag position.

An experimental analysis was conducted in a complex indoor environment, marked by the continuous movement of working staff and numerous obstacles. The results showed that the exploitation of multichannel transmission, using RSSI signal aggregation techniques, significantly improved the localisation system’s performance, reducing the positioning error from 1.5 meters to about 1 meter.

Other solutions, such as RSSI signal filtering, distance estimation with an empirical propagation model or Machine Learning (ML), numerical optimisation and ML models for estimating the tag’s unknown position, also impacted performance but to a lesser extent. These solutions resulted in either a decrease or an increase in positioning errors, depending on the specific combination of solutions adopted.

The study’s findings suggest that the use of multichannel transmission and the combination of RSSI signals from different transmission channels are crucial for achieving optimal performance. This approach leverages the full potential of BLE 5.0 technology and is the most significant factor in reducing positioning errors. The paper concludes that the results can guide designers in choosing appropriate solutions based on the desired accuracy of the localisation system. However, it’s noted that the results are specific to the tested conditions and may vary under different operating scenarios.

Bluetooth 4 is Still Dominant

For technology, newer versions typically overshadow their predecessors, but the Bluetooth beacon market has been different. Despite the introduction of Bluetooth 5, the significant majority of beacon applications continue to rely on Bluetooth 4. This is not a mere reluctance to adopt newer technology but a practical decision rooted in compatibility concerns, especially with existing smartphones.

Bluetooth 5 arrived with much fanfare, offering significant improvements over Bluetooth 4. It promised doubled speed, quadrupled range and an eightfold increase in data broadcasting capacity. These advancements opened new possibilities for IoT applications, making it an attractive prospect for beacon technology. However, this leap forward did not translate into immediate widespread adoption in the beacon ecosystem.

The core issue hindering the widespread adoption of Bluetooth 5 beacons lies in device compatibility. The majority of smartphones in circulation still operate on older Bluetooth versions. While Bluetooth 5 is backward compatible, meaning it can work with devices supporting older versions, the reverse is not true. A beacon using Bluetooth 5’s advanced features cannot be fully used by a device that only supports Bluetooth 4.

Bluetooth 4, particularly 4.2, introduced Low Energy (LE) technology, which was a game-changer for battery-powered devices like beacons. It provided an efficient way to transmit small amounts of data over a reasonable range without draining the battery. This efficiency made Bluetooth 4 beacons incredibly popular for a wide range of applications, from retail marketing to indoor navigation and asset tracking.

In real-world scenarios, the extended range and speed of Bluetooth 5 are often unnecessary for typical beacon applications. Most beacon use-cases, like sending notifications or tracking assets, require neither long-range transmission nor high-speed data transfer both of which usually cause more Bluetooth battery use. Bluetooth 4’s capabilities sufficiently meet these requirements, making it a practical choice.

The transition to Bluetooth 5 beacons will likely charge a little as the market penetration of Bluetooth 5-enabled smartphones increases. However, only applications demanding higher data throughput and longer ranges will gravitate towards Bluetooth 5. However, until there is a significant shift in the smartphones, Bluetooth 4 will continue to be the backbone of beacon technology.

In conclusion, while Bluetooth 5 offers technological enhancements, the beacon market’s reliance on Bluetooth 4 is underpinned by practical considerations. Compatibility with the existing smartphone ecosystem and the adequacy of Bluetooth 4 for current applications justify its continued dominance.

Which Beacons Transmit a MAC Address?

A MAC (Media Access Control) address is a hardware identification number that uniquely identifies each device. In the context of Bluetooth, a MAC address is used to identify a specific Bluetooth device, such as a smartphone, headset or a Bluetooth beacon. All beacons transmit a Bluetooth MAC Address which is a 48-bit address usually represented in hexadecimal format like this: 0123456789AB.

All devices such as smartphones can see the incoming MAC addresses that are sent as part of the device discovery stage rather than the main Bluetooth LE advertising payload. iOS is a bit strange and non-standard because it hides detected Bluetooth MAC address from apps, and hence from users, when detecting beacons and other Bluetooth devices.

No such restriction happens on Android or any other device. The rationale is probably that Apple wants you to use their ids, the iBeacon UUID, major and minor or the Peripheral Id rather than the MAC address. Apple also probably think they are protecting privacy in some way. A few beacons and other devices such as sensors and fitness trackers additionally put the MAC address into the advertising payload which circumvents Apple’s restrictions and allows reading of the MAC address by apps.

Does Bluetooth Signal Go Through Walls?

One question that often comes up is whether Bluetooth signals can go through walls. The answer is a bit more nuanced than a simple yes or no.

Bluetooth operates on a 2.4 GHz ISM (Industrial, Scientific, and Medical) radio frequency band. This frequency is also shared by other wireless technologies like Wi-Fi. Bluetooth signals are designed to be robust but are generally short-range, typically extending up to 50 metres. As it uses the same frequency as Wi-Fi which most people have a knowledge of range of, a very rough approximation is to think of Bluetooth as being similar to Wi-Fi.

The material of the wall plays a significant role in how well a Bluetooth signal can pass through it. Materials like drywall, glass and wood are generally more permeable to Bluetooth signals. In contrast, concrete, brick and metal can severely limit or block the signal altogether.

The strength of the Bluetooth signal also matters. Higher-powered Bluetooth devices can transmit signals that are more likely to pass through walls. However, even with a strong signal, the quality may degrade as it passes through obstacles.

The distance between the transmitting and receiving devices will also impact the signal’s ability to pass through walls. The closer the devices are to each other, the more likely it is that the signal will successfully penetrate the wall.

In practical terms, while it’s possible for Bluetooth signals to go through walls, the quality and reliability of the connection can be compromised.

So, does Bluetooth signal go through walls? The answer is yes, but with caveats. The type of wall, the strength of the signal, interference from other devices, and the distance between the connected devices all play a role in determining how well a Bluetooth signal can penetrate walls.

Changing the Beacon Bluetooth Name

Some manufacturer applications permit you to alter the Bluetooth beacon name, whilst others do not. Sometimes this modifies the entire name and other times elements such as the device id or a fixed id are prefixed or suffixed to the name. It depends on the manufacturer. Occasionally, the name may alter but the configuration app and/or phone Bluetooth software can’t discern the modification until the phone is restarted. Often, the phone’s Bluetooth stack doesn’t relay changes in the name.

In instances where the beacon prefixes or suffixes a string, this is typically because the name is being utilised by the configuration app to ascertain something, for instance, compatible beacons able to be connected, within the configuration app.

While we endeavour to inform you through our quick start guides about what’s feasible with name alterations, this frequently becomes outdated as firmware and applications evolve. The optimal method to know is to try it out for yourself.

However, the inconsistency of name-changing functionality across beacon types/versions coupled with the unreliability of seeing name changes in applications means that applications shouldn’t depend on a particular name or the capability to modify a name. We have found it’s preferable to avoid such functionality in applications and utilise the iBeacon or Eddystone ids instead.

Using Bluetooth Metadata to Infer Social Context

Researchers from Idiap Research Institute and EPFL, Switzerland have been looking into the use of smartphone data, include Bluetooth metadata to try to infer social context, for example whether someone is alone or not.

The paper Understanding Social Context from Smartphone Sensing: Generalization Across Countries and Daily Life Moments (pdf) attempts to better understand human behaviour and mental well-being. The paper focuses on the use of passive smartphone sensors, including Bluetooth, to track the social context of individuals over time. In the past, this field of research has been limited by the fact that most studies have only been conducted in one or two countries and often focused on specific contexts such as eating or drinking.

This paper aims to overcome these limitations by using a new, extensive and multimodal smartphone sensing dataset that includes over 216,000 self-reports from more than 580 participants across five different countries – Mongolia, Italy, Denmark, the UK and Paraguay. The goal is to explore the feasibility of using sensor data to infer whether a person is alone or not and to examine how behavioural and country-level diversity influences this inference.

The sensor data comes from 34 different sensors, divided into continuous and interaction sensing modalities. Continuous sensing includes types of activity, step count, Bluetooth, WiFi, location, cellular, and proximity data, while interaction sensing involves app usage, touch events, screen on/off episodes, and notifications. In terms of Bluetooth, the study used both normal and low-energy Bluetooth capturing data on the number of connected devices and received signal strength indicators (RSSI).

The study’s key findings suggest that sensor features can be used to infer the social context. The research also found that models partially personalised to multi-country and country-specific data achieved similar accuracy levels, typically ranging from 80% to 90%. However, the models did not generalise well to unseen countries regardless of geographic similarity.

View sensor beacons

Reverse Engineering iBeacon and Eddystone Bluetooth GATT Services

For some of our beacons such the manufacturers haven’t documented their Bluetooth Service Characteristics. This means that while they are ok for scanning/proximity type applications, you can’t write your own app to, for example, change programmatically the UUID, major and minor, transmit power, advertising period and must rely on the manufacturer’s configuration app. While this of no consequence for the majority of uses that set and forget settings, more ambitious scenarios might want directly access the Bluetooth GATT services to change settings.

Uri Shaked has a great article on Medium on how to Reverse Engineer a Bluetooth Lightbulb. His method uses the developer logging in Android 4.4 and later to allow inspection of the Bluetooth packets and hence the Bluetooth Services and Characteristics that are being used. This method can equally be used with iBeacon and Eddystone beacons to reverse engineer the Bluetooth GATT information.

Another method is to use a Bluetooth sniffer. This listens in on the Bluetooth communication between two devices. One way of doing this is with Nordic Semiconductor’s Sniffer software on a dongle. There’s a tutorial on JimmyIoT.

It’s usually ill-advised to reverse engineer interfaces to discover undocumented features because the manufacturer can change the implementation thus breaking your solution. However, it’s very rare that firmware is ever updated in beacons and when it is, it’s usually only to fix bugs rather than change the implementation.

Processing on Bluetooth Device or Smartphone?

There’s often a dilemma when creating Bluetooth systems whether to place the processing on the smartphone or on the Bluetooth device.

The efficient and accurate prediction of an individual’s heart rate using wearable devices is crucial for various personal care applications. A new study Energy-efficient Wearable-to-Mobile Offload of Machine Learning Inference for Photoplethysmogram-based Heart-Rate Estimation (pdf) from the Universita di Bologna, Italy, looks into the trade-offs between carrying out heart rate tracking on the device itself or delegating the work to a mobile device.

The research introduces CHRIS, an inference system that uses the interconnectedness between a smartwatch and a smartphone. This system assesses the balance between energy consumption and heart rate tracking error. Depending on the connection status, a user-specified error, energy constraints and an estimate of the input difficulty, CHRIS employs two heart rate prediction algorithms. These are executed on either the smartwatch or the phone.

CHRIS showed the potential to achieve up to 2.03 times energy reduction on the smartwatch by deferring processing off the smartwatch, without a reduction on the tracking accuracy.

Predicting Use of Bluetooth Frequency Bands

There’s new research on predicting the channel access of Bluetooth Low Energy (BLE) devices conducted by a team from Silicon Austria Labs GmbH and Johannes Kepler University in Austria. The team aimed to estimate the channels used by multiple BLE connections by passively listening to the channel, with the goal of predicting future channel access to avoid collisions in other wireless networks.

The hardware setup for this research consisted of six Nordic NRF52840 BLE devices that formed three BLE connection pairs, and one sniffer based on the Ubertooth One. This setup allowed the researchers to actively monitor and analyse the BLE channel.

Channel hopping over time

The researchers demonstrated that by passively listening they could reconstruct channel access algorithms for multiple BLE connections in parallel. This approach can be used in new applications to avoid collisions in wireless networks, particularly in applications with high reliability requirements.