You can chat about native SDK questions and issues here.

User avatar
By Agentsmithers
#80541 https://datasheets.maximintegrated.com/en/ds/DS1302.pdf

So, One of the issues I am trying to tackle is a problem with Battery Usage. I have a thought about maybe pairing up the ESP8266 with this chip and have it hold the RTC but the ESP even in deepsleep only takes 20UA where the DS1302 takes just under 1.2UA, 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?

Did anyone generate code to talk to the DS1302 at all yet?

Okay different topic, relevant but different.
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?

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?

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?

Thank you!
User avatar
By davydnorris
#80547
Agentsmithers wrote:...

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?

Thank you!


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
User avatar
By Agentsmithers
#80557
davydnorris wrote:
Agentsmithers wrote:...

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?

Thank you!


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


davydnorris, Thank you for the highly educated response sir. Very helpful, ALL of it..
User avatar
By eriksl
#80952 The DS1302 has a weird proprietary protocol to communicate with. I would suggest searching for an alternative RTC that has I2C or SMB (which is mostly the same) access. There are various (varying in quality) I2C implementations available for the ESP8266 and it's industry standard.