Every Meshtastic forum eventually produces the same thread: “My network worked great with 10 nodes. Then I added more and everything got worse.” The replies are always the same — reduce rebroadcast rate, increase hop limit, try a different frequency. None of it fully solves the problem.

That’s because the problem isn’t configuration. It’s math. And once you understand the math, you realize Meshtastic is doing exactly what it was designed to do — it just wasn’t designed for dense networks.

The Protocol Behind the Problem: Flooding Mesh

Meshtastic uses a flooding broadcast protocol. When a node transmits, every node that hears it rebroadcasts the message (minus a rebroadcast factor to reduce collisions). This works beautifully for sparse networks — say, 5 to 15 nodes spread across miles of terrain where each node has limited neighbors.

But as you add nodes, something predictable happens. The channel gets busier. Nodes start colliding with each other. And LoRa — the radio layer Meshtastic runs on — has no collision detection. It’s ALOHA-style: you transmit and hope nothing else was transmitting at the same time.

The ALOHAnet Math

In 1970, Norman Abramson at the University of Hawaii published the original ALOHA protocol paper. His key finding: in a pure random-access channel, maximum throughput is approximately 18.4% of channel capacity. Slotted ALOHA improved that to 36.8%. But LoRa mesh doesn’t use slotted ALOHA — it uses a variant closer to pure ALOHA with carrier-sense added.

Here’s the throughput equation for pure ALOHA:

S = G × e-2G

Where S is normalized throughput and G is offered load. Maximum throughput S = 1/(2e) ≈ 0.184 at G = 0.5.

What this means in plain English: if your network is trying to use more than 50% of channel capacity, your actual throughput starts decreasing. At 100% offered load, your effective throughput drops below 5%. The network becomes self-defeating.

At What Node Count Does This Hit?

On a standard Meshtastic deployment running at SF9 / BW125 on 915 MHz:

  • Channel capacity: approximately 1,340 bits/second (airtime)
  • A typical Meshtastic packet: ~250ms airtime including preamble
  • Maximum sustainable transmissions: ~4 per second across the entire channel

Now add the flooding math. Each transmission triggers rebroadcasts. With a rebroadcast factor of 0.5, each original packet generates — on average — 0.5 additional broadcasts per hop. With 3 hops and 30 nodes, that single original packet can generate 15–20 total air-events.

Free · Field intelligence handbook

10-page PDF: faction breakdowns, zone strategy, mesh tech explained. Yours free.

At 50 nodes with moderate traffic, you can hit 100% offered load with just 4–5 simultaneous conversations.

That’s not a configuration problem. That’s the ceiling.

Why Adding “More” Doesn’t Help

The intuitive fix is to reduce the rebroadcast factor. Set it to 0.2 instead of 0.5. This reduces redundant rebroadcasts — but it also reduces coverage reliability. Nodes that were reachable via 2-hop paths now require 3 or 4 hops. Latency increases. Reliability drops.

You can tune the rebroadcast factor to optimize for either coverage or capacity — but you cannot optimize for both simultaneously on a flooding protocol. It’s a fundamental tradeoff baked into the design.

What a Coordinated Protocol Changes

The alternative to flooding is coordination. Instead of every node deciding independently when to transmit, a time-synchronized protocol assigns each node a dedicated transmission slot. No collisions. No flooding overhead. Deterministic delivery.

This is the approach GPS-TDMA takes. By using GPS pulse-per-second (PPS) signals to synchronize clocks across all nodes to sub-millisecond accuracy, you can divide the LoRa channel into time slots — each node transmits only in its assigned slot. Zero protocol-layer collisions, regardless of node count.

The math inverts: instead of throughput degrading as you add nodes, a properly designed TDMA system maintains near-100% channel efficiency up to the slot limit. A 32-slot frame can support 32 simultaneous nodes with guaranteed delivery and no coordination overhead.

The Real-World Implications

For hobbyist use, Meshtastic’s scaling ceiling doesn’t matter much. If you’re coordinating a camping trip with 8 friends, you’re nowhere near the wall. The protocol is excellent for what it does.

But for emergency response networks, defense applications, or any scenario requiring reliable communication in a dense node environment — the flooding math becomes a hard constraint. You need coordination, not just radio access.

I’ve been working on this problem for over a decade. The Tessera Mesh protocol is built specifically to bring GPS-TDMA coordination to LoRa-class hardware — giving you the range and low-power characteristics of Meshtastic-style radios with the collision-free throughput of a properly coordinated protocol.

The result: networks that scale beyond 50 nodes without the flooding penalty. Predictable. Deterministic. Built for operational environments where packet loss isn’t an option.

What Comes After Meshtastic?

Edge Orbital is building Tessera Mesh — a GPS-TDMA protocol designed specifically to solve the scalability problem. Zero protocol-layer collisions, deterministic timing, and a coordination layer that works at scale. If you are building for defense, emergency response, or autonomous systems, the investor data room is here.

Stay Ahead of the Mesh

Get technical deep-dives on GPS-TDMA, LoRa mesh, and edge communications — written for engineers and operators, not press releases.

Further Reading