RE: Simultaneous Beacon and Peripheral Role Connection: Impact on Connection Packet Latency

tesc — Mon, 21 Oct 2024 14:04:03 GMT

Hi,

Both connection event as peripheral and advertiser fall in the "third priority" category of "All Bluetooth Low Energy roles in states other than above". See SoftDevice timing-activities and priorities for details. Since both are at the same priority, and the connection as peripheral is not about to time out, those collisions will typically be handled in a round-robin fashion.

Please note that both intervals are highly variable:

Timings for the BLE connection as a peripheral are tied to the clock of the central, leading to drifting connection interval if measured with the peripheral clock.
BLE advertising has a random component, leading to drifting advertising interval (back and forth), from the random distribution of the 0-10 ms random delay.

This means if advertising interval (including expected delay of 5 ms) aligns with connection interval, you should expect periods of repeated collisions, leading to alternating dropped events from advertising and connection, when those events are in phase. Since both intervals drift uncorrelated to each other, you should expect to drift into and out of this state of collisions.

When the advertiser is off, you only have the connection and there should be no collisions. Occasional packet losses could still occur, due to e.g. packet collisions or other interference from nearby electronic equipment.

If you want to prioritize the BLE connection, then reducing slave latency and/or supervision timeout (both are connection parameters) could improve the situation, since the BLE connection event as peripheral would then be considered a "peripheral connection that is about to time out" and therefore given higher priority. Please note however that this would lead to more advertiser events being dropped (typically many events in a row if intervals are similar,) and the BLE connection would break more easily from packet collisions etc.

If you want to spread the collisions more evenly (so that they are not arriving as bursts of many collisions in a row) then I would choose an advertising interval which (when the additional 0-10 ms random delay is taken into account) does not align with the connection interval. This would also ensure more advertisements go through should you reduce slave latency / supervision timeout as suggested above.

Please note that both advertising events and connection events could last a few milliseconds, so if the interval is low there may be not much space for interleaving. (Note that any interleaving is accidental and temporary, due to the drifting explained above.) With short intervals (around 10 ms and shorter) you should expect collisions almost constantly. For longer intervals (50 ms and above) you should typically expect collisions to occur less often, but depending on connection event length. Please note that those are ballpark figures, and your mileage may vary. You should test this in practice for deciding on what parameters best suit your needs, and you should test with different devices (for different drift between central and peripheral clocks.)

Longer connection events will typically collide more than shorter ones. In order to reduce the overall number of collisions, you could therefore try reducing the connection event length.

Regards,
Terje