Debug Flags
Eine häufig gestellte Frage ist die Bedeutung der "Debug Flags", die auf der Repeater Admin Seite unter den Systemstatistiken ("System Stats - Battery, Uptime, Queue Length and Debug Flags") angezeigt werden. Die Debug Flags entsprechen internen Fehlerereignissen, die vom Paket-Dispatcher aufgezeichnet werden. Der angezeigte Wert ist eine Bitmaske, die verschiedene Hardware- und Funkfehler darstellt, die seit dem letzten Neustart (oder seit dem Zurücksetzen der Statistiken) auf dem Knoten aufgetreten sind.
Bedeutung der einzelnen Basis-Werte
Jeder Basis-Fehler hat einen bestimmten Zahlenwert:
1(Warteschlange voll / ERR_EVENT_FULL) Die Warteschlange für ausgehende Pakete war voll. Das bedeutet, dass der Repeater die Pakete nicht schnell genug über den Funkkanal senden konnte und gezwungen war, Pakete zu verwerfen.2(Kanal belegt / ERR_EVENT_CAD_TIMEOUT) Zeitüberschreitung bei der Kanalaktivitätserkennung (Channel Activity Detection - CAD). Das bedeutet, dass der Funkchip erkannt hat, dass der verwendete Funkkanal dauerhaft belegt war, als er versuchte, ein Paket zu senden.4(Hardware-Zeitüberschreitung / ERR_EVENT_STARTRX_TIMEOUT) Eine Zeitüberschreitung trat auf, als versucht wurde, den Empfangsmodus (RX) der Funkhardware zu starten. Dies deutet auf eine minimale Verzögerung, ein Problem beim Aufwachen oder beim Wechseln des Hardware-Status hin.
Kombinierte Werte (Bitmaske)
Da es sich um eine Bitmaske handelt, werden die Werte addiert, wenn mehrere verschiedene Fehler seit dem letzten Start aufgetreten sind:
0= Bislang sind keine Fehler aufgetreten.3= Kombination aus1und2. (Die Warteschlange war voll und es gab ein Channel Activity Detection Timeout).5= Kombination aus1und4. (Die Warteschlange war voll und es gab ein RX Timeout).6= Kombination aus2und4. (Es gab sowohl ein CAD Timeout als auch ein RX Timeout).7= Alle drei oben genannten Fehler (1+2+4) sind aufgetreten.-
Anhand dieser Einteilung kannst du bei Verbindungsproblemen sehr schnell ablesen, ob der Kanal dauerhaft belegt ist (CAD Timeout) oder ob das Gerät einfach überlastet war (Warteschlange voll).
Um diese Fehler (und damit verbundene Verbindungsprobleme) in deinem Mesh-Netzwerk abzumildern, gibt es je nach Fehlercode verschiedene Lösungsansätze. Hier sind die gängigsten Strategien für jeden der drei Fehler, die du über die Kommandozeile (CLI) oder das Admin-Interface anpassen kannst:
1. (ERR_EVENT_FULL) – Warteschlange voll
Dieser Fehler tritt auf, wenn der Knoten mehr Pakete senden soll, als das LoRa-Modem zeitlich über die Antenne abarbeiten kann. Dies ist ein Symptom für ein überlastetes Netzwerk (zu viel Traffic) oder ein zu langsames LoRa-Profil.
Maßnahmen zur Behebung:
- Werbeintervalle erhöhen (Weniger Traffic erzeugen): Erhöhe die Intervalle, in denen der Repeater seine eigenen Standort- und Statusdaten (Advert) ins Netz funkt. Befehle:
set advert.interval <Minuten>(für lokale Pings) undset flood.advert.interval <Stunden>(für weitreichende Floods). - Ausbreitung begrenzen (Flooding reduzieren): Reduziere die Anzahl der Hops, die ein Paket maximal machen darf, um die allgemeine Mesh Auslastung zu verringern. Befehl:
set flood.max <Wert>(Standard ist 64, ein kleinerer Wert wie 32 oder 16 genügt oft für lokale Netze). - Bei Firmwareversionen des Repeaters >= 1.14.0 kann man auch durch das Aktivieren von 2-byte Path ID Hashes die maximale Anzahl an flood hops minimieren (64/32/16). Befehl:
set path.hash.mode 10 für 1-byte, 1 für 2-byte, 2 für 3-byte lange Path ID Hashes.
2. (ERR_EVENT_CAD_TIMEOUT) – Kanal dauerhaft belegt
Dies bedeutet, dass das Modul senden möchte, der Frequenzkanal am aktuellen Standort aber ständig durch andere Signale belegt ist (andere Knoten, fremde Netze, oder Dauerstörer). Das Gerät wartet aus Höflichkeit, bricht den Sendeversuch aber irgendwann ab.
Maßnahmen zur Behebung:
- Passiert häufig, wenn die maximale "Airtime"/Duty Cycle erreicht ist. Befehl
set af 9- 10% duty cycle in einer Stunde ist der in Deutschland gesetzlich legale Wert!
- Eventuell den Standort des Repeaters wechseln oder einen Bandpass Filter für das 868MHz Band verwenden.
3. (ERR_EVENT_STARTRX_TIMEOUT) – Hardware/RX Timeout
Dies ist primär ein Hardware- oder Treiber-Problem beim Wechsel der Funk-Modi des Chips.
Maßnahmen zur Behebung:
- Stromversorgung prüfen: Solche Timeouts oder Abstürze im LoRa-Chip werden sehr häufig durch kurze Spannungseinbrüche (Voltage Dips) ausgelöst, besonders wenn der Knoten vorher mit hoher Leistung gesendet hat und dann in den RX-Modus zurückkehrt. Ein hochwertiges Kabel oder Akku schafft meist Abhilfe.
- Sendeleistung reduzieren: Um das Netzteil bzw. den Akku zu entlasten, kannst du versuchen, die TX-Leistung (TX Power) etwas zu drosseln. Befehl: set tx
- Firmware-Updates nutzen: Dies kann auch durch minimale Timing-Bugs im Firmware-Treiber (z. B. beim SX1262 Chip) passieren. Es hilft oft, die MeshCore-Firmware auf dem aktuellsten Stand zu halten.
Oft hängen Fehler 1 und 2 direkt zusammen: Wenn der Kanal immer belegt ist (CAD Timeout), läuft kurz darauf auch unweigerlich die Warteschlange (Queue Full) voll, da nichts mehr gesendet werden kann. Der Fokus sollte in diesem Fall auf der Beseitigung der Kanalbelegung liegen.