logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Atmega - Jak sprawdzić poprawność odebranego czasu NTP przed aktualizacją RCT?

Elektronik_Kraków 01 Lip 2016 16:59 2298 7
  • #1 15780376
    Elektronik_Kraków
    Poziom 13  
    Posty: 182
    Ocena: 7
    Witam
    Czy jest możliwość "określenia", czy odebrany czas NTP jest poprawny ? Tak, aby nie dopuścić do aktualizacji zegara RCT błednymi wskazaniami.
  • #2 15780465
    Konto nie istnieje
    Konto nie istnieje  
  • #3 15786234
    Elektronik_Kraków
    Poziom 13  
    Posty: 182
    Ocena: 7
    Witam
    Interesujące rozwiązanie. Nie wiem tylko, czy da się je wykorzystać w przypadku skorzystania z ESP8266 ( zapomniałem wspomnieć ,że z niego korzystam ).

    Wykorzystuje taki kod ( publikował go Kolega Pusiek ), nieco go rozbudowałem o "zabezpieczenie" właściwie sprawdzenie, czy jest internet, gdyż gdy go nie będzie, program się zatrzyma.
    Kod: VB.net
    Zaloguj się, aby zobaczyć kod


    I to działa, tylko nie wiem dlaczego za pierwszym pobraniem czasu NTP są jakieś dziwne wartości.
  • #4 15787137
    krru
    Poziom 33  
    Posty: 1819
    Pomógł: 230
    Ocena: 214
    Ale to chyba nie jest NTP. Ten protokół działa na porcie 123, a w przykładzie masz port 37 (o ile dobrze rozumiem ten kod), czyli tzw "time protocol". W NTP przesyłana jest wartość tzw stratum - liczba określająca jakość czasu (jak daleko od źródła wzorcowego) i wartość 16 oznacza że czas jest niewiarygodny. Do prostych zastosowań można użyć uproszczonej wersji NTP zwanej SNTP (Simple Time Network Protocol) - o ile pamiętam nie jest wtedy liczony czas propagacji ramek po sieci.
  • #5 15788161
    Elektronik_Kraków
    Poziom 13  
    Posty: 182
    Ocena: 7
    No to wygląda, że część stron ma nie poprawny kod, np. na Forum MCS.
    również mają port 37. Przeglądając strony jest tak 50 % dla portu 123 i 50 % dla portu 37
  • #6 15788326
    krru
    Poziom 33  
    Posty: 1819
    Pomógł: 230
    Ocena: 214
    Nie należy ufać ślepo wszystkiemu znalezionemu w internecie (moim postom też).
    W sumie jeśli chodzi tylko o ustawienie czasu to "time protocol" też jest dobry, ale on przesyła pakiet 4-bajtowy, zawierający tylko czas (timestamp) więc nie ma tam informacji na ile ten czas jest dobry. W NTP jest cała sieć serwerów i konkretny serwer zaczyna podawać czas jako dobry dopiero jak zsynchronizuje się z serwerami nadrzędnymi, co trwa czasem nawet kilkanaście minut (zależnie od łącza). Na twoje pytanie odpowiedź brzmi TAK - w NTP jest taka możliwość, natomiast to co używasz to nie jest NTP.
    Jak widać wielu nie rozróżnia "NTP" i "time protocol".
    https://pl.wikipedia.org/wiki/Network_Time_Protocol
    https://en.wikipedia.org/wiki/Time_Protocol
  • #7 15788407
    Konto nie istnieje
    Konto nie istnieje  
  • #8 15790428
    Elektronik_Kraków
    Poziom 13  
    Posty: 182
    Ocena: 7
    Cytat:

    No i trzeba sobie postawic pytanie jak dokladny czas jest potrzebny. W wiekszosci zastosowan nawet ten znieksztacony przez czasy przejscia przez siec jest bardziej niz wystaczajaco dobry.


    Dokładnie tak. Jak dla mnie czas odebrany przez NTP lub time protocol jest wystarczający. Dodatkowo stopień komplikacji w porównaniu z DCF77 jest mniejszy - DCF 77 zajmuje dodatkowo 1 Timer, a pewność, że się odbierze większa ( u mnie DCF77 odbierał tylko po północy ). Można nawet przeboleć to, że za pierwszym razem nie odbiera - przynajmniej u mnie :D .

    Mama jednak problem z wykryciem braku sieci. Bo brak samego internetu można sprawdzić przez Ping.
    Myślałem, że coś takiego:
    Kod: VB.net
    Zaloguj się, aby zobaczyć kod


    czyli najpierw sprawdzam, czy nie ma FAIL, ( nie zalogowano lub brak sygnału WifI ), jeśli nie doczekał się na FAIL, a wyskoczyła flaga od Timer'a to powinien iść dalej i sprawdzić czy OK, tak się nie dzieje

Podsumowanie tematu

✨ W dyskusji poruszono kwestie związane z weryfikacją poprawności odebranego czasu NTP przed aktualizacją zegara RCT. Użytkownicy sugerują, że w przypadku korzystania z Bascom, można użyć wbudowanej funkcji do konwersji danych na zmienną typu Long, a następnie sprawdzić, czy wartość ta jest różna od zera przed aktualizacją czasu. W kontekście użycia ESP8266, podano przykłady kodu, które uwzględniają sprawdzenie połączenia internetowego przed próbą pobrania czasu. Zwrócono uwagę na różnice między protokołami NTP a time protocol, podkreślając, że NTP oferuje lepszą jakość czasu dzięki synchronizacji z serwerami nadrzędnymi. Użytkownicy zauważają, że w większości zastosowań czas z NTP lub time protocol jest wystarczający, a także omawiają problemy z wykrywaniem braku sieci.
Wygenerowane przez model językowy.
REKLAMA