pocitadlo

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

OGN Cube Control

Způsobil to buď suchý únor, nebo hrozba blížící se sezóny, nevím. Prostě jsem se nějak dostal do stavu programovací hyperaktivity. Myšlenka, nebo možná spíše nutnost existence aplikace, kterou by bylo možné aktualizovat firmware ogn krabiček ve mě zrála stejně už dlouho a nakonec to prostě muselo ven.

S jejím vývojem jsem začal už minulé jaro. Založit jsem ji chtěl na zkušenostech získaných při vývoji V poli a VFR Manuálu před (teď už) několika lety. Velmi záhy po založení projektu jsem však narazil na nepřekonatelný problém v komunikaci s modrozubovými zařízeními, který nejspíš pramenil z mého hlubokého nepochopení souvisejícího API. Tudíž byl vývoj opět odložen na neurčito. O nějakých šest měsíců později se mi naskytla příležitost zúčastnit se mobilní minikonference Brmo, na které jeden týpek vykládal o vývoji aplikaci ve Flutteru a Dartu. Celé to vypadalo tak nějak zajímavě, přímočaře, no musím uznat, že mě to velmi zaujalo. Udělal jsem si pár poznámek a pak to tak nějak opět zapadlo. Nikoliv ovšem příliš hluboko aby se na to zapomnělo, protože už po čtyřech měsících od této akce jsem se konečně přesvědčil k tomu tu alikaci KONEČNĚ NAPSAT. A to se stalo přibližně před 96 hodinami..

Po téměř nepřetržitých čtrnácti hodinách v sobotu, dvanácti v neděli (už jsem fakt měl hlad jako drak), čtyřech v pondělí v noci a ještě jednou čtyřech dnes ráno můžu vesele ohlásit celému světu: Seče to jak sfiňa! 🙂

Pochopitelně to chce ještě tu a támhle poštelovat a poladit, ale už plánujeme, jak to dostat do Play šopu tak, aby to šlo snadno stáhnout (.apk bude taky), abyste si mohli vaše krabičky vyšperkovat tím nejnovějším a nejlepčejším firmwarem a taky, abyste z nich měli ještě víc užitku než doteď! 🙂

Velké problémy s malým filesystémem

Kompletní záznam celého letu by byla krásná funkce OGN krabiček. Problémem ovšem je, že SD karta, na kterou se záznam ukládá, se relativne rychle opotřebuje. Způsobuje to častý zápis do FAT tabulky, konkrétně pole poslední modifikace souboru, ale hlavně alokace sektorů a velikost souboru, které je pokaždé ve stejné buňce FATky. Času a datumu změny se lze snadno zbavit, ale ostatních častých zápisů už moc ne. Moc tomu ani nepomáhá velikost RAM (20kB) použitého mikrokotroléru a velikost sektorů (512B) FATky.

Proto jsem se rozhodl ji nahradit LittleFS. Schopnost filesystému přežít výpadek napájení, ale hlavně wear leveling (t.j. rozprostření ošoupávání buněk flešové paměti na celou kartu) napovídají tomu, že by karta mohla ve zdraví přežít značně větší množství zápisů a že toto je ta správná cesta. To vše jen do chvíle, kdy se 4000+ řádků LittleFS zkompilovalo do více než 8kB binárky, a to i po vynucení té nejsilnějsí optimalizace na velikost a nezahrnování nepoužitého kódu.

Toto, v kombinaci s blížícím se dalším problémem (konkrétně rozsáhlostí mého vlastního kódu + s bluetooth booloaderem taktéž o velikosti 8kB) způsobilo, že se podpora LittleFS prostě nevleze do 128kB flash paměti programu použitého mikrokontroléru F103CB.

A co ted s tím? Nabízí se dvě možnosti. První z nich je nahradit F103CB MCU jiným ze stejné řady, který má více FLASH, jako například F103CB. Ten má ovšem 64 nožiček a tudíž nesedne do footprintu na tištáku, kde se počítá jen se 48 nožičkovým pouzdrem. Proto je druhou otevřenou možností jej nahradit jiným – F030CB, který má stejný footprint (to je mimochodem moc pěkná vlastnost mikrokontrolérů od STM, že se snaží dodržovat stejný pinout i mezi různými řadami jejich MCU) a 256kB FLASH + 32kB RAM. Nemusel bych dělat nové tišťáky, ale budu muset upravit kód, aby podporoval architekturu F030ky (ARM Cortex M0 vs. M3, sběrnice a periférie jsou připojeny občas někde jinde a podobně). Ale zůstalo by tak stejně malé pouzdro s tím, že by se otevřely další možnosti vývoje! 🙂

Ovšem věci nemohou jít nikdy jen tak snadno. V několika posledních měsících jsem zaznamenal, že System Workbench for STM32 (sw4stm32) který používám není schopen stáhnout SPL firmware. Nepomáhá ani jejich ruční instalace z webu STM. Dotazoval jsem se proto na fóru openstm32.org (tady poprvé a tady podruhé), zda má někdo řešení tohoto problému, ale zatím neúspěšně.

(Edit) Tak nakonec se mi podařilo najít cestu jak to obejít 🙂

(Edit2) Zde je ke stažení záloha STM32 firmwarů které byly ješte dostupné na serverch odkazovaných v souboru stm32targets.xml.

CUBE3 jsou k dispozici!

Před pár týdny jsem nahoru do menu v tichosti přidal nabídku Choose & Buy, jen jsem však nějak pozapomněl ji zpropagovat i tu uprostřed. A před chvilkou jsem si i všimnul, že poslení příspěvek z dubna lehce naznačuje, že to tu umřelo. Tak to přitom ale vůůbec není! 🙂

Udělali jsme dvacet pět dalších krabiček (opravdu 25 navíc) a ty ted rozesíláme po celé zeměkouli! Protože jsem chtěl ruční výrobu poněkud urychlit, nechal jsem přibližně polovinu součástek na deskách osadit na mašině. Polovinu proto, že modely A a B mají něco společného a ten zbytek je rozdílný. A ač jsem zpočátku moc nevěřil, že to dopadne dobře, bylo to úplně zbytečné a příště nechám už osadit asi úplně všechno. Plánuji o tomto dobrodružství napsat delší povídání, něco jako příběh pokusu o malou sériovku bez jakýchkoliv přechozích zkušeností a znalostí.

Ale protože je půlka sezóny za námi a řádků v zápisníku je pomálu, pojďme raději nejdřív plachtit! 🙂

HROMADA krabiček

Dlouho jsme se neviděli, no ňi? Celý měsíc jsem totiž pracoval na změnách na tišťáku (jajaj), objednával součástky, třídil je, dohledával další, o kterých jsem ani neveděl, že mi chybí, pájel je, a nakonec tisknul krabičky a nálepky. A to všechno jen proto, aby bylo během závodů veselo i na zemi.

Postavit hromadu krabiček není jen tak, ale stejně tak důležité je i jejich důkladné vyzkoušení. Proto jsem s nimi jezdil kolem komína i okolních okresech jak vzteklý. A hlavně k večeru, kduž padla tma, tak to muselo vypadat jako když jedou hasiči, když celé auto blikalo všemi barvami, převážně modře.

Po úspěšném otestování všech krabiček bylo načase jim postavit nový domov.

No není to paráda? Ibišku, dobrá práce, fakt že jo! 🙂

První dvě trojky jdou do světa!

Přišl ten velký den, kdy se první dvě krabičky třetí generace vydaly do světa 🙂 Vybaveny jsou tříosým akcelerometrem pro monitoring zatěžování letadla a nově i záznamníkem letů, který počítá a ukládá časy startů, přistání a doby letů do souboru na SD kartě. První z krabiček začne svůj slavný život v Piperu 28, druhá bude poletovat všude okolo v pro oko našince podivně vypadajícím Morane-Saulnierovi MS.880.

Navzdory podivně vypadajícímu mikroUSB konektoru je možné tyto trackery napájet přímo z palubní sítě 12V (prakticky od 4 do 15V). Samozřejmě jsou vybaveny tak jako všechny předchozí modrým zubem, přes který se do navigace dostanou informace o okolním provozu, aktualizace firmwaru a navíc je přistupný i logbook pro stažení do androidího telefonu pomocí specializované aplikace (hned jak ji napíšu 😉 ).

A protože času není nazbyt, tak ještě navíc provádím experimenty s rozličnými krabičkami pro různé varianty – shora dolů: tenkou (napájení přes mikroUSB, vysoká 17mm), standardní (RJ45, 20mm) a tlustou pro baterií napájenou variantu (24mm).

Zpátky ve hře

Znáte takovéto když se řekne „Já mám kamaráda, co má kamaráda..“?

Tak já vám řeknu, že mám kamaráda, co má kamaráda, který umí pájet jak největšíborecnazeměguli! Bez nadsázky. Za použití mikroskopu a infraohřevu dokázal osadit dvacetičtyř(ne)nožičkový integráč o rozměrech 3×3 mm bez toho, aby se mu nespojily a zároveň dobře připájely všechny jeho (ne)nožičky. Popravdě řečeno, ještě jsem nikdy neviděl takto čistou a skvělou práci. Paráda!!

Je to tak okulahodící, no podívejte:

V tuto chvíli to znamená, že jsme ověřili správné zapojení a návrh destičky a tudíž můžeme začít se skutečně brutálně masivní výrobou. Někteří sice brblají, že nevidí v akcelerometru zádný užitek (tak ho tam nedostanou a bude :P), ale pro mnoho z vás, ne tak zaslepených, to bude užitečná funkcionalita.. teda aspoň doufám. No řekněte, že ano!

Takže se těšte, protože je kurňa na co! 🙂