MeshCore vs Meshtastic: Welches LoRa-Mesh-Protokoll passt zu Ihnen?

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.

Meshtastic-Nutzer im Einsatz — netzunabhängige LoRa-Mesh-Kommunikation in Aktion
LoRa-Mesh-Netzwerk-Knoten — die Hardware-Basis für sowohl Meshtastic- als auch MeshCore-Einsätze.

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.

Meshtastic Flood-Routing: Jeder Knoten leitet Nachrichten an alle Nachbarn weiter
Meshtastics verwaltetes Flood-Routing: Jeder Knoten sendet an alle Nachbarn weiter, kaskadiert bis zu 7 Hops nach außen.

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.

MeshCore-Netzwerkarchitektur: Companion Radio, Repeater und Room Server
MeshCores hierarchische Knotenarchitektur: Companion Radios (Clients), Repeater (Rückgrat) und Room Server (Nachrichtenverlauf).

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.

Beliebte LoRa-Hardware-Boards: Heltec, LilyGo T-Beam, RAK WisBlock, Seeed SenseCAP
Gängige LoRa-Hardware: Heltec WiFi LoRa 32 V3, LilyGo T-Beam, RAK WisBlock und Seeed SenseCAP — alle kompatibel mit beiden Protokollen.

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:


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:

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

  1. 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.
  2. 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.
  3. 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.

Für unseren Newsletter anmelden

Erhalten Sie die neuesten Informationen über unsere Produkte und Sonderangebote.

Website Feedback

Help us improve OpenELAB

Found a website issue or have an idea? Tell us what would make your experience better.