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

[Stefan Birnir Sverrisson]

Thanks for the detailed information. I will report back within a few days what I find out on our side

[roberto]

Hi Stefan, any news on this? let me know if you need more information from my side or if the case is clear. To me the phone is misbehaving in not sending out packets on first connection event after new connection parameters being applied... anyway the gap is less then Logical Link timeout so Nordic side, if correctly listening, it should be able to acknowledge the first packet sent by phone after resuming from its strange state. Thanks

[Stefan Birnir Sverrisson]

@roberto Thanks for your clarification.

One question. In your attached sniffer trace, how do you see in 3rd case if the packet contains ack or not from the slave. I see that you have marked the packet from the slave with "-->" indicating that an ack is expected but not received and then marked "--> first ack" some seconds later. Is there anything in the sniffer data that indicates if an acknowledge is sent by the slave or not, other than your comment?

[roberto]

@Stephan,

sorry if cut&paste text is not clear. See below some explanation (basically is the side column, I made a type error indicating it as Sede :( )

40,373 26 0x88d1351e 0x00b2 1 Empty

--> 40,373 is #ofFrame,... 0x00b2 is connEvt where to move to new conn params and '1' is indicating the Master side '2' indicate slave one

so isolating this instant we have:

FRAME CH ACCESS ADD EVT CNT Side LLID NESN SN MD

40,373 26 0x88d1351e 0x00b2 1 Empty 1 1 0 --> packet from Master when change conn params

40,374 26 0x88d1351e 0x00b2 2 Empty 0 1 0 --> slave ack it in same connEvt (side ==2)

40,887 8 0x88d1351e 0x00b9 1 Empty 0 0 0 --> from here no ack from slave; note the gap 0xb9-0xb2

40,952 16 0x88d1351e 0x00ba 1 Empty 0 0 0

...

43,593 16 0x88d1351e 0x00df 1 Empty 0 0 0

43,594 16 0x88d1351e 0x00df 2 Empty 1 0 0 --> finally it is acked

Let me know if it is clear.

[Stefan Birnir Sverrisson]

@roberto No worries, I can now identify the NESN and SN fields in the sniffer data, sorry for the confusion. Thanks for your clarification