MeshCore Repeater konfigurieren: Checkliste für Firmware 1.16 und 1.17

Vorab

Diese Checkliste gilt für die Stock-Firmware ab 1.16. Ältere Versionen kennen flood.max.unscoped nicht, und alles unter 1.14 verwirft Multi-Byte-Pfade und floodet ungefiltert. Wer noch EVO fährt: EVO ist mit 1.15 eingestellt worden, 1.16 hat die EVO-Funktionen übernommen.

Alle Befehle klein schreiben (set, nicht Set). Änderungen an Funkparametern brauchen einen Reboot. Hardware und Aufbau stehen unter Repeater aufbauen und in der Geräteübersicht.

Firmware ist 1.16 oder 1.17.1, geprüft mit get version
Private Key per USB mit get prv.key gesichert, bevor du irgendetwas flashst

Name und Identität

set name <Name> mit Standort und Kontaktmöglichkeit. Einen verbindlichen Namensstandard gibt es nicht, aber ein Kontakt im Namen erspart Rätselraten, wenn dein Repeater Ärger macht.
ID-Präfix prüfen: Die ersten zwei Hex-Zeichen dürfen in deiner Nachbarschaft nicht doppelt vorkommen, sonst werden Traces unlesbar. Wunschpräfix per gessaman.com/mc-keygen setzen.
Nur stationär betreiben. Mobile Repeater zerstören gelernte Pfade.

Regionen und unscoped Traffic

Regionen entscheiden, welche Nachrichten dein Repeater weiterleitet. Details, Schema und Fallstricke stehen unter Regionen und Scopes, hier nur die Kurzfassung.

Nur lokale Regionen eintragen, in Hamburg de-hh, de-nord und hansemesh. Maximal etwa 10, technisch 32 à 29 Byte. Groß-/Kleinschreibung zählt.
de sperren. Die Region wird wie * missbraucht, Hamburg und Sachsen haben sie abgeschaltet.
Nach jeder Änderung region save, sonst ist die Liste nach dem Reboot weg.

Befehl	Wert	Warum
`set flood.max`	10	Scoped Floods enden nach 10 Hops statt 64. Ab 7 bis 8 Hops liegt die Zuverlässigkeit ohnehin nur noch bei 70 bis 80 %.
`set flood.max.unscoped`	2 bis 5, je nach Lage	Unscoped Pakete laufen nur noch ein paar Hops. Neulinge ohne Scope kommen lokal noch an, das Netz wird nicht überschwemmt. Ländlich eher 5, in dichten Netzen 2 bis 3. Nur überlastete Kern-Repeater setzen 0.
`set flood.max.advert`	3 bis 5	Flood-Adverts fremder Nodes werden nach wenigen Hops gestoppt.

flood.max.unscoped 0 nur mit Bedacht: Auf Firmware bis 1.16 brach das die Fernadministration, weil Remote-Admin und Pfadsuche unscoped laufen; mit der aktuellen Firmware ist das behoben. Ein hartes denyf * auf Stock-Firmware unter 1.15 sperrt zusätzlich DMs, Traces und Adverts.

Duty Cycle

set dutycycle 10

In Deutschland gelten 10 % im rollierenden 60-Minuten-Fenster, also 360 Sekunden Sendezeit pro Stunde. Der Default liegt bei 50 % und ist damit nicht legal. Bis 1.15 hieß der Befehl set af 9, die Formel war 100 / (af + 1). Bei 0,5 bis 0,75 s pro Paket schafft ein Repeater so 600 bis 700 Pakete pro Stunde. Das ist die Kapazität des gesamten Kanals, nicht nur deine.

Befehl	Wert	Warum
`set advert.interval.zero`	240	Zero-Hop-Advert alle 4 Stunden, das ist der Maximalwert. Nachbarn lernen dich, ohne dass jemand außer ihnen etwas davon merkt.
`set advert.interval.flood`	0 oder 48 bis 150	0 heißt aus. Wer den Repeater in der Ferne sichtbar haben will, nimmt 48 bis 150 Stunden. Nicht 168, sonst filtern manche Karten den Repeater als offline.

Die Rechnung dahinter: 70 Hamburger Repeater mit je 70 Wiederholungen bei 48 Stunden ergeben 4.900 Pakete, rund 100 Adverts pro Stunde reiner Overhead. Flood-Adverts machten zeitweise die Hälfte des gesamten Traffics aus.

Zero-Hop auf 240 Minuten
Flood-Advert auf 0 oder in Absprache mit der Region 48 bis 150 Stunden

Timing und Pfade

Befehl	Wert	Warum
`set txdelay`	0.7	Kern-Repeater mit vielen Nachbarn 2.0. Zu hohe Werte bremsen das ganze Netz, zu niedrige erzeugen Kollisionen.
`set direct.txdelay`	0.5	Verzögerung für gerichtete Pakete. Kern-Repeater 0.9.
`set rxdelay`	0	Kein echtes Delay, sondern ein Filter für schlecht gehörte Flood-Pakete. An Kern-Repeatern in dichten Netzen bis 6.
`set path.hash.mode`	2	3-Byte-Pfade. 1 Byte bedeutet nur 256 mögliche IDs und ständige Kollisionen. Companions nutzen Modus 1.
`set loop.detect`	minimal	Reicht mit 3-Byte-Pfaden, spart Aussetzer.
`set cad off`		Hardware-CAD blockiert den Kanal bis zu 4 Sekunden. Die Software-Lösung ist genauso gut, ohne Aussetzer.
`set int.thresh`	0	In EVO war 1 Listen-Before-Talk, in Stock 1.16/1.17 bringt es nichts.
`set agc.reset.interval`	60	Setzt die Empfänger-Regelung regelmäßig zurück. Hilft, wenn der Repeater bei Störern taub wird.
`set multi.acks`	1	Etwas mehr Traffic, spürbar zuverlässigere Zustellung.

Die Delay-Werte sind die wichtigsten Zeilen dieser Tabelle. Ein normaler Repeater am Rand nimmt die Standardwerte, ein Kern-Repeater mit vielen Nachbarn die höheren Werte, sonst reden alle gleichzeitig.

Alle Werte aus der Tabelle gesetzt, in der App zum Schluss oben den Haken zum Speichern drücken, dann Reboot

Empfänger: rxgain und Rauschen

set radio.rxgain on ist der Standard. Ausnahme Heltec V4 und T096 auf 1.17.1: dort set radio.fem.rxgain off und set radio.rxgain off

1.17.1 schaltet den Vorverstärker per Default ein. Auf Heltec V4 und T096 hebt das den Noise Floor von etwa -115 auf -84 dBm, weil der Verstärker vor allem Rauschen verstärkt. Auf 1.16 ist der Verstärker per Default aus.

Gut ist ein Grundrauschen von -110 bis -117 dBm. Liegt es dauerhaft über -100 dBm, sitzt in der Nähe eine Störquelle wie ein Mobilfunkmast oder ein Balkonkraftwerk. Dann hilft ein SAW-Filter, an Mastenstandorten bis zu 14 dB.

Sendeleistung und ERP

Erlaubt sind 500 mW ERP, das sind 27 dBm. ERP ist nicht der Wert am Chip, sondern das, was die Antenne abstrahlt:

ERP [dBm] = tx [dBm] + Antennengewinn [dBd] - Kabel und Stecker [dB]
dBd = dBi - 2,15

Verluste: SMA-Übergang etwa 0,3 dB, N etwa 0,2 dB, RG58 etwa 1 dB pro Meter, H155 0,27 bis 0,55 dB pro Meter. Rechne mit dem realen Gewinn, nicht dem Aufdruck. Eine als 5 dBi verkaufte Antenne liefert oft 2 bis 3 dBi, siehe 868-MHz-Antenne.

Board	tx-Wert	Leistung am Chip
SX1262 (RAK, Xiao, Heltec V3)	22	ca. 158 mW, 22 dBm
Heltec V4	16	ca. 467 mW
Heltec V4	17	ca. 520 mW
Heltec V4	22	ca. 800 mW, über dem Limit
T096	12	250 mW
T096	13	380 mW
T096	16	560 mW

Beispiel: SX1262 mit 22 dBm, Antenne 3 dBi (0,85 dBd), 1 m H155 und zwei SMA-Übergänge ergeben rund 22,5 dBm ERP, deutlich unter 27. Ein Heltec V4 mit tx 17 (27,2 dBm) und derselben Antenne liegt bei etwa 27,5 dBm ERP, also knapp drüber. Mit einer 6,5-dBi-Antenne (4,35 dBd) landet der V4 bei tx 16 schon bei rund 30 dBm, das ist 1 W.

set tx so gewählt, dass die Rechnung unter 27 dBm bleibt
Zu hohe Werte auf dem V4 werden gekappt und können die Endstufe beschädigen

1.16 gegen 1.17: was sich ändert

	1.16	1.17.x
Neu	`flood.max.unscoped`, `flood.max.advert`, PowerSaving aus IoTThinks	Kollisions-Fixes, Login-Response nicht mehr als Flood
rxgain	Default aus	Default an, manuell ausschalten
Bekannte Bugs		`region load` friert die CLI ein, App-Menü nutzen. T096 auf 1.17.0 sendet nicht, 1.17.1 nehmen. Nach Login-Bug notfalls per Flood anmelden und Pfad neu setzen.

Nach jedem Update prüfen

get version zeigt die erwartete Version
Coding Rate steht auf 8. Nach Updates wurde schon CR 5 beobachtet, das Narrow-Preset braucht 869,618 MHz, BW 62,5 kHz, SF 8, CR 8
Regionen noch vorhanden, Updates haben sie sporadisch gelöscht
dutycycle, Advert-Intervalle und Flood-Limits kontrollieren
rxgain und fem.rxgain aus
Uhrzeit stimmt, sonst werden Adverts verworfen. Ohne RTC-Modul nach jedem Reboot clock sync
Wenn Werte unerklärlich falsch sind: mit Erase flashen und alles neu setzen

Auslastung messen

Airtime in der Status-Abfrage: RX 12 bis 17 % und TX unter 1 % sind in Ordnung. Ab 10 bis 14 % Kanalauslastung wird es kritisch, über 30 % fällt das Netz aus.
Paketfehler: 20 bis 25 % sind in dichten Netzen normal, 11 % sehr gut, bis 50 % an exponierten Standorten. Duplikate 13 bis 15 % sind normal.
Debug Flag 2 im Log bedeutet, der Kanal war 4 Sekunden belegt und TX blockiert. Dann txdelay erhöhen oder den Standort hinterfragen.
Nachbarn: Links unter -6 dB sind nicht stabil. Über 20 Nachbarn mit 30 bis 70 % Fehlern: rxdelay hoch, TX runter, Filter einbauen.
Langzeitsicht über analyzer.letsmesh.net, meshcore-analyzer.eu und map.kiekr.app. Observer erzeugen keinen Mesh-Traffic.

Fallstricke

EVO-Migration. EVO hängt Parameter am Dateiende an, 1.16 liest sie an anderer Stelle. Nach dem Wechsel stehen falsche Werte im Speicher. Mit Erase flashen oder jeden Parameter einzeln neu setzen.
ESP32-Bootloop nach EVO-Flash. Merged-Datei ohne Erase aufgespielt. Erst Standard mit Erase, dann neu.
UF2 gegen merged. UF2 überschreibt nur die App, die Config bleibt. Merged löscht auch das Dateisystem.
Regionen ohne region save. In der App eingetragen, aber nicht gespeichert: nach dem Reboot weg.
Position nach Reboot deaktiviert. Bekannter Bug, nach jedem Neustart prüfen.
Uhr springt zurück. Ohne RTC steht die Zeit nach Reboot auf 1970 oder 2024, nRF-Quarze driften zudem nach etwa 50 Tagen. Ein DS3231 an I2C wird automatisch erkannt.
Automatische Abfragen. Home-Assistant-Skripte fragen per Flood ab und laufen durchs ganze Land. Pfad fest setzen oder abschalten.
Alte Firmware in der Nachbarschaft. Repeater unter 1.14 verwerfen 2- und 3-Byte-Pfade. Betreiber ansprechen, Update oder Abbau.

Repeater-Hardware

Boards, die in der Checkliste vorkommen:

Xiao nRF52840 + Wio-SX1262 Kit – Sparsam, erste Wahl für Solar. Bei Amazon ansehen *
SenseCAP P1 Pro – Fertiger Repeater mit Akku. Bei Amazon ansehen *
Heltec V4 – Stark, aber stromhungrig, nur mit Netzstrom. Bei Amazon ansehen *
Heltec V3 – Budget-Board, für Repeater nur mit Dauerstrom. Bei Amazon ansehen *
RAK WisBlock – Modular, nRF52-basiert. Bei Amazon ansehen *
SAW-Filter – Pflicht an exponierten Standorten. SAW-Filter im Shop

Fragen?

Bei Unklarheiten zu einzelnen Werten oder zur Absprache in deiner Region hilft die Telegram-Gruppe: t.me/meshcorede.

* Affiliate-Links: Kaufst du über einen mit * markierten Link bei Amazon, bekommt HanseMesh eine kleine Provision. Für dich ändert sich der Preis nicht. Wir verlinken nur Hardware, die in der Community im Einsatz ist.