RTC in combinattion with deepsleep unusable

[PeterB]

When using the Pysense and its library for sleep the RTC is useless as at every wake from sleep it is reset to 1970, also wehn every time setting it to the 32 kHz crystal as source. The ESP32 documentation shows it will keep the RTC alive when in deepsleep mode. That means the Pycom code or its libraries are doing somthing wrong with the RTC when putting the thing in to sleep or wehn it gets out of sleep.

Using the sleep time remaining is also useless as it is inaccurate, the bigger the number the larger the error, already visible at values of 120 seconds, but very clear at large values of e.g. 32000, then 10 seconds cound as someting like 500 seconds.

So for a RTC there seems no other solution than adding an external RTC. Really wasting resources as the ESP32 has it inside.

[jcaron]

@peterb I think you missed something...

There are two different ways to achieve deep sleep:

• machine.deepsleep uses the internal ESP32 deep sleep mode. That one will keep the RTC alive.
• Pysense-controlled deep sleep (using the setup_sleep / go_to_sleep from the Pysense library) just completely switches off the ESP32, including the RTC (it really cuts all power to the ESP32).

Depending on your exact use case (the module you use, the wake-up sources...), one or the other may be more appropriate.

@Paul-Thornton This is a recurring question/issue which results in a lot of confusion and frustration. I think the different (deep) sleep modes should be all explained and compared in a single page in the docs, and all pages that talk about sleep modes should reference that page.

[kjm]

I'm using machine.deepsleep on a GPY & my rtc wakes up at 1970 too!

[andreas]

Dear @kjm,

we can confirm the clock of the RTC works as intended after invoking machine.deepsleep() using the most recent firmware on a FiPy device. See also [1].

With kind regards,
Andreas.

[1] https://community.hiveeyes.org/t/strom-sparen-beim-einsatz-der-micropython-firmware-im-batteriebetrieb/2055/159