Why distance estimates move
Raw RSSI (Received Signal Strength Indicator) data from Bluetooth beacons is inherently unstable. Even when a beacon and a receiving smartphone remain perfectly still, the reported signal strength will fluctuate by several decibels milliwatts (dBm) from one packet to the next. This noise is caused by multipath interference—signals bouncing off walls, floors, and furniture—as well as the human body absorbing radio frequencies and minor hardware variations in the receiving device.
Filtering and smoothing are the mathematical techniques applied to this raw data stream to produce a stable, usable value. Without them, any system relying on RSSI to estimate distance or trigger a zone entry will behave erratically, firing notifications repeatedly or showing a user's blue dot jumping across a map.
A critical point often misunderstood during procurement: the beacon itself does not perform filtering. The beacon simply broadcasts a radio packet at a set power. All filtering and smoothing happen on the receiving side—inside the mobile app, a dedicated scanning gateway, or the backend server processing gateway data. When evaluating a proximity platform, the questions about filtering should be directed at the software receiving the signals, not the hardware transmitting them.
Core Filtering Methods
Several standard algorithms are used in proximity systems, each with distinct trade-offs:
- Simple Moving Average (SMA): Calculates the mean of the last N RSSI readings. It is straightforward to implement and effectively dampens random spikes. However, it treats all N readings equally, meaning an older reading carries the same weight as the most recent one, which introduces lag.
- Weighted Moving Average (WMA): Assigns a higher mathematical weight to the most recent readings. This reduces lag compared to SMA while still smoothing out noise, making it a common choice for retail and museum environments where visitors move at a walking pace.
- Median Filtering: Rather than averaging, this method sorts the last N readings and selects the middle value. It is highly effective at ignoring sudden, massive spikes—such as a person walking directly between the phone and the beacon—which would skew an average-based filter.
- Kalman Filtering: A more complex predictive algorithm that estimates the true signal state while accounting for measurement noise and movement. It is useful for asset tracking where tagged items move through variable environments, but it requires careful tuning of parameters to avoid becoming unstable.
Build thresholds from observed data
The choice of filtering technique cannot be separated from the physical use case and the broadcast interval of the beacons. A filter that works perfectly for a slow-moving museum visitor will fail for a forklift in a warehouse.
Zone Triggering in Retail and Museums
When the goal is to trigger a notification as a visitor enters a specific zone—such as a new exhibition wing or a promotional aisle—precise distance calculation is less important than boundary stability. A median filter combined with a short WMA is typically effective here. It prevents a visitor standing exactly on the boundary of a zone from causing the system to rapidly trigger and dismiss the notification. The system only fires when the smoothed value consistently crosses the defined RSSI threshold for a set number of consecutive packets.
Asset Tracking in Warehouses
In logistics environments, gateways mounted on ceilings scan for tags on pallets. Metal racking and moving machinery create severe multipath interference, leading to wild RSSI spikes. Median filtering is particularly valuable here because it discards these anomalous spikes rather than averaging them into the result. The latency introduced by the filter is acceptable because pallets do not require real-time, centimetre-precise tracking.
The Latency Trade-off
Every filtering technique introduces a delay between the physical change in distance and the system recognising that change. If a beacon broadcasts at 1 Hz (once per second) and the app uses a simple moving average of five readings, the system will take five seconds to reflect a sudden movement. To reduce this latency, you must increase the broadcast interval (e.g., to 10 Hz), but this directly reduces battery life. For illustrative purposes, moving from a 1000 ms to a 100 ms broadcast interval can drastically reduce smoothing lag, but will typically shorten a standard coin-cell battery's life from over a year to a matter of weeks. The filtering parameters must be balanced against the hardware's power constraints.
Use the result without overclaiming accuracy
Filtering can refine noisy data, but it cannot fix fundamental physical limitations. Understanding where these techniques break down prevents unrealistic expectations during a pilot.
Over-Smoothing and Under-Smoothing
The most common operational mistake is using a filter window that is too large for the environment. Over-smoothing eliminates noise but introduces so much lag that a user walking briskly through a venue triggers the notification only after they have left the zone. Under-smoothing keeps the system responsive but allows noise to cause false triggers. During a pilot, this manifests as visitors complaining about duplicate notifications or missing them entirely.
Filtering Cannot Correct Multipath Errors
If a signal is bouncing off a metal wall and arriving at the receiver stronger than it would over a direct line of sight, the RSSI will falsely suggest the beacon is closer than it actually is. Smoothing this data simply produces a stable, incorrect distance. Filtering manages noise; it does not resolve the physics of radio propagation. In environments with high reflectivity, zone-based triggers (where exact distance is irrelevant) are far more reliable than distance-based triggers.
Key Questions for an Integrator or Platform Provider
When reviewing a proximity system, the filtering logic is a strong indicator of technical maturity. Useful questions to put to a supplier include:
- Where does the filtering logic reside (on-device in the app, on the gateway edge processor, or in the cloud)? Edge processing reduces latency and cloud costs.
- Which specific algorithms are available, and are the window sizes and weights configurable per deployment, or are they hardcoded?
- How does the system handle a beacon dropping out of range and returning? Does the filter reset, or does it carry stale data that slows down the re-entry detection?
- How does the platform behave when the receiving device's Bluetooth scanning interval changes (which happens frequently on Android to preserve battery)?
Finally, ensure the filtering parameters are documented as part of the site's operational handover. If the venue layout changes—such as installing new shelving or moving a partition—the filter settings that worked previously may need recalibration to account for the new interference patterns.
