Core 2.x vs. 3.x vraagje ntp probleem

[rene7777 Profiel PrivéberichtWebsite]

Hallo,

ik wou ff jullie mening horen.

ben ik nou de enige die vervelende issues tegen qua werking (of mss zelfs compilatie fouten) als je naar een hogere core gaat bv. van 2.x naar 3.x voor de esp8266 bordjes.

nu heb ik meerdere computers en nu ben ik bezig met een zij-projectje en daarvoor gebruik ik nu core 3.0.2.
De reden was omdat deze core ethernet kabel ondersteund en een recentere en interne ntp functie (easyntp).

Nu werkt dat allemaal maar mijn hoofd-projectje (wifi * core 2.5.0)) waarvan dit zij-projectje afgeleid is had nooit problemen.

Het probleem is dat met die nieuwe core alles wel werkt maar ieder uur wordt tijd op gevraagd met ntp functies.

ik kan zowel de oude externe core gebruiken wat ik ook bij 2.5.0 gebruik, maar heel af en toe krijg ik een verkeerde tijd (1 uur vroeger).
maar dat effect heb ik alleen gezien als ik compileer onder core 3.0.2.

Als ik de nieuwe functie gebruik (#include <EasyNTPClient.h>) krijg ik heel af en toe dat de tijd wordt ingesteld in het jaar 2036.
Ik las op internet dat dit een bug is en iets te maken had met 32-bit en 64-bit variabelen.

Nu merk ik ook dat nieuwe cores steeds strenger zijn met codering en problemen ondervinden met oude (niet bijgewerkte) bibliotheken.

Ik moet eens kijken waar die interne bibliotheek zich bevind, maar je zou toch zeggen dat het goed getest is.

Ik heb hieronder de code gezet van de oudere functie die ik nog zonder problemen gebruik in mijn hoofdprojectje met core 2.0.5.

ik las op internet dat het mss beter is om long long (2x dus) te gebruiken i.p.v. 1x long.

=====================================================
p.s. ik heb nu

time_t t = ntpClient.getUnixTime())

i.p.v.

long t = ntpClient.getUnixTime())

met nieuwe functie gedaan ..... ben nu ff langdurig aan het testen ........

==========================================================
Oude functie: oude 2.5.0. core nooit problemen ::: Core 3.0.2. valt die af en toe uur terug=????

Code: Alles selecteren


unsigned long ntpSync()
{
  //get a random server from the pool
  //////////////////////////WiFi.hostByName(ntpServerName, timeServerIP);
  dns_gethostbyname(ntpServerName, timeServerIP, NULL, NULL);

  sendNTPpacket(timeServerIP); // send an NTP packet to a time server
  // wait to see if a reply is available
  delay(1000);
 
  int cb = udp.parsePacket();
  if (cb) {
    //Serial.print("packet received, length=");
    //Serial.println(cb);
    // We've received a packet, read the data from it
    udp.read(packetBuffer, NTP_PACKET_SIZE); // read the packet into the buffer

    //the timestamp starts at byte 40 of the received packet and is four bytes,
    // or two words, long. First, esxtract the two words:
    unsigned long highWord = word(packetBuffer[40], packetBuffer[41]);
    unsigned long lowWord = word(packetBuffer[42], packetBuffer[43]);
    // combine the four bytes (two words) into a long integer
    // this is NTP time (seconds since Jan 1 1900):
    unsigned long secsSince1900 = highWord << 16 | lowWord;
    //Serial.print("Seconds since Jan 1 1900 = " );
    //Serial.println(secsSince1900);

    // now convert NTP time into everyday time:
    //Serial.print("Unix time = ");
    // Unix time starts on Jan 1 1970. In seconds, that's 2208988800:
    const unsigned long seventyYears = 2208988800UL;
    // subtract seventy years:
    unsigned long epoch = secsSince1900 - seventyYears;
    // print Unix time:
    //Serial.println(epoch);
    return epoch;
    } else {
    //Serial.println("no packet yet");
    return false;
  }
}


// send an NTP request to the time server at the given address
void sendNTPpacket(IPAddress& address)
{
  //Serial.println("sending NTP packet...");
  // set all bytes in the buffer to 0
  memset(packetBuffer, 0, NTP_PACKET_SIZE);
  // Initialize values needed to form NTP request
  // (see URL above for details on the packets)
  packetBuffer[0] = 0b11100011;   // LI, Version, Mode
  packetBuffer[1] = 0;     // Stratum, or type of clock
  packetBuffer[2] = 6;     // Polling Interval
  packetBuffer[3] = 0xEC;  // Peer Clock Precision
  // 8 bytes of zero for Root Delay & Root Dispersion
  packetBuffer[12]  = 49;
  packetBuffer[13]  = 0x4E;
  packetBuffer[14]  = 49;
  packetBuffer[15]  = 52;

  // all NTP fields have been given values, now
  // you can send a packet requesting a timestamp:
  udp.beginPacket(address, 123); //NTP requests are to port 123
  udp.write(packetBuffer, NTP_PACKET_SIZE);
  udp.endPacket();
  }


[rene7777 Profiel PrivéberichtWebsite]

nou, nou

wat een berichten zeg ......

ik ben inmiddels er achter gekomen dat het wellicht een flush probleem is met de udp buffer.

het lijkt er op dat wifi.udp niet hetzelfde is als ethernet.udp

heb na de parsing commando udp.flush geprobeerd maar dat schijnt niet te werken via de ethernet methode

maar ja .... tegen wie heb ik het eigenlijk???

oh ja het 2036 probleem van de internet core 3 functie is vermoedelijk een slechte receive van de ntp server (0), in Februari 2036 begint de rollover ..... (32 bit aantal seconden na 1900 is 136 jaar ..... dat wordt dan spannend)