MeshCore-Evo ist eine Repeater-Firmware, die weitestgehend identisch zur MeshCore Firmware ist und zusätzlich ein paar Ergänzungen für große/dichte Mesh-Netzwerke beinhaltet.

Im Wesentlichen liegen diese Ergänzungen dem MeshCore Projekt in Form von Pull Requests (PRs) bereits vor, sind aber noch nicht in die MeshCore-Firmware eingeflossen. Oder werden es evtl. auch nie - wer weiß.

Insofern ist MeshCore-Evo eigentlich eher als Notlösung gedacht, bis diese Änderungen in irgendeiner Form Einzug in die originale Firmware („Upstream“) finden.

Diese Änderungen betreffen derzeit (März 2026):

Flood Advert Pakete werden in Abhängigkeit ihrer Hop Anzahl exponentiell seltener wahrscheinlich weiter geleitet. 1 Hop: 100% Wahrscheinlichkeit, 2 Hops: ~30% Wahrscheinlichkeit, 3 Hops: ~10% Wahrscheinlichkeit, 4 Hops: 3% Wahrscheinlichkeit etc.

Diese auf den ersten Blick sehr aggressive Eindämmung von Flood Advert Paketen schränkt die Verteilung von Advert darauf ein, wo sie relevant sind: Auf das lokale Mesh.

Mehr Info dazu unter https://github.com/meshcore-dev/MeshCore/pull/1338

https://github.com/meshcore-dev/MeshCore/pull/1297

Siehe auch https://github.com/meshcore-dev/MeshCore/issues/817

Verteilt das Sendebudget auf eine rollierende Stunde und sorgt daher für die Möglichkeit, kurzzeitig viele Pakete zu senden und dennoch im 10% Duty-Cycle zu bleiben. Achtung: `set af 9` setzt den airtime_factor so, dass theoretisch max 10% duty cycle eingestellt werden.

https://github.com/meshcore-dev/MeshCore/pull/1810

Flood-Nachrichten können Repeater nicht passieren, wenn region denyf * gesetzt ist. Repeater mit dieser Einstellung würden nicht nur die Weiterleitung von Kanalnachrichten und Flood-Ankündigungen verweigern, sondern auch alle Nachrichten, die zur Aushandlung und Einrichtung neuer Pfade für Direktnachrichten verwendet werden. In Bereichen, in denen alle Repeater die Weiterleitung von Flood-Verkehr verweigern, können keine direkten Nachrichtenpfade (wieder) eingerichtet werden.

Dieser PR erlaubt daher die Weiterleitung von REQ, RESPONSE, TXT_MSG, ACK, ANON_REQ, PATH, TRACE, MULTIPART, CONTROL und blockiert GRP_TXT, GRP_DATA, and ADVERT wenn denyf * gesetzt wurde.

Mit https://github.com/meshcore-dev/MeshCore/pull/1413 wurde für NRf-basierte Systeme eine Sicherung für Bootloops durch niedrige Akkuspannung eingebaut, die leider für unterschiedliche Akku-Typen nicht gut funktioniert. Siehe https://github.com/meshcore-dev/MeshCore/issues/1572, nRF devices with LTO batteries: PWRMGT_VOLTAGE_BOOTLOCK too high; prevents boot.

In der Evo Firmware wird diese Lockout-Spannung für RAK4631-basierte Repeater (z.B. uart.cz Platine) auf 0V gesetzt und die Funktion somit deaktiviert.