Closed Five-Nines closed 2 years ago
Hi @Five-Nines
Did you try using the public NTP servers, such as in the examples ? If OK, your code / board could be OK, and the issue could be your NTP server (hardware / software, etc).
It's your problem to solve, and I have no interest in dealing with your special use-case, unless you prove this is the bug of this library.
Good Luck,
Referencing NINA_NTPClient_Advanced.ino: The …Time() variables will have values regardless of whether an NTP transaction was properly processed. The delay(1000) “conflicts” with _retryInterval and _updateInterval in that there is an impression that update()/updated() actually performs a new NTP transaction with every loop() – it may or may not occur based on the intervals and flags.
I’ve tried three NTP servers: Pi, SAN NTP, and time.nist.gov. All operate the same: Upon initial sketch operation at boot, if the NTP server is online and returns a valid a NTP response, the sketch sets its variables (updated(), …Time(), etc.) accordingly. Else, updated() =0 and the …Time() variables have their initialization values. If the NTP server goes online, then updated() =1 and the …Time() variables are set accordingly. If, while the sketch is running, the NTP server goes offline, updated() is not flipped to 0, but the …Time() variables continue to update from their previous values.
updated() is dependent on _currentEpoc (and isTimeSet()), which is dependent on _lastUpdate. Update() and forceUpdate() are dependent on the intervals, a timeout, and other flags. The point is updated() will likely be = 0 only at sketch boot. This assumes the purpose of updated() is to reflect an actual successful NTP transaction and all program limitation (intervals, flags) have been met.
Having stated the above, here’s working code for NINA_NTPClient_Advanced.ino.
The above also works in the original library, but # 4 is: this->_currentEpoc = secsSince1900 - SEVENZYYEARS; Serial.println("NTPClient::forceUpdate()"); return true; // return true after successful update
isTimeSet() is only a flag that there is one valid NTP transaction.
Referenced: https://forum.arduino.cc/t/ntpclient-library-how-does-timeclient-update-work/553833 https://github.com/arduino-libraries/NTPClient/issues/57 https://github.com/arduino-libraries/NTPClient/issues/41
Using MKR1010 FW v1.4.8, Windows Arduino IDE v1.8.19, NTPClient_Generic v3.7.5.
Pi is running NTP server and its IP address is hardcoded in the NINA_NTPClient_Advanced.ino sketch.
I’ve left NTP stopped for an hour while the MKR1010 continued run thinking that a buffer might get purged, but there was no change in the results of 1 above. It’s operating as if there is a time server being accessed. The issue could be my Arduino system configuration (libraries)…but I don’t see anything.
NTP started (1 above):
NTP stopped (1 above), no difference other than time:
NTP stopped, then MKR1010 booted (2 above):
NTP started after MKR1010 boot plus ~30 seconds (2 above):