Je úplně jedno, jestli létáte tralalajty, větroně, nebo velká letadla – někdy to nastane jednou za měsíc, jindy dvakrát do týdne a pak zase třeba pětkrát denně – potkáte v luftě někoho dalšího. Může to být příjemné setkání ve formě jiného kluzáku točícího pětimetr až do základny, kladnou nuličku někde u země která vás zachrání od přistání do pole, nebo naopak agresivního mesršmita který na vás neviditelně zaútočil zpoza mraku že jste se až .. lekli. Ve všech případech si pak kolikrát říkáme kdo to asi byl, čím to letěl a kam pak asi pokračoval. Odteď už nad tím nemusíme tolik špekulovat, máme na to přece logbook a v něm novou funkci, kterou jsem nazval Encounters (potkání/setkání).
Modré kolečko naznačuje, že někde zde jsme mohli vidět UFO.
Od půlky února jste si mohli na mapě všimnout malých modrých puntíků. Tyto značky označují místa, kde piloti, kteří se občas i dívají ven, mohli zahlédnout někoho jiného – letadlo, které bylo na onom místě v přibližně stejné chvíli.
Kliknutím na puntík se zobrazí identifikace letadla (pokud ji logbook zná).
Pokud se na mapě zobrazí divoký počet modrých teček, tak to znamená, že ste zřejmě potkali chumel závodníků, všechny v jednom stoupáku. Jedna tečka se objeví v aerovleku ve chvíli, kdy už jsou obě letadla ve vzduchu a žádná tečka v případě, že jste nepotkali lautr nikoho, nebo jednomu z vás jen nefungovala trackovací krabička.
Trasa letu druhého letadla jde přidat do mapy kliknutím na tlačítko.
Aktuální stav je takový, že pro ukončení letu se vyhledají všechny možné sblížení podle nastavených podmínek a to na vzdálenost do 500m v časovém rozestupu do 10s. Aby se tečky neopakovaly příliš často (například při letu ve formaci), následující setkání je detekováno a zobrazeno až po uplynutí dalších 20 minut. A dále, analýza letů se provádí pouze pro OGNka a Flarmy, protože ostatního provozu je už až až.
Teď v zimě při převládajícím motorovém provozu se zdá, že vyhledávání funguje vcelku pěkně, nicméně uvidíme, jak to pojede v sezóně, neboť dohledávání okolního provozu dává procesoru co proto. V takovém připadě očekávejte zpoždění ve vyhledávání klidně i několik hodin, možná i dnů 🤓
V logbooku jsou schované mazané detaily, o kterých jste doposud ještě nejspíš neslišeli. Tentokrát se dozvíte o dvou nových užitečných záležitostech, které by se vám mohly někdy hodit a určitě i líbit.
Maximální výška ve vleku
Toto je spíš záležitost pro vlekaře, kteří jdou vlekat někam do světa. Na mnohých letištích za kopečkama nezaplatíte dobu vleku, ale spočítají vám částku za vlek z výšky vypnutí. Již přibližně dva roky lze stáhnout přehled dne konkrétního letiště ve formě .csv souboru, který můžete naimportovat buď přímo do FlightOfficu (pokud jste se k tomu v aeroklubu někdy dostali) nebo jednoduše otevřít například v LibreOffice Calcu nebo nějakém jiném tabulkovači (jo, třeba v Excelu). K soboru se dostaneje vcelku jednoduše – je ke stažení nahoře v hlavičče stránky.
Zaznamenanou výšku vypnutí (maximální výšku onoho letu) pak najdete ve sloupečku R, v hlavičce označeného jako MAX_ALT.
Je samo sebou, že logbook zaznamená tyto informace pouze v případě, kdy je na palubě nějaká trackovací krabička (OGN, mode-S odpovídač, flarm, SafeSky app, nebo možná ještě něco jiného) a na letišti je dobré pokrytí OGN (nebo jinou sítí), ideálně až na zem.
Zobrazení více letů na mapě
Toto je featurka, která ležela na poličce v plánovacím deníčku už hodně dlouho. Je užitečná pro případy, kdy chcete porovnat svůj let s letem kamaráda, který letěl tu samou trať, nebo jste se aspoň cestou někde potkali. Lze zde krásně vidět, kdo volil jakou stopu, kde jste se mohli vidět (a třeba ani neviděli), potkat ve stoupáku a kdo jak pokračoval dál po jiné řadě, protože se mu ta jeho zdála samozřejmě lepší.
Přidat let lze v náhledu mapy velkým plusem v modrém kolečku vpravo nahoře. Implicitně vám to nabídne datum a místo startu již zobrazeného letu, ale snadno si tyto údaje můžete změnit a tak přidat let začínající na jiném letišti, nebo i třeba svůj vlastní z předchozích dnů. Pouze je třeba myslet na to, že lety nejsou uloženy nekonečně dlouho a tak koncem léta už tam určitě nenajdete svá pětikila ze začátku sezóny. Tož enjoy! 🙂
Někdy začátkem února, kdy už tak nějak oskar šajnoval ale i přesto byla furt jestě kosa, jsem začal testovat nový softvér pro sezónu 2023. Testované škatulky jsem měl v hokně na střeše, neboť zkoušky na čersvém luftě nejsou žádné laboratoř a projeví se tam i to, co ve sklepě nejde vidět. Obzvláště mi v tom napomáhal medlánecký Dynamik, který bóchal okruhy hned a blízkým hrbem.
Za polních podmínek používám pro aktualizaci androidí aplikaci OGN Cube Control, kterou jsem napsal proto, aby se nemusely krabičky aktualizovat jako Flarmy – kuchat to z éra, nebo nosit počítač do hangáru. Ještě v pondělí odpoledne všechno chodilo jak má, úpravy jedna za druhou mi dělaly radost, paráda. Ve sředu, kdy jsem zamýšlel flešnout finální verzi, se něco stalo. V aplikaci jsem viděl jen čínské znaky. ___!? V telefonu mám zakázány jakékoliv aktualizace a všechno dělám ručně, především proto, aby se veci děly konzistentně a měl jej aspoň trochu pod kontrolou. OGN Cube Control mám ve vývojové verzi (tudíž ne z play storu). Tak co se ***** mohlo stát? Jak jsem se dozvěděl o pár měsíců později, tak v ono úterý se soudruzi z Googlu rozhodli změnit „něco“ v API a jakmile byl telefon připojen k iternetu, tak protlačili toto „vylepšení“ i přes zákaz aktualizací do všech našich telefonů. Aplikace, které používaly starší knihovny tak ze dne na den přestaly fungovat. No tvl!
Řešení bylo na snadě – tak upgraduju android dev kit, Flutter, Dart a obecně celý workspace, překompiluju aplikaci, deploynu a bude hotovo, ne? To ani náhodou! Od té chvíle je projekt kompletně rozbitý a nejde ani zbuildovat. Jak to tak vypadá, tak to bude chtít přepsat OGN Cube Control úplně od začátku.. až jednoho dne bude čas (a chuť). A protože to není záležitost úplně na jeden víkend a krabičky tu aktualizaci opravdu chtějí, přináším (pro lehce zkušeněší uživatele) návod, jak krok po kroku provést aktualizaci vašich OGN krabiček.
Co k tomu budete pořebovat: počítač s nejakou verzí linuxu (popis bude pro *buntu, ale jakékoliv jiné distro je ok) a fungujícím modrozubem (bluetooth). Celé je to stále možné provést ve vymrzlém hangáru bez vymontování krabičky z letadla.
Krok #1: V terminálu/konzoli nainstalujte nástroje potřebné pro běh aktualizačního programu, skriptů a kominukaci mezi skripty a krabičkou přes modrozub:
Krok #3: Stáhněte si (ideálně ten nejnovější) firmware pro vaši konkrétní krabičku z repozitáře ognCubeReleases. Pro tento krok je nutné přesně vědět, jaký mikrokontrolér v ní máte. To můžete určit podle následující tabulky, ale pokud si chcete být fest jistí, tak ji kuchněte a přečtěte si typ přímo na MCU (na tišťáku černý čtvereček vlevo dole).
OGN CUBE 2 -> STM32F103CBT6
OGN CUBE 3 -> STM32F103CBT6
OGN CUBE 3.5 -> STM32L152CC..
!!VAROVÁNÍ!! Pokud flešnete firmware pro nesprávný typ MCU, tak další přeflešování už nebude úplně tak jednoduché. Stále to jde udělat doma, ale je s tím poněkud víc práce..
Krabičky s MCU F103 (CUBE 2 + 3) mají pevně nastavený typ letounu (kluzák/motorová mašina/uav), takže stahujte ten firmware, který potřebujete. CUBE3.5 mohou být nakonfigurovány (na počátku jsou všechny GLD), ale konfigurace by měla přežít aktualizaci firmwaru, takže nemusíte nic řešit. Pokud byste ale potřebovali nějakou změnu, můžeme to tu v budoucnu rozebrat..
cd bin-files
wget https://github.com/ibisek/ognCubeReleases/raw/master/releases/ognCube3.5.l152-2023-11-30-GLD-0x2800.bin
wget https://github.com/ibisek/ognCubeReleases/raw/master/releases/ognCube3.f103-2023-02-10-UAV-0x2800.bin
wget https://github.com/ibisek/ognCubeReleases/raw/master/releases/ognCube3.f103-2023-03-06-GLD-0x2800.bin
wget https://github.com/ibisek/ognCubeReleases/raw/master/releases/ognCube3.f103-2023-03-06-POWERED-0x2800.bin
cd ..
Krok #4: Flešovnání firmwaru. Před tímto krokem je třeba mít krabičku nějakou chvíli zapnutou (řekněme 20s), aby už nebyla v boot módu (prvních 10s po zapnutí). LEDůvka by měla signalizovat vyhledávání družic (dva hned po sobě následující záblesky, –), nebo v případě, kdy už má GPS fix dva velmi krátké každou sekundu.
sudo ./findAndFlash.sh
Po úspěšném naflešování se krabička sama restartuje.
Otázku a dopovědi:
Jak poznám stávacící verzi firmwaru v mé krabičče? V androidím telefonu lze využít aplikaci Serial Bluetooth Terminal, připojit se ke krabičce a po zapnutí z vypsaných informací vyčíst verzi. Jdou tam vidět dva datumy – první je verze bootloaderu (hned po zapnutí). Bootloader po 10 sekundách předá řízení samotnému programu a tak se v cca 11. sekundě vypíše verze firmwaru. A to je to číslo, o které vám jde.
Ačkoliv to nejde vidět, pod kapotou logbooku se toho děje skutečně hodně. Aplikace, která se stará o zpracování dat z OGN sítě trpí během krásných letních dnů neskutečnou zátěží (jak jsem již dříve popisoval tady) a kromě počasé kromě super zážitků v luftě způsobuje značnou frustraci a spoustu vrásek ve tváři admina serveru. Popravdě, asi by to nebyl zase takový problém, ale je to tak nějak iritujující..
Fronta OGN beaconů řazených pro zpracování je nakonfigurována na „neomezenou“ délku již více než dva roky a jediný způsob, jak se problém projevuje, jsou až 12hodinová zpoždění ve zpracování nahromaděných dat během těchto přenádherných dnů, aniž by tedy došlo k jakékoliv ztrátě cenných dat. Vzhledem k tomu, že běžící kód plně vytěžuje všechny čtyři jádra procesoru Intel Xeon Silver 4214 @ 2,20 GHz, vyvstala doměnka, že je v kódu něco opravdu shnilého. Navíc je již v běhu i plán přesunout tento server na Raspberry Pi s výrazně nižším výkonem. Takže je s tím třeba něco konečně udelat.
Rozhodování bylo jasné – potřebujeme výrazně urychlit vše, co je třeba provést v reálném čase. Tudíž hned teď. Jak je Python na některé věci opravdu vynikající, tak v tomto případě je zárověn i neskutečně zdechlý. V níže uvedené tabulce je několik programovacích jazyků, ze kterých bychom mohli volit náhradu a které by vyhovovaly našim potřebám. Na základě této tabulky, kterou jsem si vypůujčil z mého oblíbeného informačního zdroje Hackaday.com se jako vhodné alternativy nabízejí následující:
Programovací jazyky seřazené podle energetické (ne)nažranosti, výkonu a paměťových nároků. Zdroj: https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/
Odshora dolů můžeme uvažovat o C, C++, Rust, Adě, Javě, Packalu. No, C/C++ nepřipadá v úvahu, protože moje zkušenosti s vícevláknovými aplikacemi v C nejsou zrovna pozitivní (a ne, opravdu netvrdím, že po všech těch letech vývoje OGN krabiček jsem někde blízko zkušenému vývojáři v Céčku 😉 ). Rust je neskutečně divný, Ada, Fortran (ani náhodou) a Java. Kdysi jsem chrlil vcelku dost krásného kódu v Javě, Java je dobrá, jen její paměťová náročnost je pro malé Pi asi poněkud příliš. Ale co takhle vyzkoušet ten Rust!?
Navzdory všem nepočítaným článkům a blogům, které nepokrytě vychvalují Rust snad i jako náhradu zdravé výživy, a po téměř roce škrábání se po pověstné učící křivce si troufám tvrdit, že Rust je zdaleka nejkrvavější pokus o naučení se nového jazyka, který jsem kdy zažil. Přepsat celé jádro OGN logbooku mi prakticky zabralo dva měsíce kódění na plný úvazek, způsobovalo hromadu zoufalství a válčení s dosud neviděnými kompilačními problémy, exotickou syntaxí a celkově odlišným přístupem. Přesně jak se říká.. zážitek nemusí být kladný, hlavně když je silný! Nakonec se to povedlo, po dalším měsíci testování, ověřování, nahrazování spousty unwrapů a pilování detailů máme funkční back-end logbooku postavený na .. korozi. Zkušenější ‚rustaceans‘ sice asi při pohledu na to, co bylo zkomponováno skalním OOP vývojářem trefí šlak, ale hlavní je, že to (více méně) funguje.
OGN APRS provoz jak jej vidí pythonní (zeleně) a rustový (modře) logbook.
Více méně. Logbook, který v tuto chvíli využíváte je stále postaven na pythonním kódu. Důvodem je především to, že objem provozu, jak jej lze spatřit v monitoringu se poněkud odlišuje pro obě implementace. V počtu zpracovaných OGN beaconů to může být jen pár procent v nočních hodinách, nicméně rozdíl dosahuje i více než 20% ve špičkách přes den. APRS filtry jsou identické (celý svět) a pravidla pro filtrování beaconů takéž. Jen rustový logbook dostává méně beaconů a navíc, což je nejpozoruhodnější, vyskytuje se i mnoho beaconů letadel, které pythonní logbook vůbec nevidí (a i naopak). Kdybyste někdo náhodou měli ponětí, proč se tak děje, dejte mi prosím vědět! 🤓
Další věcí která se nedávno podařila je rozšíření databáze letišť o všelijaké větší i menší plochy v Kanadě. Na prosbu jistého Tima jsem přidal nejen jejich letiště v divočině (CPL3, Kars, Ontario) ale přibylo i dalších 1637 nových ploch. Výsledný soubor se teď tedy sestává z pozoruhodných 26903 letišť nad kterými OGN logbook drží stráž 🙂
I když to už může znít jako klišé, nedostatek součástek mě přiměl vrátit se k jednomu pěknému, ale již nějakou dobu v pověstném šuplíku ladem ležícímu projektu – adaptéru pro krtka. Motivace je jasná a zřejmá: Před pěti lety jsme byli donuceni vyměnit naše perfektně fungující rádia za jiná kvůli přechodu na frekvenční rozteč 8,33 kHz a od té doby je doslova utrpení uložit cokoli do paměti stanic. Každé jaro se ve všech hangárech po celém vesmíru odehrává ta stejná scéna, ve které se nešťastní piloti pokoušejí aktualizovat z nějakého neznámého důvodu neustále se měnící frekvence ve svých milovaných radiích KRT2, jejichž ovládání vymyslel odobně sám Herr Belzebub. A následně po zbytek sezóny pak všichni odmítají provádět jakékoli další úpravy, protože frustrace dosahuje nebetyčných výšin (odborně se tomu prý ríká bad UX, user experience) . Takže někdo s tím už konečně musel něco udělat! B-)
K našemu štěstí vytvořili konstruktéři rádia KRT2 prográmek, který nazvali „KRT2 Manager WinXP“. Tento používá již mnohdy neexistující sériový port našich starších počítačů k nahrání seznamu stanic do rádia přes příslušný kabel, který má dnes snad už jen Dorota Máchalová. Navíc se nám ovšem nechce nosit rádio k počítači, ani počítač do hangáru, proto vznikla aplikace KRT2 Bluetooth pro androidí telefony, která nám s tím značně pomůže. A díky kamarádovi s aktivním vývojářským účtem si ji můžeme snadno stáhnout přímo z obchodu PLAY.
Samotný adaptér je pak krabička, která přijde mezi rádio a konektor, který tam již je. Není potřeba žádná sofistikovaná instalace – stačí jej jen zapojit a zajistit obě strany dobře pasujícími zobáčky.
Po zapnutí rádia spárujete svůj androidí telefon s bluetooth adaptérem, spustíte aplikaci, nakonfigurujete svůj vlastní seznam frekvencí, vyberete vhodné bluetooth zařízení a nahrajete svou konfiguraci do rádia. Hotovo. Prostě je to tam!! 🙂
Pořadí stanic v seznamu lze změnit přetažením řádků v tabulce seznamu frekvencí nahoru a dolů. Více seznamů je hodí v případě, kdy často cestujete po soutěžích nebo když kamarádi z aeroklubu chtějí mít jinou sadu frekvencí než vy. Kompletní seznamy lze exportovat do .csv souboru pomocí tlačítka sdílení, zatímco jejich import je třeba provést odesláním souboru do aplikace („Odeslat do */*“).
Rád říkávám, že jedna KRT2 Bluetooth krabička patří do každého aeroklubu, aby se všechna rádia dala snadno nastavit už na začátku sezóny a později s nimi už nebyly žádné další potíže. Ale využít se dá samozřejmě i jinak.. A protože jsem jich udělal doslova hromadu (nojo, tak jen hromádku), jsou již teď k dostání u Horsta Fuchse v oddělení Choose and Buy 🙂
Ve známém akademickém kolečku vymysli-udělej-publikuj tak nějak zanedbávám ten poslední krok. V půce ledna jsem byl totiž dotázán jak a jak dobře funguje zobrazení okolního provozu v navigaci XCSoar s daty z krabiček OGN CUBE. Popravdě řečeno jsem to nikdy dřív nezkoušel, neboť létám na LK8000 a tam to chodí velmi dobře (jak již všichni mimochodem) víme z dřívějších příspěvků. Takže bylo na čase to poněkud uměle a improvizovaně vyzkoušet. Proč uměle? Protože byla (a furt ještě je) zima a nikde okolo nic nelétá..
Třetí víkend v lednu jsem vyrazil do akce. Stále slušně mrzlo, do toho dul silný severák, ale aspoň vylezl oskar, který (planě) sliboval, že to nebude tak hrozné. Jedna krabička CUBE3B našla své místo na střešní římse zkušebny LÚ. S tou druhou, měřicí, jsem vyšplhal o něco výše na opačnou a co nejvzdálenější stranu. Mimochodem, zde lze i spatřit novou anténu, která bude letos podléhat letovým testům B-)
Na levém obrázku je náhled situace, za které probíhala divoká zkouška. Obrazovka pochází z androidí aplikace OGN viewer, přičemž data proudila přes Soběšický OGN přijímač. Na pravém obrázku je pak ukázka nastavení bluetooth propojení OGN CUBE a XCSoaru. Na dalším obrázku vpravo dole je pak mapové zobrazení v XCSoaru – druhá krabička na opačné straně střechy je ta malá červená šipka. Na obrázku vpravo pak ta samá situace v LK8000. V obou případech je zoom na maximum (ta střecha prostě není zase tak velká). Screenshot s terminálem, kde bylo vidět jak chodí NMEA věty jsem ovšem už zašantročil..
Další obrazovky jsou z loňského léta (2021), na kterých lze v LK8000 spatřit povícero kluzáků – jeden kroužící ve stoupáku přímo nad letištěm (zelená šipka) a další dva na gridu netrpělivě vyhlížející neskutečně pomalu vyklesávající vlekovku (modrá šipka) povětru levého okruhu na dráhu 33. Prostřední a pravá obrazovka jsou pak různé možné náhledy, které pro podobné situace nabízí LK8000.
Takže jaký je závěr? ANO, chodí to pěkně i v XCSoaru a oboje aplikace umí přehledně zobrazit situaci ostatních letadel v luftě okolo, samozřejmě za předpokladu odpovídajícího vybavení na palubě. A funguje to úplně stejně jako v devítílitru, jen za značně příznivější cenovku B-)
Vánoční „prázdniny“ mi konečně uvolnily ruce a tak se s vámi mohu podělit o informace o některých nových funkcích implementovaných do webu a enginu OGN logbooku. Prvního, největšího a nejcennějšího přírůstku jste si dozajisté již všimli. Kliknutím na malou lupu 🔍 na řádku letů můžete podrobně prozkoumat trať onoho konkrétního letu!
Záznam letu jak jej viděl glidertracker.de (vlevo) a OGN logbook (vpravo)
Je tu však však jedno omezení. K letovým záznamům lze přistupovat pouze po dobu 24 hodin po přistání sledovaného letounu, neboť zásady využití dat z OGN sítě omezují interval, po který je možné s nimi nakládat. To nám (pravděpodobně) brání uchovávat data déle, protože si opravdu nejsem jistý, jak správně naložit s interpretací výrazu „data redistribution“. Navíc dlouhodobější ukládání takového množství letových dat by stejně rychle zabralo veškeré dostupné místo na disku našeho serveru. To má za následek, že se veškerá letová data po tomto časovém limitu automaticky zahodí. Někteří z nás by se sice rádi podívali v historii svých letů i na záznam, kudy jsme letěli, na druhou stranu takto veřejně přístupné záznamy by mohly i způsobit nepěknou paseku v případě zneužití. Co si o tom myslíte? Jak přistupovat k ukládání letových záznamů?
Na druhou a docela užitečnou novou funkci lze narazit při výběru data v záhlaví. Aby se toto políčko zobrazilo, musíte nejprve vybrat svoje letiště nebo nějaké letadlo.
Volba data pro zvolené letadlo nebo letiště
Původně to měl být všestranný nástroj pro výběr rozsahu datumů ve smyslu od-do, ale zjevně nejsem tak dobrý webdesignér, jak bych potřeboval, nebo jsem doufal, že kdy budu. Možnost výběru rozsahu dnů, tedy kompletního víkendu nebo dokonce celého týdne, je tu s námi informovanými uživateli již nějakou dobu, ale stále není dostupná tak nějak snadněji přímo uživatelského rozhraní. Ale pořád je tu možnost poladit URL ručně, jako například v této ukázce: https://logbook.ibisek.com/loc/LKSU/2021-06-13/2021-06-16. Pouze mějte na paměti, že maximální rozpětí pro zobrazení historie je omezeno na 14 dní, aby se odlehčilo databázi nebohého raspberry.. aspoň trošičku.
Další velkou novinkou na backendu, zejména z hlediska výpočetního výkonu, bylo opuštění pythonovských vláken ve prospěch modulu multiprocessing. Možná jsem věděl (ale nikdy předtím jsem si to asi neuvědomil), že pythonní GIL (global interpreter lock) neumožňuje paralelně spouštět pythonní vlákna na více jádrech CPU paralelně, jako to nativně umí spousta jiných programovacích jazyků. To, že všechna vlákna běžela na jedinném jádře způsobovalo dlouhá zpoždění ve zpracování beaconů (beacon = informace o poloze a stavu letadla) a to především ve chvílích největšího plachtařského (ale samozřejmě i motorářského) provozu. Kapacita real-time zpracování dosahovala svého vrcholu při 168 tisících beaconech za minutu zatímco všechny další příchozí beacony čekaly ve frontě na zpracování dalších klidně až 10 hodin. Knihovna multiprocessingu tedy zajistí navýšení kapacity zpracování beaconů, ale na druhou stranu zase aktivně brání rozumnému procházení kódu v debuggeru. A právě proto je teď backend napsán tak, aby se v závislosti na režimu spuštění aplikace používaly buď vlákna nebo multiprocesing. Koho by to zajímalo více, může se vesele pustit do zkoumání zdrojáků na GitHubu.
Například takto lze detekovat výkonnostní problémy OGN logbooku. Oranžové tečky v horní polovině grafu představují počet beaconů čekajících ve frontách ke zpracování. Všimněte si, jak po poledni, kdy se většina kluzáků již dostala do vzduchu, fronta náhle narostla. Zelené tečky pak ukazují aktuální počet příchozích beaconů každou minutu. Ve spodní části grafu poté můžete shlédnout aktuální stav zpracování příchozích beaconů každou sekundu rozdělených podle protokolů – OGN/ICAO/FLARM.
Novinkou na úvodní stránce je zobrazení provozu z celého světa. To bylo zpočátku omezeno na region, ze kterého pocházíte, na základě nastavení jazyka vašeho webového prohlížeče. Proto jsme my a šalení viděli primárně jen lety uskutečněné z ČR+SR, seveřani Norsko, Švédsko, Finsko, skopčáci a rakušáci jen dění v říši, pšonci v pšonsku a frantíky nejspíš nezajímali angláni a naopak. Ale nakonec přece jen někteří z nás mohli chtít nahlédnout do toho, co se děje v Čile, Namibii nebo na Novém Zélandu, obzvláště teď v zimě.
Databáze letišť byla rozšířena na neuvěřitelný počet 25262 záznamů přidáním mnoha dalších letišť v Austrálii, na Novém Zélandu a především tisíců severoamerických letišť. Za to vřele děkujeme Johnovi, nejspíš z emeriky 🙂
Jednou z posledních zde popsaných novinek OGN logbooku je podpora zpracování beaconů protokolu SafeSky jako dalšího hned vedle OGN, ICAO a FLARMů . Zdá se totiž, že tento provoz nabírá na síle a uvidíme, jak se mu bude dařit i v příští sezóně. A třeba nám zvědavcům to k něčemu nakonec taky bude.
Tož to by bylo k OGN logbooku pro tentokrát všechno. O tom, co de děje s krabičkama OGN CUBE vám povykládám příště. Protože i tam se furt, i když teď o něco pomaleji, něco děje! 🙂
Po nekonečných třech měsících je načase ukázat něco nového, nebo alespoň projevit nějaké známky života 🙂 Čas a historie letí kolem, zatímco krabičky doznaly značného zpoždění. A sezóna už zase utíká jak zběsilá, takže bylo na čase si vzít nějaké to volno z rachoty a pohnout s líně plížícím se vývojem zase o kus dopředu.
Většinu osazovacích prací si vzal na starost Jan Weber ve svém osazovacím království, zatímco já jsem pak jen doosazoval vetší a dražší moduly, protože bez nich je snažší a rychlejší odhalit některé zákeřné chyby, které mohou při (i jejich) osazování vzniknout. Jako například ty, co nám způsobily superkondenzátory, které zálohují GPS při krátkých výpadcích napájení. Jejich exploze způsobily několik ošklivě schovaných zkratů mezi nožičkami některých součástek. Příště tam ty kondíky asi nedáme, nebo přidám ručně až nakonec. Nicméně i tak se nechtěly moc chytat.. asi nějaká mizerná várka.
Následovalo flešování nejčerstvějšího multiprotokolového firmwaru do nových mikrokontrolérů (o kterých jsem psal posledně) a všechny krabičky jedna za druhou úspěšně procházely „stolními“ testy. Během venkovních a letových testů se vyskytlo pár podivných chybek, které se v tuto chvíli už ovšem podařilo pochytat a kód tak vyladit téměř k dokonalosti. Téměř, neboť ne všechny na letošek plánované featury (kurňa, jak se to řekne česky? Snad vymoženosti? 🙂 ) se podařilo dotáhnout do konce, proto jsou teď vypnuty a jak budou stabilní, tak přijdou s některou budoucí aktualizací přes OGN CUBE Control.
Zároveň byly aktualizovány uživatelské a instalační příručky a jsou k dispozici v sekci věcí pro stažení. Finalizace krabiček OGN CUBE 3.5 je tedy v plném proudu a budou se již brzy moci vydat na cestu třeba i na to vaše letiště! 🙂
První náznaky nadcházejících potíží s nedostatečnou velikostí paměti FLASH aktuálně používaného STM2F103CB začaly vykukovat těsně před koncem loňské sezóny. S tím, jak pokračoval vývoj nových funkcí jsem se v mé experimentální krabičče začal blížit zaplnění paměti programu a vypadalo to, že nejpozději do konce roku přijde konečná. Už dříve jsem se toho začínal obávat a proto jsem přemýšlel nejen o rozšíření, ale i o možných změnách v návrhu a architektuře MCU na kterou bych přenesl stávající kód. Toto je shrnutí úvah a příběh o přechodu na jiné MCU, ke kterému došlo v průběhu Vánoc a protáhlo se daleko přes Nový rok.
Jak již bylo zmíněno dříve v jednom z předchozích příspěvků, první prototyp OGN CUBE trackeru se zrodil na 8-bitovém mikroprocesoru ATMEGA8-16PU RISC od společnosti Atmel. Před pěti(!) lety se podařilo vtěsnat základní funkcionalitu trackeru do 8 kB FLASH a neuvěřitelných 1024 bajtů (BAJTů!) SRAM – téměř neskutečný výkon, který si dnes už ani nedovedu představit. Velmi brzy však bylo zapotřebí VÍCE paměti. Proto první přesun přirozeně směroval na ATMEGA328P – nyní včeobecně známý Arduino čip. Jen si představte ty neomezené možnosti: čtyřikrát více FLASH a dvojnáobek RAM! 32K by mělo stačit všem, nebo ne? 🙂 No, vlastně ani ne, ale tento tracker stále neúnavně a spolehlivě brázdí termikou a točí šprajcy pod kumuly v LSce se znakem ‚PK‚ na ocase.
Třetí migrace byla jasná. Už jsem měl nějaké zkušenosti s ekosystémem kolem STM32 (zejména F042 a F303), vlastní stabilní sadu I/O knihoven pro SPL a zároveň mnoho odstrašujících zážitků při hledání problémů v HAL (kteréžto knihovně se důrazně doporučuji velkým DME obloukem vyhnout). Následník krále od Atmelu musel být integráč se světlou budoucností, podporou SPL a některými dalšími rozumnými parametry. Po dlouho promýšleném ale nekončícím oscilováním mezi možnými alternativami a nesčetných hodech korunou se novým srdcem CUBE stal všudypřítomný integrovaný obvod STM32F103CB, zejména z důvodu jeho dostupnosti (v té době jsem ani netušil, že ostatní OGN trackery byly založeny právě na STM32F103C8). Díky 128kB FLASH (C8 má polovinu) a 32kB RAM byla položena cesta ke svělým zítřkům. A ptáte se, jaké byly ty zvažované alternativy? Však počkejte..
První Kinderrüberraschung vykouklo už po první úspěšné kompilaci – binární velikost stejného kódu byla na ARMu dvakrát větší než na starém dobrém AVR! Bylo skutečně štěstí, že byl místo C8 zvolen MCU s označením CB. Ale i v tomto novém „století ARMu“ se velikost kódu neustále zvětšovala. Byly nazazeny různé optimalizace (jak kompilační, tak v kódu samotném) a některé funkce byly odstraněny – jako například záznam celého letu na SD kartu za použití little-fs. Ale zbývající FLASH se stále zmenšovala..
S implementací toho druhého protokolu B-) bylo potřeba provést další velký skok. No jo, ale kterým směrem? Potřeboval jsem stejné pouzdro (LQFP48; desky plošných spojů byly vyrobeny již koncem léta), v ideálním případě zase něco od ST s podporou SPL (kteréžto, jak se zdá, úplně osiřelo a pro nové MCU se s ním již nepočítá) a hlavně proto, že HAL je jen rychlou zkratkou do pekel. A nebo.. co takhle podívat se o plot dál?
NRF52 od Nordicu se v učité skupině lidí těší nevídané oblibě. Tento čip vybavený modrým zubem (rozuměj bluetooth) by také umožnil zrušit samostatný BT modul a ušetřit trochu energie a o něco více místa! Ale ten jejich ekosystém mi přijde takový .. no, jiný. Co MSP430 od společnosti Texas Instruments? Z nějakého zcela neznámého důvodu mě tento mikrokontrolér láká, ale ne, nejspíš by to byl krok špatným směrem. Snad nějaký PIC? (vzpomeňme zde kdo je lepší – Microchip nebo Atmel? B-) ) A co taková ESP8266? Málo I/O. ESP32? FCC certifikace, o trochu více I/O nožiček (ale stále nestačí), on-chip Wi-Fi a bluetooth by bylo manifique .. ale jeho spotřeba? No tvl! Něco s RISC-V? Zatím se zdá, že nic použitelného zde pro „produkční“ použití s dlouhodobějším výhledem neexistuje. A v neposlední řadě – co si byste řekli na Teensy? .. no, přiznávám, bylo to divoké! 🙂 Po vystřízlivění, ale i po všech zralých úvahách zůstanou naše krabičky v království ST Micro. Ve skutečnosti to vůbec nějak špatný mikrokotrolér! A tak jsem se zase jednou vydal na nákupy …
Výbavička v podobě vývojových destiček ST Nucleo 🙂
Jedním z dlouhopřetrvávajích záměrů bylo zmigrovat kód na mikrokontroléry od ST vyšší třídy, jako je L4 (bez podpory SPL ;( ) nebo F4 (dostupné SPL a k tomu i hardware pro podporu výpočtů s plovoucí desetinnou čárkou, krása!), ale zárověň i nízká spotřeba byla jedním z hlavních sledovaných parametrů. Bohužel F4 nedělají v LQFP48 s 256 kB FLASH. Chjo!! Spoustu probdělých noci a ještě více volných chvílí přes den jsem strávil s aplikací ST MCU Finder (která ač má nezměrný potenciál, je naprosto zanedbaná a nefunguje ani po mnohých aktualizacích), dokud finální a vlastně jediná zbývající alternativa neukázala na ten samý integrovaný obvod jako před dvěma lety (kdy jsem zvolil F103) – STM32L152CC. Má 256 kB FLASH, tikat může až na 32 MHz (což furt tak nějak ještě jde 🙂 ), 32kB RAM + nějaká ta EEPROM pro uložení uživatelské konfigurace a .. snad i delší budoucnost 🙂
Po měsíci stráveném přesunem a laděním kódu pro L152 (jsou tam určité nehezké rozdíly jak v SPL, tak i architektuře MCU; hlubší zájemci si porovnají blokové schémata v odpovídajících datasheetech) a dohledání úplně posledního brouka v způsobujícího problémy v časování SPI zde mohu optimisticky vyhlásit, že novým MCU, kteréhožto budeme vozit na palubě v nadcházející generaci OGN CUBE, je ST L152CC! 🙂
Tento příspěvek jsem plánoval napsat už loni v únoru, ale .. tak nějak to nevyšlo a proto jsem se k tomuto tématu dostal až po krapet delší době. Na sklonku pozimu roku 2019 jsem poprosil kamaráda Zdenka, který má přístup ke spektrálnímu analyzátoru a hlavně jej umí používat, jestli by mi proměřil několik antén, které jsem zakoupil především pro experimentální účely. Výsledky měření jsem pak skoro rok nosil všude s sebou v batohu a právě teď se naskytla vhodná chvilka vás s nimi konečně seznámit 🙂
Anténa č.1
Toto je prvotní anténa, která byla použitá na krabičkách CUBE ONE. Celkem dlouho jsem hledal anténu na 868 MHz, která by se hodila k malé krabičče, kterou potřebujete schovat pod palubku do míst, kde není moc místa a přitom, aby nebyla zastíněná konstrukcí kříbku. Čirou náhodou jsme na ni s Martinem (PK) a Vencou (ten volačku nemá) narazili na Ampéru na jednom stánku, kde jsem ji téměř utrhl z výstavky a dožadoval se okamžitého vydání. Vlastně jsem až doteď ani pořádně nevěděl, u stánku jaké firmy to tehdy bylo. Měla červené logo a .. Byl to Sectron a typ antény byl AO-AGSM-TG09.
Anténa č.1: dodnes létá na krabičkách CUBE ONE
No co vám mám povídat? Byla to láska na první pohled! Malinkatá, s ohebným kolínkem, SMA konektorem, údajně pro pásmo 868 MHz, no úžasná. A když je krásná, tak musí přece i dobře fungovat. Nebo ne? Ale ano, funguje vcelku velmi dobře (alespoň air-to-ground). V CUBE1 měla navíc protiváhu z pocínovaného plechu pod tišťákem uvnitř krabičky, což je možná onen vliv, co vyvažuje její nevyváženost:
Vlastnosti antény č.1
Značka M1 je přibližne kolem 730 MHz (my potřebujeme 868) a oněch 868 MHz je až daleko vpravo (M2). Umístění a ohyb kolínka má nečekaně značný vliv na její vlastnosti – červená čára je anténa v narovnaném stavu, bleděmodrá je ohnutá v úhlu 90 stupňů a spodní zelená (ta tmavší) je se šrubovákem přiloženým ke kovovému prstýnku SMA konektoru (což je možná i ten vliv protiváhy). Jak to komentoval Zdenek? „Pěkná, ale tak pro děti na hraní!“.
Anténa č.2
CUBE2 potřebovala novou anténku, tedy především proto, že jsem už nevěděl, odkud byla ta předchozí. Jako ovbykle, zabralo to spoustu času a probdělých nocí strávených nikoliv u škopku ale porovnáváním různých typů, velikostí, výrobců a téměř i barev, až jsem u SOS Electronic narazil na 2J010. Skutečný klenot mezi drahokamy 🙂
Anténa č.2: aktuálně používaná pro CUBE2 a CUBE3
Pohádka o anténkách sotva začala a já ji už teď poněkud pokazím – tato krasavica je nejlepší ze všech v celém tomto přehledu. Funguje velmi pěkně na 868 MHz – koukněte na markery M2 a M3 (-16 a -23dB); M1 je v poloze 903 MHz. Spodní zelená linka je opět s přiloženým sroubovákem, přičemž jeho vliv je víceméně zanedbatelný. Anténa má skutečně nejlepší přizpůsobení pro naše pásmo, což jí umožňuje vidět ostatní kluzáky na vzdálenost 5-7 km ve všech směrech kolem přijímače (na toto má samozřejmě vliv i vzájemná poloha a orientace obou kluzáků).
lastnosti antény č.2
Anténa č.3
Další kousek s ohýbatelným kolénkem. Vypadá jako wifi, ale není to wifi. Její výkony jsou ale velmi chabé. Po přiložení šroubováku k zemi nemělo znatelného efektu, ovšem jeho blízkost k ohybu už ano. Její vlastnosti se ještě zhoršily po přiložení ruky do blízkosti až to stavu úplné nepoužitelnosti. Je to krám. Víc k tomu nemám.
Anténa č.3: slabá jak čajVlastnosti antény č.3
Anténa č.4
Má osobní favoritka. Jednou mi možnila mi sledovat letadlo ve vzdálenosti 23 km (air-to-air) ve chvíli, kdy jsem měl trochu času si za letu hrát s LK8000. A je možné, že se vyskytly i vzdálenější cíle (možná by nebylo špatné tuto informaci přidat do záznamu). Za normálních podmínek je schopná spolehlivě přijímat data z letadel vzdálených 5-10km, což ji dělá ještě skvostnější než č.2. Nicméně je poněkud neskladná a je celkem problém ji někam napasovat v kabině, obzvláště tak stísněné jako je LS1 (ale ani v osmě to nejspíš nebude zádný med ;)).
Anténa č.4: dobrá jak cyp
Železné předměty v její blízkosti nemají téměř žádného vlivu. Stejně tak i další objekty kolem jejího kořene a těla. Přizpůsobení na 868 MHz je sice o něco horší, než v případě antény číslo 2, ale díky svým rozměrům bude mít větší zisk. Na grafu níže je marker M2 na 868 a M1 na 920 MHz.
Vlastnosti antény č.4
Podobně jako anténa číslo 3 byla i tato koupena od číňana, což jí sice dává pěknou cenovku, ale zárověň přináší vsechny ty čínské problémy jako nekonzistentnost v opakovatelnosti a pravděpodobnosti doručení. A to teď ani nemyslím na celní a daňové poplatky, které nás údajně čekají od roku 2021. Některé další antény (zcela jiné typy) pořízené od ťamana totiž potřebovaly manuální doladění (ke kterému je opět potřeba spektrák) a i tak nakonec skočily ve smetí. V tomto případě jsem možná narazil na dobrý kus, možná na dobrý zdroj, nikdo neví. Ale je skutečně magnifique! 🙂
Anténa č.5
V Toužimi na T-CUPu 2019 jsem v Cirrusu u Kádi narazil na zjevně sektorovou, samodomo dělanou anténu, kterou měla u Flarmu a velmi si ji pochvalovala (a škoda, že nevěděla, kdo ji udělal, hned bych ji přidal do testu). To, že byla sektorová, usuzuji nejen z jejího tvaru (antény), ale i z toho, že údajně jdou vidět spiše okolní letadla, která jsou nad čumákem než po ním. Někde bych měl mít ještě fotku, ale jsou to holt dva roky. Nicméně i z tohoto důvodu jsem se rozhodl pořídit anténu jiné konstrukce než všesměrovou, tentokráte i s dvoumetrovým kabelem umožňující snadnější umístení někde na nebo pod haubnu.
Anténa č.5
Bohužel je v tomto případě velmi znatelný vliv kabelu na její vlastnosti. Je naladěná pro pásmo někde kolem 900 MHz, ale navíc je velmi silně ovlivněná materiálem a rozměrem předmětu, na kterém je umístěna. Takže negativ.
Vlastnosti antény č.5
Sečteno a podrtženo
Zdá se, že anténa č. 2 má nejlepší přizpůsobení pro pásmo, které potřebujeme pro naše hraní si s OGN krabičkami, zatím co anténa č. 4 poskytuje nejlepší dosah v luftě mezi letadly. Obě mohou poskytovat docela slušné výkony, především pokud jde o rozsah a spolehlivost příjmu dat. Proto jsem pro jejich další smělé využití. Problémem ovšem je, že anténa číslo 2 není v tuto chvíli k dispozici (jako spousta dalších součástek celý poslední rok) a tak přemýšlím nad zakoupením dalších vzorků typu 4 a jejich porovnáním, zda mají všechny kusy alespoň stejné nebo podobné vlastnosti jako ten jeden, který už mám. Nákupy věcí z Číny jsou ovšem značně ošemetná věc. Ať tak či onak, určitě dám vědět jako to všechno dopadlo 🙂
