Sporadic Disconnected, reason 8 (GATT timeout)

[emb_dev]

We have a design that uses a simple custom board with an NRF52832 chip, button, accelerometer and onboard battery. For many phones, the operation is quite stable - we connect, bond, and subscribe to notifications and don't see any unusual behavior. However sometimes (especially with Android 7), we connect, bond, and then after a while get disconnected with the timeout. Even though nothing changed in the setup.

Some more information is included below:

/* Configuring BLE enabled services */
#define BLE_LBS_ENABLED 0
#define BLE_BAS_ENABLED 1
#define NRF_SDH_BLE_VS_UUID_COUNT 4
#define NRF_SDH_BLE_GATT_MAX_MTU_SIZE 247
#define NRF_SDH_BLE_GAP_DATA_LENGTH 32
#define NRF_SDH_BLE_GAP_EVENT_LENGTH 10
#define BLE_ADVERTISING_ENABLED 1
#define NRF_BLE_CONN_PARAMS_MAX_SLAVE_LATENCY_DEVIATION 5

#define TX_POWER                            (-16)
#define CONN_SUP_TIMEOUT                    MSEC_TO_UNITS(6000, UNIT_10_MS)         /**< Connection supervisory time-out. */

We used the nRF Sniffer to capture the disconnect:

htc10-disconnect.pcapng

This error only happens sporadically, we do not see a pattern. On some phones  - as the one with device information below that was used for the sniffer trace - it happens more frequently.

We do not know what to change to improve the connection stability at the moment, so every hint would be helpful.

Thank you in advance for helping us out!

[emb_dev]

It seems to be more stable now (edit: another disconnect reason 8 happened just now). At the same time it only happens sporadically so from the short test I can't really tell. The problem with the different clock source is the power consumption, is there another way to handle this?

[Vidar Berg]

My idea was to try synthesized clock to see if it would affect the fail rate or not. If it did we would know that it probably had something to do with the LF crystal oscillator. E.g. maybe the tolerance of your crystal is really 40 ppm, and not 20 ppm as stated in your configuration.

Edit: you can change back to the NRF_CLOCK_LF_SRC_XTAL and try to lower the NRF_SDH_CLOCK_LF_ACCURACY up to 500 ppm to see if it has the same effect as using NRF_CLOCK_LF_SRC_SYNTH.

The NRF_SDH_CLOCK_LF_ACCURACY setting determines how much clock drift the protocol stack has to compensate for (i.e. how large the RADIO RX listening window has to be) to not miss connection events. Just keep in mind that this will have a small negative impact on the average current consumption during connections.

The root cause might be excessive clock drift on the phone as well. In that case, you may be see some improvement if you reboot the phone first.