WiFi clock "Leon" by vayo

Ostatnio sporo osób prezentuje swoje konstrukcje zegarów, więc i ja postanowiłem pokazać zegar jaki zrobiłem na prośbę kolegi. Ogólnie założenie było takie, by zegar był widoczny w nocy z większej odległości. Kolega zaproponował aby zrobić go na około 10cm wyświetlaczach LED. Wydało mi się to zbyt banalne i postanowiłem zrobić to na matrycach LED 8x8. Testowo zastosowałem trzy gotowe moduły (z Chin) zawierające po cztery matryce 8x8. Dało to wyświetlacz o rozdzielczości 16x48 pixeli. Z racji tego, że sterowanie wyświetlaczami odbywa się za pomocą układów MAX7219 ogranicza to sterowanie jasnością do zdefiniowanych 16 poziomów. Ustawiając najniższy poziom zegar w nocy emitował tyle światła, że spokojnie mógł zastąpić nocną lampkę. Postanowiłem więc zrobić go na jednym gotowym module z czterema wyświetlaczami co dało rozdzielczość 8x32 pixeli. Wyświetlacz wydał mi się trochę za gruby, bo matrtyce LED umieszczone są w nim w gniazdach. Postanowiłem wylutować gniazda i wlutować wyświetlacze prosto w PCB. Próbowałem różnych technik, ale niestety zawsze uszkodziłem jakiś pad -wysunąłem z niego metalizację i płytka nadawała się już do śmieci. Gdy uszkodziłem piątą płytkę wiedziałem już, że będę musiał zaprojektować i zamówić takie PCB, aby móc w nie bezpośrednio wlutować wyświetlacze. Zaprojektowałem PCB kompatybilne z oryginałem, jedyne co zmieniłem, to wielkość rezystorów i kondensatorów SMD, bo w moich zasobach są tylko elementy w rozmiarze 1206.
Aby nie bawić się w ustawianie zegara przyciskami postanowiłem zastosować w nim moduł WiFi (z ESP8266). W pierwszej wersji wgrałem do niego oprogramowanie z możliwością odczytu czasu z NTP za pomocą komend AT. Z racji iż oprogramowanie nie pozwalało na zmianę serwera NTP szybko z niego zrezygnowałem i wróciłem do oryginału. Odczyt czasu odbywa się teraz z dowolnego serwera NTP poprzez wysłanie do niego odpowiednio spreparowanego pakietu danych po UDP. Konfigurację zegara (SSID, hasło, serwer NTP, strefę czasową i czas letni) chciałem ustawiać z poziomu przeglądarki po podłączeniu się do modułu ESP pracującego w trybie AP, ale zrezygnowałem z tego z powodu braku czasu na naukę programowania tego modułu. Zastąpiłem to odczytem konfiguracji z pliku z karty SD. W przyszłości może jeszcze to przerobię. Baterię dołożyłem na samym końcu, gdy już PCB było prawie gotowe. Zrobiłem to, by po zaniku zasilania mieć czas mimo braku Internetu.
Moduł RTC (DS3231) posiada wbudowany termometr, ale i tak postanowiłem zastosować nieśmiertelny DS18B20 (w obudowie SO8), by uzyskać lepszą dokładność (dziesiętne stopnia). Z modułów ESP wylutowałem LED sygnalizujące zasilanie, by niepotrzebnie nie dawało poświaty z tyłu zegara. Oczywiście nie ustrzegłem się poważnego błędu, co da się zauważyć na zdjęciach. PCB zawsze projektuję w Protel/Altium i od zawsze korzystam tylko z własnych bibliotek elementów, ale taki błąd zdarzył mi się po raz pierwszy W module ESP zamieniłem strony i aby nie zamawiać nowych PCB postanowiłem wlutować je odwrotnie. Nawet źle to nie wygląda. Kolejnym błędem, było umieszczenie za bezpiecznikiem polimerowym dławika o tak małym rozmiarze. Chińczyk pisał, że są one do 0.7A, a co się okazało do 0.07A. Zegar przy włączonym module WiFi i najwyższej jasności pobiera około 0.35A. Poszukiwanie dławika >0.35A w takim małym rozmiarze spełzło na niczym, więc lutując zastąpiłem go zworą SMD w rozmiarze 1206. Do programowania uC zastosowałem gniazdo w rastrze 1.27mm i dodatkowo wyprowadziłem na nim linię UART (połączenie uC z ESP). Uruchamiając zegar z wciśniętym przyciskiem ESP przechodzi w tryb upgrade i za pomocą tego gniazda możemy zaktualizować mu firmware. Uruchamiając zegar normalnie w pierwszej kolejności czytana jest konfiguracja z karty SD (o ile jest w slocie). Dane z karty porównywane są z danymi zapisanymi w EEPROMie. Gdy są różne, to następuje ich nadpisanie w EEPROMie. Hasło do WiFi zapisane na karcie SD dla bezpieczeństwa po odczytaniu jest zastępowane gwiazdkami. Gdy przy ponownym odczycie zegar odczyta gwiazdki, to oczywiście nie zastąpi nimi poprawnego hasła zapisanego już w EEPROMie. Napis "vayo" na pierwszej matrycy ma jasność najniższą -"0", na drugiej "5", na trzeciej "10" i na czwartej najwyższą "15". Podczas tego napisu następuje połączenie z siecią WiFi, odczyt czasu i wyłączenie WiFi. Kolejny etap uruchamiania, to wyświetlenie intro (czcionka 8x8 ze zbiorów z małego Atari) i na koniec przejście do trybu wyświetlania czasu. Sam pomysł na ruszające kropki i przewijające się cyfry zaczerpnąłem z filmiku na YouTube gdzie jakiś Rosjanin chwalił się swoim zegarem na wyświetlaczu opartym tak samo o układy MAX7219. To jedyne na czym sie wzorowałem -cała reszta jest całkowicie mojego autorstwa. Zegar konstruowałem tak, by nie musieć tworzyć dla niego obudowy. Jako stopki pod wyświetlaczami zastosowałem silikonowe odbojniki do drzwi szafek i na taką wysokość (1.5mm) projektowałem nogi w PCB z "sercem" zegara. Gniazdo zasilania umieściłem w otworze, by wtyczka nie wystawała poza obrys wyświetlacza. Umożliwia to też skierowanie kabla zasilającego w dowolnym kierunku. Fotorezystor również umieszczony jest tak, by nie wystawał poza obrys. Jest to mój pierwszy tak banalny projekt -niczego nowego mnie nie nauczył (no może poza większym przyłożeniem się do rysowania footprint’ów elementów), ale zainteresowanie nim było spore. Do tej pory zrobiłem już 8 sztuk i to na pewno nie będzie koniec.

Jeżeli powstanie kolejna wersja firmware, to dorobię do niej odczyt komunikatów z serwera WWW, tak by można było przekazywać jakieś informację do konkretnego zegara (np. składać za pośrednictwem zegara życzenia urodzinowe, lub wyświetlać zewnętrzną temperaturę z danej miejscowości) i dorobię automatyczną zmianę czasu w standardzie US, bo teraz można włączyć tylko naszą.
Gerberów na razie nie poprawiałem. Jak zużyję wszystkie PCB i będę zmuszony zamówić nowe, to wtedy poprawię i zamieszczę je tutaj.

A co wy sądzicie o moim projekcie?


Link

Bardzo estetycznie wykonane. Świetny pomysł z wcięciem w PCB na przewód USB. Można dać jakiś filtr na matryce, żeby zwiększyć czytelność - np przykleić ciemną folię do przyciemniania szyb.

Świetne wykonanie, gdyby miał jeszcze bateryjne zasilanie całej matrycy to już w ogóle

patyk_piotr wrote:

Świetne wykonanie, gdyby miał jeszcze bateryjne zasilanie całej matrycy to już w ogóle

Zastanawiałeś się nad tym jaką musiałaby mieć pojemność, by przetrwać chociaż 24h?

Rozumiem, że MAXy są też od chińczyków? Jak się zachowują te ich podróbki? Nie grzeją się?

dambusio wrote:

Można dać jakiś filtr na matryce, żeby zwiększyć czytelność - np przykleić ciemną folię do przyciemniania szyb.

Naklejona jest folia do matowienia szyb, ale praktycznie nic nie wniosła. Myślałem o takiej folii jak piszesz, ale jakoś zbrakło mi motywacji, by zamówić i przetestować.

IS wrote:

Rozumiem, że MAXy są też od chińczyków? Jak się zachowują te ich podróbki? Nie grzeją się?

Tak, MAXy są z Chin, jak i większość pozostałych elementów. Poniżej zdjęcie przedstawiające dwa MAXy -górny wylut z płytki wyświetlacza, a dolny zamówiony jako sam układ. Te z wylutu nie zawsze poprawnie się inicjują i padają jak muchy. Te dolne działają idealnie. Żadne z nich się nie grzeją -przynajmniej w moim zastosowaniu.

Świetny projekt, urzeka swoją prostotą z zewnątrz aż chciałoby się go postawić na półce. Wykonanie na wysokim poziomie a efekty przejścia robią wrażenie.
Jaki wyszedł ostatecznie koszt całego urządzenia?

dondu wrote:

patyk_piotr wrote:

Świetne wykonanie, gdyby miał jeszcze bateryjne zasilanie całej matrycy to już w ogóle

Zastanawiałeś się nad tym jaką musiałaby mieć pojemność, by przetrwać chociaż 24h?

Powiedzmy, że diodki biorą 10mA i jednocześnie jest ich max 32 zapalone - mamy pobór ok 320mA średni (pomijając ustawienia jasności itp) dodajmy resztę elektroniki to mamy ok 400mA. na ogniwie 2000mAh podziałałby ok 5h, ale trzeba dołożyć przetwornicę itp - dużo pracy, żeby to dodać.

Zależy do czego miałoby to służyć - podtrzymanie na jakiś czas wyłączenia prądu, czy działanie dłuższe w plenerze?

Zawsze można układ zasilić z powerbanka.

Znalazłem obsługę NTP na esp8266
http://www.john-lassen.de/en/projects/esp-8266-arduino-ide-webconfig.
Wybierasz dowolna strefę czasową i dowolny serwer.

W tej chwili robię sterownik PID do wędzarni, który oparty jest tylko na esp8266 (Witty 32Mb). Program napisany (zlepiony z części znalezionych w sieci) - PID na sterowaniu grupowym z oknem 10s (takie PWM 10s) + DS18B20. W tej chwili meczę stronę WWW. Niestety HTML i C to dla mnie nowość...
Chciałbym tam zrobić coś w rodzaju sterownika czasowego z synchronizacją NTP, ale w tej chwili to dla mnie czarna magia.
Ogólnie sterowanie najlepiej działa na Websocket (jest natychmiastowe) chodzi mi o obsługę np włącz wyłącz przez www w sieci lokalnej.
Stronę można zbudować bezpośrednio w środowisku Arduino. https://github.com/esp8266/Arduino
Jak chcesz sterować tym spoza sieci domowej to są już biblioteki MQTT.

Co myślicie o wyświetlaczu na diodach Neopixel (ws2812b) do sterowania całym wyświetlaczem wystarczy 1 wyjście cyfrowe z ESP i dałoby to nowe możliwości (kolor 24bit).

Projekt super.

Jak już tak kombinować na siłę z zasilaniem bateryjnym to trzeba by było ostro ciąć pobór prądu żeby to miało sens, co za tym idzie czytelność wyświetlacza by spadła gabaryty by się zwiększyły itd.

Jak ktoś chce to może przecież sobie taki zegar skonstruować, tutaj autor prezentuje swój gotowy zegar i zasilanie bateryjne jak widać nie było jednym z założeń projektowych.

macgyver96 wrote:

Jaki wyszedł ostatecznie koszt całego urządzenia?

W końcu znalazłem chwilę, by policzyć i oto co wyszło:

10x PCB wyświetlacza	$42.32
10x PCB logiki	$44.12
28x LED matrix Red	$29,75
12x LED matrix Yellow	$21,25
40x MAX7219	$20.00
10x ESP8266	$22.68
10x micro SD	$4.20
10x ATmega328P	$10.97
10x DS3231	$2.65
10x 8MHz	$1.99
10x micro USB	$2.50
10x 74LVC125	$3.19
10x DS18B20Z	$16.84
10x gniazdo bat	$0.96
10x przycisk	$0.14
10x gniazdo prog.	$1.71
10x LM1117	$0.36
---------------------------------
	$225.63 * 4,13 = 931.85zł

Do tego dochodzą elementy dyskretne, cyna, flux, zmywacz, więc materiał na wykonanie 1 zegara to około 100zł

_JAG_ wrote:

Stronę można zbudować bezpośrednio w środowisku Arduino. .

Pewnie i można, tylko że ja koduję w C i raczej nie zainteresuję się już Arduino.

Męczę się od jakiegoś czasu dokładnie z tymi samymi wyświetlaczami na tym sterowniku. Nie mogę wpaść na pomysł jak wydajnie sterować nimi, tak by jak u Ciebie dało się scrollować obraz. Mógłbyś napisać coś więcej o programie który steruje wyświetlaczami?

BartekWB wrote:

Mógłbyś napisać coś więcej o programie który steruje wyświetlaczami?

Pierwsze co musiałem zrobić, to to, aby jeden bajt był jedną pionową linią. Dlatego do scroll'owania stosuje się czcionkę o takiej konstrukcji. Ja tu miałem małą zagwozdkę, bo robiąc płytkę wyświetlacza wzorowałem się na oryginale w którym umieszczono wyświetlacze tak, że wysłanie bajtu do MAXa rysuje poziomą linię. Czyli osiem bajtów, to osiem poziomych linii na pierwszym wyświetlaczu. Wystarczyłoby obrócić je o 90 stopni i byłoby idealnie, ale trzymałem się oryginału i musiałem zastosować konwersję. Stworzyłem bufor o pojemności 4x8 bajtów (tablica 32 bajtowa) i to do niego zapisuję dane, tak jakby wyświetlacz był w zapisie pionowym. Następnie zawartość bufora jest konwertowana do zapisu poziomego i wysyłana do wyświetlacza. Sam scroll to też nic skomplikowanego. Bufor jest większy o 1 znak (wyświetlacz) niż to co widać i przesuwane są w nim bajty (po kolei bajt po bajcie, bo to pionowe linie) aż wysunie się cały jeden znak (dla ułatwienia zastosowałem czcionkę 8x8 pix z małego Atari). Następnie pobierany jest kolejny znak i tak w kółko, aż cały tekst zostanie odczytany. Myślę, że w miarę jasno to opisałem.

Dotarły do mnie okleiny i okleiłem zegarki. Boki zegarków okleiłem folią o fakturze carbon. Na wyświetlaczu czarnego zegara folia do przyciemniania szyb (darc black) i na niej jeszcze folia matowiąca by tak niebłyszczał. Na wyświetlaczu białego matowa folia do drukarki.



Wydaje mi się, że właśnie tego brakowało tym zegarom.

Gdzie można znaleźć tą czcionkę zapisaną w postaci pliku font lub gotową tablicę do wysyłania do matrycy? Wszystkie które wygoglowałem są o wysokości 7 pikseli (jeden dolny wiersza jest czyszczony), a ty masz 8 pikseli. Udostępnisz tablicę znaków?

FastProject wrote:

Gdzie można znaleźć tą czcionkę zapisaną w postaci pliku font lub gotową tablicę do wysyłania do matrycy? Wszystkie które wygoglowałem są o wysokości 7 pikseli (jeden dolny wiersza jest czyszczony), a ty masz 8 pikseli. Udostępnisz tablicę znaków?

Jeżeli chodzi Ci o czcionkę, którą prezentuję czas, to "rzeźbiłem" ją ręcznie przyglądając się innym czcionkom, tak by miała rozmiar 8x6:


a jeśli chodzi Ci o czcionkę od napisów, to tak jak pisałem jest ona w formacie 8x8 i pochodzi ze zbiorów z ATARI XL/XE. W załączniku wszystkie czcionki jakie pobrałem z atarionline.pl i skonwertowałem do C w wersji poziomej i pionowej wraz z plikami graficznymi obrazującymi ich wygląd.

A w czym konwertujesz te czcionki znaków do C?
Czy faktycznie nie ma innej opcji i dla wersji statycznego tekstu/cyfr zegara i dla wersji przesuwanej trzeba generować 2 rożne tablice znaków i cyfr?

FastProject wrote:

A w czym konwertujesz te czcionki znaków do C?

Przecież masz to w listingu.

Freddy wrote:

FastProject wrote:

A w czym konwertujesz te czcionki znaków do C?

Przecież masz to w listingu.

No jest, ale chciałbym wiedzieć, czy konwertował wszystko ręcznie, czy korzystał z jakiegoś narzędzia....na przyszłość taki konwerter by się przydał.

FastProject wrote:

A w czym konwertujesz te czcionki znaków do C?
Czy faktycznie nie ma innej opcji i dla wersji statycznego tekstu/cyfr zegara i dla wersji przesuwanej trzeba generować 2 rożne tablice znaków i cyfr?

Te od prezentacji czasu -tak jak napisałem wcześniej były tworzone "ręcznie". Dlatego właśnie zapisane są binarnie. Te z Atari konwertowałem jakimś autorskim skryptem. Nigdy nie korzystałem z żadnego programu do tworzenia/konwertowania czcionek.
Nie ma konieczności posiadania dwóch zestawów fontów. Miałem czcionki 8x8 pix to je wykorzystałem, a że na reprezentację czasu były za szerokie, to specjalnie wykreowałem węższe.

Da radę abyś napisał lub podał przykład jak ściągasz czas z serwera NTP, jak wysyłasz zapytanie i co otrzymujesz?
Próbowałem coś wysłać ale jeszcze z użyciem układu ENC

vp32 wrote:

Da radę abyś napisał lub podał przykład jak ściągasz czas z serwera NTP, jak wysyłasz zapytanie i co otrzymujesz?

Wzorowałem się na kodzie z tej strony: http://forum.43oh.com/topic/8948-ntp-from-esp8266-via-at-commands/

Czyli w prostych krokach:
-zestawiamy połączenie UDP na porcie 123,
-wysyłamy paczkę 48 bajtów (0xE3, 0x00, 0x06, 0xEC i dalej same zera),
-z odebranej paczki danych wyłuskujemy czas (4 bajty 40-43) -są to sekundy od 1 stycznia 1900 roku,
-odejmujemy od tego 2208988800 co daje nam sekundy od 1 stycznia 1970 roku, tj. Unix Timestamp.
Następnie konwertuję Timestamp na rok, miesiąc, dzień, dzień tygodnia, godzinę, minuty i sekundy.

vayo wrote:

-z odebranej paczki danych wyłuskujemy czas (4 bajty 40-43) -są to sekundy od 1 stycznia 1900 roku,

Należy wyłuskiwać bajty 17-20 (Reference Timestamp), bo te które wskazałeś są opcjonalne według standardu NTP:



Dlatego też jak wykorzystasz NTP Google np. time1.google.com to odczyt z tych bajtów będzie prawidłowy.

W twoim przypadku z NTP 130.102.128.23 wykazuje pomiędzy bajtami 17-20, a 40-43 różnicę.

Dlatego zmień serwer i odczytuj właściwe bajty. Dodatkowo podając adres w postaci domeny serwera, a nie konkretnego IP będziesz miał pewność, że DNS prawidłowo odnajdzie adres IP serwera.

Korzystając z serwerów Google będziesz miał natomiast pewność, że serwer zawsze będzie działał, bo to Google, a nie jakiś z University of Queensland w Australii: http://www.localiser-ip.com/?ip=130.102.128.23
którego adres to: a.pool.ntp.uq.edu.au


A jeśli chcesz dodatkowo kontekst patriotyczy, to możesz wykorzystać polskie zegary atomowe np.: ntp1.tp.pl
Inne polskie: https://pl.wikipedia.org/wiki/Serwer_czasu

Polskie serwery NTP, to może być nawet lepszy wybór niż Google, gdyż PING do nich to zapewne kilkanaście ms, a do Google i Australii może być nawet pół sekundy. Jest więc prawdopodobne, że dokładność synchronizacji będziesz miał jeszcze większą

Quote:

AT+PING="ntp1.tp.pl"
+15

OK
AT+PING="130.102.128.23"
+438

OK
AT+PING="130.102.128.23"
+519

OK
AT+PING="time1.google.com"
+264

OK
AT+PING="time1.google.com"
+291

OK
AT+PING="ntp1.tp.pl"
+15

OK
AT+PING="ntp1.tp.pl"
+15

OK

dondu wrote:

Należy wyłuskiwać bajty 17-20 (Reference Timestamp), bo te które wskazałeś są opcjonalne według standardu NTP:

Ja nie należę do tych, co bezmyślnie przepisują to co znajdą. Poniżej przykładowy odebrany pakiet z moich wcześniejszych testów:
2B4950442C34383A [0-7] // preambula: +IPD,48:
240206EC000036EC000007DC808A8C2CDB79A27DC45F221D0000000000000000 [0-31][8-39]
DB79A5D53A83319BDB79A5D53A84BAF1 [0-15][40-55]
Pierwsze wyróżnienie to Twój Reference Timestamp -zobacz o ile się różni od faktycznego czasu, a dlaczego? Bo Reference Timestamp to czas ostatniej synchronizacji serwera, a nie aktualny czas.
Ja korzystam z Receive Timestamp, a jest jeszcze Transmit Timestamp i w naszym przypadku nie ma znaczenia z którego skorzystamy, bo i tak operujemy tylko na sekundach, a nie na ich częściach.

Co do samych serwerów, to u siebie korzystam ze swojego na MikroTik'u, a poza własną siecią z pl.pool.ntp.org -zwraca IP losowego serwera z Polski

Przecież właśnie ten problem opisałem i wskazałem korzystasz z serwerów, które nie są bezpośrednio sprzężone z zegarami atomowymi i muszą się synchronizować przez sieć i w dodatku są powolne.

Dlatego sugeruję Ci korzystać bezpośrednio z polskich zegarów atomowych.

Oto odpowiedź z polskiego zegara atomowego ntp1.tp.pl podzielona na 32 bitowe bloki zgodnie ze standardem NTP.

Quote:

24 02 06 EC
00 00 00 00
00 00 00 76
47 4F 4F 47
DC 33 C3 31
67 90 5F FE
00 00 00 00
00 00 00 00
DC 33 C3 31
67 90 5F FF
DC 33 C3 31
67 90 60 01

w dodatku ping ma 15ms.

Obaj pomijamy oczywiście fakt, że pola te są 64-bitowe porównując tylko sekundy.

Co do Transmit Timestamp masz oczywiście rację.

Tak więc jak sam widzisz, tylko przy korzystaniu z NTP z jakiegoś root serwera z zegarem atomowym czas synchronizacji równy jest czasowi zapytania (co widać na Twoim przykładzie) -dla tego nigdy nie powinno się korzystać z Reference Timestamp, a z Receive Timestamp / Transmit Timestamp, bo to są aktualne czasy, a sam serwer może się synchronizować nawet co kilka godzin. Ja na swoim mam standardowo włączoną synchronizację co 900s i słuchając Twojej wcześniejszej rady, by korzystać z Reference Timestamp mógłbym otrzymać czas nawet 15 minut spóźniony

vayo wrote:

Ja na swoim mam standardowo włączoną synchronizację co 900s i słuchając Twojej wcześniejszej rady, by korzystać z Reference Timestamp mógłbym otrzymać czas nawet 15 minut spóźniony

Oj nie
Wyrwałeś z kontekstu tylko fragment wypowiedzi, a brzmiała ona:

dondu wrote:

Dlatego zmień serwer i odczytuj właściwe bajty.

bo jak pokazałem korzystanie bezpośrednio z serwera zegara atomowego nie powodowałoby 15 minut, gdyż sekundy są takie same we wszystkich 3 polach, co pokazałem na przykładzie serwera zegara atomowego ntp1.tp.pl

Gdybyś więc zrobił tak jak sugerowałem nie miałbyś nawet sekundy opóźnienia.

Dodatkowo należy zwrócić uwagę na dane z pól Root delay (Estimated Error ) oraz Root dispersion (Estimated Drift Rate), które w serwerze ntp1.tp.pl są zerowe lub znacznie mniejsze niż ten którego przykład pokazałeś.

Dlatego jeszcze raz podkreślam, niepotrzebnie korzystasz z wtórnych źródeł czasu, mając do dyspozycji idealne źródło w postaci zegara atomowego zlokalizowanego w Polsce, który w dodatku odpowiada w ciągi 15ms.

Ale Ty uparty jesteś Protokół NTP został wymyślony nie po to, by serwerami były tylko atomowe wzorce czasu, ale po to by średnio dokładne zegary mogły też być serwerami -wystarczy tylko że co jakiś czas zsynchronizują się z dokładniejszym serwerem. A Reference Timestamp to tylko informacja kiedy ostatnio nastąpiła taka synchronizacja, a nie aktualny czas. Jest to podane tylko w celach informacyjnych. Powtarzam jeszcze raz, że Reference Timestamp == Receive Timestamp tylko w przypadku, gdy serwer NTP korzysta z własnego atomowego wzorca czasu. No ale tak jak napisałem wcześniej protokół ten został tak wymyślony, aby każdy mógł mieć swój własny serwer czasu.
Korzystając z Twojej rady, trzeba by było faktycznie zmienić serwer na taki z atomowym wzorcem i można wtedy pobierać czas z Reference Timestamp, ale po co to robić, skoro niezależnie od typu serwera NTP aktualny czas mamy w Receive Timestamp / Transmit Timestamp?

Ale Ty uparty jesteś

Przecież napisałem, że co do pola Reference Timestamp vs Transmit Timestamp masz rację ... ale jednocześnie pokazałem, że gdybyś korzystał z zegara atomowego to nie byłoby to problemem bo oba pola zawierają te same sekundy.

vayo wrote:

Korzystając z Twojej rady, trzeba by było faktycznie zmienić serwer na taki z atomowym wzorcem i można wtedy pobierać czas z Reference Timestamp, ale po co to robić, skoro niezależnie od typu serwera NTP aktualny czas mamy w Receive Timestamp / Transmit Timestamp?

To mniej więcej takie postępowanie: Mógłbym jechać taksówką prosto do celu, ale wybieram jadącą dookoła.

Zmień więc ten serwer bezpośrednio na atomowy zegar np. ten wskazany w Polsce pobieraj dane jak pobierasz, czyli z pola Transmit Timestamp, bo projekt dotyczy zegarka, który synchronizować ma się z najlepszym możliwym wzorcem, a tego nie robi ... i zakończmy dyskusję