What Is RSSI?
RSSI stands for Received Signal Strength Indicator. It is a measurement, expressed in decibels relative to a milliwatt (dBm), of the power present in a received radio signal. In the context of Bluetooth Low Energy beacons, RSSI is the value that a receiving device—typically a smartphone, a gateway or a dedicated scanner—assigns to the signal it picks up from a beacon.

Because RSSI is measured at the receiver, it is not a fixed property of the beacon itself. A beacon may broadcast at a configured transmit power, but the RSSI that any given device records depends on the distance between the two, the materials in between, the receiver's antenna design and the immediate radio environment. Values are always negative: a figure closer to zero, such as −40 dBm, indicates a stronger received signal than a figure further from zero, such as −80 dBm.
Understanding this distinction matters because many deployment mistakes start from the assumption that RSSI is a stable, predictable number. In practice it fluctuates, and treating it as a precise distance reading leads directly to unreliable zone detection and poor user experiences.
How RSSI Relates to Distance
In free space—no walls, no furniture, no people—radio signal strength decays following the inverse-square law. As the distance from the transmitter doubles, the received power drops by roughly 6 dB. This relationship allows a theoretical conversion from RSSI to distance using a log-distance path loss model, but the model requires an accurate reference measurement at one metre and a path loss exponent that accounts for the specific environment.
The difficulty is that very few real-world venues resemble free space. A retail unit with metal shelving, a museum with stone walls and glass cases, or an exhibition hall with temporary partitions all alter the path loss exponent in ways that are difficult to predict without measurement. A signal passing through a brick partition might lose 8–12 dB compared to an unobstructed path of the same length, but the exact loss depends on the wall's thickness, composition and whether it contains metal reinforcement or services.
Floor plans, ceiling height and even the presence of stock on shelves change the radio environment as occupancy and layout shift. This is why any system that converts RSSI to an estimated distance must be calibrated on-site, and why that calibration only remains valid for as long as the physical space stays the same. A rearrangement of display units or the addition of a temporary exhibition can invalidate previous measurements within hours.
RSSI Variability Across Devices
Two phones held at the same spot, at the same moment, facing the same beacon will often report different RSSI values. This happens because antenna design, radio chipset, phone case material and operating-system signal processing all differ between manufacturers and models. An iPhone and a mid-range Android device may consistently differ by 5–10 dB in the same position, and the gap is not predictable without testing both devices.
Device orientation adds further variation. Holding a phone flat in front of you produces a different antenna pattern to holding it upright against your ear or at an angle in your hand. The human body itself absorbs and reflects Bluetooth signals, so a reading taken with the phone in a pocket will be lower and more erratic than one taken with the phone held in front of the torso.
For deployments that rely on a single device type—such as venue-provided handheld guides—this variability is manageable because the hardware is consistent. For deployments that depend on visitors' own phones, the system must account for a wide and shifting range of receiver characteristics. This is one of the practical reasons why zone-based triggers (detecting that a device is somewhere near a beacon) tend to be more robust than point-location estimates (calculating an exact position in metres).
Measuring RSSI in a Real Environment
Reliable RSSI measurement starts with a clear method. Walking through a venue holding a phone and glancing at a scanning app produces anecdotal data, not a usable baseline. A practical measurement process looks more like this:
- Define measurement points. Mark specific locations on the floor plan—at one metre from the beacon, at the intended zone boundary, at the next beacon's overlap region and at any points where obstacles sit between beacon and receiver.
- Use consistent hardware. If the deployment targets visitors' own devices, measure with at least two or three common phone models. If the deployment uses dedicated scanners, measure with those scanners.
- Record multiple samples. At each point, collect enough readings to see the spread. A set of 20–30 readings over 30 to 60 seconds reveals the typical range and any intermittent spikes or drops.
- Document conditions. Note the time of day, the number of people in the area, whether doors are open or closed and the position of any movable objects. These details matter when you later need to explain why readings have changed.
- Store results with context. A spreadsheet of raw numbers is hard to interpret later. Link each set of readings to a labelled point on the floor plan and to the specific beacon identifier and transmit-power setting used.
This process does not need to cover every square metre of a venue. Focus on the points where zone boundaries and trigger decisions actually happen. The goal is to know, with measured confidence, what RSSI range a device is likely to report when it enters, dwells in or leaves a given zone.
RSSI Filtering and Smoothing Techniques
Raw RSSI readings jump around. A single reading might swing by 10 dB or more from one second to the next, even with the receiver stationary, because of multipath interference—signals bouncing off surfaces and arriving slightly out of phase. Feeding unfiltered RSSI directly into a zone-detection algorithm produces flickering triggers: a user appears to enter and leave a zone several times in a few seconds, which in turn causes repeated notifications or erratic wayfinding behaviour.
Simple Moving Average
The most straightforward approach is a moving average over a window of recent readings. A window of five to ten samples smooths out short spikes while still responding to genuine movement. The trade-off is latency: a larger window produces a more stable value but delays the system's reaction when a user actually crosses a zone boundary. For a museum exhibit trigger, a slight delay is usually acceptable. For a safety-critical zone alert, it may not be.
Median Filtering
Taking the median of a small window—typically three to seven readings—removes occasional outliers without being pulled by extreme values the way an average can be. A single rogue reading of −30 dBm in a sequence that otherwise sits around −65 dBm will shift a moving average noticeably but will have no effect on the median. Median filtering is particularly useful in environments with intermittent interference from other 2.4 GHz devices, such as Wi-Fi access points or microwave ovens.
Exponential Smoothing and Kalman Filtering
Exponential smoothing applies a weighting factor that gives more influence to recent readings and less to older ones, allowing the filter to adapt faster to real changes while still suppressing noise. Kalman filtering goes further by incorporating a simple model of how the signal is expected to change over time, adjusting its trust in new measurements based on whether they fit that model. Kalman filters can produce good results for indoor positioning but require tuning to the specific environment and are more complex to implement and debug.
Choosing a Filtering Approach
The right filter depends on what the system needs to do. For a simple proximity notification—triggering a message when someone approaches a display—a basic moving average or median filter over a modest window is usually sufficient and easy to validate. For real-time indoor navigation where the blue dot on a map must track a walking visitor smoothly, more sophisticated filtering is justified, but it brings a corresponding increase in development and testing effort. In all cases, the filter parameters should be set using measured on-site data, not assumed values, and rechecked whenever the physical layout changes.




