RE: The selection of LFCLK in the "ble_app_uart"

senoo — Mon, 11 Sep 2017 01:36:06 GMT

I appreciate your kind support. Best regards Senoo

RE: The selection of LFCLK in the "ble_app_uart"

Jørn — Fri, 08 Sep 2017 11:24:01 GMT

I have updated my answer.

RE: The selection of LFCLK in the "ble_app_uart"

senoo — Fri, 08 Sep 2017 06:13:29 GMT

I'm sorry. Please advise about the effect on ble_conn_params module when using internal RC oscillation circuit. The area to implement the external XTAL and GPIP pins is insufficient, we are very pleased if the built-in RC oscillation circuit can be used. Is there a case where the BLE communication application based on ble_app_uart is operating stably using the built-in RC oscillation circuit in the past? I expect that to be okay.

RE: The selection of LFCLK in the "ble_app_uart"

senoo — Fri, 08 Sep 2017 05:51:56 GMT

Thanks to very much! Our product development has been accelerated! Regards, Senoo

RE: The selection of LFCLK in the "ble_app_uart"

Jørn — Thu, 07 Sep 2017 14:45:14 GMT

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