Inconsistent behavior when connecting from Custom BLE device to nrf52dk running different SDKs

RE: Inconsistent behavior when connecting from Custom BLE device to nrf52dk running different SDKs

Sigurd — Wed, 19 Sep 2018 12:40:55 GMT

[quote user="Alexandr Kolodinsky"]Is there a way to explicitly control ChSel #1 / #2 in Nordic SDK? [/quote]

No, that is not possible. The SoftDevice is following the BLE spec, so I would recommend reporting this issue to the Bluez developers. (I see that Bluez version 5.50 is released, so it might be a chance that it’s fixed in that version.)

RE: Inconsistent behavior when connecting from Custom BLE device to nrf52dk running different SDKs

Alexandr Kolodinsky — Wed, 19 Sep 2018 09:52:52 GMT

Yes, the issue is the same with SDK 15.2. I can't yet post the sniffer log for security reasons, but you last answer lead to a different DevZone issue where ChSel #1 / #2 is discussed.

Sniffer logs analysis has shown that:

Our custom BLE Central device always offers ChSel #2
DK running SDK 13 as Peripheral offers ChSel #1
DK running SDK 14+ as Peripheral offers ChSel #2

Apparently when both devices offer #2 - they use it and this isn't handled correctly.

Is there a way to explicitly control ChSel #1 / #2 in Nordic SDK? At least for debugging purposes we'd like to try SDK 14+ with ChSel #1 offer. Is it possible?

Thank you for your help!

RE: Inconsistent behavior when connecting from Custom BLE device to nrf52dk running different SDKs

Sigurd — Mon, 17 Sep 2018 16:25:21 GMT

[quote userid="73930" url="~/f/nordic-q-a/38499/inconsistent-behavior-when-connecting-from-custom-ble-device-to-nrf52dk-running-different-sdks/149091"]What is so significantly different between these?[/quote]

One significant difference is that s132_nrf52_5.0.0_softdevice is a Bluetooth 5 qualified SoftDevice and uses Channel Selection algorithm #2. It could be that Bluez somwhow does not handle this correctly.

Do you see the same issue with SDK 15.2 ?

A sniffer trace could be helpful(see this page).

RE: Inconsistent behavior when connecting from Custom BLE device to nrf52dk running different SDKs

Alexandr Kolodinsky — Mon, 17 Sep 2018 15:31:12 GMT

Results are 100% consistent:

connectivity never fails when connecting to DK running SDK 13.1
connectivity always fails when connecting to DK running SDK 14+

As per above, RC clock source was also validated, just with a different setting:

NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 4 (not 2 as you propose, unlikely this is significant).

If it was soldering or RF problem - why would it then work OK with SDK 13.1? What is so significantly different between these?

Thanks!

RE: Inconsistent behavior when connecting from Custom BLE device to nrf52dk running different SDKs

Sigurd — Mon, 17 Sep 2018 13:16:02 GMT

62(0x3E ) is BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED. This is normally a sign that one of the peers have lost packets during the initial "CONNECT_REQ" process. You can get into a scenario where you receive the request, but the central does not get the ACK from the peripheral. This can happen if the RF link quality is bad (ie: connecting at a long range), or when there is an issue with the RF layout (soldering is bad or similar).

How often do you see this issue? Are you able to reliable recreate it?

To rule out any problems with the LF crystal, you could try to use the RC oscillator:

Try these values in sdk_config.h

// </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_XTAL_ACCURACY  - External crystal clock accuracy used in the LL to compute timing windows.
 
// <0=> NRF_CLOCK_LF_XTAL_ACCURACY_250_PPM 
// <1=> NRF_CLOCK_LF_XTAL_ACCURACY_500_PPM 
// <2=> NRF_CLOCK_LF_XTAL_ACCURACY_150_PPM 
// <3=> NRF_CLOCK_LF_XTAL_ACCURACY_100_PPM 
// <4=> NRF_CLOCK_LF_XTAL_ACCURACY_75_PPM 
// <5=> NRF_CLOCK_LF_XTAL_ACCURACY_50_PPM 
// <6=> NRF_CLOCK_LF_XTAL_ACCURACY_30_PPM 
// <7=> NRF_CLOCK_LF_XTAL_ACCURACY_20_PPM 

#ifndef NRF_SDH_CLOCK_LF_XTAL_ACCURACY
#define NRF_SDH_CLOCK_LF_XTAL_ACCURACY 1
#endif

RE: Inconsistent behavior when connecting from Custom BLE device to nrf52dk running different SDKs

Alexandr Kolodinsky — Mon, 17 Sep 2018 12:32:10 GMT

<info> app: Disconnected reason: 62.

RE: Inconsistent behavior when connecting from Custom BLE device to nrf52dk running different SDKs

Sigurd — Mon, 17 Sep 2018 11:10:32 GMT

Could you print the disconnect reason?

In ble_evt_handler, you could do something like this:

        case BLE_GAP_EVT_DISCONNECTED:
        
            NRF_LOG_INFO("Disconnected reason: %d.",p_ble_evt->evt.gap_evt.params.disconnected.reason);

RE: Inconsistent behavior when connecting from Custom BLE device to nrf52dk running different SDKs

Alexandr Kolodinsky — Mon, 17 Sep 2018 08:58:27 GMT

We use XTAL for the posted results, tried different NRF_SDH_CLOCK_LF_XTAL_ACCURACY values.

In other attempts we also used RC as a clock source with different NRF_SDH_CLOCK_LF_RC_CTIV values - no luck either.

Here's our current sdk_config.h configuration:

//==========================================================
// <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_XTAL_ACCURACY  - External crystal clock accuracy used in the LL to compute timing windows.
 
// <0=> NRF_CLOCK_LF_XTAL_ACCURACY_250_PPM 
// <1=> NRF_CLOCK_LF_XTAL_ACCURACY_500_PPM 
// <2=> NRF_CLOCK_LF_XTAL_ACCURACY_150_PPM 
// <3=> NRF_CLOCK_LF_XTAL_ACCURACY_100_PPM 
// <4=> NRF_CLOCK_LF_XTAL_ACCURACY_75_PPM 
// <5=> NRF_CLOCK_LF_XTAL_ACCURACY_50_PPM 
// <6=> NRF_CLOCK_LF_XTAL_ACCURACY_30_PPM 
// <7=> NRF_CLOCK_LF_XTAL_ACCURACY_20_PPM 

#ifndef NRF_SDH_CLOCK_LF_XTAL_ACCURACY
#define NRF_SDH_CLOCK_LF_XTAL_ACCURACY 7
#endif

Thanks for the reply!

RE: Inconsistent behavior when connecting from Custom BLE device to nrf52dk running different SDKs

Sigurd — Fri, 14 Sep 2018 12:08:11 GMT

Hi,

Are you using the LF RC oscillator ?

What is the value of NRF_SDH_CLOCK_LF_SRC and NRF_SDH_CLOCK_LF_XTAL_ACCURACY in sdk_config.h?

Note that starting from s132_nrf52_5.0.0-2.alpha, the application need to set the accuracy/ppm of the RC oscillator itself. From the s132_nrf52_5.0.0-2.alpha release notes:

The RC oscillator accuracy can now be set to any of the defined NRF_CLOCK_LF_ACCURACY values, and there is no default anymore. In other words, the nrf_clock_lf_cfg_t::accuracy parameter now has the same functionality when used with the RCOSC clock source as with the XTAL clock source