In großen oder dicht besiedelten Mesh-Netzen stoßen Repeater schnell an Grenzen: zu viele Flood-Adverts, Interferenzen und ausgereizte Sendezeit-Budgets (Duty Cycle) führen zu Kollisionen und verlorenen Nachrichten. Genau hier setzt MeshCore-Evo an – eine Community-Fork der offiziellen MeshCore-Firmware, die ausgewählte, noch nicht offiziell übernommene Verbesserungen bündelt.
Hinweis: MeshCore-Evo ist eine inoffizielle Community-Fork des Entwicklers mattzzw und keine offizielle MeshCore-Firmware. Der Einsatz erfolgt auf eigene Verantwortung.
Was ist MeshCore-Evo?
MeshCore-Evo bezeichnet sich selbst als „freundliche Fork" des MeshCore-Projekts. Ziel ist es, Repeater-Firmware mit einigen noch ausstehenden Upstream-Verbesserungen bereitzustellen – also Pull Requests (PRs), die im offiziellen Repository noch nicht übernommen wurden oder es aus verschiedenen Gründen vielleicht nie werden. Die Fork steht unter der MIT-Lizenz und basiert jeweils auf einer offiziellen MeshCore-Version (aktuell dem Entwicklungszweig von 1.15.0).
Der Schwerpunkt liegt klar auf Repeatern in großen bzw. dichten Netzen. Für normale Companion-Clients ist die Fork weniger relevant – diese leiten in MeshCore ohnehin keine Pakete weiter.
Was MeshCore-Evo verbessert
Der Schwerpunkt liegt auf typischen Problemen großer Netze:
- Flood-Adverts steuerbar machen: Statt jede Advert-Flut ungebremst weiterzuleiten, lässt sich der Anteil weitergeleiteter Flood-Adverts dosieren – das entlastet dichte Netze spürbar.
denyf *verfeinern: Ein Repeater, der perdenyf *eigentlich alles ablehnt, kann trotzdem weiterhin Pfade für Direktnachrichten zulassen.- Interferenz hardwareseitig erkennen: Über die Channel Activity Detection (CAD) des Funkchips werden Störungen zuverlässiger erkannt.
Aktuelle Version: v1.15.0-evo_0.1.20 (14. Mai 2026)
Die derzeit neueste Version basiert auf dem offiziellen MeshCore-1.15.0-dev-Zweig (Stand 14. Mai 2026) und ergänzt ihn um folgende noch nicht offiziell übernommene Pull Requests (PRs):
- PR2553 – Flood-Adverts begrenzen:
set flood.advert.base 0...1steuert die Weiterleitung von Flood-Advert-Paketen (0= keine Weiterleitung,0.308= Standard,1= alle weiterleiten). - PR1810 – Direktnachrichten trotz
denyf *: erlaubt Pfade für Direktnachrichten, auch wenndenyf *gesetzt ist. In dieser Version so angepasst, dass Flood-Adverts nicht blockiert werden, sondern nurPAYLOAD_TYPE_GRP_TXTundPAYLOAD_TYPE_GRP_DATA(Gruppen-Text und Gruppen-Daten). - PR1727 (neu in dieser Version) – Hardware-CAD: hardwareseitige Channel Activity Detection zur Interferenzprüfung, aktivierbar mit
set int.thresh 1.
- Abschalt-Spannung (lockout voltage) für die Varianten RAK 4631, Xiao nRF und T114 von 3,3 V auf 0 V gesenkt.
- Flood-Adverts standardmäßig deaktiviert (
flood.advert.interval= 0). - Neu: LoRa-Coding-Rate
LORA_CRstandardmäßig auf 8 (in derplatformio.ini).
⚠️ Wichtig nach dem Flashen: Prüfe, dassradio.rxgaineingeschaltet (on) undflood.advert.baseauf0.308gesetzt ist.
Die beiden vorangegangenen Versionen waren v1.15.0-evo_0.1.19 (24. April 2026) und v1.14.1-evo_0.1.18 (5. April 2026).
Versionierung und Release-Rhythmus
Die Versionen tragen ein zweiteiliges Schema: die zugrunde liegende MeshCore-Version plus ein evo-Suffix, zum Beispiel v1.15.0-evo_0.1.20. Seit Ende Februar 2026 erschien rund ein Dutzend Releases, die jeweils zügig auf neue MeshCore-Stände (1.13.0 → 1.14.x → 1.15.0) nachgezogen wurden.
Für wen lohnt sich ein Blick?
Vor allem für Betreiber von Repeatern in dichten oder stark frequentierten Netzen, die mit Advert-Fluten, Interferenzen oder Duty-Cycle-Grenzen zu kämpfen haben. Wer einen einzelnen Repeater in ruhiger Lage betreibt, kommt mit der offiziellen Firmware in der Regel gut aus.
Da es sich um eine inoffizielle Fork handelt, gilt: die Änderungen genau in den Release-Notes nachlesen, die Einstellungen nach dem Flashen prüfen und im Zweifel mit der eigenen Community abstimmen.
Quellen
- Repository: github.com/mattzzw/MeshCore-Evo
- Releases & Changelogs: github.com/mattzzw/MeshCore-Evo/releases