Why is system time sometimes not NTP synchronised after a reset?

Question

I’ve been working with the 2.9″ ESPaper Plus Kit and have noticed an odd issue. It appears on the weather station, intermittently (aren’t those the best!), as an incorrect update time. I investigated further by adding the date to the display. I now know that the faulty time, and date, is a few seconds after the start of the Unix time epoch (i.e. near zero). I investigated further by using the example from the simpleDSTadjust library by neptune2. That also shows the same issue intermittently after resets. So, I dug deeper, through the simpleDSTadjust shell around the standard time functions. The problem still occurs after resets. I found this (https://github.com/esp8266/Arduino/issues/4749) and although it seems to be related, it does not really cover the problem which occur after resets.

My skinny code example now looks like this:

#include <ESP8266WiFi.h>
#include <time.h>

time_t tnow;
const char* ssid = "ssid";
const char* password = "password";

// Maximum of 3 servers
#define NTP_SERVERS "us.pool.ntp.org", "pool.ntp.org", "time.nist.gov"

void setup() {
  Serial.begin(115200);
  Serial.setDebugOutput(false);

  Serial.print("\nConnecting to WiFi ");
  WiFi.mode(WIFI_STA);
  WiFi.begin(ssid, password);

  while (WiFi.status() != WL_CONNECTED) {
    Serial.print(".");
    delay(1000);
  }

  Serial.println(" Done");

//delay(10000);  // This delay actually makes the problem worse

  updateNTP();
  tnow = time(nullptr);
  Serial.print(String(ctime(&tnow)));

  ESP.deepSleep(5 * 1000000);

}

void loop() {}

void updateNTP() {
  configTime(0, 0, NTP_SERVERS);
  delay(500);

  while (!time(nullptr)) {
    Serial.print("#");
    delay(1000);
  }

}

This code, on startup, does the expected time sync, reports the result, then goes back to sleep for 5 seconds. A sample of its output was as follows, edited to remove the start-up “noise” and to highlight the faulty timestamps:

Connecting to WiFi ..... Done
Thu Jan  1 08:00:05 1970
Connecting to WiFi .. Done
Mon Mar 25 15:33:50 2019
Connecting to WiFi .. Done
Mon Mar 25 15:33:58 2019
Connecting to WiFi .... Done
Mon Mar 25 15:34:08 2019
Connecting to WiFi .. Done
Thu Jan  1 08:00:02 1970
Connecting to WiFi ..... Done
Thu Jan  1 08:00:05 1970
Connecting to WiFi .. Done
Thu Jan  1 08:00:02 1970
Connecting to WiFi ..... Done
Mon Mar 25 15:34:44 2019
Connecting to WiFi .. Done
Thu Jan  1 08:00:02 1970
Connecting to WiFi .. Done
Mon Mar 25 15:34:59 2019
Connecting to WiFi ....... Done
Thu Jan  1 08:00:07 1970

I am begining to think that the call to configTime(0, 0, NTP_SERVERS)is taking a long time to have an effect: many seconds.

I would be very grateful if a reliable solution could be found to this issue. I believe it is one that affects any "sleepy" applications for which the real time is important, not just the weather station. Thanks.

Answer 1

Fetching time information via NTP is a requirement we have with many of our applications. We keep learning about new behavior with every iteration of the underlying SDK and Arduino platform. We then adjust our own implementation to cope with that. For some of our applications we already implemented two important improvements:

• loop until fetched time is greater than some recent reference value
• break the loop with a retry counter after a certain time has passed and re-issue an NTP request

Both of those improvements have not yet been applied to the ESPaper Weather Station (fat client). Please take a look at how our ESPaper Client app handles this.

https://github.com/ThingPulse/espaper-client/blob/master/EspaperClient/EspaperClient.ino#L98

I'm quite convinced applying these two changes will fix your problem.

Comments

I have implemented these changes to my copy of the weather station and to my minimal test sketch. I have to say that the overall performance is much improved.
An underlying issue remains in that NTP sync can still take an age. However, with the suggested changes, my sketches are now in a good position to handle a failure (i.e. when initTime() returns false). I am now able to decide what to do when the time cannot be relied on, which is great when there may be other important operations that must be completed. And, of course, all may be working well at the next opportunity.
Thank you.

---

And now it's passed the first biannual test. It accurately made the transition from GMT to BST. Thanks again.