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

[fughilli]

Hello, I am building a device which simultaneously advertises as a beacon and acts as a peripheral role device. Advertisements are sent at ~20 Hz with the connection to the central configured with an interval of 15 ms. I am observing significant variability in connection packet timing when the beacon advertisements are enabled (data transmission is synchronized with the connection interval, and when the beacon is disabled the variability is essentially zero).

According to the SD140 documentation (https://docs.nordicsemi.com/bundle/sds_s140/page/SDS/s1xx/multilink_scheduling/advertiser_timing.html), I would expect that beacon advertisement packets would take the lowest priority unless blocked for several intervals. I tried an experiement where I lengthened the advertising interval to 1 second, and I still observed the same increase in variability in the connection packet timing (no improvement).

Any idea why this might be occurring?

[tesc]

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