- Tue Feb 12, 2019 10:10 pm
The issue comes when my chip crashes or reboots then the RTC is lost and it has to reconnect to the internet to get the RTC correct, however if I then push the time to the external chip I can then read the chip on reboot vs. connecting back to the internet for an updated RTC but is it worth it?
I have the same issue and I've ended up connecting the wifi and starting sntp to get/set the time whenever I come back from a reset or deep sleep - I've found that I can get the whole process down to a second or less most of the time. I have cached the wifi channel and mac so connecting back to the SSID is fast if nothing has changed, and I also cache the dns entries for the sntp servers and register them as IP addresses so there's as little extra overhead as possible.
It's worth noting that you have two areas in the RTC - the clock and the memory. You lose both if you lose power to the ESP, but you don't lose the memory if you reboot, reset or deep sleep. You will lose the RTC clock if you hard reset or deep sleep, but not if you soft reboot.
Agentsmithers wrote:Anyone know how to set the RTC clock to a specific value.
At this point, I'm not sure what values to expect it.
When the chip first powers on what value should it have? Zero?
You can read and write to the RTC clock via registers, but I don't think I'd recommend it. Have a look in eagle_soc.h for the macros.
All timers including the RTC will be zero when the chip first powers on, or when coming back from deep sleep or a hard reset. The RTC keeps running during a soft reset
Agentsmithers wrote:When I first load do I connect to the internet and pull NTP and ALSO the RTC then go into deep sleep, then wake, check to see if I awake from a deep sleep and if so check the difference between the RTC then and now and add the amount of time to my first obtained NTP value?
If the chip has had a hard reset, a power loss or has come back from deep sleep, then the RTC will be reset and will start at power up so no, each time you wake up the RTC will read about the same value which will be the number of ticks since you woke. The sntp code in the NoNOS SDK looks like it has the ability to set the RTC but I'm not sure it's being used. Also the clocks are used by the chip so changing them is not a good idea - read and save their value in your own register.
Agentsmithers wrote:Is the RTC incrementing in Tickets, It almost seems like its only tracking by the 100th of a second (two dec places)?
HMS.00, I'll need to add the ticks together?
The RTC increments in system ticks - the function system_rtc_clock_cali_proc() returns a temperature corrected count of ticks/us so that you can translate between RTC ticks and the real elapsed time. This value is a 32bit fixed point value so you'll need to do a little bit of math, but it's reasonably accurate over short periods of time if the temperature doesn't change too much.
This is actually a problem with all RTCs - they will lose accuracy with temperature variations, which is why I ended up just using the sntp code for most of my work as it keeps its own internal timer based on the SDK timer routines, which are fed off the system clock and the FRC2 clock.
The system clock is actually a lot more accurate than the RTC, so that's the one I have ended up using to fine tune the sntp time (sntp is only accurate to +/- 1s so for fine timing I do a calibration between sntp and the system clock - this gives about millisecond precision). The RTC starts drifting the moment you deep sleep because the chip cools down
- that's why deep sleep cycles are almost always shorter than the actual interval you request.
There's actually a *really* cool write up about the various clocks inside the NodeMCU code base here:https://github.com/nodemcu/nodemcu-firmware/blob/master/app/include/rtc/rtctime_internal.h