Skocz do zawartości

zbuffer

Społeczność Astropolis
  • Postów

    707
  • Dołączył

  • Ostatnia wizyta

Treść opublikowana przez zbuffer

  1. Czy ktoś się orientuje jaka jest minimalna odległość ostrzenia dla typowych lunetek do guide 120mm F4? Może znacie jakieś narzędzie które pozwala to wyliczyć i określić jak daleko musi być sensor?

    1. Pokaż poprzednie komentarze  4 więcej
    2. Gość na chwilę

      Gość na chwilę

      Spoko. Ja ze względu na pesel mam pamięć długoterminową :) w praktyce oznacza to że pamiętam równanie soczewki ale nie pamiętam czy wziąłem rano proszki na pamięć :)

    3. Tayson
    4. zbuffer
  2. Dzięki! Ja myślałem, że oprogramowanie montażu w ogóle nie jest na to przygotowane, szczególnie jak widziałem te ciągłe szybkie oscylacje na zapisie PE. Zresztą nie tylko na wykresie je widzę bo można je usłyszeć. Ciekawy jestem czy to problem mechaniczny czy takie świetne jest sterowanie prędkością serwa w tym montażu… BTW tak jak pisałem na końcu - nie miałem jeszcze możliwości sprawdzenia tego podczas zbierania materiału. Zresztą wątpię żebym był w stanie zmierzyć z taką dokładnością prowadzenie na gwiazdach - może na jakiejś pustyni
  3. Trochę czasu minęło od ostatniego postu bo miałem niestety bardzo mało czasu na pracę nad nowym sterownikiem do montażu. W końcu jednak się udało. Używam platformy INDI do sterowanie sprzętem. Moim pomysłem było rozszerzenie sterownika montażu tak by wspierał drugie urządzenie - płytę od enkodera. Sterownik dla iOptron iEQ45 jest jakby podklasą generalnego sterownika opartego o protokół LX200. Niestety widać, że pisany był przez kilka osób i z chęcią wsparcia różnych modeli - jest bałagan, masa niewykorzystanych funkcji itp. Nie lubię pracować z takim kodem więc przepisałem cały sterownik od zera, opierając się o dokumentację protokołu iOptron'a. Znalazłem co najmniej kilka błędów w starym sterowniku. Swoją drogą protokół jest tekstowy, zero jakiejkolwiek kontroli błędów, wygląda jak napisany przez kogoś kto dopiero co nauczył się programować i może raz widział mikrokontroler. Niestety nie jest to jedyny sprzęt, w którym spotykam się z tak amatorskimi rozwiązaniami, które może były dobre do testowania a nie do stworzenia produktu. Na to niestety nie mam wpływu dopóki nie stworzę własnego montażu, więc trudno się mówi. Po przepisaniu sterownika zaimplementowałem wsparcie dla mojego enkodera. Oczywiście transmisja odbywa się binarnie, pakietowo, z sumami kontrolnymi itp. Na koniec zostało rozszerzenie GUI sterownika, który wyświetla się w EKOSie. GUI zawiera podstawowe funkcje i parę diagnostycznych - połączenie z enkoderem, możliwość uruchomienia odczytu, PEC, zmienne wzmocnienia korekty, częstotliwość, możliwość zapisu odczytów w pliku itd. Dzięki zintegrowaniu sterownika enkodera ze sterownikiem montażu mam bezpośredni dostęp do PulseGuiding'u, który wykorzystuję do korekt. Rozwiązanie nie różni się specjalnie jeśli chodzi o generalny zamysł od TDM (Telescope Drive Master), ale tam urządzenie jest zupełnie zewnętrzne w stosunku do montażu, a guiding jest aplikowany przez złącze ST4. Oczywiście ingerując bezpośrednio w sterowniki montażu ma się dużo większe pole manewru co do np. zmiany trybu działania enkodera w zależności od tego co robi montaż czy możliwości korzystania z PulseGuiding'u po stronie kamery. Dla mnie największą zagadką było to jak montaż zareaguje na szybkie korekty z enkodera poprzez PulseGuiding - coś na co bezpośrednio nie mam wpływu. Okazało się jednak, że jest lepiej niż się spodziewałem... RMS bez PEC: 9.62 arcsec RMS z PEC: 0.10 arcsec Zoom na wykres z PEC: Korekty robione były z częstotliwością 20Hz, co po kilku próbach wyglądało na najlepsze ustawienie. Na tym etapie korekta jest banalna - proporcjonalna do błędu z możliwością regulacji wzmocnienia, żadnej predykcji, żadnych fajerwerków. Na takie zabawy przyjdzie pora jak będę sterował napędami bezpośrednio. Uwaga: brakuje mi kilku elementów toru optycznego, które właśnie jadą do mnie od Tomka, więc nie miałem sposobu na wykonanie pomiarów na gwiazdach i pod obciążeniem teleskopem, żeby zobaczyć jak to działa w praktyce.
  4. Problem jest wtedy jak kupujesz sprzęt na gwarancji i nie możesz nic wymieniać. Poza tym generalnie jest to kiepskie rozwiązanie nieadekwatne do zastosowań na zewnątrz, w wysokiej wilgotności, czy nawet często w sensie maksymalnego prądu i rezystancji.
  5. Ja myślę że największe nieporozumienie to używanie gniazd DC w całym sprzęcie astro. W montażu muszę uważać żeby nie ruszać kablem bo się resetuje. Wszystko powinno być na jakichś gniazdach/wtykach z gwintem albo inna blokadą.
  6. Pix’a możesz zainstalować na dowolnej liczbie komputerów i platform. Musisz normalnie ściągnąć installer z Twojego konta na ich stronie.
  7. Ja mam ASI1600 MM Pro i jestem całkiem zadowolony. Jak dla mnie bardzo dobra kombinacja wielkości piksela i rozdzielczości, bo już można zrobić nawet spory wydruk i „zwiedzać” zdjęcie, przy zachowaniu rozsądnego czasu procesowania klatek podczas obróbki. Wbudowany hub usb to fajne rozwiązanie bo pozwala na zachowanie porządku w kablach. Chłodzenie działa tak jak koledzy pisali. W ciepłe hiszpańskie noce z trudem schodziło poniżej -10 C. Nie stanowi to jednak żadnego problemu bo szum termiczny jest bardzo niski i wiele osób na stałe ustawia taką temperaturę, żeby mieć zawsze tak samo schłodzoną kamerę, niezależnie od pory roku. Kamera była bardzo popularna tylko po prostu pojawiły się nowe konstrukcje o wyższej czułości.
  8. Jak Ci gniazdo wyszło z płytki a Ty go „nasunąłeś”? Może jakbyś jakieś zdjęcia zrobił to by to więcej powiedziało. Swoją drogą nie rozumiem - jak Ci działa z laptopem to czemu doszukujesz się problemu w sprzęcie? Chyba się pogubiłem…
  9. To akurat ma małe znaczenie bo tak naprawdę każdym silnikiem elektrycznym steruje się prądowo. Napięcie to nie jest parametr silnika. Parametrami są rezystancja i induktancja uzwojeń czy np. zależność momentu od prądu. Jeżeli tylko nie podasz napięcia, które przebije izolację, to silnikowi nic się nie stanie, ale zbyt duży prąd go po prostu spali. Ja bym się o drivery nie martwił. Po prostu mogą tam być jakieś przetwornice dla reszty elektroniki czy stabilizatory liniowe, które przy wyższym napięciu mogą się przegrzać. Także jak producent mówi, że 24V też może być to znaczy tylko że przetwornice mają wystarczająco szeroki zakres wejść. Wracając do USB to obecnie można bardzo łatwo kupić konwerter UART-USB i podpiąć go pod linie RX TX, które wchodzą do obecnego chipu konwertera FTDI z reszty elektroniki. Trzeba oczywiście rozpoznać układ i przeczytać notę katalogową. Mnie jednak zastanawia czy software będzie rozpoznawał potem montaż. Wszystko zależy od tego czy sprawdzają VID/PID w driverze czy po prostu lecą żywcem po porcie COM który wybierze użytkownik. Nie widziałem softu więc nie mam pojęcia.
  10. Wielkie dzięki! Postaram się nie zawieść. Następny etap to chyba próba przepisania drivera pod INDI, tak żeby mógł połączyć się z dwoma urządzeniami - montażem i enkoderem...? Nawet nie wiem czy to jest możliwe bez trików. Ewentualnie jakieś gadanie pomiędzy driverami... Na pewno nie jestem pierwszy z tym problemem
  11. Pogratulujesz mi jak zmuszę ten montaż do prowadzenia na tyle dokładnie, żebym mógł wyeliminować guiding przy skali ok. 0.7''/px (marzy mi się przejście na dłuższą ogniskową). W przeciwnym przypadku to będzie sztuka dla sztuki. Nie odpuszczę jednak tak łatwo i przejdę do wymiany elektroniki jak się będzie bardzo opierał...
  12. Dzięki! Nie rozumiem pytania więc opiszę. Pomiar kąta składa się z kilku elementów. Najpierw generuję sygnał kwadraturowy z sin/cos, żeby wiedzieć w której ćwiartce okresu jestem, i akumuluję kąt dodając kolejne 90 stopni przy każdym przejściu. Do tego zgrubnego akumulowanego kąta dodaję dokładny pomiar brakującej reszty przez użycie funkcji arctan na sygnałach analogowych. Ostateczny pomiar ma zatem pełną rozdzielczość jaką mogę uzyskać. Musisz go sporo zoomować żeby zobaczyć gdzie się kończy rozdzielczość BTW dzięki dostępności sygnału analogowego nie jest do niczego potrzebne 1kHz żeby znać dokładny kąt - wystarczy że próbkowanie jest na tyle szybkie żeby dało się wygenerować kwadraturę i nie zgubić żadnej ćwiartki. W montażu astro to sprawa banalna ale już niekoniecznie jak taki enkoder pracuje na maszynie robiącej tysiące obrotów na minutę. Nagrałem trochę ponad 1200s i przepuściłem przez skrypt w Pythonie, który wypluwa mi te wykresy. Zamiast dzielić pomiar na trzy 400s odcinki i to uśredniać, po prostu zrobiłem FFT całości a potem iFFT po wybraniu tych zaznaczonych częstotliwości. W sumie to dało coś w rodzaju uśrednienia, ale widać że ostateczny wykres nie powtarza się idealnie.
  13. No to pora na pierwsze pomiary. Najpierw na zatrzymanym montażu sprawdziłem z jakim poziomem szumu pomiaru kąta mam do czynienia. Przypominam, że przetwornik analogowo-cyfrowy ma tylko 12 bit, a tak naprawdę to efektywnie ok. 10.5 bit wg producenta mikrokontrolera. Stosując 256x oversampling teoretycznie uzyskać można 20 bit jednak wynik konwersji może mieć max 16 bit, więc trzeba go przesunąć w prawo o 4 bity. Otrzymujemy więc lepszą rozdzielczość i przy okazji uśredniamy pomiar. Uwaga: żeby wykorzystać pełny zakres przetwornika sygnał musiałby się idealnie mieścić w zakresie napięć wejściowych, co oczywiście nie jest możliwe. Przy prezentowanych wynikach sygnał wykorzystywał tylko około 56% zakresu przetwornika. Muszę to poprawić zwiększając trochę wzmocnienie. Tak czy inaczej, na płytce uniwersalnej i z wbudowanym ADC szum odczytu mieści się dla obu kanałów w przedziale mniej więcej +-11 jednostek. Samo to w sobie wiele nie mówi, ale po przeprowadzeniu analizy najgorszego przypadku wyszło mi, że największy błąd estymacji kąta wyniesie ok. 0.02 arcsec. Wygląda więc na to, że szum nie będzie mnie limitował. Biorąc natomiast pod uwagę częstotliwość próbkowania 1kHz, pracujący montaż pokona pomiędzy próbkami około 0.015 arcsec. Są to generalnie wartości o rząd wielkości mniejsze niż dokładność prowadzenia jaką chciałbym uzyskać. W moim przypadku, ze względu na znaczny oversampling sygnału enkodera (tysiące próbek na jeden okres sinusa), zastosowałem software'owe generowanie sygnału kwadraturowego poprzez detekcję przejścia przez zero z histerezą. Poniżej fragment sygnału z enkodera podczas pracy montażu. Brnąc dalej w temat wykonałem dłuższy pomiar pracy montażu, obejmujący 3 okresy ślimaka, żeby oszacować PE. Na wykresie poniżej prezentuję błąd prowadzenia zakładający, że montaż powinien poruszać się zgodnie z prędkością ruchu gwiazd (sideral tracking), wynoszącą trochę ponad 15 arcsec/s. Widać, że bez usunięcia trendu, montaż prowadzi zbyt wolno, przynajmniej na tym fragmencie ślimacznicy (obliczam błąd jako model minus pomiar). Następnie przechodzimy do transformaty Fouriera, żeby wyizolować z sygnału częstotliwości o znaczącej amplitudzie. Na koniec syntetyzujemy PE używając transformaty odwrotnej. Jak na montaż, w którym dokonano wszystkich opisanych wcześniej zmian, to raczej szału nie ma. Muszę zobaczyć czy ma tu jakiś wpływ wyważenie sprzętu i chyba przeczyszczę i przesmaruję wszystko jeszcze raz. Oczywiście teraz przede mną najtrudniejsze zadanie - wykorzystanie enkodera do poprawienia prowadzenia.
  14. Dzięki za miłe słowa! Jeśli chodzi o dokładność to są dwa problemy. Po pierwsze poziom szumu samej analogowej części elektroniki i zastosowanie ADC wbudowanego w mikrokontroler. Jest to jedynie rozwiązanie tymczasowe ale chcę zobaczyć co z tego wycisnę. Po drugie, i tu mam większe obawy, brak bezpośredniej kontroli napędów i konieczność symulowania guidingu. Wiadomo, że nie przeskoczę tego jak zaimplementował to producent, a nie mam dobrych przeczuć… Dlatego nowa elektronika będzie pewnie nieunikniona, ale to da mi możliwość generalnego unowocześnienia i poprawienia wszystkiego co nie działa, więc będzie to fajny projekt.
  15. Witam! Jestem posiadaczem montażu iOptron iEQ45 (nie pro). Jest to jeden z pierwszych montaży tej firmy. Ma klasyczną konstrukcję GE, napędzany jest serwami DC i oczywiście nie posiada enkoderów. Ma teoretycznie możliwość nagrania korekcji PEC, ale nie działa ona z guidingiem a sama w sobie nie wystarcza. Montaż został już przeze mnie dość mocno zmodyfikowany: - wymieniłem wszystkie łożyska na 'firmowe' - wymieniłem smary - założyłem paski o mniejszym module - dodałem napinacze pasków - przerobiłem ustawienie azymutu na śruby z gwintem drobnozwojnym - wykonałem teflonową podkładkę pod głowicę - zrobiłem nową poziomicę - wypiaskowałem i przemalowałem proszkowo na czarno - zbudowałem przeciwwagę z akumulatorem LiIon (której ostatecznie nie używam :D). - zamontowałem siodełko od Primalucelab - wyciąłem błędnie działający GPS. - zmodyfikowałem sterownik dla platformy INDI bo miał kilka błędów. Teraz przyszedł jednak moment na poważniejsze modyfikacje. Ostatecznie prawdopodobnie zaprojektuję własną elektronikę i wymienię napędy na serwa Maxon'a (używane), żeby mieć pełną kontrolę. Jestem jednak narazie na etapie instalacji enkodera na osi RA. Pomysł obejmuje dalszą modyfikację drivera dla platformy INDI, z uwzględnieniem odczytów z enkodera i wprowadzaniem poprawek przez Pulse Guiding. Jeśli chodzi o typ enkodera to zdecydowałem się na zastosowanie rozwiązania wykorzystywanego przez twórców TDM (Telescope Drive Master), czyli inkrementalnego enkodera przemysłowego typu sinus-cosinus. Normalny enkoder inkrementalny, generujący jedynie sygnał kwadraturowy nie ma możliwości dostarczenia odpowiedniej rozdzielczości pomiaru, bo takie enkodery nie przekraczają kilkudziesięciu tysięcy impulsów na obrót. Enkodery używane w dobrych montażach i robotach przemysłowych muszą mieć dużą średnicę i są zawsze zintegrowane z obudową osi. Montaż takich pierścieni byłby niepraktyczny na gotowym montażu a same enkodery pewnie bardzo trudne do kupienia. Enkoder typu sinus-cosinus to ciekawe rozwiązanie bo zamiast sygnału kwadraturowego wypluwa ciągły pomiar w postaci dwóch sinusoid przesuniętych o 90 stopni. Nie jest to jednak jedna a wiele sinusoid na jeden obrót. Taki sygnał pozwala na zgrubny pomiar kąta obrotu poprzez generowanie sygnału kwadraturowego (detekcja przejścia przez zero, np. za pomocą komparatorów) i precyzyjny w oparciu o pomiar wartości sygnału analogowego i zastosowanie funkcji arctan. Udało mi się dopaść używany enkoder Heidenhain o 5000 sinusoid na obrót za około 180 EUR. Enkoder montuje się na wale napędu. W moim wypadku wykorzystałem gwint w osi RA, służący do instalacji lunetki biegunowej. Zaprojektowałem i wydrukowałem sobie mocowanie stalowego wałka, który był w zestawie z enkoderem, oraz obudowy całości. Nie jest to pewnie ostateczna forma ale do testów jest ok. Układ elektroniczny oparłem o moduł rozwojowy z mikrokontrolerem serii STM32, który ma wbudowane dwa przetworniki ADC o rozdzielczości 12 bitów, mogące pracować w trybie jednoczesnym - konieczne w celu uniknięcia przesunięcia fazowego sygnałów. Dodatkowo przetworniki te mogą pracować na sygnale różnicowym a taki właśnie jest na wyjściu z enkodera. Po drodze trzeba jednak dokonać analogowego kondycjonowania sygnału (filtracja, przeskalowanie, przesunięcie zera) za pomocą układów FDA (fully differential amplifier). Polutowałem to testowo na płytce uniwersalnej (perfboard). Muszę jeszcze zrobić obudowę na płytkę. Obecnie program w mikrokontrolerze obejmuje tylko pomiar sygnałów z 256-krotnym oversamplingiem i wypluwa przez wirtualny COM port binarny strumień z pomiarami 16-bitowymi, z częstotliwością 1kHz. W dalszej części wrzucę pierwsze pomiary... Pozdrawiam!
  16. Nie sugeruję tego jako rozwiązania profesjonalnego bo moim zdaniem nawet pod względem dopracowania narzędzi to jeszcze nie może zastąpić mainstreamowego CAD’a, ale do zastosowań hobby i projektowania rzeczy do wydruku 3D jest to wygodne rozwiązanie, szczególnie dla osób pracujących na Linuksie.
  17. Ja tylko podpowiem jeśli koledzy nie znają, że istnieje CAD online onshape.com. Można używać dowoli jeśli udostępnia się projekty publicznie. Oczywiście najlepsze w tym rozwiązaniu jest to, że niczego nie trzeba instalować, a pliki są w chmurze, więc dzielenie się projektami jest właściwie podstawą. Co do jakości to jest naprawdę zaskakująco płynny i wygodny, brakuje paru elementów z dużych CADów, które pewnoe dodadzą.
  18. Hmmm… ale usunąłeś najpierw gwiazdy Starnetem? Bo to wygląda jak jakieś zbyt obszerne maskowanie.
  19. Też myślę, że teraz lepiej! Tylko zauważyłem jeden problem - ciemniejsze placki wokół głównych gwiazd.
  20. Bardzo fajnie pokazane różne pyły. Mi się oryginalność tej fotki akurat podoba. Jedyne co jednak można by poprawić to dynamika/kontrast w centrum. Może lekki HDRWavelet czy coś….?
  21. Sprawdzałeś co możesz zobaczyć w KStars? Posiada opcję wyświetlania w tle zdjęcia całego nieba, zrobionego podczas DSS (Deep Sky Survey). No ale nie jest to software na telefony. Inny pomysł - komputer z planetarium w domu i z tabletu podgląd za pomocą np. TeamViewer’a?
  22. No chyba, że koledze o to chodzi żeby guidingu nie używać. Może to nie wielki kłopot ale też żadna przyjemność
  23. Przerobiłeś pierwszą wersję a ona ma kilka dużych mankamentów jak zbyt wyciągnięty histogram, strasznie nierówne tło i niebieskie obwódki od nieostrego kanału niebieskiego. Teraz się starałem wszystko robić delikatniej i kontrolować detal/odszumianie. Poza tym użyłem LN w trybie interactive i to pozwoliło na dużo lepsze wyrównanie tła.
  24. Podszedłem do obróbki jeszcze raz. Poprawiłem wszystko od stacków, przez odszumianie, po gwiazdy i kolorystykę. Jak się teraz podoba?
  25. Dzięki za propozycje. Najbardziej to mnie zastanawia jak to jest z optyką w tych Skywatcher’ach i innych chińskich produkcjach. Przy APO chyba bardziej wszyscy zwracają uwagę na jakość optyki i nie wiem czy po prostu przy lustrach nie ma takiej różnicy w obrazie i tylko mechanika jest istotna?
×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

Umieściliśmy na Twoim urządzeniu pliki cookie, aby pomóc Ci usprawnić przeglądanie strony. Możesz dostosować ustawienia plików cookie, w przeciwnym wypadku zakładamy, że wyrażasz na to zgodę.