BLE Supervisory Timeout Behavior Based on Clock Source and Accuracy Settings

[mlyonupdesigns]

We have a BLE peripheral implementation using the nRF52832 and both the S332 v2.0.0 and v7.0.1 softdevice. We are supplying the LF clock to the nRF52 from an STM32 MCO output through a external buffer and 32KHz source for the STM32 is a 20ppm XTAL. We have over 500K devices in use with the v2.0.0 softdevice and are in pre-production with the v7.0.1 softdevice (< 100 devices in beta).

The radio application configuring the v2.0.0 softdevice is using the following LF clock settings:

source: NRF_CLOCK_LF_SRC_RC

rc_ctiv: 32

rc_temp_ctiv: 33

accuracy: NRF_CLOCK_LF_XTAL_ACCURACY_250_PPM

Our radio application originally was requesting the following connection parameters:

conn interval (min): 15ms

conn interval (max): 30ms

slave latency: 0

conn supervisory timeout: 720ms

and due to other considerations we changed to the following connection parameters:

conn interval (min): 50ms

conn interval (max): 100ms

slave latency: 0

conn supervisory timeout: 720ms

Since making this change we seem to experience more frequent disconnects, and I'm assuming it is due to connection supervisory timeouts. Annecdotally, it appears to happen when users have numerous BLE/WiFi functions active on their mobile device simultaneous with our application connection.

I have started out with the radio application configuring the v7.0.1 softdevice using the following LF clock settings:

source: NRF_CLOCK_LF_SRC_RC

rc_ctiv: 32

rc_temp_ctiv: 33

accuracy: NRF_CLOCK_LF_XTAL_ACCURACY_500_PPM

Even though this device is in pre-production (therefore being used much less), there  are still reports of disconnects..

I have several questions:

1. Is there any down-side to configuring a less accurate LF source (used for setting timing windows) which should minimize the likelihood of supervisory timeouts?

2. Is the 720ms supvervisory timeout too short given the typical 98msec connection interval negotiated with the central (e.g., prior to changing the connection parameters when the connection interval was 30ms requiring 24 missed intervals before the timeout would trigger, now it only requires 8)?

[Simonr]

Hi

1. Sorry, but I'm not sure I'm following your first statement. Do you have a functioning device using an external LF clock (the 20ppm XTAL you're referring to)? 

Is there any down-side to configuring a less accurate LF source (used for setting timing windows)

What kind of timing windows are you referring to here? The scan/advertising intervals, and so on?

2. No, I don't think the supervisory timeout you have set is too short.

What I think is the issue here, is that the clock calibrations are a little too large, causing the RC oscillator to drift too much between each calibration, and therefore causing disconnections. The suggested parameters for using the NRF_CLOCK_LF_SRC_RC are the following:

// </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 0
#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 16
#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 2
#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 1
#endif

Best regards,

Simon

[mlyonupdesigns]

Sorry for the confusion. We have a functioning design that uses a 20ppm XTAL that is reclocked through an STM32 MCU and provided as an output to be used by the nRF52832 as the LF clock input. Because of the reclocking we have always specified a less accurate LF clock source in our nRF52832 application to compensate for any jitter/instability in the clock.

The values for rc_ctiv (32) and rc_temp_ctiv (33) may be holdovers from a first generation product that uses the nRF51422, but these values have been used since the beginning for the second generation product. The change that appeared to noticeably increase the disconnections was changing the connection interval from 30msec to 100msec while keeping the supervisory timeout at 720msec.

On a mobile device where multiple applications are using BLE and WiFi, cannot the resulting demands on radio operation (and a busy RF spectrum) potentially cause supervisory disconnects if the timeout is shorter? Per the Apple Accessory Design guidelines:

"The accessory must set the link supervision timeout to 2 seconds or greater when it is the Bluetooth host to account for the unpredictable nature of RF signals as well as the device's need to service other concurrent wireless systems."