Hop-Limit Justification
Why hop limit 5, argued from a 10-minute RF capture: 100% of distinct nodes were within 4 hops, 95% of traffic within 5.
Question
Meshtastic allows a hop limit of 1–7. What value gives full practical reachability across the Boca Raton mesh without paying the airtime cost of an unnecessarily high limit? Every extra hop is re-broadcast by every node that hears the packet, so the limit is a direct trade between reach and network congestion.
We selected 5. This document is the evidence for that choice.
Method
A node (KYKM) was placed in listen mode for 10 minutes and every packet it received directly over RF was logged, with its hop_start (the origin’s configured limit) and hop_limit (the limit remaining when it reached us). The number of hops a packet actually traversed to reach the capture point is:
hops traversed = hop_start − hop_limitAll 22 received packets in the window carried an rx_snr value (they were demodulated off the air) and none were via_mqtt — this is a clean RF-only sample, not internet-relayed traffic. That distinction matters: MQTT-learned nodes tell you nothing about RF hop adequacy, so they are excluded by construction here.
Results
Sample: 22 RF packets, 15 distinct source nodes, SNR −14.2 to +11.5 dB.
Packets by hops traversed
| Hops traversed | Packets | Cumulative |
|---|---|---|
| 0 | 2 | 9% |
| 1 | 1 | 14% |
| 2 | 3 | 27% |
| 3 | 8 | 64% |
| 4 | 6 | 91% |
| 5 | 1 | 95% |
| 6 | 1 | 100% |
Distinct nodes by closest hop distance
Counting each node once, at the shortest hop distance it was heard:
| Reachable within | Nodes | % of nodes heard |
|---|---|---|
| ≤ 2 hops | 5 | 33% |
| ≤ 3 hops | 11 | 73% |
| ≤ 4 hops | 15 | 100% |
Every distinct node heard in the window was reachable within 4 hops. The 5- and 6-hop packets were later re-broadcasts of nodes already heard at a closer distance — not new nodes that required a high hop count.
⏳ Hop distribution chart — asset pending. The four-panel capture chart (
Hop-Distribution-2026-09-12.png) belongs here. Every figure it plots is in the two tables above.
Interpretation
-
Reach is achieved well within the limit. 95% of received traffic arrived within 5 hops, and 100% of the distinct nodes were reachable within 4. Hop 5 leaves headroom above the observed reachability floor.
-
The topology is not deep. Of the 22 packets, 12 originated from senders configured at hop_start 7 (the maximum) — yet they still reached us having used no more than 6 hops, and every distinct node within 4. Senders set high limits out of habit; the physical mesh around Boca simply is not 7 hops deep. A higher local limit would not reach more nodes — it would only add re-broadcasts.
-
The cost of going higher. At hop 7, every packet that currently dies at 5 would instead be rebroadcast two additional times by every node in earshot. In a dense corridor like South Florida (dozens of routers and bases audible here), that is a large, compounding airtime penalty for the ~5% of traffic beyond 5 hops — traffic that is largely duplicate re-broadcasts of already-heard nodes.
-
Why not lower (3 or 4). 4 hops covered 100% of distinct nodes in this window, but with zero margin. Real conditions vary — a node normally 3 hops away can become 4–5 when an intermediate relay is down or propagation shifts. Hop 5 provides one to two hops of margin over the observed worst case, which is prudent for reliable delivery without approaching the congestion cost of 6–7.
Conclusion: Hop 5 captures full practical reachability for this location (100% of nodes were within 4 hops, 95% of traffic within 5) while holding airtime well below what hop 6–7 would impose. It is the balance point between reach and congestion for the Boca Raton mesh.
Limitations (stated plainly)
- Single 10-minute window, n = 22 packets. This is a snapshot, not a census. It is consistent with hop 5 being correct; it does not by itself prove it across all conditions.
- One vantage point (KYKM). Reachability is measured from one location; a node elsewhere in the county would see a different — but analogously shallow — distribution.
- Time of day. Captured mid-afternoon. Evening mesh traffic is typically heavier and would exercise more of the hop range.
v2 plan
Strengthen the dataset with a full-weekday capture and/or a full-week capture, ideally from more than one vantage point (KYKM and the router KYKR), aggregating multiple windows to show the hop distribution is stable across time-of-day and load. v2 will restate the conclusion against that larger sample and quantify how often, if ever, traffic genuinely requires more than 5 hops.
Capture artifact: kykm_capture_2026-09-12.txt (raw Meshtastic listen log, 13:49–13:59 local, 12 SEP 2026). Retained as the primary evidence for this document.