Bonded peripheral is disconnected after few minutes

[Gilpa]

Hi,

My product is automagically disconnected from the central after 9min of connection...

The same problem can be reproduced from the ble_app_template example as is, on a NRFDK. The device is disconnected from the central after 9min too.
The disconnection appear only when the peripheral is bonded with the central.

Central configuration:
- Phone: Wiko Rainbow with Android 4.4.2
- NrfConnect

Peripheral configuration:
- NRFDK PCA10040 v1.1.0
- Softdevice s132_nrf52_6.0.0_softdevice.hex
- NRF SDK 15
- Sources : unmodified ble_app_template from sdk examples

Steps to reproduce:
- Both mobile and peripheral are clean (device completely erased & flashed and everything is clear on the BLE side of the mobile phone)
- From NrfConnect bond the device to the mobile phone
- Connect to the device and do nothing else than waiting 9 minutes
- The peripheral should be disconnected from the central with reason 0x08 / BLE_HCI_CONNECTION_TIMEOUT (BLE_GAP_EVT_DISCONNECTED)

Any help will be appreciated to understand why the link is automagically disconnected after 9min when the peripheral is bonded and connected to the mobile phone.

Regards.

[Einar Thorsrud]

Hi Paul,

Do you have a sniffer trace of the communication between the phone and the nRF? Does it only happen with the Wiko Rainbow, or does it also happen with other centrals?

[Gilpa]

Hi Einar,

The sniffer trace doesn't show anything very relevant... Empty PDUs are exchanged between the slave and the master (normal because I do nothing else other than being connected). When the disconnect occurs, no more empty PDUs and the slave simply advertise again.

I've tested with another phone this morning (Samsung S6 with Android 7.0) and everything works as expected (no disconnection).

With the Wiko I can also reproduce the bug with the ble_app_hrs example from the SDK 15.

[Einar Thorsrud]

Sounds like there is a problem on the phone side, then. Have you checked the log from the nRF Connect app (You can get the log by swiping to the right)? Any clues there?

[Gilpa]

As requested, here is the log from NrfConnect :

nRF Connect, 2018-04-30
Nordic_Template (C3:79:D8:30:9F:AC)
V 14:25:00.470 Connecting to C3:79:D8:30:9F:AC...
D 14:25:00.470 gatt = device.connectGatt(autoConnect = false)
D 14:25:01.307 [Callback] Connection state changed with status: 0 and new state: CONNECTED (2)
I 14:25:01.307 Connected to C3:79:D8:30:9F:AC
D 14:25:01.308 [Broadcast] Action received: android.bluetooth.device.action.ACL_CONNECTED
D 14:25:01.313 wait(1600ms)
V 14:25:02.914 Discovering services...
D 14:25:02.914 gatt.discoverServices()
D 14:25:02.962 [Callback] Services discovered with status: 0
I 14:25:02.962 Services discovered
V 14:25:02.976 Generic Access (0x1800)
- Device Name [R W] (0x2A00)
- Appearance [R] (0x2A01)
- Peripheral Preferred Connection Parameters [R] (0x2A04)
- Central Address Resolution [R] (0x2AA6)
Generic Attribute (0x1801)
- Service Changed [I] (0x2A05)
   Client Characteristic Configuration (0x2902)
D 14:25:02.977 gatt.setCharacteristicNotification(00002a05-0000-1000-8000-00805f9b34fb, true)
D 14:33:45.669 [Broadcast] Action received: android.bluetooth.device.action.ACL_DISCONNECTED
I 14:33:45.670 Disconnected
D 14:33:45.683 [Callback] Connection state changed with status: 0 and new state: DISCONNECTED (0)
D 14:33:45.685 gatt.refresh() (hidden)

Hope that will help

[Einar Thorsrud]

There is no indication on what caused the disconnect in the log. From the nRF side there was a timeout, though. One theory is that perhaps the phone has a lower clock accuracy than reported. In that case, the transmit/receive window might not overlap at some point. You could probably test that by configuring a lower clock accuracy on the nRF52832 side (assuming you use a crystal, you could set NRF_SDH_CLOCK_LF_ACCURACY to 500 ppm). This would increase the margin. If not, there is probably something else happening within the phone, but it is difficult to say exactly what.