Niestety, po kolejnych testach sprawa wygląda gorzej, niż się wcześniej wydawało. W zależności od sytuacji, czas internetowy laptopa, nawet synchronizowany z serwerami urzędowymi, może dać różne wyniki w stosunku do czasu GPS! Dotąd otrzymywałem wyniki stabilne, gdzie czas laptopa zawsze był nieco spóźniony w stosunku do czasu GPS, średnio o 0.06 do 0.08 s. Dzisiejsze testy pokazały coś innego - czas laptopa różnił się bardziej, nawet ponad 1 s! Co więcej był on przyśpieszony, nie opóźniony. W każdej sesji kontrolnej różnica była przy tym inna, chociaż stabilna w ciągu kilku minut.
Wniosek: musimy poczekać na profesjonalny inserter czasu dla kamer cyfrowych.

Poprawkę czasu w przypadkach szczególnych należałoby wyznaczać przed i po ważnej obserwacji kamerą cyfrową, ale stałej jej wielkości nie da się podać.
Przypuszczam, że jednym z powodów jest opóźnienie łączenia się z serwerem czasu, a to z kolei zależy od jakości sygnału internetowego. Dziś brałem go z routera domowego, ale dość oddalonego od miejsca testowania; czasem nawet program synchronizujący nie mógł się z serwerem połączyć.
Oczywiście, w przypadku, gdy zależy nam tylko na czasowym przebiegu zjawiska zakrycia bez konieczności uzyskiwania czasu bezwzględnego, sprawa opóźnień nie jest istotna.

Być może tu był problem z tym WiFi.
Komputer powinien być podpięty pod stałe, szybkie łącze internetowe.
Wszelkie WiFi i internet mobilny są na chwile bieżącą niewiarygodne, nawet w przypadku synchronizacji "tuż przed zjawiskiem".

Wydaje mi się, że najdokładniejszą metodą stempla czasowego w przypadku kamer cyfrowych jest nagranie błysków diody LED, która bezpośrednio bierze impulsy 1PPS z odbiornika GPS, np z insertera.

Jedna z prezentacji na ostatnim ESOP była o tym: http://esop37.cz/sbor/L6-1_Wuensche_lecture.pdf

_________________
Pozdrawiam, Wojciech Burzyński
członek Zarządu Głównego PTMA

Jestem cały za, aby to przetestować. Kamera cyfrowa ma zbyt wiele zalet, aby z niej od razu rezygnować.
Z drugiej strony to chyba wszystko zależy też od aktualnej siły sygnału. Bo z wi-fi też korzystałem (nawet z telefonu komórkowego, bo też zwykle ma u mnie w polu lepszy zasięg, niż router przenośny), może akurat było dobre połączenie, bo wyniki były poprawne. Z trzeciej strony stwierdziłem też drobne uchyby czasu w synchronizowanym automatycznie telefonie komórkowym, w odniesieniu do zegara DCF77 i do czasu GPS. Różnie to więc bywa.
Ale przedwczoraj się normalnie przeraziłem, widząc uchyby czasu laptopa w sekundach. Laptop był na balkonie, a domowy router dwa pokoje dalej, może to stąd. Jeszcze jedna rzecz: Inseter VTI IOTA też czasami sygnalizuje problemy, np. brak zasięgu większej liczby satelitów i stąd pogorszenie displaya czasu. Trzeba i na to uważać. Nie wiem, jak to jest w inserterach produkcji krajowej.
Będę jednak testował dalej, jak to wszystko działa, róbcie to samo.

Witam, ja w swojej pracy jako krótkofalowiec wykorzystuję cyfrowe emisje radiowe. W większości oparte są one o pracę komputera. Niektóre z tych emisji wymagają synchronizacji czasowej komputer ów, ale na szczęście wystarcza tu synchronizacja nie przekraczająca dokładności sekundy. Do takiej pracy wystarcza mi synchronizacja komputera przeprowadzona internetowo.
Jednak znam ten problem. Ta synchronizacja nigdy nie jest dokładna w stosunku np. do radiowych sygnałów czasu. Zawsze jest opóźniona i to różne wartości. Nie sposób stwierdzić czy za każdym razem połączenie z serwerem idzie tą samą drogą i poprzez tą samą liczbę elektroniki pośredniczącej. Gdyby komputer nawet znał odległość to i tak wniesienie poprawki tylko na odległość może nic nie dać. Nie tylko odległość wchodzi tu w grę, ale i zmienna obciążalność łączy, a zatem szybkość transmisji. Do tego nawet nasz komputer nie jest stabilny w czasie jeśli chodzi o jego obciążenie. Musi kontrolować wiele podzespołów i funkcji, których praca też jest zmienna w czasie.
Kto dzisiaj kontroluje dokładność pracy rejestratorów GPS ? Kiedyś robiło się to namacalnie programem Janusza W. z dokładnością nie gorszą niż 0,001 sek. Po prosu program przyjmował na kartę dźwiękową równocześnie 2 sygnały czyli ze wzorca (np. radiowego) i z rejestratora. Różnice były pięknie widoczne na ekranie. Być może dzisiejsze rejestratory GPS wprowadzają opóźnienie tak małe, ze można je zupełnie pominąć w naszych potrzebach.
Myślę, że do czasowania rzędu setnych części sekundy w rejestracji cyfrowej trzeba skonstruować specjalne urządzenie li tylko do obsługi czasu. Jego zniekształcenia będą raczej stałe i dające się skorygować, lub będą pomijalne.

Tak, to wszystko wydaje się tak wyglądać, niestety.
Jest jeszcze "drugie dno" przynajmniej dla mało obeznanych z tematem zawodowo (jak ja...).
Programy synchronizujące pokazują na bieżąco poprawki, jakie wprowadzają do czasu komputera. Można też synchronizować ręcznie , nawet co chwilę. I te wyniki "skaczą", np. raz jest +0.32s, a zaraz potem np. -0.28s. Zegar komputera na pewno tak źle nie chodzi, są to zatem opóźnienia na łączach.
Ale gdy zapuściłem synchronizację automatyczną co 1 min. na dłuższy czas, to przy odczytaniu historii synchronizacji miałem wyniki nawet na poziomie +- kilka sekund!!! Np. była synchronizacja typu -5 s, a natychmiast potem +5s, czyli jakby wycofanie się z tej pierwszej (być może błędnej). Ale, co dziwne, tego nie było tego widać na porównaniu zegara komputera z tym z GPS - na nagraniach trwających dłużej, niż 1 minuta. A powinno być widać jako periodyczne (co 1 min) i skokowe zmiany czasu komputera, nawet przy poprawkach rzędu 0.1s powinny być łatwo zauważalne. Będę jeszcze dalej testował rzadszą synchronizację, co pozwoli ocenić sam zegar komputera i dam znać.

Aby program w komputerze mógł wprowadzić poprawkę to by musiał najpierw wysłać sygnał kontrolujący do serwera czasu, a ten by musiał niejako odbić ten sygnał z powrotem do komputera czyli na jego adres. To by mogło określić czas przebiegu sygnału i wtedy by mogła być obliczona i wprowadzona poprawka. To by to było możliwe też odwrotnie, że inicjuje to np. serwer czasu. Nie sądzę aby to tak działało. Serwer by nie wydolił odpowiadając takiej liczbie użytkowników.
Same zegary w komputerach bywają różne. Różnymi laptopami sterowałem emisją cyfrową w radiostacji. Niektóre wystarczyło zsynchronizować raz na wiele dni i trzymały czas inne trzeba było synchronizować codziennie by potem radiostacje mogły wymieniać ze sobą informacje.
Przyszłość jest na pewno w tym naniesieniu czasu już na etapie samej kamery co zrobili nasi koledzy z południa. Wtedy nie ma znaczenia kiedy i jak rytmicznie się to zapisze na pliku. O ile wiem podali sposób jak to zrobić, ale do tego trzeba mieć odpowiedni warsztat by nie uszkodzić kamery. Każda nieudana próba może być kosztowna. Nie wiem jaką czułość mają kamery astronomiczne przy czasie ekspozycji 1/50 czy 1/25 sek. My operujemy luxami i wiemy jak to się przedkłada na obraz przy danym teleskopie. Jeśli ktoś z zakryciowców naszych ma kamerę astronomiczną to niech ustawi tam np. 1/25 bo taki czas nam wystarczy do uzyskania dokładności obserwacji rzędu 0.04 sek i sprawdzi do jakiej wielkości gwiazdy widać przy danym teleskopie. Chyba, że to jest już znane i odgrzewam stare kotlety. To w takim razie może ktoś poda tutaj wyniki takich prób.

Nie znam obsługi kamer astronomicznych, ale widzę z opisów że ten czas ekspozycji ustawia się tylko do zdjęć. Robienie filmów determinuje szybkość np. 50 czy 60 kl/sek. Czyli podobnie jak to jest w naszych popularnych aparatach fotograficznych. Tak więc można nagrać próbne filmy i sprawdzić zasięg sprawdzając poklatkowo.

Testy zasięgu dla swojej kamery cyfrowej pokazywałem na ostatniej konferencji SOPiZ. Zasięg znacznie zależy od czasu ekspozycji, ale z kolei rozdzielczość czasowa zależy jeszcze od rozdzielczości obrazu. Dla zakryć wystarcza mała rozdzielczość obrazu np. nawet 320x240, co zwiększa szybkość zapisu klatek. Gdyby dać pełną rozdzielczość kamery na zapis, to uzyskanie klatek np. co 0.05 s nie jest możliwe z uwagi na ograniczoną szybkość zapisu obrazu.
Co do serwera czasu, to dziwne nadal jest dla mnie, że co chwilę daje inną poprawkę czasu dla zegara latopa, który chyba jest dość stabilny (nie mówię tu jego o trendzie chodu w ogóle). Inna uwaga: korzystając z różnych programów synchronizacji czasu można czasem nie otrzymać żadnej poprawki. Tak np. zameldował mi raz program NeT Time, który automatycznie wybiera sygnał z 4 serwerów NTP. Dał po prostu komunikat, że z żadnym z nich nie dało się połączyć... Dimension 4 tak nigdy nie zakomunikował, aczkolwiek on daje swoje poprawki czasu, o innej wartości i nadal to testuję.

Ludzie w innych krajach mają urządzenia GPS, generujące sygnał świetny na kamerę cyfrową. W okresie obserwacji zakrycia wyznaczają poprawkę synchronizowanego zegara laptopa.
Link do takiej strony z wyjaśnieniami (po francusku, ale można przetłumaczyć):

http://www.nocturno.fr/ost/ost.html

Wyniki są stabilne.
Ale ja uważam, że tak jest przy dobrym sygnale internetowym oraz stabilnym serwerze czasu, a z tym, jest różnie w warunkach polowych.

Kolejne testy, na razie ostatnie.
Użyłem do synchronizacji programu NetTime, ustawionego na 30 min częstotliwość. Sygnał z internetu z routera domowego po kablu do laptopa.
Sygnał GPS z IOTA VTI.

Wyniki:
TEST 1. offset NetTime +1 ms
Opóźnienie średnie 0.08s (+-0.02s jak chodzi o pojedyncze klatki)

TEST 2. offset NetTime +3 ms
Opóźnienie średnie j.w.

TEST 3. offset NetTime +4 ms
Opóźnienie średnie j.w.

WNIOSEK OGÓLNY : stabilny sygnał internetowy daje bardzo stabilne wyniki stempla czasowego na kamerze cyfrowej i nie grozi żadnym poważnym błędem wyniku końcowego obserwacji przy użyciu takiej kamery. Problem tylko, jak taki sygnał uzyskać w terenie. Na wszelki wypadek należy dokonać porównania obu czasów w okolicy obserwacji zjawiska (jeśli ktoś ma obie służby czasu, rzecz jasna). Przy słabym sygnale czasowym lub zakłóceniach błąd może iść w sekundy!

Jednak te testy nadal trzeba wykonywać. Jak mi słusznie zwrócił uwagę Leszek, dochodzi jeszcze opóźnienie reakcji ekranu laptopa. Toteż moje wcześniejsze testy nie zawsze były poprawne, ponieważ na nagraniach niekiedy czas z VTI był brany bezpośrednio, a czas z kamery cyfrowej, a więc z laptopa, był nagrywany z ekranu. Dlatego też zrobiłem nowe testy, o czym poniżej:
1. Można nagrać obraz pokazujący display z VTI na ekranie, a zawierający, oczywiście ten sam czas brany bezpośrednio. Mój wynik: opóźnienie wskazania ekranowego wynosi 0.12 s w temperaturze >20 stopni C.
2. Testy porównania powtórzyłem, filmując jednak oba displaye czasu – VTI i laptopa brane z ekranu. Wtedy okazuje się, że średnio czas laptopa (oczywiście po jego dobrej synchronizacji) jest WCZEŚNIEJSZY od VTI o 0.04-0.05 s. To się zgadza, ponieważ poprzednio ustalona różnica w.w niepoprawną metodą wynosiła 0.07-0.08 s jako opóźnienie czasu laptopa. W tym mieściło się opóźnienie ekranu 0.12s.
3. Wykonałem tez inny test – nagrywania migania sztucznej gwiazdki. Utworzyłem ją przez błyskanie na ścianę wskaźnikiem laserowym. Gwiazdka była całkiem nagła, chociaż z uwagi na ręczny przycisk niekiedy pojawiała się i znikała na dwóch klatkach, w większości przypadków jednak na jednej, a więc nagle. Nagranie było wykonywane: a) dla czasu satelitarnego kamerą analogową Watec z VTI IOTA i grabberem oraz programem VirtualDub przy 25 fps, b) dla czasu laptopa kamerą cyfrową ZWO ASI 120MM i laptopem Lenovo z podłączonym kablowo internetem i synchronizacją czasu programem Net Time (w dwóch seriach poprawka wyniosła +10 i +15 ms, ale w czasie samego nagrywania korekty czasu już nie było) przy rozdzielczości czasowej ok. 0.02s (obraz 320x240 px); program nagrywający firmowy ASICAP.
Wynik z około 30 sztucznych zjawisk pojawiania się i znikania sztucznej gwiazdki: wartości momentów czasu z obu źródeł były bądź identyczne, bądź z uchybem 0.02s (czas laptopa wcześniejszy), co mieści się w granicach błędu pomiaru czasu przez kamerę Watec (0.04s – 25 fps).
Ale uwaga: prawdopodobnie z uwagi na obciążenie procesora (nagrywanie na tym samym laptopie dwóch strumieni video jednocześnie) część klatek na nagraniu VirtualDub została utracona (sekwencje po 8-11 klatek). Ciekawe, że równoległe nagranie z kamery cyfrowej było praktycznie bezstratne.
Ten test jest miarodajny jednak dla idealnie działającego internetu, nadal nie ma pewności, jak to się odbywa w warunkach terenowych. Pilnie potrzebny inserter satelitarny z migającą diodą co 1 sekunda.

Potrzebujesz GPS-owej diodowej sekundy. Inserter Tomka daje taką sekundę czerwoną diodą. To jest dobre bo dioda niemal nie ma zwłoki.

Czyżby koniec problemów?

Wykonałem na razie ostatnie testy, jakie mogłem na swoim sprzęcie:

Test 1. Sprawdzenie chodu zegara laptopa Lenovo przy wykorzystaniu początkowej synchronizacji czasu programem Dimension4 wg serwera Vega, internet wifi z routera domowego, zegar laptopa nie synchronizowany ponownie w czasie trwania testu. Wynik na załączonym wykresie - średnie opóźnienie zegara laptopa 0.01s na godzinę. Na osi poziomej czas względny - długość testu około 1 godziny.
W tym miejscu dziękuję Tomkowi Kluwakowi za udostępnienie autorskiego oprogramowania do zapisywania różnic czasu do pliku.

Test 2. Rejestracja obrazu migającej diody odbiornika DFC za pomocą kamery cyfrowej ZWO ASI 120MM (programem firmowym ASICAP) przy rozdzielczości obrazu 320x240px (108 fps) oraz 640x480px (57 fps).
Wyniki: opóźnienie diody średnio 0.04-0.05 s w pierwszym przypadku i 0.05-0.06s w drugim. Z dyskusji z Leszkiem wynika, że użyty układ DCF ma stałe opóźnienie 0.018s, w takim razie coś jeszcze spowalnia diodę o dalsze 0.02-0.03s, ale zegar laptopa chodzi idealnie w ciągu przynajmniej kilku minut testu. Nieco większe opóźnienie przy większym rozmiarze obrazu może wynikać z szybkości jego zapisu na dysk twardy.

Wykonujcie swoje dalsze testy, w każdym razie na pewno wypada jeszcze testować szybkość i stabilność łączy internetowych w terenie.

Żeby nie było za pięknie: wszystkie poprzednie testy były wykonywane w korzystnych warunkach temperaturowych, a ostatnie dodatkowo przy pobieraniu sygnału internetowego kablem z modemu.
Podczas obserwacji zakrycia przez Dulcineę silnego sygnału internetowego nie było, wziąłem do więc z telefonu komórkowego. Temperatura była około 0 C.
Synchronizacja zegara laptopa Dimension4 powiodła się znakomicie z opóźnieniem 0.00 s. Zrobiłem ją raz, a potem drugi raz przed samą obserwacją i nagrywaniem. Na załączonym wykresie rezultaty pracy zegara laptopa przy pobieraniu wartości jego offsetu z serwerów internetowych przez program, użyczony przez Tomka Kluwaka. Te offsety to najmniejsze wartości określane co minuta, czyli najmniejsze wartości z najlepszego aktualnie serwera czasu ( w sensie jakości połączenia się z nim).
Jak widać, na mrozie laptop pracuje już nie tak dobrze - chociaż opóźnienia nie przekraczają 0.02s w ciągu około kwadransa ( z jednym wahnięciem 0.06s niewiadomego pochodzenia).

Jeszcze drobna korekta: jeśli jest offset<0, to czas laptopa trzeba zmniejszyć! Czyli jest to poprawka, dodawana ze znakiem.
W związku z tym 12.02 mój laptop raczej przyspieszał, a nie opóźniał się.