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]

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

[roberto]

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.

[roberto]

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.

[Stefan Birnir Sverrisson]

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.

[Craig Carlson]

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