Taki feature dodałem do AllSkyRadar/dummy.py na GH:
Zielone kółka to miejsca gdzie samoloty znajdą się najbliżej obserwatora.
Zielona linia łączy ten punkt z obecną pozycją samolotu.
Mini-opis przy zielonym kółku:
CALLSIGN
odległość w jakiej samolot będzie najbliżej (km); wysokość na jakiej będzie widoczny (kąt w stopniach/alt)
aktualny azymut na którym jest samolot / kierunek w jakim leci samolot (debug).
Chyba już działa dla każdej kombinacji azymutu/kierunku lotu, ale może się zdarzyć dziwne wskazanie.
To trochę rozwinięcie prediction z tabelki we flight_warning, ale tam nie ma (na razie) azymutu na którym samolot będzie najbliżej.
Żeby to działało, potrzebna jest najnowsza wersja flight_warning, który eksportuje dodatkowe dane.
@wzzak dziś uruchomił na wirtualnej maszynie flight_warning+AllSkyRadar/dummy.py i podpiął do dump1090 na rPi stawianej z obrazu piaware, więc działa się poza moim środowiskiem testowym.
Do opisu przewidzianej pozycji dodałem ETA, np. na screenie poniżej:
= 04m34s
Jeśli dostaję inf o prędkości, to jest "=", czasem nie ma info o prędkości i w opisie przed ETA będzie "~",
a zamiast prędkości podstawiam 900km/h, nawet dla "kukuryźników"
(hmm, może prędkość zgadywaną zmienię jeszcze zależnie od wysokości lotu...).
Jeszcze odsiewam krzaki z wyznaczaniem azymutu na którym samolot będzie najbliżej, bo u mnie nie wszystkie przypadki kierunków występują w dużej ilości i jak myślę, że jest już ok to pojawia się coś na nietypowym azymucie i kierunku lotu, więc dodaje warunki na bieżąco.
@Vader Dokłanie, czas w którym samolot osiągnie najbliższą odległość do obserwatora.
To samo teraz przy tranzytach zrobiłem, zamiast wyświetlać ile zostało km, to będzie ETA, więcej sensu to ma.
*Ten zielony kwadrat, to testuję sprawdzanie jasności fragmentów obrazu w których powinno być Słońce/Księżyc,
będzie bardziej zaawansowany auto-exposure i beton-check w jednym .
Krótki TL z dziś, z uruchomionym pomiarem światła w kwadracie 100x100px, wycinanym z miejsca gdzie na obrazie jest Słońce.
Jeśli jasność tego cropa jest dużo większa od jasności ogólnej zdjęcia, to wchodzi w tryb ustawiania ekspozycji pod fragment ze Słońcem.
Jeśli jasność tego cropa jest mniej więcej podobna, czyli najprawdopodobniej są chmury, to ustawia ekspozycję pod ogólną jasność zdjęcia.
W lewym górnym narożniku widać "<", która wskazuje jaki pomiar jest brany pod uwagę (Br_A = jasność ogólna, dalej Br dla Słońca/Księżyca).
To się dzieje jeśli Słońce jest na wysokości > -10st, ale jeśli jest < 0st to mierzy kawałek nad horyzontem, a nie poza zdjęciem.
W nocy gdy Słońce jest < -10st, najpierw sprawdza czy Księżyc jest > 0st, jeśli tak sprawdza crop z Księżycem, a jeśli nie ma znacznej różnicy to mierzy całość.
Efektem ubocznym jest "beton-check", bo jeśli nie ma znaczącej różnicy między cropem na Słońcu a ogólną jasnością, to raczej za sprawą chmur. W nocy gorzej, bo może nie być Księżyca albo będzie ogryzek i ten trick nie zadziała.
Jeszcze muszę dobrać na nowo zakresy min/max dla jasności, ale chyba będzie to lepiej eliminować prześwietlenia.
W sumie w nocy powinien sprawdzać azymut Słońca też, na wypadek gdyby wyszły NLC, pomyślę potem.
Dodałem też tło do opisów, bo przy dużej dynamice na zdjęciu, samo zmienianie koloru liter czarne/białe zależnie od ogólnej jasności już niewiele daje przy tym natłoku danych. Zmniejszenie czcionki pomaga na zagęszczenie opisów, ale czytelność bez tła spada.
Ilość opisów zmniejszy się trochę, jak przetestuję to czego nie jestem pewien na 100%.
Może przydałoby się jakieś rozsuwanie labeli żeby się nie nakładały.
Wrócił metar, potem wyciągnę z niego kierunek wiatru i na overlay wrzucę.
Wcześniej wrzuciłem filmik z odliczaniem przez komputer "na głos" czasu do najbliższego możliwego tranzytu.
Działa to z przeglądarki w pc albo w telefonie. To tak jako dodatek do tabelki, którą przeniosłem z terminala do www, w pewnej chwili zabrakło mi pikania z konsoli i zamiast zrobić pikanie przez www, to trochę rozwinąłem temat.
Tabelka chyba lepiej na www niż w terminalu.
Dwa screeny podsumowujące ostatnie 2-3dni.
Mój obecny układ z kamerami i tabelką:
Dzięki @spinka. Wszystko bardzo dobrze ogarnięte. U mnie skrypty są wykonywane na wirtualnej maszynie która ciągnie pozycje z fizycznego Rpi0. Host z windowsem ma zainstalowanego VRS wg instrukcji Spinki dzięki czemu działa MLAT. W planie mam podłączenie kamerki.
Chyba tu nie wrzucałem - w międzyczasie jeszcze powstała taka pasywna nakładka na "embeded" fr24.
Generują się tu przezroczyste png z azymutem Słońca lub Księżyca i przebieg altitude w czasie.
Precyzji prawie żadnej, ale pokazuje gdzie na mapie musi lecieć samolot żeby nastąpił tranzyt.
Nędzny przykład bo Księżyc dziś idzie nisko nad horyzontem:
Na czerwonej linii azymutu podziałka od FL160 do FL400 co 4000ft, żółte linie pokazują stan przed/po aktualnym czasem, tak jak zmienia się wysokość na jakiej jest Słońce/Księżyc:
Tu TAY4017 lecący na FL330 (trzeba znać FL z innego okna fr24 bo embeded nie pokazuje labeli, a kliknąć się przez png nie da :/ ).
Przetnie azymut Księżyca o wiele za blisko, gdyby, leciał na FL160 miałby szansę na tranzyt.
Tu podgląd z AllSkyRadar dla porównania, TAY4017 leci za blisko a więc powyżej Księżyca.
Używałem tego jakiś czas jak nie miałem MLATów z pozycjami. Od biedy jeśli ktoś byłby zainteresowany to mogę ożywić temat, to było w pythonie, ale skompilowałem to jakoś do .exe więc powinno działać z byle windowsa bez żadnych zależności.
Zakładka FW Settings - ustawienia flight warning.py
wedle potrzeb + wybór jakie chcemy śledzić tranzyty (defaultowo: Moon i Sun, ale można też wybrać Wenus, Jowisza, Marsa, Saturna)
Zakładka Dummy Settings - ustawienia Dummy.py
wedle potrzeb
Zakładka Dummy+VRS+FW bezpośredni link do /html_wzzak_bak/index.html
* Pewnie w kilku miejscach są na sztywno wpisane adresy np. w vrs.html, ale coś powinno działać.
** Zmiana ustawień w GUI i kliknięcie Save Changes powinno samo zrestartować fw i dummy z nowymi ustawieniami.
Skrypty komunikują się ze sobą. Kliknięcie w przeglądarce w tabeli na dany lot podświetli go po chwili na "podglądzie".
Ale najważniejsze:
Po otwarciu */html_wzzak_bak/index.html w przeglądarce (oprócz tabeli i podglądu) możliwe tranzyty oraz nadlatujące w określony zasięg samoloty są "ogłaszane" głosowo z wykorzystaniem syntezy mowy.
Format dźwiękowy dla tranzytu np.: Sun one minute; Sun zero minutes 30 seconds;
Format dźwiękowy dla nadlatującego samolotu np.: Incoming D,L,H,7,2,2, 4 minutes 30 seconds; (czas do najbliższego miejsca wobec obserwatora)
Incoming = leci z daleka, ale będzie w interesującym nas promieniu
In range = już w zasięgu.
Testuję to jeszcze, ale z tym minimalnym ruchem, przy pogodzie to priorytet ma robienie zdjęć, więc mogą jakieś bzdury wychodzić, ale na oko i ucho "u mnie działa".
Tu nagrana telefonem próbka jak to wygląda i jak mówi:
*Jak uda mi się nagrać coś logiczniejszego to podmienię.
Edit - wcześniej chciałem chyba posta wrzucić, ale coś i tylko zapisałem, na filmie skrypty kilka wersji wstecz i "ogłoszenia" jeszcze z mp3/wav, zanim odkryłem cudowny świat syntezy mowy... Wrzucam bo tam klikałem po opcjach, semi prezentacja taka niema.
Kilkuminutowy film z działaniem AllSkyRadar + VRS + Flight_warning w oknie przeglądarki www i szybki przegląd kilku opcj.
Z nowości zaznaczenie lotu w tabeli, wyróżnia go na podglądzie:
Uruchomione na Wirtualnej Maszynie (dummy.py + fw.py), dane idą z rebroadcast server (VRS na rPi4), gui vrs w ramce też z rPi4.
Generowanie i odświeżanie ramki z nakładką co 1s, odświeżanie tabelki co 1s.
W trakcie filmu zmieniałem kilka ustawień w panelu konfiguracyjnym w ramach pokazu.
.
ale podziwiam, bo wiedza przeogromna...
