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

RTC1 behavior in low power mode

I intend to keep a long running clock in the system and use the app_timers(hence RTC1) in a soft device enabled nrf51822 firmware. I basically have a minute tick and update local time every minute, However, I've observed that once I call the sd_power_mode_set(NRF_POWER_MODE_LOWPWR), I see the RTC not being updated regularly and begin to see a drift in the local clock because of this. The code would then mainly be at WFE() - is this correct ? Is this a possibility, what is the accuracy of RTC1 when in low power mode? I am using a 32Khz NRF_CLOCK_LFCLKSRC_XTAL_20_PPM and internal RTC1 via app_timer approach to keep track of time.

Parents
  • Hi

    The accuracy of the RTC and app timer should be identical, regardless if you are in low power mode or constant latency mode. If you have a <=20ppm crystal and choose the 20ppm as you have done, the accuracy should be 20ppm for the app timer. In my mind I can think of two possible resons for this:

    • You are using a softdevice, which potentially delays the execution of app_timer interrupt handler. The softdevice can block the CPU for up to 6ms during a radio event. This should however not cause any drift, just that handling of individual app_timer interrupts are delayed.
    • The accuracy of your crystal is larger than 20ppm. If the crystal accuracy is larger than the accuracy chosen in the application, it could lead to occasional BLE packets are lost that the central sends to the peripheral

    Could one of those two be true in your case?

    Update 12.3.2015 Thanks for the update. I think I realize better what the problem is now. I suspect it is the same problem as described on this thread.

Reply
  • Hi

    The accuracy of the RTC and app timer should be identical, regardless if you are in low power mode or constant latency mode. If you have a <=20ppm crystal and choose the 20ppm as you have done, the accuracy should be 20ppm for the app timer. In my mind I can think of two possible resons for this:

    • You are using a softdevice, which potentially delays the execution of app_timer interrupt handler. The softdevice can block the CPU for up to 6ms during a radio event. This should however not cause any drift, just that handling of individual app_timer interrupts are delayed.
    • The accuracy of your crystal is larger than 20ppm. If the crystal accuracy is larger than the accuracy chosen in the application, it could lead to occasional BLE packets are lost that the central sends to the peripheral

    Could one of those two be true in your case?

    Update 12.3.2015 Thanks for the update. I think I realize better what the problem is now. I suspect it is the same problem as described on this thread.

Children
No Data
Related