pycom / pycom-micropython-sigfox

A fork of MicroPython with the ESP32 port customized to run on Pycom's IoT multi-network modules.
MIT License
200 stars 166 forks source link

rtc time sync is not properly working with the newest release 1.20.2.r2 #500

Closed gruenwaldi closed 3 years ago

gruenwaldi commented 4 years ago

Please include the following information when submitting a bug report:

I get a succesfull timesync, but then the time is not synced, but time.time() is 30 for example.

NTP_SERVER_DEFAULT = "134.130.4.17" # German ntp server
NTP_SERVER_BACKUP = "193.30.120.245" # another german ntp server
SYNC_INTERVAL_DEFAULT = 60 * 60 * 12 # sec * min. * hours

rtc = machine.RTC()

def enable_time_sync(server=NTP_SERVER_DEFAULT, interval=SYNC_INTERVAL_DEFAULT):
    rtc.ntp_sync(server, interval)

def disable_time_sync():
    rtc.ntp_sync(None)

def wait_for_sync(timeout=60, print_dots=True):
    i = 0
    while not rtc.synced():
        if print_dots: print(".", end="")
        time.sleep(1.0)
        i += 1
        if i > timeout:
            raise Exception("timeout when waiting for time sync")
    return
dessc commented 4 years ago

Confirming that I am also having problems with the time.time() function after upgrading to pycom firmware version 1.20.2.r2 I am using Lopy4 board with time sync over WiFi. Time sync works correctly and the datetime tuple returned from rtc.now() is correct. Subsequent call to time.time() returrns erroneous seconds since Epoch, e.g. 3213659630 (year 2071) or 584485126 (year 1988). After downgraded firmware version to 1.20.2.r1 the returned value from time.time() after time sync is correct.

doniks commented 4 years ago

Could you do me a favor and check your reproduction with the last pygate rc version? It would help narrow down where this was introduced

dl2080 commented 4 years ago

Hi, the bug was introduced in transition from rc10 to rc11: https://github.com/pycom/pycom-micropython-sigfox/issues/478 However, some other user may have had a related bug already in rc7: https://github.com/pycom/pycom-micropython-sigfox/issues/459

didilamken commented 3 years ago

a turnaround is "rtc.init(rtc.now())" at the begining of program. After that time.time() is working

dl2080 commented 3 years ago

Thank you @didilamken, the workaround works for me! Details in https://github.com/pycom/pycom-micropython-sigfox/issues/478

dl2080 commented 3 years ago

Unfortunately, the workaround does only work in this special case. I initialize the clock with an external source as rtc.init((2022, 1, 7, 11, 36, 57, 3, 0)). If I do rtc.init(rtc.now()) before, the rtc.init function does not take any other time value afterwards. This is also a bug in r3. In rc10 it is still working. I will discuss details in https://github.com/pycom/pycom-micropython-sigfox/issues/478

ajoeleht commented 3 years ago

I confirm that rtc.init() is not working on FiPy either since 1.20.2.r2. I use external DS3231 date and time data to init rtc. Works like a charm with r1. With r2 and r3 it might occasionally work on first time after powering up, but defenitely not working after deepsleep (By the way, many sd cards also stop working after deepsleep). rtc.init(rtc.now()) cannot be a solution, because nobody who reads docs cannot figure out this!!

amotl commented 3 years ago

Hi there,

within the release v.1.20.2.r4 (#514), which just happened, the problem described here may have been fixed. See also 120f929b. Thanks, @gijsio and @peter-pycom!

With kind regards, Andreas.

peter-pycom commented 3 years ago

LOL, indeed, @amotl spots it even faster than I'm able to complete the release ;)

All affected, it should be fixed with latest release 1.20.2.r4 - please retest.

dessc commented 3 years ago

I have upgraded my Lopy4 to pycom firmware version 1.20.2.r4. The time.time() function now appears to return correct values after time sync over WiFi.

1.20.2.r1 also worked for me. 1.20.2.r2 did not work. I have not tested 1.20.2.r3.

ajoeleht commented 3 years ago

Indeed, with 1.20.2.r4 the rtc.init() works and time.time() returns correct values.