MESHTASTIC - Po jednom roce

UPOZORNĚNÍ : Texty na tomto blogu jsou psány srozumitelně pro laiky a mohou obsahovat zjednodušení a nepřesnosti, které nemohou vyhovovat profesionálním standardům. Profesionálové tak mohou mít k obsahu výhrady, což je v pořádku. Přesto věřím, že i tyto informace mohou pomoci začátečníkům lépe pochopit Meshtastic a vyhnout se chybám, které jsem sám udělal.

V lednu 2025 uplynul rok od chvíle, kdy jsem začal provádět první experimenty s Meshtastic zařízením. Mým prvním zařízením byl T-Beam. Postupem času jsem si pořídil další typy, jako například Heltec HT-CT62, Wireless Stick V3 (s displejem), XIAO-WIO-1262 a RAK4631. Nedávno jsem si pořídil kompaktní SENSECAP Tracker, který nosím s sebou 24/7 k monitorování funkčnosti sítě při veškerých denních aktivitách po městě a na stole mám SENSECAP Indicator. 

Nejhrubší experimenty s Meshtastic jsem prováděl na prototypové desce založeném na HT-CT62. Tento hardware musel vydržet veškeré pokusy a omyly, které doprovázely vývoj. Mít vlastní testovací zařízení bylo fajn pro všechny experimenty, od základních až po pokročilé – od připojování periferií, výběru dobíjení, logování provozu při experimentech, až po úpravy firmwaru či výběr antén apod. Je to fest-bastl, dovolil ale rychle jakékoliv úpravy a "beztrestnost" v případě neúspěšnosti experimentu. 

Přesto se stále vracím k "all-in-one" desce T-Beam. Díky její kompaktnosti, displeji, počtu dostupných GPIO,  GPS, PSRAM, poměrně dobré citlivosti a solidní výdrži na baterii (stačí vsunout standardní 18650 baterii do slotu bez pájení). Navíc se jedná o ESP32 desku, na které lze snadněji dělat pokusy s úpravou FW (VSCODE + PlatformIO). S doplněním o pípák a se zapnutým modulem "External notification" (GPIO13) je to nejlepší bastl-deska na nejširší možné testování a využití - doma na stole a hlavně v terénu. Doporučuji ale používat výhradně verzi s SX1262. Samozřejmě, výdrž se nedá srovnávat s RAK zařízením.

Síť byla zpočátku, a pravděpodobně stále je, poměrně tichá a málo využívaná. V Brně, kde trávím 99 % svého času, byla síť v té době ještě naprosto nepoužitelná. Co bych za to dal, kdyby existoval podobný návod. Zpočátku to bylo způsobeno nedostatečnou hustotou uzlů po městě. To přirozeně, místo posílání zpráv bez odpovědí a do tmy, vedlo k experimentům a objevování toho, jak to má fungovat. Meshtastic je totiž relativně jednoduchá, přístupná a otevřená technologie, která nabízí neomezený prostor "zabíjet" čas nebo utrácet peníze v libovolné míře. Za pár stovek lze experimentovat s hardwarem, upravovat software, naladit si vlastní anténu, získat zkušenosti s šířením radiového signálu.

Později se však situace zlepšila. Především díky dostatečnému zahuštění sítě a také díky "páteřní síti", kterou budoval jeden z nadšenců. Kromě promyšlené infrastruktury bylo navíc v Brně několik velmi osvícených a technicky zdatných uživatelů, kteří významně přispěli k dalšímu zkvalitňování sítě - notoricky známá „Ping“ služba. Ta je (a stále bude) neocenitelným nástrojem. Dokonce už si něco podobného můžete snadno a rychle zprovoznit i doma - viz. příklad kompilace vlastního firmware. Služba umožňuje jednoduchým dotazem (odeslání zprávy Ping) rovnou v terénu ověřit, zda je vše v pořádku. Současně zjistit úroveň signálu a viditelnost uzlu z pohledu druhé strany (uzel, který obdrží od někoho "Ping" odpoví "Pong" a připojí ještě informaci o SNR a RSSI). V době, kdy síť v podstatě nefungovala a spolkla cokoliv, Ping dostupný na síti 24/7 byl fajn pomocník (aktualizace červ 2025 - v Brně si už běžně na LF plnohodnotně povykládáte s AI chatbotem, když není v okolí nikdo aktivní a neodpovídá). 

Dalším důležitým faktorem, který přispěl k úspěšnému rozvoji byla možnost fundované komunikace přes telegramový kanál (*JMK). Jestli Brno se posunulo tam, kde je, pomocí páteřní sítě, nástroji k testování sítě a spoluprací (řešení problémů, sdílení zkušeností apod. na Telegramu), mělo to jedno společného jmenovatele - KOMUNITA. 

Nyní stav v online prostoru reflektuje, tak jako v případech mnoha podobných sexy-technologii, "hype" fázi. Každý z kanálů s několikanásobným nárůstem uživatelů sice dále plni funkci inkubátoru všemožných nápadů, vůbec hledání využití této technologie.

Osobně mi z toho všeho vyplývá, že pro další rozvoj sítě (spolehlivosti, služeb a obsahu) bude důležitým faktorem návrat k menším a  úzkým skupinám lidí (uživatelů), kteří budou spravovat lokálně doporučení pro provoz a konvence pro využívání sítě. Samozřejmě za předpokladu, ze i progresivnější a ambicióznější uživatelé, kteří budou experimentovat a provozovat zařízení "na hraně", provozem mimo dobu takových experimentu budou respektovat doporučené pravidla a konvence. 

Dost nostalgie a úvah! Nyní přijde (snad) něco praktického...

Z mnoha experimentů jsem dospěl k následujícím poznatkům, opřených o poměrně pečlivé a pracné testování či ověřování:

• Je dobré mít už od začátku alespoň dvě zařízení. Jedno může být vybavenější, zatímco druhé může být jednoduchý Heltec za přibližně 500 Kč z AliExpressu. Možnost sledovat, jak zařízení mezi sebou komunikují, výrazně usnadní rychlé seznámení s technologií a pomůže nastavit správná očekávání – zejména co se týče spolehlivosti. Mimo čas experimentů mějte prosím aktivní pouze jedno zařízení - dvě aktivní zařízení hned vedle sebe jsou mimo čas experimentů spíš problém než výhoda.
  
  
  
  
• Pokud nemáte možnost pořídit si dvě zařízení, připojte to jedno přes USB/Serial k počítači a sledujte, co posílá v logu (například pomocí obyčejného terminálu). Získáte tím mnoho užitečných informací o tom, co se v zařízení děje, co právě provádí a kdy komunikuje se sítí. Toto je naprosté minimum, které by měl každý udělat při seznamování s Meshtastic. Případně alespoň sledujte v aplikaci "Debug Panel" ať máte alespoň nějaké povědomí, jak je síť aktivní.
  
  
• Je vhodné vycházet z doporučeného nastavení zařízení. Teprve posléze, až se seznámíte s provozem zařízení, uzpůsobit nastavení svým potřebám. Doporučené nastavení naleznete zde.
• Je NUTNÉ pořídit si alespoň GIZONT anténu (868MHz) na zařízení, které budete nosit s sebou (mobilní). Dále je vhodné mít jednu magnetickou anténu asi za 150 Kč, kterou lze připevnit na venkovní parapet okna. Doma pak doporučuji mít stacionární uzel (například levný Heltec) připojený právě na tuto externí anténu. Dodávané antény jsou naprosto nevhodné. Pokud někdo stále používá originální anténu a stěžuje si, že mu síť nefunguje, je to většinou příčina jeho problémů. Kdo si nenechá poradit, tomu není pomoci. Magnetickou anténu lze navíc využít i při cestování autem. Mějte vždy na paměti, že pokud zařízení necháte uvnitř auta za čelním sklem, citlivost klesne o několik dB (i běžný pokles o 3dB je dost, aby to přestalo komunikovat s venkovním okolím). V každém případě to významně zhoršuje spolehlivost komunikace. Proto magnetku mějte na vždy venku kapotě - rozdíl uvidíte ihned. 
  
  
• Anténa je základ. Bohužel se nelze spoléhat na informace uváděné u antén na e-shopech. Výše zmíněné antény jsou ale z těch e-shopových ověřené. Kdo musí kupovat naslepo, určitě výběrem těch zmíněných chybu neudělá. Místo nákupu drahé antény (1000Kč a víc), je ovšem lepší investovat několik stovek do nástroje, jako je nanoVNA. Postavte si a nalaďte podle tahaku anténu vlastní. Mezi jednodušší typy, které si můžete vytvořit sami, patří například ground-plane anténa nebo kolineární anténa z koaxiálního kabelu.
  
  
• Minimálně jednou si vyjeďte mimo město a na volném prostranství, například na poli, si vyzkoušejte posílání zpráv na přímou viditelnost. Zprávy budou fungovat poměrně dobře i na vzdálenost několika kilometrů. Na LongFast (LF) je běžné dosahovat více než 10 km, přičemž komunikace je stále dobře použitelná. Tento test může být vůbec jednou z prvních pozitivních zkušeností, které vám ukážou, jak síť může fungovat. V tomto konkrétním případě však půjde spíše o peer-to-peer komunikaci než o skutečný mesh.
• Meshtastic nefunguje jako běžné komunikační aplikace typu WhatsApp, Messenger a podobné. Snižte svá očekávání na úplné minimum, abyste se vyhnuli zklamání. Na rozdíl od Meshtastic existují spolehlivé komunikátory, které činí Meshtastic poměrně tichou sítí. Jednotlivci zde komunikují poměrně zřídka a to pouze ve svém volném čase, což se odráží i na provozu uzlů – mnoho z nich je během dne vypnuto. Nedivte se, když je na síti naprosté ticho.
• V mnoha případech, kdy byla síť naprosto nepoužitelná, se mi osvědčilo vymazat v aplikaci NodeDB a po 15 minutách zkontrolovat, kolik uzlů se stihlo obnovit. Právě v situacích, kdy nic nefungovalo, bylo zřejmé, že mnoho okolních uzlů bylo neaktivních (neobnovili se tedy ani v NodeDB). Tím pádem v okolí nebylo k dispozici komu předávat zprávy a ani přijímat nové zprávy. Tímto krokem zjistíte, proč síť momentálně nefunguje tak, jak bývá obvyklé. 
  
  
• Kupte si USB SDR přijímač a sledujte provoz sítě. Je to sice už odbornější záležitost, ale okamžitě budete schopni vidět, jak pakety "letí vzduchem" ve vašem okolí. To vám může pomoci lépe pochopit, jak síť funguje, nebo zjistit případné problémy. Současně můžete také odhalit blízké zdroje rušení, pokud nějaké v okolí máte. Je možné třeba, ze se vám válí něco podobného v šuplíku (USB DVB-T tuner, modrý vlevo). Pokud však máte ambice zkoumat provoz ve frekvenčním spektru detailněji, na zaklade doporučení zkušenějších uživatelů zvolte rovnou lepší variantu (vpravo) ve verzi 3 nebo 4 (na zařízení je verze vidět na jeho levém spodním rohu). 
  
  
  

  Provoz na "frekvenci" můžete sledovat jak doma na stolním počítači/laptopu, tak i v terénu na mobilním telefonu s příslušným ovladačem. Osobně používám běžně dostupné freeware programy - pro desktop je to HDSDR (Windows/Linux) a na mobilním telefonu aplikaci SDRTouch pro Android  + příslušný Rtl-sdr driver (obojí dostupné na Google Play). Pro připojení USB SDR přijímače budete navíc potřebovat USB redukci - aby USB-A zařízení bylo možné zapojit do USB konektoru vašeho telefonu (s největší pvd. USB-C nebo USB-Micro).

  
  

   
  
  
• Oblíbené LF/MF – neustále diskutované téma. MF by mělo byt primárně určeno pro krátké vzdálenosti spojení, a proto i tým vývojářů Meshtastic nastavil jako výchozí typ spojení LF. LF je lepší pro spojení ve městech, mezi vesnicemi a i mezi kopci. Až budete testovat spojení, jak jsem uvedl již dříve, vyzkoušejte rozdíl mezi LF a MF a sami uvidíte. V tomto případě však doporučuji testovat v lese, kde rozdíl bude rychleji patrný než v podmínkách přímé viditelnosti. V lese nenachodíte tolik, kolik na poli s přímou viditelností. O LF a MF jsem se rozepsal podrobněji zde.

Situace v Brně

V provozu je primárně LF (ale začíná se objevovat současný provoz i na MF), s přibližně 100 LF/ 20MF uzly po městě o rozloze 230 km², poměrně členitý terén s údolími a kopci. Město má asi 15 km z jedné strany na druhou, a dnes je běžně možné dosáhnout vzdáleností až 3 hops (před rokem bylo nemožné doručovat zprávy ani na 2 hopy). SNR bývá běžně o 2 dB horší než mimo město. Na podzim 2024 probíhalo v večerních hodinách nad Brnem desítky paketů za minutu. Kolik jich je dnes, budu zase zjišťovat při další vhodné příležitosti (rozhledna Holedná nad Jundrovem).

Dnes, po roce, bych řekl 75% zpráv na krátko zafunguje (aktualizace červ 2025 - chodí už běžně 95% zpráv, dokonce i víc). Přehled ale, kolik procent uživatelů má podobnou zkušenost nemám. Co se ale radikálně změnilo a považuji to za naprosto průlomovou změnu, je propojení "přes celé město". To už po roce možné je a "už začíná nějak fungovat". Podíl na tom má síť v této podobě (ověřeno smazáním NodeDB na Z001 a následnou kontrolu obnovených aktivních uzlů v okolí do 15min - dne 2025-02-20 12:00). Viz. obr. zde.

 
Jde o síť uzlů v režimu LF. Na stejném území však už opakovaně dochází i k ověřování režimu MF (kompatibilita s okolními regiony). Pokusy ale zatím končí neúspěchem. MF z důvodů vyšších požadavků na kvalitu signálu, zvýšené závislosti na počtu vyžadovaných HOPů (vycházející z především z nároků na nesrovnatelně vyšší hustotu uzlů) doposud nedovolí provoz sítě tak, jako umožňuje režim LF.

 

LF z důvodu výrazně nižších nároků "alespoň nějak obstojně" po městě a blízkém okolí funguje. Přenos zpráv z mého zaměstnání domů, na vzdálenost 6,5km, bez přímé viditelnosti, s anténou Gizont uvnitř kancelářské budovy za oknem lze uskutečnit na 2-3 HOPy (dle denní doby a počtu aktivních uzlů a existujících alternativních cest). I když situaci nelze označit jako uspokojující, po roční mizérii je aktuální stav možné označit minimálně jako "slibný". Důvod, proč zde mapu ukazuji a rozepisuji se o aktuální situaci je ten, že po roce se teprve teď začíná ukazovat, že síť právě od takové hustoty uzlů má předpoklady pro její funkčnost jako mesh-síť. Podotýkám, že se jedná o LF provoz. MF zcela evidentně bude vyžadovat ve stejných podmínkách ještě hustotu uzlů výrazně vyšší. Srovnatelné funkčnosti dosáhne při stávajícím tempu růstu počtu uživatelů výrazně později.

FUNGOVÁNÍ SÍTĚ - Podmínka první 

Zásadní pro fungování sítě je, že máme dostatek uzlů v okolí, které se postarají o přeposlání zpráv dál. Podmínka, že téměř kdekoliv jste v dosahu jiného komunikativního uzlu, který dokáže poslat paket dál, je již splněna. K tomu dochází v Brně spolehlivě v rámci městských čtvrtí nebo kolem dobře umístěných uzlů (například na kopcích nebo střechách). V takových podmínkách, když odesíláte nebo čekáte na zprávu, jste v dosahu uzlu který paket převezme a předá dál.

Tuto skutečnost si snadno ověříte, jak jsem uvedl dříve, smazáním NodeDB a kontrolou obnovy uzlů po 15 minutách. Pokud po těchto 15 minutách uvidíte pouze jeden aktivní uzel s mizerným signálem, změňte místo nebo vyměňte anténu za lepší. Pokud ale máte uzel s dodávanou anténou a sedíte doma u počítače, nemůžete se divit, že máte špatné výsledky.

FUNGOVÁNÍ SÍTĚ - Podmínka druhá

Neméně důležitá pro fungování sítě: komunitní shoda na provozních pravidlech a parametrech sítě. V Brně se o to již pokusil uživatel uzlu STPN (viz dokument zde). Jelikož jde o komunitní aktivitu, každý může přispět svým návrhem, nebo alespoň respektovat doporučené nastavení. Pouhým respektováním pravidel se spolehlivost sítě zcela určitě zvýší. V rámci komunity je v Brně několik zkušených uživatelů, kteří to mohou posunout ještě dál. Samozřejmě, i méně zkušeným nelze zakázat experimenty s nastavením. Zkoušejte, experimentujte, ale ihned poté prosím nastavte vše tak, aby to bylo co nejvíce v souladu s doporučeným nastavením a pravidly. Pokud si s nastavením nevíte rady, nahlédněte zde. Vše co se tam píše je v tento okamžik pouze prvotní návrh jak by to mělo být, později se rozhodně může ukázat, že to lze dělat i lépe. Dnes tím ale nic nezkazíte a pomůže to :-)  

Další osobní postřehy o které bych se rád podělil:

• V provozu zjistíte, že některé velmi exponované uzly, byť aktivně odesílají packety, přesto neodpovídají a nepřeposílají dál běžný provoz (v Brně máme minimálně jeden zombie, který je vidět všude, packety nepřenáší - pouze parazituje na existující síti). Pokud o takovém "zombie" uzlu v okolí víte, dejte ho v aplikaci do ignore listu. Tímto krokem eliminujete část jeho požadavků na přenos a uvolněná kapacita tak zůstane k využití uzly s větším přínosem pro funkčnost sítě. Ignore list bych doporučoval spravovat místní komunitou. Prostor musí být k dispozici každému uživateli/uzlu respektujícímu pravidla v provozu ISM (tzn. i parazitujícím uzlům). S tím nic nenaděláme. Komunitně prosazovaný (a hlavně komunitou aplikovaný) ignore list tento problém způsobený (řekněme diplomaticky) méně ohleduplnějšími uživateli vše velmi elegantně a dostatečně účinně vyřeší .   
• Pokud máte doma dvě a vice zařízení, jedno hlavni zařízení mějte na CLIENT, vše ostatní na CLIENT-MUTE. Já dokonce mám sekundární zařízení při experimentech nastavené pouze na přímé "direct" spojení (HOP=0). Jenom to zařízení, co je na externí anténě, mám nastavené standardně (CLIENT/HOP3).
• Osvědčilo se mi mít v provozu (pouze) jedno stacionární zařízení s dobrou anténou (tipuji zisk 6-8 dBi**), které běží 24 hodin denně. Jednak to tím přispívá ke spolehlivosti a propustnosti sítě svým umístěním a dosahem, současně sbírá zprávy které si až večer pročítám.
• Navíc provozuji (OK, mám tedy trvale v provozu 2 zařízení), už však pouze doma, zařízení  s minimálním výstupním výkonem (do 5 dBm) a s PSRAM. To mi umožňuje provoz Store&Forward modulu (tzn. sbírá všechny zprávy) a veškerá další zařízení, která mám, si v okamžiku, kdy je zapnu, stáhnou zprávy určené pro ně a zobrazí je. Klidně i po týdnu a více!
  
  Podotýkám, že cizí zprávy tak nelze přečíst – jsou šifrované a stejně je SF jiným než adresovaným uzlům neposkytuje. Před časem jsem nabízel tento uzel k širšímu užívání, později jsem jeho dosah z důvodu nezájmu snížil jen na několik metrů doma. Nicméně pořád se domnívám, že uzly s aktivovaným Store&Forward modulem by mohly přispět ke snížení jalového provozu zařízení uživatelů, kteří nechtějí přijít po dobu nepřítomnosti na síti o zprávy (i takový uzel komunikuje a zatěžuje přenosový kanál). Pro pokrytí Brna tipuji, že by stačilo 5-6 dobře situovaných a dostupných uzlů s S&F.
  
  
  

Pro zájemce se zkušenostmi s PlatformIO SDK, kteří chtějí dál objevovat:

• I v současné situaci, jakou máme v Brně, je anténa základ! Můžu nasdílet kód na Wireless Stick, který ze dvou takových zařízení proti sobě udělá tester na antény – pošle ping z jednoho zařízení na druhé, to přečte RSSI/SNR a pošle zpět prvnímu. Tímto jsem zjistil reálnou použitelnost a směrové charakteristiky několika antén, které jsem zkoušel. Později jsem viděl i alternativní řešení na GitHubu – MeshShark link zde). Je to alternativa k běžnému řešení (jiné), které využívá Python CLI. Tato varianta ale nepotřebuje připojené PC/RPI a je praktičtější do terénu (nebo si upravte FW a zprovozněte podobnou funkci dle tohoto návodu)
  
  
  
  
  
• Hodně mi pomáhalo sledovat a hledat informace o provozu v logu. Vytvořil jsem si "udělátko", které mi dokonce online přes Wi-Fi přenášelo log rovnou do počítače ze stožáru (kabel by byl moc dlouhý). Současně vše i ukládalo přímo do souboru, který jsem si později mohl z udělátka kdykoliv stáhnout (link pro zájemce kdo potřebuje číst log i ze stožáru zde). V případě, že je vaše zařízení na stožáru (a jedná se o nRF52), promyslete i možnost aktualizovat firmware vzdáleně. Já osobně tu zkušenost nemám, vím ale, že současně budete potřebovat i možnost měnit takto firmware a bude to v tomto případe vaší výhodou.
  
  
  
  
  
• Ne přímo pro MF (v mém případě na LongSlow na dlouhé vzdálenosti), jsem dělal bridge mezi LS a LF. Tento kód jsem nedotáhl do produkční podoby, je ale funkční jako demonstrátor na GITHUBu. 
• Úprava firmware podle jednoduchého návodu - nový modul , který odpovídá na Ping a posílá zpět úroveň RSSI/SNR (snadno přenositelné pro zájemce o vyzkoušeni kompilací vlastního FW v PlatformIO). Alternativním a jednodušším řešením jsou existující skripty v pythonu, které však vyžadují trvale připojené PC.
  
  
  
  
  
• Úprava firmware: Range modul, který po privátním kanálu (kanál 0 s jiným než default klíčem) posílá na ostatní uzly přes Meshtastic  aktuální polohu. Ve zprávě ostatní uživatelé (příjemci, nebo uzel kterým kontrolujete dosah) periodicky dostávají rozkliknutelný link, který dovolí zobrazit pozici odesílajícího přímo na Google Mapy (nedotáhnuto k publikaci, ale snadno přenositelné pro zájemce se zkušenostmi s kompilací vlastního FW v PlatformIO - viz soubory "range test module" v repozitáři zde).
  
  
  
  
  
  
  

To nejdůležitější na závěr:

V rámci komunity jsou uzly, které svou pozicí, dostupností a spolehlivostí mohou významně přispívat ke spolehlivosti (upřednostňujme je), tak jako uzly, které ji jen "protěžují" (takové uzly převeďme do pasivního módu) a pak, bohužel, i uzly, které přímo škodí – ty ignorujme (ignore list). No a pokud ani to nepomůže, určitě existují vylepšení, na které bude nutné teprve objevit řešení. Respektujme k tomu ještě doporučené nastavení, po dokončení experimentů uveďte zařízení do stavu "pro síť nenarušujícího" a vše bude fajn :-)

dBi** – pseudo jednotka zisku antény, získána experimentálně z údajů prezentovaných přímo LoRa/Meshtastic zařízením. Cílem zavedení této konvence je zachycení  zlepšení/zhoršení vnímáno přímo samotným použitým zařízením.