• State Verified Answer
  • Replies 5 replies
  • Subscribers 88 subscribers
  • Views 2703 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 311133
Options

Configuring the RC oscillator's softdevice clock

Ayaan

Hello, Nordic team.

Currently, I am utilizing a custom board, specifically the nRF (52833 or 52840), within the nRF5_SDK 17.1 (S140) environment.

My objective is to gather sensor data every second and transmit it in real-time through BLE. To accomplish this, I have incorporated an Internal RC oscillator into the board, and I have configured the sdk_config accordingly.

#define NRF_SDH_CLOCK_LF_SRC 0
#define NRF_SDH_CLOCK_LF_RC_CTIV 1
#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 0
#define NRF_SDH_CLOCK_LF_ACCURACY 1


My primary concern is to maintain low power consumption. Here are my specific inquiries:

1. Will making adjustments to the RC value of my board according to the recommended setting have any impact on the real-time collection and transmission of sensor data, as well as the accuracy of calendar time measurements?
#define NRF_SDH_CLOCK_LF_SRC 0
#define NRF_SDH_CLOCK_LF_RC_CTIV 16
#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2
#define NRF_SDH_CLOCK_LF_ACCURACY 1

2. I would appreciate some clarification on NRF_SDH_CLOCK_LF_ACCURACY. It has been noted that the recommended stability of the RC oscillator is attained when the value exceeds 500 PPM. Should I consider 500 PPM as a fixed value, or can it be adjusted? I have noticed that modifying this value triggers a warning message.(I believe that reducing it below the recommended value might result in dropped packets rather than reducing power consumption.)

3. Is there a theoretical way to calculate clock misalignment?


Best regards!
Ayaan

Parents
  • 0

    Hi

    1. It's strongly recommended to do calibration with the parameters you mention in Q1, as that will calibrate the internal RC oscillator to avoid drift that may cause issues for the SoftDevice, and make the calendar functionality inaccurate. The best middle ground for good accuracy and low power consumption would be to have an external LF crystal (32.768kHz) instead of using the internal RC oscillator though, but if you've already designed the HW then the RC oscillator with these calibration settings is your best option I think.

    #define NRF_SDH_CLOCK_LF_SRC 0
    #define NRF_SDH_CLOCK_LF_RC_CTIV 16
    #define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2
    #define NRF_SDH_CLOCK_LF_ACCURACY 1

    2. The NRF_SDH_CLOCK_LF_ACCURACY is the accuracy of the clock used in the link layer. This must be set to 1 when using the RC oscillator, as it's the only value the internal RC oscillator supports. If using an external LF crystal, it supports better accuracy values, where 20ppm is the standard.

    3. Not really, it is based on multiple factors, and will slightly vary from chip to chip, operating conditions such as temperature, etc.

    Best regards,

    Simon

  • 0 in reply to Simonr

    Hi,

    I guess my question was vague.

    My goal is to increase the accuracy of the calendar time measurement.
    To further compensate for the error in the timer, we adjusted the calibration interval.
    However, I'm not sure how much the level of calibration affects the overall result.
    Also, the faster the calibration interval, the higher the current.

    The current calibration period value is faster than the recommended value.
    For the internal RC oscillator settings, see NRF_SDH_CLOCK_LF_RC,
    #define NRF_SDH_CLOCK_LF_RC_CTIV 1 (my cycle)
    #define NRF_SDH_CLOCK_LF_RC_CTIV 16 (recommended cycle)

    1. Does increasing the calibration cycle rate beyond the recommended value have an impact on reducing timer errors, and if so, by how much?
    (I would like to know if it is important to increase the calibration cycle rate).

    2. Also, what can we expect in terms of timer errors per hour based on the recommended values?

    question needs a little more clarification.

    best regards!
    Ayaan

  • 0 in reply to Ayaan

    Hi again

    1. No, it won't impact the timer drift a noticable amount. The better way to ensure an accurate clock would be to use either of the other LF clock sources for these timers.

    2. Can you clarify what a "timer error" is in this context? Are you having issues in your application with the timer being noticably inaccurate or what exactly?

    Best regards,

    Simon

Reply
  • 0 in reply to Ayaan

    Hi again

    1. No, it won't impact the timer drift a noticable amount. The better way to ensure an accurate clock would be to use either of the other LF clock sources for these timers.

    2. Can you clarify what a "timer error" is in this context? Are you having issues in your application with the timer being noticably inaccurate or what exactly?

    Best regards,

    Simon

Children
Related