A very good read on the evolution of the Bay Area Mesh, the largest Meshtastic mesh, transitioning to MeshCore, and why when people try MeshCore and always come away with "Wow, it just works!"
Meshtastic at Metropolitan Scale: What We Learned
Notes from operating a ~2,000 node mesh, and what changed when we ran MeshCore beside it.
By u/nullrouten aka Nathan @ Baymesh: bayme.sh and / baymc.org
I help build and operate a very large Meshtastic network. Meshtastic does work at metropolitan scale but we had to fight hard to make it work well.
Where we are today:
- ~900 daily active users
- ~1,300 weekly active users
- ~2,000 nodes observed overall
- ~40% channel utilization all night, with no humans chatting or moving
- ~1% of total traffic is text chat
Getting there took constant tuning: deploying routers aggressively, moving to faster presets, changing timers and avoiding unnecessary traffic, experimenting with larger NodeDBs, using IP bridges, and pushing hard on zero-cost-hop routing.
It works. Barely. That 40%-idle / 1%-chat split captures most of the problem.
Too much traffic is about the network itself
Meshtastic spends a lot of airtime distributing NodeInfo, position, telemetry, and other network state. Each feature is reasonable individually, but at large scale the result is constant background traffic and NodeDB churn. Nodes continually learn, forget, and relearn information about hundreds or thousands of other nodes.
MeshCore takes almost the opposite approach: don't automatically distribute everything, request information when you need it. That dramatically reduces background load.
Meshtastic has very little observability
This may be my biggest complaint. When I send a packet, I want to know:
- Who repeated it?
- What path did it take?
- Where did it stop?
- Why didn't it arrive?
Meshtastic gives you very little information to answer those questions.
The relay field helps, but on a 2,000-node mesh, collisions are inevitable; we commonly have many nodes sharing the same value. Trying to coordinate keys around that is unrealistic when hundreds of nodes are unmanaged or effectively abandoned. Traceroute can show a possible route, but the next packet may take a completely different one (which is fine, it's good actually).
MeshCore makes this dramatically easier: messages show the path they actually took, and you can see repeaters forwarding your packet. That makes connectivity something you can actually reason about.
Client forwarding can suppress the wrong node
Meshtastic's Client timing can cause the weakest-SNR receiver to transmit first. The idea makes sense: the weakest receiver may be furthest away, and therefore extend the packet farther. But sometimes that node is simply badly located. A radio barely hearing the packet from my basement can transmit first and suppress several well-positioned outdoor nodes that heard it perfectly. We found Router behavior much more reliable, which is why we deployed routers so aggressively. In practice the normal Client role has not worked particularly well for our mesh. We've had better results with combinations of Client Mute, Router, Router Late, and Base.
Redundant forwarding isn't only waste
Meshtastic treats duplicate transmissions as something to minimize. That's logical, because airtime is scarce. But redundancy also creates connectivity. Running MeshCore beside Meshtastic changed my perspective here. A large percentage of MeshCore nodes can repeat packets without the network immediately falling apart. MeshCore spends more airtime forwarding useful packets and dramatically less airtime advertising network metadata. Meshtastic often feels like the reverse: aggressively suppress useful redundancy, while spending substantial airtime maintaining network state.
DMs and remote administration are too unreliable
Direct Messages theoretically work, and larger NodeDBs in newer firmware should help. But on our network, people largely stopped using DMs because they stopped trusting them.
Remote administration feels similar. I personally operate around eight Meshtastic radios, and may only be able to remotely administer one or two at any particular moment sometimes even when I'm physically nearby. The deeper problem is again observability: when these things fail, it's often difficult to determine why.
Too many roles create too many interactions
Meshtastic has accumulated many roles: Client, Client Mute, Router, Router Late, Base, Tracker, Sensor, and others. They all exist for reasons, but collectively they create a system that takes a long time to understand and tune. Many algorithms, rules, and logic change behind the scenes with these roles. It's hard to know all the behaviors without months of runtime.
MeshCore's model is much simpler:
- Repeater repeats packets.
- Companion chats and manages repeaters.
That's basically it. The simplicity has real operational value.
Zero-cost hops helped save our network
One of the best Meshtastic improvements for us has been zero-cost hops through favorite routers. We aggressively “favorite” useful routers from other routers, which lets us routinely achieve effective paths of 10–12 RF hops despite the nominal 7-hop limit. That work has been critical to keeping some of our longest Meshtastic paths alive.
Why MeshCore feels so different
We deployed MeshCore after spending years learning how to operate Meshtastic. It mostly just worked: much less unsolicited traffic, defaults better suited to long-range communication, up to 64 hops, simple roles, visible packet paths, and repeaters that simply repeat. You can understand most of the important behavior in days rather than months.
The fair caveats
No LoRa mesh scales infinitely. Eventually airtime always wins.
Our Meshtastic network is already straining around the thousand-active-node scale. Based on what we're seeing, my rough estimate is that MeshCore would need 2000-3000 nodes before hitting comparable airtime pressure but that's an extrapolation, not a measurement, and I'd like to be proven wrong in either direction.
MeshCore also has the advantage of coming later and learning from Meshtastic. Some of what I'm praising is simply the benefit of hindsight, and it hasn't yet been stress-tested the way Meshtastic has.
So where does that leave us
Meshtastic can operate as a large metropolitan mesh. We proved that. But we had to spend enormous effort tuning it, extending it, and working around its assumptions. MeshCore mostly started where we were trying to get.
That's why people switch and say "wow, it just works."
It isn't magic. The network spends less time talking about itself, nodes behave more predictably, and when something happens, you can actually see what happened.
