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