BLE: Enhancing RSSI-Based Distance Estimation

Photo by Alexander Andrews on Unsplash

When working with Bluetooth Low Energy (BLE), advertising is the lifeline that allows peripherals to announce their presence. It’s simple, lightweight, and battery-efficient. But what if we told you that by designing BLE firmware a bit smarter, we could unlock greater flexibility for the app — and significantly improve how we estimate device distance using RSSI?

In this post, I’ll walk you through a key idea: designing BLE firmware to allow app-level control over the advertising frequency range, enabling adaptive behavior and more reliable proximity estimation.

The Problem: Static Advertising ≠ Flexible Applications

RSSI, or Received Signal Strength Indicator, is a measure of how strong a Bluetooth signal is when it reaches the receiver , such as a smartphone or gateway. It gives a rough estimate of how far the Bluetooth device is from the receiver: the stronger the RSSI (closer to 0 dBm), the nearer the device is; the weaker the RSSI (a more negative value like -90 dBm), the farther away it likely is. However, this signal strength is affected by many factors such as obstacles, interference, and antenna orientation. Despite its limitations, RSSI remains one of the most practical ways to estimate proximity or movement in Bluetooth-based systems, especially when enhanced with smart firmware design and adaptive strategies.

Most BLE devices follow a static advertising strategy. Once configured (say, at 100ms intervals), the device keeps broadcasting at that interval — no matter the context, environment, or app needs.

For apps that rely on RSSI (Received Signal Strength Indicator) to estimate proximity — say, in asset tracking or spatial awareness applications — this rigidity is limiting:

• Faster advertising is good for quick discovery, but drains battery.
• Slower intervals save energy but may reduce responsiveness or affect RSSI stability.
• Environmental noise and multipath reflections can make RSSI values jittery, especially with low advertisement frequency.

Yet, there’s no way for the app to tell the BLE device:

“Hey, I need more accuracy right now — please advertise more frequently.”

The Idea: Let the App Adjust Advertising Parameters at Runtime

Instead of hardcoding advertisement intervals in firmware, what if the BLE device supported a custom characteristic that allowed the app to control:

• Advertising interval
• Advertising channel map
• Transmission power

This allows the app to dynamically tune the advertising behavior, based on the scenario. For example:

• Increase frequency temporarily during distance measurement
• Use only specific channels to reduce interference
• Lower power to limit range when needed

Such dynamic behavior opens the door to smarter interactions between the app and the BLE device.

Why It Matters for RSSI and Distance Estimation

RSSI is notoriously unstable due to noise, reflections, and human interference. However, statistical filtering techniques like moving averages, Kalman filters, or even ML-based models require a stable stream of RSSI samples.

If your BLE device is advertising every 1000ms, you’re only getting one sample per second. That’s painfully slow for estimation or interaction. But if the app could temporarily switch the device to a faster advertising rate (say 50ms), it could gather richer data for a short period and then revert.

This is a huge win for:

• Proximity detection
• Indoor navigation
• Asset tracking
• Presence detection in smart environments

How to Implement It in BLE Firmware

Here’s a high-level approach to implementing this idea:

Define a Custom Service and Characteristic

• Example UUID: 0xFFF1
• Payload: JSON or bit-encoded struct for settings like: Interval (20–10240ms)

Handle Write Requests in Firmware

• Parse the values
• Validate against hardware limits
• Stop current advertising
• Apply new settings
• Restart advertising with updated parameters

Protect from Abuse

• Limit the frequency of changes
• Apply only when the device is idle
• Use bonding or authentication if needed

Update the BLE central app to use these new characteristics

• Have an option for the user to opt in to this tracking feature
• If this option is enabled, it will call the new characteristic so the BLE peripheral can apply dynamic advertising
• As this dynamic advertising is optimized for frequency and battery life, we can always keep the scanning operation on, so it can get RSSI, and we can show an approximate distance based on RSSI

A Real Example in Action

In one prototype, we designed the firmware for a BLE-based sensor that could be configured via GATT. Our app requested higher-frequency advertising (20ms) during “scan burst” phases, where an accurate distance was required. After collecting ~50 RSSI samples, it instructed the device to return to its standard low-power 1000ms interval.

The results?

• RSSI variance dropped
• Distance estimation became more reliable
• Battery impact was minimal due to short high-frequency windows

Looking Ahead

As BLE use cases evolve — from industrial asset tracking to personal health devices — app-level control over BLE behavior becomes essential. Designing firmware with such flexibility not only makes your product smarter but also more adaptable across real-world scenarios.

It’s time we stopped treating BLE firmware as a rigid broadcast-only tool and started thinking of it as a collaborator in context-aware applications.

This approach was experimental in our case and tailored to our specific hardware and use case. Advertising frequency, RSSI behavior, and distance estimation can vary significantly depending on your device settings, environment, and antenna design. So, this should not be taken as a generalized solution — but rather as a conceptual guide to help you think about how to design flexible BLE systems that can adapt to different contexts and make smarter use of RSSI.

Stay tuned for a demo app showing this in action!

TL;DR

• RSSI-based distance estimation is sensitive to advertising frequency.
• Most BLE devices use static advertising parameters.
• You can design firmware with a custom characteristic that allows the app to dynamically adjust advertising interval, power, and channels.
• This improves proximity estimation without major power tradeoffs.
• Small change in firmware = Big upgrade in user experience.