LoRa-basiertes Mesh-Netzwerk hat in den letzten Jahren bemerkenswerte Verbreitung gefunden. Egal, ob Sie ein Notfallkommunikationssystem aufbauen, IoT-Sensoren auf einer abgelegenen Farm einsetzen oder eine Wandergruppe fernab von Mobilfunknetz koordinieren wollen — zwei Protokolle dominieren heute die Diskussion: Meshtastic und MeshCore.
Sie teilen dieselbe zugrundeliegende Funktechnologie — LoRa (Long Range Funk) — und können auf identischer Hardware laufen. Unter der Haube treffen sie jedoch grundlegend unterschiedliche architektonische Entscheidungen, die sehr unterschiedliche reale Verhaltensweisen erzeugen. Dieser Artikel erklärt genau, worin diese Unterschiede bestehen, mit genug technischer Tiefe, um eine fundierte Entscheidung für den eigenen Einsatz zu treffen.
Was sind sie? Ein kurzer Überblick
Meshtastic ist eine vollständig Open-Source, dezentrale, netzunabhängige Mesh-Kommunikationsplattform. Jeder Knoten ist gleichberechtigt — jedes Gerät kann jede Nachricht weiterleiten. Es ist als Plug-and-Play konzipiert: Firmware flashen, mit dem Telefon koppeln, und schon ist man im Mesh. Das Projekt ist Community-getrieben mit zehntausenden aktiven Nutzern weltweit und einem umfangreichen Ökosystem unterstützter Hardware.
MeshCore ist ein neueres, leichtgewichtiges LoRa-Mesh-Protokoll, das auf einer hybriden Routing-Architektur basiert. Es teilt Geräte in unterschiedliche Rollen ein — Client-Geräte, die nur senden und empfangen, dedizierte Repeater, die das Routing übernehmen, und Raum-Server, die Nachrichtenverläufe speichern. Diese Struktur macht es bei großer Skalierung deutlich effizienter und ist für professionelle Einsätze konzipiert.
Beide Protokolle sind Open Source. Beide funktionieren auf LoRa-Funkhardware. Beide unterstützen Multi-Hop-Mesh-Netzwerke. Der grundlegende Unterschied liegt darin, wie Nachrichten durch das Netzwerk reisen.
Der technische Kernunterschied: Routing-Architektur
Dies ist das wichtigste Konzept überhaupt. Jeder nachfolgende Unterschied — Akkulaufzeit, Skalierbarkeit, Störungsresistenz — ergibt sich direkt aus dieser einen architektonischen Entscheidung.
Meshtastic: Verwaltetes Flood-Routing
Meshtastic verwendet einen kontrollierten Flooding-Ansatz. Wenn ein Knoten eine Nachricht sendet, sendet er sie an alle Knoten im Funkbereich. Jeder empfangende Knoten sendet sie an seine Nachbarn weiter. Dies kaskadiert nach außen, bis jeder Knoten im Netzwerk die Nachricht erhalten hat oder die Hop-Grenze erreicht ist.
Wichtige Parameter:
- Standard-Hop-Grenze: 3 Hops
- Maximale Hop-Grenze: 7 Hops
- Deduplizierung: Knoten speichern kürzlich gesehene Pakete und ignorieren Duplikate, um Endlosschleifen zu verhindern
- Alle Knoten leiten weiter: Jedes Gerät nimmt standardmäßig am Weiterleiten des Datenverkehrs teil
Dieser Ansatz ist elegant in seiner Einfachheit — keine Routing-Tabellen zu pflegen, keine Pfadfindungsphase, keine Infrastrukturplanung erforderlich. Er ist auch sehr widerstandsfähig: Wenn ein Knoten offline geht, werden Nachrichten automatisch um die Lücke herumgeleitet.
Der Kompromiss ist die Kanaleffizienz. In einem großen, dichten Netzwerk erzeugt Fluten enorme Mengen redundanten Funkverkehrs. Jede Nachricht kann netzwerkweit Dutzende von Wiederholungen auslösen. Dieses Phänomen wird manchmal als "Broadcast-Sturm" bezeichnet und wird mit wachsender Knotenzahl zu einem bedeutenden Engpass. Die Dokumentation von Meshtastic erkennt an, dass die Leistung bei etwa 100 Knoten auf einem Kanal aufgrund von Hardware-Speicherbeschränkungen und Kanalsättigung zu sinken beginnt.
MeshCore: Hybrides Source Routing
MeshCore verfolgt mit seinem hybriden Routing-Protokoll einen grundlegend anderen Ansatz. Es kombiniert eine anfängliche Flutphase zur Pfadfindung mit gerichteten Unicast-Übertragungen für alle weiteren Kommunikationen.
Phase 1 — Pfadfindung (Fluten):
Wenn Knoten A zum ersten Mal Knoten B erreichen will, flutet er das Netzwerk. Wenn Knoten B die Nachricht erhält, erzeugt er eine Zustellbestätigung, die den vollständigen Pfad enthält, den die Nachricht zurückgelegt hat — die geordnete Folge der Repeater-Adressen. Diese Bestätigung flutet zurück zu Knoten A.
Phase 2 — Gerichtete Übertragung (Unicast):
Knoten A extrahiert den Pfad aus der Bestätigung und speichert ihn zwischen. Alle nachfolgenden Nachrichten an Knoten B betten diesen Pfad direkt in den Paketheader ein. Repeater prüfen, ob ihre Adresse mit dem im Pfadheader angegebenen nächsten Hop übereinstimmt — wenn ja, leiten sie weiter; wenn nicht, verwerfen sie das Paket vollständig. Keine unnötigen Wiederholungen.
Wichtige Parameter:
- Maximale Hop-Anzahl: 64 Hops
- Pfadzwischenspeicherung: Client-Geräte speichern bekannte Routen pro Kontakt in ihrem Adressbuch
- Pfadwiederherstellung: Wenn ein Pfad durch Knotenbewegung unterbrochen wird, erkennt der Sender den Ausfall nach einigen Wiederholungen, löscht den zwischengespeicherten Pfad und flutet erneut, um eine neue Route zu finden
Das Ergebnis ist eine dramatisch reduzierte Kanalnutzung nach dem anfänglichen Pfadfindungs-Handshake. In einem etablierten MeshCore-Netzwerk ist der meiste Datenverkehr punkt-zu-punkt gerichteter Unicast — keine Broadcasts. Diese Architektur skaliert weit über das hinaus, was flood-basierte Systeme praktisch leisten können.
Knotenrollen: Wo MeshCore das Modell verändert
Eine der wirkungsvollsten Designentscheidungen von MeshCore ist die explizite Trennung der Gerätefunktionen. Bei Meshtastic sind alle Knoten funktional gleichwertig. Bei MeshCore sind die Rollen klar definiert, bewusst gewählt und beeinflussen alles von der Batterielaufzeit bis zur Planung der Netzwerktopologie.
Companion Radio (Client)
Dies ist das Gerät, das Endnutzer tragen, verbunden via Bluetooth LE mit einer Smartphone-App. Die entscheidende Designentscheidung: Companion Radios leiten standardmäßig keinen Verkehr weiter. Sie senden und empfangen eigene Nachrichten, beteiligen sich aber nicht am Weiterleiten von Paketen anderer Knoten.
Auswirkung auf die Akkulaufzeit: Da das Gerät den Kanal nicht kontinuierlich überwacht und nicht ständig weiterstrahlt, sinkt der Funk-Duty-Cycle erheblich. Dies ist ein großer praktischer Vorteil für Handgeräte, die über einen ganzen Tag im Feldeinsatz genutzt werden.
Hinweis: Ein "Client-Repeat"-Modus existiert für Szenarien ohne Repeater-Infrastruktur — eine temporäre Notlösung, nicht der vorgesehene Betriebsmodus.
Repeater
Repeater sind das Rückgrat eines MeshCore-Netzwerks. Mit spezieller Repeater-Firmware betrieben, werden sie typischerweise an festen, erhöhten Standorten eingesetzt — Hügelkuppen, Gebäudedächer, Funkmasten — um die Abdeckung zu maximieren. Im Gegensatz zum rein dezentralen Modell von Meshtastic sind MeshCore-Repeater die Routing-Infrastruktur.
Da Repeater Pakete nur weiterleiten, wenn ihre Adresse mit dem im eingebetteten Pfadheader angegebenen nächsten Hop übereinstimmt, ist ihre Verarbeitung hochgradig zielgerichtet. Sie übernehmen echte Routing-Aufgaben, ohne an Broadcast-Stürmen teilzunehmen.
Room Server
Der Room Server ist eine einzigartige Funktion ohne direktes Meshtastic-Äquivalent. Er fungiert als BBS (Bulletin Board System) — ein persistenter Nachrichtenspeicher für Gruppenkanäle. Nutzer, die ihre Geräte Stunden nach der Übertragung einschalten, können den vollständigen Verlauf abrufen, ähnlich einer Chat-Anwendung mit serverseitigem Verlauf.
Dies ist besonders wertvoll für Teams mit asynchronen Zeitplänen: Such- und Rettungsteams, landwirtschaftliche Überwachungsoperationen oder Gemeinschaftsinfrastrukturnetzwerke, bei denen Knoten nicht ständig online sind.
Room Server können optional als Repeater konfiguriert werden, aber die MeshCore-Dokumentation rät davon ab, Rollen in leistungs-kritischen Einsätzen zu kombinieren.
Seitenvergleich
| Funktion | Meshtastic | MeshCore |
|---|---|---|
| Routing-Protokoll | Gesteuertes Flooding (Broadcast) | Hybrides Source Routing (Flood → gerichteter Unicast) |
| Netzwerkarchitektur | Vollständig dezentralisiert, alle Knoten gleichberechtigt | Hierarchisch: Clients + Repeater + Room Server |
| Maximale Hops | 7 (Standard: 3) | 64 |
| Client-Weiterleitung | Ja — alle Knoten leiten standardmäßig weiter | Nein — Clients leiten standardmäßig nicht weiter |
| Skalierbarkeit | ~100 Knoten vor Kanalverschlechterung | Nahezu unbegrenzt (infrastrukturgebunden) |
| Kanaleffizienz | Niedriger bei Skalierung (Flood-Overhead) | Hoch (gerichteter Unicast nach Pfadfindung) |
| Akkulaufzeit des Handgeräts | Mäßig (Relay-Duty-Cycle) | Hoch (kein Relay = geringere Funkaktivität) |
| Offline-Nachrichtenverlauf | Keine (nur Echtzeit) | Ja — über Room Server |
| GPS / Standortfreigabe | Integriert, eine Hauptfunktion | Keine Hauptfunktion |
| Verschlüsselung (Broadcast) | AES-256-CTR symmetrischer Schlüssel pro Kanal | Verschlüsselte Kommunikation |
| Verschlüsselung (Direktnachrichten) | PKC Ende-zu-Ende (Firmware v2.5.0+) | Sicher durch Design |
| Einrichtungsaufwand | Sehr gering — Plug-and-Play | Mittel — erfordert Planung der Netzwerkrolle |
| Community-Größe | Sehr groß (Zehntausende) | Wachsend, kleiner aber aktiv |
| Open Source | Vollständig Open Source (MIT/GPL) | Open-Source-Kern; einige kommerzielle Elemente |
| Interoperabilität | ❌ Nicht kompatibel — inkompatible Protokolle | |
Verschlüsselung und Sicherheit in der Tiefe
Beide Protokolle verschlüsseln ihre Kommunikation, aber die Implementierungsphilosophie unterscheidet sich in für professionelle Einsätze wichtigen Punkten.
Meshtastic verwendet AES-256-CTR für Kanalübertragungen. Jedes Gerät, das einen Kanal teilt, nutzt denselben symmetrischen Schlüssel — wer den Schlüssel kennt, kann den gesamten Kanalverkehr entschlüsseln. Für Direktnachrichten führte Meshtastic in Firmware v2.5.0 PKC (Public Key Cryptography) Ende-zu-Ende-Verschlüsselung ein, sodass nur der beabsichtigte Empfänger eine DM entschlüsseln kann, selbst wenn Pakete über Funk abgefangen werden.
Wichtige Hinweise zur Betriebssicherheit bei Meshtastic:
- Der Standard-Kanalschlüssel ist öffentlich bekannt (
"AQ==") — jede produktive Nutzung muss diesen sofort ändern - Paket-Header sind niemals verschlüsselt — Knotenadressen und Hop-Zahlen sind für Beobachter immer sichtbar
- Es gibt keine perfekte Vorwärtsgeheimnis (PFS) — abgefangener verschlüsselter Datenverkehr könnte nachträglich entschlüsselt werden, wenn ein Kanal-Schlüssel später kompromittiert wird
- Kanalnachrichten haben keine Integritätsprüfung, was theoretisch Manipulationen ermöglicht
Für eine vollständige Anleitung zu bewährten Sicherheitspraktiken siehe unseren Leitfaden: Meshtastic Konfigurationstipps — Kanal-Einrichtung und Sicherheit.
MeshCore ist mit Sicherheit als Hauptanforderung statt als Zusatz konzipiert, insbesondere für taktische und professionelle Einsätze. Der v2-Spezifikationsfahrplan des Protokolls umfasst verbesserte Pfad-Hashing- und Verschlüsselungsverbesserungen. Der Fokus auf professionelle Anwendungsfälle bedeutet, dass die Sicherheitsverstärkung eine höhere Entwicklungspriorität hat als im eher hobbyorientierten Code von Meshtastic.
Hardware: Gleiche Funkmodule, unterschiedliche Firmware
Dies ist einer der wichtigsten praktischen Punkte: Beide Protokolle laufen auf weitgehend ähnlicher LoRa-Hardware. Die meisten Entwicklungsboards, die um die Semtech SX1262- oder SX1276-Chipsätze gebaut sind, werden von beiden Ökosystemen unterstützt.
Hardware, die von beiden häufig unterstützt wird:
- Heltec WiFi LoRa 32 V3 — Kompakt, erschwinglich, integriertes OLED, beliebter Einstiegspunkt
- LilyGo T-Beam / T3-S3 — GPS-integriertes Board, weit verbreitet in Meshtastic-Tracking-Anwendungen
- RAK WisBlock — Modulare Plattform, ideal für kundenspezifische Sensor- und Gateway-Einsätze
- Seeed Studio SenseCAP Serie — Industrielle Hardware mit Solarstromunterstützung
Die wichtigste Erkenntnis: Sie sind nicht an eines der Ökosysteme gebunden. Dasselbe physische Gerät kann mit jeder Firmware betrieben werden. Wenn Sie mit Meshtastic beginnen, um die Grundlagen des Mesh-Netzwerks zu lernen, und später feststellen, dass die Architektur von MeshCore besser zu Ihrem Einsatz passt, ist es nur ein Firmware-Flash entfernt — keine neue Hardware erforderlich.
Für Antennenauswahl und Reichweitenoptimierung (für beide Protokolle anwendbar) siehe:
Flash-Tools:
- Meshtastic: flasher.meshtastic.org
- MeshCore: flasher.meshcore.co.uk
Welches Protokoll sollten Sie wählen?
Kein Protokoll ist universell überlegen. Sie sind für wirklich unterschiedliche Einsatzszenarien optimiert. Die ehrliche Antwort ist, dass die richtige Wahl vollständig davon abhängt, was Sie bauen möchten.
Wählen Sie Meshtastic, wenn:
- Sie sind neu im LoRa-Mesh-Netzwerk und wollen den schnellsten Weg zu einem funktionierenden System
- Ihr Anwendungsfall ist mobil und temporär — Wandergruppen, Skipatrouillen, Trailrennen, Campingausflüge, Veranstaltungskoordination
- GPS-Standortfreigabe ist eine Kernanforderung
- Sie wollen die größte Community, die meisten Tutorials und das breiteste Hardware-Ökosystem
- Ihr Netzwerk bleibt relativ klein (unter ~30 Knoten), wo der Flooding-Overhead vernachlässigbar ist
- Sie benötigen alles über eine ausgereifte mobile App mit minimalem technischem Aufwand konfiguriert
Unsere vollständige Meshtastic-Anleitungsserie deckt jeden Aspekt von Einrichtung und Betrieb ab:
- Meshtastic Konfigurationstipps
- Android-Anwendungsnutzungsanleitung
- Meshtastic UI Übersicht
- Meshtastic BaseUI Anleitung
- Konfiguration des Reichweitentestmoduls
- Übersicht Nachbarinformationsmodul
- Benutzereinstellungen und Konfiguration
Wählen Sie MeshCore, wenn:
- Sie setzen permanente, feste Infrastruktur ein — Community-Mesh-Netzwerke, Smart Agriculture, industrielles IoT, Notfallmanagementsysteme
- Die Netzwerkskalierung ist wichtig — Sie brauchen zuverlässige Kommunikation für Dutzende bis Hunderte gleichzeitiger Nutzer
- Sie benötigen Offline-Nachrichtenspeicherung und -abruf (Room Server's BBS-Funktionalität)
- Kanaleffizienz ist entscheidend und Sie können sich keine Broadcast-Stürme leisten, die Ihre LoRa-Spektrumzuweisung sättigen
- Die Akkulaufzeit des Handgeräts hat Priorität für verlängerte Feldeinsätze
- Ihr Anwendungsfall ist professionell oder taktisch und erfordert definierte Kommunikationsrollen und eine strukturierte Netzwerktopologie
- Sie benötigen eine Abdeckung über 7 Hops hinaus — MeshCore unterstützt Pfade mit bis zu 64 Hops Länge
Ein Hinweis zur Interoperabilität
Das ist ausdrücklich zu sagen: Meshtastic- und MeshCore-Geräte können nicht miteinander kommunizieren. Sie verwenden inkompatible Paketformate, unterschiedliche Routing-Protokolle und verschiedene Kanalstrukturen. Ein Meshtastic-Knoten, der auf 915 MHz arbeitet, wird MeshCore-Daten auf derselben Frequenz nicht dekodieren können, und umgekehrt.
Wenn Sie in einer Umgebung einsetzen, in der bereits ein Protokoll läuft, müssen Sie sich auf dasselbe festlegen, um Interoperabilität zu erreichen. Es gibt derzeit keine Brücke oder Gateway zwischen den beiden Ökosystemen.
Drei Fragen zur Entscheidungsfindung
-
Mobil oder fest?
Wenn sich Ihre Knoten bewegen (Personen tragen Geräte), bewältigt Meshtastics Flood-Modell Topologieänderungen ganz natürlich ohne Konfiguration. Wenn Ihre Knoten feste Infrastruktur sind, wird MeshCores Pfad-Caching zu einem großen Effizienzvorteil. -
Null-Konfiguration oder bereit, Infrastruktur aufzubauen?
Meshtastic kann in Minuten ohne Planung ein funktionierendes Netzwerk bilden. MeshCore erfordert gezielte Platzierung von Repeatern und Rollenzuweisung – mehr Arbeit am Anfang, deutlich bessere Leistung im großen Maßstab. -
Kleine Ad-hoc-Gruppe oder große dauerhafte Community?
Für Gruppen unter ~30 Knoten bei temporärem Einsatz gewinnt Meshtastics Einfachheit. Für größere oder permanente Netzwerke werden MeshCores Routing-Effizienz und Room-Server-Fähigkeiten zu entscheidenden Vorteilen.
Fazit
Meshtastic und MeshCore sind beide technisch ausgereifte, aktiv entwickelte und wirklich nützliche LoRa-Mesh-Protokolle. Sie sind weniger Konkurrenten als vielmehr Lösungen für unterschiedliche Probleme.
Meshtastic ist die demokratisierte Option: maximale Zugänglichkeit, minimale Einrichtung, die größte Community und das beste mobile Erlebnis. Es ist die richtige Wahl, wenn Sie etwas brauchen, das sofort funktioniert und Ihr Netzwerk überschaubar bleibt.
MeshCore ist die entwickelte Option: überlegene Routing-Effizienz, klare Rollentrennung, Offline-Nachrichtenpersistenz und ein Weg zu stadtweiter oder regionaler Abdeckung. Es erfordert mehr Planung, liefert aber deutlich bessere Leistung bei großen oder professionellen Einsätzen.
Da die Hardware mit beiden kompatibel ist, sind Sie nie vollständig gebunden. Der praktische Weg für die meisten Nutzer: starten Sie mit Meshtastic, um die Grundlagen des LoRa-Mesh zu lernen, prüfen Sie, ob die Architektur von MeshCore echte Probleme löst, die Sie haben, und wechseln Sie, wenn die Effizienzgewinne die Einrichtung rechtfertigen.
Für eine vollständige Einführung in Meshtastic durchstöbern Sie unsere komplette Meshtastic-Einsteigerleitfaden-Serie. Für MeshCore beginnen Sie bei docs.meshcore.io, um die Architektur der Knotentypen zu verstehen, bevor Sie Hardware kaufen.
Viel Spaß beim Vernetzen.
