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.

Parents
  • 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

Reply
  • 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

Children
  • Hi Einar,

    The model name we applied for development is nRF52810.

    Looking at the datasheet, nrf52810 is all RC oscillator frequency tolerance is +/-500ppm(after calibration) from PS_v1.0 to PS_v1.3.
    As you can expect from this, the nRF52810 designed at +/-500ppm from the beginning.
    Additionally, as described in the datasheet, the frequency tolerance requirement for the BLE Stack is +/-250 ppm, so the RC oscillator frequency tolerance +/-500ppm is unacceptable.

    By the way, RC oscillator(LFRC) frequency tolerance is +/-500ppm enough, but why should external crystal(LFXO) frequency tolerance be +/-250ppm?

    External crystal(LFXO) frequency tolerance is +/-500ppm should be enough.

    This confuses me. I think this has a clear reason.

    Otherwise,Hmm.... I think the specification of frequency tolerance requirement for BLE Stack is wrong.

    Thank you and Best Regards,

    Sungsuk Han.

  • Hi Sungsuk,

    nunjjaram said:
    Looking at the datasheet, nrf52810 is all RC oscillator frequency tolerance is +/-500ppm(after calibration) from PS_v1.0 to PS_v1.3.
    As you can expect from this, the nRF52810 designed at +/-500ppm from the beginning.

    Yes and no. The nRF52810 is a subset of the nRF52832, wit some fixes to HW and documentation. There is no real difference here, just that for the S132 there is a discrepancy between the datasheet and reality, hence the erratum. And for this reason, the datasheet for the nRF52810 RC oscillator was updated to reflect the reality instead of having the erratum. But that does not imply a difference in the actual HW.

    nunjjaram said:
    Additionally, as described in the datasheet, the frequency tolerance requirement for the BLE Stack is +/-250 ppm, so the RC oscillator frequency tolerance +/-500ppm is unacceptable.

    The datasheet is inaccurate in this regard. The SoftDevice (BLE stack) was updated to support a +/-500 ppm RC oscillator when it was discovered that the HW did not meet +/- 250 ppm. This has no practical implications.

    nunjjaram said:
    External crystal(LFXO) frequency tolerance is +/-500ppm should be enough.

    What do you mean?

    nunjjaram said:
    This confuses me. I think this has a clear reason.

    Yes. The reason is as explained above: the RC oscillator for the nRF52832 was intended to have +/- 250 ppm accuracy, and the original documentation reflects that. Then, because of erratum 146 for nRF52832, this was adjusted to +/- 500 ppm, and the SoftDevice was also updated. And since the nRF52810 is a subset of the nRF52832, the same applies to it, though it looks different in the PS since it was released after the erratum was discovered.

    nunjjaram said:
    I think the specification of frequency tolerance requirement for BLE Stack is wrong.

    Yes, for the LFXO that is the case, unfortunately. But please note that it has no practical implications since it makes little sense to use a crystal that is worse than +/- 250 ppm, as then you could just as well use the internal RC.

    Einar

  • Hi Einar,

    "External crystal(LFXO) frequency tolerance is +/-500ppm should be enough."

    I tried to explain the above content as below.

    1. The RC oscillator(LFRC) frequency tolerance +/- 500 ppm fully support for BLE stack.

    2. If so, the External crystal(LFXO) frequency tolerance +/- 500 ppm can fully support for BLE stack, too. (Not necessarily +/-250 ppm.)

    3. The specification of frequency tolerance requirement(+/-250ppm) for BLE Stack is wrong.

    4. The frequency tolerance requirement for the BLE Stack is +/-500 ppm.(+/-250ppm -> +/-500ppm)

    5. There is no problem with using external crystals(LFXO) with frequency tolerance of +/-500 ppm.

    Your great support has helped me a lot.
    Thank you very much.

    Sungsuk Han.

  • Hi Einar,

    All my questions have been solved.

    Thank you very much for your help for a few days.

    Best Regards,

    Sungsuk Han.

Related