RTC1 behavior in low power mode

[psavoy]

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.

[Stefan Birnir Sverrisson]

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.

[psavoy]

Thanks Stefan, Yes, the logic doesn't necessarily uses a app_timer, the ticks are extracted out of RTC1 counter and added to my local time. So, even if the app_timer interrupts are delayed the RTC1 counter should reflect that shouldn't they ? i.e. my logic is not say add "60" seconds to my local time every minute started with app_timer called minute_timer, However, whenever requested (by BLE application), convert_to_seconds(RTC1 counter) + "previously set time from phone". This RTC1 counter can go wrong only on reboot, or roll-over, with my logic making sure I don't roll over.

So, there is a high chance that no timers, BLE events, system events are called in my system for huge time (with prescaler set to 0xFFF, roll over happens after 590~ hours). Could this be a concern ?

Unlikely with the crystal accuracy - it is said to be 20ppm.

[psavoy]

Update: 3/12/2015

Stefan, Can you explain this a bit more ? We (I and manjunatha) do that configuration where we have reduced RTC_COMPARE_OFFSET_MIN to 1 since our prescaler was the largest that we could set (0xFFF), would this actually cause the drift ? Can this happen in System ON mode when CPU is not sleeping as well ?

Also, the large prescaler we set was due to the power considerations, setting RTC_COMPARE_OFFSET_MIN to default value and reducing the prescaler to 0x1FFF (15.625) would then affect my power numbers wouldn't they ?

[Stefan Birnir Sverrisson]

I do not realize what tick frequency you actually need, but you should keep the RTC_COMPARE_OFFSET_MIN to 3 in order to ensure normal operation, regardless if you are in low power mode or constant latency mode. Did you try already to set RTC_COMPARE_OFFSET_MIN as 3? Does the problem persist? As I understand your problem, you are missing some RTC interrupts and that is what is expected if you have RTC_COMPARE_OFFSET_MIN as 1.

Changing the prescaler should not have any effect on the power consumption of the device. The RTC consumes ~0.1uA regardless of prescaler settings. It is the actual interrupt frequency that will effect the power consumption as higher interrupt frequency would require higher CPU activity.

[psavoy]

At RTC_COMPARE_OFFSET_MIN = 3, our APP_TIMER_PRESCALER set to 0xFFF, A "tick_timer" is started with 125ms as timeout. In this situation our ticks are delayed and hence the unit is not-operational from a functional perspective (this is solely our product requirement issue...)

Issue: We set RTC_COMPARE_OFFSET_MIN = 1, APP_TIMER_PRESCALER=0XFFF and the tick_timer at 125ms timeout, then we never see any ticks that happen at 125ms getting skipped, However, on entering a product defined low power mode, I perform a sd_power_mode_set(NRF_POWER_MODE_LOWPWR), turn off several other components and wait at sd_app_event_wait() - long hours of wait in this certainly causes the drift.

drift definition: when a current time is requested, we add a phone's set time to rtc1_counter_get() to get the time, this time is different from time on phone. phone sets the time once say on boot.