EasySkyMesh PowerSaving: MeshCore-Repeater sinnvoll konfigurieren

Eine gute Repeater-Konfiguration hängt nicht allein von der Sendeleistung ab. Ebenso wichtig sind ein sinnvoller Standort, möglichst wenig unnötiger Funkverkehr und die Frage, welche Nachrichten tatsächlich über mehrere Stationen weitergeleitet werden sollen. EasySkyMesh PowerSaving ergänzt MeshCore um Funktionen, die vor allem bei Akku- und Solarbetrieb interessant sind.

Diese Anleitung zeigt Empfehlungen mit begründetem Spielraum statt fester Werte für jedes Netz. Der Landkreis Gießen dient dabei ausschließlich als Beispiel für die Regionskonfiguration. Andere Standorte in Hessen benötigen gegebenenfalls andere Regionen und Hop-Grenzen.

Wichtig: Jeder Konsolenbefehl muss einzeln ausgeführt werden. In der WordPress-Fassung stehen die Befehle deshalb jeweils in einem eigenen Code-Block-Pro-Block mit Kopierfunktion.

1. Hardware, Firmware und Funkparameter

Zunächst sollte geprüft werden, welche Platine und Firmware tatsächlich verwendet werden. Dabei müssen der Mikrocontroller und der LoRa-Funkchip unterschieden werden, denn nicht jede Empfangs- oder Stromsparfunktion steht auf allen Boards zur Verfügung.

Hardware kontrollieren:

• board
• ver
• get radio
• get tx
• powersaving
• get radio.rxps

Für das EU/UK-Narrow-Preset verwenden wir 869,618 MHz, 62,5 kHz Bandbreite und SF8. Bei der Coding Rate ist CR8 ein robuster Ausgangspunkt. Bei stabilen Funkverbindungen kann CR5 die Airtime verringern, weil weniger Fehlerkorrekturdaten übertragen werden müssen.

Im üblichen LoRa-Modus mit explizitem Header wird die Coding Rate im Paket mitgeteilt. Unterschiedliche Coding Rates sind daher grundsätzlich kompatibel. Bei schwierigen Verbindungen kann die stärkere Fehlerkorrektur von CR7 oder CR8 jedoch Vorteile bringen.

Ausgangseinstellungen:

• set radio 869.618,62.5,8,8
• set dutycycle 10
• set repeat on

Alternative für gute Verbindungen:

• set radio 869.618,62.5,8,5

Nur eine Coding Rate verwenden und die Auswirkungen auf Empfang und Airtime prüfen. Die Sendeleistung bleibt zunächst unverändert, da Antennengewinn, Kabelverluste und zusätzliche Verstärker berücksichtigt werden müssen.

2. Flood-Hops sinnvoll einstellen

Je größer die Hop-Grenze, desto weiter können Flood-Nachrichten verbreitet werden. Gleichzeitig steigt die Gefahr unnötiger Mehrfachaussendungen. Eine hohe Zahl ist deshalb nicht automatisch besser.

Für normale Flood-Nachrichten sind sechs Hops ein brauchbarer Ausgangspunkt. Soll ein Repeater größere Regionen verbinden, können auch acht bis zehn Hops sinnvoll sein. Nachrichten ohne Regionszuordnung sollten dagegen eher auf drei oder vier Hops beschränkt werden.

Ausgangswerte:

• set flood.max 6
• set flood.max.unscoped 3
• set flood.max.advert 6

Alternativen nach Netztests:

• set flood.max 10
• set flood.max.unscoped 4

Die Werte sind Alternativen und keine Befehlsfolge, die vollständig abgearbeitet werden muss. Die Hop-Grenzen gelten außerdem für die jeweiligen Flood-Paketarten, nicht pauschal für direkt geroutete Nachrichten.

3. Pfad-Hashes, Schleifenerkennung und Multi-ACK

MeshCore unterstützt Pfadkennungen mit einem, zwei oder drei Bytes. Ein Byte kann in größeren Netzen zu Kollisionen führen, wenn verschiedene Repeater dieselbe kurze Kennung erhalten. Zwei Byte sind ein brauchbarer Ausgangspunkt, drei Byte erhöhen die Eindeutigkeit weiter.

Allerdings benötigen größere Kennungen mehr Platz im Paket. Auch die Firmwareversionen benachbarter Repeater sollten berücksichtigt werden.

Die Schleifenerkennung mit minimal ist eine zurückhaltende Ausgangseinstellung. Über strengere Einstellungen gibt es unterschiedliche Meinungen. Sobald ältere 1-Byte-Hashes weitgehend verschwunden sind, können strengere Werte erneut geprüft werden.

Ausgangseinstellungen:

• set path.hash.mode 1
• set loop.detect minimal
• set multi.acks 1

Alternative für ein aktuelles, größeres Netz:

• set path.hash.mode 2

Wert 1 entspricht zwei Byte, Wert 2 entspricht drei Byte. Multi-ACK sollte aktiviert bleiben, da es die zuverlässige Nachrichtenbestätigung unterstützt.

4. Empfang und Sendeverzögerung

Die Funkumgebung hat erheblichen Einfluss auf die Empfangsqualität. Besonders exponierte Standorte können durch starke Sender in der Umgebung beeinträchtigt werden.

CAD und die Interferenzschwelle können als Ausgangspunkt ausgeschaltet bleiben. Der periodische AGC-Reset ist mit Wert 0 deaktiviert. Bei einzelnen Boards, beispielsweise bestimmten Heltec-V4-Konfigurationen, oder bei starken Störsignalen kann ein gezielter AGC-Reset sinnvoll sein. Das sollte aber anhand tatsächlicher Empfangsprobleme untersucht werden.

Empfang und Störerkennung:

• get radio.rxgain
• set radio.rxgain on
• set cad off
• set int.thresh 0
• set agc.reset.interval 0

Anders sieht es bei den Weiterleitungsverzögerungen aus. txdelay, direct.txdelay und rxdelay hängen unter anderem von der Exponiertheit, den Nachbarrepeatern und der Auslastung ab. Insbesondere txdelay 0 ist keine allgemeine Empfehlung, da dadurch die zufällige Verzögerung zur Kollisionsvermeidung abgeschaltet wird.

Werte zunächst nur auslesen:

• get txdelay
• get direct.txdelay
• get rxdelay

Eine Optimierung dieser Werte sollte erst erfolgen, wenn die Netzstruktur und das tatsächliche Verhalten des Repeaters bekannt sind.

5. Advert-Intervalle: Warum 47 Stunden sinnvoll sind

Zero-Hop-Adverts informieren unmittelbar erreichbare Stationen über den Repeater. Vier Stunden sind hierfür ein netzschonendes Intervall.

Bei Flood-Adverts sollte nicht nur die Netzlast betrachtet werden. Ein Intervall von 150 Stunden reduziert zwar die Aussendungen, kann aber dazu führen, dass Repeater auf Karten als veraltet angezeigt werden.

47 Stunden sind deshalb ein sinnvoller Kompromiss. Außerdem handelt es sich nicht um ein Vielfaches von 24 Stunden, sodass sich der Sendezeitpunkt gegenüber der Tageszeit verschiebt.

Konsolenbefehle:

• set advert.interval 240
• set flood.advert.interval 47

Ob ein Repeater in einer Karte als aktuell erscheint, hängt zusätzlich davon ab, ob seine Adverts empfangen und an den jeweiligen Kartendienst übermittelt werden.

6. EasySkyMesh PowerSaving auf nRF52-Platinen

nRF52-Geräte wie der Seeed XIAO nRF52840 mit Wio-SX1262, das RAK4631 und der Heltec T114 sind häufig für stromsparende Akku- und Solarsysteme geeignet.

EasySkyMesh bietet zwei unterschiedliche Ansätze: Allgemeines PowerSaving reduziert die Aktivität des Mikrocontrollers. RX PowerSaving (RXPS) lässt zusätzlich den kompatiblen LoRa-Empfänger zwischen Empfangsfenstern schlafen.

Das kann den Energiebedarf senken, allerdings auch die Empfangszuverlässigkeit beeinflussen. Gerade bei Repeatern, die wichtige Verbindungen bereitstellen, sollte deshalb zunächst ohne RXPS getestet und anschließend ein Vergleich mit balanced durchgeführt werden.

Status und allgemeines Stromsparen:

• powersaving
• get radio.rxps
• powersaving on

RXPS-Testalternativen:

• set radio.rxps off
• set radio.rxps balanced

Die beiden RXPS-Werte sind Alternativen. Nach einer Änderung empfiehlt der Entwickler einen Neustart und anschließende Empfangstests.

7. ESP32-Repeater und externe Funkverstärker

Auch geeignete ESP32-Repeater können die PowerSaving-Funktionen verwenden. Der erreichbare Vorteil hängt jedoch stark von der Hardware ab. Display, USB-Schnittstelle, Spannungsregler und weitere Komponenten können einen erheblichen Anteil am Gesamtverbrauch haben.

Einige Heltec-Platinen besitzen außerdem ein externes Front-End-Modul mit zusätzlichem Empfangsverstärker. Bei passenden Hardwareversionen lässt sich dieser Verstärker softwareseitig abschalten.

Das ist keine allgemeine ESP32-Eigenschaft. Bei einem normalen XIAO nRF52840 mit Wio-SX1262 ist kein entsprechendes schaltbares externes FEM vorhanden.

Allgemeine PowerSaving-Abfragen:

• powersaving
• get radio.rxps
• powersaving on

Nur bei unterstütztem externen FEM:

• get radio.fem.rxgain
• set radio.fem.rxgain off

Das Abschalten der zusätzlichen Empfangsverstärkung kann Strom sparen, gegebenenfalls aber die Empfangsqualität verringern. Die externe Sendeverstärkung sollte ohne Prüfung der tatsächlich abgestrahlten Leistung nicht geändert werden.

8. Erweiterte RXPS-Profile

EasySkyMesh bietet neben off und balanced auch weitere Profile. conservative entspricht Stufe 3, balanced Stufe 6 und max Stufe 8.

Darüber hinaus gibt es experimentelle Modi wie overdrive und riskyWorkingMax. Diese verlassen die dokumentierten Timing-Bedingungen der Funkchips. Insbesondere der aggressivste Modus kann Paketverluste verursachen.

Profile für Vergleichstests:

• get radio.rxps
• set radio.rxps conservative
• set radio.rxps balanced
• set radio.rxps max

Nur jeweils einen Modus verwenden und Stromaufnahme sowie Empfangsqualität vergleichen.

9. GPS und automatischer Neustart

Ist ein kompatibles GPS-Modul vorhanden, kann EasySkyMesh dieses für die Synchronisation nutzen und energieeffizient verwalten. Ohne entsprechendes Modul werden die GPS-Befehle übersprungen.

Ein automatischer Neustart ist bei einem zuverlässig arbeitenden Repeater normalerweise nicht nötig. Bei Stationen, die sich nach längerer Laufzeit wiederholt aufhängen, kann ein Neustartintervall vorübergehend helfen. Die eigentliche Ursache sollte trotzdem untersucht werden.

Neustartintervall:

• get reboot.interval
• set reboot.interval 0

Nur mit kompatiblem GPS-Modul:

• gps
• gps on
• gps sync

10. Regionen und Scopes: Landkreis Gießen als Beispiel

Regionen helfen dabei, Nachrichten möglichst dort weiterzuleiten, wo sie tatsächlich benötigt werden. Für MeshCore Hessen ist deshalb keine einheitliche Regionskonfiguration für sämtliche Standorte vorgesehen.

Ein Repeater im Landkreis Gießen kann beispielsweise die Home-Region de-he-gi verwenden. Diese liegt unterhalb von de-he für Hessen.

Die Default-Region beeinflusst dagegen die eigenen Aussendungen des Repeaters. Solange nicht ausreichend viele benachbarte Repeater den engeren Scope de-he-gi weiterleiten, sollte als Default zunächst de-he verwendet werden. Eine spätere Umstellung auf die kleinere Region ist sinnvoll, wenn die regionale Abdeckung zuverlässig funktioniert.

Beispielkonfiguration ausschließlich für den Landkreis Gießen:

• region
• region put de-he
• region put de-he-gi de-he
• region allowf de-he
• region allowf de-he-gi
• region allowf *
• region home de-he-gi
• region default de-he
• region save

Bestehende Regionen werden dadurch nicht automatisch entfernt. Vor Änderungen sollte daher zunächst die vorhandene Hierarchie kontrolliert werden.

Zusätzlich wurde ein Scope für Oberhessen vorgeschlagen. Ein einheitlicher, tatsächlich verwendeter Regionsname ist dafür allerdings noch nicht ausreichend bestätigt. Deshalb sollte dieser Scope erst nach Abstimmung mit den beteiligten Repeater-Betreibern aufgenommen werden.

11. Konfiguration kontrollieren

Nach der Einrichtung sollten die wichtigsten Werte erneut ausgelesen werden. Erst wenn die Einstellungen stimmen, wird der Repeater neu gestartet.

Kontrollbefehle:

• get radio
• get flood.max
• get flood.max.unscoped
• get flood.max.advert
• get path.hash.mode
• get flood.advert.interval
• get radio.rxps
• region
• region home
• region default
• reboot

Nach Änderungen am Funkprofil oder an RXPS sollten Empfangsqualität, Paketverluste und gegebenenfalls Stromverbrauch erneut geprüft werden.

Das ganze Handbuch dazu gibt es hier als Download

Fazit

Eine sinnvolle Repeater-Konfiguration ist kein starres Profil, das überall identisch verwendet werden sollte. CR5 kann bei guten Verbindungen Airtime sparen, größere Pfad-Hashes können die Eindeutigkeit in wachsenden Netzen verbessern und passende Hop-Grenzen vermeiden unnötigen Funkverkehr.

Auch die Advert-Intervalle müssen sowohl die Netzlast als auch die Sichtbarkeit der Repeater berücksichtigen. Mit EasySkyMesh PowerSaving lässt sich der Energiebedarf zusätzlich optimieren. Entscheidend bleibt jedoch, dass die Station zuverlässig empfängt und weiterleitet.

Für MeshCore Hessen dienen die gezeigten Einstellungen deshalb als Ausgangspunkt. Die endgültige Konfiguration sollte immer zum jeweiligen Standort, zur Netzstruktur und zur verwendeten Hardware passen.

Quellen und weiterführende Informationen

• EasySkyMesh PowerSaving – stabile Firmware
• PowerSaving-Fork – CLI-Dokumentation
• Offizielle MeshCore-CLI-Dokumentation
• Offizielle MeshCore-FAQ
• Semtech – LoRa-Funkheader und Coding Rate

Technischer Stand: 28. Oktober 2026. Die beschriebenen Einstellwerte sind praxisbezogene Empfehlungen und keine verbindlichen Vorgaben für jeden Standort.