Multirole (C and P) device misses connection events

RE: Multirole (C and P) device misses connection events

dtp — Mon, 26 Aug 2024 14:06:02 GMT

This was indeed what was happening. We solved by using a different connection interval on the B - C connection, as per Emil's suggestion.

RE: Multirole (C and P) device misses connection events

dtp — Mon, 26 Aug 2024 14:03:32 GMT

Hi Emil, apologies for never getting back to you on this. Thank you for this because we ended up going for the approach you suggested here. My concern at the time were the iOS (the Central) connection interval constraints (only multiples of 15 ms allowed) but we solved the problem by having platform-specific connection parameters.

RE: Multirole (C and P) device misses connection events

Emil Lenngren — Tue, 11 Apr 2023 17:30:37 GMT

Consider the case when there are three devices A, B, C with two connections:

1. A (peripheral) <-> B (central)

2. B (peripheral) <-> C (central)

and both connections have equal connection interval.

Since the timing is based on the central's clock in a connection, B's clock will drive the first connection and C's clock will drive the second connection. These two clocks are not perfectly synchronised but will drift with respect to each other. It is therefore possible that the connection events at B for the two connections for some time always clash, until they drift apart. Having unrelated connection intervals solves this issue, since if two connection events from two different connections in that case happen to overlap, they will certainly not overlap at the next connection event.

This can be compared to the case when there is only one central, but multiple peripherals to this central. Since the central's clock drive all connections in this case, the timings will always drift the same, causing no overlaps in this case.

RE: Multirole (C and P) device misses connection events

Hung Bui — Tue, 11 Apr 2023 14:33:24 GMT

Hi David,
I assume you are using Nordic BLE controller ?

If you have a look at the scheduling documentation here, you can find somewhat the explanation for the behavior you observed. By default BLE connection event should have same priority and when one connection is about to timeout due to too much preemption it will have first priority.

However, I'm not so certain about the drifting explanation. If there is a drifting, both connection should be drifted. And why would B-C has higher priority than A-B.

I agree with Emil suggestion that you can try to make the connection interval slightly different to see if you have the same issue. I would assume collision still occurs but it will not last for a long time as you are seeing in your case.

RE: Multirole (C and P) device misses connection events

Emil Lenngren — Sun, 09 Apr 2023 08:07:45 GMT

I think the easiest solution would be to use different connection intervals. Do you really need exactly 100 ms on both connections? If one had for example 101.25 ms and the other 98.75 ms, that would instead result in seldom occasional clashes rather than constantly overlapping clashes.

RE: Multirole (C and P) device misses connection events

dtp — Sat, 08 Apr 2023 11:04:24 GMT

Another update: after some analysis, the issue is clearly caused by the connection events for the two connections (A-B, B-C) drifting and eventually overlapping. When they overlap, the A-B event seems to be "sacrificed" for half of the conn events, until enough time passes for the the two events to drift apart from each other and a healthy exchange resumes.

Some more useful information on this side: I am using an external 20ppm crystal and the auto-update of conn params is disabled:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_20PPM=y
CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS=n

I thought re-enabling CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS on device B might allow the B-C connection to automatically re-update itself when the two connection events clash so that the phase of the event can be shifted or the conn parameters renegotiated, but this did not happen.

One of the reasons I chose 100ms for both connections is to avoid issues like this occurring, but it's clear I need to take the drift of the two connections into account on device B. Ideally, I keep the B-C connection event within a certain window, semi-synchronised with the A-B conn events.

1) Are there any NCS/Zephyr techniques to avoid the clash of connection events on a multirole device?

2) If not, it might have to look at PPI ways. I was thinking of recalling a conn_params_update() whenever the two events get to close, but where the next event would occur in the window would be left up to chance?

3) Is there a way to force a connection event to occur at a certain point in time rather than leaving it up to chance?

RE: Multirole (C and P) device misses connection events

dtp — Thu, 06 Apr 2023 20:20:52 GMT

Just to provide an update on this: the issue still occurs when using two nRF52840 DK as A and B.