Presence detection sounds simple. A tag shows up, so a person or asset must be in the room. Done, right?

Not quite.

In real deployments, BLE presence detection fails for familiar reasons. Teams set intervals too slow, duty-cycle the receiver too aggressively, trust one noisy RSSI reading, and then act surprised when a badge in Room 12 still “exists” in Room 13. We’ve seen this pattern over and over. The hardware usually works. The timing and interpretation logic do not.

Lansitec’s own B-Mobile and B-Fixed guidance makes an important point that many projects skip: single-point BLE presence detection is for room-level or rough tracking, not for exact directional positioning. In B-Mobile, fixed Bluetooth gateways listen for mobile beacons. In B-Fixed, fixed beacons advertise and the mobile tracker listens, then forwards beacon ID plus RSSI upstream. Those are similar ideas, but the timing constraints are not identical.

BLE Presence Detection Architecture Explained (B-Mobile vs B-Fixed)

Model	What stays fixed	What moves	What presence really means
B-Mobile	Bluetooth gateways	Badge beacon, label, bracelet, asset tag	“This beacon is within the gateway’s effective room or zone coverage.”
B-Fixed	Bluetooth beacons	Badge tracker, helmet sensor, container tracker	“This tracker heard the room beacon strongly enough, often enough, to belong to that zone.”

That distinction matters. In B-Mobile, Lansitec recommends an 800 ms advertising interval for fast-moving people and notes that the indoor Bluetooth gateway and badge Bluetooth gateway keep Bluetooth receiving always on. For solar gateways, receiving can also stay on, but Lansitec advises lowering the receive duration during long rainy periods to save power.

In B-Fixed, the constraint comes from the listener side. Lansitec states that the tracker’s Bluetooth receiving window is three seconds, so the beacon transmission interval should not exceed one second. Their suggested beacon interval is 800 ms, 500 ms, or less, and at 100 ms the tracker can hear multiple packets in the three-second window, discard the highest and lowest RSSI, and average the rest. That is a very practical clue. Presence detection improves when you treat BLE as a stream of evidence, not a single ping.

Common BLE Presence Detection Mistakes (And How to Fix Them)

Here are the usual mistakes.

1. They optimize battery first, then wonder where detection went.
   Bluetooth LE lets you stretch advertising intervals a lot. The formal advertising interval range in the Bluetooth Core Specification runs from 20 ms to 10,485.759375 s, with a pseudo-random advDelay of 0 to 10 ms added to each event. That flexibility is useful, but it also makes it easy to configure a beacon so lazily that a moving person walks through a doorway between packets. ⁽¹⁾
2. They under-scan.
   On the scanner side, scan interval and scan window are the levers that decide how often the radio listens and for how long. Silicon Labs defines scan interval as how often scanning starts, and scan window as how long the device listens. The window must be less than or equal to the interval, both expressed in 0.625 ms units. Silicon Labs also notes that channel switching consumes time and packets are not received during the switch. ⁽²⁾
3. They assume the strongest RSSI always equals the correct room.
   That is the seductive mistake. NIST found that BLE RSSI varies not just with distance, but also with multipath interference, other 2.4 GHz traffic, orientation, and obstruction. In other words, RSSI is evidence. It is not truth. ⁽³⁾⁽⁴⁾
4. They ignore wall leakage and human-body attenuation.
   Lansitec explicitly says gateways or trackers may still hear signals from the next room, but the signal is generally much weaker, with an RSSI difference that can reach 20 dBm. NIST’s BLE proximity work helps explain why that gap moves around in practice: different wall materials attenuate very differently, and even a person blocking the direct path can shift RSSI by about 11 dB. ⁽⁴⁾

BLE Timing Settings That Impact Presence Accuracy

A surprising number of projects obsess over floor plans and marker icons before they tune the radios. That order is backwards.

Practical starting points for Lansitec-style deployments

Scenario	Better starting point	Why it works
B-Mobile, people moving through corridors/doors	Badge beacon at 800 ms, gateway receive always on when power allows	You raise the chance of at least one useful advertisement during a short doorway crossing.
B-Fixed, room beaconing to mobile tracker	Tracker receive window 3 s, beacon interval 800 ms or 500 ms, never slower than 1 s	The tracker needs enough beacon opportunities inside each receive window.
Battery-sensitive but still room-aware	Keep interval modest, then reduce TX power before making interval too slow	Lower power helps shrink leakage into adjacent rooms without destroying event cadence.
Rooms bleeding into each other or floors interfering	Per-room thresholds plus lower TX power, even down to -26 dBm in difficult multi-floor metal structures	Lansitec already uses TX-power reduction to control interference across floors. The same idea helps room boundaries too.

That last row matters more than people think. When leakage is the problem, shorter range beats more post-processing. Lansitec’s B-Fixed guidance for multi-floor factories says to reduce beacon transmit power to -26 dBm to avoid interference between floors. That is a floor-separation example, but the principle generalizes nicely to neighboring rooms and doorways.

How to Use RSSI Correctly for Indoor Presence Detection

Lansitec’s B-Fixed material includes a classic log-distance path-loss formula for deriving distance from RSSI:

d=10^{((∣RSSI∣−A)/(10n))}

with recommended example values of A = -59 and n = 3.3226.

That formula is useful. It is also dangerous when treated too literally.

NIST describes the same general family of path-loss models and shows why variance matters so much in BLE proximity work. The model can describe the trend, but the scatter around the trend is large because of fading, blockage, and environment-specific effects. ⁽⁴⁾

So here is the better way to use RSSI in presence detection:

Use it as a ranked signal over time.

A solid room-level engine usually does at least three things:

1. Aggregates multiple packets, not one. Lansitec already hints at this in B-Fixed by averaging several RSSI samples after dropping extremes.
2. Compares rooms by margin, not by absolute value alone. A badge heard at -67 dBm in Room A and -70 dBm in Room B is ambiguous. A badge heard at -59 dBm in Room A and -78 dBm next door is much cleaner. This is an inference grounded in Lansitec’s “up to 20 dBm” adjacent-room difference and NIST’s findings on attenuation variability.
3. Adds hysteresis and dwell, so the system does not bounce on every RSSI wobble. NIST’s data on orientation, walls, and body blocking makes that more or less mandatory.

In plain English: do not declare “entered Room B” because of one packet. Declare it because Room B stayed stronger long enough, by a large enough margin, across enough packets.

How to Fix BLE Signal Leakage Between Rooms

This is where many deployments fall apart.

Lansitec says it clearly in both B-Mobile and B-Fixed: next-room reception happens, but it is usually weaker, often by as much as 20 dBm. That gives you the foundation for a better classifier.

A practical logic stack looks like this:

Calibrate each room, not the whole building

One global RSSI threshold rarely survives real walls. Measure doorway-open, doorway-closed, occupied, and empty-room conditions. NIST shows wall material alone can swing attenuation dramatically, and their study observed roughly a 20 dB path-loss gap between glass and metal wall cases. ⁽⁴⁾

Use “best room plus margin”

Do not just ask, “Did I hear the tag?” Ask, “Was this room stronger than the runner-up by at least X dB for Y seconds?” The exact X depends on site survey results, but the logic comes straight from the adjacent-room weakness Lansitec documents.

Separate entry and exit thresholds

Entry should be stricter than stay. Exit should require a little more patience. Otherwise, someone standing near a wall will flap between rooms.

Fix leakage with RF before software if possible

Reduce TX power, move the gateway or beacon away from shared walls, or shift it closer to the area you actually care about. BLE gives you adjustable transmit power, and Lansitec’s beacon portfolio supports that.

Know when corridor coverage is enough

Lansitec’s B-Mobile Q&A gives a realistic deployment tradeoff: corridor, lobby, and hall gateways can be the more economical option if the real requirement is “know when people are out of the room.” Put one gateway in every room only when you truly need room identity, roommate swaps, or same-room co-presence with higher certainty.

That point is easy to miss, but it saves money. Presence detection only looks bad when the design goal and the deployment density do not match.

Scan Window and Interval Settings for Reliable Detection

This is the piece many articles gloss over.

On paper, advertising and scanning are just GAP parameters. In practice, they define whether your system even has a chance to notice something moving. Silicon Labs notes that passive scanning only listens, while active scanning also sends scan requests and listens for scan responses. They also warn that channel switching takes time, and no advertising packets are received during that switching period. ⁽²⁾

That means two things:

• For simple presence detection, passive scanning often makes more sense. It is quieter and easier on power.
• If you shorten the scan window too far, you do not just reduce battery use. You create blind time.

NIST made the same operational point from another angle. In their BLE encounter work, when advertising and listening were not aligned often enough, devices could simply miss each other’s presence. ⁽³⁾

So, the first real commissioning question is not, “What is my dashboard going to look like?”
It is this: How many chances per doorway crossing does my system have to hear the packet?

If the answer is one, maybe, the deployment is fragile already.

Step-by-Step BLE Presence Detection Setup Guide

Use this order on site.

1. Set the timing first.
   For B-Mobile, start around Lansitec’s 800 ms guidance for fast-moving people. For B-Fixed, respect the 3 s tracker receive window and keep beacon advertising at 1 s max, preferably 800 ms or 500 ms.
2. Trim TX power second.
   If neighboring rooms bleed, lower power before you start inventing heroic filtering rules. Lansitec’s configurable BLE power ranges and the -26 dBm floor-isolation recommendation make this a very sensible knob.
3. Collect room-by-room RSSI histograms.
   Standing in the room center is not enough. Test at the door, shared wall, corridor edge, and near metal shelving.
4. Build classification logic around medians, margins, and dwell.
   We would not ship a production system on “last packet wins,” and neither should you.
5. Only then decide density.
   Small room? One gateway or beacon may be enough. Hazardous workshop? Lansitec suggests 10 m spacing. Need true room identity in a hotel or care facility? One per room improves accuracy materially.

Best Practices for Accurate BLE Presence Detection

Good presence detection is not magic. It is disciplined BLE timing plus humble expectations.

B-Mobile and B-Fixed both show the same lesson from opposite directions: presence detection works best when you optimize for repeated, believable evidence inside a known zone. Not for perfect coordinates. Not for single-packet certainty. And definitely not for a building-wide threshold copied from a lab test.

Tune the advertising interval to match movement. Size the receiver window so it can actually catch packets. Treat RSSI as a noisy ranking signal. Reduce leakage with placement and power before you try to outsmart physics in software.

Do that, and presence detection stops being “kind of okay.” It becomes dependable.

References and further reading:

1. Bluetooth SIG: Bluetooth Core Specification
2. Silicon Labs: Bluetooth LE GAP API Reference
3. NIST: Development and Evaluation of Bluetooth Low-Energy Device for Electronic Encounter Metrics
4. NIST: On the Feasibility of COVID-19 Proximity Detection Using Bluetooth Low Energy Signals