The measurement model and its assumptions
Received Signal Strength Indicator (RSSI) is not a standardised physical measurement. It is a value reported by a device's Bluetooth chipset and passed up through the operating system, and every stage in that chain introduces differences between phone models. Two visitors standing at the same spot, at the same distance from the same beacon, will routinely report different RSSI values purely because one is holding an iPhone 15 and the other a Samsung Galaxy S24.
This happens for several reasons. Antenna design varies between manufacturers: the physical placement, gain characteristics and how the phone casing attenuates the signal all differ. Chipsets from different suppliers interpret signal strength slightly differently before reporting it. Operating systems apply their own smoothing, filtering and scaling. iOS and Android do not share a common reference point for what RSSI of -70 dBm means in terms of actual received power, and even within Android, device-specific HAL implementations add further variation.
The practical consequence is straightforward but frequently overlooked: a distance estimate derived from RSSI on one device model will not reliably transfer to another. If a system is calibrated using a single test phone, the resulting distance estimates will be systematically offset for every other model in your visitors' pockets. The size of that offset varies. In controlled tests, the same beacon at a fixed distance has been observed to produce RSSI differences of 10 to 15 dBm between popular handset models, which translates to a substantial error in any distance calculation.
This variability is a property of the technology, not a defect in any particular beacon or phone. It cannot be designed out at the hardware level. It must be accounted for in how the system uses RSSI data.
Control the variables you can control
Zone detection versus distance estimation
The impact of device variability depends entirely on what you are trying to do with RSSI. If your system triggers a notification when a visitor enters a broad zone — say, the footwear department — the variation between devices is manageable. A zone boundary drawn with enough margin (typically several metres of RSSI overlap) will catch visitors on different handsets without noticeable inconsistency. The visitor does not know whether the notification fired at 4.2 metres or 5.8 metres from the beacon; they simply know it fired when they walked into the area.
Distance estimation is where device variability becomes a genuine problem. If your system needs to know whether a visitor is 1.5 metres or 2.5 metres from an exhibit to trigger the correct audio track, a 10 dBm device-to-device swing makes that distinction unreliable. The same RSSI value might mean 1.5 metres on one phone and 3 metres on another. Systems that require metre-level precision from RSSI alone are fundamentally working against the physics of the signal and the diversity of consumer hardware.
Planning note: Numeric examples are not performance guarantees; verify the same settings and receiver mix in the intended venue.
Designing around variability
The most robust deployments avoid relying on a single RSSI value to make a decision. Instead, they use techniques that absorb device-level differences:
- Wide zone margins. Set trigger thresholds with enough buffer that a 10 dBm shift does not move a visitor in or out of a zone unexpectedly. This means accepting coarser granularity in exchange for reliability.
- Multiple beacon averaging. Where several beacons cover an area, use the combined RSSI pattern rather than a single beacon's reading. Device-specific offsets tend to be more consistent relative to each other across beacons, so the pattern is more stable than any individual value.
- Trend-based triggers. Rather than acting on a single RSSI snapshot, respond to a sustained trend — several consecutive readings showing the signal strengthening as the visitor approaches. This filters out momentary spikes that differ between devices.
- Relative rather than absolute thresholds. If your application can establish a baseline RSSI for a device when it first enters the space, subsequent changes relative to that baseline are more meaningful than the absolute number.
Implications for specific environments
In retail settings, where zones are typically large and the action is a push notification or a loyalty check-in, device variability is an inconvenience that wide margins handle well. In museums, where exhibits may be close together and content is specific to a single display, the same variability demands either very careful zone design with generous overlap, or a supplementary technology such as NFC to handle the last metre of precision. For indoor navigation, device variability is one of several factors that limit step-by-step accuracy, alongside multipath interference and environmental changes.
What changes invalidate the result
Calibrating with a single device
The single most common mistake is performing the entire site calibration — mapping RSSI to distance at various points — using one phone, then assuming that calibration applies to every visitor. This produces a distance model that is accurate for that specific handset and systematically wrong for others. At minimum, calibration should involve a representative mix of the most common devices in your expected visitor demographic, and the resulting spread should be documented as part of the system's known accuracy envelope.
Quoting accuracy without qualifying the device assumption
Any accuracy claim attached to an RSSI-based system is meaningless unless it states which devices were tested and what the variance was across them. A claim of "two-metre accuracy" based on testing with a single iPhone model tells you nothing about how the system performs with Android devices, older handsets, or phones in cases. When evaluating a system or writing requirements for an integrator, insist on accuracy figures that include the device-to-device spread, not just the best-case single-device result.
Treating RSSI as a calibrated instrument reading
RSSI is an indicator, not a measurement. It is not traceable to a standard, it is not calibrated at the factory for absolute accuracy, and it is subject to the filtering decisions of whichever operating system is interpreting it. Systems that treat RSSI values as precise inputs — feeding them into complex algorithms without accounting for the noise floor of device variability — tend to produce results that look impressive in a controlled demo and disappoint in a live environment with a diverse visitor population.
Key checks before deployment
- Test with at least four or five different device models spanning iOS and Android, different chipset generations, and common case types. Record the RSSI spread at each test point.
- Compare the spread to your zone widths. If the device-to-device variation at your zone boundary is larger than the margin you have allowed, the boundary will be unreliable. Widen the zone or add beacons.
- Check whether your platform applies device-specific corrections. Some middleware vendors maintain device profiles that adjust RSSI interpretation based on the detected handset model. Understand whether this is in use, how it is maintained as new models are released, and what happens when an unrecognised device appears.
- Ask your integrator what happens with older or budget devices. Cheaper handsets often have lower-quality antennas and less consistent Bluetooth stacks. If your venue attracts a broad demographic, these devices may represent a meaningful share of your traffic.
- Document your test devices and results. If the system behaviour changes after an OS update or a new phone model becomes popular, you will need a baseline to compare against.
Acceptable limitations
Device variability cannot be eliminated. The practical question is whether your use case can tolerate it. Presence detection in a broad zone, dwell-time measurement, and rough proximity sorting all work well despite device differences. Metre-accurate ranging, precise indoor positioning, and any system that makes binary decisions on a narrow RSSI threshold will struggle. Understanding this distinction before committing to a deployment architecture avoids the most common source of disappointment in beacon-based systems.
