Änderungen zu v1.14.1 zeigen die fortlaufende Entwicklung des Codes. Nach dem 1.14.0-Release gab es eine Reihe an wichtigen Neuerungen unter der Haube.
Hier ist der Überblick über die Kernfunktionen im neuesten Release für Repeater und Room Server.
1. Token Bucket Duty Cycle (Akkumuliertes Sende-Budget)
Was ist das? Damit Funknetzwerke nicht überlastet werden und gesetzliche Sendezeiten (Duty Cycle) eingehalten werden, muss jeder Repeater nach dem Funken physisch pausieren. Bisher war diese Pause starr an das zuletzt gesendete Paket geknüpft (z. B. 1 Sekunde Sendezeit = sofort 2 Sekunden Blockade).
Was ist neu? Der Repeater nutzt nun eine intelligente „Token Bucket“-Logik. Er bekommt ein stetig nachladendes Zeit-Budget zugewiesen. Jedes gesendete Paket zieht lediglich seine Zeit von diesem Gesamtkonto ab.
Warum ist das nützlich?
-
„Sendezeit ansparen“: Repeater, die längere Zeit leise waren, haben ein volles Budget.
-
Bei einem plötzlichen Ansturm an Nachrichten (sog. Bursts) können sie nun mehrere Pakete rasch und direkt hintereinander weiterleiten, ohne von der Funk-Sperre blockiert zu werden. Das Netz läuft bei Lastspitzen dadurch spürbar flüssiger.
2. Intelligenter Sende-Dispatcher (Airtime Limits)
Was ist das? Der Dispatcher ist der „Verkehrspolizist“ im Repeater. Er entscheidet auf Systemebene, wann ein in der Warteschlange liegendes Paket physisch in die Luft (Airtime) geht.
Was ist neu? Der Dispatcher schätzt via getEstAirtimeFor() vorab die benötigte Sendezeit für das nächste Paket. Er weigert sich strikt, die Übertragung zu starten, wenn sein aktuelles Sende-Budget zu knapp ist (präziser: wenn es kleiner als die Hälfte der geschätzten Airtime ist). Stattdessen kalkuliert er eine zielgerichtete Pufferzeit (next_tx_time).
Warum ist das nützlich? Der Dispatcher bewahrt den Repeater davor, sich in Sachen „Sendezeit zu verschulden“. Große Datentransfers werden nicht unnötig gestartet, wenn absehbar ist, dass dem Repeater am Ende illegal die Luft ausgeht. Das reduziert Sende-Abbrüche und stellt höchste Fairness im Node-Netzwerk sicher.
3. Schaltbarer Empfangsverstärker (Remote LNA)
Was ist das? Viele moderne Hardware-Boards (z.B. mit dem SX1262-Funkchip) besitzen einen internen Hardware-Verstärker (Low Noise Amplifier, LNA), mit dem sehr leise Funksignale besser „gehört“ werden können.
Was ist neu? Ein Software-Bug, der die Register-Auswertung der Chips zerschossen und den LNA unbemerkt fehlerhaft ausgewertet hat, wurde repariert. Nun kann man das Verhalten der Empfangsantenne präzise auf „Power Saving“ (Stromsparend) oder „Boosted Gain“ (Hoher Empfang) konfigurieren (sx126x_rx_boosted_gain).
Warum ist das nützlich?
-
Standalone auf dem Berg: Steht dein Repeater abgelegen und soll Signale von schwachen Handfunkgeräten aus großer Distanz aufschnappen? Schalte den LNA ein (Boosted Gain).
-
Im Zentrum der Stadt: Steht der Repeater inmitten des Mesh-Netzes, nah an vielen anderen Nodes, und hängt vielleicht an einem kleinen Akku? Aktiviere den Power Saving Modus für drastisch längere Laufzeiten!
4. Entzerrte Flood Advert Timer
Was ist das? Jeder Repeater funkt periodisch automatische „Adverts“ (Rundrufe), um dem gesamten Mesh-Netz mitzuteilen: „Hallo Leute, ich bin noch online, hier ist meine Route auf der Karte.“
Was ist neu? Vorher war die Wartezeit auf den exakten Millisekunden-Timer fixiert. Jetzt fließt der vom Administrator eingestellte Hash-Modus des Repeaters direkt als Offset in die Wartezeit-Logik (delay_millis) ein.
Warum ist das nützlich? Starten mehrere Repeater unfreiwillig zeitgleich neu (etwa nach einem regionalen Stromausfall), senden sie ihre großen Adverts jetzt minimal zeitversetzt ab. Das verhindert fatale Paket-Kollisionen auf derselben Funkfrequenz und der Netzaufbau nach Ausfällen pendelt sich robuster ein.
5. Integrierte Temperatur-Telemetrie (Spezifisch für Room Server)
Was ist das? Sogenannte Room Server im Netz senden standardmäßig Statusmeldungen über Akkustände oder externe I2C-Umweltsensoren (wie BME280 Module) als Telemetrie ins Mesh-Netz.
Was ist neu? Ab sofort liest die Firmware automatisch die direkt im ESP32-Chip (MCU) hardwareseitig verbaute Diode für die Chippunkt-Temperatur aus (board.getMCUTemperature()) und fügt sie dem Standard-Telemetrie-Bericht an. Komplett ohne angelötete Sensoren!
Warum ist das nützlich? Admins können nun verlässlich von der Ferne überwachen, ob Outdoor-Cases von Room Servern durch harte Sommerhitze kritisch überhitzen oder gefährlich kalten Frostnächten ausgesetzt sind.