MeshCore Learning

Managing Traffic and Congestion

As more stations and repeaters join a MeshCore network, flooded messages can occupy more airtime than necessary. Managing traffic keeps local messages local, reduces collisions, and leaves room for useful communication. The tools below work together; none of them requires removing stations that are actually helping.

Regions and Scopes

Regions remain the most direct way to limit how far flood traffic travels. When users set a region scope on a channel, only repeaters that have been configured with that exact region name will forward the message.

  • Operators configure regions on each repeater (see the Regions and Region Scopes lesson and the Tuning lesson).
  • Users set the scope in the companion app so their messages carry the intended region.
  • A tight local scope keeps neighborhood traffic from being rebroadcast across a wide area.
  • A broader scope can still be used when a message genuinely needs to travel farther.

Regions only reduce traffic when both operators and users participate. A repeater with carefully chosen regions does little good if most messages are sent without a scope.

Hop Limits

Flood packets can be limited by the maximum number of hops they are allowed to travel. A lower hop limit keeps messages from propagating farther than needed.

  • The command is typically set flood.max <number> (the exact range depends on firmware; common values are well below the maximum).
  • A modest limit (for example 8–16) is often enough for local and regional use while still allowing useful multi-hop paths.
  • Very high limits increase the chance that the same packet will be rebroadcast many times across a wide area.

Hop limits and regions complement each other. Regions decide which repeaters may forward a packet; hop limits decide how far it may go even among those repeaters.

TX and RX Timing

The delay settings covered in the Tuning lesson also help manage congestion. When many repeaters hear the same flood packet, randomized delays reduce the chance they all transmit at once.

  • Higher txdelay and direct.txdelay values on high-profile sites make them more likely to defer.
  • Lower values on local sites let them serve nearby users more quickly.
  • rxdelay can further stagger processing of weaker copies so stronger paths are preferred.

These settings do not reduce the amount of traffic, but they reduce collisions and improve the chance that useful packets are received.

Reducing Low-Value Repeaters

A cluster of low-profile repeaters that all rebroadcast the same flood packets can consume airtime without extending coverage. In these cases:

  • Identify which stations actually appear in useful paths (see the Monitoring and Troubleshooting lessons).
  • Tighten region settings on the least useful sites so they forward less traffic.
  • If a repeater still adds congestion without improving reliability, it is reasonable to relocate or remove it.

Fewer, better-placed repeaters with appropriate region and timing settings usually outperform a larger number of unrestricted stations.

Practical Steps for Operators and Users

Operators

  1. Configure each repeater with only the region names it should carry.
  2. Set hop limits and TX/RX delays appropriate to the site’s role.
  3. Monitor path traces and local reports for signs of congestion.
  4. Adjust or remove stations that add airtime without clear benefit.

Users

  1. Set a region scope on channels that are meant to stay local.
  2. Use a broader scope only when the message needs to reach a wider area.
  3. Avoid sending unnecessary flood traffic (for example, repeated tests) on wide scopes.

Congestion is usually the result of many small choices adding up. Consistent use of regions, reasonable hop limits, and selective repeater placement keeps the network usable as it grows.

Next: Keeping the Network Reliable

← Previous: Tuning Repeater Settings

Continue to: Keeping the Network Reliable →

Was this material helpful? Leave feedback or suggest a correction.