Die offizielle MeshCore-Firmware (meshcore-dev/MeshCore)
MeshCore ist eine schlanke, portable C++-Bibliothek für Multi-Hop-Paketrouting über LoRa und andere Paketradios, entwickelt für dezentrale, internetunabhängige Kommunikationsnetze. Das Projekt positioniert sich bewusst zwischen Meshtastic (eher auf Plauder-Verkehr ausgelegt) und Reticulum (umfangreiches Networking-Framework) und legt den Fokus auf leichtgewichtiges Multi-Hop-Routing für Embedded-Anwendungen.
Die Firmware wird in mehreren Rollen ausgeliefert, die sich im Verhalten deutlich unterscheiden:
- Companion Radio — Client-Gerät, das sich per BLE, USB oder WiFi mit einer Chat-App verbindet. Companion-Knoten leiten bewusst keine Pakete weiter, um ungünstige Routing-Pfade zu vermeiden.
- Repeater — verlängert die Netzreichweite durch Weiterleitung von Nachrichten.
- Room Server — eine Art BBS-Server für geteilte Posts.
- Sensor — Telemetrie-Knoten mit ACL-Unterstützung.
- KISS Modem — Serial-KISS-Bridge für Host-Anwendungen.
Fertige Binaries lassen sich über den Web-Flasher unter flasher.meshcore.dev bzw. flasher.meshcore.co.uk auf eine breite Palette von LoRa-Hardware (Heltec, RAK Wireless, Ebyte, Seeed, u.a.) schreiben, ohne selbst kompilieren zu müssen. Die Konfiguration von Repeater- und Room-Server-Firmwares erfolgt über config.meshcore.io (USB) oder remote per LoRa aus den Mobile-Apps heraus. Die Roadmap nennt unter anderem ACLs für Repeater, standardisierten Bridge-Mode, erweiterte Zero-Hop-Nachbarerkennung, LZW-Nachrichtenkompression, dynamische Coding Rate und langfristig eine V2-Protokollspezifikation.
Airtime-Management in der offiziellen Firmware stützt sich auf klassische Duty-Cycle-Prüfungen pro Sendung, eine feste Hop-Begrenzung sowie rollenbasiertes Routing (Companion-Knoten repeaten nicht). Ein rollierendes Duty-Cycle-Fenster und adaptive Flood-Advert-Begrenzung sind als Pull Requests offen (PR #1297, #1338), aber noch nicht im Main-Branch enthalten.
MeshCore-Evo (mattzzw/MeshCore-Evo)
MeshCore-Evo versteht sich ausdrücklich als friendly fork der offiziellen Codebasis. Ziel ist es nicht, eine alternative Mesh-Plattform aufzubauen, sondern Repeater-Firmwares mit ausgewählten, noch nicht gemergten Upstream-PRs und zusätzlichen Patches bereitzustellen — insbesondere für Betreiber großer oder dichter Netze. Der Fork bezieht sich regelmäßig frisch auf den offiziellen dev- oder main-Branch und legt pro Release transparent offen, welche Änderungen eingeflossen sind.
Die wiederkehrenden Kernänderungen gegenüber dem offiziellen Build sind:
- Token-Bucket Duty-Cycle Enforcement (Upstream-PR #1297). Damit wird der TX-Airtime-Budget nicht mehr pro Sendung, sondern in einem rollierenden Zeitfenster gemanagt. Das erlaubt zentralen, stark frequentierten Repeatern einen robusteren Sendebetrieb, ohne die regulatorischen 1 %- bzw. 10 %-Duty-Cycle-Grenzen (ETSI 868 MHz) zu verletzen.
- Limit Flood Advert Packet Forwarding (PR #1338). Ein neuer Parameter
flood.advert.base(Float zwischen 0 und 1, Default ~0,308) entscheidet probabilistisch, welcher Anteil der empfangenen Flood-Adverts überhaupt weitergeleitet wird. 0 schaltet Flood-Advert-Forwarding komplett ab, 1 leitet alles weiter. Hintergrund ist das Problem, dass in dichten Meshes Flood-Adverts einen erheblichen Anteil der Airtime auffressen. - Längere Advert-Intervalle:
flood.advert.intervalundadvert.intervallassen sich deutlich höher setzen als im Upstream — bis zu 168 h (wöchentliche Flood-Adverts). Empfohlen werden in den Release-Notes z. B.flood.advert.interval=168undadvert.interval=240(alle 4 h). - EU/Narrow LoRa-Defaults bei frisch geflashten Boards, was Fehlkonfigurationen in europäischen Deployments vorbeugt.
- Hardware-spezifische Patches: Für das RAK4631-Variant wurde die Boot-Lockout-Spannung gesenkt (z. B. von 3,3 V auf 3,1 V bzw. 0 V), damit Boards mit LiFePo4- oder LTO-Zellen (etwa die uart.cz-Boards) überhaupt booten. Außerdem enthielten frühere Builds einen undokumentierten Register-Patch zur Verbesserung der RX-Empfindlichkeit des Heltec V4 (PR #1398, inzwischen upstream gemergt).
Die aktuellen Evo-Releases basieren auf MeshCore 1.13/1.14 und liefern ausschließlich Repeater-Firmwares — keine Companion- oder Room-Server-Builds. Der unterstützte Hardware-Satz (Ebyte EoRa-S3, Heltec CT62, Heltec Mesh Solar, RAK4631, generische E22 SX1262/SX1268 etc.) entspricht einer Teilmenge der offiziellen Hardware-Liste, fokussiert auf gängige Repeater-Plattformen.
Direktvergleich
| Aspekt | meshcore-dev/MeshCore (offiziell) | mattzzw/MeshCore-Evo |
|---|---|---|
| Rolle des Projekts | Komplette Plattform mit allen Node-Rollen | Repeater-Spezial-Build mit Pre-Merge-Patches |
| Node-Typen | Companion, Repeater, Room Server, Sensor, KISS Modem | Nur Repeater |
| Airtime-Management | Klassisches Duty-Cycle pro Sendung | Token-Bucket / rolling window (PR #1297) |
| Flood-Advert-Kontrolle | Upstream-PR offen | Aktiv, konfigurierbar via flood.advert.base |
| Max. Advert-Intervall | Niedriger (default 48 h) | Bis 168 h (wöchentlich) |
| LoRa-Defaults | Regionsunabhängig | EU/Narrow vorkonfiguriert |
| Hardware-Fixes | Upstream-Stand | RAK4631-Lockout-Patch, frühere Heltec-V4-Patches |
| Flasher-Integration | Ja (flasher.meshcore.dev) | Nein — Binaries aus GitHub Releases, aber uploadbar über flasher.meshcore.dev |
| Remote-Management | Vollständig unterstützt | Kompatibel (erbt Upstream-Funktionen) |
| Zielgruppe | Alle Anwender | Betreiber großer/dichter Meshes |
| Release-Takt | Regelmäßig, versioniert (aktuell v1.14.x) | Folgt dev/main zeitnah nach |
Wichtig zu betonen: MeshCore-Evo ist protokollkompatibel zur offiziellen Firmware. Ein Evo-Repeater spricht mit Companion-Knoten und Room-Servern des Upstream-Builds ohne Anpassungen. Der Fork ersetzt also nicht das Ökosystem, sondern optimiert einen spezifischen Knoten-Typ für Netze, in denen Airtime und Advert-Flut sonst zum Problem werden.
Hardware-Abhängigkeiten
Beide Firmwares unterstützen im Wesentlichen die gleiche Hardware-Basis: nRF52840-basierte Boards (RAK4631, Heltec Mesh Node T114, Heltec Mesh Solar), ESP32/ESP32-S3-Boards (Heltec V3/V4, Ebyte EoRa-S3, LilyGo T-Beam, T3-S3) sowie generische SX1262/SX1268-Module. Da Evo auf den offiziellen Boards-Definitionen aufsetzt, sind neu hinzugefügte Geräte im Upstream automatisch auch für Evo baubar — die veröffentlichten Binaries decken allerdings nur eine kuratierte Teilmenge ab. Wer exotische oder sehr neue Hardware fährt, ist mit dem offiziellen Flasher besser bedient; wer zentrale Repeater auf Standard-Hardware betreibt, profitiert vom Evo-Feature-Set.
Alternativen im MeshCore-Umfeld und darüber hinaus
Rund um MeshCore selbst existieren mehrere relevante Projekte:
- liamcottle/meshcore.js — Node.js-Bibliothek und Web-Client (
app.meshcore.nz) für Companion-Firmware. - fdlamotte/meshcore-cli — Python-Kommandozeilen-Client.
- config.meshcore.dev / config.meshcore.io — Web-basierte Konfigurations-Tools für Repeater und Room Server.
Als alternative Mesh-Protokolle/-Firmwares außerhalb von MeshCore sind vor allem zu nennen:
- Meshtastic (
meshtastic.org) — der Platzhirsch im LoRa-Mesh-Bereich, breitere App-Landschaft und größere Community, aber mit anderem Routing-Ansatz und höherem Overhead, was in dichten Netzen schneller zu Airtime-Problemen führt. - Reticulum / RNS (
reticulum.network) — universelles, kryptografisch abgesichertes Networking-Stack, das nicht auf LoRa beschränkt ist. Deutlich umfangreicher als MeshCore, dafür ressourcenhungriger. - disaster.radio — älteres Open-Source-Projekt für Krisenkommunikation per LoRa, inzwischen weniger aktiv.
- LoRa APRS / OE5BPA-Firmware — für Amateurfunker im APRS-Kontext, kein klassisches Mesh, aber im gleichen Hardware-Ökosystem.
Für reinen Repeater-Betrieb in großen MeshCore-Netzen ist Evo derzeit die naheliegendste Alternative zur Upstream-Firmware. Wer hingegen Companion- oder Room-Server-Knoten betreibt oder aktuelle Flasher-Integration braucht, fährt mit meshcore-dev/MeshCore am besten — und kann Evo gezielt dort einsetzen, wo es weh tut: auf den zentralen, stark frequentierten Repeatern.
Quellen
- meshcore-dev/MeshCore — offizielles Repository: https://github.com/meshcore-dev/MeshCore
- mattzzw/MeshCore-Evo — Fork-Repository: https://github.com/mattzzw/MeshCore-Evo
- MeshCore-Evo Release Notes: https://github.com/mattzzw/MeshCore-Evo/releases
- PR #1297 „Implement token bucket duty cycle enforcement": https://github.com/meshcore-dev/MeshCore/pull/1297
- PR #1338 „Limit flood advert packet forwarding": https://github.com/meshcore-dev/MeshCore/pull/1338
- Issue #817 „Rolling window duty cycle management": https://github.com/meshcore-dev/MeshCore/issues/817
- Issue #1223 (Flood-Advert-Proposal): https://github.com/meshcore-dev/MeshCore/issues/1223
- Issue #1572 (RAK4631 Lockout-Spannung): https://github.com/meshcore-dev/MeshCore/issues/1572
- MeshCore-Dokumentation: https://docs.meshcore.io
- MeshCore Flasher: https://meshcore.io/flasher bzw. https://flasher.meshcore.co.uk