Skocz do zawartości

Zakrycie planetoidalne podczas najbliższego zlotu w Lipowcu


Agent Smith

Rekomendowane odpowiedzi

24 minuty temu, Gajowy napisał:

BTW2, Osobiście korzystam z własnego programu do rejestracji obrazu z kamery (Tapir), który dodatkowo wykorzystuje najbardziej precyzyjny z możliwych odczyt zegara komputera (dokładność wg dokumentacji wykorzystywanych funkcji <100 ns :) ) i ma parę fajnych cech niedostępnych w FC i innych softach tego typu.

Hmm, a podeślesz? :P Czy to na linux? Zasadniczo mógłbym na potrzeby rejestracji tranzytów zainstalować jakąś super stabilną dystrybucję linuksa czasu rzeczywistego...

24 minuty temu, Gajowy napisał:

P.S. Jednym z pomysłów na test jakości synchronizacji jest wykorzystanie... sztucznych satelitów i rejestracja ich ruchu wraz ze znacznikami czasu, a następnie porówanie z efemerydami.

Dobry pomysł!

24 minuty temu, Gajowy napisał:

Moje badania wskazują, że przy dobrym dostępie do Internetu, za pomocą poprawnie zaimplementowanego protokołu NTP można uzyskać dokładność pomiaru czasu rzędu 0.001 sek.

"Dobrym"... Czyli zapewne po kablu? W polu raczej nie ma co liczyć na coś więcej, niż sieć komórkowa + router z telefonu + wifi. A to równa jest całkowite zaprzeczenie stabilności. Chyba lepszy jednak ten gps jako wstępna synchronizacja.

 

BTW, czy poza SDK ZWO bawiłeś się może PointGreyem? Co myślisz o wykorzystaniu jej pinów gpio do przekazania sygnału pps? Tych pinów używa się np do wyzwalania migawki na jakiejś linii produkcyjnej gdy czujnik wykryje przedmiot. Raczej jest to szybkie medium i wejdzie "między" ramki ze zdjęciami.

Edytowane przez MateuszW
Odnośnik do komentarza
Udostępnij na innych stronach

44 minuty temu, MateuszW napisał:

No właśnie, a nas interesuje raczej tryb wideo? Choć w sumie nie wiem, czy wybór zapisu jako zdjęcia wpływa na tryb pracy kamery?

Wydaje mi się, że taka metoda, jaką opisałeś, wnosiłaby zbyt duże straty czasu, tj te wszystkie oczekiwania zamiast wykonywania maksymalnej ilości klatek jaką się da.

Masz rację. Do obserwacji zakryć jedynie tryb video - ale znowu, pod warunkiem, że opanujemy wszystkie opóźnienia, inercje i stratę ramek.

I tak, przynajmniej w wypadku ASI (choć myślę, ze to standard) tryb video różni się od trybu zdjęć. W trybie zdjęć żądasz każdego zdjęcie osobno i odczytujesz osobno. W wypadku video - wysyłąsz żądanie, kamera działa dopóki jej nie każesz przestać, a w międzyczasie odbierasz zdjęcia. Jeśli nie zdążysz odebrać - przepadają.
Zajrzyj tu, rodział 4: https://astronomy-imaging-camera.com/software/ASI_Windows_SDK_V1.13.0930.zip

 

44 minuty temu, MateuszW napisał:

Spróbuję jeszcze dla zabawy poanalizować ramki USB w WireShark :) Niedawno sobie uświadomiłem, że jest taka możliwość. Ze wstępnych oględzin wygląda na to, że ramki od komputera do kamery wysyłane są bardzo rzadko i raczej nie decydują o otwarciu migawki. Ale na razie nawet nie mam pewności, że patrzyłem na właściwe urządzenie :P

Z komputera do kamery to pewnie polecenie otwarcia miagwki, a pozniej kopiowanie danych. Napisz, jak to przeanalizujesz.

 

44 minuty temu, MateuszW napisał:

Jest taka jedna QHY. Nie znajdzie się jakaś przemysłowa może trochę taniej?

Dla przemysłowych GPS, a zwłaszcza tak precyzyjny GPS chyba potrzebny nie jest... QHY 174 chyba, nie? Mam nadzieję ją wkrótce obejrzeć...

 

44 minuty temu, MateuszW napisał:

Hmm, a jak to się ma do kwestii tego magicznego bufora w nowych wersjach asi, który zapobiega ampglow? Skoro w każdej kamerze jest bufor na jedną klatkę, to jakim prawem ten amp glow się pojawia? Zakładałem, że dane są przesyłane bezpośrednio z matrycy do kompa, co by tłumaczyło ampglow na wolniejszym połączeniu. Jeśli jest bufor to nie widzę jak to jest możliwe.

Nie wiem co to jest ampglow, używam ASI 290MM z krótkimi czasami :P. Bufor może przechowywać więcej ramek niż jedną, ale więcej szczegółów na ten temat nie udało mi sie zdobyć, ani nie badałem tego (w zasadzie za pomocą SDK można to było przetestować).

 

Odnośnik do komentarza
Udostępnij na innych stronach

9 minut temu, Gajowy napisał:

Dla przemysłowych GPS, a zwłaszcza tak precyzyjny GPS chyba potrzebny nie jest... QHY 174 chyba, nie? Mam nadzieję ją wkrótce obejrzeć...

Na pewno znajdą się zastosowania. Kiedyś się dziwiłem, po co w przemyśle takie czułe matryce planetarne :) A co do precyzji - to my tu nie potrzebujemy nic więcej, niż dają zwykłe, popularne odbiorniki. Profesjonalne GPSy np do geodezji to potrafią kosztować dopiero majątek.

Tak, 174. Kurcze, gdyby była wersja niechłodzona, to może bym nawet kupił, sprzedając równocześnie ASI 174 i nie byłoby drogo. Ale za chłodzenie też trzeba dopłacić, a ono mi zbędne.

13 minut temu, Gajowy napisał:

Nie wiem co to jest ampglow, używam ASI 290MM z krótkimi czasami :P. Bufor może przechowywać więcej ramek niż jedną, ale więcej szczegółów na ten temat nie udało mi sie zdobyć, ani nie badałem tego (w zasadzie za pomocą SDK można to było przetestować).

Ampglow to zaświetlenie matrycy wywołane nagrzewaniem się elektroniki podczas odczytu danych. W ASI podpiętych na USB2.0 występuje z powodu wolnego transferu. Na 3.0 nie ma problemu. No a żeby zapobiec problemom na 2.0, to wprowadzili właśnie dodatkowy bufor (wersje "Pro").

Odnośnik do komentarza
Udostępnij na innych stronach

56 minut temu, MateuszW napisał:

Hmm, a podeślesz? :P Czy to na linux? Zasadniczo mógłbym na potrzeby rejestracji tranzytów zainstalować jakąś super stabilną dystrybucję linuksa czasu rzeczywistego...

Oczywiście, mogę udostępnić. Program działa jednak w trybie zdjęć poklatkowych - używam go do astrometrii, gdzie FPS nie jest kluczowy (w moim setupie pełnoklatkowy FPS to 10; większość traconego czasu to inercja kamery na żądanie wykonania zdjęcia).

 

Program działa pod Windowsem. Jaką masz wersję systemu?

 

56 minut temu, MateuszW napisał:

 

"Dobrym"... Czyli zapewne po kablu? W polu raczej nie ma co liczyć na coś więcej, niż sieć komórkowa + router z telefonu + wifi. A to równa jest całkowite zaprzeczenie stabilności. Chyba lepszy jednak ten gps jako wstępna synchronizacja.

U mnie ejst WiFi, ale faktycznie zasilane światłowodem. Spróbuję za chwilę z komórką, czemu nie :).

 

56 minut temu, MateuszW napisał:

 

BTW, czy poza SDK ZWO bawiłeś się może PointGreyem? Co myślisz o wykorzystaniu jej pinów gpio do przekazania sygnału pps? Tych pinów używa się np do wyzwalania migawki na jakiejś linii produkcyjnej gdy czujnik wykryje przedmiot. Raczej jest to szybkie medium i wejdzie "między" ramki ze zdjęciami.

Nie, nie znam PoitGreya. Możesz w  parku słowach opsiać, albo podesłać jakiś link?

 

Pozdrawiam,

Gajowy

Odnośnik do komentarza
Udostępnij na innych stronach

23 minuty temu, Gajowy napisał:

Oczywiście, mogę udostępnić. Program działa jednak w trybie zdjęć poklatkowych - używam go do astrometrii, gdzie FPS nie jest kluczowy (w moim setupie pełnoklatkowy FPS to 10; większość traconego czasu to inercja kamery na żądanie wykonania zdjęcia).

 

Program działa pod Windowsem. Jaką masz wersję systemu?

Dzięki! Mam Win10 64bit

23 minuty temu, Gajowy napisał:

Nie, nie znam PoitGreya. Możesz w  parku słowach opsiać, albo podesłać jakiś link?

Cóż, mam taką kamerkę: https://www.ptgrey.com/chameleon3-usb3-vision-cameras. Już dość stara, z epoki ASI120 :) Jest tam z tyłu takie złącze, gdzie można podłączyć jakiś sygnał cyfrowy i go później odczytać w sdk. To jest odpowiednik ASI174: https://www.ptgrey.com/grasshopper3-23-mp-mono-usb3-vision-sony-pregius-imx174-camera. Analogicznie, masz tam okrągłe złącze do wykorzystania w sofcie. Niestety, nie wgłębiałem się w tą sprawę bardziej niż to, że da się tych pinów użyć i odczytywać ich stan :)

Odnośnik do komentarza
Udostępnij na innych stronach

On 1/18/2019 at 11:14 AM, burza said:

Polecam więc optymalne rozwiązanie - nagrywać zjawisko kamerami USB, zsynchronizować czas komputera z serwerem NTP na 5 min przed zjawiskiem, a jednocześnie zastosować nagrywanie głosem na dyktafon wg metody podanej wyżej. Kombinacja tych dwóch służb czasu będzie już na tyle dokładna, że wyniki można posłać w świat.

 

@burza, ja tu jednej rzeczy nie kumam: skoro efemeryda głosi "max duration 3,9 sek" a my jesteśmy na skraju pasa zakrycia, możemy pewnie spodziewać się czasów dużo krótszych niż 3,9 sek. Jaki więc sens miałaby w takim wypadku obserwacja wizualno-wokalna? No nie bardzo sobie to wyobrażam... :)

To już jeśli jechać w takie prowizorki, to chociaż jakieś pikadła akustyczne sobie zmontować...słowo daję duch Romana F. się nad tym unosi :)

 

Skoro jesteśmy przy pikadłach chciałbym tutaj wspomnieć o potencjalnie użytecznym (tak mi się wydaje) programem na Androida, a mianowicie Time The Sat  - sporo możliwości, pika, gada, zapisuje nasze naciśnięcia klawiszy (z "dokładnością" do trzech miejsc po przecinku), synchronizuje czas z ntp i innymi serwerami do wyboru.

 

TTServer1.jpg.9618615845df946ded757316c3c5d466.jpg

Kolegów "cyfrowców", którzy chcą  chciałbym zapytać o jedną rzecz: jaka jest czułość posiadanych przez Was kamer przy krótkich ekspozycjach ?

Mówiąc szczerze nie mam pojęcia i ciekaw jestem czy kiedykolwiek to testowaliście, tj jaki zasięg łapiecie swoim zestawem kamera/teleskop przy ekspozycji 1/25 czy 1/30 sek?

@MateuszW - czuj się wywołany do tablicy :)

 

Ja doświadczenia z cyfrówkami praktycznie nie posiadam (guiding się nie liczy) więc jeśli chodzi o zakrycia pozostanę na razie przy przestarzałych kamerach analogowych, zwłaszcza że ostatnio zakupiłem kilka sztuk: Samsunga SCB-2000 (za 100 zł), Watec-902B (za 250 zł) oraz polecaną (i sprzedawaną) przez IOTA RunCam Night Eagle 2 Pro Astro, która kosztuje teoretycznie 79 USD ale za przesyłkę panowie doliczają sobie $55 a celnicy z Okęcia, którzy na niej siedzą i którą może łaskawie wypuszczą w Poniedziałek doliczą do tego wszystkiego kolejne 30-parę procent...no nic, to i tak w sumie ułamek ceny porządnej kamery cyfrowej.

Więcej na jej temat: http://occultations.org/wp/wp-content/uploads/2018/03/READ-ME-file-for-RunCam-Night-Eagle-PRO-2-Astro-Edition-v1.2.pdf a zwłaszcza tu:

http://occultations.org/wp/wp-content/uploads/2018/03/RunCam-Night-Eagle-Astro-Camera-Review-Operating-Guidelines-and-Comments-v7.pdf

 

Topowa kamera analogowa (i pewnie dużo czulszych kuż nie będzie) - Watec-910HX/910BD to koszt ok 800USD.

Ciekawy projekt z nią związany - TACOS (mniam):

http://www.kuriwaobservatory.com/TACOS_BD-System.html
 

Chciałbym ze swoich kamerek zmontować 2 stanowiska obserwacyjne (oczywiście z użyciem VTI :)) - jedno na Newtonie 150/600 drugie na achromacie 100/500 (w obu wypadkach z reduktorem ogniskowej 1:2) 

Z braku pogody na testy wszystko będzie wielką improwizacją, nie mam bladego pojęcia czego (w zakresie zasięgu) mogę się spodziewać - zobaczymy :)

 

Tu jeszcze jeden temat a'propos zakryć - metoda dryfu:

image001.jpg.ee15578094c9cc51e05038a809f9f877.jpg

http://www.asteroidoccultation.com/observations/DriftScan/Index.htm

Więcej o metodologii:

https://www.rogergroom.com/projects/occultation-timing-recording/occultation-timing-drift-scan-technieque/

 

Wielka zaleta to fakt, iż można tu wykorzystać oba rodzaje kamer, oraz łatwość obserwacji "zdalnych".

Problemem jest timing.

 

Lecę skręcać obudowę swojego VTI :)

 

PS: @MateuszW - pewnie wiesz, ale się upewnię: większość odbiorników GPS gasi diodę LED na pełnej sekundzie :)

 

 

 

 

Odnośnik do komentarza
Udostępnij na innych stronach

1 godzinę temu, Agent Smith napisał:

@burza

Kolegów "cyfrowców", którzy chcą  chciałbym zapytać o jedną rzecz: jaka jest czułość posiadanych przez Was kamer przy krótkich ekspozycjach ?

Mówiąc szczerze nie mam pojęcia i ciekaw jestem czy kiedykolwiek to testowaliście, tj jaki zasięg łapiecie swoim zestawem kamera/teleskop przy ekspozycji 1/25 czy 1/30 sek?

@MateuszW - czuj się wywołany do tablicy :)

A ja mogę? :-) 10 mag rejestruję w czasie poniżej 0.01 sek używając 11" RASA + ASI 290MM. Przy 1/25 sek to będzie ok. 12 mag.

 

Moim zdaniem, póki co jednak kamery analogowe wydają się być bardziej przewidywalne, zwłaszcza jeśli chodzi o obserwacje zakryć przez planetoidy pasa głównego. Będzie tak dopóki nie zostanie opisana pełna charakterystyka wszystkich opóźnień w konkretnym setupie. Zakrycia przez obiekty dalsze, pasa Kuipera albo nawet przez Centaury nie wymagają już tak dużej częstotliwosci próbkowania.

Sam mam zarówno inserter Tomka Wężyka, kamerę Watec jak i setup z cyfrówką. Cyfrowa ma tę podstawową zaletę, ze jest o niebo mniej kablologii i jest prostsza w obsłudze.

 

Pozdrawiam,

Gajowy

 

 

Odnośnik do komentarza
Udostępnij na innych stronach

3 minuty temu, Agent Smith napisał:

Ajajaj! Gratuluję pięknego setupu.

A którego Wateca masz?

Pozdro

Agent

Dzięki. Szkoda że przez pogodę się tylko kurzy.

Watec to 120N+. Używam jej na SCT 8", zasięg przy czasach 1/25 sek to jakieś 9-10mag.

 

Pzdr,

Gajowy

Odnośnik do komentarza
Udostępnij na innych stronach

2 godziny temu, Agent Smith napisał:

Kolegów "cyfrowców", którzy chcą  chciałbym zapytać o jedną rzecz: jaka jest czułość posiadanych przez Was kamer przy krótkich ekspozycjach ?

Mówiąc szczerze nie mam pojęcia i ciekaw jestem czy kiedykolwiek to testowaliście, tj jaki zasięg łapiecie swoim zestawem kamera/teleskop przy ekspozycji 1/25 czy 1/30 sek?

@MateuszW - czuj się wywołany do tablicy :)

To ja tutaj przedstawię wynik z ASI178MM-c przy 1/15s oraz średnicy obiektywu 10cm (który jest u Ciebie ;)). Gwiazda na samym środku ma 11.2 magnitudo. Przy tak krótkich czasach, jakość gwiazdy można wyznaczyć matematycznie. Na przykład, tak powinna być widoczna dla 10.2 mag przy 2.5x krótszym czasie, czyli ~1/40s. Od razu podałem link, gdzie zobaczysz jak wyszła krzywa blasku z takiego zakrycia.

https://www.youtube.com/watch?v=xajJXoVy460

https://astropolis.pl/topic/61088-zakrycie-planetoidalne-1072-malva-29-września-2017-roku/

 

Odnośnik do komentarza
Udostępnij na innych stronach

2 minuty temu, Agent Smith napisał:

To jeszcze podpytam - a jak zapisujesz sygnał analogowy ?

Za każdym razem uczę się tego od nowa ;-). Kamera połączona z inserterem, odbiornik GPS z inserterem, inserter podłaczony do grabbera, a grabber do komputera. Wszystko opiera się na jakiś przedpotopowych sterownikach niezgodnych z niczym ;-).

 

Pzdr,

Gajowy

Odnośnik do komentarza
Udostępnij na innych stronach

2 godziny temu, Agent Smith napisał:

@MateuszW - czuj się wywołany do tablicy :)

Ja akurat nie wiem, bo nie robiłem nigdy takich testów :) Uważam jednak, że nie ma powodu, aby nowoczesne kamery, z minimalnymi szumami odczytu i wysokim QE mogły jakoś odstawać od kamer analogowych (które tak na prawdę tak samo rejestrują światło, tylko stosują stratny i wprowadzający dodatkowy szum sposób transmisji).

  • Lubię 1
Odnośnik do komentarza
Udostępnij na innych stronach

7 minutes ago, Gajowy said:

Za każdym razem uczę się tego od nowa ;-). Kamera połączona z inserterem, odbiornik GPS z inserterem, inserter podłaczony do grabbera, a grabber do komputera. Wszystko opiera się na jakiś przedpotopowych sterownikach niezgodnych z niczym ;-).

 

Pzdr,

Gajowy

Zaraz tam przedpotopowych...działa? Działa!

To będę pytał dalej: a ten grabber to jakim obsługujesz programem i z jakim kodekiem?

 

Ja kupiłem jakiś lipa-grabber, żadnych sterów nie wgrywałem (inna rzecz, że w tym kompie mam nadmiar wszystkiego) no i w SharpCapie na przykład za cholerę nie pozwala ustawić PAL'owej (PAL'owskiej? Trza by zapytać Azję Tuchajbejowicza) prędkości 25 czy 24 kl/s. Wyłącznie takie, które się dzielą przez 15 (czyli NTSC)

Ale kamera (Watec) jest na 100% PAL. Więc o co chodzi?

Może ten grabber jest tylko w NTSC, mimo że go reklamują jako wszechsystemowy?

A może trzeba zrobić wyjątek i wgrać coś z podejrzanej małej płytki CD... :-8

 

Interesuje mnie też temat zapisu "bezkomputerowego". Stare kamery DV - wiadomo. Ale kodek DV to nie jest do końca niewiniątko.

A więc DVR - moda na drony i kamerowa paranoja dały nam masę mniejszych lub większych urządzeń pod tą nazwą (najmniejszy jaki mam jest wielkości połowy pudełka zapałek i nie zużywa wcale prądu ;))

No ale tu z kodekami jest problem: dominują odmiany MPEG4 (interframe), które odpadają. Zaś te (które widziałem) reklamowane jako MJPEG (intraframe) z reguły mają maks 480 linii poziomo, więc coś opisywane przez nich jako PAL D1 nim nie jest.

 

Coś? ktoś?

@burza, może Ty coś wiesz?

 

Dzięki

Nikodem

Odnośnik do komentarza
Udostępnij na innych stronach

Panowie i panie, mam rozwiązanie!!!

Udało mi się ogarnąć, do jak wykorzystać piny GPIO w Chameleon 3. Analogiczna sytuacja powinna być w innych kamerach PointGreya, które opierają się o te same matryce, co ZWO. Zapraszam na krótki film, mam nadzieję że da się mnie jakoś słuchać :) 

Moja kamerka jest dość stara, ale wyciąga prawie 100 FPS przy malutkiej rozdzielczości. Szumy odczytu ma raczej wysokie i pewnie nie będzie tak dobrze z zasięgiem gwiazdowym. Ale to CCD, więc można użyć sprzętowy bin2, który powinien znacznie poprawić sprawę. W połączeniu z 8" f/4 może uda się uzyskać jakieś 50 fps na tej gwiździe?

 

Koniec końców, myślę zrobić takie urządzenie: 

Do arduino podłączę gps poprzez uart oraz sygnał pps. Podłączę pod niego również dwa piny gpio kamery Chameleon. Arduino będzie też wpięte do komputera poprzez port szeregowy (na usb). Za pomocą terminala będę mógł wybrać w arduino godzinę rozpoczęcia nagrywania. Gdy nastanie ta godzina (z dokładnością do sekundy), arduino odebrawszy sygnał pps, wyśle sygnał do triggera kamery, aby ta rozpoczęła film. Podpięty będzie również sygnał zwrotny, którym kamera sygnalizuje moment rozpoczęcia naświetlania. Arduino będzie zapisywać czas kolejnych klatek na podstawie tego sygnału i wysyłać wartości po porcie szeregowym do komputera - w celu ich zapisania, tu już nie mają znaczenia opóźnienia. Teoretycznie sygnał uruchomienia kamery jest precyzyjny, ale jest jakieś opóźnienie (może dokumentacja podaje?), więc odczytując sygnał od kamery, powinienem je poznać. Ten sygnał zwrotny powinien już być pozbawiony opóźnień. No i zapisując czas każdej klatki uodparniam się na wahania prędkości kamery, czy zgubione ramki.

 

Dla zainteresowanych w załączniku dokumentacja kamery (trzeba założyć konto, żeby pobrać...). Interesuje nas rozdział 6, od strony 29.

 

CM3-U3-Technical-Reference.pdf

Edytowane przez MateuszW
  • Lubię 1
  • Dziękuję 2
Odnośnik do komentarza
Udostępnij na innych stronach

13 minut temu, Agent Smith napisał:

Zaraz tam przedpotopowych...działa? Działa!

To będę pytał dalej: a ten grabber to jakim obsługujesz programem i z jakim kodekiem?

Muszę to wszystko ponownie podłączyć żeby odpowiedzieć na Twoje pytania. Robię to raz na kilka miesiecy i zwykle mija ponad godzina zanim mi to zacznie działać. Więc odpowiem na Twoje pytania, jak tylko to popodłączam.

 

Pzdr,

Gajowy

Edytowane przez Gajowy
  • Dziękuję 1
Odnośnik do komentarza
Udostępnij na innych stronach

16 minut temu, MateuszW napisał:

Podpięty będzie również sygnał zwrotny, którym kamera sygnalizuje moment rozpoczęcia naświetlania.

I to jest klucz. Jeśli kamera może wysłac taki sygnał to właściwie jesteśmy w domu. Jak precyzyjny jest moment pojawienia się tego sygnału?

 

Pzdr,

Gajowy

  • Lubię 1
Odnośnik do komentarza
Udostępnij na innych stronach

42 minutes ago, MateuszW said:

Panowie i panie, mam rozwiązanie!!!

(....)

Dla zainteresowanych w załączniku dokumentacja kamery (trzeba założyć konto, żeby pobrać...). Interesuje nas rozdział 6, od strony 29.

 

CM3-U3-Technical-Reference.pdf

Mateusz, Panie się napewno ucieszą, zwłaszcza o tej porze ! :)

Słuchać się da, spoko. ++++  szacun.

Nawet sobie rano puszczę jeszcze raz bo żona moja już śpi.

Za wolny jestem niestety, żeby w 6 minut ogarnąć w pełni doniosłość Twojego odkrycia ale wyłapałem tyle, że możesz tą metodą zapisać dokładnie czas otwarcia i zamknięcia migawki.

Wnoszę też, iż uskrzydlony tym wynalazkiem zamierzasz bić rekord w ilości zapisanych klatek na sekundę (przecież zawsze można kupić sobie czulszą/droższą/szybszą kamerę! ;)) i oczywicie tak długo jak trzymasz służbę czasu w ryzach też ma to sens - oczywiście o ile przekonasz do swojej metodologii "świętych starców" z IOTA itp. :)

Za to też trzymam kciuki, wymiatasz bracie w te klocki, no questions asked.

 

Mnie to jednak zainteresowało od trochę innej strony - jak być może wiesz (podawałem przykładowe linki powyżej) właśnie to, co osiągasz swoją metodą jest piętą achillesową obserwacji metodą dryfu. Ludzie cuda jakieś wymyślają, mikrofony przyklejone do kamer, żeby zapisać kliknięcie na ścieżce audio etc, to dopiero jest oldskul! :)

Więc jakby tak zamiast jak najszybciej, puścić tę kamerę jak najwolniej? To by mogło być czaderskie!

Tu mam pytanka (jeśli pisałeś o tym a ja przegapiłem podlinkuj please:

- które konkretnie modele kamer posiadają tę magiczną właściwość ?

- jakie mają najdłuższe czasy naświetlania ? (czy wykonalne jest "B"?)

- czy jest możliwe, że kamery jakiegoś innego producenta (wspomniałeś o ZWO?) mają te złącza na płytkach we wnętrzu obudowy, czyli w bebechach?

 

Aha: nie trzeba zakładać konta, wystarczy "kliknij prawym i zapisz jako" :)

 

Dzięki, podziwiam i gratuluję!

Nikodem

 

 

  • Lubię 1
Odnośnik do komentarza
Udostępnij na innych stronach

15 minut temu, Gajowy napisał:

I to jest klucz. Jeśli kamera może wysłac taki sygnał to właściwie jesteśmy w domu. Jak precyzyjny jest moment pojawienia się tego sygnału?

 

Pzdr,

Gajowy

W dokumentacji chyba nie mówią tego wprost, ale wygląda na to, że jest to natychmiastowe - czyli pewnie jakoś sprzętowo sprzężone z matrycą. Piszą tam natomiast, że można sobie zmierzyć opóźnienie między triggerem, a rozpoczęciem naświetlania właśnie porównując czas impulsu triggera, oraz impulsu zwrotnego kamery. Czyli ja bym założył, że sygnał zwrotny jest idealny.

 

Ale jest jeszcze coś - rozkmiłem te informacje zapisywane w klatkach, o których mówiłem na filmie. To jest bardzo pomysłowe :)

image.png.a14d2158dc6c0bee3897143a55f037ac.png

Otóż, one są faktycznie na klatce, na obrazie :) Ale nie jako ładne cyferki, jak z insertera, tylko cyfrowo - jako jasność pikseli. To, co widać w narożniku screena, to akurat zapisany timestamp.

I teraz myślę, że lepiej będzie to wykorzystać. Tzn podłączyć sygnał PPS z GPS do kamery jako input, a na klatce zapisywać timestamp, oraz stan pinów (czyli pps). Timestamp jest jak zrozumiałem generowany przez samą kamerę, oczywiście to tylko względna wartość. Jest on mierzony w momencie zakończenia ekspozycji. Teraz na podstawie analizy tych danych (trzeba by napisać program, który to odczyta), czyli względnego timestampu, stanu pinu pps, oraz czasu rozpoczęcia nagrywania (z windowsa) powinno się dać ustalić precyzyjnie czas każdej ramki. Metoda ta ma przewagę nad poprzednią (czyli zapisywanie czasu na arduino), bo nie trzeba tu właściwie nic sprzętowego robić - starczy podłączyć GPS do kamery, bez żadnego arduino i żadnego programowania! Otrzymujemy w efekcie coś bardzo podobnego do QHY174 GPS :)

Odnośnik do komentarza
Udostępnij na innych stronach

9 minut temu, Agent Smith napisał:

Wnoszę też, iż uskrzydlony tym wynalazkiem zamierzasz bić rekord w ilości zapisanych klatek na sekundę (przecież zawsze można kupić sobie czulszą/droższą/szybszą kamerę! ;))

Chyba zawsze rejestrowało się najwięcej, jak tylko się da :) Wszystko determinuje jasność gwiazdy i czułość sprzętu. Ta moja obecna kamerka demonem nie jest, ale chyba sprzedam ASI174 i kupię odpowiednik PointGrey, żeby mieć już świetne wyniki.

11 minut temu, Agent Smith napisał:

Mnie to jednak zainteresowało od trochę innej strony - jak być może wiesz (podawałem przykładowe linki powyżej) właśnie to, co osiągasz swoją metodą jest piętą achillesową obserwacji metodą dryfu. Ludzie cuda jakieś wymyślają, mikrofony przyklejone do kamer, żeby zapisać kliknięcie na ścieżce audio etc, to dopiero jest oldskul! :)

Więc jakby tak zamiast jak najszybciej, puścić tę kamerę jak najwolniej? To by mogło być czaderskie!

Chodzi Ci o to, żeby precyzyjnie zapisać czas jednej ekspozycji, na której zrobimy pojechaną gwiazdkę z widocznym zakryciem? No też dałoby się to zrobić.

12 minut temu, Agent Smith napisał:

Tu mam pytanka (jeśli pisałeś o tym a ja przegapiłem podlinkuj please:

- które konkretnie modele kamer posiadają tę magiczną właściwość ?

- jakie mają najdłuższe czasy naświetlania ? (czy wykonalne jest "B"?)

- czy jest możliwe, że kamery jakiegoś innego producenta (wspomniałeś o ZWO?) mają te złącza na płytkach we wnętrzu obudowy, czyli w bebechach?

Czasy ekspozycji zależą od modelu. U mnie jest słabo, bo jakieś 30 s... Cóż, to raczej planetarne, niż dsowe kamery.

Jeśli nie wszystkie, to większość kamer tego producenta ma wymagane złącze. Lista kamer jest tu:

https://www.ptgrey.com/Camera-selector#InterfaceValueId=510

Sprzedają też wiele modeli z innym interfejsem, niż USB. Swego czasu te kamery był nawet popularne wśród planeciarzy. Potem przyszło ZWO i zgarnęło rynek :) Bo w ZWO wychodzi zazwyczaj trochę taniej.

Jeśli chodzi o producentów astronomicznych, to raczej bym się nie nastawiał. Te kamery mają zupełnie inną elektronikę, więc raczej nie znajdzie się tam takich "pozostałości". Choć zapewne dałoby się gdzieś tam coś dolutować, żeby dostać sygnał otwarcia migawki :) Jednakże wymagałoby to sporo czasu nad rozgryzaniem sprzętu.

Natomiast na pewno jest wiele innych firm produkujących podobne kamery przemysłowe. A w przemyśle takie złącza to standard. I może któryś ma całkiem dobre ceny?

Odnośnik do komentarza
Udostępnij na innych stronach

Mateusz, dzięki za info, zwiedzam tę instrukcję i przecieram oczy: czy ja dobrze widzę, że ta kamerka wymaga tradycyjnego kompa-kloca i dodatkowej karty z interfejsem 3.1?

Hmmm, jeśli tak, to można powiedzieć, że stanowi most rozkraczony między przeszłością i przyszłością :)

 

A czy USB 3.1 w ich rozumieniu to to samo co USB 3.1 w niektórych nowych laptopach ?

Odnośnik do komentarza
Udostępnij na innych stronach

10 minut temu, Agent Smith napisał:

Mateusz, dzięki za info, zwiedzam tę instrukcję i przecieram oczy: czy ja dobrze widzę, że ta kamerka wymaga tradycyjnego kompa-kloca i dodatkowej karty z interfejsem 3.1?

Hmmm, jeśli tak, to można powiedzieć, że stanowi most rozkraczony między przeszłością i przyszłością :)

Nie, nic takiego nie trzeba :) Normalnie działa na zwykłych usb 3.0 w kompie czy laptopie. Ta kamera powstała w czasach, gdy USB3 dopiero wchodziło i większość ludzi potrzebowała karty rozszerzeń albo wymiany kompa :)

17 minut temu, Agent Smith napisał:

A czy USB 3.1 w ich rozumieniu to to samo co USB 3.1 w niektórych nowych laptopach ?

Z tym USB to jest mały mętlik, bo są dwa systemy nazewnictwa. Pierwszy podział jest na USB 3.0 (ten "stary" 5Gb/s) i USB 3.1 (nowe 10 Gb/s). Drugi podział (jego powinno się stosować) jest na USB 3.1 gen 1 (odpowiednik USB 3.0 5Gb/s), oraz USB 3.1 gen 2 (odpowiednik USB 3.1 10Gb/s). PointGrey (a właściwie nowa nazwa to FLIR :P ) używa nowego nazewnictwa, tego z gen 1 (czyli nie używają tego najszybszego standardu). ZWO zresztą podobnie.

 

A, warto też dodać, że kamery PointGrey są wspierane normalnie w FireCapture, także nie ma problemów z zastosowaniami astro.

  • Lubię 1
Odnośnik do komentarza
Udostępnij na innych stronach

42 minuty temu, MateuszW napisał:

Jeśli nie wszystkie, to większość kamer tego producenta ma wymagane złącze. Lista kamer jest tu:

https://www.ptgrey.com/Camera-selector#InterfaceValueId=510

 

Dzięki. Pociekła mi ślina. Wygląda na to, że mają wiele podobnych matryc do ASI ZWO, a możliwość odczytania momentu rozpoczęcia zbierania fotonów jest bezcenna.

 

Pzdr,

Gajowy

  • Lubię 1
Odnośnik do komentarza
Udostępnij na innych stronach

Dołącz do dyskusji

Możesz dodać zawartość już teraz a zarejestrować się później. Jeśli posiadasz już konto, zaloguj się aby dodać zawartość za jego pomocą.

Gość
Dodaj odpowiedź do tematu...

×   Wklejono zawartość z formatowaniem.   Usuń formatowanie

  Dozwolonych jest tylko 75 emoji.

×   Odnośnik został automatycznie osadzony.   Przywróć wyświetlanie jako odnośnik

×   Przywrócono poprzednią zawartość.   Wyczyść edytor

×   Nie możesz bezpośrednio wkleić grafiki. Dodaj lub załącz grafiki z adresu URL.

×
×
  • 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ę.