Meshtastic Network Capacity and Congestion

Why LoRa airtime is finite, how flooding multiplies traffic and what public networks can do about it.

Meshtastic feels quiet because people send short messages, but the radio channel also carries node information, positions, telemetry, routing control, acknowledgements, retries and relayed copies. LoRa provides excellent range by transmitting slowly enough to be decoded at weak signal levels. That same property makes airtime the network’s scarce resource.

Capacity cannot be expressed as one universal number of nodes. It depends on preset, packet size, automatic intervals, hop limits, topology, collision domains, regulatory duty cycle and human behavior. A hundred mostly silent nodes may work better than twenty nodes broadcasting data every minute.

Airtime is the basic budget

While one packet occupies a frequency slot, another overlapping transmission may collide. A slower preset keeps the channel busy longer. Flooding multiplies one original packet into relay transmissions, and larger hop limits expose it to more of the network.

European EU_433 and EU_868 profiles also enforce a 10 percent rolling hourly duty-cycle limit in firmware by default. That legal transmitter limit is not a capacity target: a network can become unreliable long before every device reaches it.

Sources of background traffic

Position, device telemetry, environment telemetry and NodeInfo have independent schedules. MQTT downlink can inject internet-originated traffic. Neighbor information, range tests, traceroute, store-and-forward requests and third-party applications add more packets. A network operator must count all of them, not only chat messages.

Fixed nodes do not need moving-location behavior. Sensors rarely need minute-level public updates. Range-test transmitters should be disabled after testing.

Symptoms of congestion

Messages arrive late or inconsistently, acknowledgements fail, nodes appear and disappear, traceroutes vary wildly and local delivery worsens at busy times. Signal strength may remain excellent because the problem is contention rather than coverage.

One node can also reach its own duty-cycle limit and temporarily stop transmitting even while it continues receiving. Logs and channel-utilization metrics help distinguish this from a hardware failure.

The hidden-node problem

Two distant nodes may both reach a high relay but be unable to hear each other. They can transmit at the same time, causing collisions at the relay. Adding more elevated routers can enlarge collision domains and make this worse.

Topology therefore matters as much as node count. A clear backbone with restrained traffic can outperform a dense collection of privileged repeaters.

How to recover capacity

First lengthen unnecessary broadcast intervals and disable unused modules. Keep most devices as CLIENT and limit routers or repeaters to strategic sites. Retain maximum hops 3 unless measurements justify an exception. Prefer LONG_FAST for the public mesh; do not migrate to a slower preset in search of range without calculating the airtime cost.

Control MQTT downlink and avoid bridging large remote populations into local RF. Coordinate tests and events. If a separate high-volume application is necessary, give it a deliberately separate radio configuration rather than consuming the community channel.

Capacity planning checklist

Inventory nodes and roles.
Record preset, hop limit and rebroadcast mode.
List every enabled periodic module and interval.
Estimate which nodes share the same collision domain.
Observe utilization during peak hours.
Change one source of traffic at a time and compare delivery.

The goal is not zero utilization. It is enough quiet time that urgent and ordinary packets have a high probability of being heard and relayed.

Why node count is a poor capacity metric

A node powered off in a drawer contributes no traffic. A fixed sensor transmitting several metrics every minute can contribute hundreds of original packets per day, each potentially relayed. A mobile node using aggressive smart-position thresholds may change load with user movement. Count packet sources and relay domains rather than registrations.

The same network also behaves differently at night, during an event or after MQTT brings in remote traffic. Capacity assessment needs time-based observation.

A congestion-response procedure

Freeze nonessential configuration changes, record a baseline and identify the largest periodic sources. Disable test modules and MQTT downlink first. Increase automatic intervals, then review privileged roles and excessive hop limits. Make each change separately so its effect can be measured.

Do not immediately split the community across different presets or frequencies. Fragmentation removes shared reach and can hide the original problem. Use a separate radio layer only for a deliberately high-volume service with its own participants and plan.

How these settings work together

No setting should be evaluated in isolation. A slower preset increases packet airtime; a larger hop limit multiplies that airtime across more relays; frequent position and telemetry packets create a permanent load; and privileged repeaters can produce additional copies. Conversely, a well-sited node using ordinary CLIENT behavior may extend the mesh effectively without special privileges.

For a public deployment, document the complete profile and the reason for every exception. Test delivery in both directions, during quiet and busy periods, and retain a way to reverse remote changes. Revisit the profile as the network grows.

Related configuration guides

Official sources

Meshtastic firmware and documentation change over time. Confirm setting names, defaults and regional requirements in the current official documentation before changing live infrastructure.