Ich war letztes Jahr ebenfalls mit Meshtastic auf der Fusion unterwegs – eine wirklich großartige Erfahrung, nicht zuletzt wegen der vielen neuen Kontakte mit Menschen, die ähnlich technikaffin sind. Besonders in Erinnerung geblieben ist mir auch der Vortrag von Davide Gomba.
Hardware-seitig hatte ich ein ESP32-basiertes Board dabei. Das funktionierte grundsätzlich gut, erwies sich jedoch als recht stromhungrig. Rückblickend würde ich klar zu nRF52-basierten Boards raten, da diese sich in der Praxis als deutlich energieeffizienter und insgesamt besser geeignet erwiesen haben.
Auf der Fusion waren schätzungsweise rund 160 Nodes aktiv. Zusätzlich wurde ein Node mit aktivierter Router-Funktion in einem Hangar installiert, um den Höhenvorteil für eine bessere Funkabdeckung zu nutzen. Zu diesem Zeitpunkt erschien das sinnvoll, da Meshtastic sehr flexibel konfigurierbar ist und Handhelds – je nach Einstellung – als Client oder Router fungieren können. Insgesamt entstand dadurch ein sehr dynamisches Netz, dessen Kommunikation jedoch bereits spürbar an Stabilität verlor.
Ein wesentlicher Faktor dafür ist die hohe Individualisierbarkeit von Meshtastic. Standortdaten, Sensoren, Node-Info-Intervalle und zahlreiche weitere Parameter lassen sich pro Gerät individuell konfigurieren. In Netzen mit steigender Node-Zahl können einzelne Fehlkonfigurationen oder besonders „auffällige“ Geräte das gesamte Mesh deutlich beeinflussen. Bereits bei der genannten Anzahl an Nodes war die Channel Utility stark ausgelastet.
Diese Beobachtungen bestätigten sich später im Dauerbetrieb. In Bremen hat sich mit dem BreMesh eine lokale, lose organisierte Mesh-Community etabliert, die zunächst ebenfalls auf Meshtastic gesetzt hat. Im laufenden Betrieb zeigte sich jedoch, dass die Router-Funktion von Meshtastic für den praktischen Einsatz nur eingeschränkt geeignet ist und sich in bestimmten Situationen nicht zuverlässig oder vorhersehbar verhält. Dies führte zu einer insgesamt erhöhten Unzuverlässigkeit des Netzes.
Darüber hinaus wurde deutlich, dass einzelne belastende Knoten das gesamte Mesh erheblich beeinträchtigen konnten. Besonders problematisch waren stationäre Nodes, die weiterhin in kurzen Intervallen Positionsdaten oder umfangreiche Telemetrie sendeten. Diese belegten unverhältnismäßig viel Airtime und wirkten sich spürbar negativ auf die Netzqualität aus. Mit zunehmender Node-Zahl verstärkten sich diese Effekte weiter, während gezielte Gegenmaßnahmen im laufenden Betrieb kaum möglich waren.
Auf Grundlage dieser Erfahrungen ist das BreMesh schließlich auf MeshCore migriert.
Ein zentraler Unterschied zwischen MeshCore und Meshtastic besteht darin, dass Clients bei MeshCore keine Pakete weiterleiten. Dadurch bleibt das Netz deutlich kontrollierbarer, und das Hop-Limit kann auf bis zu 64 gesetzt werden, ohne Broadcast-Stürme oder ähnliche Effekte zu erzeugen. Große Netze lassen sich auf diese Weise wesentlich besser skalieren. Für die Fusion halte ich es daher für sinnvoll, über eine MeshCore-basierte Infrastruktur nachzudenken – zumal sich die Hardware größtenteils identisch zu Meshtastic weiterverwenden lässt.
Meshtastic eignet sich hervorragend für mobile, autarke Meshes mit überschaubarer Node-Zahl, etwa beim Wandern, auf Touren oder in Outdoor- und Survival-Szenarien. Auch für kleinere, lose gekoppelte Setups funktioniert es sehr gut. Für hochdichte, langfristig betriebene Netzwerke – beispielsweise stationäre Meshes in Großstädten – sowie für temporäre Großevents mit hunderten Nodes skaliert jedoch eine stärker kontrollierte Architektur wie MeshCore deutlich besser.
Falls Interesse besteht, tausche ich mich dazu gern weiter aus.
Ich hoffe, ich habe bei der zweiten Auslosung im Februar noch einmal Glück – dann sieht man sich im Mesh
