pocitadlo

Autor: ibisek

Publikováno

Configuring KRT2BT in LK8000, XCSoar & SkyDemon

I am constantly receiving inquiries whether the KRT2BT adapter can be used to send frequencies directly from the LK8000, XCSoar or SkyDemon navigation applications. The answer is Yes it can! and this post will show you in detail what are the necessary configuration steps.

Bluetooth Pairing

This step is specific for each device. Works on PDAs running Windows CE or phones with Android. Please note, that Apple-based product will mostly ignore all devices without specific Apple ID – including the KRT2BT module.

In general, turn on the bluetooth in your phone/PDA and search for available bluetooth-enabled broadcasting gadgets. When powered on, the devices (including KRT2BT) broadcast a here-I-am bluetooth packet when not connected to another phone/PDA. Once paired and connected, the beacons are not broadcast and hence are not visible (!)

The KRT2BT adapter announces itself as KRT2BT and will require pin 1234. Before proceeding with the next step please make sure the the device is paired.

LK8000 Configuration

Run LK8000 and tap (M)enu -> Config -> Config -> LK8000 Setup -> Device Setup. On this screen you see currently configured devices under tabs A-F where in default installation on Android phone the A is the Internal sensors (GPS & barometric if available). Pick an unused one and in the Name field select ‚Dittel KRT2‘. Then tap onto the Port field and select your paired bluetooth device. This will vary depending on your system but you will surely find the right one easily:

Name..
Port..
Done

Here you can also see that the same way you can configure reception of the traffic information received by the OGN Cube units 🙂

Once this setup is done you can exit the configuration menu and either wait until the LK8000 will reset the ports by itself (takes sometimes a bit longer) or just restart the application which forces the communication ports to be restarted. Once the radio is connected you receive the following message on screen:

After app restart
Automatic port restart

This indicates the KRT2 radio is connected and can be controlled from the LK8000 app. Now you can find there are new entries in the menu where you can send airfield frequency to the radio or manually enter a custom frequency and send it to the top (current) or bottom (backup) position in your radio.

XCSoar Configuration

This is very similar to the setup above. Tap on the screen for the menu to pop up and go Config -> Devices. Here you can see already configured or empty configuration slots A-F.

Device configuration
Radio disconnected..
.. and connected!

Tap on one unused slot or a slot you want to replace/edit and as configure as depicted above. Until the radio is not connected (XCSoar has not received the KRT2 radio announcement packet) you will see ‚No data‘ show below the device. After the connection is established this changes to ‚Connected‘.

Similarly to LK8000 now you can send an airfield’s frequency directly into the KRT2 radio or configure and arbitrary frequency elsewhere in the menus.

SkyDemon Configuration

How to set-up and SkyDemon is nicely shown in the following youtube videos:

And that’s it! 🙂

Also do not forget there is an KRT2Bluetooth application for Android phones to configure your radio’s memory positions! It has been featured right here!

Publikováno

Potkání

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ů 🤓

Publikováno

OGN Logbook IV

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

Publikováno

Aktualizace OGN krabiček

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:

sudo bash
apt install bluez git python3
hcitool scan
^D

Pokud jste už měli krabičku zapnutou, měla by být vidět ve výpisu po provedeném scanu na posledním řádku. Pokud ne, proveďte scan znovu.

Krok #2: Stáhněte aktualizační program (skripty) z githubu:

git clone https://github.com/ibisek/firmwareLoader.git
cd firmwareLoader
python3 -m venv venv
source ./venv/bin/activate
pip install -r requirements.txt 
deactivate

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.
Publikováno

OGN Logbook III

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áž 🙂

Publikováno

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 🙂

Publikováno

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

Publikováno

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!

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

Publikováno

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

Publikováno

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