Surprised by RTC value at ESP8266 boot/reset?

[Jibun-no-Kage]

Since I almost always do a time sync (via ntptime or home rolled NTP query) right after WiFi connect, I was surprised that the RTC seems to magically have the correct time after a machine.reset and connect to WiFi when the script I am testing IS NOT setting the RTC. Ghost in the machine? I looked up the documentation on the machine.RTC and I did to any reference to the RTC getting set per se at boot. So is the network.WLAN doing a stealth time sync? Moreover I though machine.reset() clears RTC memory, no? I even pulled the power, and when I reconnected to WiFi, RTC spooky time set?

See in bold below...
Run! Alive
WiFi! Network
WiFi! Worstation
WiFi! Link True
WiFi! Connect? False
WiFi! Connect? False, Status 1, Time Out 30
WiFi! Connect True
WiFi! Alive
WiFi! Media
WiFi! Name 'esp8ff589'
MQTT! Connect
MQTT! Ping Alive
MQTT! Listen Active
MQTT! Publish 'status/esp8ff589/acknowledge', PayLoad '{"payload": true}'
Main! Alive
Schedule! Task 0x3fff0f30, Interval 5
Schedule! Task 0x3fff0b50, Interval 0.1
MQTT! Ping '715206401'
MQTT! Publish 'status/esp8ff589/ping', PayLoad '{"payload": 715206401}'
MQTT! Ping '715206406'
MQTT! Publish 'status/esp8ff589/ping', PayLoad '{"payload": 715206406}'
Run! Interrupt
Main! Not Alive
MQTT! Publish 'status/esp8ff589/acknowledge', PayLoad '{"payload": false}'
MQTT! Disconnect
Run! Not Alive

[jimmo]

Are you using Thonny or rshell?

[Jibun-no-Kage]

Thonny at the moment.

[robert-hh]

Thonny sets the time.

[Jibun-no-Kage]

Ah... well... that is just annoying. LOL.

[Lobo-T]

You can disable it:

[Lobo-T]

You should probably also be aware that th ESP8266' RTC is pretty bad. I haven't tried it myself, but I remember reading a discussion about it.
The ESP32 without external 32kHz crystal is also pretty bad. Like 10 minutes wrong per day. But the ESP32, unlike the ESP8266 can take an external 32kHz crystal, and then it's very good.

[Jibun-no-Kage]

Yes, I am very familiar with how RTCs can be off the mark. Even on some high end servers across the various enterprise environments I have engineered and supported over the years, we had to do massive synchronization 'waves', it was not uncommon to have servers that had to be synchronized every 4 to 6 hours. Microsoft Active Directory domains and kerberos based environments have little tolerance for clock deltas.

On ESP8266 my base scripting logic always synchronizes the RTC at boot/reset and then every 4 hours, typically. For when I do sensor data capture that needs time indexing, I capture the clock drift as well, easy to do, since I have the device report the time and I capture the time when the database record is created. This is not completely legit because it ignores the data transmission time cost, and other overhead time lag, but for my needs it will capture any gross delta.

I also use a visual indicator, every 5 minutes I flash/blink a GPIO driven LED (not the on-board) 5 times, with a 1 second interval, this is aligned with 0 seconds for the given minute at execution. So when I walk pass a group of devices, installed or on a test bed, where I see the flashing poorly synchronized, I know the which devices likely have a higher drift issue. I developed this approach because even across Raspberry Pi devices I saw some odd RTC drifting at times.

[Maumtrasna]

One weird phenomenon explained, it bugged me as well. Another thing I have been wondering is that my ESP8266 seems to connect to Wi-Fi automatically and get a working IP from my DHCP service. Any idea why this happens?

MicroPython v1.19.1 on 2022-06-18; ESP module with ESP8266
Type "help()" for more information.
>>> import network
>>> wlan=network.WLAN(network.STA_IF)
>>> wlan.active()
True
>>> wlan.ifconfig()
('192.168.0.112', '255.255.255.0', '192.168.0.1', '8.8.8.8')
>>> import uping
>>> uping.ping("google.com")
PING google.com (216.58.210.142): 64 data bytes
84 bytes from 216.58.210.142: icmp_seq=1, ttl=59, time=14.669999 ms
84 bytes from 216.58.210.142: icmp_seq=2, ttl=59, time=19.255997 ms
84 bytes from 216.58.210.142: icmp_seq=3, ttl=59, time=17.851997 ms
84 bytes from 216.58.210.142: icmp_seq=4, ttl=59, time=15.104001 ms
4 packets transmitted, 4 packets received
(4, 4)

I have yet found no way how to use this live connection in my application, though. I can see that Wi-Fi is on and get the values from ifconfig() but it is not usable and I cannot "reconnect" using the correct credentials. Using simple scripts works fine but inside a class init() function nothing works, for instance.

[Maumtrasna]

Yes, as I wrote, that became perfectly clear before my "next question". What I wondered above was where the automatic Wi-Fi connection comes from. I have a fresh MicroPython installation and my boot.py contains this:

import uos,machine
import gc

I do not have anything else. No main.py, just the boot.py and, lo and behold, I am in the wireless LAN with IP and route as you can see from the test. Is this an ESP8266 automation or a MicroPython one, possibly?

[robert-hh]

It is an ESP8266 thing. The ESP8266 RTOS remembers the previous WiFi connection and reconnects on power-on.

[Maumtrasna]

Thanks, that explains a lot. That ESP-12 used to be a while in detector testing (C++), and it seems to me that the IP setting has been the same ever since those days (months ago). IP 192.168.0.112 was in a "manual testing IP range" earlier this year, before my new range modifications. The IP overlaps my current general DHCP range, the IoT range now starting from 192.168.0.160.

I wonder how I can reset the bloody thing. It does not seem too easy and may not be doable from MicroPython. Well, maybe using this variant of the Russian roulette.

Anyhow, thanks for putting the ball rolling, Robert!

[robert-hh]

You can always run a full erase of the flash. But setting the IP to a different value with ifconfig() may works a well.

[Maumtrasna]

Funny, but esptool does not do full erase and the IP still sits there. Erasing flash block 0x7E (as proposed by somebody) only rendered the firmware useless. Dumping that block revealed that the AP/Password is definitely not there. After ifconfig() the IP was correct, of course, but after the next restart we were back in square one again. Well, this problem will not stop me, anyhow, now that I know where it originates from.

Thanks