• State Verified Answer
  • Replies 8 replies
  • Subscribers 63 subscribers
  • Views 1532 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 226139
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

SDK15.2: impact of NRF_SDH_CLOCK_LF_RC_* setup on performance

rgrr2

Hello

I'm currently struggling with the LF_RC setup in sdk_config.h.

Calibration of the internal LF clock can be parameterized thru NRF_SDH_CLOCK_LF_RC_CTIV and NRF_SDH_CLOCK_LF_RC_TEMP_CTIV.

Does anybody has already done measurements about current vs. parameters?  Nordic?  Also: is there any other impact due to these parameters (throughput etc)?

Regards

Hardy

  • 0

    The softdevice is probably intelligent enough to do the calibration while the HFXO is running anyway for radio operation, so the additional current could be rather hard to measure in most cases.

    But the *running* current of the LFRC is actually higher than the running current when using LFXO - that would make a difference. Bottom line: If your application requires low idle/standby current, use the LFXO with a crystal.

  • 0 in reply to Turbo J

    No, the additional current is actually not hard to measure.  It is in the range of 20-30uA according to my measurements.  And I doubt, that I'm getting all calibration effects while in developer environment.  Also I've read somewhere that the softdevice is doing (additional?) calibration if there are packet losses.  Perhaps I'm lucky with my nRF52 and this part has an almost ideal LFRC oscillator!?

    Also, if the Softdevice would be intelligent enough, then why there are these parameters?

    So because there is the possibility to set parameters, I guess that there are somehow impacts/drawbacks on performance.

    And that's what I would like to understand.

    BTW: we have parts which require NRF_SDH_CLOCK_LF_RC_CTIV in the range of 2 to allow a permanent BLE connection.  External crystal is unfortunately no option, because it is a cost sensitive application.

  • 0 in reply to rgrr2

    I can not think of anything else than increased current consumption that will be impacted by these parameters. I don't think the calibration will decrease the throughput or halt the application.

    Best regards,

    Simon

  • 0 in reply to Simon

    Ok, thanks.  Under the topic "halt the application", there is the final answer from Jørgen Holmefjord stating that the calibration task is run inside the clock peripheral, and does not halt the application.

    Is there any more information about this calibration timer? Esp concerning current consumption, duration etc.

  • 0 in reply to rgrr2

    There are some information about it in the nRF52832 Product Specification (you can find it at DocLib) under CLOCK, but I was not able to find anything related to current consumption.

    The expert on current consumption will get back to the office at monday, and I will ask him then.

    Best regards,

    Simon

Related