Meshtastic boomt, kommt aber ins Stolpern.

Ich möchte nach knapp 8 Wochen intensiver Nutzung, meine Erfahrungen zu Meshtastic beschreiben. Ich bin nur ein Funkamateur und beschreibe meine Erlebnisse aus Sicht eines Funkers, nicht aus Sicht eines Entwicklers. Bei meinem Ausprobieren habe ich die Bluetooth-APP, die Webseiten von Meshtastic und Foren und Communitys intensiv genutzt. Dies ist auch keine Anleitung, wie Meshtastic richtig zu nutzen ist.

Mein Name ist Mario, DM1MJ, mit dem QTH in Langenlonsheim, das ist in Rheinland Pfalz zwischen Bingen am Rhein und Bad Kreuznach. Ich habe mit fast direkter Sicht zum Taunus eine Anbindung nach Hessen und durch den Donnersberg geht es für mich auch Richtung Darmstadt, Mannheim und Heidelberg. Eigentlich eine ideale Ausgangslage, wenn ich das Thema unter dem Aspekt der Notfallkommunikation auch betrachten möchte. Das stand aber bei meinen Tests gar nicht im Fokus.

Damit ich ein Verständnis für das Thema bekam, habe ich mir auch die Entstehungsgeschichte angeschaut um auch meine aktuellen Erfahrungen besser einordnen zu können. Angefangen hat das Thema LoRa 2009. LoRa ist die Grundlage, aus der sich dann Meshtastic entwickelt hat. Aber der Reihe nach:

Die technologische Basis: LoRa (Long Range)

LoRa ist kein Produkt eines einzelnen Bastlers, sondern eine patentierte Funktechnik mit industriellen Wurzeln.

Ursprung (2009–2010): Die Franzosen Nicolas Sornin und Olivier Seller entwickelten eine neue Funkmodulation, die extrem wenig Energie verbraucht, aber enorme Reichweiten erzielt.

Technik: Sie nutzten das sogenannte Chirp Spread Spectrum (CSS)– ein Prinzip, das in der Natur von Delfinen und Fledermäusen zur Ortung verwendet wird.

Kommerzialisierung (2012): Ihr Unternehmen Cycleo wurde 2012 von der US-Firma Semtech übernommen, die die Technik heute weltweit vermarktet.

Zweck: Ursprünglich war LoRa für das „Internet der Dinge“ (IoT) gedacht, etwa um Wasserzähler in Kellern oder Sensoren auf Feldern auszulesen, ohne dass man Batterien oft wechseln muss.

Das Open-Source-Projekt: Meshtastic

Meshtastic nahm diese industrielle Technik und verwandelte sie in ein Werkzeug für Endnutzer.

Gründung (Februar 2020): Der Entwickler Kevin Hester startete das Projekt als Open-Source-Lösung.

Die Idee: Hester suchte eine Kommunikationsmöglichkeit für Hobbys wie Wandern, Paragliding oder Camping in Gebieten ohne Mobilfunknetz. Er wollte keine teure Infrastruktur, sondern Geräte, die sich gegenseitig Nachrichten zuschieben.

Der Clou – Das Mesh-Prinzip: Während normales LoRa (oft als LoRaWAN) meist sternförmig an ein zentrales Gateway sendet, macht Meshtastic jedes Gerät zu einem Relais. Eine Nachricht „hüpft“ von Gerät zu Gerät, bis sie das Ziel erreicht, was die Reichweite massiv erhöht. Das Projekt ist heute zu 100 % gemeinschaftsbasiert und wird von Hunderten Freiwilligen auf GitHub weiterentwickelt.

Die erste Meshtastic-Welle, die mich erreichte, war im Frühjahr 2025.

Auf einmal war das Thema in aller Munde, entweder beim regionalen OV, in der CQ-DL, der Mitgliederzeitschrift des DARC oder einfach in vielen QSO´s wurde darüber gesprochen. Bei mir war es dann auch soweit und ich habe mich mit zwei LilyGo Boards mit einem ESP32-Chip ausgestattet. Die Firmware habe ich mir über den Mestastic-Webflasher installiert und über die Bluetooth-APP dann die ersten Einstellungen vorgenommen. Damit ich so einigermaßen wusste, was ich tue, habe ich mir einige Youtube-Videos angeschaut, u. a. von „Funkwelle“.

Mein Ziel war es, Nachrichten ohne das Internet nur von Antenne zu Antenne zu versenden. Zum Glück hatte ich mir zwei LilyGo-Boards organisiert, so konnte ich mir wenigstens selbst Nachrichten von „links nach rechts“ und umgekehrt schreiben. Bei mir in der Nähe gab es scheinbar keine anderen User, die ebenfalls mit Meshtastic ersten Erfahrungen machen wollten. Ich blieb auch nach 2 Wochen immer noch alleine. In der Zwischenzeit wurde das Wetter besser und ich habe mich anderen Aktivitäten, z. B. dem Portablefunk gewidmet. Die beiden Metatstic-Nodes verschwanden wieder in der Schublade und das Thema war für mich erstmal abgehakt.

Im November 2025 war ich in Oberstdorf im Allgäu um (Funk-) Freunde zu besuchen.

Im gemeinsamen Austausch lernte ich dann auch Joachim (DO5JH) persönlich bei einem kleinen Funkertreffen kennen. Joachim hat sich sehr intensiv mit Meshtastic beschäftigt und ist über das Thema überhaupt zum Amateurfunk gekommen. Er hat auf eigene Faust auf dem Grünten einen privaten Meshtastic-Router mit Solarbetrieb aufgestellt. Der Grünten ist ein markanter, 1.738 Meter hoher Berg im Oberallgäu und wird aufgrund seiner exponierten Lage direkt am Alpenrand auch als der „Wächter des Allgäus“ bezeichnet. Der Router führte dann zu einer Vielzahl von erfolgreichen Verbindungen zwischen den Nodes innerhalb des Tals.

Ca. 6 Monate war nun der Solar-Node erfolgreich auf dem Grünten im Einsatz. Genau in der Novemberwoche, als ich zu Besuch war, war dann aber der Akku des Nodes wegen mangelnder Sonne am Ende und das kleine Meshtatstic-Abenteuer endete durch den gezielten Abbau des Meshtastic-Routers.

Über die Erfahrungen, die Joachim mit seinem Projekt gemacht hat, werde ich später berichten, denn diese decken sich in weiten Teilen mit meinen eigenen Ergebnissen. Dazu später mehr.

Als ich wieder zu Hause war, habe ich die Schublade geöffnet, die beiden LilyGo-Module wieder mit einer aktuellen Firmware bespielt und beide noch mit jeweils einer externe Antennen ausgestattet.

Zum Glück hat die „alte“ Hardware noch gut funktioniert. Und nach ca. 3 Tagen Laufzeit war ich begeistert, was auf einmal in meiner APP angezeigt wurde. 492 Nodes verteilten sich zwischen Hessen und Rheinland-Pfalz. Wahnsinn, wie groß das Gebiet war, teilweise bis zum Bodensee konnte ich Nodes sehen. Auch Nachrichten konnte ich nun lesen und schreiben. Wow, was hat sich denn da in den letzten 8 Monaten alles entwickelt? Das machte mich neugierig und ich fing an, ebenfalls Nachrichten an meine „Nachbarn“ mit einem oder zwei Hops Entfernung zu schreiben. Und ich bekam sogar Antworten. Ok, nicht immer waren die Nachrichten und Antworten im Zusammenhang aber es fand ein erster Austausch statt.

Jetzt fingen leider auch die ersten Probleme an:

Es fehlte eine Art Bestätigung, ob Direktnachrichten an Empfänger A, B oder C angekommen sind. Einige Male funktioniert es reibungslos und dann auch wieder nicht. Das Warum blieb für mich ein Rätsel. Auch die sogenannte AirUtilTX-Time war extrem hoch, obwohl ich teilweise stundenlang keine Nachricht versendet habe.

Natürlich ging ich auf Recherche und las in Foren und in Messangergruppen. Die Probleme waren dort die gleichen, doch eine eindeutige Lösung gab es nicht. Vielmehr kristallisierte sich heraus, dass die Grundeinstellungen, wie sie Meshtatsic vorsieht, aufgrund der hohen Nodesdichte nicht mehr passend sind. In der Community, insbesondere bei Mesh Hessen (https://meshhessen.de) ist die Empfehlung, die Voreinstellungen von Long Fast auf Short Slow zu ändern.

In der Welt von Meshtastic bestimmen die Presets (Voreinstellungen), wie die LoRa-Funkwellen moduliert werden. Dies ist immer ein Abwägen zwischen Reichweite, Geschwindigkeit und Netzkapazität.

Erklärung und ein direkter Vergleich der beiden Presets:

Was sind die Vorteile von „Short Slow“?

Obwohl „Short“ nach weniger Leistung klingt, ist dieses Preset in bestimmten Szenarien die deutlich bessere Wahl: 

1. Massive Reduzierung von Stau (Congestion): In dichten Netzen (z. B. in Städten oder bei Events) ist der Funkkanal oft durch die lange Sendezeit von Long Fast-Paketen blockiert. Short Slow sendet Daten viel schneller, wodurch die Airtime sinkt und mehr Nutzer gleichzeitig kommunizieren können, ohne dass sich Pakete gegenseitig stören.
2. Bessere Skalierbarkeit: Während Long Fast oft bei etwa 60 aktiven Knoten an seine Grenzen stößt, erlauben „Short“-Presets den Betrieb von Hunderten Geräten im selben Mesh.
3. Geringere Latenz: Nachrichten „hüpfen“ viel schneller durch das Netzwerk. Das System fühlt sich reaktionsschneller an, da Bestätigungen (ACKs) fast augenblicklich zurückkommen.
4. Zuverlässigkeit im Nahbereich: Durch eine robustere Fehlerkorrektur (Coding Rate) innerhalb der „Slow“-Variante kommen Nachrichten in bebauten Gebieten oft stabiler an, solange die absolute Reichweite nicht das Problem ist.

Fazit: Wechsle auf Short Slow (oder Medium Fast), wenn du in einer Stadt mit vielen aktiven Nodes wohnst und merkst, dass Nachrichten oft nicht durchkommen.

ACHTUNG: Nur die Nodes mit dem gleichen Preset können sich auch gegenseitig sehen und untereinander kommunizieren!

Hier noch schnell die Erklärung zu den wichtigen Werten AirUtilTX (deine eigene Sendezeit) und ChUtil (die gesamte Kanalauslastung), um die Belastung des Funkkanals zu verstehen:

AirUtilTXsteht für Air Utilization Transmit. Dieser Wert gibt in Prozent an, wie lange dein eigenes Gerät in einem bestimmten Zeitraum (meist eine rollierende Minute) aktiv auf Sendung war.

• Bedeutung: Wenn der Wert hoch ist, sendest du entweder sehr große Datenmengen oder nutzt ein langsames Preset (wie Long Slow), das die „Luft“ lange belegt.
• Wichtigkeit: In Regionen wie Europa gibt es gesetzliche Grenzwerte (Duty Cycle), wie lange ein Gerät pro Stunde senden darf (oft 1% oder 10%). Meshtastic drosselt dich automatisch, wenn du dieses Limit überschreitest.

2. ChUtil (Gesamte Kanalauslastung)

ChUtil (Channel Utilization) misst, wie beschäftigt der Funkkanal insgesamt ist. Hier zählt alles rein: deine Pakete, Nachrichten von anderen Meshtastic-Nodes in Reichweite und sogar fremde LoRa-Signale (z. B. von Sensoren oder anderen Netzwerken).

• Der „Lärmpegel“: Ab ca. 25–40 % ChUtil wird das Netzwerk instabil, da die Wahrscheinlichkeit für Kollisionen massiv steigt.
• Short Slow Effekt: Hier glänzt das Preset Short Slow(oder noch schnellere Presets). Da die Pakete viel kürzer in der Luft sind, sinkt sowohl dein AirUtilTX als auch das gesamte ChUtil im Mesh drastisch, wodurch mehr Platz für andere Nutzer entsteht.

Zusammengefasst: Wenn du auf das Display deines Geräts schaust, zeigt dir AirUtilTX, ob du gerade die „Plaudertasche“ im Netz bist, während ChUtil dir sagt, wie voll die Party insgesamt schon ist.

Die Umstellung ist in der APP schnell erledigt. Natürlich waren jetzt erstmal nur ein Bruchteil der Nodes in der APP zu sehen. Auch die beiden oben genannten Werte sind deutlich gesunken und waren nun im grünen Bereich. Da wir uns in der Ein-und Zwei-Hop-Nachbarschaft auf Short Slow geeinigt hatten, stand jetzt einem erfolgreichem Nachrichtenaustausch nichts mehr im Weg. War das schon alles um eine erfolgreiche Nachrichtenübermittlung sicher zu stellen?

Doch so einfach ist es dann doch nicht. Die Probleme waren weniger, doch eine erfolgreiche Nachrichtenübermittlungsquote stellte sich nicht ein. Dazu kamen jetzt noch weitere Themen, die es zu lösen galt.

Weniger Nodes bedeutet auch, dass die Funkstrecke zwischen zwei Antennen durch Hügel oder Hindernisse unterbrochen wird. Um das zu beheben, bin ich nun viel spazieren gegangen und habe mir ideale hoch gelegene Plätze heraus gesucht, die folgende Kriterien erfüllen mussten.

• Gute Erreichbarkeit auch mit dem Auto
• Sichtverbindung zu meinem Heimatnode in Langenlonsheim und auch Sichtverbindung zu anderen Stationen in meiner Nähe
• Nicht zu öffentlich, damit nicht jeder Hund, jedes Wildtier oder Spaziergänger darüber stolpern
• Wetterschutz, aber auch kein privates/fremdes Eigentum nutzen

Ich hatte Glück und habe bei mir in Laufnähe einen passenden Platz gefunden. Den Node habe ich mit einer Powerbank mit Strom versorgt und für den Wetterschutz habe ich eine passende Tubberbox etwas angepasst. Auf die Tubberbox habe ich noch eine Metallplatte für die Magnetfußantenne mit Gewebeband befestigt und ich konnte meinen ersten Node strategisch passend platzieren.

Doch welche Rolle weise ich dem Node in seiner strategischen Höhe zu? Ganz klar, das wird ein Repeater (Router), sprich Senden und Weiterleiten von Signalen wird seine Hauptaufgabe. Sobald ich diese Einstellung über die Bluetooth-APP finalisiert hatte, schaltet sich der Node in einen Stromsparmodus und lässt sich nicht mehr über die APP ansprechen. Auch sonst ist keine andere Verbindung mehr möglich. Schade eigentlich. Hier ist eine Erklärung mit Lösung, das habe ich natürlich erst später heraus gefunden.

Sobald du ein Gerät als Router konfigurierst, passieren im Hintergrund drei Dinge:

1. Deaktivierung der Schnittstellen: Um Strom zu sparen, schaltet der Node Bluetooth und oft auch WLAN dauerhaft ab. Da die App meistens via Bluetooth kommuniziert, verlierst du die Verbindung.
2. Kein lokaler „User“: Ein Router gilt im Mesh nicht mehr als Endgerät. Er sendet keine eigenen Positionsdaten (Position Beacons) mehr für sich selbst, sondern reicht nur noch Pakete anderer Teilnehmer mit höchster Priorität weiter.
3. Standort-Fokus: Die Router-Rolle ist für Geräte gedacht, die an schwer zugänglichen Orten (wie Masten oder Erhöhungen) fest installiert sind und dort autark laufen sollen.

Die Lösung für das Routerproblem mit der fehlenden APP-Verbindung:

Wenn du dein Gerät weiterhin mit der App steuern und Nachrichten lesen willst, aber dennoch möchtest, dass es effizient Pakete weiterleitet, solltest du die Rolle „Router_Client“ wählen.

• Router_Client: Fungiert wie ein normaler Node (Bluetooth bleibt an, App-Verbindung möglich), wird aber vom Mesh-Algorithmus bei der Paketweiterleitung bevorzugt behandelt, wenn er dauerhaft am Strom hängt.
• Wichtiger Hinweis: Wenn du den Node bereits auf „Router“ gestellt hast und nicht mehr reinkommst, musst du ihn meistens per USB-Kabel an den PC/Laptop anschließen und über den Web-Client zurückstellen.

Also, den Node wieder komplett neu flashen und nun in seiner neuen Rolle als Router-Client an den neuen Standort platzieren.

Meiner Ein- bzw. Zwei-Hops-Nachbarschaft habe ich stolz von dem neuen Router-Client-Node erzählt, denn nun hatten wir ja eine bessere und direktere Funkverbindung. Doch Meshtastic sieht das Stand heute etwas differenzierter, was strategisch gute Standorte in Verbindung mit der Anzahl der (Router-) Nodes für das Mesh sind. Auf den ersten Blick hatte ich zwar Erfolg, doch für andere Node, die als Router in der weiteren Umgebung standen, war mein Router nun ein weiterer Knoten, der dazu führte, dass sich bei einigen Nodes die Wegstrecke innerhalb des Netzes verlängerte und die Anzahl der Hops erhöht. Im schlimmsten Fall heißt das, dass Nachrichten nicht zu ihrem Ziel finden und einfach verschwinden.

Hier ist die Erklärung im Detail:
Wenn du einen weiteren Routerin ein Gebiet stellst, das bereits gut versorgt ist, schlägt das Prinzip „Viel hilft viel“ oft ins Gegenteil um.

Hier sind die negativen Folgen eines „überbevölkerten“ Mesh-Netzwerks:

1. Broadcast-Storms & Paket-Stau: Jedes Mal, wenn eine Nachricht gesendet wird, versuchen alle Router gleichzeitig, sie weiterzuleiten. Das führt zu massiven Kollisionen auf dem Funkkanal. Die Folge: Die ChUtil (Kanalauslastung) schießt hoch und Nachrichten kommen gar nicht mehr an.
2. Unnötige Hops: Meshtastic begrenzt die Anzahl der „Sprünge“ (Hops), die ein Paket machen darf (Standard ist meist 3). Wenn zu viele Router auf engem Raum stehen, verbraucht eine Nachricht ihre Hops schon auf den ersten paar hundert Metern, anstatt die Distanz in die Ferne zu überbrücken.
3. Verwirrung des Routing-Algorithmus: Das Netz wird „instabil“. Da viele Router die Nachricht fast zeitgleich empfangen, müssen sie per Zufallsprinzip entscheiden, wer zuerst sendet (Delay-Mechanismus). Zu viele Knoten in Hörweite machen diese Verzögerungen ineffizient.
4. Verstopfung der Airtime: Da Router Pakete mit hoher Priorität behandeln, „blockieren“ sie die Airtime für normale Nutzer (Clients). Wenn drei Router dasselbe Paket wiederholen, ist der Kanal dreimal so lange belegt wie nötig.

Was man stattdessen tun sollte:

• Abstand halten: Ein Router macht nur Sinn, wenn er eine Versorgungslücke schließt oder einen exponierten Punkt (wie ein hohes Gebäude oder Berg) besetzt.
• Rolle „Client“ nutzen: Wenn du am selben Ort wie ein Router bist, lass dein Gerät einfach auf der Rolle Client. Es leitet im Notfall trotzdem Pakete weiter, aber viel „sanfter“ und ohne das Netz zu dominieren.
• Hop-Limit prüfen: In dichten Gebieten sollte man das Hop-Limit eher niedrig halten, um die Anzahl der Wiederholungen zu begrenzen.

Also habe ich meinen Nodes wieder auf Client All eingestellt. Zu Hause hatte ich einen weiteren Client stehen, dort konnte ich immer sehen, wann sich mein „Tubberdosen-Node“ am Waldrand meldet. Nach drei Tagen kam keine Aktualisierungsmeldung mehr. Da ich nicht einschätzen konnte, wie lange die Powerbank mit 15.000 mAh die Stromversorgung sicher stellt, bin ich wieder zu dem Standort gegangen um nach dem rechten zu schauen. Entweder war meine Tupperbox geklaut worden, oder die Powerbank war einfach leer. Zum Glück ging dem Node einfach nur der Saft aus. Ganz schön Stromhungrig der Liliygo T3 V2.

Durch den Austausch mit der Community habe ich nun ein Analyseprogramm mit dem Namen Meshsense mir installiert.

Kurzbeschreibung von Meshsense:
MeshSense ist ein spezialisiertes Open-Source-Desktop-Tool (für Windows, Mac und Linux), das von Affirmatechentwickelt wurde, um den Zustand und die Struktur deines Meshtastic-Netzwerks visuell und technisch tiefgreifend zu analysieren.

Im Gegensatz zur Smartphone-App, die primär auf Nachrichten fokussiert ist, dient MeshSense der Überwachung und Diagnose.

Was macht MeshSense?

• Netzwerk-Mapping: Es zeichnet eine Karte aller empfangenen Knoten (Nodes) und stellt Verbindungen grafisch dar.
• Echtzeit-Telemetrie: Das Tool zeigt detaillierte Sensordaten wie Batteriespannung, Temperatur, Luftfeuchtigkeit und Luftqualität der einzelnen Nodes an.
• Trace-Route-Visualisierung: Du kannst den Weg eines Pakets durch das Mesh verfolgen („Hops“), um zu sehen, welche Router die Nachricht weiterleiten.
• Signal-Analyse: Für direkt empfangene Nodes werden SNR(Signal-Rausch-Abstand) und RSSI (Signalstärke) angezeigt.
• Globale Karte: Es gibt eine integrierte globale Karte, die aktive Nutzer weltweit anzeigt, ohne dass ein MQTT-Gateway (Verbindung zum Internet) eingerichtet werden muss.

Welche Aussagen lassen sich daraus ziehen?

Durch die Nutzung von MeshSense kannst du präzise Rückschlüsse auf die Gesundheit deines Netzes ziehen:

1. Reichweite & Abdeckung: Durch die Darstellung von SNR und RSSI erkennst du sofort, ob eine Verbindung stabil ist oder kurz vor dem Abbruch steht.
2. Topologie-Fehler: Wenn Nachrichten über unnötig viele Hops gehen, deutet das auf falsch platzierte oder überflüssige Router hin (das „Router-Problem“, das wir zuvor besprochen haben).
3. Wartungsbedarf: Du siehst auf einen Blick, welche Nodes eine kritisch niedrige Batteriespannung haben oder seit längerer Zeit inaktiv sind.
4. Kanalbelastung: Durch die grafische Aufbereitung der Datenpakete lässt sich beurteilen, wie hoch die Last im lokalen Mesh ist und ob ein Wechsel des Presets (z. B. auf Short Slow) sinnvoll wäre.
5. Sensorkontrolle: Du kannst Umweltbedingungen an entfernten Standorten in Echtzeit überwachen.

Achtung, Meshsense kann bei intensiver Nutzung auch Probleme verursachen. Deswegen ist es wichtig, wie es eingesetzt wird.

1. Passives Monitoring (Keine Mehrbelastung)

Wenn MeshSense nur mitliest, was ohnehin über den Funk reinkommt (z. B. Positionsdaten oder Statusnachrichten, die die Nodes sowieso alle 15–30 Minuten senden), erzeugt das Tool null zusätzliche Last. Dein Node empfängt die Daten einfach und MeshSense bereitet sie am PC hübsch auf.

2. Aktive Analyse (Zusätzliche Belastung)

Es gibt Funktionen in MeshSense (und auch in der normalen App), die das Netz aktiv belasten:

• Node-Info-Abfragen: Wenn du manuell die Infos eines entfernten Nodes abfragst, schickst du ein Paket hin und erwartest eine Antwort – das verbraucht Airtime.
• Traceroute: Hierbei wird ein Paket durch das Netz geschickt, um den Pfad zu tracken. Das ist super für die Analyse, belegt aber kurzzeitig den Kanal über mehrere Hops hinweg.
• Häufige Telemetrie-Intervalle: Wenn du deine eigenen Nodes so einstellst, dass sie alle 60 Sekunden ihre Batteriespannung senden, nur damit die Grafik in MeshSense schön aussieht, dann „müllst“ du das Netz tatsächlich zu.

Die Folge: „Teufelskreis“ der Analyse

In einem bereits überlasteten Netz (hoher ChUtil) führt jede zusätzliche Analyse-Anfrage dazu, dass:

1. Noch mehr Kollisionen auftreten.
2. Die Analyse-Antworten verloren gehen.
3. Man denkt, das Netz sei noch schlechter, als es eigentlich ist.

Profi-Tipp für ein sauberes Mesh:

Nutze MeshSense vor allem passiv. Schau dir an, was „natürlich“ im Netz passiert. Wenn du Nodes konfigurierst, setze die Telemetrie-Intervalle (Battery/Position) so hoch wie möglich (z.B. alle 30-60 Minuten), damit die Grundlast niedrig bleibt.

Ein gut eingestelltes Netz zeichnet sich dadurch aus, dass MeshSense fast „langweilig“ aussieht, weil nur selten Pakete fliegen.

In meiner Testphase und Recherche las ich sehr häufig von Paket-Kollisionen. Was ist das genau?

1. Das physikalische Problem (Überlagerung)

LoRa-Signale sind Radiowellen. Wenn zwei Nodes gleichzeitig senden, treffen zwei Wellenfronten zur selben Zeit auf die Antenne eines Empfängers.

• Die Wellen vermischen sich zu einem unleserlichen Rauschen.
• Der Empfänger (z.B. ein Router) hört zwar, dass „etwas“ gesendet wurde, kann aber die digitalen Informationen (die Nullen und Einsen) nicht mehr aus dem Signal-Brei herausfiltern. Das Paket ist verloren.

2. Der „Hidden Terminal“ Effekt (Das versteckte Gerät)

Das ist die häufigste Ursache für Kollisionen im Mesh:

• Node A sendet eine Nachricht zu Node B.
• Node C ist weit weg von A und hört ihn nicht. Da C denkt, der Kanal sei frei, fängt er ebenfalls an zu senden.
• Node B sitzt genau in der Mitte und hört nun beide gleichzeitig. Für B „krachen“ die Signale zusammen, und er versteht gar nichts mehr.

3. Warum „Long Fast“ das Problem verschlimmert

Hier kommt die Airtime ins Spiel:

• Ein Paket im Modus Long Fast braucht vielleicht2 Sekunden, um durch die Luft zu reisen. In diesen 2 Sekunden muss der Kanal absolut still sein.
• Ein Paket im Modus Short Slow(oder Medium) ist vielleicht schon nach 0,5 Sekunden fertig.
• Die Logik:Je länger ein Paket „in der Luft“ steht, desto höher ist die statistische Wahrscheinlichkeit, dass ein anderer Node in genau diesem Zeitfenster ebenfalls anfängt zu senden.

4. Der Teufelskreis: Die automatische Wiederholung

Meshtastic versucht, verlorene Pakete zu retten. Wenn ein Node keine Bestätigung (ACK) erhält, dass seine Nachricht angekommen ist, sendet er sie nach einer kurzen Pause erneut.

• In einem überlasteten Netz kollidieren die ersten Pakete.
• Daraufhin senden alle Nodes ihre Pakete noch einmal (Retransmission).
• Das führt zu noch mehr Funkverkehr auf dem Kanal, was zu noch mehr Kollisionen führt. Man nennt das einen„Stall“oder Netz-Infarkt.

Wie verhindert Meshtastic das normalerweise?

Meshtastic nutzt ein Verfahren namens CSMA (Carrier Sense Multiple Access). Bevor ein Node sendet, „lauscht“ er kurz in den Kanal. Wenn er ein Signal hört, wartet er eine zufällige Zeitspanne ab (Backoff), bevor er es erneut versucht. Das klappt super bei 5 Nodes, wird aber bei 50 Nodes in einer Stadt extrem schwierig. Kollisionen sind wie ein Stau auf einer einspurigen Straße. Je breiter die Autos (längere Airtime) und je mehr Verkehr, desto eher kracht es.

Weihnachten steht vor der Tür und ich merke anhand der Zunahme von Nodes, dass viele Menschen Urlaub haben und sich mit Meshtastic mit dem Preset Short Slow beschäftigen.

So langsam steigt auch bei mir die Dichte an. Doch nun kommen die oben beschriebenen Probleme immer mehr zum Tragen. Nachrichten, egal ob öffentlich oder als Direktnachricht machen was sie wollen. Scheinbar stolpert das Netzt über sich selbst. So langsam verliere ich die Lust, ständig bei meinen direkt Meshnachbarn per Whats App oder Telegramm zu fragen, „Hast du meine Nachricht bekommen?“

Ja Meshtastic führt auch dazu, dass sich meine Kontakte in meinem Smartphone innerhalb kurzer Zeit deutlich erhöhen. Auch hier kann ich sagen, Funk verbindet. Aber die Lust, das System mit der aktuellen FW 2.7.15 weiter zu nutzen ist erstmal vergangen. Vielleicht kommt ja mit dem nächsten großen Update eine Version auf den Markt, wo diese ganzen Probleme besser gelöst werden. Was die Hardware betrifft, habe ich natürlich aufgerüstet und meine ESP32-Chips sind jetzt entweder Heltec V3 oder V4 Module.

Zwischen den Jahren sind meine Frau und ich wieder nach Oberstdorf ins Allgäu gefahren und wir treffen wieder unsere Funkfreunde. Auch mit Joachim stehe ich wieder im Austausch. Er bestätigt mir all meine oben beschriebenen Erfahrungen. Und nachdem er mir lang genug zugehört hat, fragt er mich: „Hast du ein paar ESP32-Nodes dabei? Ich antworte mit einem „Ja, warum?“

In dem Moment sagt er nur, „Meshcore“.

An dieser Stelle möchte ich meine Geschichte vorerst zu Meshtatstic beenden. Für mich hat sich in der Sylvesterwoche eine neue Meshcore-Welt aufgetan und ich teste gerade diese Technik. Sobald ich mehr weiß, werde ich wieder darüber berichten. Der erste Eindruck ist deutlich ausgereifter und zuverlässiger. Auch sind die Einstellungen und Rollen klarer, so dass das Netz aktuell stabil läuft.

Wer Lust und Laune hat, in das Thema einzusteigen, der kann sich gern an mich wenden. Entweder per Funk über den DB0FT, DMR TG 26269, oder einfach per E-Mail an mario.jeschke@gmail.com