Obserwacje zakryć gwiazd przez planetoidy

Gajowy · 15 Stycznia 2016

Czy jest tu ktoś kto obserwuje zakrycia gwiazd przez planetoidy?

Obserwowałem to we latach wczesnych latach 90-tych ub. wieku, ruskim refraktorem 70mm i plastikowym zegarkiem ze stoperem, też ruskim, kupionym na bazarze. Teraz chciałbym wrócić do obserwacji. Chętnie pogadałbym z kimś, to praktykuje to na obecnie dostępnym sprzęcie i korzysta z takich nowinek technicznych jak rejestrowanie zjawiska na kamerze CCD i korzystanie ze służby czasu GPS (+ te kosmiczne insertery!). Trochę poczytałem na ten temat, no ale diabeł tkwi zapewne w szczegółach.

Pozdrawiam,

Gajowy

r.ziomber · 15 Stycznia 2016

Niestety zakryc nie obserwowalem, proponuje tylko zamiast insertera na tor analogowy, uzyc normalnej, szybkiej kamery planetarnej. Dokladny czas zawarty bedzie w naglowku FITS.

W kwestii synchronizacji czasu z GPS moglbym pomoc, ale pod systemem Linuks. Mozna do tego uzyc gpsd i ntpd.

Edytowane 15 Stycznia 2016 przez r.ziomber

Tayson · 15 Stycznia 2016

Prowadziłem obserwacje zjawisk zakryciowych. 99-04r.

Mam cały sprzęt analogowy.

Tomasz Wężyk (Piotrków Trybunalski) niedawno stworzył inserter który synchronizuje się z gps. Podłącza się go do kompa przez jakiegoś video grabber'a ze średniej półki. Obecne prędkości komputerów i przepustowość usb pozwala praktycznie bezstratnie rejestrować obraz 25-30fps. Taka prędkość jest zadowalajac przy odczycie monentu.

Gajowy · 15 Stycznia 2016

Niestety zakryc nie obserwowalem, proponuje tylko zamiast insertera na tor analogowy, uzyc normalnej, szybkiej kamery planetarnej. Dokladny czas zawarty bedzie w naglowku FITS.

W kwestii synchronizacji czasu z GPS moglbym pomoc, ale pod systemem Linuks. Mozna do tego uzyc gpsd i ntpd.

Możesz podać jakiś link lub nazwę takiej przykładowej kamery? Taka kamera na bieżąco odczytuje czas z GPS-a i dodaje do każdej klatki?

Pzdr,

Gajowy

r.ziomber · 15 Stycznia 2016

Mam na mysli kamery Imaging Source, ASI, QHY, itp, tylko trzeba poszukac modeli o wyzszej czulosci.

GPS podlaczasz do komputera konwerterem USB-TTL i dzieki niemu synchronizujesz zegar systemowy.

Program obslugujacy kamere zapisuje czas w naglowku FITS. Pytanie tylko, z jaka rozdzielczoscia podawane sa te dane? Gorzej, jesli programy podaja tylko z dokladnoscia do sekundy...

Polecam odbiornik GPS VK2828U7G5LF.

http://www.aliexpress.com/item/Free-shipping-VK2828U7G5LF-GPS-Module-with-Antenna-TTL-1-10Hz-with-FLASH-Flight-Control-Model-Aircraft/32593845903.html

Szybko lapie fixa (moze dzieki obsludze GLONASS) i jest tani.

Przykladowy konwerter (choc nie polecam akurat z tego linku, bo nie gwarantuje, ze chip FTDI jest oryginalny).

http://www.aliexpress.com/item/Free-shipping-1pcs-FT232RL-FTDI-USB-3-3V-5-5V-to-TTL-Serial-Adapter-Module-for/32294938771.html

Edytowane 16 Stycznia 2016 przez r.ziomber

Gajowy · 15 Stycznia 2016

Prowadziłem obserwacje zjawisk zakryciowych. 99-04r.

Mam cały sprzęt analogowy.

Tomasz Wężyk (Piotrków Trybunalski) niedawno stworzył inserter który synchronizuje się z gps. Podłącza się go do kompa przez jakiegoś video grabber'a ze średniej półki. Obecne prędkości komputerów i przepustowość usb pozwala praktycznie bezstratnie rejestrować obraz 25-30fps. Taka prędkość jest zadowalajac przy odczycie monentu.

Widziałem, że łowcy zakryć często używają kamer przemysłowych. Gdybym na taką się zdecydował, to rozumiem, że te 30 fps to minimum. Na allegro sporo tego, nawet nie za drogie, ale... niektóre opisy wymieniają pół strony różnych funkcji-ulepszaczy obrazu i nawet nie wiadomo czy da się je powyłączać. I ta myląca czułość 0 lx, bo mają doświetlenie promieniami IR .

Powiedzmy, że znamy czułość kamery CCD, powiedzmy 0,003 lx i czas naświetlenia pojedynczej klatki 1/30 sek (przy fps 30/s, choć nie jestem pewny, czy migawka otwiera się naraz cała). Do tego średnicę obiektywu teleskopu, np. 8". Czy na podstawie tych danych da się określić jakie najsłabsze gwiazdy zostaną uchwycone?

Gajowy · 15 Stycznia 2016

Mam na mysli kamery Imaging Source, ASI, QHY, itp, tylko trzeba poszukac modeli o wyzszej czulosci.

GPS podlaczasz do komputera konwerterem UART-USB i dzieki niemu synchronizujesz zegar systemowy.

Program obslugujacy kamere zapisuje czas w naglowku FITS. Pytanie tylko, z jaka rozdzielczoscia podawane sa te dane? Gorzej, jesli programy podaja tylko z dokladnoscia do sekundy...

Z tego co czytam, FITS to standard astronomiczny, więc jeśli kamera jest do zastosowań astronomicznych, to program powinien pobierać czas w ułamkach sekund. Nawet zresztą gdyby było w sekundach pełnych, nie byłoby problemu - 30 kolejnych klatek miałoby ten sam czas więc każda kolejna klatka to +1/30 sek.

Tutaj nasuwa mi się jedynie wątpliwość związana z lagami systemu operacyjnego. Czy różne nieprzewidziane działania w tle (aktualizacja Windows , nie zakłócą synchronizacji zegara albo przekazywania danych do kamery?

Dzięki za nazwy kamer, poczytam na ich temat.

Pzdr,

G.

Edytowane 15 Stycznia 2016 przez Gajowy

Tayson · 16 Stycznia 2016

W 2001 przy 0,001lux w 8" wydać przy jasnej krawędź ksiazyca gwiazdy 8 mag. Księżyc kolo pełni. Kiedyś innych niż przemysłowych nie było. Teraz masz większy wybór.

Jakby coś to na PW.

Pozdr.

T.

Gajowy · 9 Lutego 2016

Niestety zakryc nie obserwowalem, proponuje tylko zamiast insertera na tor analogowy, uzyc normalnej, szybkiej kamery planetarnej. Dokladny czas zawarty bedzie w naglowku FITS.

W kwestii synchronizacji czasu z GPS moglbym pomoc, ale pod systemem Linuks. Mozna do tego uzyc gpsd i ntpd.

Odświeżam temat. Rozumiem, że kamera sama z siebie nie dodaje nagłówka FITS i robi to dopiero oprogramowanie, które odbiera obraz i zapisuje go na dysku, tak?

Czy nie wystarczy zatem jakieś oprogramowanie pod Windows które reguluje czas systemowy z odbiornika GPS? Np. coś takiego. Pozostaje kwestia dokładności.

Pzdr,

Gajowy

MateuszW · 9 Lutego 2016

Ja również myślałem o takim rejestrowaniu kamerką planetarną. FireCapture zapisuje czas startu i końca nagrania z dokładnością do 1 ms. Można też dołożyć timestamp na obraz, który jest nawet z większą dokładnością (pozostaje pytanie, skąd ta dokładność?). Zegar systemowy Windowsa ma rozdzielczość chyba 1 ms (w każdym razie tyle można z niego odczytać). Protokół NMEA do GPS również przekazuje co do 1 ms. Czyli teoretycznie wszystko powinno hulać. Ten programik, który linkujesz być może wystarczy do synchronizacji czasu w PC. Jeśli nie, to można dość prosto napisać program, który odczyta czas z GPS i ustawi go w PC (funkcja SetSystemTime w C++).

Zastanawia mnie tylko jedno. Niby GPS zwraca czas co do 1 ms, ale przecież wysłanie jednej ramki danych po RS232, która ma kilka bajtów zajmuje już kilka ms. Tak więc nie wiadomo, jaki dokładnie czas dostajemy. R.ziomber, co o tym sądzisz? Aha, no chyba, że to pracuje na większej prędkości, niż 9600

Gajowy · 9 Lutego 2016

Ja również myślałem o takim rejestrowaniu kamerką planetarną. FireCapture zapisuje czas startu i końca nagrania z dokładnością do 1 ms. Można też dołożyć timestamp na obraz, który jest nawet z większą dokładnością (pozostaje pytanie, skąd ta dokładność?). Zegar systemowy Windowsa ma rozdzielczość chyba 1 ms (w każdym razie tyle można z niego odczytać). Protokół NMEA do GPS również przekazuje co do 1 ms. Czyli teoretycznie wszystko powinno hulać. Ten programik, który linkujesz być może wystarczy do synchronizacji czasu w PC. Jeśli nie, to można dość prosto napisać program, który odczyta czas z GPS i ustawi go w PC (funkcja SetSystemTime w C++).

Zastanawia mnie tylko jedno. Niby GPS zwraca czas co do 1 ms, ale przecież wysłanie jednej ramki danych po RS232, która ma kilka bajtów zajmuje już kilka ms. Tak więc nie wiadomo, jaki dokładnie czas dostajemy. R.ziomber, co o tym sądzisz? Aha, no chyba, że to pracuje na większej prędkości, niż 9600

Trafiłem na ciekawy artykuł. Są 2 sposoby ustawiania czasu za pomocą GPSa:

1. Odczytujesz po RS232 ramkę NMEA, która zawiera w sobie informacje o położeniu i czasie. To faktycznie "powolna metoda".

2. Odczytujesz sygnał PPS, który jest generowany przez GPS receiver co 1 sekundę z bardzo dużą dokładnością. Sygnał pojawia się na jednym z pinów RS232, który poprzez UART generuje przerwanie w systemie operacyjnym. Program obsługujący to przerwanie powinien wówczas zsynchronizować czas systemu operacyjnego. To chyba dzieje się w czasie mikrosekund. W ciągu tej 1 sekundy miedzy sygnałami skazani jesteśmy na zegar wewnętrzny komputera. Oczywicie wszystko musi iść po standardowym starym RS232, USB się do tego nie nadaje .

Pzdr,

Gajowy

MateuszW · 9 Lutego 2016

Czyli jak rozumiem sygnał na PPS pojawia się w czasie "pełnej sekundy"? Konwertery np FTDI mają wszystkie piny sterujące, więc ten sygnał powinien działać prawidłowo. Wydaje mi się, że więcej, jak jednak synchoronizacja na kilka minut/godzin i tak nie jest potrzebna. Zegar systemu to zapewne jakiś po prostu kwarc, który ma jakiś błąd i spieszy lub opóźnia, ale to się nie uwidoczni na takim krótkim czasie. Nie powinno być krótkookresowych oscylacji, a tylko jakiś stały "mnożnik".

r.ziomber · 9 Lutego 2016

Aha, no chyba, że to pracuje na większej prędkości, niż 9600

Widze, ze mozna ustawic wieksze baud rate. Str 16:

http://github.com/CainZ/V.KEL-GPS/blob/master/VK2828U7G5LF%20Data%20Sheet%2020150902.pdf

Kiedys przegladalem artykul, ktory bardzo polecam:

Raspberry Pi GPS jako zegar czasu rzeczywistego

W ogole kurs Raspberry Pi moze okazac sie przydatny dla obserwatoriobudowniczych:

http://www.mt.com.pl/raspberry-pi-gps-jako-zegar-czasu-rzeczywistego

Przy okazji Using android phone as gps sensor for linux gpsd (with ShareGPS android app)

Oczywiscie Bluetooth szkodzi i jeszcze bardziej zwieksza lag w komunikacji.

Edytowane 9 Lutego 2016 przez r.ziomber

Gajowy · 9 Lutego 2016

Czyli jak rozumiem sygnał na PPS pojawia się w czasie "pełnej sekundy"? Konwertery np FTDI mają wszystkie piny sterujące, więc ten sygnał powinien działać prawidłowo. Wydaje mi się, że więcej, jak jednak synchoronizacja na kilka minut/godzin i tak nie jest potrzebna. Zegar systemu to zapewne jakiś po prostu kwarc, który ma jakiś błąd i spieszy lub opóźnia, ale to się nie uwidoczni na takim krótkim czasie. Nie powinno być krótkookresowych oscylacji, a tylko jakiś stały "mnożnik".

PPS pojawia się na początku każdej sekundy i jest zsynchronizowany z czasem atomowym. Jakiś mini program musiałaby po prostu siedzieć w pamięci, reagować na przerwanie i ustawiać czas. Nie potrafię czegoś takiego napisać od ręki, choć sądzę, ze to musi być proste .

A częstotliwość konieczności wykonywania synchronizacji trzeba by chyba dla każdego PCta sprawdzić oddzielnie. Nie mam pojęcia jaki wpływa na zegar może mieć np. temperatura pracy.

Edit: tutaj przykład odbiornika GPS, który podaje sygnał PPS (nie wszystkie podają):

http://allegro.pl/gtpa010-fgpmmopa6c-odbiornik-gps-i5962010607.html

Pzdr,

Gajowy

Edytowane 9 Lutego 2016 przez Gajowy

r.ziomber · 9 Lutego 2016

Wspomniany wczesniej VK2828U7G5LF za 7 dolarow rowniez obsluguje PPS.
http://github.com/CainZ/V.KEL-GPS/blob/master/VK2828U7G5LF%20Data%20Sheet%2020150902.pdf
http://www.dfrobot.com/wiki/index.php?title=GPS_Module_With_Enclosure_%28SKU:TEL0094%29

Zupelnie OT. Dedykowane moduly GPS do teleskopow sa bardzo drogie. Przegladam PDFy z protokolami komunikacyjnymi.

Czystych danych NMEA montaze raczej nie przyjmuja, ale Arduino moze odczytac dane z GPS i ustawic je w pilocie poprzez komunikat zgodny z protokolem producenta.

Celestron i tozsamy protokol SkyWatchera (str 4):

http://www.celestron.com/media/795779/1154108406_nexstarcommprot.pdf

Meade (str 14):

http://www.meade.com/support/TelescopeProtocol_2010-10.pdf

Dzieki temu mozna dokladnie ustawic czas i lokalizacje w montazu

MateuszW · 9 Lutego 2016

Zupelnie OT. Dedykowane moduly GPS do teleskopow sa bardzo drogie. Przegladam PDFy z protokolami komunikacyjnymi.

Czystych danych NMEA montaze raczej nie przyjmuja, ale Arduino moze odczytac dane z GPS i ustawic je w pilocie poprzez komunikat zgodny z protokolem producenta.

Celestron i tozsamy protokol SkyWatchera (str 4):

http://www.celestron.com/media/795779/1154108406_nexstarcommprot.pdf

Meade (str 14):

http://www.meade.com/support/TelescopeProtocol_2010-10.pdf

Dzieki temu mozna dokladnie ustawic czas i lokalizacje w montazu

Swego czasu próbowałem temat rozgryźć i jeśli chodzi o SW, to nie jest to takie proste. Już nie pamiętam wszystkiego, ale mniej więcej. GPSy SW obsługują dwa protokoły: NMEA do komunikacji z PC i jakiś "binary" do komunikacji z pilotem. Opis tego "binary" swego czasu znalazłem w czeluściach internetu i gdzieś go mam na dysku. Do GPS w pilocie mamy dostęp z poziomu menu chyba utilities oraz na początku, przy uruchamianiu pilota. W menu nie ma problemu - pilot rozpoznaje komendy w tym protokole binary i jest git (napisałem taki "symulator" na PC). Ale już na początku, przy inicjalizacji, czyli wtedy, gdy gps jest najbardziej potrzebny, to już niestety nie chce działać. Pilot wysyła jakiś bajt i zapewne oczekuje na odpowiedź, ale ten bajt ma się nijak do protokołu. W starych wersjach firmware tego nie było i działało normalnie. W nowych coś zmienili i już nie działa. Tak więc chyba jedyną opcją na zmuszenie tego do działania jest zakup oryginalnego gpsa i podpatrzenie, co też on wysyła do pilota.

Można też użyć funkcji Set Location i Set Time, które służą do ustawiania tych parametrów z PC. Problem jest tylko taki, że w tym wypadku należy dane wysłać w momencie, gdy wyświetlany jest ekran z ustawieniem czasu podczas inicjalizacji, jeśli zrobimy to w innym momencie inicjalizacji, to dane zostaną zignorowane (czemu? nie mam pojęcia). Po zakończeniu inicjalizacji działa to już normalnie, w dowolnym momencie. Poza tym, gdy używamy tych komend PC, to pilot i tak pyta się nas o datę, czas i lokalizację, co jest znaczną wadą w stosunku do prawdziwego gpsa, dzięki któremu pozbywamy się tych ekranów.

Miałem właśnie w planie zrobienie takiego małego modułu do tłumaczenia komend dla pilota, ale temat zarzuciłem. Poza licznymi problemami, które wypisałem, jest jeszcze coś. Gdy używamy EQMod, to możemy gps podłączyć do pc i użyć go w sterowniku bez żadnych przeróbek. Po prostu działa.

pieg · 10 Lutego 2016

Swojego czasu rozmawiałem z nieodżałowanym Pawłem Maksymem o tym temacie.

Wniosek był jeden, lepiej używać analogów (dziś już pewnie też cyfrówek) i "wstrzykiwania" sygnału z gps do obrazu.

Jeżeli prowadzimy rejestracje obrazu i jednocześnie obsługę służby czasu jednym procesorem mogą pojawić się teoretycznie błędy czasu spowodowane

zmiennym obciążeniem procesora itp. Zazwyczaj to nie problem bo te niedokładności są pomijalne, jednak w zakryciach to te niedokładności mogą decydować o wynikach.

pozdrawiam

Edytowane 10 Lutego 2016 przez pieg

MateuszW · 10 Lutego 2016

Swojego czasu rozmawiałem z nieodżałowanym Pawłem Maksymem o tym temacie.

Wniosek był jeden, lepiej używać analogów (dziś już pewnie też cyfrówek) i "wstrzykiwania" sygnału z gps do obrazu.

Jeżeli prowadzimy rejestracje obrazu i jednocześnie obsługę służby czasu jednym procesorem mogą pojawić się teoretycznie błędy czasu spowodowane

zmiennym obciążeniem procesora itp. Zazwyczaj to nie problem bo te niedokładności są pomijalne, jednak w zakryciach to te niedokładności mogą decydować o wynikach.

Hmm. FireCapture z tego, co zauważyłem dość dobrze "zawłaszcza" sobie procesor i dba o płynność nagrania. Gdy próbuję robić równocześnie coś, co obciąża procesor, to ten inny program zaczyna się ciąć, a FireCapture działa nadal niewzruszony. Do tego obecnie procesory są wielowątkowe (co najmniej 2), więc istnieje możliwość faktycznie równoczesnej synchronizacji czasu i rejestracji. Na pewno jakieś opóźnienia są, ale dla komputera 1 ms to wieczność i myślę, że z taką dokładnością powinien dać radę. Chyba nic innego nie rozstrzygnie sprawy, niż testy Tylko jak to testować?

r.ziomber · 11 Lutego 2016

Tylko jak to testować?

Nagrywac roznymi setupami to samo zjawisko i porownac zarejestrowane momenty?

Można też użyć funkcji Set Location i Set Time, które służą do ustawiania tych parametrów z PC. Problem jest tylko taki, że w tym wypadku należy dane wysłać w momencie, gdy wyświetlany jest ekran z ustawieniem czasu podczas inicjalizacji, jeśli zrobimy to w innym momencie inicjalizacji, to dane zostaną zignorowane (czemu? nie mam pojęcia). Po zakończeniu inicjalizacji działa to już normalnie, w dowolnym momencie. Poza tym, gdy używamy tych komend PC, to pilot i tak pyta się nas o datę, czas i lokalizację, co jest znaczną wadą w stosunku do prawdziwego gpsa, dzięki któremu pozbywamy się tych ekranów.

No wlasnie chcialem uzyc polecen z protokolu do komunikacji z PC.

Str 4: http://www.celestron.com/media/795779/1154108406_nexstarcommprot.pdf