pocitadlo

KRT2 Bluetooth adaptér

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 🙂

Okolní provoz v XCSoaru a LK8000

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

OGN logbook II

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!

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! 🙂

Už tam budem?

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ě! 🙂

MCU dilema

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! 🙂

Antény, antény, a zase jenom antény!

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 čaj
Vlastnosti 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 🙂

Co vše se lze naučit při vývoji ognLogbooku

Jak jsem již zmínil dříve, to, co mělo být rychlým víkendovým projektíkem se změnilo na čtyřměsíční martirium ladění algoritmů a jejich nastavení. Dokonce i teď v listopadu není ognLogbook stále ve formě a ve stavu v jakém by mohl a měl být. V tomto příspěvku bych rád popsal problémy a jejich řešení, se kterými jsem se setkal během vývoje takovéto, na první pohled jednoduché a jasně definované aplikace.

První falešné případy detekce vzletu a přistání byly zaznamenány při nácviku startů z navijáku na letišti v Kolíně. Detekční rutiny založené hlavně na pozemní rychlosti (Ground Speed, GS), prahových hodnotách rychlostí a minimální době letu (přece nejde zaletět okruh rychleji než za 2 minuty, nebo jo?) Vše selhlalo, když rychlost při vzletu na navijáku klesla po odpoutání téměř na 0 km/h (kobra jak cyp, asi za to pěkně tahali), zde zůstala nějakých 5-8 sekund ve stoupání a konečně na okruhu pokračovali s Blaníkem těsně nad minimálním nastaveným limitem GS. Aby to nebylo tak jednoduché, tyto odvážné dívky a chlapci navíc trénovali nouzová přistání kolmo přes dráhu, čímž zkrálili dobu letu jednoho „okruhu“ klidně na nějakých 60 sekund.

Později v tom samém týdnu jsem zaznamenal druhý problém s detekcí – GS opět blízko 0, když ementálka (nebo noví instruktoři?) v Mejtě nacvičovali vývtrky. A kdyby jenom jednu otočku, oni hned několik za sebou! V tomto případě bylo zaznamenáno přistání, které hned následoval okamžitý vzlet na tom samém místě, což bylo způsobeno vágně nastavenými prahovými hodnotami v algoritmu pro detekci letmého přistání (kačenkou).

A ješte jedna taková perlička nastala ve chvíli, když se nějaký bojovník (či -ce) odvážně se vydavší do termiky za podmínek silného severozápadního proudění snažil se svým Šemíkem vtěsnat do úzkého stoupáku v proklatě malé výšce, přičemž ani do toho Hradce mu to v tu chvíli nevycházelo. Rychlost, na které umí Blaník kroužit mínus rychlost větru se opět dostala pod hranici nastavenou jako limitní pro přistání.

WTF?!

Další takový špek byl detekován jednoho dne v Polsku jak naznačuje tento obrázek. Teorií je, že po opravě motoru nechtěl tento (motor, mechoš určite ano) moc dobře vrčet a tak jej štelovali krátkými skoky po dráze. Zde již byla zavedena podmínka indikace vzletu po překročení určité minimální výšky (AMSL) při vypnuté podmínce minimální délky letu. V tomto případě to tedy bylo vyhodnoceno jako velmi krátké lety. Což je prakticky asi správně.

Přetrvávající problémy s detekcí startů a přistání mě tedy dovedly k nutnosti vytvoření další podmínky – výšky nad terénem (AGL). Jako obvykle mi ovšem odmítala fungovat lopata a těch pár ukázek, jak zacházet s GDAL knihovnou se mi nikdy nepodařilo oživit. Dobrou zprávou bylo, že reliéf terénu je volně k dispozici ze družice jménem Copernicus s neuvěřitelným horizontálním rozlišením 20m a použít to nějak půjde. Musí. Soubory s dlaždicemi, pokrývajícím celou EU mají pěkných 32GiB. Po zmenšení rozlišení na 500x500m se mi podařilo získat jeden 8MiB soubor pokrývající území celé EU. Což bylo jedinně dobře, protože v tu chvíli jedinný způsob jak pro danou polohu získat nadmořskou výšku terénu bylo spawnovaní externího procesu při volání nástroje gdallocationinfo na příkazovém řádku s následným parsováním jejo výstupu do konzoly. Samotné toto volání je pochopitelně pomalé, navíc, když se pokaždé musí načíst oněch 8MiB datového sobouru z disku do paměti (rozdíl mezi klasickým HDD a SSD byl skutečně enormní). Z toho důvodu byly tyto dotazy používány jen v blízkosti startu a přistání, ale jak bylo popsáno výše, toto stále nestačilo. Asi o měsíc později jsem ve fóru konečně narazil na nápovědu, jak úspěšně využít gdal přímo z Pythonu. Řřešení je relativně pochopitelné: verze pythonní knihovny musí být stejná jako binárka v systému, takže je potřeba ji downgradovat a zafixovat. Toto tedy konečně umožnilo nejen zvýšit rozlišení dlaždic na 200x200m (soubor 160MiB), ale jen jedno načítání do paměti při startu aplikace zároveň umožnilo počítat výšku nad terénem v každé poloze a tím pádem vyřešit některé z výše popsaných problémů. Ale zbývá samozřejmě ještě jeden problém – terénní data pokrývají pouze území EU. Ve zbytku světa je tedy velká díra..

Nejčerstvější zapeklitos se oběvila teď na podzim s příchodem vlnové sezóny. Rychlost větru v FL195 může být tak vysoká, že tam ta naše létadla prostě couvají – mají zápornou GS, což je samozřejmě také pod všemi nastavenými hranicemi pádových rychlostí. Nicméně teď už to zachraňuje algorimus výpočtu AGL popsaný před nepatrnou chvílí. Zdravím do ESNC (to je ve Švédsku)! 🙂

Původní ognLogbook pokrýval území jen do vzdálenosti 300km od našeho baru v Křižanově (holt pupek světa). Ale už během (tajného) testovacího provozu stačil někdo vykect adresu a tak se začali ozývat hlasy i z okolních zemí dožadující se, aby bylo pokryto i to jejich letiště. Proto byl rádius rozšířen na 1000km, ovšem stále omezen zejména z důvodu výkonosti tehdejšího serveru. Ten spočíval na ramenech torza rozbitého notebooku se slušným dvoujádrem Core i7-3537U, což do té doby mohlo stačit. Ale nestačilo. Limit výkonu byl rychle překročen jednoho polojasného letního dne, kdy celá Evropa vytáhla i toho posledního hadráka ze zaprášeného rohu do té doby opuštěného hangáru a s vidinou tisícikilometrových přeletů se směle vydala na štreku. Poslední stabilně zpracovávaný provoz z OGN sítě byl 120000 beaconů (paketů, poloh) za minutu. Celková kapacita front v u dobu byla z nějakého důvodu omezena na pouhý jeden milión záznamů a všechny co se nevlezlo bylo prostě zahazováno.

Kapacita pro zpracování dat z OGN sítě narazila na nechtěné limity.

Toto samozřejmě nebyl žádný závažný problém. Stačilo jen změnit kapacitu front na nekonečno (fyzicky 8GB RAM) a už se neztratil ani jeden bajt. Pouze vyprázdnění těchto front pak zabralo o neco více času – do brzkých ranních hodin .. o dva dny později.

Bylo tedy jasné, že pětivláknová pythoní aplikace na 4 jádrech (z toho jen 2 fyzických) to prostě za daných podmínek rychleji nezvládne (vlákna: 1. – příjem dat, dekédování a rozřazení, 2. – OGN beacon processor, 3. – FLARM beacon processor, 4. – ICAO beacon processor, 5. – maria db insertion queue a konečně 6. – influx db insertion queue). To šesté bylo možné přidat až po přesunu na výkonnější ‚CML7‘ – virtuální mašinu s přiřazenými 4 fyzickými jádry CPU Intel Xeon Silver 4214 @2.20GHz. A jak byste čekali, od té doby už žádný další takový problém nenastal 🙂

Objem provozu v OGN síti teď ke konci listopadu: zelené tečky v horním grafu indikují počet přicházejících beaconů za minutu, oranžové celkový počet nezpracovaných záznamů ve frontách. Dolní graf zobrazuje provoz podle typu trackeru: modré jsou Flarmy, oranžove ICAO a zelené OGN trackery. OsyY jsou v logaritimické.

Takže dokud nám náš štědře zapůjčený stroj běží, máme skvělou a možná i jedinečnou příležitost si dále s daty z OGN sítě hrát a analyzovat je. Kde se průměrný údržbář-traktorista z aeroklubu jako je ten náš normálně dostane ke zpracování real-time skutečně big dat(a)? 🙂 V tuto chvíli jsou zaznamenávána všechna dostupná data všech letů na celé planetě (teď tam čile spatříte například i provoz v Čile či Austrálii) do influxu pro pozdější kompletní a detailní analýzu záznamu letů (ta, co ještě není). Nicméně určitě ne na furt – doba po kterou zůstávají záznamy dostupné je omezena na jeden týden. Důvodem není jen jejich objem (800 miliónů záznamů během posledních srpnových latí), ale hlavně .. proč?

Práce, která stojí (a není zajíc ani ženská) je stále hodně – jak na straně backendu (algoritmů zpracování), tak i na webovém rozhraní (například responzivita, live data feed). Nebo to celé přepsat do rustu? Pokud byste měli zájem si to také zkusit, chcete se zabavit, nebo vás prostě jen neco štve a nikdo s tím nic nedělá, můžete směle přiložit ruku k dílu a jste vřele vítáni na GitHubu https://github.com/ibisek/ognLogbook. Jakékoliv vylepšení oceníme dozajisté úplně všichni 🙂

OGN logbook

Čekání na součástky, objednané pro novou verzi CUBE 3.1, bylo už nekonečné a tak jsem se nechal přesvědčit k nakódění nového logbooku, když ten kissácký prý už nefunguje. Kvůli přetrvávajícímu monzunovému počasí můžeme stejně jen znovu a znovu leštit navlhlé krovky a o létání si vykládat leda tak na letištním baru. A napsat takový loogbook může přece trvat tak den až dva.. a nebo?

Popravdě – ano i ne. Skutečně fungoval už v neděli navečer, ale ladění všelijakých zapeklitých detailů zabralo dobře další měsíc. (Jakou ground speed ma Blaník startující na navijáku? A jakou při vývrtce?) V tuto chvíli se většina věcí (připouštím, že je tu ještě pár ne úplně chtěných vlastností) zdá být stabilní a tak slavnostně celému světu oznamuji vypuštění úplně nového a krásného OGN Logbooku! 🙂

Na hlavní stánce lze spatřit veškerý provoz, jak se aktuálně děje. Jsou zde však mírné nuance podle nastavení jazyka prohlížeče. Pokud je nastaven jako čeština či slovenčina, budou se zde zobrazovat jen letadla z letišť a ploch s ICAO kódem začínajícím LK a LZ. V případě, že je jazykem prohlížeče „hákoština“ (píšete švabachem), uvidíte zde primárně provoz na letištích ED, LO a LS. A pro všechny ostatní hatmatilky se zobrazuje veškerý celosvětový provoz dohromady.

Po kliknutí na ICAO kód některého z letišť se zobrazí informace o jeho provozu v konkrétní den. Ve dnech lze dále listovat šipečkami po stranách datumu uvedeného v hlavičce stránky. Kliknutím na registraci letadla se pak dostaneme na detail a součty letů konkrétního letadla ve zvolený den.

Tu se nesmíme nechat vyvést z míry v případech, kde se některé informace zdají jako špatně spočítané. Například v seznamu nahoře je odlet v 9:51 a přistání 9:58 spočítáno jako 6 minut letu ač by tam mělo být minut 7. Je to způsobeno tím že čas startu i přistání se pro zobrazení zaokrouhlují na celé minuty, zatím co je doba letu zaznamenána po sekundách a až teprve pak zaokrouhlena na minuty. Vypadá to možná divně, ale je to tak. Jak počítat čas letu, aby to vyhovovalo všem zúčastněným je stále otázkou pro vášnivou diskuzi..

Jak již bylo zmíněno, logbook analyzuje veškerý provoz v OGN síti. Nicméně záznam vzletů a přistání je omezen pouze na události, ke kterým dojde do 4 km od známých ploch. Tento seznam je založen na ŘLPáckém VFR Manuálu a dále na informacích z openflightmaps.org. Žádné jiné pohyby (včetně přistání do polí) nejsou v tuto chvíli zaznamenávány. Podmínkou pro start je překročení 50km/h a pro přistání 20 km/h pro kluzáky, 50km/h pro motorové mašiny. Navíc dodatečnou podmínkou pro přistání je i výška menší než 160m nad terénem.

Užitečná vlastnost hlavně pro ty, co opisují šmírák do Flight Office, je možnost exportu .csv souboru, kterýžto pak lze importovat do FO. Ke stažení tohoto souboru pro daný letový den se dá dostat po kliknutí na ICAO kód letište v hlaviččce stránky detailu letiště. Url zde získané lze i snadno použít pro vlastní skripty. Navíc je právě v přípravě přímý import dat ze stránek logbooku do FO na jedno jedinné kliknutí 🙂

Předpovídání možných sblížení a hrozících kolizí

Věštění z křišťálové koule je něco, co jsem si chtěl zkusit už dávno. Mít rozumné varování před blížícími se problémy je určitě užitečné, obzvláště v dnešní době, kdy stále více pilotů čucí do obrazovek a co se děje venku pro ně není až tak podstatné. Zároveň upozornění na kolizní provoz musí být rozumné a nemělo by otravovat ve stoupání s dvaceti ostatními větroni, nebo ve chvíli, kdy visíme padesát metrů za vlečnou. Ale jak to udělat? Dnes vás čekají kouzla a čáry!

Základem je práce s informacemi, které můžeme odchytit přímo z éteru. OGN krabičky poslouchají a rády přijímají zprávy vysílané okolními trackery. Když budeme zpracovát údaje o poloze, výšce, směru letu a pár dalších parametrů každého letadla, které uslyšíme na vyhrazených frekvencích, mohli bychom za použití sofistikovaných matematických modelů předpovídat jejich budoucí trajektorii. Ale protože mozeček našich krabiček má svá omezení, je pořeba přizpůsobit tyto algoritmy jeho možnostem.

Začněmež tudíž jedním bodem – nejčerstvější informací o poloze jiného letadla, kterou jsme právě přijali. Tento paket (beacon) obsahuje jeho identifikaci, rychlost, výšku, směr letu, rychlost stoupání či klesání a úhlovou rychlost (t.j. jak rychle zatáčí, jak moc to má v tom šprajcu zalomené). Z tohoto singulárního údaje o aktuálním stavu můžeme iterativně spočítat budoucí polohy v prostoru v diskrétních bodech (resp. časových intervalech). V případě, kdy máme informaci z dvou (či více) takových beaconů, můžeme do výpočtu odhadu trajektorie navíc přidat změny dopředné rychlosti, úhlové rychlosti a změny výšky. A samozřejmě musíme počítat s tím, že čím dál do budoucnosti se díváme, tím nám narůstá neurčitost odhadované polohy. Ne to je třeba nezapomínat. Ale i tak to vypadá, že to bude fungovat poměrně dobře.

Jednobodová předpověď trajektorie letu letounu letícího severním směrem přes střechu hangáru majícího konstantní dopřednou rychlost, směr letu a konstantní úhovou rychlost.

Pro předpověd naší trajektorie letu použijeme úplně ten samý postup výpočtu. Následně zkombinujeme jednotlivé predikované body obou tratí a spočítáme vzdálenosti mezi nimi. Následně, tedy za předpokladu že uvažujeme náš a jeho heading (ehm, směr letu) v každém bodě, můžeme vydávat informativní varování o okolním provozu. A tak nějak by to teoreticky mohlo fungovat.

Situace, ve které jde kluzák do průletu před/nad jiným startujícím letadlem. Z prvotního pohledu plachtaře se zdá, že má dost času a místa se vyhnout, nicméně ke kolizní situaci může dojít právě v místě druhého křížení trajektorií, kde cessna už letí ve větší výšce a klesající kluzák nevidí. Navíc plachtař v tu dobu může mít plné ruce práce s klesajícím érem, věnujíce více pozornosti přípravě na přistání.

Takže teď je potřeba podrobit popsané hypotézy praktickým zkouškám v luftě. A pokud by se náhodou stalo, že o mě uslyšíte na příštím zimním školení v rozboru nehod, tak tato celá teorie byla zřejmě chybná 😉

OGN Cube Control je venku!

Netrvalo to až tak dlouho, podařilo se nám dostat aplikaci do Androidího Play storu (Peťo, děkujeme!) a tudíž je mou ctí oznámit, že si ji můžeme odtamtud vesele stahovat!

V tuto chvíli je pro stáhnutí a flešnutí firmwaru potřeba být k internetu (do chvíle zvolení firmwaru ze seznamu). Nicméně pro lidi bez datového připojení (jako já) není vše ztraceno a offline režim je vysoko na seznamu plánovaných akcí 🙂