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!

[Vidar Berg]

Hello,

Please let me know what LF clock configuration you use as well (i.e. NRF_SDH_CLOCK_LF_SRC, NRF_SDH_CLOCK_LF_RC_CTIV, NRF_SDH_CLOCK_LF_RC_TEMP_CTIV, and NRF_SDH_CLOCK_LF_ACCURACY in sdk_config.h).. The sniffer trace is showing a high number of re-transmits (mostly the slave not receiving the packets from the master) and I'm wondering if it might be due to clock drift.

Also, I see you define TX_POWER as -16, does that mean the TX output power is only set to -16 dBm during connections? If so, do you see any improvement if you increase it?

Best regards,

Vidar

[emb_dev]

Hello,

this is the LF clock configuration:

// </h> 
//==========================================================

// <h> Clock - SoftDevice clock configuration

//==========================================================
// <o> NRF_SDH_CLOCK_LF_SRC  - SoftDevice clock source.
 
// <0=> NRF_CLOCK_LF_SRC_RC 
// <1=> NRF_CLOCK_LF_SRC_XTAL 
// <2=> NRF_CLOCK_LF_SRC_SYNTH 

#ifndef NRF_SDH_CLOCK_LF_SRC
#define NRF_SDH_CLOCK_LF_SRC 1
#endif

// <o> NRF_SDH_CLOCK_LF_RC_CTIV - SoftDevice calibration timer interval. 
#ifndef NRF_SDH_CLOCK_LF_RC_CTIV
#define NRF_SDH_CLOCK_LF_RC_CTIV 0
#endif

// <o> NRF_SDH_CLOCK_LF_RC_TEMP_CTIV - SoftDevice calibration timer interval under constant temperature. 
// <i> How often (in number of calibration intervals) the RC oscillator shall be calibrated
// <i>  if the temperature has not changed.

#ifndef NRF_SDH_CLOCK_LF_RC_TEMP_CTIV
#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 0
#endif

// <o> NRF_SDH_CLOCK_LF_ACCURACY  - External clock accuracy used in the LL to compute timing.
 
// <0=> NRF_CLOCK_LF_ACCURACY_250_PPM 
// <1=> NRF_CLOCK_LF_ACCURACY_500_PPM 
// <2=> NRF_CLOCK_LF_ACCURACY_150_PPM 
// <3=> NRF_CLOCK_LF_ACCURACY_100_PPM 
// <4=> NRF_CLOCK_LF_ACCURACY_75_PPM 
// <5=> NRF_CLOCK_LF_ACCURACY_50_PPM 
// <6=> NRF_CLOCK_LF_ACCURACY_30_PPM 
// <7=> NRF_CLOCK_LF_ACCURACY_20_PPM 
// <8=> NRF_CLOCK_LF_ACCURACY_10_PPM 
// <9=> NRF_CLOCK_LF_ACCURACY_5_PPM 
// <10=> NRF_CLOCK_LF_ACCURACY_2_PPM 
// <11=> NRF_CLOCK_LF_ACCURACY_1_PPM 

#ifndef NRF_SDH_CLOCK_LF_ACCURACY
#define NRF_SDH_CLOCK_LF_ACCURACY 7
#endif

Increasing the TX Power to 0dBm does also result in the high number of re-transmits.

[Vidar Berg]

Hello,

As a test, can you please try to select the NRF_CLOCK_LF_SRC_SYNTH source and repeat the test? This is to rule out any issues with the 32KHz crystal.

Best regards,

Vidar

[emb_dev]

Yes, here is the sniffer result: lf_src_synth.pcapng

[Vidar Berg]

Thanks. Have you been able to replicate the sporadic disconnects after changing the clock source? I may have overlooked this earlier, but the re-transmits I see now are to be expected because you have slate latency enabled (slave latency allows the slave to skip x connection events when it doesn't have data to send).

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