Bluetooth: Controller: Connection Interval seems wrong with multiple connections

[CodingGhost]

using the Zephyr Controller Implementation,if coded PHY support is enabled but 1M connection is used, the connection interval seems to 108 Milliseconds regardless of of what is negotioated. This can be seen with wireshark, I attached the logs. when using the Softdevice controller it is behaving like expected.
Im not sure if my Wireshark maybe skews the results but as it measures correctly with the softdevice it seems to be working. It would be Interesting if someone could verify this behaviour.
I am currently using NCS 2.5, but as I tried with both Controllers, this shouldnt be a NCS only Issue.
at this stage I would first like to know if anyone can reproduce this or if its specific to my setup.
@cvinayak
wireshark.zip

[CodingGhost]

• @theob-pro who authored this code sample.

what code sample do you mean?

[kartben]

sorry, posted on the wrong issue!

[cvinayak]

tested using shell application, and i do not see any issue using 7.5 ms conn interval either with coded phy supported (but the slot reservation turned off):

Timing seems ok too (CONFIG_BT_CTLR_SLOT_RESERVATION_UPDATE=n):

conn interval of 36.25ms is working fine with slot reservation enabled (CONFIG_BT_CTLR_SLOT_RESERVATION_UPDATE=y):

[CodingGhost]

I will try to create a minimal sample to demonstrate it and also try to verify that it works correct with the console application. Maybe this is harder to replicate than I thought. What I know for sure right now is that with LL_SW_SPLIT it behaves "wrong" and then I only set LL_SW_SPLIT=n and everything works as it should. I will update this issue with my findings once I have some more time todo specific testing.

[henrikbrixandersen]

Thank you for reporting this. However - unless you are able to reproduce this issue with upstream Zephyr main - please report issues with the nRF Connect SDK (NCS) on the Nordic Semiconductor DevZone.

CC: @carlescufi

[CodingGhost]

I thought that it would fit better here, because its about the Zephyr BLE Controller implementation and not about the softdevice, but If you think Its better to put it in the devzone I will do that.
I will get around to more testing in about two weeks, but Im pretty sure it has something todo with some kind of time reservation for the scanning. If I start a scan with coded phy window and interval set in the bt_le_scan_param and then stop it and connect, the connection interval is wrong. It doesnt even matter if coded phy scanning was enabled, its just about if the values for window and interval have been set. and the scan was stopped before connecting and never restarted, so something is going on there. But as I said, i will put together a sample to demonstrate it once I have some spare time.

[CodingGhost]

@cvinayak I have created a sample to demonstrate the problem.
In the attached zip file you will find a central and a peripheral app. the central is based on the central_multilink sample and the peripheral is just the peripheral sample code with some additional config options.

To reproduce the issue, upload central and peripheral to two nRF52840s , then start a sniffer before connecting.
As I couldnt reproduce the issue with only one central and peripheral, I modified the central example so that it is a multirole example. It advertises until something connects, then starts a scan and connects the peripheral device.

in the sniff I can see that everything is correct, until the connection interval gets updated. The used value seems to be about double the negotiated interval. As soon as the device that connected to the central disconnects, the Interval goes back to the expected value:

I know I cant have unlimited devices with fast connection intervals connected, but I think 2 devices with 36ms Interval should be achievable with constant connection intervals.

IMPORTANT:

1. change the address of the peripheral on line 81 to the Address of your board.
2. I could not always reproduce this, it may take some attempts to successfully reproduce.
3. If the Interval always seems correct, let it run in this state for some time. In my case sometimes it suddenly changed to the double Interval and back later. (can take a long time, up to about 20 minutes)
4. the nRF connect Android App was used to initially connect to the Central/multirole device

EDIT: I was able to reproduce this issue with the Softdevice Controller now. This could mean that its not a Controller Issue but dont know what it is then though?!

EDIT2: After reading https://devzone.nordicsemi.com/f/nordic-q-a/89298/increase-throughput-in-multi-role-multi-connection-system
I think it may have something todo with how the connection events get scheduled? I tried using different connection intervals for the two connections of the multirole device and the behaviour changed.

Devzone Post

bug_demo.zip

[CodingGhost]

as Vidar Berg pointed out in his analysis on the Devzone post, the Controller is skipping every other event. The cause is unknown though. Is there any log that I can enable where I would see this skipping happen? Also, could this all be because of a misalignment of event scheduling? like somehow the events are scheduled for the same time? as far as I know, the LL connection update has a offset field for exactly this purpose, but neither the Softdevice nor the Opensource Controller are using this feature. Maybe this would solve the problem..?

[cvinayak]

he LL connection update has a offset field for exactly this purpose, but neither the Softdevice nor the Opensource Controller are using this feature. Maybe this would solve the problem..?

You could try the Zephyr Controller in Zephyr v3.3 release with CONFIG_BT_LL_SW_LLCP_LEGACY=y, i believe the older implementation had code to find offset and use it in connection update. If you do not see offset used in sniffer log with v3.3 release, do revert back and i can check if I have any local implementation that does it... do post sniffer logs here anyway.

[CodingGhost]

wireshark_wrongintervaldemo.pcapng.txt
I tested it as you said, and it really does use an offset! But unfortunately it did not change anything, it was still reproducable within 2 tries. What I think is a little bit odd, because I would have assumed that with the offset there should be no collisions directly after the negotiation, but eventually a long time later when the system clocks have drifted enough. But what you can see in the sniffer log is, that the problem is there from the first packet( packet no. 11564) with the updated interval onwards.

I cant upload .pcapng files, so i just added .txt at the end, so just rename it.

[cvinayak]

eventually a long time later when the system clocks have drifted enough

If I remember correct there was some automatic detection of drift and the connection parameter request was auto-initiated, but I do not think it is there anymore in any release of Zephyr.

Alternatively, applications can periodically initiate connection parameter request to mitigate the eventual overlap... may be you can try that, say a connection parameter update every 30 seconds or so.

[CodingGhost]

yeah, that could work, BUT in order for that to work, it first has to work at all after the update. Currently as you see in the log, there is a offset of 5msec applied, but they seem to still overlapp / Controller is still skipping events right after the update.

[cvinayak]

it first has to work at all after the update

In your sniffer trace your Peripheral (I think a non Zephyr Controller) is not using the LL Connection Parameter Request (but L2CAP Connection Parameter Update), hence the Central device (I think a Zephyr Controller) is not provided with the scheduling offset hints.

Anyway, we are diverging away from the fact that Central clock would drift and that any measure taken will eventually lead to the Central connection events drifting into and overlapping with other roles in the Peripheral. LL Connection Parameter Request Control Procedure would to some extent help as long as all devices in the topology co-operate in the scheduling.

[CodingGhost]

Sorry, I forgot to also apply this config to the Peripheral. Now it looks different, but somehow the connection param request now gets rejected with "Unsupported LMP/LL Parameter Value". This is how the request looks:

By the way, If I get it to work like that, and just do a update every 30sec or so, how will that work in a current version of Zephyr? Why was this feature even removed?

[carlescufi]

@CodingGhost moved this to a discussion since it's not really a bug.