This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

RC oscillator Frequency tolerance for LFRC after calibration(accuracy increment)

Dear Nordic,

We have almost completed development with nRF52810.

We are trying to improve the accuracy of product operation.

RC oscillator(LFRC) is currently used as the internal clock source.

Frequency tolerance for LFRC after calibration is shown as +/- 500ppm on the datasheet.

 * Constant temperature within ±0.5 °C and calibration performed at least every 8 seconds, defined as 3 sigma

The part I can't understand is below.

---------------------------------------------------------------------------------

# 32.768 kHz RC oscillator (LFRC)

    Frequency tolerance for LFRC after calibration / ± 500 ppm

# 32.768 kHz crystal oscillator (LFXO) specification.

    Frequency tolerance requirement for BLE stack / ± 250 ppm

---------------------------------------------------------------------------------

1. Why is the Frequency tolerance range applied to the RC oscillator(LFRC) and Crystal oscillator(LFXO) set differently?

1.1 Why is the Frequency tolerance for LFRC after calibration that didn't meet the specifications(Frequency tolerance requirement for BLE stack / ± 250 ppm)?

2. Is there a way to set the Frequency tolerance for LFRC after calibration of RC Oscillator to ± 250ppm? 

2.1 Or RC Oscillator can it be set under ± 250 ppm?

3. Should I use an external crystal to need a frequency tolerance under ± 250ppm?

4. Is there any problem running the BLE stack even at RC oscillator(LFRC) frequency tolerance ± 500 ppm?

Thank you and Best Regards,

Sungsuk Han.

  • Hi Sungsuk,

    1. Why is the Frequency tolerance range applied to the RC oscillator(LFRC) and Crystal oscillator(LFXO) set differently?

    I do not think a higher tolerance then 250 ppm was ever considered for the LFXO since it makes little sense to use a crystal instead of the RC oscillator if the crystal is not more accurate.

    1.1 Why is the Frequency tolerance for LFRC after calibration that didn't meet the specifications(Frequency tolerance requirement for BLE stack / ± 250 ppm)?

    This is due to erratum 146. The intention was for the LFRC to be within ± 250ppm, but due to the errata, it is within 500 ppm. The SoftDevice was modified to support this change.

    2. Is there a way to set the Frequency tolerance for LFRC after calibration of RC Oscillator to ± 250ppm? 

    No. The actual tolerance will be ± 500ppm no matter what, but you can configure the SoftDevice to consider it ± 250ppm. That does not make any sense though, as you could save a negligible amount of current due to smaller listening windows in a BLE connection, but you would also increase the chance of packet loss.

    2.1 Or RC Oscillator can it be set under ± 250 ppm?

    No. The accuracy is always withing ± 500 ppm, but we cannot guarantee anything lower than that.

    3. Should I use an external crystal to need a frequency tolerance under ± 250ppm?

    Yes. That is the only option to get a higher LFCLK accuracy and is precisely the reason why customers choose to use a 32.768 kHz crystal.

    4. Is there any problem running the BLE stack even at RC oscillator(LFRC) frequency tolerance ± 500 ppm?

    No, that is fully supported and not a problem.

    Br,

    Einar

  • Hi, Einar.

    Thank you for your answer.

    Let me ask you some question. (About the answer No. 2)

    1. Please tell me how to configure the SoftDevice to ±250 ppm.

    2. Why does the consumption current decrease when the SoftDevice is configured to ±250 ppm?

    3. Why does the chance of packet loss increase when the SoftDevice is configured to ±250 ppm?

    Thanks in advance.

    Sungsuk Han.

  • Hi Sungsuk,

    nunjjaram said:
    1. Please tell me how to configure the SoftDevice to ±250 ppm.

    I strongly advise against this, since the physical properties of the clock make it ±500 ppm regardless of how you configure the SoftDevice. So it is a bad idea that can lead to packet losses (and connection losses). That said, assuming you use the SoftDevice handler library as the SDK examples do, you just need to change NRF_SDH_CLOCK_LF_ACCURACY in sdk_config.h according to the comment. E.g., set it to 0 for 250 ppm and 1 for 500 ppm. If you use the internal RC, then the only recommended configuration is 1 (500 ppm).

    nunjjaram said:
    2. Why does the consumption current decrease when the SoftDevice is configured to ±250 ppm?

    This is because in BLE, the radio is on for a fixed amount of time during connection events, and this amount of time is widened based on the combined clock inaccuracy of the peers. The more inaccurate the clocks, the wider the window. And the wider the window, the higher current consumption. This is not a very big effect, though. You can experiment with the online power calculator to see the effects of different clock accuracies (the only two options are internal RC and an external crystal). The difference is generally not very big.

    nunjjaram said:
    3. Why does the chance of packet loss increase when the SoftDevice is configured to ±250 ppm?

    That is because the LFRC is ±500 ppm, and if you configure the SoftDevice to behave as if it is more accurate than it is, then the listening window might be too small sometimes, and a packet may be received after the end of the window when the radio is no longer in Rx mode. This would be the same problem in both directions.

    Einar

  • Einar, Thank you very much.

    Thanks to your answers I was able to understand.

    There is one thing that confuses me.

    In the previous answer, you have let me know that there is no problem with the LFRC oscillator's frequency tolerance +/- 500 ppm to fully support the BLE stack.

    If so, it will have to fully support the BLE stack even if use frequency tolerance +/- 500ppm crystal oscillator(LFXO).

    And, the specification should have indicated that the frequency tolerance requirement for BLE stack is +/- 500 ppm.

    However, +/-250ppm was suggested in the data sheet as a specification for using the BLE statck.

    This confuses me. 

    You say there is no problem(RC Oscillator tolerance +/- 500 ppm), but I am not sure.

    If there's really no problem, both specifications should have changed. (LFRC, LFXO)

    What do you think? Isn't that a little strange?

    Thank you and Best Regards,

    Sungsuk Han.

  • Hi Sungsuk,

    nunjjaram said:

    However, +/-250ppm was suggested in the data sheet as a specification for using the BLE statck.

    This confuses me. 

    You say there is no problem(RC Oscillator tolerance +/- 500 ppm), but I am not sure.

    If there's really no problem, both specifications should have changed. (LFRC, LFXO)

    What do you think? Isn't that a little strange?

    This is for historic reasons. The SoftDevice initially only supported up to ±250 ppm, since the LFRC on the nRF52832 was supposed to have an accuracy of ±250 ppm. But due to erratum 146, this is not the case, and therefore the SoftDevice behavior was changed to support ±500 ppm. So to sum up: The actual accuracy of the LFRC is ±500 ppm even if the product specification states ±250 ppm, and the SoftDevice actually supports ±500 ppm.

    Einar

Related