Connection drop immediately in specific Android models

[Charadhar Rddy]

Device/SW Info:

Ubuntu 18.1
SDK : 15.0
SD 132 v 6.0

NRF52832 QFAAE1

The device once connected to the device is immediately dropping the connection upon going into discoverServices(), as seen in the logs. I am unable to understand the reason exactly. The same behaviour is seen in OnePlus 5, Vivo Nex Smartphones. Surprisingly, phones from same brand, OnePus 3 and OnePlus 6 don't exhibit this behaviour. Please suggest if something can be done to fix this

nRF Connect, 2019-03-16
TestDevice (FB:55:34:92:A5:46)
V	11:29:39.723	Connecting to FB:55:34:92:A5:46...
D	11:29:39.723	gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, preferred PHY = LE 1M)
D	11:30:05.422	[Callback] Connection state changed with status: 0 and new state: CONNECTED (2)
I	11:30:05.422	Connected to FB:55:34:92:A5:46
D	11:30:05.424	[Broadcast] Action received: android.bluetooth.device.action.ACL_CONNECTED
V	11:30:05.452	Discovering services...
D	11:30:05.452	gatt.discoverServices()
D	11:30:05.452	[Callback] Connection state changed with status: 34 and new state: DISCONNECTED (0)
E	11:30:05.453	Error 34 (0x22): GATT CONN LMP TIMEOUT
I	11:30:05.453	Disconnected
D	11:30:05.461	[Broadcast] Action received: android.bluetooth.device.action.ACL_DISCONNECTED

I have attached Sniffer trace from one working model and one not working model. The trace is for just connection using nrf Connect app. One is from Xiaomi brand, this works perfectly. The second trace is from OnePlus brand, where the issue is happening. It seems to be something related to LL_PHY_REQ. Once this opcode is sent, the connection basically goes dead.

PFA the pcapng from Wireshark:

BLESniff_OnePlus5_(NRFConnect-1).pcapng

BLESniff_Xiaomi_(Connect Using NRF Connect).pcapng

[Hung Bui]

LMP TIMEOUT is Link Manager Protocol Timeout. This happens when a link layer request didn't get a response after (usually) 30 seconds. It would be much easier to know what exactly causing the issue if you can provide a sniffer trace. 

[Charadhar Rddy]

Hi Hung Bui,

I have attached the logs above. Can you please check now to see if it makes things any clearer?

[Hung Bui]

Ok, so it looks like that the phone tried to change PHY (1Mbps or 2Mbps or Long range)  and was waiting for the response from the NRF52 but received nothing, so it disconnected after awhile. It's not "immediately dropped" , the connection remains 40 seconds after the request. 

So you would need check if you handle BLE_GAP_EVT_PHY_UPDATE_REQUEST event in your ble_evt_handler() in main.c or not (it's by default handled there in our examples in the SDK) , you would need to call sd_ble_gap_phy_update() to reply to the request, on which PHY you want to use.