Doomtenna: Von Meshtastic zu MeshCore

Bei Xebia gibt es eine Gruppe von Mitarbeitern, die sich begeistert mit Mikroelektronik und IoT-Geräten beschäftigen. Im Rahmen eines unserer langfristigen Projekte betreiben wir einen solarbetriebenen LoRa-Knoten auf dem Dach unseres Büros in Hilversum.

Dieser Knoten bildet die Grundlage für ein dezentrales Messaging-Mesh-Netzwerk. Ihr Smartphone kann in Verbindung mit einem zugehörigen LoRa-Gerät dieses System nutzen, um eine WhatsApp-ähnliche Funktion bereitzustellen, die auch dann noch funktioniert, wenn die gesamte normale Infrastruktur ausfällt. Aus diesem Grund bezeichnen wir diesen Knoten liebevoll als „The Doomsday Device“ oder „Doomtenna“.

Im Jahr 2022 haben wir eine Reihe von Blogbeiträgen veröffentlicht, in denen wir erläutert haben, wie und warum wir mit Meshtastic begonnen haben, die Installation des Knotens auf dem Dach unseres Büros beschrieben und den Wechsel von einem ESP32-basierten Gerät zu einem nRF52-basierten Gerät erklärt haben. Seitdem haben wir keine weiteren Neuigkeiten veröffentlicht, daher ist es an der Zeit für ein neues Update.

Umstellung auf MeshCore

Die wichtigste Änderung seit dem letzten Update war der Wechsel zu einem neuen LoRa-Mesh-Messaging-System. In den vergangenen Jahren haben wir Meshtastic genutzt, doch erst kürzlich, im Januar 2026, haben wir den Wechsel zu MeshCore vollzogen.

Wir konnten sofort deutlich größere Entfernungen erreichen. So konnten wir beispielsweise von unserem Büro in Hilversum aus eine Verbindung zu einem unserer Häuser in 60 km Entfernung herstellen, was uns mit Meshtastic nie gelungen war.

Eine fundierte Diskussion darüber, welches System besser ist, wäre ein eigenständiges Forschungsgebiet. Dennoch sind dies die Gründe, warum wir der Ansicht sind, dass dies bei MeshCore funktioniert hat, bei Meshtastic jedoch nicht:

Routing

Das Routing-Verhalten stellt für uns den interessantesten Unterschied dar.

Wenn ein Meshtastic-Knoten eine Nachricht empfängt, wartet er eine Weile, bevor er die Nachricht weiterleitet. Diese Wartezeit besteht aus einer festen und einer zufälligen Komponente. Beide werden anhand der Rolle des Knotens bestimmt.

Das Clevere daran ist, dass ein Knoten die Nachricht nur dann weiterleitet, wenn er noch keine andere Weiterleitung derselben Nachricht empfangen hat. Dies reduziert die Sendezeit, da nicht jeder Knoten jede Nachricht weiterleitet.

Das Problem besteht darin, dass dieses Verhalten in hohem Maße davon abhängt, dass die Knoten sinnvoll konfiguriert sind. Wenn ein Knoten mit schlechter Reichweite so konfiguriert ist, dass er Nachrichten sehr schnell wiederholt, kann er der erste Knoten sein, der eine Nachricht wiederholt. Bessere Knoten innerhalb seiner Reichweite nehmen diese Wiederholung dann wahr und entscheiden sich, die Nachricht nicht selbst zu wiederholen.

Ein schlecht platzierter Knoten mit einer überambitionierten Rolle kann also effektiv verhindern, dass besser platzierte Knoten Hilfe leisten können. Dies muss nicht böswillig geschehen. Es reicht bereits aus, wenn er so falsch konfiguriert ist, wie es häufig vorkommt, wenn man denkt: „Mein Knoten ist wichtig, also mache ich ihn zum Router“.

MeshCore funktioniert anders. Zunächst einmal wiederholen normale Begleitknoten Nachrichten überhaupt nicht. Das Wiederholen ist eine spezifische Aufgabe für Repeater und Raumserver, bei denen der Wiederholungsmodus aktiviert ist. Dadurch werden bereits einige unbeabsichtigte Fehler beim Routing vermieden.

Repeater in MeshCore werden nicht daran gehindert, eine Nachricht weiterzuleiten, nur weil sie eine andere Wiederholung dieser Nachricht empfangen haben. Bei per Flood-Routing weitergeleiteten Nachrichten wird jeder Repeater, der zur Weiterleitung der Nachricht berechtigt ist, diese auch weiterleiten. Dies macht das Routing zwar vorhersehbarer, beansprucht jedoch auch deutlich mehr Sendezeit.

Zur Verwaltung der Sendezeit verfügt MeshCore über Funktionen wie Regionen, die festlegen, welchen Flood-Verkehr die Repeater weiterleiten sollen. Noch wichtiger ist jedoch die Einführung eines Modus, in dem der Absender den zu verfolgenden Pfad festlegt. Bei Nachrichten an einen bestimmten Knoten leitet MeshCore nicht jede Nachricht unendlich lange weiter. Die erste Nachricht kann das Flood-Routing nutzen, um einen Pfad zu ermitteln. Wenn der Empfänger sie erhält, wird ein Zustellbericht mit den verwendeten Repeatern zurückgesendet. Zukünftige Nachrichten können diesen Pfad dann im Paket enthalten. Ein Repeater leitet die Nachricht nur dann weiter, wenn sie mit dem nächsten Hop in diesem Pfad übereinstimmt.

In MeshCore gibt es nach wie vor einen hohen Datenverkehr, insbesondere bei öffentlichen Kanälen und der Routenermittlung, sodass die Platzierung und Konfiguration weiterhin von Bedeutung sind. Der Ausfallmodus ist jedoch ein anderer und wirkt sich stärker auf die Verfügbarkeit (Sendezeit) aus als auf die Entfernung, die ein Paket zurücklegen kann.

Fortsetzung folgt

Die Doomtenna ist also nach wie vor in Betrieb, und das Netzwerk um sie herum ist seit der Umstellung auf MeshCore wesentlich interessanter geworden. Die größte Veränderung besteht nicht nur darin, dass wir nun einen Ping von 60 km erreichen, sondern auch darin, dass das Routing-Verhalten viel besser zu dem Netzwerk zu passen scheint, das wir tatsächlich aufbauen.

Der nächste Schritt besteht darin, das System weiterhin zu nutzen, die Messungen fortzusetzen und zu beobachten, ob sich MeshCore auch dann noch besser verhält, wenn das Netzwerk um uns herum stärker ausgelastet ist.