Sebo_b

Może za mało embedded kodu widziałeś Można to owrapować w define'y - ale moim zdaniem wtedy nie jest czytelne. Jak usuniesz delta, bo myślę, że z nią to przesadziłem (zrób testy na sprzęcie, sam jestem ciekaw) - to kod się uprasza do kilku linii i imo jest mega czytelny. Oczywiście założenie jest, że chcesz mieć jak najdokładniej zachowany czas całej sekwencji, a nie różnicę pomiędzy wywołaniami. // constructor nextCall = now() + interval; //active loop if ( nextCall < now() ) { nextCall += interval; callWhatever(); }

1kHz? Rozumiem, że to 1 kbps. 20 lat temu na 8051 wyciągałem stabilne 115200bps (choć nie na timerach). Więc 1kHz dzisiaj to nie powinien być żaden problem.

Schodzimy coraz niżej Co do samego kodu, dość pokrętnie napisane, np: m_timeStart = timeNow; // leftover = timeNow - m_timeAwaited // in SetAwaitedTime m_timeAwaited = (unsigned long)(m_timeStart + m_interval - leftover); // so m_timeAwaited = m_interval + m_timeAwaited Propozycja: // constructor nextCall = now() + interval; delta = 0; //active loop unsigned long n = now(); if (nextCall - (delta >> 8) < n) { nextCall += interval; delta = ( (abs(nextCall - n) << 7) + (delta*4) )/5; // old delta is weighted 4, new delta is weighted 1, this needs to be checked on hardware to determine right weights callWhatever(); } W zaproponowanym rozwiązaniu: - kolejne czasy liczę zawsze od bazowego (nextCall += interval), więc niedokładności wywołań nie wpływają na kolejne wywołania, - kod jest odporny na przepełnienia, po prostu arytmetyka zadziała, - gdyby stosować proste if (nextCall < n to czasy odchylały by się zawsze w jedną stronę, było by spóźnienie, stąd delta która odchyla to w stronę przeciwną - delta za każdym razem się koryguje (średnia ważona, waga 4 na starą wartość, waga 1 na nową) - delta ma 8 bitów dokładności po przecinku, nowa jest przesuwana o 7 bitów bo interesuje nas połowa delty żeby rozłożyć czasu równomiernie po obu stronach - jeśli na Arduino mnożenie i dzielenie jest drogie (nie wiem tego) to *4 można zamienić na << 2 Nie kompilowałem/debuggowałem/testowałem tego kodu, więc ręki nie dam sobie uciąć, że wszystko działa poprawnie - ale pokazuje o co chodzi. EDIT: ta delta może być przedwczesną optymalizacją - bez tego pewnie średnio zadziała tak samo dobrze.

Nie jestem ekspertem od Arduino, ale aktywna pętla zwykle nie jest najlepszym rozwiązaniem. Nie lepiej użyć timerów i przerwań (rejestry TCCRxA i TCCRxB)? Rozdzielczość jest chyba taka sama jak zegara samego CPU.

Te 2 duże placki uparły się i nie chcą być okrągłe ale pozostałe gwiazdy już chyba są. Jest lepiej?

@Pav1007 @Tayson Mam jeszcze pytanie co do placków. Czy robiliście może kiedyś tak, żeby oddzielnie naświetlać gwiazdy, a oddzielnie DSy? Tzn zrobić serię na gwiazdy tak, żeby nie przekroczyć studni i serię na DSa nie przejmując się tak bardzo gwiazdami. Później złożyć to razem. Ma to sens?

Oczywiście to że są pojechane to błąd - to napisałem. Chodzi mi bardziej o maskowanie poszczególnych elementów, moim skromnym zdaniem to o jeden krok za daleko - ale przyznaję, że wygląda dużo lepiej.

Tak, przez maskę Bahtinova, nie poprawiałem już jej poźniej - a temperatura spadała. Jak wyszedłem po 30 min od ostatniego subframe'a to niebo było całe w chmurach. Odrzucone klatki mają masakrycznie mniejszy kontrast. Tak, Nebulosity na average'u. Wiem, że ma rację Jak znajdę czas to podejdę jeszcze raz, muszę ręcznie przejrzeć materiał i odrzucić poruszone subframe'y.

Zdaję sobie z tego sprawę. Uważam, że nieokrągłe placki to ewidentny błąd techniczny, też to że są przepalone. Ale to że placki są jest estetyką, a nie techniką. Moim zdaniem w momencie jak zaczynasz maskować obiekty oddzielnie, wchodzisz w sztukę, a nie technikę. Przecież równie dobrze mógłbym te placki usunąć i wstawić idealne białe kółka. Inna kwestia to skala tego zdjęcia, tam jest 0.6arcsec/px. Gdybym to zdjęcie zrobił DSLRem to pewnie bez zabawy było by wszystko okrągłe.

To nie sarkazm - napisałeś mi przy moim pierwszym zdjęciu, że zbyt bardzo wyciąłem szum i materiał. Pobawiłem się nim jeszcze i miałeś oczywiście 100% rację, pokazało się dużo więcej wartościowych gwiazdek. Zgodzę się też, że lekki szum poprawia odbiór - jakoś nie pomyślałem o tym o 3 w nocy jak szybko chciałem zobaczyć co z tego wyszło. Załączam takie, które wydaje się dobre + master darka. m102_oneframe.zip

Zaraz przejrzę klatki, żeby wybrać najostrzejszą. Co do tła, to oczywiście, że przykrywa szum - ale w tym tle nic więcej nie było. Tego się już nauczyłem z Twoich trafnych komentarzy, żeby nie wycinać wartościowego materiału Re naszej ostatniej dyskusji: wg Synscana (nie wiem na ile jest to dokładne) miałem około 30s błędu w obu osiach w ustawieniu na biegun. Przez godzinę obiekt uciekł prawie dokładnie w dół klatki - więc prawie po równo w osi RA i DEC.

Cześć! Obiekt M102 został odkryty przez Pierre'a Méchain'a i wpisany przez Messiera do jego katalogu. Jest jednym z brakujących obiektów w tym katalogu, który nie był jednoznacznie identyfikowany. Jego odkrywca, w liście wysłanym w 1783 do Johanna Bernoulli, dyrektora Akademi w Berlinie, twierdził, że obiekt ten jest omyłkową obserwacją M101 (Galaktyka Koło Zębate). Dowody historyczne wskazują jednak inaczej. NGC5866 (Galaktyka Wrzeciono) pokrywa się z opisem Méchain'a z oryginalnego druku katalogu Messiera z 1781 roku. Pozycja obiektu jest również zgodna z własnoręcznymi notatkami Charlesa Messiera do tegoż katalogu. Owen Gingerich zaproponował uznanie NGC5866 za do tamtej pory niejednoznaczny M102, taka interpretacja obowiązuje do dzisiaj. M101 / NGC5866 / Galaktyka Wrzeciono jest jasną galaktyką o magnitudo 9.81 i rozmiarze kątowym 6.3 x 2.7 minuty. Galaktyka jest ustawiona "krawędzią" w kierunku ziemi, stąd jej podłużny kształt przypominający wrzeciono. Linia pyłu przykrywa jej jądro cienkim ciemnym pasem. Ciekawostką jest, że oprócz NGC5866 również NGC3115 jest nazywana wrzecionem. NGC5866 jest galaktyką soczewkową typu S0. Galaktyka soczewkowa to typ pośredni pomiędzy eliptyczną a spiralną. Posiadają podobnie jądro do galaktyk eliptycznych, bardziej spłaszczone. Dysk wokół jądra nie ma śladów struktury spiralnej. NGC5866 jest położona około 47 mln lat świetlnych od Ziemi. Jest częścią grupy NGC5866, która zawiera między innymi obiekty NGC5907 i NGC5879. Jej masa została wyestymowana na 1 bilion mas Słońca. Zdjęcie: Korzystając z tymczasowego przejaśnienia i tego, że Andromeda była wysoko i po przeciwnej stronie Księżyca, widocznego w 80%, nastawiłem się na jej dopalenie moją starą (40D) lustrzanką. Aktualny stack ma za dużo szumu. Po rozstawieniu i skonfigurowaniu sprzętu okazało się, że nie naładowałem w staruszku baterii po ostatniej sesji. Szybko przesiadłem się na dużo węższy ASI290mc i szybko musiałem zdecydować się na coś innego - wystarczająco wysoko żeby "zniwelować" chmury i wystarczająco daleko od księżyca. Miałem ochote dopalić Whirlpoola, ale w ciągu godziny byłby już za nisko, padło na trochę wyżej położoną M102. Jak się przyjrzę to na zdjęciu widzę majaczące ramiona NGC5867 o magnitudo 16.77. Może tam są, a może to moja wyobraźnia Setup: MN190 / EQ6-R / ASI290mc bez guidingu 120x30s - odrzut 22 klatek ze względu na chmury 30x30s dark Obróbka bez masek i takich tam, stąd te kilka placków; gdybym się bardziej przyłożył do selekcji i odrzucił kilka poruszonych klatek, to pewnie nawet okrągłe by te placki wyszły. Soft: Nebulosity4 + Affinity Photo. Wersja 2.0.

prawie niezauważalnie = zauważalnie Niestety zrobiłem wtedy tylko 4 klatki - to było po sesji 40s tylko, żeby zobaczyć czy 90s też wyciągnie (zakładałem, że nie). Na 4 klatki 2 są takie jak załączyłem, 2 są bardziej pojechane.

Na dowód, że się da - załączam pojedynczego RAWa: - HEQ5, bez guidera, bez pasków, bez wymiany łożysk, bez regulacji - 90sek - 1000mm + ASI290MC = 0.6 arcsec / px Nie mam licencji na CCDInspectora, ale na oko te kilka gwiazd, które tam są, w najgorszym razie są prawie niezauważalnie pojechane. Series2_004.fit

Cool - to pełna zgoda PS: nie wiem w czyj dom celuje @piotr.d

I w praktyce masz rację, błąd w Dec będzie dużo bardziej/szybciej zauważalny. Narysuję o co mi chodzi, z rysunku moim zdaniem widać: - prędkości kątowe są równe, więc w tej sytuacji tracking będzie się spóźniał - oś R.A. montażu ma więcej niż 180 st - jeśli się niewiele pomylisz, to błędu w R.A pewnie nie zauważysz (w DEC odjedzie dużo szybciej)

I tak i nie jak nie trafisz w biegun to gwiazdy pojadą w obu osiach. Jak precyzyjnie trafisz to pojadą (bo po czasie zawsze pojadą) tylko w RA.

@Pav1007 już Ci napisał, tracking jest tylko w osi RA, więc nie przejmuj się DEC. Ustaw tracking na lunar dla księżyca, a sidereal na resztę. Jeśli używasz GOTO to z zależności od wybranego obiektu, Synscan sam ustawi odpowiedni tracking. Z mojego doświadczenia z HEQ5 i EQ6-R bez guidera wynika, że 60s przy tej matrycy powinieneś wyciągnąć, 120s to już jest większe wyzwanie - ale da się (nie bez klatek do wyrzucenia). Ważne jest precyzyjne ustawienie na polarną, po wyalignowaniu na 3 gwiazdy pilot pokazuje Mel= i Maz= to jest wyliczony błąd ustawienia na polarną, jak z nim zejdziesz poniżej 1 arcmin w obu osiach to na 60-120s powinno wystarczyć (piszę z doświadczenia, można to też dokładnie wyliczyć). Synscan ma dość fajną (prostą) metodę alignowania na polarną (w menu Setup/Align/Polar alignment), oczywiście nie będzie to tak dokładne jak dryf, ale na początek powinno Ci wystarczyć.

A propos bzdur - wytłumacz mi proszę czym się różni górna część studni od dolnej części studni

Ale przecież napisałem dokładnie to co Ty: 1. Ilość bitów przetwornika to rozpiętość tonalna* 2. Rozpiętość to nie szum. 3. Przez większą ilość klatek, efektywnie zwiększasz ilość bitów. Jak to się liczy napisałem (2 idealnie probabilistyczne klatki to o 1 bit więcej). Ty to powtarzasz pisząc jednocześnie, że piszę bzdury - hmmm.. 4. Przez większą ilość klatek niwelujemy też losowy szum (to tak jakby dodatkowy efekt stackowania). * - uproszczeniem w moim myśleniu było, że rozpiętość tonalna (głębokość studni/szum) jest conajmniej taka jak ilość bitów przetwornika. Jeśli tak nie jest to oczywiście puste bity niczego nie wniosą.

Nie myl szumu z rozpiętością, ilość bitów to rozpiętość tonalna.

Posłużę się (trochę koślawą) analogią: wyobraź sobie, że masz cyfrową metrówkę, która mierzy długość tylko z dokładnością do pełnego centymetra. Do tego masz lekkiego Parkinsona i trzęsą Ci się ręce (to żeby dodać probabilistyki do pomiarów, chwytanie elektronów jest probabilistyczne). Mierzysz daną długość i raz wychodzi Ci 10cm a raz 11cm - po kilku pomiarach stwierdzisz, że ta długość to 10.5. Jeśli na 4 pomiary w 3 będzie 10 a w jednym 11 - to uśrednisz do 10.25. Im więcej zrobisz pomiarów, tym większą dokładność uzyskasz i dokładność ta będzie większa niż dokładność urządzenia pomiarowego. Jeśli metrówka miała by o 1 bit więcej (czyli dokładność do połowy centymetra), to żeby uzyskać tą samą dokładność, mógłbyś zmniejszyć ilość pomiarów o połowę. Więc czysto teoretycznie, przy założeniu ceteris paribus, 2 bity więcej w przetworniku zmniejszają ilość pomiarów (sub-frameów) czterokrotnie, a 4 bity więcej 16-krotnie.

( 6.5 / 3.6 ) ^ 2 = 3.26 => Czyli f/3.6 jest 3.26x jaśniejszy od f/6.5. Dla przykładu, jeśli mają taką samą ogniskową, to ten jaśniejszy ma o 6.5 / 3.6 = 1.81 raza większą średnicę apertury. A jeśli mają taką samą aperturę, to ten jaśniejszy ma o 1.81 raza mniejszą ogniskową.

Jak to ciężko - jeśli porównujemy f/ do f/ to porównujemy tylko i wyłącznie światłosiłę - niezależnie od ogniskowej i apertury. Więc tak należy porównywać. Więc jeśli weźmiemy 2 teleskopy o dowolnie różnych aperturach i ogniskowych i stosunek liczb przysłony wynosi 2, to (pomijając obstrukcje i spadki na warstwach), jeden jest 4x jaśniejszy od drugiego.

Nie używałem tych aparatów do astro więc nie wypowiem się w tym temacie. W 2008 roku używałem dość dużo jak na amatora lustrzanek - i wtedy brałbym 50D (mniejsze szumy, większe iso, niezłe darki). Ale nie chcę zaczynać kolejnej świętej wojny pomiędzy C i N.