rtc.ntp_sync

[kjm]

I've got this weird effect on the gpy whereby rtc.ntp_sync('time.google.com') is rock solid on 4G but ratty over wifi with 5-10min chunks of time where it just won't work. I haven't had much experience with rtc syncing, anything that connects to a server without a socket is black magic to me. Given that 4G via the sequans & wifi via my router are more or less equivalent connections reliability wise, can anyone offer a clue as to why the difference?

[kjm]

@jcaron No the rtc.ntp_sync fails to connect to time.google.com a lot on wifi & the default 1970 timestamp is what the rtc defaults to when it's not synced. I have to resync the rtc after each wakeup on the gpy because it doesn't keep time during deepsleep.

[jcaron]

@kjm you get the wrong date, but still get your own request through all the time?

You could check if the time is correct after the ntp_sync call and retry if it’s not the case.

Are you using a local NTP server of a remote one?

If you are sending the data to a server each time you wake up anyway, you possibly don’t even need the NTP sync: just have the server time stamp the data when it receives it (though I guess it depends on your exact application and the accuracy you need).

[kjm]

@jcaron The GPY sleeps for 10 mins then wakes up, trys to set the rtc, reads some sensors & uploads the results to the server over 4G. It all works nicely. But when testing I use wifi for connectivity rather than 4G mainly because I can get a wifi connection to my router quicker than the 4G attach/connect waltz. And, in doing this, I've noticed the rtc often comes up on the default 1970 time.

If you REALLY think it would help I could write some code to graph the RTC failures.

[jcaron]

@kjm Quite a few people seem to have intermittent WiFi connectivity issues, not sure if they are all related.

Could you clarify you scenario? Is your GPy constantly awake or are you using deep sleep? What exactly do you do and how do you know when it's not working (sources + logs and/or graphs would be useful).

Any logs are always appreciated, the more detailed the better.