BLE: disconnection doing connection update procedure

[roberto]

Hi Nordic guys,

we are observing a strange behavior. Here some background on the project:

1. we are developing a peripheral device that asks via L2CAP signalling connection param update;
2. we are using nrf51822 with SDK 6.0 and SoftDevice 7.1.0 (s110 being peripheral); note: in another project where we use SoftDevice 8.0 we observed similar issue
3. as said peripheral based on context asks to switch between 'normal' connection interval (~100ms) and fast one ~30ms

We are observing sporadic disconnection when new connection parameters are applied using some specific phones (Moto X 2014 w/ Android 5.1, Nexus 5 w/ Android 6.0, HTC M8 w/ Android 4.4).

We took some OTA with Frontline tool (an extract of them is in the text in attach with some analysis).

What we see is:

1. at the connection event counter where to switch to new param the phone is correctly sending a packet that is acknowledged by nordic side;
2. sometimes phone sends next packet on first expected connection event after this, in that case Nordic acknowledged it correctly (see 1st and 2nd connection update in attached txt)
3. sometimes phones sends first packet not on first connection event, but there is a gap of 600/700ms; in that case Nordic is not acknowledging it (3rd and 4th case);
4. in one case, 3rd case, Nordic acknowledges it after 5 seconds .. and having an LL timeout of 6 seconds this let to keep the link alive
5. in another case, 4th, case where the LL is of 1 second the Nordic detects the link timeout and due to application implementation it re-start to advertise

From OTA traces it seems phones is doing stuffs correctly and only strange behavior is that sometimes it sending first packet with new connection param with a Gap that anyway is less then LL timeout. Sniffer anyway get it while Nordic side no.

It seems that having this gap lead nordic to not be synch anymore... could it be a clock drift that is not computed for each listened packet on nordic side?

Any help?

Thanks

Roberto

All_connUpdate_resume.txt

[roberto]

Hi Stefan, thanks to follow up. Actually with most of Android phones we do not have this issue, simply because the phone send packet w/o the gap explained on step 3 (actually they act as described in step 2). Just to give you some phones: Sony Z3 5.1.1 Sony Z2 5.0.2 Sony E3 4.4.2 Samsung S6 5.1.1 Samsung Galaxy S4 5.0.1 Samsung Galaxy S4 4.4.2 Sansung Galaxy S5 4.4.2 Samsung Galaxy S5 5 Motorola Nexus 6 5.1.1 Motorola Moto G - 2014 5.1.1 Motorola Moto X - 2014 5.1.1 Motorola Moto E -2013 4.4 Motorola Moto XT1085 5.0.2 LG G3 5.0.2 LG Nexus 5 6.0 (M preview 3) LG Nexus 5 5.1.1 LG Nexus 5 4.4.2 HTC M8 4.4.3 HTC M8 5.0.1 XiaoMi Mi4 4.4.4 ASUS Zenphone 2 5.0.1

as you see the list contains also reported problematic phones but it sounds like problematic sample has different model, like Moto X it fails on Model : XT1085 but not on Model: XT1092.

Let me know if you need more info Roberto