The selection of LFCLK in the "ble_app_uart"

[senoo]

Hello,

In our product, we would like to select LFCLK from the following choices instead of external XTAL.

• NRF_CLOCK_LF_SRC_RC
• NRF_CLOCK_LF_SRC_SYNTH

However, it is unclear how these differences in accuracy affect the behavior of ble_app_uart. So, please tell me about the risk of choosing each one.

Below is my current situation. From the follwing Web pege, I found the following comments. But I can not understand why that is.

---

[Web page]

devzone.nordicsemi.com/.../

[found comments]

In general NRF_CLOCK_LF_SRC_SYNTH is not recommended. If you don't have an external 32 kHz crystal, it is recommended to use NRF_CLOCK_LF_SRC_RC.

---

And I know that RC is less accurate than XTAL. However, I do not understand how this affects the behavior of ble_app_uart.

Regards, Senoo

[Jørn]

Hello senoo.

The BSP module uses app_timer, which uses the RTC module which again uses LFCLK as clock source. The BSP module handles buttons, LEDS, state indications etc. You can read more about the BSP module here. LFCLK accuracy should not affect this in any notable way.

The power management module also employs the app_timer module. The RTC uses very little power while running, and is therefore used to supervise sleep durations and to wake the CPU after a certain amount of time. LFCLK accuracy could potentially cause give wrong sleep duration results or wake the CPU prematurely/too late if the CPU sleeps for long periods of time.

The ble_conn_params module also uses the app_timer module which uses the timer during negotiation routines. You can read more about the module here

Beyond this I haven't found anything that should affect the performance of the ble_app_uart example.

Do note that the synthesized LFCLK needs to have the HFCLK running to work, and has increased power consumption compared to the RC based LFCLK.

EDIT

If you look at the files ble_conn_params.h and ble_conn_params.c you will see it uses app_timer to track time between parameter negotiation attempts.

The actual timings are defined in main as

#define FIRST_CONN_PARAMS_UPDATE_DELAY  APP_TIMER_TICKS(5000)                       /**< Time from initiating event (connect or start of notification) to first time sd_ble_gap_conn_param_update is called (5 seconds). */
#define NEXT_CONN_PARAMS_UPDATE_DELAY   APP_TIMER_TICKS(30000)                      /**< Time between each call to sd_ble_gap_conn_param_update after the first call (30 seconds). */

I conferred with a colleague and he pointed me to this errata. As stated in the workaround you should configure the RC oscillator for 500 ppm accuracy.

500 ppm is within the Bluetooth specification, so using it for BLE communications should not be a problem.

So with the errata in mind the RC oscillator has a accuracy of +/-500 ppm, while the XTAL on the nRF52 DK has a accuracy of +/-20 ppm. During the longest waiting period of 30 seconds the 20ppm crystal would, at worst case, be 600 us off. With 500 ppm you end up at 15 ms off.

Do keep in mind that the current consumption of the RC oscillator is larger than with the crystal oscillator.

Best regards

Jørn Frøysa

[Jørn]

I have updated my answer.