Wer in einem dichten Mesh unterwegs ist, kennt das Problem: Zwei Knoten senden gleichzeitig, die Pakete kollidieren, Status-Abfragen laufen ins Leere. MeshCore hatte dafür bisher int.thresh, eine Interferenzerkennung auf Basis des RSSI-Werts – die galt aber schon länger als unzuverlässig und war im Code praktisch deaktiviert.
Die Entwickler nutzen stattdessen die Channel-Activity-Detection-Funktion, die in den LoRa-Chips selbst steckt. Der Transceiver korreliert aktiv auf LoRa-typische Chirp-Muster, und das in Bruchteilen einer Millisekunde. Erkennt er Aktivität, wartet der Knoten kurz ab, statt blind dazwischenzufunken. Der Gedanke ist pragmatisch: Wer ohnehin gleich sendet, kann vorher auch ein paar Millisekunden zuhören.
Gegenüber der bereits vorhandenen RX-Prüfung ist CAD deutlich schneller – die Interrupt-basierte Erkennung muss erst über mehrere Symbole hinweg auf eine Präambel einrasten, CAD schlägt schon nach ein bis zwei Symbolen an. Ein Haken bleibt: CAD sieht ausschließlich LoRa-Signale. WLAN und sonstige Störungen im Band bleiben unsichtbar.
Aktivierung
CAD ist ein eigener Schalter und lässt sich per CLI umschalten:
set cad onset cad off
Auf Repeatern, Room Servern und Sensor-Nodes ist die Funktion im Upstream standardmäßig aus, auf Companions dagegen aktiv. Eine Konfiguration über die App gibt es vorerst nicht. Wichtig: Die Backoff-Logik wirkt erst, wenn txdelay größer als 0 gesetzt ist.
Was die Feldtests zeigen
Die Rückmeldungen sind überwiegend positiv, aber differenziert. Bei kurzen Nachrichten und Kommandos ist der Gewinn deutlich – gleichzeitig gesendete Ein-Zeichen-DMs, die vorher fast 30 Sekunden brauchten oder ganz ausblieben, kommen mit CAD zuverlässig durch. Mehrere Betreiber exponierter Repeater berichten von spürbar weniger fehlgeschlagenen Status-Abfragen.
Bei langen Nachrichten kippt das Bild. Hier schlagen gleichzeitige Übertragungen weiterhin fehl – Ursache ist aber nicht CAD, sondern der fehlende Zufallsanteil in den Retry-Intervallen: Zwei kollidierende Knoten wiederholen in nahezu identischen Abständen und kollidieren erneut. In dichten SF7-Meshes mit viel Telemetrie-Rauschen fallen die Ergebnisse ebenfalls gemischt aus.
Bekannte Baustellen
An Hochstandorten mit Sicht auf viele Repeater meldet CAD faktisch dauerhaft „Kanal belegt". Dann greift ein fest hinterlegtes Zeitlimit von vier Sekunden, nach dem trotzdem gesendet wird – aus dem Timeout wird so das eigentliche Sendekriterium. Mehrere Beteiligte fordern, diesen Wert konfigurierbar zu machen, zumal viele Repeater nach einem Relay gleichzeitig ins Timeout laufen und dann geschlossen senden könnten.
Zudem läuft der Scan derzeit mit der RadioLib-Standardkonfiguration von zwei Symbolen. Das openHop-Projekt kalibriert bereits detPeak und detMin, um Fehlauslösungen zu reduzieren; ein Folge-PR für dynamische CAD-Empfindlichkeit ist offen.
Was das für uns bedeutet
Wer einen Repeater an exponierter Lage betreibt, sollte CAD nicht blind aktivieren, sondern beobachten: Steigt die Antwortquote, oder läuft der Knoten nur noch ins Vier-Sekunden-Timeout? Für Companions und Nodes an normalen Standorten in dichteren Bereichen des Netzes dürfte sich der Schalter dagegen lohnen. Erfahrungsberichte aus dem sächsischen Mesh sind ausdrücklich willkommen.
Quelle: meshcore-dev/MeshCore PR #1727, gemergt am 15. Juni 2026 in den Dev-Branch.