BLE Discovery Latency & Battery Estimator

An advertiser transmits advertising events. In each event it sends at most one PDU on each enabled primary advertising channel: 37 (2402 MHz), 38 (2426 MHz), and 39 (2480 MHz). The time from the start of one event to the start of the next is:

T_advEvent = advInterval + advDelay

For legacy advertising, HCI LE Set Advertising Parameters accepts an advInterval from 20 ms to 10.24 s in 0.625 ms units. advDelay is a pseudo-random value from 0 ms to 10 ms that the Link Layer draws for every event. Within one event, consecutive PDUs must start no more than 10 ms apart. The actual gap between them is implementation-defined.

A scanner listens on one primary channel for the scan window, once per scan interval, and should use a different channel in each window. HCI LE Set Scan Parameters accepts both values from 2.5 ms to 10.24 s in 0.625 ms units, with the window no longer than the interval. Equal values request continuous scanning, and the scanner should still change channel at each interval boundary.

The scanner receives a packet only when the packet is on the channel it is listening to and the whole packet falls inside an open window. A full legacy ADV_IND on LE 1M carries 1 byte of preamble, a 4-byte Access Address, a 2-byte header, a 37-byte payload (6-byte AdvA plus 31 bytes of AdvData), and a 3-byte CRC: 47 bytes at 8 µs per byte, or 376 µs on air.

Without advDelay, both devices run strictly periodic schedules. The offset between each advertising event and the scan windows then repeats, and an advertiser whose events start in the gaps between windows stays there. This is phase locking. With a 100 ms advertising interval, a 100 ms scan interval, and a 10 ms window, roughly one starting phase in ten is discovered within the first few events and the rest are never discovered.

advDelay adds an independent 0 to 10 ms offset to every event, so the phase drifts like a random walk and eventually crosses an open window. The same perturbation keeps two advertisers with the same interval from overlapping on every event. HCI LE Set Advertising Parameters has no parameter to turn it off.

To reproduce the effect, clear the advDelay checkbox and set a scan window shorter than the advertising interval. When fewer than 99% of trials discover the advertiser, the result names phase locking as the likely cause. The setting exists only to demonstrate this failure mode.

Android apps choose a scan mode through ScanSettings. The Bluetooth stack maps each mode to a scan window and interval in ScanManager.java. The values below are the AOSP defaults from the android13-release branch through main.

• The stack converts milliseconds to 0.625 ms units with integer truncation, so the 183 ms balanced window reaches the controller as 292 units, which is 182.5 ms. The tool uses 182.5 ms.
• Each default can be overridden through Settings.Global keys such as BLE_SCAN_BALANCED_WINDOW_MS, so a specific device can differ. SCAN_MODE_AMBIENT_DISCOVERY uses the balanced values.
• When several clients scan at once, the stack programs the controller with the most aggressive requested mode.
• With the screen off, unfiltered scans are suspended, and scans from apps that are not in the foreground move to SCAN_MODE_SCREEN_OFF. Its window and interval come from device configuration and default to the values in the table.
• Android 12 (android12-release) used different defaults: 512 ms every 5,120 ms for low power, 1,024 ms every 4,096 ms for balanced, and 4,096 ms every 4,096 ms for low latency.

Apple's Accessory Design Guidelines specify advertiser intervals rather than scan parameters. The tool offers them as advertiser presets: 20 ms for at least the first 30 seconds, then 152.5, 211.25, 318.75, 417.5, 546.25, 760, 852.5, 1022.5, or 1285 ms.

Between events the advertiser sleeps, so its average current is set by the charge spent per event and the event rate:

I_avg = (t_TX × I_TX + t_overhead × I_overhead) ÷ (advInterval + 5 ms) + I_sleep

The 5 ms term is the mean of advDelay. The event term scales with the inverse of the interval, so doubling a long interval roughly halves it. Once that term falls toward the sleep current, longer intervals add latency without a matching gain in battery life.

Packet length and PHY set the TX time. Three full legacy PDUs on LE 1M take 1,128 µs per event. On LE Coded S=8, each ADV_EXT_IND takes 1,168 µs and carries no advertising data, and the AUX_ADV_IND with 31 bytes of data takes another 3,344 µs, for 6,848 µs per event. Using fewer channels shortens each event, but scan windows on the unused channels can no longer discover the device.

Apple's guidance pairs both ends of the trade: a 20 ms interval while discovery is expected, then a longer interval to save power. The current and capacity defaults in the tool are example values. Replace them with datasheet figures, then confirm the result with a power analyzer across many advertising events.

The simulation is a timing model. It assumes:

• No collisions and no RF effects other than the optional packet loss, which is drawn independently for each packet in a matching window.
• A packet counts only if it lies entirely inside an open window on its channel. Channel switching time is not modeled.
• The scanner rotates 37, 38, 39. The specification requires a different channel per window but does not fix the order.
• Passive scanning. Scan requests, scan responses, and connection setup are not modeled.
• On LE Coded, discovery is counted when ADV_EXT_IND is received. The controller reports the advertiser only after it also receives the AUX_ADV_IND, which the model assumes arrives.
• Latency ends when the controller has the packet. Host, operating system, and application delivery time are extra.

To validate the estimate on real hardware:

• Capture the advertiser with a sniffer and check the real interval, advDelay spread, PDU gap, and channel set.
• Record an HCI log on the scanner (for example an Android btsnoop log) and read the scan interval and window from the LE Set Scan Parameters or LE Set Extended Scan Parameters command.
• Start the advertiser or the scan at a known time, timestamp the first advertising report, and repeat at least a hundred times to compare percentiles. Disable report batching for this test: on Android, a non-zero report delay delivers results in batches.

• Bluetooth Core 6.2, Vol 6, Part B, Link Layer: sections 1.4.1 (channel indices), 2.1 and 2.2 (packet formats), 4.4.2.2.1 (advertising interval and advDelay), 4.4.2.3 onward (PDU spacing), and 4.4.3 (scanning).
• Bluetooth Core 6.2, Vol 4, Part E, HCI: sections 7.8.5 (LE Set Advertising Parameters), 7.8.10 (LE Set Scan Parameters), and 7.8.53 (LE Set Extended Advertising Parameters).
• AOSP ScanManager.java and Utils.java for scan mode values and unit conversion.
• Apple Accessory Design Guidelines, Release R31, section 58.5 (advertising interval).

To measure discovery in an application, start with the SimpleBLE scan recipe. For the connection that follows discovery, use the connection parameter validator and the throughput calculator.