Go Down

Topic: WiFiRTC never enters "NTP unreachable" loop (Read 1 time) previous topic - next topic

MSX_BASIC

Jan 21, 2017, 12:58 pm Last Edit: Jan 21, 2017, 01:09 pm by MSX_BASIC
I've been using the WiFiRTC tutorial from https://www.arduino.cc/en/Tutorial/WiFiRTC and found out that on a network where the NTP server can NOT be reached, the code doesn't enter the "NTP unreachable" loop and keeps trying <WiFi.getTime()>

After some research I found the comparison in the following code isn't evaluated correctly:
Code: [Select]
while ((epoch == 0) || (numberOfTries > maxTries));

To evaluate the comparison correctly, you have to change the code to:
Code: [Select]
while (((epoch > 0) || (numberOfTries > maxTries)) == false);

The maximum number of tries is then 7, one more than maxTries (=6).

Who can change the code posted on the Arduino website?


The issue of not being able to reach NTP server is not clear to me, but I assume this is dependent on the settings of the local Wifi network. On one network NTP server is reachable with my MKR1000, on another it's not.
Learn by doing, with persistence

MSX_BASIC

#1
Jan 21, 2017, 03:07 pm Last Edit: Jan 21, 2017, 11:50 pm by MSX_BASIC Reason: Additional information
I also found out that presumably when port 123 is closed on your local wifi network, the WiFi.getTime() can't reach the NTP server. I still have to test this, by opening port 123.

Edit:
Here's some background info, with link to testing your connection online:
http://support.ntp.org/bin/view/Support/TroubleshootingNTP#Section_9.8.

I still can't reach the NTP server, probably because from this location I'm on a high level security connection with the ISP, which blocks outbound traffic on port 123 (UDP). But I know my MKR1000 works with WiFiRTC on another location, with a different internet connection.
Learn by doing, with persistence

ballscrewbob

Blocked or restricted ports seem to affect a few users in corporate or even educational settings.

Antivirus/Antimalware and third party firewalls are another source of frustration for some users too trying to talk to Arduinos or vice-versa.
It may not be the answer you were looking for but its the one I am giving based on either experience, educated guess, google or the fact that you gave nothing to go with in the first place so I used my wonky crystal ball.

Leone_Euglena

#3
Feb 10, 2018, 01:12 pm Last Edit: Feb 10, 2018, 01:27 pm by Leone_Euglena
hello I just incurred in the same problem, and I think it's because the while condition in the Arduino Tutorial page is not correctly coded for its purpose.

The tutorial on the Arduino page should be updated accordingly (it is not yet after more than 1 year apparently).

in fact because of the OR condition in the tutorial...

Code: [Select]

while ((epoch == 0) || (numberOfTries > maxTries));


...the WHILE loop will cycle indefinitely until either 1 of the 2 conditions is true.
So no surprise if the number of tries will be passed, because if epoch is still 0 because the NTP is not received... the loop will continue! :-)

So, in my opinion the right way to set this condition (and to amend the sketch) is as follow:

Code: [Select]

while ((epoch == 0) && (numberOfTries < maxTries));


This way, if the program don't get epoch value, the loop will actually stop once reached the max allowed number of trials.


And, for consistency, I personally also gave an actual value before the cycle, so eventually the whole loop looks like this:

Code: [Select]

  unsigned long epoch = 0;
  int numberOfTries = 0;
  int maxTries = 3;
    do {
    Serial.print("Attempt getting Server Time: "); Serial.print(numberOfTries+1);
    Serial.print("/"); Serial.println(maxTries);
    epoch = WiFi.getTime();
    numberOfTries++;
    delay(1000); //delay is for reading purpose on serial monitor
  } while ((epoch == 0) && (numberOfTries < maxTries));


Now it works nice. I initially thought of a library incompatibility problem in my sketch.

I've seen around similar buggy-ish code for Azure stuff and so on... but I think they never experienced a server not responding to the NTP request, and so they never experienced the problem.

Go Up