Understanding Hop Count and Hop Limits
What Is a Hop?
A hop is a single radio transmission between two adjacent nodes. When a message originates at Node A and is received by Node B, that is one hop. If Node B re-transmits the message and Node C receives it, that is a second hop. Each re-transmission consumes airtime and contributes to channel congestion.
In a well-designed mesh, most messages should arrive in 1 - 3 hops. A message requiring 6 - 7 hops to reach its destination is a symptom of poor repeater placement (insufficient elevated infrastructure) or an oversized network diameter.
Hop Limits in Meshtastic
Meshtastic uses a hop limit field in the packet header to prevent infinite re-transmission loops. The default is 3 hops; the maximum configurable value is 7 hops.
Each time a node re-transmits a packet, it decrements the hop limit by 1. When the hop limit reaches 0, the packet is not forwarded further. This is analogous to the TTL (Time To Live) field in IP networking.
Hop limit | Maximum relay chain
-----------+-----------------------------------
1 | Source → 1 relay → Destination
2 | Source → 2 relays → Destination
3 | Source → 3 relays → Destination (default)
5 | Source → 5 relays → Destination
7 | Source → 7 relays → Destination (maximum)
Note: the hop limit counts the number of re-transmissions (relays), not the total number of nodes in the chain. A packet with hop limit 3 can traverse a chain of 4 nodes total (source + 3 relays) or equivalently pass through 3 intermediate nodes before reaching the destination.
Why Unlimited Hops Would Cause Broadcast Storms
Meshtastic uses flood routing: every relay node re-broadcasts every packet it receives. Without a hop limit, a packet could circulate indefinitely, with every node in the network repeatedly forwarding it. This creates a broadcast storm - a positive feedback loop where each re-broadcast triggers more re-broadcasts, rapidly consuming all available channel time and rendering the network unusable.
The hop limit is the primary mechanism preventing broadcast storms. Meshtastic also uses packet deduplication (comparing packet IDs to avoid re-forwarding a packet already seen), but the hop limit is the hard stop that bounds maximum path length.
Calculating Maximum Network Diameter from Hop Limit
With a hop limit of h, the maximum number of nodes in a relay chain is h + 1 (source node plus h relays). This means the maximum network "diameter" (the longest path between any two nodes) is h hops.
If each hop covers an average of 5 km in a suburban environment:
| Hop Limit | Max Path Length (5 km/hop) | Max Path Length (15 km/hop, rural) |
|---|---|---|
| 1 | 5 km | 15 km |
| 3 (default) | 15 km | 45 km |
| 5 | 25 km | 75 km |
| 7 (max) | 35 km | 105 km |
For a well-designed urban network with elevated repeaters, a hop limit of 3 should be sufficient. If your network spans a wide rural area with widely spaced repeaters, you may need hop limit 4 or 5. Increasing beyond 5 is rarely justified and noticeably increases channel congestion.
Meshtastic Flood Routing vs. MeshCore Path-Based Routing
Meshtastic: Flood Routing
In Meshtastic, every node with routing enabled (router role) re-broadcasts every packet it receives with a non-zero hop limit. The packet is sent once by each relay, regardless of whether a better path exists. This is simple and robust but inefficient: a 3-hop path in a dense network might result in dozens of redundant re-broadcasts from nodes along parallel paths.
Hop count behaviour: the hop limit is decremented at each relay. A packet leaving the source with hop limit 3 arrives at the destination (if 3 hops away) with hop limit 0. Packets consumed mid-network by deduplication still consumed their transmission slot on the channel.
MeshCore: Path-Based Routing
MeshCore maintains a routing table at each repeater node. When a message needs to be forwarded, the repeater consults its table and forwards to the specific next-hop node on the best-known path to the destination. This is closer to traditional layer-3 IP routing.
Hop count behaviour in MeshCore: the hop count field records how many hops have been traversed (an incrementing counter) rather than a decrementing TTL. This provides useful diagnostic information (you can see how many relays a received message used) but means the network relies on routing table correctness rather than TTL expiry to prevent loops. MeshCore uses sequence numbers and path validation to prevent routing loops.
For network planners: in a Meshtastic network, channel load scales directly with hop limit and network density - every node hears and potentially re-transmits every packet. In MeshCore, channel load is more predictable because only the nodes on the actual path forward a given packet.
When to Increase Hop Limit - and the Tradeoffs
Consider increasing the hop limit above the default of 3 when:
- Your network covers a geographically large area (50+ km diameter) with widely spaced repeaters where 3 hops cannot span the network
- A specific critical path (e.g., a remote outpost to the network core) is consistently failing to deliver messages
- Path analysis shows that known routes require 4 - 5 hops due to terrain
Do not increase hop limit as a first response to poor coverage. Poor coverage is a placement problem, not a hop limit problem. Adding hops to compensate for missing repeaters increases channel congestion for all users without solving the root cause.
The tradeoffs of increasing hop limit:
| Hop Limit | Network Reach | Channel Congestion | Typical Use Case |
|---|---|---|---|
| 1 | Very limited | Minimal | Dense urban, single repeater covers all clients |
| 3 (default) | Moderate | Low - moderate | Well-planned city mesh with elevated anchor repeaters |
| 5 | Large | Moderate - high | Regional mesh spanning multiple cities or large rural area |
| 7 (max) | Very large | High | Sparse wilderness mesh; use only when topology analysis confirms need |
No comments to display
No comments to display