Fixing Our Congestion Problem

A proposal for dual-frequency backhaul using existing MeshCore features

TL;DR

Our summit repeaters hear every node in the mesh and are choking. The fix: move summit nodes to a second frequency so they only talk to each other, and add a few dual-radio "bridge" nodes to connect the two layers. No changes for most operators. MeshCore's serial bridge handles all the routing. The bridge nodes require custom firmware builds with bridge support enabled — the official builds don't include it. We can pilot it with one summit and one bridge node to prove it works before asking anyone else to change anything.

The Problem We're All Feeling

If you've been on the mesh lately, you've probably noticed: messages are getting dropped, delivery is unreliable, and the network feels sluggish even when your local nodes seem fine. This isn't a hardware problem and it isn't bad firmware. It's a physics and topology problem — and it's going to keep getting worse as we add more nodes.

The summit nodes are victims of their own success

Our high-altitude repeaters have incredible coverage — they can see nearly every node in the region. But that's exactly the problem. On a single shared frequency, they hear everything: every companion ping, every relay hop, every ACK from every node. LoRa's low data rate means the channel fills up fast. The summit nodes — the very backbone of our mesh — are the first nodes to drown. The better our coverage gets, the worse this becomes.

This is not a new problem in mesh networking. It's well understood: when a node can hear too many peers, the shared channel becomes unusable. The standard solution is hierarchy — splitting the backbone from the local mesh so they don't compete for the same airtime. That's what this proposal does.

The Data

This isn't hypothetical. Here's what our observer nodes are reporting right now (24-hour averages):

HAYSTACK (summit)

28%

PEAK RX UTILIZATION

16.15% avg

982 packets / 20 min
Sees Vancouver to Olympia

COUGAR (summit)

25%

PEAK RX UTILIZATION

12.53% avg

516 packets / 20 min
Sees Vancouver to Olympia

CISIEN STATION (local)

17%

PEAK RX UTILIZATION

7.28% avg

453 packets / 20 min
Moderate node, sees both summits

The averages are still manageable, but the peaks tell the real story. Both summit nodes are regularly spiking above 20% RX utilization — the rough threshold where LoRa collision rates start seriously degrading reliability. Haystack is hitting 28%. Every node we add to the mesh pushes those peaks higher. The averages will catch up eventually, but the damage is already happening during peak activity.

What's Happening Now (Single Frequency)

Every one of those lines is a transmission the summit node has to process. Every companion checking in, every local repeater relaying — the summit hears it all and can't keep up. And as we add more nodes (which is the whole point), it only gets worse.

The Proposal

Give the summit nodes their own frequency. Create a dedicated "backhaul" channel that only carries traffic between summit repeaters and a handful of designated bridge nodes. The local mesh stays on its current frequency, completely unchanged. A small number of dual-radio bridge nodes sit between the two layers and relay messages across.

The key insight: the summits don't need to hear every companion's ping — they just need to relay messages between distant parts of the mesh. By isolating them on their own channel, they go from hearing 12+ nodes to hearing 3–5. That's the difference between a usable backbone and a saturated one.

Proposed Architecture

12+ → 3–5nodes heard by summit
(current → proposed)

0changes needed for
companions & local repeaters

1bridge node needed
to pilot the concept

Who Needs To Do What

This is the most important part. The proposal is designed so that the vast majority of operators change nothing.

Companion Users

Change nothing. Your device works exactly as before. You won't even know the backhaul exists.

Local / Personal Repeater Operators

Change nothing. Same frequency, same firmware, same config. Your local coverage continues as-is, but with less congestion.

Summit Repeater Operators

Frequency change only. Update to the backhaul frequency. Same hardware, same firmware. Your node goes from overwhelmed to actually useful.

Bridge Node Volunteers

New build required. Two radios linked via RS-232. Needs a few volunteers at mid-altitude sites with summit line-of-sight. This is the only new hardware.

Bridge Node Detail

A bridge node is two MeshCore radios connected by a serial cable. MeshCore supports serial bridging as a firmware feature, but the official builds do not include bridge support. We provide custom firmware builds with bridging enabled for multiple hardware targets. Any combination of NRF52 (RAK4631, RAK19003) or ESP32 (Heltec V3, T-Beam) boards works over RS-232. For solar-powered sites, dual RAK4631s are ideal due to the NRF52's low current draw.

How a Message Travels Cross-Region

A companion in Tacoma sends a message to someone in Everett. The message hops through the local mesh to a bridge, crosses the backhaul via Cougar and Haystack, comes back down through the eastern bridge, and reaches the recipient. The users on either end have no idea this is happening — it just works.

Anticipated Questions

"Doesn't this add complexity? We liked the flat mesh."

The flat mesh is what's causing the congestion. A flat topology works great when every node can only see a handful of peers. But when summit nodes can see everyone, flat becomes a liability. The hierarchy we're adding is minimal — one extra frequency and a few bridge nodes — and it's invisible to end users and local repeater operators. Think of it like adding an express lane to a highway: the local roads don't change.

"Won't the bridge nodes be single points of failure?"

If a bridge node goes down, that zone loses backhaul access — but the local mesh in that area keeps working for local traffic. And we can mitigate this with redundancy: two bridge nodes per zone, or ensuring adjacent zones' bridges have overlapping coverage. We also don't need to deploy the entire system at once — even a single bridge dramatically improves things for its zone.

"Does this require custom firmware?"

Yes — but we've done the work for you. MeshCore supports serial bridging as a firmware feature, but the official builds don't include it. We provide pre-built firmware with bridge support enabled for all common hardware targets. Flash it using the Custom Firmware option in the MeshCore Flasher. The summit nodes just need a frequency change in their config. No one needs to compile anything.

"I have a local repeater. Do I need to do anything?"

Nothing at all. Your node stays on the current frequency, same firmware, same config. You'll actually benefit from less congestion on the local channel once the summit nodes move off it.

"What about desense from two co-located radios on the bridge?"

This is a real consideration. With only ~1 MHz of separation between 910.525 and 911.45, the two radios on a bridge node will need physical antenna spacing — plan for 1–2 meters between antennas. Bridge node sites need enough room to mount two antennas with that separation. This is manageable on a rooftop, mast, or ridge site, but it does mean bridge placement needs a bit of planning. Bandpass filters can help further if needed.

"Why can't we just switch to a faster preset?"

Because this isn't a capacity problem — it's a collision problem. A faster preset means shorter time-on-air per packet, but the summit nodes are still hearing every transmission from every node on the same frequency. Collisions still happen at the same rate. Meanwhile, a faster preset lowers the link budget, which breaks marginal links that currently work, shrinks coverage for everyone, and requires a coordinated change across the entire mesh. We'd be trading real-world range for a speedup that doesn't address the root cause — and we'd still hit the same wall again as the mesh grows.

Proposed Pilot Plan

We don't need group consensus to change the entire mesh overnight. Here's a low-risk way to prove the concept with minimal disruption:

Phase 1 — Proof of Concept (1–2 volunteers)

Build one bridge node. Two MeshCore radios (any combo of RAK4631/Heltec/T-Beam) connected via RS-232, flashed with our custom bridge firmware and configured for serial bridging. Place it at a mid-altitude site with line-of-sight to a summit. See the Bridge Build Guide for detailed instructions.

Move one summit repeater to the backhaul frequency. The summit operator updates the frequency setting over the air. That summit now only hears the bridge node (and potentially other summits later).

Test. Send messages through the bridge and verify end-to-end delivery. Measure latency. Monitor the summit node's channel utilization — it should drop dramatically. Compare to the current congested state.

Share the results with the group. Real data from our own mesh is more convincing than any diagram. If it works, the path to full deployment becomes obvious. If it doesn't, we've learned something and only two nodes were involved.

Phase 2 — Expand (if Phase 1 succeeds)

Move remaining summit nodes to the backhaul frequency one at a time.

Add bridge nodes to additional zones as volunteers come forward. Prioritize areas with poor cross-region connectivity.

Add redundant bridges where needed, so no single zone depends on a single bridge for backhaul access.

The mesh is growing, and that's a good thing. But we've hit the ceiling of what a flat, single-frequency topology can support with high-altitude repeaters in the mix. This proposal fixes the bottleneck using tools we already have — MeshCore's native serial bridge, off-the-shelf hardware, and a second frequency. Most operators won't even notice the change. The ones who do will see their summit nodes go from useless to useful.

Let's test it with one summit and one bridge. If the data backs it up, we roll it out. If not, we're only out one afternoon of tinkering.

An expansion of an idea by lother, N7JMV, and Cisien — polished with the help of AI.