Page 2 of 3
Re: Why does get_rtc_time_us() truncate the result to uint32_t?
Posted: Sat May 20, 2017 4:32 pm
by WiFive
Maybe wakeup, read old cal value, do new cal, set rtc counter to
rtc_counter = ((rtc_counter_before_sleep * old_cal) + (sleep_count * (old_cal +new_cal)/2)) / new_cal
??
If we are worried about drift shouldn't we recal more often (not just at boot) and continue to rebase rtc_counter on latest cal value?
Re: Why does get_rtc_time_us() truncate the result to uint32_t?
Posted: Sat May 20, 2017 9:51 pm
by ESP_igrr
I was thinking along the similar lines, the only remaining question is how to do this without introducing RTC_DATA variables. Currently if the application doesn't use RTC_DATA, we can power it down.
Another option is to store these values in RTC_FAST_MEM, if it is kept enabled.
Probably will go for "rebasing" of the counter value after wakeup, assuming that calibration value was constant in deep sleep, and storing the calibration value in one of the remaining RTC__CNTL_STORE registers.
Re: Why does get_rtc_time_us() truncate the result to uint32_t?
Posted: Sat May 20, 2017 11:05 pm
by WiFive
Sounds good. So is it more accurate to take the constant new cal value on wake rather than some average since the die temp is going to be the major factor and is more representative of the die temp during deepsleep (assuming no large changes in ambient)? Should we do periodic cal as the die temp changes during runtime since temp at boot is not representative of temp at steady state full power?
Re: Why does get_rtc_time_us() truncate the result to uint32_t?
Posted: Sun May 21, 2017 2:28 am
by ESP_igrr
Re. doing calibration at runtime — this can be exposed as a API to applications, so that they can do it once in a while if needed. Or just use 32k xtal if time precision matters.
Re: Why does get_rtc_time_us() truncate the result to uint32_t?
Posted: Sun May 21, 2017 12:37 pm
by WiFive
Got it. Will it be possible to call from a wake stub?
Now if we are using FRC1 for timekeeping during runtime we probably don't need to be doing calibrations but should we sync RTC counter to FRC1 before deepsleep?
Re: Why does get_rtc_time_us() truncate the result to uint32_t?
Posted: Sun May 21, 2017 11:07 pm
by WiFive
RTC seems to gain 0.8-1.1sec/min on FRC1 in normal runtime mode.
Re: Why does get_rtc_time_us() truncate the result to uint32_t?
Posted: Mon May 22, 2017 1:11 am
by ESP_igrr
Calibration might still be messed up? Okay, will debug that as well.
Re: Why does get_rtc_time_us() truncate the result to uint32_t?
Posted: Mon May 22, 2017 3:28 am
by WiFive
Also s_microseconds rolls over at 32-bit.
Code: Select all
RTC Time: 4330469173
FRC1 Time: 4260909211
RTC Time: 4391418173
FRC1 Time: 25941852
Re: Why does get_rtc_time_us() truncate the result to uint32_t?
Posted: Mon May 22, 2017 7:12 am
by ESP_igrr
I'm not getting the 1sec/min difference here, but will try a bunch of other boards, might be chip dependent?
- timelog.png (57.61 KiB) Viewed 11187 times
Re: Why does get_rtc_time_us() truncate the result to uint32_t?
Posted: Mon May 22, 2017 9:36 am
by ESP_igrr
Also s_microseconds rolls over at 32-bit.
Can't reproduce this here, can you hint at how you got these results?
Attached are graphs of RTC/FRC timers offset w.r.t. the timer on a PC.
RTC time was obtained from
system_get_rtc_time, FRC time — from
get_time_since_boot
- timelog_rtc_frc.png (63.13 KiB) Viewed 11184 times
- timelog_frc.png (86.08 KiB) Viewed 11184 times