Hello Nordic,
Due to recent shortages we have switched from a BLE module with external LF oscillator (uBlox Nina-B3) to a module without external LF (Laird BL654). We have configured the SDK (v16.0) to use the internal RC oscillator and use calibration.
We are however now receiving feedback (did not get this before) that the device is not always showing up in the phones Bluetooth settings screen when advertising. This appears to be happening randomly, as sometimes the device shows up immediately. Some also report that the device only shows as a MAC address, and that the phone hangs on retrieving the advertised device name. Additionally, windows can generate a 'Driver error' when trying to connect to a windows PC, but this is not our main use case so we're not sure that this never happened before.
The project is originally based on the HID example provided with the SDK.
Once the device is connected (so after it was discovered by the phone), the connection is stable and reconnecting (we use bonds) goes smoothly. We suspect this is because we use quite forgiving connection parameters:
#define MIN_CONN_INTERVAL MSEC_TO_UNITS(11.25, UNIT_1_25_MS) #define MAX_CONN_INTERVAL MSEC_TO_UNITS(30, UNIT_1_25_MS) #define SLAVE_LATENCY 30 #define CONN_SUP_TIMEOUT MSEC_TO_UNITS(3000, UNIT_10_MS)
- Could this stability be caused by a misconfiguration of the LF oscillator? So because of timing errors some packets are missed etc. Here are our configurations:
#define NRFX_CLOCK_CONFIG_LF_SRC (USE_INTERNAL_LF ? 0 : 1) #define CLOCK_CONFIG_LF_SRC (USE_INTERNAL_LF ? 0 : 1) #define CLOCK_CONFIG_LF_CAL_ENABLED (USE_INTERNAL_LF ? 1 : 0) #define NRF_SDH_CLOCK_LF_SRC (USE_INTERNAL_LF ? 0 : 1) #define NRF_SDH_CLOCK_LF_RC_CTIV (USE_INTERNAL_LF ? 16 : 0) #define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV (USE_INTERNAL_LF ? 2 : 0) #define NRF_SDH_CLOCK_LF_ACCURACY (USE_INTERNAL_LF ? 1 : 7)
Please let me know if we did something wrong. The `USE_INTERNAL_LF` macro is a boolean defined by the build process (as we build for different hardware, with or without XTAL).
2. We call `nrf_drv_clock_init()` in `main` before the call to `ble_stack_init()` at the end of `main`. I think we did this for early timestamping, but maybe we can remove this call if it interferes with the softdevice enabling the clock?
3. If 1 & 2 are not the problem and the RC oscillator is correctly configured, is this decrease in performance when using RC vs. XTAL expected? Could it be improved by increasing `NRF_SDH_CLOCK_LF_RC_TEMP_CTIV`?
4. Finally, what would be the best solution if this is expected from the RC oscillator? Should we: decrease the advertising intervals? Increase fast advertising duration? Increase TX power (currently at default = 0dBm) to +4 or +8 dBm?
#define APP_ADV_FAST_INTERVAL MSEC_TO_UNITS(20, UNIT_0_625_MS) #define APP_ADV_SLOW_INTERVAL MSEC_TO_UNITS(125, UNIT_0_625_MS) #define APP_ADV_FAST_DURATION MSEC_TO_UNITS(5000, UNIT_10_MS) #define APP_ADV_SLOW_DURATION MSEC_TO_UNITS(45000, UNIT_10_MS)
Maybe the RC oscillator is just a huge red herring for me and the problem lies elsewhere, but the firmware has worked fine before so this is the only thing I can think of.
Thanks
