# Networking and Range FAQ # How many hops can a message travel? ## Meshtastic Hop Limits In Meshtastic, every packet is born with a "hop limit" - a countdown that decrements each time the packet is relayed by a node. When the hop limit reaches zero, the packet is dropped and not forwarded further. - **Default hop limit: 3** - The hop limit counts relay hops, so a default of 3 lets a message pass through up to 3 relay nodes between sender and receiver (sender → relay → relay → relay → receiver). - **Maximum configurable hop limit: 7** - Meshtastic enforces a hard cap of 7 to prevent runaway flooding - **Recommended range: 3-5** - 3 for most local networks; 4-5 for large geographic deployments; 7 only in special circumstances Configure in app: **Radio Config → LoRa → Hop Limit** or via CLI: `meshtastic --set lora.hop_limit 3` ## MeshCore Hop Behavior MeshCore uses path-based routing, where hop limits work differently. A route discovery (path discovery packet) flood uses its own hop limit; once a route is established, data packets are forwarded along the specific path. The practical maximum network diameter depends on how many repeaters are in the discovered path, bounded by the path discovery packet hop limit setting (default sufficient for most deployments). ## Why Not Set Hop Limit to Maximum? Higher hop limits mean more retransmissions, more airtime consumption, and greater risk of broadcast storms (loops where packets bounce indefinitely). On a small, sparse network, a higher hop limit lets messages travel farther. On a dense network with many relays, hop limit 7 can cause severe congestion. Start with the default (3) and only increase if users at the network edges report messages not arriving. ## Practical Distance Per Hop Each hop adds roughly 2-30 km of distance, depending heavily on terrain and antenna height. The figures below are rough field estimates, not specifications - actual per-hop and end-to-end distances vary widely with siting, and the high end of each range requires near-ideal, line-of-sight conditions. They are also best-case in another sense: every added hop lowers the end-to-end delivery probability (compounding packet loss and airtime), so the longer multi-hop ranges are achievable but not routine or reliable. Treat them as illustrative ceilings, not planning numbers:
Hop CountTypical Coverage (flat terrain with rooftop repeaters)
1 hop2-8 km from sender to first repeater (approximate, antenna/preset dependent)
3 hops10-40 km end-to-end (illustrative, environment-dependent)
5 hops20-80 km end-to-end (best-case, assumes strong links each hop)
7 hops40-150+ km end-to-end (exceptional best-case, requires mountain repeaters and ideal line-of-sight - not typical)
# Why do I see duplicate messages? ## Why Duplicates Happen Duplicate messages in Meshtastic are normal and expected - they are a feature of flood routing, not a bug. When a node receives a message, it rebroadcasts it. If you're within radio range of multiple nodes that each received and retransmitted the same message, you may receive that message 2-4 times. Meshtastic uses a packet ID deduplication window to suppress most duplicates at the firmware level - your phone typically doesn't show them all. When duplicates do appear in the app, it's usually because the deduplication window has been exceeded (the second copy arrived much later) or there's a routing issue. ## Common Causes of Excessive Duplicates - **Multiple nearby Router/Repeater nodes** - If 4 different routers can all hear the sender, all 4 will retransmit, and you receive 4 copies. This is expected flooding behavior. - **Very high hop limit** - Higher hop limits mean more retransmissions; more retransmissions from more paths means more copies arrive. - **Routing loop** - Rare but possible: Node A relays to B, B relays to C, C relays back to A. This can cause a packet to circulate until the hop counter reaches zero. Firmware prevents infinite loops via the hop counter, but you may see many copies during the loop's lifetime. - **Firmware bug** - Older firmware versions had deduplication issues. Ensure all nodes are on current firmware. ## What To Do A small number of duplicates (1-2 extra copies of busy-traffic messages) is normal in a well-functioning mesh. If you see 5+ copies consistently: - Check that no nodes are accidentally configured with very high hop limits (7) - Verify all nodes are on current firmware (deduplication has been improved over time) - Look for nodes sharing the same node ID. Node IDs are derived from a device's identity, so collisions are unusual, but they can occur if a node's NodeDB or keys were cloned onto a second device. Two devices presenting the same ID can confuse deduplication and routing. - Reduce hop limit slightly if the network is small and dense # What is channel utilization and why does it matter? ## What Channel Utilization Means Channel utilization is the percentage of time the LoRa radio channel is occupied by transmissions. It's displayed in the [Meshtastic app](https://wiki.meshamerica.com/books/hardware-guide/page/meshtastic-app) as a percentage (visible in the channel info or device telemetry). Think of it like a single-lane road. If utilization is 10%, there's plenty of room for everyone. At 25%, it's getting busy. Around 40-50%, there's constant congestion and collisions. At 80%+, the channel is saturated and very few packets get through. ## Why the 25% Threshold Matters Meshtastic's flood routing uses random backoff timing to reduce collisions - nodes wait a random short period before retransmitting a packet. At low utilization, these collisions are rare. The ~25% figure is a community rule of thumb (not a hard physical constant): around 25% utilization, rising collision probability starts to degrade throughput noticeably, and once you reach roughly 40-50% the network becomes largely unusable. ## What Drives High Channel Utilization In order of typical impact: 1. **Position broadcast interval too short** - The default fixed position broadcast interval is 15 minutes, but users can lower it, and with smart broadcast enabled a moving node can transmit as often as every 30 seconds (the smart-broadcast minimum). On a 100-node network with everyone broadcasting every 30 seconds, position traffic alone saturates the channel. Fix: set position broadcast to 5-30 minutes for fixed nodes, 1-5 minutes for mobile nodes. `meshtastic --set position.position_broadcast_secs 1800` 2. **Telemetry too frequent** - If many nodes broadcast device/environment telemetry at 5-minute intervals, the aggregate airtime adds up. Fix: set telemetry intervals to 15-30 minutes. 3. **Long-range preset with many nodes** - The Long Slow preset uses a high spreading factor, so each packet takes on the order of several seconds of airtime (the exact figure depends on payload size and bandwidth). With 50+ nodes, even moderate message rates saturate the channel. Fix: migrate to Medium Slow or Medium Fast, which cut airtime per packet substantially; note this trades some range for much lower airtime. 4. **High hop limits creating more retransmissions** - Total airtime for a packet scales with the number of nodes that actually rebroadcast it, so lowering the hop limit (for example from 5 to 3) reduces airtime by an amount that depends on how many relays would otherwise have re-transmitted, not a fixed percentage. 5. **Too many Router role nodes** - Every node set to ROUTER retransmits every packet it hears. In a dense area, CLIENT nodes should outnumber ROUTER nodes significantly. Fix: set personal handheld devices to CLIENT role, not ROUTER. ## Target Values for a Healthy Network
Channel UtilizationStatusAction
0-10%HealthyNone needed
10-25%ModerateMonitor; consider reducing position intervals
25-40%CongestedReduce intervals; consider faster preset
40%+SaturatedImmediate action needed: reduce broadcasts, change preset