Skomputeryzowany astrograf - czyli jak dokonać niemożliwego

PostGregory | 16 Cze 2006, 15:54

Koncepcja budowy Robofocusa do MTO jest jak najbardziej ciekawa. :) Być może w niedługim czasie wezmę pod rozwagę i ten element, który w dość znaczny sposób powinien usprawnić etap ustawiania ostrości. :)

Pozdrawiam,
Gregory
Gregory
 

PostGregory | 18 Cze 2006, 03:38

Dziękuję Leszkowi Jędrzejewskiemu za nadesłanie nowych wyklejeń do procesora sygnału i Astropilota. :) To jest osobiście dla mnie ogromna i bardzo miła niespodzianka. :D Na dniach zabieram się do zmiany wizerunku w/w. elementów. Jednak... nie ma to jak dbałość o każdy najsubtelniejszy nawet detal finalnego dzieła, a wygląd jak wiemy, nie pozostaje bez znaczenia. Nowe wyklejenia, dzięki temu że zostały wykonane na folii, odporne są na czynniki zewnętrzne, np. wilgoć, dzięki czemu z pewnością zachowają większą trwałość. :)

W niedługim czasie pojawi się kolejna wersja recenzji, zawierająca informacje o zaktualizowanej wersji procesora sygnału, współpracującej z komputerem PC dzięki dołączonemu m.in. oprogramowaniu. :)

Pozdrawiam,
Gregory
Gregory
 

Postleszekjed | 18 Cze 2006, 13:37

Mam nadzieję, że nowe atrapy na PS i AstroPilot-a przejdą pomyślnie testy praktyczne. Do tej pory nie przywiązywałem do tego szczegółu konstrukcji większej uwagi bo nie miał wpływu na pracę urządzenia choć miałem świadomość, że i na to kiedyś musi przyjść pora. Przesłane Grzegorzowi do testów atrapy są całkowicie plastykowe i jak twierdzi producent, wodoodporne co jest istotne w czasie 'mokrych' nocy i zimą. Pierwsze stosowane atrapy były laminowane ale drukowane na drukarce atramentowej co powodowało, że z czasem a szczególnie pod wpływem wody atrament rozmywał się. Ostatnio używałem laminowanych wydruków z drukarki laserowej więc rysunek był bardziej odporny na wodę ale ciągle był to laminowany papier z tendencją do rozwarstwiania się. Taraz jest to folia plastykowa - mam nadzieję, że pozbawiona poprzednich wad.

Na razie pracuję nad wbudowaniem do procesora sygnału funkcjonalności guide ale jak zakończę tą pracę to trzeba będzie pomyśleć o motofocus-ie do MTO. W zasadzie trzeba jedynie przemysleć sprawę przeniesienia napędu z silnika na pierścień regulacyjny MTO bo zarówno pilot jak i oprogramowanie do niego są w zasadzie gotowe do użycia.
L.J.
 
Posty: 369
Rejestracja: 28 Lip 2005, 12:01

PostGregory | 18 Cze 2006, 15:22

Wydaje mi się że sposób zamocowania silnika krokowego i przeniesienia napędu na pierścień regulacyjny w MTO nie powinny stanowić problemu. Można wykonać to podobnie, jak zrobił to Dominik za pomocą paska napędowego. Robofocus może zostać na sztywno zamocowany do korpusu MTO wykorzystując jedno zwolnione gniazdo statywowe. Rolę szukacza spełnia doskonale regulowany guider, a ponadto jest przecież dokładne GoTo. :)

Pozdrawiam,
Gregory
Gregory
 

PostAdam Tomaszewski | 21 Cze 2006, 14:05

Czy Pan Leszek ma nadal tego samego maila, którego miał?
SCT 11", Maksutov SW 4", Losmandy G11, EQ3-2, Point Grey Blackfly z IMX249, Canon EOS 5D mark II mod, Canon EOS 40D, Canon EOS 30D, C85/1.8 USM, Tamron SP 90/2.8, Tokina 28-70/2.8, Canon 70-200/2.8L, Canon 17-40 L, kupa filtrów i inne.
Awatar użytkownika
 
Posty: 586
Rejestracja: 04 Sie 2005, 13:08
Miejscowość: Poznań

PostJanusz_P. | 21 Cze 2006, 17:07

Gregory, nie polecam takiego rozwiązania bo pasek obciąży niesymetrycznie gwint regulacyjny (ciągnie go w jedną stronę) i zepsuję misterną kolimację MTO :shock: , chyba żeby z drugiej strony dać drugi pasek z pustą rolką napinającą w miejsce rolki na osi silnika jako zrównoważenie sił wywieranych na korpus MTO 8)
Astropozdrówko Janusz P.

Fujinon 10x50, SCT 6 podręczny, SCT-14" HyperStar, EQ-6, Coronado 60, EOS-6D-mod i takie tam szkiełka do niego od 8 do 4000 mm plus lasery RGB do 2 W :-)
Awatar użytkownika
Założyciel i Patron Forum
 
Posty: 18278
Rejestracja: 12 Kwi 2005, 19:17
Miejscowość: 15 km na południe od Krakowa

PostGregory | 21 Cze 2006, 22:46

Tak jak piszesz Januszu mogłoby się zapewne stać gdyby zauważalny był w miejscu pierscienia regulacyjnego pewien luz. Poczyniłem próby z tym związane i nie zauważyłem odchyłki w związku z kolimacja, obraz nie uległ zmianie, tak że sposób ten może się sprawdzić w praktyce. Nawet bez konieczności stosowania dodatkowego paska i rolki napinającej. To jest pierwsza z możliwych do wykorzystania koncepcji, być może uda się rozwiązać w przyszłości to jeszcze inaczej, a jak narazie ostrość ustawiam całkowicie manualnie. ;-)

Pozdrawiam,
Gregory
Gregory
 

PostJanusz_P. | 22 Cze 2006, 09:38

Ten luz normalnie kasuje smar będą y w tym wielowchodowym gwincie regulacyjnym, pod stałym naciskiem paska smar się przemieści po kilku dniach w jedną stronę i obudowa się zdecentralizuje co napewno wpłynie na kolimację systemu.
Zapytaj Domka, miał już podobne problemy z obiektywem Nikona :roll:
Astropozdrówko Janusz P.

Fujinon 10x50, SCT 6 podręczny, SCT-14" HyperStar, EQ-6, Coronado 60, EOS-6D-mod i takie tam szkiełka do niego od 8 do 4000 mm plus lasery RGB do 2 W :-)
Awatar użytkownika
Założyciel i Patron Forum
 
Posty: 18278
Rejestracja: 12 Kwi 2005, 19:17
Miejscowość: 15 km na południe od Krakowa

PostTom-cio | 22 Cze 2006, 09:55

Gregory napisał(a):Tak jak piszesz Januszu mogłoby się zapewne stać gdyby zauważalny był w miejscu pierscienia regulacyjnego pewien luz. Poczyniłem próby z tym związane i nie zauważyłem odchyłki w związku z kolimacja, obraz nie uległ zmianie, tak że sposób ten może się sprawdzić w praktyce. Nawet bez konieczności stosowania dodatkowego paska i rolki napinającej. To jest pierwsza z możliwych do wykorzystania koncepcji, być może uda się rozwiązać w przyszłości to jeszcze inaczej, a jak narazie ostrość ustawiam całkowicie manualnie. ;-)

Pozdrawiam,
Gregory


2 lata stosuję z powodzeniem patent z paskiem na MTO i nie stwierdziłem nijakich problemów z obrazem, kolimacją etc., a pasek jest naciągnięty dość konkretnie w celu skasowania luzów :D
pozdrówka Tomcio

ED80, MT-800, 428EX
Tuningowany EQ-6 z Melon'owym GOTO by PTL
Awatar użytkownika
 
Posty: 225
Rejestracja: 27 Paź 2005, 10:59
Miejscowość: Katowice

PostGregory | 22 Cze 2006, 10:15

Janusz_P. napisał(a):Ten luz normalnie kasuje smar będą y w tym wielowchodowym gwincie regulacyjnym, pod stałym naciskiem paska smar się przemieści po kilku dniach w jedną stronę i obudowa się zdecentralizuje co napewno wpłynie na kolimację systemu.
Zapytaj Domka, miał już podobne problemy z obiektywem Nikona :roll:


W przypadku rozwiązania Domka problem powstawał w trochę innym miejscu. Robofocus nie został zamontowany do samego obiektywu, gdyż obiektyw był za mały, czyli fizycznie byłoby to conajmniej utrudnione. W przypadku MTO Robofocus można zamontować do samego korpusu, gdzie nie będą powstawały odkształcenia na drodze obiektyw - aparat/kamera. Inną sprawą jest ewentualny luz na gwincie od regulacji ostrości. Pierścień regulacyjny wcale nie musi pracować przez cały czas tylko w pewnym, małym zakresie i doprowadzić do przemieszczenia się smaru. Pasek napinający wcale nie musi być też jakoś specjalnie silnie napięty. Ja w moim MTO zredukowałem ilość smaru, występuje on obecnie w ilości śladowej. Jakość obrazu doskonała, pierścień chodzi leciutko, nie ma luzów. :-)

Pozdrawiam,
Gregory
Gregory
 

PostJanusz_P. | 22 Cze 2006, 12:56

Jak chcesz to zrób to i się sam przekonaj, ma to szansę działać poprawnie więc czmu nie spróbować :wink:
Astropozdrówko Janusz P.

Fujinon 10x50, SCT 6 podręczny, SCT-14" HyperStar, EQ-6, Coronado 60, EOS-6D-mod i takie tam szkiełka do niego od 8 do 4000 mm plus lasery RGB do 2 W :-)
Awatar użytkownika
Założyciel i Patron Forum
 
Posty: 18278
Rejestracja: 12 Kwi 2005, 19:17
Miejscowość: 15 km na południe od Krakowa

PostGregory | 23 Cze 2006, 21:04

Taki Robofocus wykonany w oparciu o sterownik Leszka, Canon w połączeniu z Laptopem, do którego będą spływać obrazy z Canona na bieżąco analizowane przez oprogramowanie zainstalowane na Laptopie, i wysyłające odpowiednie sygnały do sterownika silnika krokowego robofocusa, który z kolei poruszy silnikiem a co za tym idzie pierścieniem regulacyjnym MTO w odpowiednim mikrometrycznym wręcz przedziale, to może być to coś! :shock: Wydaje mi się, że to po prostu trzeba będzie przetestować w praktyce. :)

MTO i jego ostrość będzie do opanowania wtedy nie tylko przez ludzi z palcami pianisty. ;-)

W niedługim też czasie, ukaże się 4 część recenzji dotycząca ulepszeń związanych z powiększoną funkcjonalnością procesora sygnału, a co za tym idzie zastosowania nowego oprogramowania działającego w samym procesorze, jak też tego instalowanego na PC. :)

Pozdrawiam,
Gregory
Gregory
 

Postleszekjed | 27 Cze 2006, 12:04

Zanim pojawi sie obszerniejszy opis Grzegorza dotyczący modułu planetarnego napiszę parę słów na temat dokładności obliczeń i uzyteczności arytmetyki 8 bitowej w obliczeniach astronomicznych. Położenie Słońca, Księżyca i planet niewustannie zmienia się w czasie (współrzędne Ra i Dec) podobnie jak gwiazd ale zmiany mają charakter na tyle duży w czasie, że należy współrzędne wyliczać co najmniej przed każda obserwacją.
Algorytm obliczeń polega początkowo na wyliczeniu pozycji Słońca, która bierze udział w wyliczeniu pozycji pozostałych planet i Księżyca a w końcowej fazie obliczeń następuje zmiana układu współrzędnych z helio na geocentryczny. W sumie jest to szereg operacji trygonomwtrycznych, potęgowanie, pierwiastkowanie a także zmiennoprzecinkowe dzielenie, mnożenie, dodawanie i odejmowanie. Poniżej podaję przykładowe dane współrzędnych wyliczone wczoraj dla róźnych pór dnia w porównaniu z wyliczeniami programu planetarium (Stellarium). W nawiasach znajdują się wartości liczone przez Stellarium (zakłądam, że dokłądnośc tych obliczeń jest referencyjna)
1. Słońce Ra=6.34 (6.369), Dec=23.335 (23.338)
2. Księżyc Ra=7.101 (7.388), Dec=27.489 (25.953)
3. Merkury Ra=8.049 (8.066), Dec=20.022 (19.874)
4. Wenus Ra=4.075 (4.11), Dec=19.157 (19.53)
5. Mars Ra=9.106 (9.12), Dec=17.911 (17.833)
6. Jowisz Ra=14.47 (14.473), Dec=-13.42 (-13.422)
7. Saturn Ra=8.823 (8.825), Dec=18.562 (18.556)
8. Uran Ra=23.08 (23.081), Dec=-6741 (-6.748)
9. Neptun Ra=21.46 (21.465), Dec=-15.15 (-15.161)
10. Pluton Ra=17.72 (17.668), Dec=-16.17 (-15.711)
Największe różnice wystepują dla Księżyca, Słońca i Plutona. Z Plutonem jest problem bo nie ma teorii opisujacej jego ruch a do celów obliczeń stosuje się aproksymację szeregami. Ja ze względu na szczupłość miejsca w kontrolerze zastosowałem prostą interpolację liniową. Dla Księżyca z kolei dokładne obliczenia wymagają uwzględnienia kilkunastu poprawek, na które także zabrakło miejsca (na razie).
L.J.
 
Posty: 369
Rejestracja: 28 Lip 2005, 12:01

Postleszekjed | 27 Cze 2006, 12:33

Ale sprawa nie jest beznadziejna bo starczy chyba jeszcze miejsca po uruchomieniu modułu guide aby wprowadzić główne poprawki zarówno dla Księżyca jak i Plutona. Ale na razie rzeczywiste położenie obiektów na niebie również nie odbiega znacząco od obliczeń teoretycznych. Dla przykładu podaję wyliczenia współrzędnych lokalnych (wysokość nad horyzontem - Alt i azymut -Az) dla podanych wyżej współrzędnych w porównaniu z wyliczeniami programu planetarium - wszystkie dane w stopniach:
1. Słońce Alt=60.67 (60.67), Az=203.76 (203.868)
2. Księżyc Alt=66.38 (65.993), Az=182.01 (183.23)
3. Merkury Alt=57.36 (57.353), Az=157.3 (157.43)
4. Wenus Alt=41.29 (41.297), Az=246.94 (247.02)
5. Mars Alt=50.02 (50.047), Az=135.63 (135.71)
6. Jowisz Alt=21.1 (21.125), Az=209.12 (209.142)
7. Saturn Alt=1.484 (1.492), Az=61.676 (61.692)
8. Uran Alt=25.03 (25.042), Az=218.37 (218.358)
9. Neptun Alt=6.328 (6.342), Az=236.25 (236.225)
10. Pluton Alt=20.36 (21.001), Dec=158.79 (159.492)
Z analizy błędów wynika, że błąd położenia wyniósł (w minutach łuku) 0 dla wysokości oraz -6.5 dla azymutu dla Słońca, +23.2 i -72.9 dla Księżyca, -38.9 i -42.1 dla Plutona i poniżej 1.5 minuty dla wysokości i poniżej 7.5 minuty łuku dla azymutu dla pozostałych obiektów planetarnych. Dla przypomnienia: drogę 1 minutę łuku przebywa ciało niebieskie w ciągu ok. 4 sekund.
Po poprawieniu algorytmów dla Księżyca i Plutona dokładność powinna zejść poniżej 10 minut łuku dla każdej współrzędnej dla tych obiektów co jest wartością nie najgorszą biorąc pod uwagę na dysponowaną moc obliczeniową mikrokontrolera (8 bitów z zegarem 11MHz). Jest to zarazem dokładność całkowicie wystarczająca do realizacji funkcji goto, śledzenia i guide.
L.J.
 
Posty: 369
Rejestracja: 28 Lip 2005, 12:01

PostGregory | 07 Lip 2006, 20:35

leszekjed napisał(a):Zanim pojawi sie obszerniejszy opis Grzegorza dotyczący modułu planetarnego


Juz niebawem. System sie sprawdza i bedzie mozna powiedziec o nim znacznie wiecej... autor wyprzedzil epoke juz dawno, to tez zostanie dodatkowo opublikowane. :) Aura letnia jest wspaniala, szczegolnie noca. Super. 8)

Pozdrawiam,
Gregory
Gregory
 

Postleszekjed | 14 Lip 2006, 14:15

Ponieważ mam już pierwsze pozytywne sygnały od Grzegorza, że ostatnio wprowadzona do procesora sygnału funkcja guide działa zgodnie z założeniami mogę powiedzieć, że założona wcześniej funkcjonalność urządzenia jest w zasadzie zrealizowana. Od czasu pierwszych prób Grzegorza największe zmiany zaszły w oprogramowaniu procesora sygnału ze względu na wprowadzone równolegle zmiany polegające na rozbudowie pamięci urządzenia. Opis procesora sygnału na tym forum znajduje się w wątku:

http://www.astromaniak.pl/viewtopic.php?t=204

Bardziej szczegółowy opis ostatnich zmian można znaleźć na mojej stronie:

http://www.lx-net.prv.pl/st/st9.htm

gdzie znajduje się pełna dokumentacja urządzenia włącznie z wykazem elementów oraz kalkulacją kosztów wykonania procesora sygnału.
Tak więc w tej chwili urządzenie pozwala na pracę z montażami paralaktycznymi i azymutalnymi o dowolnych przekładniach mechanicznych. Możliwe jest dostowanie parametrów działania ze względu na czas i miejsce obserwacji. Baza danych może pomieścić do 3600 obiektów w tym Słońca, Księżyca i planet dla których system wylicza bieżące współrzędne. Możliwa jest łatwa konfiguracja oraz modyfikacja baz danych za pomocą oprogramowania na PC a także praca guide w oparciu o program GuideDog otwierająca szeroko drogę do astrofotografii. Chętnym do samodzielnego uruchomienia urządzenia mogę pomóc zarówno radą jak i w uzyskaniu krytycznych elementów (obudowa, przyciski i inne elementy mechaniki) oraz kontrolerów lub ich bezpłatnego zaprogramowania jeśli takie posiadają.
L.J.
 
Posty: 369
Rejestracja: 28 Lip 2005, 12:01

PostGregory | 22 Lip 2006, 00:19

leszekjed napisał(a):Ponieważ mam już pierwsze pozytywne sygnały od Grzegorza, że ostatnio wprowadzona do procesora sygnału funkcja guide działa zgodnie z założeniami mogę powiedzieć, że założona wcześniej funkcjonalność urządzenia jest w zasadzie zrealizowana.


Tak to prawda. Sprawy podazaja caly czas dynamicznie do przodu. Jak sie okazuje - wazne jest wszystko. :) Trzeba zrealizowac po drodze o wiele wiecej zalozen niz sie to moglo do tej pory wydawac, niemniej jestesmy na bardzo dobrej drodze i zblizamy sie do finalu. :) Po podsumowaniu calosci, i weryfikacji w praktyce funkcjonalnosci systemu juz wkrotce pojawi sie kolejna czesc recenzji. :) Ale zawsze znajdzie sie cos, co mozna jeszcze ulepszyc, udoskonalic. ;-)

Pozdrawiam,
Gregory
Gregory
 

PostGregory | 06 Sie 2006, 00:08

No i stalo sie. Zawsze uwazalem ze taki prawdziwy astrograf to nie tylko to co zabieramy ze soba w plener z domu, ale tez to co w tym domu pozostawiamy. :) Udalo mi sie w koncu zbudowac taka z prawdziwego zdarzenia domowa siec komputerowa. ;-) Najpotezniejszy w sieci komputer, oparty zostal na bardzo wydajnym dwurdzeniowym procesorze Pentium D. No... i musze przyznac ze obrobka zdjec z Canona, odejmowanie darkow, alingowanie i stackowanie to prawdziwa poezja! :) Troche czasu zajela konfiguracja maszyn, ale w koncu calosc osiagnela 100% funkcjonalnosci czyli jest tak jak chcialem. Niedlugo ruszam z fotkami z MTO i ta recenzja zostanie rowniez odpowiednio rozbudowana. :)

Pozdrawiam,
Gregory
Gregory
 

PostGregory | 12 Sie 2006, 23:50

tutaj niedlugo cos fajnego bedzie. :)
Gregory
 

Postleszekjed | 22 Sie 2006, 22:56

Uprzedzając kolejny odcinek recenzji Grzegorza zamieszczam pierwsze wyniki działania funkcji guide wbudowanej do procesora sygnału. Opis używanego w próbie systemu guide pokazuje rysunek:

Image

Więcej na ten temat i innych możliwych konfiguracji guide można znaleźć na mojej stronie:

http://www.lx-net.prv.pl/zs/zs1.htm

Grzegorz jest jak zwykle pierwszym testerem każdego nowego rozwiązania więc czekam na jego subiektywne wrażenia z porównania działania guide realizowanego za pomocą AstroPilota z RelayBox-em oraz guide wbudowanego do procesora sygnału.
Ta próba, w wyniku której powstało to piękne zdjęcie M27:

http://www.astromaniak.pl/viewtopic.php?t=1188

odbyła się 17.08.2006r. i trwała nieprzerwanie od 23.25 do 01.15 (6667 sekund).

L.J.
Ostatnio edytowany przez leszekjed, 12 Lis 2006, 14:23, edytowano w sumie 1 raz
 
Posty: 369
Rejestracja: 28 Lip 2005, 12:01

Postleszekjed | 22 Sie 2006, 23:51

Grzegorz wykonał również wykres błędów dla obu osi w czasie działania próby:

Image

http://www.lx-net.prv.pl/glog/guide_ps.xls

Na tej podstawie zrobiłem dodatkową obróbkę statystyczną wyników.
Test trwał nieprzerwanie od 23:25:46 do 01:16:53 czyli 6667 sekund. Maksymalne odchyłki dla osi Ra to -5.729 / 6.645 arcsec a dla osi Dec odpowiednio -7.749 / 5.561 arcsec.
Suma wszystkich ruchów korekcyjnych dla dla osi Ra wyniosła 4617 arcsec a dla osi Dec 1248 arcsec co świadczy o tym, że Grzegorz znacznie lepiej przyłożył się do ustawienia montażu dla osi Dec :-)
Średnia wartość korekty dla osi Ra wynosi 1.44 arcsec a dla osi Dec 0.39 arcsec co dodatkowo wskazuje na tendencję układu do kasowania stałej odchyłki montażu dla obu osi (większej dla osi Ra).
Posumowałem też wartości bezwględne korekt dla stałych przedziałów o szerokości 1 arcsec a wyniki są następujące:

dla przedziału 0-1arcsec jest 26.0% korekt w osi Ra i 36.5% korekt w osi Dec
dla przedziału 1-2arcsec jest 25.6% korekt w osi Ra i 32.3% korekt w osi Dec
dla przedziału 2-3arcsec jest 23.9% korekt w osi Ra i 17.5% korekt w osi Dec
dla przedziału 3-4arcsec jest 16.5% korekt w osi Ra i 7.7% korekt w osi Dec
dla przedziału 4-5arcsec jest 6.3% korekt w osi Ra i 3.6% korekt w osi Dec
dla przedziału 5-6arcsec jest 1.4% korekt w osi Ra i 1.5% korekt w osi Dec
dla przedziału 6-7arcsec jest 0.2% korekt w osi Ra i 0.7% korekt w osi Dec
dla przedziału 7-8arcsec jest 0.0% korekt w osi Ra i 0.2% korekt w osi Dec

Sumują poszczególne przedziały od najniższego można powiedzieć, że błędy korekcji rozkładają się następująco:

dla przedziału 0-1arcsec jest 26.0% korekt w osi Ra i 36.5% korekt w osi Dec
dla przedziału 0-2arcsec jest 51.6% korekt w osi Ra i 68.8% korekt w osi Dec
dla przedziału 0-3arcsec jest 75.5% korekt w osi Ra i 86.3% korekt w osi Dec
dla przedziału 0-4arcsec jest 92.0% korekt w osi Ra i 94.0% korekt w osi Dec
dla przedziału 0-5arcsec jest 98.3% korekt w osi Ra i 97.6% korekt w osi Dec
dla przedziału 0-6arcsec jest 99.7% korekt w osi Ra i 99.1% korekt w osi Dec

Ten wynik należy rozumieć w taki sposób, że błąd np. dla przedziału 0-4 arcsec mógł wynosić zarówno +4 jak i -4 arcsec i takich wyników było 92% dla osi Ra oraz 94% dla osi Dec. W rzeczywistości, ze względu na stałą odchyłkę błędu w stronę dodatnich wartości należałoby dla każdego z podanych przedziałów uwzględnić (odjąć) wartość średnią błędu dla każdej z osii a więc 1.44 dla osi Ra i 0.39 dla osi Dec.
Analizując wykres zauważyć można, że zdarzały się znaczne odchyłki korekcyjne sięgające 7 arcsec. Nie potrafię powiedzieć dlaczego tak się dzieje. Grzegorz sugeruje, że okresowy wzrost błędów (daje się zauważyć okres ok. 5 lub 10 minutowy jednocześnie dla obu osi) może być związany z ruchem migawki Canon-a - właśnie co 5 minut.
Można natomiast stwierdzić, że wkład odchyłek większych niż 4arcsec do całego naswietlanego materiału jest nie większy niż 7.9% dla osi Ra i 6% dla osi Dec i nie ma praktycznego znaczenia dla dokładności i jakości wykonywanych zdjęć.
Czekam na porównanie tego wyniku z prowadzeniem guide za pomocą AstroPilota z RelayBox-em. Można jednak już powiedzieć, że system guide wbudowany do procesora sygnału działa z 92% skutecznością z błędem mniejszym niż (8-1.4)/2=+-3.3 arcsec dla osi Ra i 94% skutecznością z błędem (8-0.39)/2=+-3.8 arcsec dla osi Dec. Kolegom pozostawiam ocenę czy jest to dużo czy mało ale proszę pamiętać, że w tym wyniku znajdują się wszystkie błędy mechaniki montażu, błędy ustawienia montażu a także błędy wszystkich algorytmów sterowania w procesorze sygnału i w programie GuideDog :-)
L.J.
Ostatnio edytowany przez leszekjed, 12 Lis 2006, 14:24, edytowano w sumie 1 raz
 
Posty: 369
Rejestracja: 28 Lip 2005, 12:01

PostTUR | 23 Sie 2006, 01:17

Leszek,

Miałem ostatnio przyjemność oglądać Twoje dzieło, ponieważ Grzegorz zrobił mi mały pokaz właśnie przed sesją M27. Przyznaję, że jestem pod dużym wrażeniem. Chylę czoła za kawał dobrej roboty, który odwaliłeś nad tym urządzeniem.

Pozdrawiam
Paweł
 
Posty: 1170
Rejestracja: 28 Lip 2005, 21:40

PostGregory | 23 Sie 2006, 19:42

Leszku, wspaniale podsumowałeś zapis z powstałych plików log i taka sama jest ta statystyka. :)

Ze swojej strony dodam, ze te odchyłki na wykresie mogą być spowodowane pracującą w trakcie trwania sesji mechanika aparatu. Powiem więcej - jest to bardzo prawdopodobne. A jak czułe jest całe urządzenie chyba nie trzeba mówić. Wystarczy niefortunnie odłożyć wężyk spustowy na półkę statywu, czy poruszyć przewodem, i z marszu zaczyna intensywniej pracować korekcja. :) Canon 350D wyzwalany był za pomocą elektronicznego wężyka spustowego w ten sposób, ze na początku podnoszone było lustro, a dopiero po kilku sekundach otwierała się migawka aparatu (aktywna opcja mirror lockup). W ten sposób niepożądane drgania nie uwidoczniły się wprawdzie na poszczególnych klatkach (doskonałe prowadzenie na 100% materiału), ale oczywiście ładnie zostały zanotowane na wykresie, gdyż guider (ogniskowa 1200 mm) pozostawał aktywny przez cały czas. :)

Docelowo zamierzam jeszcze skrupulatniej przeprowadzić testy. Tym razem wykonane zostaną dwa pomiary. Jeden dla procesora sygnału z wbudowaną funkcją Guide, a drugi dla procesora sygnału z zewnętrznym RelayBoxem i dodatkowym Astropilotem. Przez czas trwania tych testów aparat pozostanie wyłączony. Dzięki temu wyeliminowane zostanie prawdopodobieństwo powstawania błędu przy podnoszeniu i opuszczaniu lustra Canona, choć i obecne wyniki uważam za więcej, jak bardzo pozytywne. :)

Pozdrawiam,
Gregory
Gregory
 

PostGregory | 04 Wrz 2006, 02:29

Ponieważ już kilkukrotnie zadawano mi pytanie, w jaki sposób montuję swojego MTO razem z Pronto do SVP, postanowiłem to trochę bardziej przybliżyć.

Całe mocowanie wykonałem na wzór krzyża i wygląda to tak:

Image

Gdzie:

A - to jest dovetail montowany do głowicy montażu w standardowy sposób;
B - szyna z wyprofilowaniem pod korpus MTO po jednej stronie, i po drugiej stronie otworem pozwalającym przeprowadzić śrubę w celu montażu głowicy fotograficznej;
C - głowica fotograficzna PZO;
D - gniazdo do którego montowane jest MTO;
E - tutaj można zamontować dowolny aparat fotograficzny, drugi większy obiektyw z aparatem czy choćby Pronto pełniący w danym momencie np. funkcję guidera. Głowica pozwala na dowolną orientację Guidera, niezależnie od miejsca, na które "spogląda" w danym momencie MTO;
F - te otwory umożliwiają w wystarczający sposób zachować środek ciężkości pomiędzy dwoma stosowanymi instrumentami;
G - tak samo te nagwintowane otwory do których przykręcana jest listwa. Dzięki kilku takim otworom można jeszcze lepiej całość zrównoważyć, ale też spory zakres do regulacji środka ciężkości dostępny jest już przy samej głowicy montażu.

W praktyce rozwiązanie to sprawdza się doskonale. W układzie MTO - Pronto, refraktor pełni funkcję guidera (ogniskowa 1200 mm + Vesta), a MTO rejestruje obraz za pomocą Canona. W układzie MTO - inny obiektyw, np. o krótszej ogniskowej, MTO jest teleskopem prowadzącym. :)

Pozdrawiam,
Gregory
Gregory
 

PostGregory | 24 Wrz 2006, 14:14

Kolejna fotografia ściśle związana z tematem DS-ów, uzyskana z wykorzystaniem opisanego wcześniej zestawu:

M31 i M32

Image

Pozdrawiam,
Gregory
Ostatnio edytowany przez Gregory 05 Lis 2006, 22:02, edytowano w sumie 4 razy
Gregory
 

Użytkownicy przeglądający to forum: Brak zarejestrowanych użytkowników oraz 9 gości

AstroChat

Wejdź na chat