MeshCore Repeater Deployment: Timing Considerations for Wide-Area Networks
By Eric Hendrickson
MeshCore repeaters are showing up everywhere these days and I am thrilled to see it happen. As folks place these repeater nodes on high-rise rooftops, hillsides, and on ham and commercial towers, they’re discovering that the key to smooth wide-area repeater behavior isn’t just about height or terrain—it sometimes comes down to timing. A MeshCore repeater forwards packets the same way regardless of its elevation or view of the horizon. What makes a difference is how well its timing settings match the size and shape of its coverage area.
The goal of this article is to help folks understand MeshCore’s four repeater timer settings. It is not my intent to promote settings changes where they are unwarranted. The old saying “if it ain’t broke, don’t fix it” comes to mind. But if your network is growing and you are starting to see unacceptable lag, dropped packets, or other issues, it may be time to consider adjusting timer values to create a tiered pacing strategy.
A small, tight cluster of nodes and a few repeaters in an isolated rural mesh or deep in a canyon will work great with the default short timing delays because packets mostly arrive with good signal strength and don’t have to travel far. A repeater with a wider or more uneven footprint, one that will be interacting with numerous other repeaters, or one that bridges two or more isolated meshes together over great distances could benefit from slightly longer timing, giving low-level repeaters an opportunity to deliver their packets before it jumps in from its perch-on-high and risks “talking over” them.
Careful waterfall analysis from multiple locations is one way to determine how well your repeaters are interacting with one another in terms of timing. Plain old user experience is another way to assess the effectiveness of your particular setup. See my related post for information on using MeshCore Trace Path to discover status of nearby nodes.
📡 Flood Networking on MeshCore’s Terms
MeshCore doesn’t use smart routing tables or directional logic. It relies on a controlled flood. When a repeater node receives a fresh packet, it forwards that packet exactly once—at a time determined by its timing parameters—and then never forwards it again. Every other repeater does the same thing, creating a smooth outward ripple as packets propagate across the mesh like waves on a pond.
A high-level repeater does not have special privileges in this process. It simply sits in a high-elevation location where it can reach more nodes. Its participation has influence on the overall flow of packets across a much wider area of the mesh so it needs to be courteous and respectful of this added responsibility and this is where timing comes in: A MeshCore repeater’s timing settings must be appropriate for the coverage area that it naturally serves in order to maintain smooth, collision-free outwardly expanding packet flow.
⏱️ The Four Timing Settings That Shape MeshCore Repeater Behavior
MeshCore exposes several timing parameters through its command line interface. Together, these control when a packet is forwarded, how long a node waits before transmitting, and how hop limits are enforced. Tuning these settings to match the repeater’s coverage area is what produces consistent, predictable behavior in a dense, wide-area MeshCore deployment.
1. txdelay: The Transmission Delay Window
When a repeater receives a packet it intends to forward, it calculates the LoRa time-on-air (ToA) and multiplies it by the txdelay1 factor. During that delay window, the repeater selects a random moment to transmit. This prevents multiple nodes from firing at the same time.
In a small, dense cluster of nodes, a low txdelay keeps the mesh fast and snappy. For a repeater covering a larger or more varied area, increasing txdelay gives weaker or slower paths a chance to deliver their packets before the high-level repeater steps in and risks talking over others, which could result in collisions and lost packets.
Best practice is shaping up to be a three-tiered system with the default 0.5 second value for local rooftop repeaters; 1 second for regional repeaters, say on a high-rise downtown; and 2 seconds for “backbone” repeaters that span great distances or bridge two or more disconnected networks.
2. rxdelay: SNR-Based Receive Staggering
rxdelay adds a slight delay based on the signal score of the incoming packet2.
Stronger signals get shorter delays; weaker signals get longer ones.
This helps prevent repeaters from immediately reacting to low-quality packets while still ensuring the stronger, more central paths flow first. It’s especially useful when coverage overlaps or when a repeater hears packets that arrive through multiple inconsistent or asymmetric paths. Increase this value to further delay the retransmission of weak signal packets so the stronger links can get in and get the job done.
3. af: The Airtime Factor
Although it isn’t usually part of repeater tuning, MeshCore also includes an optional setting called the airtime factor (af), which adjusts how long certain internal timing windows remain open3. This value doesn’t modify any of the underlying LoRa radio parameters—spreading factor, bandwidth, and coding rate remain exactly as configured at the hardware level. Instead, af acts as a multiplier inside MeshCore’s timing logic, stretching or shrinking the repeater’s pacing based on the calculated time-on-air of each packet.
In most deployments, the default value works perfectly well and never need to be changed, but it can be useful in a scenario where one repeater does a majority of the heaving lifting for a region. If this repeater is a heavily-loaded choke point on your mesh, a modest increase in its AF can help it keep up with packet flow.
4. flood.max: The Hop Limit (TTL)
Every time a packet is forwarded, its hop counter increments. flood.max4 defines how many hops it’s allowed to make. If the hop count is too high, the repeater simply ignores the packet.
This prevents runaway flood behavior and helps maintain a clean, predictable network flow.
🏔️ How MeshCore Repeater Timers Work Together in Real Deployments
Picture a rural area with a couple of repeaters and a handful of companion nodes spread out across the community. In this scenario, packets usually arrive fast and with good signal strength, so default timing values work great.
Now imagine a repeater placed higher up, maybe on a high-rise office building or a nearby mountain top. Given its location and elevation, this repeater has exceptional coverage: It can hear many other repeaters and dozens of companion nodes directly. Because of its enhanced view of the landscape, and its ability to talk over the other repeaters, some timing adjustments may be called for.
If this repeater fires too quickly, it risks overshadowing low-level repeaters that haven’t had a chance to forward their own packets yet. This “doubling” of the data transmission and resulting interference could render the packet unreadable. But if the high-level repeater waits an appropriate amount of time:
- Low-level personal rooftop neighborhood repeaters get to go first.
- Mid-level repeaters join in gracefully, half a second later.
- The mesh experiences fewer collisions.
- Odds of successful packet delivery improve.
This is exactly why timing settings should reflect the repeater’s actual coverage area, not an assumed or idealized one. Making those determinations is beyond the scope of this document and can only be done after careful analysis of your specific topology and geography using actual field measurements.
🛠️ When MeshCore Repeaters Look ‘Broken’ But Aren’t
Most repeater “issues” trace back to timing choices, not technical faults:
- Silent drops happen when hop counts exceed
flood.max. At default 64-hop setting, silent drops should not be an issue for a very long time. - Latency can occur when txdelay is intentionally set higher in wide coverage areas. It’s a balancing act and one that will require fine tuning over time.
- Odd repeat ordering comes from SNR-based staggering with rxdelay and is expected.
- Different AF values between nodes can create timing drift, resulting in packets that miss their “launch window” and get disqualified from forwarding. Keep these values in sync across your mesh. More on this later.
- Duplicate suppression can make it look like a repeater is not working properly.
Understanding how these changes affect MeshCore packet propagation and user experience is key to an effective wide-area network strategy. If your adjustments aren’t working or cause problems, go back to defaults and start over. Experimentation is how we learn. It’s how we gather the information we need for the next iteration of this program and it’s how we all get better at what we enjoy.
🔧 Practical Timer Tuning for Repeaters
A few small adjustments can completely transform how a repeater feels to its users and how well it gets along with other repeaters in your area.
Here’s how repeater operators can tune timing for real-world use:
- Keep short timing values for small, tight coverage zones.
- Increase
txdelayslightly when a repeater serves nodes that don’t necessarily hear each other very well, example a repeater that bridges two valleys. - Use
rxdelayto help with overlapping, inconsistent, or asymmetric signal paths. - Match
afsettings across the region for best coherence and dependability. - Keep
flood.maxat defaults unless your design specifically requires a short-range network.
A three-tiered approach is becoming best practice in densely-populated MeshCore areas. In this emerging standard, repeater timing is configured based on its role in the community:
- 0.5 seconds: Personal, balcony, residential rooftop, or mobile repeaters.
- 1.0 seconds: Good for overlapping repeaters placed on high-rise apartment and office buildings with good line-of-sight for a few miles.
- 2.0 seconds: Mountain-top or tower-height “backbone” repeaters that span wide areas and bridge multiple isolated meshes together.
🌄 Closing Thoughts
A well-tuned high-level MeshCore repeater cooperates in but does not dominate the mesh. It doesn’t rush to transmit. It waits just long enough to be helpful while avoiding on-air collisions that can have a negative impact on network performance and reliability.
When timing settings match a repeater’s true coverage area, the entire network benefits. Packets propagate outward in a smooth, predictable way, and the repeater does exactly what it should by extending the mesh in a cooperative manner. Footnotes link back to official MeshCore docs.
