Gajowy

Bardzo smutna wiadomość :-(.

Tomek

6 godzin temu, Pav1007 napisał:

Ha, miałem podobny problem na W10 i BT EQMOD. Moduł BT się parował, spokojnie instalował porty, łączył się i... po nieokreślonym czasie - wieszał się. Czasami po 5 sekundach, czasami po 5 minutach a czasami po godzinie. Pewne było tylko to, że się powiesi. Reinstal do W7 i problem całkowicie zniknął. EQMOD w najnowszej wersji łączy się i trzyma jak cholera :-)

 

Napisałeś, że reinstal nie wchodzi w grę :-( Szkoda. Stawiałem na zarządzanie energią BT ale żadne moje zmiany nie przyniosły oczekiwanego rezultatu.

Postawiłem Win7 na jakimś przedpotopowym komputerze z RS-ami i... przed chwilą montaż ruszył po PCDirect (!). Podłączę chip BT (na PD) do PCta i zobaczę czy będzie współpracował z modułem BT. Na razie chyba na 100% wyeliminowałem awarię montażu (uffff).

Pzdr,

Gajowy

Teraz, MateuszW napisał:

Tak, od układu BT do montażu.

 

Nie wiem, skończyły mi się pomysły  Jak to zwykle w astro, logika zawodzi...

Będzie jutro po firmach podzwonić. Dzięki za próbę pomocy! Dobranoc,

T.

2 minuty temu, MateuszW napisał:

A czekaj, to eq6? To nie ma być czasem prędkości 9600 ustawionej? Szczerze to już nie pamiętam, ale zdawało mi się że ta co ustawiłeś jest pod te nowe monty.

Próbowałem z różnymi prędkościami. Wcześniej chodził mi i z 115200. Zresztą, ta prędkość ważna jest chyba między urządzeniem BT a montażem, prawda?

Teraz, MateuszW napisał:

No to jedyne, co by mogło być logiczne, to wina EQModa lub ASCOMa. Przeinstaluj ten soft. EQMod trzyma gdzieś plik konfiguracyjny i nie wiem, czy go usuwa przy wyinstalowaniu. Zwróć uwagę, czy ustawienia wrócą na domyślne, bo jak nie, trzeba go będzie znaleźć i ręcznie wywalić.

Ale na dwóch komputerach mi nagle EQMod się popsuł?

Jutro jeszcze spróbuję bezpośrednio do kompa z fizycznym COMem podpiąć. Ale wydaje mi się, że to jakiś podzespół odpowiedzialny za dane z PCta. Choć to trochę dziwna architektura by była.

G.

6 minut temu, MateuszW napisał:

Zdarzało mi się, że się zawieszał na szukaniu, nawet jak port był ok. Ale rozumiem, że ręcznie też wskazałeś i również się nie łączył?

Tak.

Cytat

Milisekundy. Spokojnie możesz dać 1000, to i tak więcej, niż trzeba.

Czyli nie działa kabelek BT wpięty zamiast pilota, oraz PC Direct poprzez zwykły kabel podłączony przez pilot? No to w takim wypadku musi nawalać komputer  Jeśli byłby problem z samym PC Direct, to można by myśleć nad uszkodzonym złączem, no ale przecież tu używasz dwóch różnych (a to w montażu działa, bo pilot chodzi).

Niestety - testowane na 2 niezależnych komputerach :-(.

EDIT: Firmware Loader komunikuje się z pilotem...

Pzdr,

G.

Wygląda na to, że jest jakiś problem w samym montażu, zapewne od nieużywania :-/. Urządzenie BT się paruje, porty COM są dodawane, ale próba wyszukania portu w konfiguratorze EQMOD zawiesza go (na porcie COM opisanym jako "Incoming" w ustawieniach zaawansowanych):

BTW, czy wie ktoś w jakich jednostkach jest wyrażony Timeout? Można wybrać 1000 albo 2000.

Połączenie przez PC Direct też nie działa chociaż za pomocą pilota sterować montażem można.

Ma ktoś jakiś pomysł co mogło nawalić i kto to naprawia?

Pozdrawiam,

Gajowy

2 minuty temu, MateuszW napisał:

Księga zaklęć, dobra nazwa  Nie masz zwykłego kabla? Rozwiązałby problem dość szybko...

Pewnie mam, ale obawiam się, że przejściówka z RS na BT nastręczy kolejnych problemów... Niemniej poszukam i spróbuję.

G.

11 minut temu, MateuszW napisał:

BT w Win10 to dla mnie rzecz nieogarnięta. Próbowałem kiedyś coś z tym eksperymentować i za nic w świecie nie mogłem zrozumieć co się dzieje z tymi portami w menedżerze urządzeń. Co chwila się wywalało itp. Problem rozwiązałem zapominając o BT...

Jest dokładnie tak jak piszesz, Za każdym razem wykonywałem inny zestaw magicznych czynności i po dłuższych lub krótszych bojach ruszało. Jak widać moja księga Zaklęć się wyczerpała :(. Chyba ściągnę niemal gotowy montaż z tarasu i zabiorę się za konfigurowanbie tego nowego komputerka...

Dzięki, że wysłuchaliście moich żali ;-).

G.

Wiecie co? Mam od pół roku komputerek dedykowany do montażu, ale... nie mam czasu go skonfigurować :|.

Tymczasem BT nadal nie działa :(.

G.

Po dwóch miesiącach mam pogodne niebo. I co? Były jakieś aktualizacje Win10 i znowu, jak za każdym razem moduł EQMOD nie widzi połączenia z montażem (za pomocą BT). Odinstalowywuję, usuwam porty, dodaję, i nic. Zwykle pół godziny kombinowania pomagało, tym razem już godzinę klikam na mrozie :(. Nie ukrywam, że jestem nieźle wkurzony. Macie jakiś pomysł, co zrobić aby po każdej aktualizacji Windowska nie walczyć z montażem? Póki co zmiana systemu operacyjnego nie wchodzi w grę...

Pzdr,

Gajowy

Myślę jeszcze, czy nie lepiej kupić kamery ze złączem ethernetowym ?

Pzdr,

G.

5 minut temu, MateuszW napisał:

Powinno działać

To ZWO ma podobne matryce do nich  Oni byli wcześniej

Ja już jestem prawie zdecydowany na wymianę ASI174 na ich odpowiednik...

Wstrzymaj się z zakupem, może coś razem zamówimy i wyjdzie taniej :P.

Na razie przyglądam się https://eu.ptgrey.com/blackfly-s-color-200-mp-usb3-vision-sony-imx183-2 .

5 minut temu, MateuszW napisał:

A znalazłem jeszcze ciekawostkę na ich stronie:

https://www.ptgrey.com/KB/11131

Tytuł zachęcający, co?  Niestety, ta funkcja tyczy się tylko jednego modelu kamery, takiej co ma 6 obiektywów, więc nie za bardzo... Ale koncepcja jest bardzo fajna - kamera sama odczytuje sobie informacje z gps, podłączonego do złącza GPIO, synchronizuje swój timestamp i nanosi go na zdjęcia. Czyli dokładnie to samo, co robi QHY174 GPS. W mojej kamerze i innych, tak jak pisałem wcześniej, dałoby radę jedynie nanieść sygnał PPS na klatki i trzeba będzie na kompie poprzeliczać te timestampy. Tu byśmy to mieli od razu, z samej kamery. Kto wie, może zechce im się dorobić taką funkcję do starszych kamer? Bo raczej kwestia softu. Może też za kilka lat pojawi się większa oferta kamer z tym "natywnym" wsparciem.

Pewnie fajna cecha, ale tracisz kontrolę jak działa ;-). W preferowanym przeze mnie rozwiązaniu, wystarczy protokół NTP; jeśli mam sygnał zwrotny z kamery, to mam precyzję 0.003 sek (lub 0.02 sek jeśli korzystam z komórki zamiast światłowodu - dziś zmierzyłem; oczywiście na bezkresach Dzikich Pól moze być gorzej). Z drugiej strony jesteś niezależny (przynajmniej w tym zakresie) od Internetu.

Pzdr,

Gajowy

6 minut temu, Agent Smith napisał:

https://allegro.pl/oferta/kamera-przemyslowa-matrycowa-point-grey-flea3-2mp-7364642241 ?

QE 49% - to mało.

Pzdr,

Gajowy

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

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

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

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

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

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

56 minut temu, MateuszW napisał:

Hmm, a podeślesz?  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

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

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ć).

16 godzin temu, MateuszW napisał:

No ale jedyną możliwością na rejestrowanie poprawki jest dioda, czy coś przeoczyłem? Niby to dobra metoda, ale niewygodna przy późniejszej analizie. No i co, jeśli czas różni się więcej, niż o 0,5 s?

Jeśli ustalimy, że dioda zaświeca się w czasie krótszym niż 0.001 sek, to byłby to idealny wskaźnik. Przyszłą analizę możnaby zautomatyzować wykrywając pierwszą ramkę z zaświeconą diodą. W sumie nic trudnego. BTW, myślę, że może nawet nie trzeba jakoś specjalnie skupiać światłą z diody. Może wystarczy umieścić ją przy wlocie tuby? Światło powinno być na tyle wyraźne, że ramka z diodą będzie wyraźnie rozświetlona. Gorzej, jeśli ten diodowy błysk będzie trwał zbyt długo i zepsuje zbyt dużą liczbę ramek.
W proponowanej przeze mnie metodzie rejestracji popraki zakładam wstępną synchronizację zegara przed rozpoczęciem obserwacji. Wówczas 0.5 sek możliwe jest jedynie w wypadku skranie nieskorelowanego zegara. Tę wstępną synchronizacje można zrobić np. protokołem NTP.

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.

Cytat

Jeśli chodzi o skoki czasu podczas synchronizacji zegara, to te metody nie bazują na wprowadzaniu ciągłych poprawek do wartości zegara, ale subtelnie modyfikują jego częstotliwość, co właśnie zapobiega skokom. Do tego programy, o których czytam uśredniają sobie wiele pomiarów sygnału PPS, więc dokładność z czasem się poprawia. Czytam różne rzeczy, ale generalnie wydaje się, że osiągnięcie dokładności poniżej 1 ms nie jest problemem, a być może da się zejść do dziesiątków us.

Metoda zmiany częstotliwości działa chyba w systemach Linuxowych, w Windows masz przestawienie skokowe. Jedno i drugie podejscie ma wady - przy zwiększaniu częstotliwości de facto nie masz synchronizacji i nie wiesz jaki jest prawdziwy czas w momencie pomiaru, przy skokach - może się okazać, że dwie kolejne ramki robione z czasem 0.00001 sek będą opisany jako wykonane np. 0.2 sekundy po sobie.

Cytat

No tylko właśnie nie wiem jak to zmierzyć  Nie wiem, jak rozgraniczyć opóźnienie kamery od błędów mojego procesu synchronizacji. No i jeszcze pojawia się ważniejsze pytanie - na jakiej zasadzie np FireCapture nadaje znacznik czasowy klatce. Czy decyduje o tym moment wysłania żądania otwarcia migawki, moment odebrania klatki przez program, czy może inny? A może kamera robi zdjęcia bez niczyjego rozkazu, tj sama odpala migawkę z określoną częstotliwością? Wówczas program mógłby chyba tylko bazować na czasie odczytu klatki.

FireCapture - z tego co wyciągnęliśmy swego czasu na jakieś grupie FireCapture rejestruje moment początku ramki. Ponieważ jest to software uniwersalny, bazujący na prostych, amatorskich kamerach z nieskomplikowanym softem, cały proces wyglada tak [wykonanie zdjęcia lub zdjęć poklatkowych]:

1. Program wysyłą polecenie wykonania zdjęcia do kamery

2. Program rejestruje czas PC

3. Kamera odbiera polecenie wykonania zdjęcia

4. Kamera otwiera migawkę

5. Po czasie ekspozycji (kontrolowanym przez układ kamery!) kamera zamyka migawkę

6. Kamera kopiuje pixele do swojej wewnętrznej pamięci

7. Kamera ustawia swój znacznik gotowości przekazania zdjęcia

8. Program bada znacznik kamery i jeśli kamera jest gotowa - wysyła polecenie odczytania zdjęcia z pamięci kamery do pamięci PCta

9. Program dodaje do odczytanego obrazu z kamery znacznik czasu.

10. Program zapisuje obraz ze znacznikiem czasu na dysk.

11. GO TO 1.

Profesjonalne kamery mają możliwość odczytywania GPSa i dodawania znacznika czasu na poziomie oprogramowania wewnętrznego kamery.

Proces przebiega lekko inaczej gdy kamera działa w trybie video.

Cytat

 

Zastanawia mnie również, co się dzieje, gdy kamera gubi ramki lub występują wahania fps. Czy klatki są naświetlane wciąż w równych odstępach, a szwankuje jedynie przesył (czyli czegoś brakuje, ale interwał pozostaje), czy może odczyt matrycy też ulega wahaniom?

Dociekałem swego czasu, które ramki są tracone w kamerach ASI - dopóki nie opróżnisz buforu, kolejna ramka nie jest kopiowana do bufora kamery:
https://bbs.astronomy-imaging-camera.com/viewtopic.php?f=21&t=7453&p=15006&hilit=Gajowy#p15006

EDIT: W buforze może znaleźć się więcej niż jedna ramka, co trochę komplikuje sytuację. W ASI SDK jest jednak funkcja, która umożliwia odczyt liczby utraconych ramek.

BTW, zachęcam do własnych eksperymentów z SDK ASI - nad FireCapture nie masz jednak kontroli i nie wiesz do końca co siedzi w środku i jak np. obsługuje kwestię traconych ramek.

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.

Cytat

Częstotliwość odświeżania? A opóźnienie monitora?  A opóźnienie karty graficznej i procesora, który zleca jej zadanie? Tu również jest wiele niewiadomych. A opóźnienie monitora potrafi wynosić do kilkudziesięciu ms (nie mówiąc o czasie zaświecania i gaśnięcia piksela).

No, to jest temat w który kiedyś się mocną zagłębię, chyba, że...

Cytat

Jeśli chodzi o maxima, to istotnie coś jest, ale nie do końca wiem i rozumiem, co  Ale nie sądzę, żeby to było super dokładne, raczej było pomyślane dla wolnych ccd. Ale zerknę w wolnym czasie.

...sprawdzisz tego Maxima, zrozumiesz i opiszesz :).

Pzdr,

Gajowy

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.

15 godzin temu, MateuszW napisał:

Jeśli chodzi o diodę, to myślałem żeby ją po prostu podłączyć do wyjścia PPS bezpośrednio  Ale nie wiem, jaka jest szerokość tego impulsu i pewnie będzie za krótki, żeby kamera zobaczyła błysk. Jeśli tak, to na arduino zrobię elementarny program, który w przerwaniu od gpio odpali diodę - to będzie kilka instrukcji asemblera, a więc teoretycznie poniżej 1 us (zakładając zegar kilkanaście MHz).

Jeśli natomiast chodzi o testy synchronizacji bezpośrednio w windowsie, poprzez port szeregowy, to planuję zrobić test polegający na nagraniu kamerą sygnału diody sterowanej tym samym GPSem, który będzie synchronizował komputer. Tutaj mogę już dać ultra duży FPS w ASI, żeby złapać diodę bez pośrednictwa arduino - powinna być idealnym znacznikiem. W ten sposób jednoznacznie dowiem się, jakie jest opóźnienie lub jitter między GPSem, a czasem Windowsa.

 

Problem w tym, że jeszcze nie kupiłem nawet odbiornika, nie mam czasu na testy, a zakrycie tuż tuż...

Nie spiesz się, to nie jest kwestia tego jednego zakrycia przecież.

Jeśli chodzi o szerokość sygnału GPS - zgodnie z https://en.wikipedia.org/wiki/Pulse-per-second_signal ma to być < 1 s. Element GPS insertera Tomka Wężyka świeci diodą przez ok. pół sekundy, więc całkiem sporo. Nie zajmuję się elektroniką, ale zadaję sobie pytanie - jaki jest czas inercji samej diody? Tj. ile czasu mija od otrzymania sygnału do zaświecenia? Czy są to czasy pomijalne (tj. mniejsze niż powiedzmy 0.001 sek?).

Rozważ jeszcze sam proces synchronizacji. Moim zdaniem, poza wstępną synchronizacją przed obserwacją nie ma sensu synchronizować zegara komputera. Znacznie korzystniej jest po prostu rejestrować poprawkę co kilka minut a później interpolować ją na moment obserwacji i dodać do wyników. Unikasz manipulowaniem zegarem, skoków czasu, niepewności zachowania się samego OS, paru operacji wejścia-wyjścia itd.

Wracając do synchronizacji: pamiętaj, o opóźnieniu kamery, o którym pisałem. To też trzeba zmierzyć na iluś tam próbach, w różnych warunkach, by określić średnią i odchylenie standardowe.

inercja_kamery = moment_otwarcia_migawki - moment_pojawienia_sie_żądania_otwarcia_migawki
Programowo jesteś w stanie zarejestrować tylko moment_pojawienia_sie_żądania_otwarcia_migawki.

Napisałem na to program, który odczytuje liczby na monitorze. Problemem jest jednak częstotliwość odświeżania monitora, która nie pozwala zejść ponizej 0.01 sek. Mam jednak i na to pomysł. BTW, podobno jakieś narzędzie do tego jest w Maximie. Wiesz coś może więcej?

Pzdr,

Gajowy
 

W dniu 18.01.2019 o 17:14, MateuszW napisał:

@burza dziękuję za linki, jest sporo ciekawych pomysłów.

Posiedziałem teraz trochę czasu wertując internet i znalazłem dwa ciekawe programy do synchronizacji czasu systemowego za pomoca gps podpiętego do portu com:

http://www.dxatlas.com/ToyNtp/ - to wydaje się całkiem proste do odpalenia

https://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html - tu jest bardziej skomplikowana sprawa

Spróbuję zainstalować i przetestować te rozwiązania. Jeśli będą działać, to właściwie nie trzeba będzie już nic kombinować. Wykresy dokładności są wręcz fenomenalne dla naszych potrzeb.

Jak będziesz testował, dobrze byłoby przy okazji opracować testy mierzące opóźnienia (średnie i ich stabilność), np. operacji wejścia-wyjścia portów szeregowych albo też czasu jaki upłynie od otrzymania sygnału GPS do momentu zaświecenia się diody (jeśli te czasy są w ogóle mierzalne).

Pzdr,

Gajowy