Repeater Firmware 1.14.0 - Änderungen im Überblick

Meshcore
, ,
1

Repeater v1.14.0 – Änderungen im Überblick

Changelog auf Github: Release Repeater Firmware v1.14.0 · meshcore-dev/MeshCore · GitHub

1. Wählbare Pfad-Stempel-Größe (Path Hash Mode)

Was ist das?
Wenn ein Paket durch das Mesh wandert, hinterlässt jeder Repeater einen kurzen „Stempel" (Hash), damit der Rückweg bekannt ist. Bisher war dieser Stempel immer 1 Byte groß.

Was ist neu?
Der Repeater kann jetzt wählen, ob der Stempel 1, 2 oder 3 Bytes groß sein soll.

Warum ist das nützlich?

  • 1 Byte = 256 verschiedene Stempel → bei vielen Nodes können zwei denselben haben → falsche Zustellung möglich.

  • 2 Bytes = 65.536 verschiedene Stempel → Verwechslungen fast ausgeschlossen.

  • 3 Bytes = über 16 Millionen → für sehr große Netze.

Wie stellt man das ein?
Per CLI: set path.hash.mode 0 (1 Byte), set path.hash.mode 1 (2 Bytes) oder set path.hash.mode 2 (3 Bytes). Standard ist 0 (1 Byte, wie bisher).

Muss ich alle Repeater umstellen?
Die Einstellung betrifft nur die eigenen Sendungen des Repeaters (z.B. Adverts). Beim Weiterleiten fremder Pakete liest der Repeater die Hash-Größe automatisch aus dem empfangenen Paket. Allerdings müssen alle Repeater im Pfad mindestens Firmware v1.14.0 haben, weil ältere Firmware das neue Format nicht versteht und solche Pakete verwirft.

Wird die Einstellung gespeichert?
Ja, sie bleibt nach einem Neustart erhalten.

Empfehlung zur Verwendung von Multibyte Path Hashes

Kurz: Nicht umstellen, solange nicht alle Nodes im Netz auf v1.14.0+ sind.

Warum?

  1. Gemischte Netze sind das Problem. Sobald ein einziger Repeater im Pfad alte Firmware hat, kommen Pakete mit 2- oder 3-Byte-Hashes nicht an. Es gibt keine Fehlermeldung oder Rückfallmechanismus – das Paket ist einfach weg.

  2. Kein Auto-Fallback im Code. Der Sender weiß nicht, ob alle Repeater im Pfad v1.14.0+ haben. Es gibt keinen Mechanismus, der bei Nicht-Zustellung automatisch auf 1-Byte zurückfällt. Auch die Path-Discovery (createPathReturn) übernimmt die Hash-Größe aus dem empfangenen Paket – wenn das originale Flood-Paket nicht ankommt, gibt es keine Discovery.

  3. 1-Byte reicht für die meisten Netze. 256 mögliche Stempel sind nur dann ein Problem, wenn viele Repeater im selben Pfad stehen. Die relevante Kollisionsgröße ist nicht die Gesamtzahl der Nodes, sondern die Anzahl der Hops in einem einzelnen Pfad. Bei typischen Pfaden von 3–5 Hops ist die Kollisionswahrscheinlichkeit bei 1-Byte-Hashes gering.

Wann lohnt sich der Wechsel auf 2 Bytes?

  • Alle Nodes (Repeater, Companion, Room Server, Sensor) im Netz haben v1.14.0+.

  • Pfade mit 10+ Hops sind üblich.

  • Es gibt regelmäßig Zustellprobleme, die auf Hash-Kollisionen zurückzuführen sein könnten.

Wann lohnt sich 3 Bytes?

Praktisch nie. Der Overhead (3× mehr Path-Bytes = mehr Airtime) steht in keinem Verhältnis zum Gewinn gegenüber 2 Bytes. 65.536 verschiedene Stempel bei 2 Bytes reichen für jedes realistische Mesh.

2. Loop-Detection mit wählbarer Empfindlichkeit

Was ist das?
Pakete können im Mesh in einer Schleife kreisen, wenn mehrere Repeater sich gegenseitig hören. Die Loop-Detection erkennt, ob ein Paket schon einmal über diesen Repeater gelaufen ist.

Was ist neu?
Die Empfindlichkeit der Loop-Erkennung ist jetzt in vier Stufen wählbar:

  • off: Keine Erkennung (alle Pakete werden weitergeleitet).

  • minimal: Tolerant – erlaubt mehrere Durchläufe, blockiert erst bei häufigen Wiederholungen.

  • moderate: Ausgewogen – blockiert schneller.

  • strict: Aggressiv – blockiert bereits beim ersten Wiedersehen.

Wie stellt man das ein?
Per CLI: set loop.detect off, set loop.detect minimal, set loop.detect moderate oder set loop.detect strict.

Warum ist das nützlich?
In dichten Netzen mit vielen sich überlappenden Repeatern können Loops viel Airtime verschwenden. Je nach Netztopologie kann man die Empfindlichkeit anpassen.

3. Repeater Discovery

Was ist das?
Neuer CLI-Befehl discover.neighbors, der eine Anfrage ins Netz sendet und alle erreichbaren Repeater in direkter Reichweite auflistet.

Warum ist das nützlich?
Beim Aufstellen eines neuen Repeaters kann man schnell prüfen, welche anderen Repeater in der Nähe sind – ohne manuell zu suchen oder die App zu öffnen.

4. Zero-Hop Adverts

Was ist das?
Neuer CLI-Befehl advert.zerohop, der ein Advert nur an direkte Nachbarn sendet, ohne Flood.

Warum ist das nützlich?
Weniger Airtime-Verbrauch, wenn man nur testen will, ob der Repeater von Nachbarn gesehen wird.

5. Bootloader-Version abfragen (nRF52)

Was ist das?
Neuer CLI-Befehl get bootloader.ver, der die UF2-Bootloader-Version auf nRF52-Boards ausliest.

Warum ist das nützlich?
Man kann aus der Ferne prüfen, ob der Bootloader aktuell ist, ohne das Gerät physisch anzuschließen. Auf anderen Plattformen (ESP32 etc.) gibt der Befehl eine Fehlermeldung zurück.

6. Fehlerbehebungen

Was war kaputt? Was passiert jetzt?
Packet Pool Leak Wenn die RX- oder TX-Queue voll war, ging der Paket-Speicher verloren – das Gerät wurde instabil und musste neugestartet werden. Jetzt werden Pakete korrekt freigegeben, wenn die Queue voll ist.
Loop-Detection (moderate) Die „moderate"-Stufe hatte einen Fehler in der Erkennung. Legitime Pakete konnten fälschlich als Loop eingestuft werden. Jetzt funktioniert die Erkennung korrekt.
Packet::writeTo/readFrom Das Speichern und Laden von Paketen (z.B. für Logging oder Bridge) funktionierte mit dem neuen Path-Encoding nicht korrekt. Jetzt werden Pakete mit allen Hash-Größen korrekt serialisiert.
PacketQueue millis-Wraparound Nach ca. 49 Tagen Dauerbetrieb konnte der interne Zeitzähler überlaufen und Pakete wurden nicht mehr korrekt ausgeliefert. Jetzt funktionieren die Zeitvergleiche auch nach Monaten Laufzeit.
RAK3401 FEM (SKY66122) Die FEM-Steuerung (CSD/CPS) war falsch verdrahtet – der PA wurde bei jedem Senden manuell ein-/ausgeschaltet, obwohl das TX/RX-Switching über DIO2 automatisch erfolgen sollte. Jetzt wird die FEM beim Start eingeschaltet und das TX/RX-Switching läuft über die Hardware. Bessere Reichweite und stabilerer Empfang.
AGC Reset Der bisherige AGC-Reset hat den Empfänger nicht wirklich zurückgesetzt. Jetzt wird ein vollständiger Receiver-Reset durchgeführt (Sleep → Calibrate → Image-Kalibrierung für die aktuelle Frequenz), und die Noise-Floor-Messung startet neu. Betrifft SX126x und LR11x0. Weniger „taube" Empfänger nach Störungen.
GPS-Strom-Leckage Wenn GPS deaktiviert war, floss trotzdem Strom über den UART-Pin (~8 mA auf nRF52). Jetzt wird der GPS-Reset-Pin beim Abschalten korrekt gesetzt und der Peripherie-Strom freigegeben. Längere Akkulaufzeit.
RefCountedDigitalPin Ein GPIO-Pin konnte mehr freigegeben als beansprucht werden, was zu negativen Referenzzählern und falschen Pin-Zuständen führte. Jetzt wird ein doppeltes Release ignoriert.

7. Hardware/Boards

Board Was hat sich geändert?
Heltec Wireless Tracker v1.x GPS-Unterstützung hinzugefügt (GPS-Enable, Reset-Pin, Baudrate). Standort kann jetzt im Mesh genutzt werden.
Heltec Wireless Tracker v2 PA-Initialisierung verbessert: GC1109 bekommt beim Kaltstart 1 ms Einschwingzeit. Im Deep-Sleep bleiben PA_POWER und PA_EN gehalten, damit der LNA beim RX-Wakeup sofort bereit ist.
Heltec v4 PA-Initialisierung wie beim Tracker v2 verbessert. Display-Power wurde von der Peripherie-Steuerung getrennt (kein ungewolltes Display-Ausschalten mehr). VEXT_EN korrigiert auf HIGH-aktiv. I2C-Pins für Sensoren entfernt (verwenden jetzt Board-Standard GPIO 17/18).
LilyGo T-Beam Supreme 8 MB Flash statt 4 MB nutzbar. Neues WiFi-Companion-Target.
RAK3401 FEM-Steuerung komplett überarbeitet (siehe Bugfixes). Neuer SX126X_REGISTER_PATCH für verbesserten RX. Sauberes Shutdown mit FEM-Abschaltung.
Ikoka Handheld (nRF52) Build-Konfiguration korrigiert (Board-Definition, Linker-Script). Gerät lässt sich wieder bauen.
M5Stack Unit C6L Include-Pfad (Groß-/Kleinschreibung) korrigiert. USB-CDC-Flags für Companion-Build hinzugefügt.

8. Abwärtskompatibilität

  • Standard-Einstellung (1 Byte): Pakete sind voll kompatibel mit v1.13.0 und älter.

  • 2- oder 3-Byte-Hashes: Werden von alter Firmware (< v1.14.0) nicht verstanden und verworfen. Alle Repeater im Pfad müssen v1.14.0+ haben.

  • Upgrade: Beim ersten Start nach dem Update steht path.hash.mode auf 0 (1 Byte) – wie bisher. Kein Netzumbau nötig.