BLE Timing🔗

This page describes how KTag devices time their BLE advertising and scanning, why, and what that means for how quickly one device hears another. It reflects the 2024A and 2020TPC firmware as of SystemK 02.03.

Summary🔗

Advertising🔗

Every KTag packet is a BLE advertisement, so the advertising interval sets how much each device puts on the air. After each advertising event, the controller waits for the advertising interval (a fixed value it picks between the configured minimum and maximum) plus a random 0–10 ms advDelay, which the BLE specification adds so that two advertisers can't stay in lockstep. The spacing between events therefore averages the interval plus 5 ms, and varies from one event to the next with a standard deviation of 10/√12 ≈ 2.9 ms. Each event sends the packet once on each of the three advertising channels (37, 38 and 39).

Both devices advertise every 32–37 ms, which is about 25 events per second. The advertising interval is what determines congestion when many devices are playing at once: a shorter interval puts proportionally more on the air. For example, a 20–25 ms interval (about 36 events per second) would take about 40% more of the air.

Scanning🔗

KTag devices scan passively: they listen, and transmit nothing while scanning. So a device's scan duty cycle has no effect on congestion. It only affects how often that device hears others, and how much of its radio's time is left for its own advertising.

The 2024A scans 40 ms of every 60 ms, and the 2020TPC 30 ms of every 100 ms. Neither skips a measurable share of its own advertising events while scanning.

Responsiveness🔗

How quickly a device hears a new packet (for example, a TAG or a CONSOLE command) depends on how the sender's advertising events line up with the receiver's scan windows. A receiver hears an event only if the event falls inside one of its scan windows.

The table shows a simulation of the time from when a sender starts advertising a new packet to when a receiver first hears it. The sender advertises on the KTag interval of 32–37 ms. The simulation assumes the receiver hears every event inside its scan window: it ignores collisions, which make the times longer.

A scan interval close to the 37–42 ms spacing between advertising events is a poor choice, as the 30 / 40 ms row shows. Such a receiver usually hears a packet quickly, but has a long tail: when a sender's events fall into the gap between scan windows, the next ones fall there too, drifting out only slowly, by the difference between the two intervals. With a 60 ms scan interval, each of a sender's events lands 18–23 ms earlier in the scan pattern than the last, so its events cross the gap between scan windows within an event or two.

The 2024A scans 40 of every 60 ms rather than 50, to leave more of its radio's time for its own advertising. The HIL tester stops advertising while it measures, so it can scan 50 of every 60 ms.

The 2020TPC's scan has a longer gap, but its scan interval isn't close to the advertising spacing, so a sender's events drift out of that gap quickly. It is slower on average than the 2024A, with no long tail. A device that repeats a packet for long enough is still heard: for example, the HIL tester holds each CONSOLE command on the air for 500 ms.

BLE Quiet🔗

BLE quiet (see the CONSOLE packet) asks a device to stop advertising for a while. The 2020TPC builds with COMM_BLE_DISABLE_QUIET, so it ignores quiet requests and keeps advertising: on a crowded field, stopping and restarting its advertising can get it stuck. The 2024A supports quiet.

Measuring Advertising Timing🔗

The KTag HIL Tester's BLE Advertising Interval test measures a device's mean spacing between advertising events to within 1%, at 99% confidence, and checks that it matches the 32–37 ms interval. It timestamps each of the device's advertisements, stops its own advertising during the measurement, and uses only the gaps between consecutive events. Each gap is weighted to undo any bias from the alignment of the tester's scan windows, and the error is estimated from batch means, because successive gaps aren't independent. A measurement takes about 20–30 s.

A Windows PC can't make this measurement. Windows scans every 118.125 ms and reports at most one advertisement per device per scan window, so it can't see the spacing between events.