BLE: disconnection doing connection update procedure

RE: BLE: disconnection doing connection update procedure

Craig Carlson — Thu, 13 Apr 2017 18:06:25 GMT

Were the phone manufacturers ever told of this issue as it is still occurring in the field on these phones?? (abrupt disconnects due to incorrect Connection Update timing.)

RE: BLE: disconnection doing connection update procedure

Stefan Birnir Sverrisson — Tue, 13 Oct 2015 11:50:56 GMT

Yes, that is our suspicion, as time goes by the slave (nrf51) will widen its RX window as long as no packet is received from master and the RX window will eventually be large enough to capture the packet sent from master.

RE: BLE: disconnection doing connection update procedure

roberto — Tue, 13 Oct 2015 11:43:44 GMT

Based on exchanged comments the issue is on phone that is sending first packet after connection update with not the right timing and so slave (the Nordic based device) can not listen it having a link timeout.

Nordic is correctly behaving.

RE: BLE: disconnection doing connection update procedure

roberto — Tue, 13 Oct 2015 11:38:13 GMT

Stefan,

ok I didn't pay attention to the ppm in connection request and did not check it vs the first packet sent. So the windowWidening is computed by Nordic as (50ppm+slaveSCA (the nordic one))/1000000+ 637ms (time since lastAnchor)

Since Phone send packet 1.25 ms in advance it means its ppm is much more the reported 50ppm (actually 1500 is greater tan 500ppm that seems max one). I see so agree it is phone issue... that may be fixed in later update of phone.

Just wondering how in third case where on connection update there is still the 600ms of gap, nordic is not listening correctly but able to get packet from master after 4 seconds.... maybe the drifting or the windowWidening become large enough to get the packet.

RE: BLE: disconnection doing connection update procedure

Stefan Birnir Sverrisson — Mon, 12 Oct 2015 13:37:35 GMT

@roberto We have examined your sniffer file a little

when the Android phone delays its connection update request packet ~700ms, then the connection update request packet is sent ~1.5 ms before the connection event. This packet is sent before the nRF51 turns on its RX radio to listen for the packet. The nRF51 compensates for reported clock drift of the master (the Android phone) , and the reported accuracy in the connection packet is 50 ppm. the actual accuracy is however ~1500 ppm when the packet is arriving 1,5ms before the scheduled connection event. The window widening of the nRF51 will eventually make the nRF51 RX window large enough to catch the sent packet and will then respond to the master.

So we see this as a normal response from the nRF51 side. The problem seems to be on Android side, which sends the connection parameter update packet too early, apparently because the master clock drift is much larger than reported.

I can only speculate why this behavior is visible in different types of phones, but as a guess, perhaps these failed phones have the same BLE chip type inside, making the bug appear on different phone types. The good news is that the problem seems to be fixed, at least in some cases, by updating the Android version for the phones in question.

RE: BLE: disconnection doing connection update procedure

Stefan Birnir Sverrisson — Mon, 12 Oct 2015 13:03:29 GMT

@roberto. Thanks, we will examine your sniffer files further.

RE: BLE: disconnection doing connection update procedure

roberto — Mon, 12 Oct 2015 11:19:15 GMT

@ Stefan,

done: Case ID 24724

thanks

RE: BLE: disconnection doing connection update procedure

Stefan Birnir Sverrisson — Mon, 12 Oct 2015 11:06:57 GMT

@roberto For this purpose, can you create a support case on the nordicsemi.com website and attach your Frontline sniffer files? That will only be visible to Nordic technical support. Log in, go to my page and press "Register a new case" On the support case, refer to this devzone thread. You can nofity me on this thread when you have created the support case, so I can spot it and work furhter on this with Pål.

RE: BLE: disconnection doing connection update procedure

roberto — Mon, 12 Oct 2015 10:26:45 GMT

@Pal, yes it could be possible but I would prefer to send it separately via mail. The reason is that the product is for a tier-1 customer and so from BD address (that is assigned to them) and Service Discovery procedure it is possible to know WHO is developing WHAT and I would avoid attach to a public forum.

RE: BLE: disconnection doing connection update procedure

Pål Håland — Mon, 12 Oct 2015 10:04:00 GMT

@roberto, could you please provide the Frontline sniffer files so that we could browse them easier?

RE: BLE: disconnection doing connection update procedure

Stefan Birnir Sverrisson — Wed, 07 Oct 2015 10:53:17 GMT

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

RE: BLE: disconnection doing connection update procedure

roberto — Wed, 07 Oct 2015 09:51:09 GMT

@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.

RE: BLE: disconnection doing connection update procedure

Stefan Birnir Sverrisson — Wed, 07 Oct 2015 09:22:34 GMT

@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?

RE: BLE: disconnection doing connection update procedure

roberto — Tue, 06 Oct 2015 13:27:26 GMT

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

RE: BLE: disconnection doing connection update procedure

Stefan Birnir Sverrisson — Thu, 01 Oct 2015 21:18:48 GMT

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

RE: BLE: disconnection doing connection update procedure

roberto — Thu, 01 Oct 2015 14:47:48 GMT

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

RE: BLE: disconnection doing connection update procedure

Louis — Thu, 01 Oct 2015 14:37:45 GMT

Hello Stefan, No I had not opened a case because this issue had disappeared when I had updated the MotoX 2013 with the lollipop.

RE: BLE: disconnection doing connection update procedure

Stefan Birnir Sverrisson — Thu, 01 Oct 2015 12:39:07 GMT

@Roberto Thank you for you observation. I will try to have this investigated on our side

Did you have this to work properly with other Android phones? If so, which phones and Android versions?

@Louis Have you asked a devzone question for your SD 130 8.0 issue? If so, which question?

RE: BLE: disconnection doing connection update procedure

Louis — Wed, 30 Sep 2015 12:52:08 GMT

Hello Roberto,

We have experienced a similar issue on SD 130 8.0 with phones that introduce this gap after the connection update. I am waiting for the investigation from the Nordic team, like you.

Louis

RE: BLE: disconnection doing connection update procedure

roberto — Tue, 29 Sep 2015 07:24:18 GMT

Hello,

has someone looked into this issue? Is the problem clear for you Nordic guys? Should I provide more information?

Thanks

Roberto