From 293a8a9a84bfdade90c5b9f9b9453c0d20140dae Mon Sep 17 00:00:00 2001 From: Kyle Date: Wed, 29 Apr 2026 14:10:13 -0400 Subject: [PATCH] docs: add explanatory notes for txdelay, direct.txdelay, and rxdelay CLI commands --- docs/cli_commands.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/docs/cli_commands.md b/docs/cli_commands.md index fb698228ed..9a2c6fe699 100644 --- a/docs/cli_commands.md +++ b/docs/cli_commands.md @@ -490,6 +490,8 @@ This document provides an overview of CLI commands that can be sent to MeshCore **Default:** `0.5` +**Note:** When multiple nearby repeaters all hear the same flood packet, each waits a random amount of time before retransmitting to avoid simultaneous collisions. This factor scales the size of that random window. Higher values reduce collision risk at the cost of added latency. `0` disables the window entirely. + --- #### View or change the retransmit delay factor for direct traffic @@ -502,6 +504,8 @@ This document provides an overview of CLI commands that can be sent to MeshCore **Default:** `0.2` +**Note:** Same collision-avoidance random window as `txdelay`, but applied to direct (non-flood, routed) traffic. The default is lower because direct packets are addressed to a specific next hop, so far fewer nodes compete to retransmit them. + --- #### [Experimental] View or change the processing delay for received traffic @@ -514,6 +518,8 @@ This document provides an overview of CLI commands that can be sent to MeshCore **Default:** `0.0` +**Note:** When enabled, repeaters that received a flood packet with a weak signal are held in a delay queue before processing, while those that received it with a strong signal process it immediately. This gives strong-signal paths forwarding priority. By the time weak-signal nodes process their copy, the packet may have already propagated and will be suppressed as a duplicate, reducing redundant retransmissions. + --- #### View or change the duty cycle limit