MESHTASTIC - MEDIUM-FAST, LONG-FAST, DX-Meshing a rozsáhlé sítě

První, co je nutné zdůraznit

Je mylné očekávat, že by bylo možné dnes Meshtastic síť využívat jako běžný komunikátor, který známe z našich telefonů. Ve skutečnosti se doposud v 99 % případů jedná o uživatelsky skrytý přenos telemetrie, sdílení polohy a informací o okolních uzlech. Pouze zanedbatelný zlomek (promile) paketů tvoří zprávy mezi uživateli. Z tohoto pohledu se síť jeví většinu času „tichá“. Nečekejte, že obdržíte desítky zpráv denně – některé dny se neobjeví ani jedna. Nicméně i tak uzly sítě mezi sebou intenzivně komunikují – v mnoha případech (z důvodu nevhodného nastavení) až neúměrně moc, bez zjevného užitku, na úkor spolehlivosti komunikace – tedy doručování zpráv.

Prosím, berte v úvahu fakt, že v následujícím textu nechci zpochybňovat možnost, že by si některé oblasti nemohly zvolit svobodně provoz MF či LF. To je neoddiskutovatelná svobodná volba uživatelů v daných lokalitách a nikdy bych si to nedovolil zpochybňovat. Jediné, o čem zde budu polemizovat, je skutečnost, že rozhodnutí, zda používat MF či LF, mohlo být učiněno na základě mylných předpokladů.

Takže - nejede, nefunguje ... přešlo se na MEDIUM-FAST

Za dobu, co Meshtastic sleduji a od hlavních zastánců MF se snažím zjistit, co měl takový přechod z LF řešit za problémy, narazil jsem pouze na dva problémy: Prvním byl rozpad sítě kvůli pohybujícím se uzlům, druhým pak samotná nízká spolehlivost sítě. Pak už nic, a pokud víte o dalších problémech, sem s tím prosím.

Nemohlo to byt takto?

Nemohlo se stát, že přechod na MF byl neuvážený krok z důvodu neznalosti problémů? Nebo to byl krok pouze z důvodu nenaplněných očekávání, vycházejících z představy, jak fungují podobné sítě na internetu? Mohlo se to všechno zamotat až tak, že se dnes dokonce ozývají hlasy pro přechod na SF?  

Jak je to dnes?

Věrohodné opodstatnění přechodu na MF pořád neexistuje. Spolehlivost sítě je pořád v pozadí - přesně jako identifikace skutečných výhod MF. Natož aby byl brán zřetel na to, jaké MF ve srovnání s LF má neoddiskutovatelné limity. Pokud se spolehlivost sítě za více než rok změnila, určitě by bylo užitečné znát úspěšnost doručování zpráv (aktualizace červ 2025 - v Brně na LF chodí už běžně 95% zpráv i víc). Pokud jste narazil na nějaké aktuální testy nebo aktualizace, rád se na ně podívám. Toto je výsledek ankety před jedním rokem, kdy se různě po ČR začal prosazovat provoz na MF. Dnes už by samozřejmě výsledek nebyl tak mizerný. Situaci jsem popsal ve zkušenostech po jednom roce. Tam, zdá se, je už zachycená i dnešní situace hustoty uzlů, při které začíná síť plošně fungovat. Jedná se však ale pouze o LF síť (Brno). MF síť svoji minimální hustotu musí teprve najít, logicky tedy čeká na výrazně vyšší počty uživatelů. 

Jak budeme řešit důsledky roztříštěnosti sítí?

Jestli patříte mezi ortodoxní zastánce MF, je pro vás naprosto zbytečné číst dál. To platí i pro Vás, komu stačí fakty nepodložený komunitní "šum" na online kanálech. Naopak pro ostatní, pokud vás zajímá širší kontext této problematiky, může být shrnutí přínosné k vytvoření si vlastního názoru.

Rozdíly mezi režimy MediumFast (MF) a LongFast (LF)

Nejdříve je potřeba porozumět rozdílům mezi profily MF a LF. Oba tyto profily byly vývojáři předem „odladěné“. Představují, oproti experimentovaní s LoRa parametry, pro uživatele významné usnadnění. Tím je myšleno, že byl pro každý profil (MF, LF, SF) vybrán optimální mix LoRa parametrů, který nastaví interní radio modul pro odesílání a příjímání zpráv. Klíčovými LoRa parametry jsou:

1. Šířka pásma (bandwidth): V obou režimech nastavena na 250 kHz.
2. Spreading factor (SF): Udává počet možných symbolů použitých pro přenos.
   • LF: Spreading factor 11 (vyšší dosah, ale nižší přenosová rychlost).
   • MF: Spreading factor 9 (vyšší přenosová rychlost, ale nižší dosah).
3. Coding rate: Poměr redundantních dat použitých pro opravu chyb při přenosu. V obou režimech je nastaven na 4/5. Redundance pomáhá ke spolehlivosti ale prodlužuje doby odesílání zprávy.

Parametry LoRa použité v režimu MF způsobují, že paket se odesílá výrazně kratší dobu (asi 3,5x rychleji), než je tomu v režimu LF (viz obrázek níže). Současně tím má MF v důsledku toho o 5 dB nižší Link Budget, což je zhruba 3x horší situace než při stejných podmínkách u LF (z pohledu síly a kvality signálu, nikoliv vzdálenosti jak bývá často mylně vyvozováno). Ve zjednodušeném pohledu to znamená, že při režimu MF máte kratší čas na přenos stejné informace a zároveň potřebujete lepší podmínky, aby byla zachována stejná míra spolehlivosti přenosu jako u LF. 

Je však fér uznat zastáncům režimu MF, že kratší pakety umožňují přenést více dat pásmem za stejný časový interval. Zprávy jsou tedy odesílány v kratším čase za cenu spolehlivosti přenosu klesající rychleji se vzdáleností. To znamená, že ve srovnání s režimem LF budete potřebovat více HOPů (uzlů mezi odesílatelem a příjemcem). Při podobné hustotě uzlů bude nutně mít méně alternativních cest (pokud vůbec) k příjemci. Pokud dnes prochází 75 % zpráv přímo (direct), při jednom HOPu to bude asi 60 % zpráv, a při dvou HOPech jen 40 %, poté 30%, 20%, 17%, 13%, 8% (ano, u HOP = 7 je spolehlivost doručení mizerných 8%). Zvyšený počet potřebných HOPů je přímý důsledek volby MF. Vždy platí: vyšší počet HOPů znamená vždy prudký pokles spolehlivost doručování zpráv. Ta samá matematika (75/60/40...) platí i pro LF, to však z principu umožňuje spojování (direct) na delší vzdálenosti a tím nevyžaduje takovou hustotu uzlů v okolí (tolik HOPů), jak je tomu u MF. LF totiž na stejnou vzdálenost nesousedících uzlů dokáže logicky uskutečnit spojení s méně HOPy.

PS: Chci uvést, že MF jsem osobně zkoušel ve Zlíně a samozřejmě vím, že to i tak může fungovat.

Důsledek pro uživatele:

Pokud použijete stejnou anténu a stejné zařízení, pouhou změnou konfigurace na režim MF si výrazně snížíte spolehlivost přenosu. Jak na spojeni "direct", tak i v síti samotné při propojování mezi uzly. To je způsobeno vyššími nároky na kvalitu a podmínky přenosu, a také výrazně vyššími požadavky na hustotu okolních uzlů ve vašem okolí. Tato změna tedy situaci z hlediska spolehlivosti doručování zpráv na vašem zařízení paradoxně zhoršuje. 

Bez diskuzí – zhoršuje!

MF, za předpokladu že vyžadujete funkčnost sítě a chcete posílat spolehlivě zprávy a nejenom vidět uzel 5km daleko (kterému však stejně když pošlete zprávu neobdržíte od něj odpověď), je určeno k provozování sítě na menších uzemích! LF, zdá se podle situace v Brně, začíná teprve plnit svoji funkci přibližně při hustotě začínající na hodnotě 1 uzel/10km2 a z toho odvozeného průměrného odstupu uzlů ~2km (i při nesplnění podmínky přímé viditelnosti mezi uzly). Jaké očekávání v tomto srovnání lze mít v případě MF? Zcela prokazatelně při několika jednorázových experimentech přechodu na MF uzly ve stejných podmínkách opakovaně nedokázaly síť sestavit. Dokonce ani některá direct spojení v mnoha případech nebylo možné na MF realizovat (takové uzly zůstaly izolované od ostatních). 

Pokud má být zařízení stabilní součástí mesh sítě, dlouhodobější osobní pozorování na LF ukázuje, že je nutné splnit následující podmínky:

• Minimálně 20 aktivních a komunikujících uzlů v blízkém okolí (ověřitelné například testem vymazání NodeDB).
• Nejméně 3 uzly s přímým spojením (RSSI > -110 dBm, SNR > -4 dB).

Tyto dvě podmínky se s vysokou pravděpodobností obecně vztahují jak na LF, tak na MF sítě. Při jejich splnění síť zdá se začíná „nějak“ fungovat. Typická vzdálenost mezi uzly LF byla 1,5 až 4 km, což v případě hustoty uzlů odpovídá hodnotě řekněme 1 uzel na 10 km² (dle mapových podkladů, bez přímé viditelnosti). 

Tvrzení opírám o zkušenosti z oblasti Brno-město, kdy až teprve s nárůstem uživatelů na konci 2025-02 bylo možné pozorovat, že síť teprve začíná nějak fungovat v režimu LF. Současně je i evidentní, že počet HOPů více jak 3 je technický limit sítě, mající pořád ještě alespoň nějak akceptovatelnou spolehlivost doručování zpráv.

Dostatečné hustoty uzlů (první a základní podmínka pro vznik funkční LF sítě), bylo dosaženo teprve po více jak jednom roce (2025-02). Více detailů o oblasti - odkazuji na "Situace v Brně". Pokud promítnete tuto realitu do MF, bude potřeba daleko vyšší hustoty uzlů. Bude třeba i zapracovat na spolehlivosti HOPů (tzn. odstranit/zvýšit faktor 75/60/40). A i tak MF síť vždy do doby, než bude umožněno inteligentnější routování, bude schopna fungovat spíš na meším než větším geografickém území. 

Aktualizace květen 2025 - MF síť v Brně pomalu dosahuje hustoty LF v období 2024-06. Doposud však, pokud je mi známo, podmínky pro vznik a propojování MF uzlů nebyly ani zdaleka splněny.

Aktualizace červenec 2025 - Počet uzlů sítě MF v Brně dnes již výrazně převyšuje počet aktivních uzlů na LF. Tento nárůst je do značné míry způsoben migrací uživatelů z LF na MF. Databáze uzlů (NodeDB)  eviduje přes 200 MF uzlů, přičemž některé z nich pochází i z vzdálenějších oblastí – mezi zaznamenanými jsou uzly z Olomouce, Přerova, pomezí Slovácka a Slovenska, Bratislavy, Vídně, Opavy i některé polské uzly. V samotném Brně už síť LF definitivně nesplňuje základní podmínky funkčnosti, tedy podmínkám vypozorovaných ve zlomu, kdy začala síť fungovat (minimálně 20 aktivních uzlů v blízkém okolí, hustotu alespoň jeden uzel na 10 km² a spojení alespoň se třemi dalšími uzly ve vzdálenosti 2–4 km). Funkčnost sítě LF se tak výrazně zhoršila a její použití je v mnoha částech města omezené, nebo zcela nemožné. Ironií však je, že i přes vyšší počet uzlů na MF je spolehlivost této sítě ještě horší, o její funkčnosti vůbec nemůže být řeč. Doufejme, že s návratem studentů do Brna v novém školním roce se situace zlepší a vzniknou podmínky alespoň pro jednu funkční a stabilní síť. Zapojení MQTT a online portálů (jediné místo , kde lze pozorovat "komunikaci") podkopává původní myšlenku – tedy nezávislost na centrální infrastruktuře, internetu a cloudu. Doufejme, že s postupem času neskončí mnoho uzlů navždy odložených v šuplíku, bez využití a zájmu.

Jak lze tedy rozumět tomu, že na některých uzemích "jede" MF perfekně na desítky kilometrů? Odpovědí je : rozlišujte, zda "jede" znamená pouze že se takto vzdálený uzel načte do NodeDB (viz. fenomén "DX-Meshing" níže), nebo zda se vzdáleným uzlem lze skutečně komunikovat (na zaslané zprávy přichází i odpověď). Zjištěná realita Vám odpověď dá sama. Načtený uzel v NodeDB  titiž ještě zdaleka neznamená, že s ním lze vůbec nějak komunikovat. Vyzkoušejte, kolikrát se Vám vrátí požadavek na traceroute, kolik odpovědí Vám přijde zpět. Pak lze teprve usoudit, zda síť skutečně "jede" a jaká je její spolehlivost. Síť, kde se vrátí méně jak 50 procent zpráv nemůže být síť pro komunikaci. Nicméně, pořád zbývá DX-Meshing, který je i za tak mizerných podmínek pořád "ve hře". 

Pohybující se uzly: Mylný argument o vlivu na síť

Často se při zdůvodňování přechodu na MF objevovalo tvrzení, že pohybující se uzly negativně ovlivňují stabilitu sítě Meshtastic. Na základě mých zkušeností a experimentů však tento argument nepovažuji za oprávněný. Běžně cestuji po JM autem a žádný rozdíl nepozoruji – spíše naopak. Odchozí zprávy by měly být dokonce spolehlivější, protože zařízení každou zprávu vysílá až třikrát. Tím, že ji odešle při pohybu v autě ze tří různých míst, se zvyšuje pravděpodobnost, že alespoň v jednom z těchto míst budou pro odeslání vhodné podmínky.

Proč pohybující se uzly nemohou „shodit“ síť:

• Meshtastic síť nerozlišuje mezi pakety přenášenými ze stacionárních a pohybujících se uzlů. Všechny jsou zpracovávány stejným způsobem.
• Pokud sdílíte svoji polohu, navíc třeba využíváte současně i Range modul a odesíláte periodicky pozici, zvýšíte sice vytížení přenosového kanálu (vyšší utilizaci), ale ani toto zvýšení není natolik významné, aby způsobilo „kolaps“ sítě.

Když jedete autem, mějte magnetku venku na kapotě nebo střeše. Za předním oknem, i s dobrým výhledem, bude signál výrazně utlumen. Pro příjem GPS to sice stačí, ale pro komunikaci v síti Meshtastic rozhodně ne! Umístění zařízení uvnitř na palubní desce oproti kapotě znamená přibližný útlum -4 dB, tedy signál je uvnitř až 2,5× slabší. Přitom za cca 200 Kč můžete koupit magnetku a umístit ji na střechu, čímž získáte klidně +10 dB, tedy 10× lepší signál. Podobné zlepšení lze dosáhnout i doma – stačí připevnit magnetku na venkovní parapet. 

Srovnání provozování MF vs. LF: Proč to není jednoduché

Bohužel, skutečně relevantní a definitivní srovnání výhod provozu v režimech MediumFast (MF) a LongFast (LF) nebude snadné. Pravděpodobně se i nadále budeme přít o to, co je lepší a co horší. Minimálně do doby, než budou obě sítě fungovat vedle sebe v jedné lokalitě. Pak teprve bude možné objektivní srovnání. Obávám se však, že za roztříštěnost sítí budeme platit už navždy.

Regionální rozdíly v provozu MF a LF: Možná cesta k soužití obou režimů

Za normálních podmínek je zřízení současného provozu MF a LF v jedné lokalitě a na stejne frekvenci  kontraproduktivní. Ve stejném  frekvenčním pásmu se totiž přenášejí jak MF, tak i LF pakety. To nutně způsobuje vzájemné kolize. Tyto kolize z principu ještě víc snižují celkovou spolehlivost obou sítí. Berte prosim na vedomi, kdo uz tak cini, ze kolizemi torpedujete uz nejak fungujici sit.  

POKUD TO JDE - VYVARUJME SE SOUČASNÉMU PROVOZU
MF A LF NA JEDNÉ FREKVENCI

Možné řešení pro koexistenci obou režimů - HYPOTETICKÉ

Jednou z možností by mohlo být přesunutí alternativní (druhé) sítě na vyšší frekvenci, aby se vzájemně nepřekrývaly. V obou případech (MF i LF) je šířka frekvenčního pásma 250 kHz, přičemž výchozí střed pásma je 869,525 MHz (nikoliv „papírových“ 868 MHz). Pokud by tedy v některých lokalitách existovaly komunity s preferencí jak LF, tak MF režimu, mohou tyto dvě sítě provozovány odděleně, hned vedle sebe. Alternativní síť (druha prosazující se v dane lokalitě) by mohla být posunuta minimálně na frekvenci 869,775 MHz (z důvodu šířky pásma +250kHz). 

Využití alternativní frekvence má ovšem svá omezení. Je třeba splnit přísnější podmínky. Je nezbytně nutně dodržet využívání (airtime) pouze na 0.1% (oproti standardních 10%) a snížit vysílací výkon na 25mW (14dBm - parametr TX=14). 

Pokud tedy hledáte alternativní (paralelní a nekolizní) cesty spojení, ať už třeba v podobě lokální mikrosítě, nebo v podobě by-pass (HOP=0) směrového spojení na přímou viditelnost na druhou stranu města či vydálený kopec (nižší vysílací výkon a ani omezenější airtime v takových případech nepředstavují žádné významnější limity), je pro vás toto snadno realizovatelné a  elegantní řešení. 

Příklad 1: Jste v oblasti, kde všichni používají MF a komunikují na primární síti, kterou si tam zvolili (MediumFast s frekvencí 869,525 MHz). Pokud tam chcete alternativně testovat LF, vyberte LongFast a změňte frekvenci na 869,775 MHz.

Příklad 2: Jste v Brně, nebo v oblasti kde většina uživatelů používá LF (LongFast s frekvencí 869,525 MHz). Pokud chcete alternativně testovat MF, vyberte MediumFast a změňte frekvenci na 869,775 MHz. 

Důležitá poznámka k anténě: Jedna a ta samá anténa, kterou již používáte, bude fungovat stejně pro MF i LF, a to i na frekvencích 869,525 MHz a 869,775 MHz. Tak úzce laděné a přesně naladěné antény tu nikdo nemá. Pokud někdo tvrdí opak... tak kecá. A pokud by tu přece jen někdo takový byl, určitě by nepotřeboval číst tento odstavec.

Fenomén DX-Meshing

Snahu o dosažení co nejvzdálenějších spojení v síti Meshtastic, podobně jako DXeři v radioamatérském světě, bychom mohli označit jako DX-Meshing. Zatímco původní myšlenkou Meshtastic bylo vytvořit spolehlivou lokální síť, která by fungovala i při výpadku běžné infrastruktury, realita ukazuje, že značná část uživatelů se soustředí na maximalizaci dosahu spíše než na optimalizaci hustoty a robustnosti sítě v blízkém okolí. NodeDB už je taková malá kartotéka pro QSL lístky. (aktualizace červ 2025 - podle situace při mesh-turistice po okolních kopcích lze nejčastěji pozorovat MF uzly, u kterých přímá viditelnost kopec-kopec a krátké packety na tak exponovaných místech představují výhodu)

Fenomén propojování rozsáhlých oblastí

Často se objevují snahy nebo očekávání, že Meshtastic sítě by mohly propojit větší oblasti, jako je například Hodonín, Zlín, Přerov a jiná města. Je však důležité zdůraznit, že toto jde přímo proti principu fungování sítě a tomu, co teď řešíme! Meshtastic síť je určená pro komunikaci v malých oblastech. LF pro oblast města, několika vesnic (<30km), MF pro oblast kampusu (<3km) a SF do kanceláře nebo když jdete na paintball (<300 m). Vysoký počet uzlů a s tím spojená režijní zátěž sítě nevyhnutelně povede k jejímu přetížení. Výsledkem by bylo, že síť nebude schopna plnit ani základní funkce, dokonce ani ty, které už plni nyní. (aktualizace červ 2025 - ani v Brně, kde lze zachytit až130 LF, nehrozí zatím ani zdaleka dle utilizace pásma kolaps sítě z důvodu přetížení režijním provozem)

Spojování na dlouhé vzdálenosti a překonávání rekordů je doménou jiných radioamatérských skupin. Zkoušejte, experimentujte, ale prosím, po testování zařízení buď vypněte, nebo jej nastavte do doporučené konfigurace, aby přispívalo ke spolehlivosti komunikace v blízkém okolí. NEZATĚŽUJME ZBYTEČNĚ ÉTER PŘENOSY ZE VZDÁLENÝCH UZLŮ, KTERÉ V MÍSTĚ NIKDO NEPOTŘEBUJE. To lokálním sítím pouze škodí!

Meshtastic je nyní ve své fázi rozvoje především jako lokální MESH síť, která požaduje spolehlivé propojení blízkých uzlů. Na možnost spolehlivé integrace vzdálených sítí si musíme počkat. Bude třeba buď nativně tuto možnost zapracovat do komunikačního protokolu, nebo vytvořit pro tyto účely specifickou část infrastruktury (viz níže). Velmi slibně například vypadá vylepšení "next-hop" nebo podobné mechanismy, které by v blízké budoucnosti mohly zlepšit routování a eliminovat část režijního provozu (typicky se to však týká hlavně zpráv posílaných přímo konkrétním uživatelům ze seznamu). Zbytečný balast v podobě nadbytečné telemetrie, nodeinfo apod. to ale neodstraní.

(aktualizace červ 2025 - Pro eliminaci nepotrebneho provozu a zvyseni spolehlivosti a vzdalenosti dorucovani zprav existuje experimentální modifikovaný firmware (ENG) (CZ google preklad). Firmware je urceny pro strategicky umistnene uzly, umoznuje  snadne odfiltrování zbytečných paketů a soucasne elegantne resi řízené přeposílání zpráv do jiných sítí – cilene „vystřelení“ paketů do okolních sítí a vzdalenych uzlu. Na modifikacich neustale pracuji a pripadne navrhy na vylepseni uvitam.

Alternativa pro experimentátory

Rád nasdílím kód a výsledky, které jsem v této oblasti dělal ale nedokončil. Pomocí Wireless Stick V3 je veškerý zachycený provoz (packety) jednosměrně odvysílán také na MF. To, co se přesně děje v éteru, je nejlepší sledovat pomocí SDR. Po příchodu packetu zařízení změní spreading factor na MF a odvysílá ho tam. Ihned poté se přepne zpět na LF a vyčkává na další paket. Předem upozorňuji, že je nutná znalost kompilace vlastního firmware a použití PlatformIO SDK nebo GitLab. I když je to funkční, jde zatím jen o demonstrátor – stále je potřeba dopracovat detaily, aby byl použitelný v reálném provozu (zejména konfigurace, která je nyní natvrdo zadrátovaná v kódu). Takže zatím žádná klikací konfigurace. :-) Ukázka pokusu o LF → MF bridge vypadá takto (viz níže). WS Stick deska má pigtail konektor na anténu, takže ten drátek, který zatím plní její funkci, lze samozřejmě nahradit pořádnou anténou.