Making Bluetooth Indoor Positioning More Reliable with Lightweight Machine Learning

Bluetooth Low Energy direction-finding is becoming an important technology for indoor positioning. In factories, warehouses, offices and retail spaces, it can help locate tools, equipment, staff or customers without relying on cameras or other intrusive sensing systems. Yet one familiar problem still limits its accuracy: signals do not always travel directly from the transmitter to the receiver.

When there is a clear line of sight, Bluetooth angle-of-arrival measurements can be much more reliable. In real indoor environments, however, walls, furniture, metal structures and other obstacles can block or reflect the signal. These non-line-of-sight conditions create multipath effects, where the receiver picks up scattered reflections rather than the direct signal. That can bias the estimated direction and make the final location estimate less trustworthy.

A new study introduces a lightweight machine-learning approach designed to detect when Bluetooth measurements are likely to be unreliable. Rather than trying to fix every distorted signal, the system follows an “identify and discard” strategy. It classifies incoming measurements as line-of-sight or non-line-of-sight, allowing a positioning engine to ignore or down-weight the signals most likely to reduce accuracy.

A key part of the work is that it focuses on Bluetooth-native data. Many existing line-of-sight detection techniques are built for ultra-wideband or cellular systems, where richer channel measurements are available. Bluetooth direction-finding operates under tighter bandwidth and hardware constraints, so the researchers instead use Constant Tone Extension in-phase and quadrature data, known as CTE IQ features. These are the kinds of measurements already available in BLE angle-of-arrival systems, making the approach more practical for real deployments.


To test the idea, the researchers collected labelled Bluetooth measurements in two indoor environments using a u-blox direction-finding development kit. They created both line-of-sight and non-line-of-sight conditions, including the use of a blocker to remove the direct signal path and force the receiver to rely on reflected or scattered signals. This produced controlled datasets that could be used to train and compare different machine-learning models.

The proposed pipeline starts with robust preprocessing to reduce the influence of outliers, which are common in reflected indoor radio signals. The researchers then use principal component analysis to study how line-of-sight and non-line-of-sight measurements differ statistically. Adaptive kernel density estimation helps reveal that non-line-of-sight data often has heavier tails and more irregular spread, especially in higher-dimensional feature spaces.


For classification, the paper compares several approaches, including support vector classifiers, random forests and a small multilayer perceptron. The central contribution is the use of Nyström kernel approximation, which creates a compact nonlinear feature representation without the full computational cost of traditional kernel methods. This matters because Bluetooth positioning systems are often expected to run on embedded devices with limited memory, processing power and latency budgets.

The findings suggest that reliable indoor Bluetooth positioning does not necessarily require heavy machine-learning models or expensive hardware. By designing features around the specific characteristics of BLE direction-finding signals, it is possible to build a practical detector that can flag poor-quality measurements before they damage the final position estimate.

This work is especially relevant for industrial and commercial environments where indoor positioning needs to be robust, affordable and scalable. In the future, this type of line-of-sight detection could be integrated directly into Bluetooth positioning engines, allowing systems to assign confidence scores to angle measurements and make smarter triangulation decisions.

The broader message is simple. Better Bluetooth positioning may depend not only on estimating where a signal comes from, but also on knowing when that signal should not be trusted.

Changes to Delivery

We have made two changes to the delivery of beacon hardware.

For UK deliveries, we now use DPD rather than UPS. After 11 years with UPS, they increased our UK prices considerably, making the service unsustainable for us. UPS has been pruning lower-margin business and restructuring its network, including closing facilities, cutting operational roles and increasing prices for smaller customer accounts. We have be trialling DPD for the last two months and we are confident our customers will see no difference in the service they receive. UK delivery remains a 1–2 day courier service and we have prevented a large increase in delivery fees. For now, we will continue to use UPS for International orders and very large UK orders but this is under review.

We have also stopped delivering beacon hardware to the USA. This is due to a combination of increasingly onerous import documentation requirements, a new arbitrary UPS fee if they contact our customer, the removal of the de minimis limit and continued uncertainty around import taxes.

Experiment Before Committing

We sometimes speak to companies only after they have gone a long way down a particular path, only to discover that an early assumption was wrong. They may have committed heavily to the wrong beacon, chosen the wrong platform, or made assumptions about one of the mobile platforms without doing enough research. In many cases, we can help them get back on track, but not always.

At the other end of the research spectrum are companies that ask us questions such as, “Will beacons work in an xyz environment?” The “xyz” has ranged from underground on the Tube for the police to inside cars for a car retailer. We also hear from many so-called “armchair entrepreneurs” who want to work everything out in theory before they have even handled a beacon.

While we have extensive expertise and provide advice through consultancy, there are often aspects that remain unknown until they are tested in the real environment. Wireless solutions can be unpredictable, and practical testing is often the only reliable way to uncover issues.

A great deal can be learned about beacons, Bluetooth and the environment by buying a single inexpensive beacon and trying things out. For software projects, the equivalent is to build a thin slice of the proposed system, focusing on the areas that seem risky or uncertain. Experiment before committing. Do not invest in thousands of beacons or commission fully customised software until you are confident the solution will work in practice.

Consider a Feasibility Study

MQTT vs HTTP for Bluetooth WiFi Gateways?

Bluetooth WiFi gateways offer MQTT and/or HTTP for sending data to servers/cloud services. We are often asked which should be used. HTTP is what’s used by your web browser to fetch and send data to web servers. In very high level terms, MQTT accomplishes a similar thing but is better optimised for mobile devices and the Internet of Things.

HTTP is very ‘chatty’ which means it’s more complex, code wise, to implement at the sending end and wastes a lot of data and processing power getting information from sender to receiver. You can think of HTTP as wrapping the data within lots other data that gets sent backwards and forwards. MQ Telemetry Transport Protocol (MQTT) came out of IBM, is now an ISO standard and uses lightweight publish/subscribe messaging. It requires a smaller code footprint at the sender and uses less network bandwidth. This matters most when you are trying to get the maximum transactions per second or are being billed for data use.

Bluetooth WiFi gateways are powered via USB and have reasonably powerful microcontrollers so MQTT’s efficient processing doesn’t matter that much. The more efficient processing is more applicable to apps running on mobile devices.

However, being lightweight, MQTT offers faster response times and lower data use than HTTP that, while not necessarily being of much of an advantantage for the BLE WiFi gateway, benefits the communications medium and server side. The communications medium, that can sometimes be cellular or be data constrained, uses (and possibly bills) less data. More crucially, the server can process more requests in less time. MQTT tends to be better when connectivity is intermittent, bandwidth is at a premium and throughput is critical.

In summary, MQTT has lower latency and is more efficient. Whether these are required advantages depends on your actual project. If you need more help, consider our development services.

Monitoring Dementia Patients in Care Facilities Using Beacons

A study was published recently in JMIR mHealth and uHealth. Researchers evaluated a monitoring method that integrated wrist-worn accelerometers with ankle-worn Bluetooth beacons to track individuals with dementia in a long-term residential unit.


The system continuously recorded physical activity intensity, walking bouts, sleep efficiency, and social interactions based on indoor location tracking. The researchers found the beacon-based methodology to be feasible and highly reliable for identifying clinical behaviours, such as wandering, with minimal intrusion.

Should I Use the Manufacturer iBeacon SDKs?

Some manufacturers offer SDKs to allow programmatic access to their beacons from iOS and Android.

Most SDKs tend to be poorly implemented/documented, tie your code into using that particular beacon and rarely get updated to use newer mobile platform APIs. They also tend to be very thin abstractions over the Android and iOS Bluetooth APIs.

If you rely on a beacon manufacturer that doesn’t update their SDK, it’s eventually the case that the underlying Android and/or iOS API changes such that your solution becomes non-optimal and, in the worse case, breaks.

Instead, when you can, we recommend you use the iOS and Android Bluetooth APIs directly to make your code independent of the beacon type. In this way you don’t end up depending on intermediate code and this has the benefit that you can more easily change beacon providers.

Alternatively, use a more regularly updated independent 3rd party library such as Radius Network’s iOS SDK or Nordic’s Android Library.

Training-Free BLE Beacon Detection of Freight Wagon Direction at Railway Control Points

New research proposes a low-infrastructure way to detect whether a freight wagon has entered or exited a station control point using Bluetooth Low Energy RSSI signals. The system uses Eddystone-TLM BLE beacons mounted on wagon bodies and two fixed BLE gateways placed about 15 metres apart. As the metal wagon body passes between the gateways, it shields and delays the received signal in a direction-dependent way. The authors use this asymmetry to infer direction without needing trained machine-learning models, site-specific calibration, axle counters, RFID gates, cameras, or track modifications.

The core innovation is a five-stage signal-processing pipeline. It first detects a likely wagon-passage event using adaptive CUSUM change-point detection, merges fragmented windows, rejects partial or lateral passes, and then classifies direction using a speed-normalised Temporal Centroid shift. For difficult short or high-speed events, it falls back to peak-time and amplitude-based checks. The method is designed to run online with low memory use, making it suitable for embedded deployment at railway control points.

The evaluation covers 151 labelled events collected at Urtaul freight station and a university test polygon, including forward movements, backward movements, higher-speed forward passes, partial approaches, reversals, and lateral paths. The reported overall accuracy is 96.7%, with all 84 true directional events classified in the correct direction and no forward/backward reversals. The main weakness is the “Before-edge” case, where a wagon approaches near the first gateway and reverses; this category achieved 75% accuracy and accounted for all five errors.

The paper’s practical value is that it turns existing or proposed wagon-mounted BLE telemetry beacons into a dual-use sensing system: the beacon MAC address identifies the wagon, while the RSSI pattern gives the direction of movement. This could help station management systems maintain real-time wagon occupancy records.

Devices That Can See Beacons

When people think about beacons they often imagine them being detected in smartphone apps. This post explores other devices that can also see beacons allowing for different interaction possibilities and new scenarios.

Apps – Apps aren’t limited to just smartphone apps. You can run apps on TV boxes that run Android. Just make sure they have Bluetooth 4.3 or later.

Gateways – Gateways are small single pupose devices that look for beacons and send the information on via MQTT or REST (HTTP) to any server. This allows web servers to see beacons.

Desktops and Laptops – PC/Mac devices with built-in Bluetooth or dongles can see beacons.

Walky Talkies – Motorola manufacture the MOTOTRBO range of digital radios that can detect iBeacons and show their location on a map.

Raspberry Pi – This has Bluetooth and can be used to detect beacons.

Arduino – Arduino boards often have Bluetooth and can do things based on the presence of beacons.

Pixl.js – The manufacturer of the Puck.js also supplies a device with a screen that can detect and interact with beacons.

Single Board Computers (SBC) have an advantage over gateways in that data can be cached locally when there isn’t an Internet connection. They can also make decisions locally and send out alerts directly rather than having to rely on a server. This is so called ‘IoT Edge’ computing.

Why is There Variation of RSSI?

We sometimes get asked whether a beacon is faulty because a customer is seeing a lot of fluctuation in the Received Signal Strength Indicator (RSSI) values given by smartphones or gateways seeing beacons, even in a seemingly stable environment and with no change in distance. The short answer is: this is normal. The reason for this lies in the complex nature of radio signals and how they interact with the environment.

Radio signals are susceptible to a variety of factors that can affect their received strength. When a beacon sends out a signal, it doesn’t just travel in a straight line to the receiver. Instead, it disperses in multiple directions and can bounce off walls, floors and other objects.

Reflections can cause the signal to take different paths before reaching the receiver. Each path can have a different length and, therefore, a different time delay. This results in a phenomenon known as multipath fading, where multiple copies of the signal arrive at the receiver at slightly different times. This can cause fluctuations in the RSSI values you observe.

While reflections are a primary cause of RSSI fluctuation, they are not the only one. Other physical changes in the environment can also contribute to this variability. For example, the presence of people moving around can affect the signal, as the human body is mostly water and can absorb radio frequencies. Similarly, other electronic devices emitting radio frequencies can interfere with the signal, causing further fluctuations.

To get a more accurate understanding of the signal strength, it’s advisable not to rely on a single RSSI value. Instead, you should look at many RSSI values over a period of time and calculate the average. This approach helps to mitigate the effects of temporary fluctuations and provides a more stable and reliable measure of signal strength.

Many people, particularly researchers, have looked into the intricacies of RSSI and its variability. Various algorithms and methods have been developed to improve the accuracy of RSSI-based distance estimation and location tracking. For those interested in a deeper understanding or potential solutions to this issue, we recommend looking at the articles tagged RSSI and RSSIStability on our blog.

Using Bluetooth Beacons to Detect Peer Contact

A new paper examines whether smartphone Bluetooth technology, working with small wearable beacons, can detect when young adults are physically near their peers in everyday life. The aim was to move beyond self-report, which can be inaccurate or biased, and test whether passive sensing could identify socially risky situations in real time.

The study involved 21 young adult participants and 55 peers over three weeks. Peers carried small Bluetooth beacons, while participants had an Android app that scanned for those beacons and prompted ecological momentary assessment reports. A beacon encounter counted as meaningful when the beacon was detected within roughly 15 feet for at least 15 minutes, after which the app sent a signal-contingent notification. This meant the beacon system was being used not simply as a tracker, but as a way of identifying sustained peer proximity that might matter for behaviour and intervention design.

Overall, the findings suggest that beacon-based peer detection is promising but still imperfect. The system showed good acceptability: 90% of participants completed the protocol, response rates to app prompts were around 76% to 79%, peers completed 93% of weekly surveys, and peers reported carrying their beacons on 96% of days. Participants generally found the app easy to use, and the researchers judged the protocol to be workable in day-to-day settings.

The paper concludes that Bluetooth beacons have real value for detecting peer proximity in real-world settings, especially for research on health-risk behaviour and just-in-time interventions. The beacons were feasible and acceptable enough to support proof of concept, but technical issues and reliance on peers carrying a separate device limited accuracy.