MateuszW

Każdy niech decyduje za siebie..., swoich bliskich i tych, których widuje na co dzień - za nich też trzeba zdecydować. Ja nie jadę, będą jeszcze zloty.

Czym innym jest przelotne minięcie kogoś w sklepie, a czym innym zjazd ponad 150 osób, którzy (co zrozumiałe) nie jadą tam dla izolacji, tylko wręcz przeciwnie. Wszelkie "zasady i obostrzenia", o ile będą przyjęte to czysta fikcja na takim zlocie. Każdy wymieni swoją "bazę wirusów programu avast" z co najmniej połową pozostałych. Trafi się jeden chory pechowiec - mamy ognisko zakażeń o którym będą trąbić w tvp.

Trzymam kciuki, żeby moje obawy nie miały nic wspólnego z rzeczywistością, a zlot był udany (o ile w ogóle będzie mógł się odbyć).

12 minut temu, kubaman napisał:

Mateusz, wiesz że tego teraz nie pokaże bo to była kamera główna, ale ten wątek ma 14 stron, i pokazywałem tutaj już że guiding nie likwiduje dryfu. Sam o tym pisałeś dwa dni temu.

Cały wątek nie ma sensu, bo wszyscy mają pamięć na pięć postów wstecz

 

 

Problemem nie jest pamięć, tylko problem w zrozumieniu siebie nawzajem. Tak, patrzyłem na ten wpis i nawet miałem się do niego odnieść. Być może to on najlepiej pokazuje ten paradoks. Tylko się upewnię - pierwszy jest wycinek zdjęcia z głównej kamery, a drugie to wykres guidingu przez oaga w trakcie tego zdjęcia, tak?

No to w takim razie wykres jasno pokazuje, że z punktu widzenia kamery guidującej wszystko jest cacy - tj na kamerze guidującej nie ma żadnego dryfu. Widać to po tym, że wykres nie dryfuje, oraz nie ma skoków tak silnych jak wielkość pojechnia klatki (a jest ona pojechana o ok 5-6"). Czyli guiding robi co trzeba i montaż mu tego nie blokuje. Natomiast równocześnie na kamerze głównej masz pojechane klatki i to jest nie do objęcia logiką. Jedyne wytłumaczenie, jakie na ten moment widzę, (choć uważam to za totalną abstrakcję) to że coś wewnątrz samych kamer lub złączek jest odrobinę luźne i powoduje takie różnice. Nie wierzę, że tak jest, ale nie mam innego logicznego pomysłu.

4 godziny temu, kubaman napisał:

Dzięki Mateusz.

Jak pisałem gdzieś tam wcześniej problem guidingu wynika najprawdopodobniej z faktu, że natychmiast po wykonaniu korekty enkoder wymusza ruch w pozycję, która wg niego jest właściwa, niwelując całą pracę guidingu i idąc dalej zgodnie z dryfem wynikającym ze złej prędkości RA. Enkoder ma priorytet wprowadzania korekt.

Np z tego:

19 godzin temu, kubaman napisał:

 

wynika, że tak nie jest. Przecież tu jak byk widać, że w części, gdy działał guiding, gwiazda się nie poruszała, była odpowiednio korygowana korektami guidingu. Natomiast po wyłączeniu guidingu, gwiazda zaczęła uciekać, zgodnie z dryfem. Gdyby było jak mówisz, czyli że po korekcie guidera montaż "niweluje" tą korektę enkoderem, to wykres w pierwszej połowie by uciekał tak samo, jak w drugiej. Ten wykres dowodzi, że gwiazda, podczas pracy guidera się nie porusza na kamerze guidera, nie dryfuje. Ale równocześnie, druga kamera, która patrzy przez ten sam teleskop (bo jest oag) rejestruje ruch. To jest kuriozalne. Jedyne logiczne wytłumaczenie, jakie teraz znajduję to że... matryca w jednej z kamer się rusza, albo sam korpus, albo złączki - jednym słowem coś pomiędzy jedną matyrycą, a drugą jest niedokręcone. Wiem że to absurd, ale to jedyne logiczne wyjaśnienie takiego fenomenu w teście z oagiem, jakie aktualnie widzę.

Jeśli chodzi o prędkość trackingu, to u mnie w CEM25EC ona również się delikatnie nie zgadzała - identycznie jak u Ciebie (w sensie dryfowania, a nie skoków). I również było to zależne od pozycji na niebie, a nie stałe. Z uwagi na zależność od pozycji na niebie, na pewno nie jest to kwestia źle wpisanej prędkości w sofcie, czy złego taktowania kwarcu itp. To jest efekt "geometryczny" i wg mnie mogą się na niego składać 3 rzeczy - błąd ustawienia bieguna (tak, biegun też wpływa na RA), błąd stożkowy, oraz błąd nierównoległości osi RA i Dec. Z polarną już walczyłeś, to ja bym spróbował ustawić błąd stożkowy, bo da się to zrobić na dovetailu (jednak nie pomogę, bo nigdy tego nie ustawiałem). Gorzej będzie z nierównoległością osi, bo zapewne brak takiej regulacji. Niemniej, nie potrafię powiedzieć, który element jak bardzo może wpływać na zmianę prędkości i jak dokładnie musi być ustawiony. U siebie zaobserwowałem, że im lepiej ustawię polarną, tym jest lepiej i przy błędzie < 10" jest to dla mnie wystarczające (2-3 min prowadzenia na skali ok 2"/pix). Dalej więc nie drążyłem tematu.

ALE - to wszystko ma znaczenie, jeśli chcesz uzyskać super dokładne prowadzenie bez guidingu. Jeśli masz guiding, to taka różnica nie powinna mieć żadnego znaczenia i guiding powinien to bez zająknięcia skorygować. Gdy focę na NEQ6, to mam przecież znacznie większy dryf, bo ustawiam polarną niedbale, a błąd PE dokłada swoje. Po to właśnie jest guiding, żeby to korygować. Dlatego nie widzę w tym wszystkim sensu, szczególnie patrząc na próbę z oagiem która wyklucza udział ugięć itp. Tam, jeśli na wykresie nie widać strzałów, to zdjęcie również powinno być poprawne, a nie jest. Nie mam pojęcia, czym to jest spowodowane i czy jest tu winny montaż czy nie.

12 minut temu, kubaman napisał:

ostatnie pytanie - czy tak zamontowana kamera jak w poprzednim moim wpisie powinna mieć w osi pionowej DEC czy RA?

 

W tej sytuacji pionowo masz RA, a poziomo Dec - łatwo to zrozumieć, bo oś Dec porusza się właśnie lewo - prawo, gdy stoisz za tubą.

14 godzin temu, kubaman napisał:

jak dla mnie to PHD2 trzyma gwiazdę, później ją gubi jak już nie może skorygować błedu, i jak załapie na nowo to znowu trzyma

Gdyby zgubił gwiazdę, to powinna być przerwa w wykresie, a nie ma nic takiego.

No przyznaję, że skoro takie podwójne gwiazdy daje setup z oagiem, gdzie na wykresie nie widać skoków, to jest na prawdę dziwacznie. Jedyne co wydaje mi się tu logiczne to bardzo szybkie skoki silnika (wywołane błędem enkodera), który skacze między pierwotną, a przesuniętą pozycją gwiazdy. I te skoki są znacznie krótsze od czasu naświetlania klatki guidera. Tylko czemu PHD nie złapał nigdy tej drugiej pozycji? Wtedy powinno być widać szarpnięcia wykresu...

Problemy dzisiejszego świata

Tak, zepsuli coś niedawno w DSS i nie czyta polskich znaków, wcześniej nie było z tym problemów.

A czy czasem zestawy do paskowania nie mają nowych płytek? Może ktoś kto przerabiał na paski będzie miał te oryginalne płytki niepotrzebne? Tak jest w NEQ6, ale w HEQ5 nie mam pewności.

ASI120 w f/8 nawet bez filtra pomiędzy nie da rady, a z filtrem to nie ma się co dziwić, to była murowana porażka. 

Od siebie mogę polecić ASI290, wybrałem ją u siebie do guidingu oagiem z uwagi na najbardziej sensowną charakterystykę szumową. No ale z filtrem narrowband... 

Godzinę temu, licho52 napisał:

Standard?  OAG za filtrami to standard?  Powiedziałbym że anomalia nie standard. 

Dokładnie. To tylko robienie sobie problemów.

Teraz, Pestek94 napisał:

To Ci pokażę różnice między nikkorem 35 a sigma 35 pod słońce :p przepaść ale nie róbmy offa, pomóżmy koledze.

No dobra, zdążyłem zapomnieć jak wygląda świat od tego astrofoto i że jest coś takiego jak Słońce  Człowiek myśli tylko o komie i aberracji chromatycznej...

Generalnie to po tym Nikkorze 35 f/2 nie ma się co dużo spodziewać, wystarczy zobaczyć na test: https://www.optyczne.pl/114.7-Test_obiektywu-Nikon_Nikkor_AF_35_mm_f_2D_Koma_i_astygmatyzm.html Niestety pod względem komy to fatalny obiektyw. Nie wiem czemu kosztuje rynkowo aż 1600 zł. 

4 minuty temu, Pestek94 napisał:

Z pewnością nie kupował bym arta stricte pod astro

A po co innego one potrzebne?  W żadnej innej dziedzinie nie zauważy się ich jakości optycznej. 

Godzinę temu, Adam87 napisał:

Róg i centrum przy F/4 na 35 2.0 D na FF

Samyang 35 f/1.4 jest moim zdaniem dobrym kompromisem cenowym - jeden z lepszych obiektywów o tej ogniskowej i w niskiej cenie. Wyniki mam znacznie lepsze, niż to co pokazujesz. Przyzwoicie jest już na f/1.8 - f/2, tak pod timelapsy, a tak do focenia i stackowania należy pójść w stronę f/2.8, wtedy jest już bardzo dobrze.

Szczerze mówiąc, jak na tak koszmarnie drogi montaż to te +-2,5 arcsec z enkoderem brzmi słabo. Ioptron ma lepszy i znacznie tańszy enkoder.

Lightroom to akurat ten nieliczny program, którego nie mam  Chyba że w camera raw można coś podobnego?

Cześć

Potrzebuję wyrównać serię zdjęć do timelapsa, gdzie w trakcie nastąpiło "kopnięcie" w statyw i od tego momentu zdjęcia są nieco przesunięte (i obrócone). Tak więc potrzebuję wyrównać klatki względem pierwszego planu, uwzględniając rotację. Tak na prawdę wystarczyłoby, aby program umiał przesunąć i obrócić serię zdjęć o zadane wartości, które jakoś sobie ustalę. Dałoby się to zrobić ręcznie w PSie, ale szukam czegoś wygodniejszego. Może to być więc albo program, który przesuwa i obraca zdjęcia o zadane parametry, albo taki który zalignuje po prostu całą serię, ale względem pierwszego planu, a nie ruchomego nieba.

O chłopie, chcesz żebym tu wrzucał wszystkie "kwiatki", jakie widuję w grupach FB? To będzie ze dwa na dzień  Już się przyzwyczaiłem, widząc coś takiego lekko się uśmiecham i idę dalej  

Super film, gratulacje!

Mi najbardziej spodobało się to ujęcie

2 godziny temu, Behlur_Olderys napisał:

Oczywiście, wydaje mi się, że na potrzeby astrofoto wystarczyłoby pewnie 100Base-T, gdyby wyciągnąć z niego maxa. 

Do foto DS, kamerą o "normalnej" ilości pikseli pewnie tak. Ale już nowsze CMOS nawet przy DS potrafią potrzebować transferu, a przy planetach nawet nie ma o czym mówić. 

2 godziny temu, Behlur_Olderys napisał:

W drugą stronę - nie widziałem jeszcze kamery astro z Ethernetem, a nie USB.

A światłowód może być?  https://www.qhyccd.com/index.php?m=content&c=index&a=show&catid=94&id=55&cut=1

2*10 Gigabit Fiber Port

Do tego dedykowana karta za 4 koła, ale to już grosze  

Swoją drogą, ciekawe kiedy będzie w astro upgrade USB z tzw 3.0 na USB 3.2 Gen 2 lub USB 3.2 Gen 2x2 (ale dziwak wymyślił te nazwy  )

4 godziny temu, kubaman napisał:

Zakładam więc, że poza problemem z montem sama RASA generuje część tych problemów.

No nareszcie dochodzisz do tego, do czego Cię usiłowałem już dawno przekonać  

Godzinę temu, Pav1007 napisał:

- nie ma absolutnie żadnego wpływu na optykę :-)

Tak, MLPT tuby nam nie skolimuje  Ale ta funkcja pozwala skompensować błędy prowadzenia / dryf wynikający z ugięć w optyce i o to zapewne chodziło w zdaniu Kubie  

52 minuty temu, Krzysztof z Bagien napisał:

Swoją drogą - te kamery "inżynieryjne" to po prostu Chameleony 3 (w wersji kolorowej) od FLIRa.

Moja kamera na Marsie 

51 minut temu, Behlur_Olderys napisał:

Robię ostatnio w branży automotive i tam wszystko jest na Ethernecie

Ale to chyba nie jest taki standardowy ethernet (w sensie stos protokołów), jak w zwykłych zastosowaniach, tylko któraś z tych przemysłowych odmian, prawda? Pytanie czy robi to różnicę w kontekście naszych zastosowań (systemu czasu rzeczywistego tu nie mamy).

43 minuty temu, Krzysztof z Bagien napisał:

Ale w sumie jest sporo kamer przemysłowych/naukowych na Ethernecie, tylko wersje na "zwykłym" gigabitowym ethernecie są niestety wolniejsze od USB 3, a te hulające na 10G kosztują majątek.

No właśnie. A potrzebujesz jeszcze mieć komputer z tym 10GBit. Raczej to już musi być standardowy PC z kartą rozszerzeń pci-express. Albo jakaś egzotyczna (i droga) konstrukcja z wbudowanym portem. Albo... adapter ethernet - > USB3   

4 minuty temu, Behlur_Olderys napisał:

 

Dziwne, że nie lepiej byłoby robić przez Ethernet? To dużo lepszy standard, dłuższe kable i wtyczki nigdy nie wypadają...

Jest sporo problemów. 1 - to nie jest za bardzo zgodne z "filozofią" tych standardów - USB służy do łączenia urządzeń peryferyjnych, a ethernet komputerów (choć w przemyśle też urządzeń). 2 - ethernet jest trudniejszy w implementacji w małych urządzeniach, nie da się zrobić prostego konwertera na uart i śmigać na atmedze8  Złącze ethernet jest duże - w części urządzeń nawet by się nie zmieściło. Switch ethernet jest również dużo większy i droższy od huba usb. Jest problem z zasilaniem - co prawda jest POE ale w wielu niezgodnych wariantach, a switch z poe kosztuje majątek. No i trzeba jakoś "ogarnąć" tą sieć, mieć serwer dhcp, znać adresy urządzeń itd. W konfiguracji byłoby to skomplikowane. No i jeszcze jedno - do użytku z kamerami ethernet 1Gb jest z kolei za wolny, a wszystkie szybsze nie są zbyt standardowe, a tym bardziej w laptopach więcej nie montują.

Ogólnie to dałoby się i pewnie działoby lepiej, ale nasze setupy musiałyby ważyć tak 2x więcej i tyleż więcej kosztować  No może trochę pesymistycznie.

Ale największy problem to brak przyjętej "tradycji" - żeby to miało sens, to każde urządzenie musiałoby mieć ethernet, a jeśli inne nie mają, to tego jednego też nikt tak nie podłączy bo to będzie niewygodne. Choćby właśnie montaże iOptrona mają opcjonalnie ethernet, no ale co z tego jak 10 innych urządzeń które używasz już potrzebuje USB. Dla prostoty lepiej podpiąć wtedy wszystko w jeden sposób.

A żeby nie było - kamera nagrywająca otwarcie spadochronu na Perseverance używa USB3  I jest to pierwsze wykorzystanie tego protokołu na Marsie.

Wg moich obserwacji, 90% problemów z USB to problem z niekontaktowaniem złącza. Wszystkie laptopy, z jakimi miałem do czynienia miały gówniane złącza - wtyczkę trzeba wpiąć w odpowiedni sposób, nie za mocno nie za słabo i potem broń boże nie dotykać  Jedne kable lubią być wsadzone do końca, inne wręcz przeciwnie - trzeba je trochę cofnąć żeby kontaktowały.

Hubów używałem kilka i niektóre miały również gówniane, niekontaktujące gniazda, a inne dobre. Nie ma to nic wspólnego z ich ceną - można kupić drogi z syfem, albo tani idealny. Niestety nie mam nic do polecenia z USB3.

No i problemy zwykle pogłębiają się na mrozie.

Generalnie nie mogę zrozumieć, dlaczego producenci złącz mają taki problem ze spełnieniem standardu i dokumentacji usb. No chyba że projekt gniazda USB-A jest z założenia zły i te lepsze złącza wprowadziły swoje ulepszenia?

Teraz, MattN napisał:

Tylko nie kumam czemu wszyscy lobbują za podłączaniem przez rs232 i inne technologie sprzed 20lat, jak w pilotach zaczęli robić wejścia usb niewymagające żadnych sterowników. 

To USB to jest taka sama technologia sprzed 20 lat, jak rs232 obok, tylko że konwerter rs232 - usb jest w pilocie zamiast na zewnątrz  I wymaga ono tak samo sterowników do zastosowanego tam konwertera, tylko jest to pewnie ftdi który zwykle instaluje się sam.

Generalnie większość ludzi podpina się inną metodą, zamiast pilota i wtedy nie ma już usb do wyboru.

16 minut temu, wajoman1991 napisał:

@MateuszW włączam COM ten co jest podłączony kabel, sprawdzam w menedżerze urządzeń, próbuje już na każdym usb i dalej cisza. Pilot w PC direct mode.

A jaką prędkość transmisji wybrałeś w eqmod? Nie wiem jaka jest w tym przypadku właściwa, ale było z tego co pamiętam tylko 2 do wyboru, więc sprawdź obie  

@All - Strasznie mieszacie różne metody połączenia, mętlik się robi w wątku. To można zrobić na 10 sposobów i jak będziemy próbować wszystkich na raz, to nic się nie uda.

4 minuty temu, wajoman1991 napisał:

Na tym się zatrzymuje. Za cholere nie chce połączyć

Jak wyglądają ustawienia eqmoda? Wybrałeś tam com3, jak w menedżerze? Włączyłeś tryb pc direct mode?