Zakrycie planetoidalne podczas najbliższego zlotu w Lipowcu

[Agent Smith]

W Sobotę 02.02.2019 ok godz 6 rano czasu miejscowego będzie miało miejsce zakrycie gwiazdy HIP78503 (9,7 mag) przez planetoidę (260) Huberta (ok 15 m)

Oczekiwany spadek jasności ca.5 mag, czas trwania zjawiska w linii centralnej 3,9 sek.

 

Szczegóły: http://www.asteroidoccultation.com/2019_02/0202_260_59212.htm

Lipowiec znajduje się 7 km poza przewidywanym pasem zakrycia, w tzw 1-sigma zone, co czyni go świetnym miejscem (bazą) do obserwacji tego zjawiska, gdyż

obserwacje przeprowadzone blisko brzegu pasa zakrycia (po obu stronach) mają największą wartość (także obserwacje negatywne)

 

Cóż, wiem że na naszym ulubionym Astropolis tematyka zakryć nie cieszy się wielkim wzięciem, może więć byłaby to okazja do popróbowania czegoś innego

 

Gdyby znaleźli się chętni, moglibyśmy przeprowadzić akcję - np. rozstawić się prostopadle do pasa zakrycia, wzdłuż drogi lokalnej na Jaśliska

(nie wiem jak jest z widocznością nieba w tej dolince) i dalej wzdłuź drogi 887.

 

Jest oczywiście wiele wyzwań przed ewentualnymi śmiałkami - poczynając od grilla w piątkowy wieczór a na służbie czasu kończąc.

Ale najpierw zobaczmy, czy temat kogokolwiek (poza mną) kręci - dajcie znać (w niniejszym wątku) kto byłby zainteresowany, jeśli zbierze się silna grupa pod

wezwaniem będziemy się martwić o detale.

 

 

 

 

 

 

 

Edytowane 10 Stycznia 2019 przez Agent Smith

[ekolog]

O jakże ciekawy temat. Przecież tą metodą przewidziano trafnie, że Ultima Thule może mieć szyję.

Ta zdaje się nie mieć szyi lecz wygląda jak kamień węgielny ale zawsze warto sprawdzić - może coś się ostatnio zmieniło (sic!).

Spora (95 km).

Pozdrawiam

 

 

Edytowane 10 Stycznia 2019 przez ekolog

[don Pedro]

Ciekawy temat.Czyli jak ktoś chciałby załapać się w  pas główny to trzeba śmigać pod Presov?

[don Pedro]

Pogadamy w piątek.

[don Pedro]

To musimy obgadać jak to rejestrować.

[MateuszW]

Fajny temat. Widzę, że moja Wieliczka mieści się pasie 1 sigma, a może udałoby się podjechać na północ? Jeśli będę miał możliwości czasowe, to chętnie spróbuję!

 

Jeśli chodzi o służbę czasu, to czy ktoś zna jakiś program do synchronizacji czasu na Windowsie z GPS?

 

Jak należy rozumieć tą sigmę? Czy będąc w niebieskim pasie mam 68% szans na rejestrację zjawiska, czy o co innego chodzi?

[burza]

Jest to zakrycie asteroidalne o bardzo dobrych parametrach - jasna gwiazda, duży i relatywnie długi spadek jasności.

Wyjaśnienia jak czytać efemeryde znajdziecie w moim tekscie na stronie: http://www.sopiz.ptma.pl/odczytywanie-efemeryd-zakryc-asteroidalnych-s-preston/

Ta obserwacja uda się nawet małym teleskopem, rzędu 10 cm średnicy i powinni ją z powodzeniem zarejestrować początkujący w zakryciach.

Najlepiej byłoby ją wykonać przy pomocy czułych kamer nagrywając film, jednak nawet obserwacje wizualne będą miały dużą wartość.

 

Aktualnie najdokładniejsze wyniki uzyskuje się zestawem czułej kamery analogowej sprzężonej z inserterem czasu - przykład tu: http://www.occultations.ch/equipment.html

Wieloletni obserwatorzy zakryć taki sprzęt posiadają i taki zestaw jest teraz normą, w zasadzie niezbędnym minimum w tego typu obserwacjach.

Takimi kamerami z inserterami czasu osiągamy dokładność 0,01-0,02 sek.

 

W przypadku zakryć asteroidalnych dopuszcza się jeszcze obserwacje wizualne, z zastrzeżeniem, że służba czasu musi być prowadzona z dokładnością 0,1 sek.

Możemy to uzyskać nagrywając na dyktafon smartfona akustyczne sekundowe sygnały czasu wraz ze swoim głosem.

Polecam w tym przypadku stronę: https://time.is/sound  - mniej więcej wzorcowe "piki" sekundowe

Jak gwiazda zniknie natychmiast mówimy krótko i wyraźnie np "ZA" (od "zakrycia"), w przypadku odkrycia mówimy jak najszybciej "OD"

Szacujemy od razu swój błąd osobowy dla każdego momentu zjawiska, przeważnie będzie to opóźnienie rzędu 0,4 sek i błąd ten uwzględniamy w wyniku końcowym.

Wszystkie nagrania dźwiękowe lub filmy najlepiej przesłać do mnie - ja zajmę się dalszą obróbką.

 

Jeśli chodzi o nagrywanie kamerami USB podłączonymi do komputera to niestety,  nawet pomimo synchronizacji czasu systemowego Windowsa z serwerami czasu NTP, metoda ta jest bardzo niedokładna, błędy mogą sięgać nawet powyżej 0,5 sekundy, co dyskwalifikuje wynik obserwacji. Na pewno będziecie nagrywać takimi kamerami, więc zminimalizujmy ewentualne błędy.

 

Polecam więc optymalne rozwiązanie - nagrywać zjawisko kamerami USB, zsynchronizować czas komputera z serwerem NTP na 5 min przed zjawiskiem, a jednocześnie zastosować nagrywanie głosem na dyktafon wg metody podanej wyżej. Kombinacja tych dwóch służb czasu będzie już na tyle dokładna, że wyniki można posłać w świat.

 

Nagrywanie rozpoczynamy na ok. 2 minuty przed początkiem zjawiska i kończymy na 2 minuty po momencie przewidzianym przez efemerydę, w tym przypadku 6:00-6:05.

Nagranie najlepiej w formacie AVI, najlepiej około 30 FPS.

 

Program do synchronizacji czasu NTP - np Dimension 4, wybieramy serwer czasu jak najbliższy miejscu obserwacji, w Polsce polecam serwer GUM.

Program do nagrywania kamerami USB - np SharpCap, należy załączyć opcję pokazywania czasu na nagraniu: Camera Control Panel->Image Controls-> Timestamp Frames: ON

 

Co do przebiegu pasa - nie należy na siłę jechać w kierunku jego środka, pas może przesunąć się akurat na południe w taki sposób, że będziecie w jego środku - to się zdarza.

Jeśli znajdzie się kilu obserwatorów to warto rozstawić się co 5-10 kilometrów,pamiętając że gwiazda jest na wysokości 25 stopni nad horyzontem w kierunku prawie południowym. To ważne zwłaszcza w terenie górskim, ewentualne miejsca pod obserwację wybierzcie za dnia, aby w nocy nie było przykrej niespodzianki i zakrycia gwiazdy przez okoliczne wzgórze. 

 

Należy zanotować z jak największa dokładnością współrzędne i wysokość swojego miejsca obserwacji - z GPS smartfona, z Google Maps, etc...

 

Jeszcze jedna ważna rzecz - niedaleko miejsca zlotu mieszka w Króliku Polskim (14 km na N od Lipowca, wzdłuż drogi 887) bardzo doświadczony zakryciowiec - ks. Wiesław Słotwiński.

Ma on niezbędny sprzęt, w tym kamery i doświadczenie i myślę, ze możecie go odwiedzić w tej sprawie.

Jeśli jesteście zainteresowani podam kontakt telefoniczny na priv.

 

Jeśli pojawią się dodatkowe pytania chętnie odpowiem.

Powodzenia I POGODY !

Wojtek Burzyński

 

 

Edytowane 18 Stycznia 2019 przez burza

[DARK]

Po (mam nadziej udanej) obserwacji zakrycia nie sprzątajcie sprzętu bo ok 7 rano będzie możliwość obserwacji zakrycia Saturna przez Księżyc  Warto wiec znaleźć taką miejscówkę by horyzont i dla zakrycia planetoidalnego i planetarnego był w miarę odsłonięty. Powodzenia!

[MateuszW]

4 godziny temu, burza napisał:

Jeśli chodzi o nagrywanie kamerami USB podłączonymi do komputera to niestety,  nawet pomimo synchronizacji czasu systemowego Windowsa z serwerami czasu NTP, metoda ta jest bardzo niedokładna, błędy mogą sięgać nawet powyżej 0,5 sekundy, co dyskwalifikuje wynik obserwacji. Na pewno będziecie nagrywać takimi kamerami, więc zminimalizujmy ewentualne błędy.

No własnie o to chodzi. NTP ma słabą dokładność. Dlatego próbuję zrobić synchronizację z GPS, ale nie znalazłem takiego programu.

 

Za to wpadłem właśnie na inny pomysł, wydaje mi się że bardzo dokładny! Otóż, zrobię sobie proste urządzenie z GPSem, które w konkretnym i znanym momencie mrugnie diodą, którą umieszczę w teleskopie. Zrobię to na chwilę przed zakryciem, na jednym filmiku. Dodatkowo będzie wyświetlony znacznik czasowy z programu, jak piszesz później, dzięki czemu będzie można porównać chwilę mrugnięcia z czasem systemu i zrobić precyzyjną poprawkę. Co myślisz?

 

Idealną rzeczą wydaje mi się pomysł QHY z GPSem umieszczonym bezpośrednio w kamerze: https://www.qhyccd.com/index.php?m=content&c=index&a=show&catid=94&id=46&cut=1. Myślę, że to jest metoda na odejście od prehistorycznej technologii kamer analogowych. Szkoda tylko że nie ma czegoś tańszego. I szkoda, że nie ma więcej takich kamer (a może są?).

 

Inną metodą, ale to już bardziej skomplikowana sprawa, byłoby użycie kamer przemysłowych np PointGrey. To są cyfrowe kamery np z interfejsem USB, które można normalnie obsługiwać w FireCpature itp. Ale ich przewagą jest, że posiadają kilka pinów GPIO, które można wykorzystać do odczytania impulsu czasowego. Wymagałoby to tylko (lub aż) programu, który zrobi z tego użytek. Czyli np dodanie do FireCapture funkcjonalności odczytywania tych wejść i zapisu ich do metadanych pliku. W sumie to może zapytam autora FC, co o tym myśli.

Edytowane 18 Stycznia 2019 przez MateuszW

[burza]

1 godzinę temu, MateuszW napisał:

 

Otóż, zrobię sobie proste urządzenie z GPSem, które w konkretnym i znanym momencie mrugnie diodą, którą umieszczę w teleskopie.

 

Skorzystaj z gotowego pomysłu na mrugającą diodę, której impulsy będą wyzwalane sygnałem 1 PPS.

Na swojej stronie Pierre La Cam umieścił realizację tego oparte o serwer czasu zbudowany na Raspberry Pi

Zobacz: http://www.nocturno.fr/ost/ntpserver.html oraz http://www.nocturno.fr/ost/ost.html

 

Nieco prostsze wydaje się rozwiązanie oparte na Arduino - zajrzyj na stronę Piotrka Smolarza http://smopi.news.nstrefa.pl/index.php?pages/Video-Time-Inserter i ze schematu ideowego wyrzuć modeł OSD. Pozostaje jedynie zogniskowac obraz diody w tulejce redukcyjnej przy pomocy soczewki krótkoogniskowej - w przypadku projektu Pierre La Cam było to 4 mm ogniskowej. To rozwiązanie zrobisz najszybciej.

 

Jak na razie nie ma innej kamery cyfrowej z wbudowanym inserterem GPS oprócz QHY 174 GPS, którą przedstawiłeś.

Istnieje jednak prototyp kolegów ze Szwajcarii oparty na ZWO ASI 120, oto link do prezentacji, która zakłada w przyszłości produkcję małej serii kamery cyfrowej wraz z inserterem czasu, powinna być 2x tańsza od QHY: http://www.occultations.ch/images/20181027_Digital_vti_presentation.pdf

 

Kolejne rozwiązanie cyfrowego inserterowania to urządzenie TimeBox: https://airylab.com/timebox-utc/

 

Byłbym zapomniał, a to może być jedno z lepszych rozwiązań dla obserwatorów.

Istnieją aplikację na smartfony:

 - z Androidem: Occult Flash Tag https://play.google.com/store/apps/details?id=br.eti.erickcouto.occultflashtag&hl=pl

 - oraz iOS: Astro Flash Timer https://sites.google.com/site/astroflashtimer/home

Mogą nie działać na niektórych telefonach, koniecznie trzeba by wcześniej sprawdzić jakość nagranego błysku na filmie i poćwiczyć w jakiej odległości od tubusa nalezy trzymać telefon. Niestety, obydwie aplikacje jako źródło czasu korzystają z NTP, ale błędy są o wiele mniejsze niż użycie NTP z Windowsem.

Edytowane 18 Stycznia 2019 przez burza

[MateuszW]

@burza dziękuję za linki, jest sporo ciekawych pomysłów.

Posiedziałem teraz trochę czasu wertując internet i znalazłem dwa ciekawe programy do synchronizacji czasu systemowego za pomoca gps podpiętego do portu com:

http://www.dxatlas.com/ToyNtp/ - to wydaje się całkiem proste do odpalenia

https://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html - tu jest bardziej skomplikowana sprawa

Spróbuję zainstalować i przetestować te rozwiązania. Jeśli będą działać, to właściwie nie trzeba będzie już nic kombinować. Wykresy dokładności są wręcz fenomenalne dla naszych potrzeb.

[burza]

Podobno wg kolegów z zagranicy najbardziej wiarygodnym i jedynie akceptowalnym programem do synchronizacji Windowsa z NTP jest software firmy Mainberg

Oto prezentacja z ubiegłego roku: http://esop37.cz/sbor/L6-1_Wuensche_lecture.pdf

 

[Agent Smith]

Cieszę się bardzo, że temat wzbudził tyle zainteresowania

 

Dla nowicjuszy w tym fascynującym "fachu" polecam przejżenie na początek tego:

https://slideplayer.pl/slide/11876956/

Tam dosyć metodycznie opisano co i jak, a i osoba autora jakby znajoma  

Pozdrawiam, Wojtku i dziękuję za jakże wartościowy głos w tym wątku! 

 

Jeśli chodzi o rejestrację zjawiska - fakt, że kamery analogowe to przeżytek (oraz, że wszyscy mamy jakieś kamery cyfrowe) - ale nie są one jeszcze przeżytkiem przy zakryciach dosyć łatwe jest bowiem naniesienie znaczników czasu na sygnał analogowy - jest na "rynku" parę rozwiązań komercyjnych, których wymieniał nie będę bo większość z nich jest obecnie nie do kupienia. 

Można jednak bardzo łatwo coś takiego sobie zmontować samemu, kosztem ok. 60-80 euro, lub nawet sporo mniej ->. Jest na ten temat oddzielny wątek: 

 

Miło mi pochwalić się, że właśnie uruchomiłem VTI (video time inserter) według pomysłu Piotra Smolarza   (mój pierwszy kontakt z Arduino w życiu)

Jeśli więc ja mogę, to Wam nie powinno to żadnego problemu sprawić

http://smopi.news.nstrefa.pl/index.php?pages/Video-Time-Inserter

 

O kamerach i zapisie analogowego sygnału (kolejne problemy) też napiszę w tamtym wątku, żeby był porządek (czy to ja to mówię??)

 

Wrócmy więc do niezwykłego poranka 02.02.2019. Mamy to szczęście, że do akcji włączył się (na razie zakulisowo) nasz niezawodny "Sokole Oko" Piotrek Guzik, znający te okolice "jak własną kieszeń"

Cytuję fragmenty naszej korespondencji (za zgodą Piotrka):

 

Co do miejscówek, to ciekawsze z odpowiednim na to zjawisko horyzontem są tu:

 

https://drive.google.com/open?id=1OCGtemVXcuXP1wm9FftVEJUoRA_95gQs&usp=sharing

 

Na zielono są takie, gdzie jest spora szanse, że nie będzie problemu ze śniegiem i będzie można stanąć poza droga. Na niebiesko zaznaczyłem takie, gdzie trudno mi powiedzieć, czy śnieg nie utrudni rozstawienia się. Na pomarańczowo zaznaczyłem dobrą miejscówkę, do której raczej nie da się dojechać samochodem i gdzie o tej porze może być sporo śniegu.

 

Co do tej dolinki, z Jaślisk do Lipowca, to na tej trasie znajdzie się więcej miejsc, z których będzie widać tę część nieba, tyle że może być ciężko zejść z drogi. Inna sprawa, że tą drogą prawie nic nie jeździ, a już zwłaszcza zimą o 6 rano ;).

 

Świt astronomiczny będzie niestety już o 5:15, tak więc w momencie zjawiska będzie już się robiło jasno (Słońce będzie tylko 11 stopni pod horyzontem), ciągle jednak powinno być na tyle ciemno, żeby zakrywana gwiazda była całkiem nieźle widoczna.

 

Wmalowałem więc (tak z palca, nie wiem jak się dodaje warstwy do map Googla etc) linię przewidywanej granicy pasa  zakrycia na mapie Piotrka.

 

Edit: gdyby komuś mapa z linku Piotrka nie wyświetlała się tu jest inny link: https://drive.google.com/open?id=1OCGtemVXcuXP1wm9FftVEJUoRA_95gQs&usp=sharing

Najlepiej byłoby, aby "poranny desant śmiałków" rozlokował się po obu stronach tej linii - pamiętajmy, że wynik "negatywny" w pobliżu linii brzegowej ma taką samą wartość jak "pozytywny"

 

No i na deser mamy zakrycie Saturna, w wersji malowniczej... tu zapis czasu nie wydaje się konieczny - chyba, że uda się złapać któryś z księżyców.

Ja bardzo chciałbym podelektować się tym przepięknym zjawiskiem na luzie - czyli trzeba by wyczaić jakąś miejscówkę na więcej osób z odkrytym horyzontem w kierunku 140.

Bogowie Pogody - słyszycie nas???

Edytowane 24 Stycznia 2019 przez Agent Smith

[Agent Smith]

On 1/17/2019 at 6:20 PM, don Pedro said:

Ciekawy temat.Czyli jak ktoś chciałby załapać się w  pas główny to trzeba śmigać pod Presov?

Odwrotnie - trzeba jechać w stronę Stalowej Woli

[Agent Smith]

On 1/18/2019 at 11:14 AM, burza said:

Jeszcze jedna ważna rzecz - niedaleko miejsca zlotu mieszka w Króliku Polskim (14 km na N od Lipowca, wzdłuż drogi 887) bardzo doświadczony zakryciowiec - ks. Wiesław Słotwiński.

Ma on niezbędny sprzęt, w tym kamery i doświadczenie i myślę, ze możecie go odwiedzić w tej sprawie.

Jeśli jesteście zainteresowani podam kontakt telefoniczny na priv

 

Piotrek Guzik dał mi numer do księdza Wiesława, który jest także członkiem naszej forumowej społeczności - będę go jutro zagajał w tej sprawie.

Nie wiem jak z widocznością horyzontu u niego (myślę tu o wspólnej obserwacji zakrycia Saturna) ... zobaczymy.

 

Ja będę ,miał do Ciebie pytania związane z kamerami i rekorderami - zrobię to jednak, jeśli pozwolisz, w tamtym, wskazanym wcześniej przeze mnie wątku o "technologii"

Pozdrawiam!

Nikodem

[burza]

Oczywiście, jak tylko dam rade to odpowiem.

Gratuluję VTI, jeden wg pomysłu Piotra zrobiłem rok temu.

Teraz będę robił wg pomysłu Pascala.

Zapraszam na konferencje SOPiZ w kwietniu - szczegóły w wątku: 

 

[Gajowy]

Oprócz zakrycia z 2 lutego zachęcam do zasadzenia się na zakrycie, a właściwie dwa zakrycia, w nocy 3/4 lutego. Zakrywane będą kolejno gwiazdy 13.3 i 10.2 magnitudo, a dokona tego planetoida - trojańczyk jowiszowy (105808) 2000 SZ135 o jasności 19.4 mag. Zakrycia nie ma w plkach Prestona - została przewidziane przez zespół LESIA (ten, który odkrył pierścienie wokół Haumei). Ja (bazując na Gaia DR2) obliczyłem lekko inną efemerydę, ale pas niepewności tak czy siak obejmuje większość terytorium Polski. W wypadku trojańczyków niepewność położenia planetoidy jest większa niż pasa głównego, bo znajdują się one dwukrotnie dalej przez co dokładność astrometrii [ściślej: fizycznego położenia w przestrzeni] jest mniejsza. Z drugiej strony są to obiekty ciekawsze i bardziej tajemnicze od planetoid Pasa Głównego.

Podaję dane zakrycia jaśniejszej gwiazdy. Słabsza gwiazda zgaśnie dokładnie 30 minut wcześniej:

 

Edytowane 25 Stycznia 2019 przez Gajowy

[Agent Smith]

3 hours ago, burza said:

Oczywiście, jak tylko dam rade to odpowiem.

Gratuluję VTI, jeden wg pomysłu Piotra zrobiłem rok temu.

Teraz będę robił wg pomysłu Pascala.

Zapraszam na konferencje SOPiZ w kwietniu - szczegóły w wątku: 

 

Dziękuję, myślałem o tym ale trochę mi głupio...SOPiZ powstała dokładnie rok po tym, jak doznałem zaćmienia przez pewną koleżankę z klasy i zdezerterowałem z partyzanckiej ekipy "dachowych chuliganów z magnetofonem" pod dowództwem niezapomnianego Romka Fangora w nieodłącznym bereciku (dowódcy) 

Potem odłożyłem astronomię na półkę na parę dekad... i tylko koleżanki się co jakiś czas zmieniały.

Więc jako dezerterowi trochę mi głupio - tak jakoś "mineliśmy sę na styk", a teraz...jesteśmy nagle siwiejącymi i łysiejącymi "starszymi panami"...

40-lecie jest to jednak faktycznie niezły pretekst, żeby się wreszcie poznać !

PS: Przepraszam (sam siebie) za mały OT  

Edytowane 24 Stycznia 2019 przez Agent Smith

[Gajowy]

W dniu 18.01.2019 o 17:14, MateuszW napisał:

@burza dziękuję za linki, jest sporo ciekawych pomysłów.

Posiedziałem teraz trochę czasu wertując internet i znalazłem dwa ciekawe programy do synchronizacji czasu systemowego za pomoca gps podpiętego do portu com:

http://www.dxatlas.com/ToyNtp/ - to wydaje się całkiem proste do odpalenia

https://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html - tu jest bardziej skomplikowana sprawa

Spróbuję zainstalować i przetestować te rozwiązania. Jeśli będą działać, to właściwie nie trzeba będzie już nic kombinować. Wykresy dokładności są wręcz fenomenalne dla naszych potrzeb.

Jak będziesz testował, dobrze byłoby przy okazji opracować testy mierzące opóźnienia (średnie i ich stabilność), np. operacji wejścia-wyjścia portów szeregowych albo też czasu jaki upłynie od otrzymania sygnału GPS do momentu zaświecenia się diody (jeśli te czasy są w ogóle mierzalne).

 

Pzdr,

Gajowy

[MateuszW]

1 godzinę temu, Gajowy napisał:

Jak będziesz testował, dobrze byłoby przy okazji opracować testy mierzące opóźnienia (średnie i ich stabilność), np. operacji wejścia-wyjścia portów szeregowych albo też czasu jaki upłynie od otrzymania sygnału GPS do momentu zaświecenia się diody (jeśli te czasy są w ogóle mierzalne).

 

Pzdr,

Gajowy

Jeśli chodzi o diodę, to myślałem żeby ją po prostu podłączyć do wyjścia PPS bezpośrednio  Ale nie wiem, jaka jest szerokość tego impulsu i pewnie będzie za krótki, żeby kamera zobaczyła błysk. Jeśli tak, to na arduino zrobię elementarny program, który w przerwaniu od gpio odpali diodę - to będzie kilka instrukcji asemblera, a więc teoretycznie poniżej 1 us (zakładając zegar kilkanaście MHz).

Jeśli natomiast chodzi o testy synchronizacji bezpośrednio w windowsie, poprzez port szeregowy, to planuję zrobić test polegający na nagraniu kamerą sygnału diody sterowanej tym samym GPSem, który będzie synchronizował komputer. Tutaj mogę już dać ultra duży FPS w ASI, żeby złapać diodę bez pośrednictwa arduino - powinna być idealnym znacznikiem. W ten sposób jednoznacznie dowiem się, jakie jest opóźnienie lub jitter między GPSem, a czasem Windowsa.

 

Problem w tym, że jeszcze nie kupiłem nawet odbiornika, nie mam czasu na testy, a zakrycie tuż tuż...

[Agent Smith]

Panowie (i Panie) czas goni, niestety mnie przegonił i jest strasznie późno na przygotowania, w każdym razie dla tych z Was, którzy chcieliby się zabawić metodą tradycyjną i uznaną, czyli za pomocą kamery analogowej, tanim standardem jest RunCam Night Eagle 2 Pro

 

Jest to kamera do dronów, dostępna w wielu polskich sklepów (google is your friend) za ok 400 zł, są na stanie, można jeszcze zamówić na przyszły tydzień.

 

IOTA po wielu deliberacjach zamówiło partię tych kamer z nieco zmienionym firmware i sprzedaje tu (doliczając kosmiczne ceny za przesyłkę):

http://occultations.org/night-eagle-2-pro-astro-edition-ordering-page/ 

Zakładam "że te z Polskich sklepów też się nadają" bo ponoć hardware, a z nim i czułość jest taka sama.

Więcej danych:

http://occultations.org/wp/wp-content/uploads/2018/03/READ-ME-file-for-RunCam-Night-Eagle-PRO-2-Astro-Edition-v1.2.pdf

http://occultations.org/wp/wp-content/uploads/2018/03/RunCam-Night-Eagle-Astro-Camera-Review-Operating-Guidelines-and-Comments-v7.pdf

 

Druga opcja to kamery przemysłowe Samsunga, np SCB-2000, SDC-435, można kupić na aledrogo za 100-300 zł

 

Jeśli chodzi o zapis sygnału analogowego, starym klasykiem są kamery DV (na taśmę) z wejściem AV, też można upolować na A., lista (niepełna) kamerek z wejściem AV jest tutaj:

http://www.4kam.com/camcorders_with_av-in_av_input.htm

 

Druga opcja to komputer wraz z grabberem, polecany jest oficjalnie (przez IOTA) model StarTech SVID2USB23 (też bywa w polskich sklepach) ale większość tańszych grabberków też pewnie da radę.

 

Muszę lecieć....więcej po poł€dniu

 

[Gajowy]

15 godzin temu, MateuszW napisał:

Jeśli chodzi o diodę, to myślałem żeby ją po prostu podłączyć do wyjścia PPS bezpośrednio  Ale nie wiem, jaka jest szerokość tego impulsu i pewnie będzie za krótki, żeby kamera zobaczyła błysk. Jeśli tak, to na arduino zrobię elementarny program, który w przerwaniu od gpio odpali diodę - to będzie kilka instrukcji asemblera, a więc teoretycznie poniżej 1 us (zakładając zegar kilkanaście MHz).

Jeśli natomiast chodzi o testy synchronizacji bezpośrednio w windowsie, poprzez port szeregowy, to planuję zrobić test polegający na nagraniu kamerą sygnału diody sterowanej tym samym GPSem, który będzie synchronizował komputer. Tutaj mogę już dać ultra duży FPS w ASI, żeby złapać diodę bez pośrednictwa arduino - powinna być idealnym znacznikiem. W ten sposób jednoznacznie dowiem się, jakie jest opóźnienie lub jitter między GPSem, a czasem Windowsa.

 

Problem w tym, że jeszcze nie kupiłem nawet odbiornika, nie mam czasu na testy, a zakrycie tuż tuż...

Nie spiesz się, to nie jest kwestia tego jednego zakrycia przecież.

Jeśli chodzi o szerokość sygnału GPS - zgodnie z https://en.wikipedia.org/wiki/Pulse-per-second_signal ma to być < 1 s. Element GPS insertera Tomka Wężyka świeci diodą przez ok. pół sekundy, więc całkiem sporo. Nie zajmuję się elektroniką, ale zadaję sobie pytanie - jaki jest czas inercji samej diody? Tj. ile czasu mija od otrzymania sygnału do zaświecenia? Czy są to czasy pomijalne (tj. mniejsze niż powiedzmy 0.001 sek?).

 

Rozważ jeszcze sam proces synchronizacji. Moim zdaniem, poza wstępną synchronizacją przed obserwacją nie ma sensu synchronizować zegara komputera. Znacznie korzystniej jest po prostu rejestrować poprawkę co kilka minut a później interpolować ją na moment obserwacji i dodać do wyników. Unikasz manipulowaniem zegarem, skoków czasu, niepewności zachowania się samego OS, paru operacji wejścia-wyjścia itd.

 

Wracając do synchronizacji: pamiętaj, o opóźnieniu kamery, o którym pisałem. To też trzeba zmierzyć na iluś tam próbach, w różnych warunkach, by określić średnią i odchylenie standardowe.

inercja_kamery = moment_otwarcia_migawki - moment_pojawienia_sie_żądania_otwarcia_migawki
Programowo jesteś w stanie zarejestrować tylko moment_pojawienia_sie_żądania_otwarcia_migawki.

Napisałem na to program, który odczytuje liczby na monitorze. Problemem jest jednak częstotliwość odświeżania monitora, która nie pozwala zejść ponizej 0.01 sek. Mam jednak i na to pomysł. BTW, podobno jakieś narzędzie do tego jest w Maximie. Wiesz coś może więcej?

 

Pzdr,

Gajowy
 

[MateuszW]

8 godzin temu, Gajowy napisał:

Nie zajmuję się elektroniką, ale zadaję sobie pytanie - jaki jest czas inercji samej diody? Tj. ile czasu mija od otrzymania sygnału do zaświecenia? Czy są to czasy pomijalne (tj. mniejsze niż powiedzmy 0.001 sek?).

To jest dobre pytanie. Nie mogę znaleźć jednoznacznego i pewnego źródła dla tej informacji. Znalazłem jedynie, że transoptory (czyli elementy separujące sygnał elektryczny za pomocą diody i detektora) mają opóźnienia rzędu od kilku ns do kilku us, czyli jak dla nas super krótki. Jednak nie bardzo umiem to znaleźć dla zwykłych diod. Nie mam też pomysłu, jak zmierzyć ten czas (wymaga to detektora, który również będzie miał jakieś swoje opóźnienie).

9 godzin temu, Gajowy napisał:

Rozważ jeszcze sam proces synchronizacji. Moim zdaniem, poza wstępną synchronizacją przed obserwacją nie ma sensu synchronizować zegara komputera. Znacznie korzystniej jest po prostu rejestrować poprawkę co kilka minut a później interpolować ją na moment obserwacji i dodać do wyników. Unikasz manipulowaniem zegarem, skoków czasu, niepewności zachowania się samego OS, paru operacji wejścia-wyjścia itd.

No ale jedyną możliwością na rejestrowanie poprawki jest dioda, czy coś przeoczyłem? Niby to dobra metoda, ale niewygodna przy późniejszej analizie. No i co, jeśli czas różni się więcej, niż o 0,5 s?

Jeśli chodzi o skoki czasu podczas synchronizacji zegara, to te metody nie bazują na wprowadzaniu ciągłych poprawek do wartości zegara, ale subtelnie modyfikują jego częstotliwość, co właśnie zapobiega skokom. Do tego programy, o których czytam uśredniają sobie wiele pomiarów sygnału PPS, więc dokładność z czasem się poprawia. Czytam różne rzeczy, ale generalnie wydaje się, że osiągnięcie dokładności poniżej 1 ms nie jest problemem, a być może da się zejść do dziesiątków us.

9 godzin temu, Gajowy napisał:

Wracając do synchronizacji: pamiętaj, o opóźnieniu kamery, o którym pisałem. To też trzeba zmierzyć na iluś tam próbach, w różnych warunkach, by określić średnią i odchylenie standardowe.

No tylko właśnie nie wiem jak to zmierzyć  Nie wiem, jak rozgraniczyć opóźnienie kamery od błędów mojego procesu synchronizacji. No i jeszcze pojawia się ważniejsze pytanie - na jakiej zasadzie np FireCapture nadaje znacznik czasowy klatce. Czy decyduje o tym moment wysłania żądania otwarcia migawki, moment odebrania klatki przez program, czy może inny? A może kamera robi zdjęcia bez niczyjego rozkazu, tj sama odpala migawkę z określoną częstotliwością? Wówczas program mógłby chyba tylko bazować na czasie odczytu klatki.

 

Zastanawia mnie również, co się dzieje, gdy kamera gubi ramki lub występują wahania fps. Czy klatki są naświetlane wciąż w równych odstępach, a szwankuje jedynie przesył (czyli czegoś brakuje, ale interwał pozostaje), czy może odczyt matrycy też ulega wahaniom?

9 godzin temu, Gajowy napisał:

Napisałem na to program, który odczytuje liczby na monitorze. Problemem jest jednak częstotliwość odświeżania monitora, która nie pozwala zejść ponizej 0.01 sek. Mam jednak i na to pomysł. BTW, podobno jakieś narzędzie do tego jest w Maximie. Wiesz coś może więcej?

Częstotliwość odświeżania? A opóźnienie monitora?  A opóźnienie karty graficznej i procesora, który zleca jej zadanie? Tu również jest wiele niewiadomych. A opóźnienie monitora potrafi wynosić do kilkudziesięciu ms (nie mówiąc o czasie zaświecania i gaśnięcia piksela).

Jeśli chodzi o maxima, to istotnie coś jest, ale nie do końca wiem i rozumiem, co  Ale nie sądzę, żeby to było super dokładne, raczej było pomyślane dla wolnych ccd. Ale zerknę w wolnym czasie.

[Gajowy]

16 godzin temu, MateuszW napisał:

No ale jedyną możliwością na rejestrowanie poprawki jest dioda, czy coś przeoczyłem? Niby to dobra metoda, ale niewygodna przy późniejszej analizie. No i co, jeśli czas różni się więcej, niż o 0,5 s?

Jeśli ustalimy, że dioda zaświeca się w czasie krótszym niż 0.001 sek, to byłby to idealny wskaźnik. Przyszłą analizę możnaby zautomatyzować wykrywając pierwszą ramkę z zaświeconą diodą. W sumie nic trudnego. BTW, myślę, że może nawet nie trzeba jakoś specjalnie skupiać światłą z diody. Może wystarczy umieścić ją przy wlocie tuby? Światło powinno być na tyle wyraźne, że ramka z diodą będzie wyraźnie rozświetlona. Gorzej, jeśli ten diodowy błysk będzie trwał zbyt długo i zepsuje zbyt dużą liczbę ramek.
W proponowanej przeze mnie metodzie rejestracji popraki zakładam wstępną synchronizację zegara przed rozpoczęciem obserwacji. Wówczas 0.5 sek możliwe jest jedynie w wypadku skranie nieskorelowanego zegara. Tę wstępną synchronizacje można zrobić np. protokołem NTP.

Moje badania wskazują, że przy dobrym dostępie do Internetu, za pomocą poprawnie zaimplementowanego protokołu NTP można uzyskać dokładność pomiaru czasu rzędu 0.001 sek.

 

Cytat

Jeśli chodzi o skoki czasu podczas synchronizacji zegara, to te metody nie bazują na wprowadzaniu ciągłych poprawek do wartości zegara, ale subtelnie modyfikują jego częstotliwość, co właśnie zapobiega skokom. Do tego programy, o których czytam uśredniają sobie wiele pomiarów sygnału PPS, więc dokładność z czasem się poprawia. Czytam różne rzeczy, ale generalnie wydaje się, że osiągnięcie dokładności poniżej 1 ms nie jest problemem, a być może da się zejść do dziesiątków us.

Metoda zmiany częstotliwości działa chyba w systemach Linuxowych, w Windows masz przestawienie skokowe. Jedno i drugie podejscie ma wady - przy zwiększaniu częstotliwości de facto nie masz synchronizacji i nie wiesz jaki jest prawdziwy czas w momencie pomiaru, przy skokach - może się okazać, że dwie kolejne ramki robione z czasem 0.00001 sek będą opisany jako wykonane np. 0.2 sekundy po sobie.

 

Cytat

No tylko właśnie nie wiem jak to zmierzyć  Nie wiem, jak rozgraniczyć opóźnienie kamery od błędów mojego procesu synchronizacji. No i jeszcze pojawia się ważniejsze pytanie - na jakiej zasadzie np FireCapture nadaje znacznik czasowy klatce. Czy decyduje o tym moment wysłania żądania otwarcia migawki, moment odebrania klatki przez program, czy może inny? A może kamera robi zdjęcia bez niczyjego rozkazu, tj sama odpala migawkę z określoną częstotliwością? Wówczas program mógłby chyba tylko bazować na czasie odczytu klatki.

FireCapture - z tego co wyciągnęliśmy swego czasu na jakieś grupie FireCapture rejestruje moment początku ramki. Ponieważ jest to software uniwersalny, bazujący na prostych, amatorskich kamerach z nieskomplikowanym softem, cały proces wyglada tak [wykonanie zdjęcia lub zdjęć poklatkowych]:

1. Program wysyłą polecenie wykonania zdjęcia do kamery

2. Program rejestruje czas PC

3. Kamera odbiera polecenie wykonania zdjęcia

4. Kamera otwiera migawkę

5. Po czasie ekspozycji (kontrolowanym przez układ kamery!) kamera zamyka migawkę

6. Kamera kopiuje pixele do swojej wewnętrznej pamięci

7. Kamera ustawia swój znacznik gotowości przekazania zdjęcia

8. Program bada znacznik kamery i jeśli kamera jest gotowa - wysyła polecenie odczytania zdjęcia z pamięci kamery do pamięci PCta

9. Program dodaje do odczytanego obrazu z kamery znacznik czasu.

10. Program zapisuje obraz ze znacznikiem czasu na dysk.

11. GO TO 1.

Profesjonalne kamery mają możliwość odczytywania GPSa i dodawania znacznika czasu na poziomie oprogramowania wewnętrznego kamery.

Proces przebiega lekko inaczej gdy kamera działa w trybie video.

 

 

Cytat

 

Zastanawia mnie również, co się dzieje, gdy kamera gubi ramki lub występują wahania fps. Czy klatki są naświetlane wciąż w równych odstępach, a szwankuje jedynie przesył (czyli czegoś brakuje, ale interwał pozostaje), czy może odczyt matrycy też ulega wahaniom?

Dociekałem swego czasu, które ramki są tracone w kamerach ASI - dopóki nie opróżnisz buforu, kolejna ramka nie jest kopiowana do bufora kamery:
https://bbs.astronomy-imaging-camera.com/viewtopic.php?f=21&amp;t=7453&amp;p=15006&amp;hilit=Gajowy#p15006

EDIT: W buforze może znaleźć się więcej niż jedna ramka, co trochę komplikuje sytuację. W ASI SDK jest jednak funkcja, która umożliwia odczyt liczby utraconych ramek.

BTW, zachęcam do własnych eksperymentów z SDK ASI - nad FireCapture nie masz jednak kontroli i nie wiesz do końca co siedzi w środku i jak np. obsługuje kwestię traconych ramek.

 

BTW2, Osobiście korzystam z własnego programu do rejestracji obrazu z kamery (Tapir), który dodatkowo wykorzystuje najbardziej precyzyjny z możliwych odczyt zegara komputera (dokładność wg dokumentacji wykorzystywanych funkcji <100 ns ) i ma parę fajnych cech niedostępnych w FC i innych softach tego typu.

 

Cytat

Częstotliwość odświeżania? A opóźnienie monitora?  A opóźnienie karty graficznej i procesora, który zleca jej zadanie? Tu również jest wiele niewiadomych. A opóźnienie monitora potrafi wynosić do kilkudziesięciu ms (nie mówiąc o czasie zaświecania i gaśnięcia piksela).

No, to jest temat w który kiedyś się mocną zagłębię, chyba, że...

 

Cytat

Jeśli chodzi o maxima, to istotnie coś jest, ale nie do końca wiem i rozumiem, co  Ale nie sądzę, żeby to było super dokładne, raczej było pomyślane dla wolnych ccd. Ale zerknę w wolnym czasie.

...sprawdzisz tego Maxima, zrozumiesz i opiszesz :).

 

Pzdr,

Gajowy

 

P.S. Jednym z pomysłów na test jakości synchronizacji jest wykorzystanie... sztucznych satelitów i rejestracja ich ruchu wraz ze znacznikami czasu, a następnie porówanie z efemerydami.

Edytowane 26 Stycznia 2019 przez Gajowy

[MateuszW]

8 minut temu, Gajowy napisał:

Może wystarczy umieścić ją przy wlocie tuby? Światło powinno być na tyle wyraźne, że ramka z diodą będzie wyraźnie rozświetlona. Gorzej, jeśli ten diodowy błysk będzie trwał zbyt długo i zepsuje zbyt dużą liczbę ramek.

No ja właśnie o czymś takim myślałem pierwotnie. Ale zrobić to tak, żeby zarejestrować kilka błysków przed zjawiskiem i wyłączyć diodę na czas jego trwania.

9 minut temu, Gajowy napisał:

Proces przebiega lekko inaczej gdy kamera działa w trybie video.

No właśnie, a nas interesuje raczej tryb wideo? Choć w sumie nie wiem, czy wybór zapisu jako zdjęcia wpływa na tryb pracy kamery?

Wydaje mi się, że taka metoda, jaką opisałeś, wnosiłaby zbyt duże straty czasu, tj te wszystkie oczekiwania zamiast wykonywania maksymalnej ilości klatek jaką się da.

Spróbuję jeszcze dla zabawy poanalizować ramki USB w WireShark  Niedawno sobie uświadomiłem, że jest taka możliwość. Ze wstępnych oględzin wygląda na to, że ramki od komputera do kamery wysyłane są bardzo rzadko i raczej nie decydują o otwarciu migawki. Ale na razie nawet nie mam pewności, że patrzyłem na właściwe urządzenie

13 minut temu, Gajowy napisał:

Profesjonalne kamery mają możliwość odczytywania GPSa i dodawania znacznika czasu na poziomie oprogramowania wewnętrznego kamery.

Jest taka jedna QHY. Nie znajdzie się jakaś przemysłowa może trochę taniej?

14 minut temu, Gajowy napisał:

Dociekałem swego czasu, które ramki są tracone w kamerach ASI - dopóki nie opróżnisz buforu, kolejna ramka nie jest kopiowana do bufora kamery:

Hmm, a jak to się ma do kwestii tego magicznego bufora w nowych wersjach asi, który zapobiega ampglow? Skoro w każdej kamerze jest bufor na jedną klatkę, to jakim prawem ten amp glow się pojawia? Zakładałem, że dane są przesyłane bezpośrednio z matrycy do kompa, co by tłumaczyło ampglow na wolniejszym połączeniu. Jeśli jest bufor to nie widzę jak to jest możliwe.