500 kHz Didn’t Break Our Mesh

What YYCmesh learned about frequency placement, infrastructure, and drawing conclusions from real-world LoRa networks

By Cully@KBOXLabs and Elliot “TARS” Renn

Satirical illustration representing a LoRa mesh protocol turf war — AI-generated satirical editorial illustration. Meshtastic® is a registered trademark of Meshtastic LLC. YYC Mesh is not affiliated with or endorsed by the Meshtastic project or MeshCore, and no sponsorship or endorsement is implied.

The LoRa mesh community appears to have stumbled into a turf war. A long-standing FCC rule has caused Meshtastic and MeshCore users to reconsider operation in the US 902–928 MHz band. Meshtastic moved its US default toward LongTurbo, a 500 kHz preset. Philadelphia tested LongTurbo, found it unreliable in its environment, and began moving infrastructure toward a custom 500 kHz MeshCore configuration. Hackaday summarized the dispute as “FCC ISM Rules May Shatter LoRa Mesh Communities.”

That framing combines questions that need to stay separate:

Are the old defaults compliant with US regulations?
Does a 500 kHz LoRa channel perform poorly in a busy city?
Does Meshtastic’s flooding model scale, and is MeshCore’s routing model better?
Where in the 902–928 MHz band should a regional mesh operate?

YYCmesh cannot settle all of them. Calgary is not Philadelphia, and we did not conduct a laboratory-controlled comparison. We can contribute a real-world result: a Meshtastic network operating at 500 kHz near the bottom of the band has communicated consistently across southern Alberta for months. That does not make our configuration universally better; it shows that “500 kHz Meshtastic does not work” is too broad a conclusion.

YYCmesh has more than 300 nodes visible on its public channel, but that is not the complete network. Additional nodes operate only on encrypted channels and are neither running on nor advertised through the main public channel. Visible node count is therefore not a complete measure of deployment, infrastructure, or RF activity.

What changed in the United States?

Nothing recently. 47 CFR §15.247(a)(2) has long said that digital-modulation systems in the 902–928 MHz band must have a minimum 6 dB bandwidth of 500 kHz. Meshtastic’s traditional LongFast configuration uses 250 kHz, while MeshCore’s traditional US default is narrower still.

What changed was the projects’ understanding of how the rule applies. Meshtastic has described LongTurbo becoming the US default in version 2.8 as an interim step, with a larger change planned for 3.0 to address remaining matters such as band-edge guard space. YYCmesh operates in Canada, where ISED—not the FCC—is the regulator. This is not legal advice or a compliance certification for any jurisdiction.

Philadelphia found a real problem

Philadelphia’s results should not be dismissed. Philly Mesh operates in a dense and difficult RF environment with hundreds of visible nodes, non-mesh interference, legacy devices, and relatively limited purpose-built infrastructure. Its MediumSlow and LongTurbo testing encountered firmware compatibility issues, inconsistent hardware behaviour, and significant interference. It concluded that 500 kHz Meshtastic did not provide the reliability it needed.

Its testing also revealed an important point: frequency placement matters. A 250 kHz LongFast experiment at 910.000 MHz performed substantially better than its original LongFast channel. Later, in moving toward MeshCore, Philly selected 902.250 MHz because measurements suggested that it avoided the worst local interference.

Setting	Philly MeshCore 500
Centre frequency	902.250 MHz
Bandwidth	500 kHz
Spreading factor	SF11
Coding rate	CR4/5

MeshCore’s message-prioritized routing and lower background traffic may offer genuine advantages there. But Philly’s unsuccessful Meshtastic test and successful MeshCore test changed both the protocol and spectral placement. That cannot isolate routing from frequency, configuration, or other differences. A true comparison would hold frequency, bandwidth, SF, coding rate, power, radio hardware, antennas, sites, and approximate traffic load constant.

YYC independently arrived at almost the same PHY

In October 2025, before the present controversy, YYCmesh submitted Meshtastic firmware issue #8214, proposing a preset for large, geographically distributed meshes:

Setting	Original YYC proposal
Centre frequency	902.6875 MHz
Bandwidth	500 kHz
Spreading factor	SF11
Coding rate	CR4/8

The goals were to retain SF11 for long links, reduce airtime with wider bandwidth, use stronger coding on marginal paths, leave saturated LongFast traffic, and operate away from the noisy centre of the band while remaining near familiar Meshtastic frequencies. The exact 902.6875 MHz setting came from the LongModerate configuration that formed our starting point. We noticed that operating low in the band appeared advantageous and retained that frequency while changing bandwidth and coding rate. Good engineering sometimes starts with a good hypothesis and sometimes with a useful existing setting; the important part is to test, observe, and remain willing to be wrong.

What YYC actually observed

Our evidence is operational and observational, not experimental proof. Before the change, regional communication was poor and unreliable. After moving to 902.6875 MHz, 500 kHz, SF11, CR4/8—and after substantial infrastructure and network work—the mesh became consistently usable and has remained so for months.

We cannot honestly attribute that change to frequency alone. Purpose-built nodes were installed at strong line-of-sight sites; placement and antennas improved; the community became more coordinated about settings and traffic; hop policy evolved; zero-hop forwarding became available; selected infrastructure nodes were later moved to Router_Late; and excess traffic sources were investigated and reduced where possible. Mesh performance is a system-level result.

A busy channel that remains useful

YYC is not succeeding because it has an empty channel. Some elevated infrastructure nodes have reported channel utilization approaching 40%, while their own transmitted airtime has remained low, with the highest observed value around 4%. Channel utilization represents detected activity—including Meshtastic, other LoRa, and non-Meshtastic RF energy—while airtime is the time an individual node transmits. High utilization combined with low node airtime suggests a busy environment without individual infrastructure nodes monopolizing it.

There is also substantial packet traffic on encrypted channels. Multi-hop traceroutes may take seconds or a couple of minutes depending on channel activity and hop count, but delayed routes generally complete. We are not claiming a measured packet-delivery ratio; we are saying that under meaningful channel activity, the network continues to deliver the service its users care about.

Good infrastructure without aggressive routers

YYC’s improvement did not come from filling the region with traditional priority routers. For most of this period, we had zero nodes assigned the traditional Router role; even elevated infrastructure nodes operated as Clients. Selected sites were moved to Router_Late only recently, after zero-hop forwarding created a useful reason to do so.

Put radios at genuinely useful line-of-sight locations.
Avoid the traditional Router role.
Let ordinary Clients handle nearby delivery first.
Use Router_Late selectively at high-value sites.
Use zero-hop behaviour to avoid unnecessary propagation.

A high site can provide an excellent RF path without insisting on rebroadcast priority. Physical topology—what a node hears—is separate from forwarding behaviour—how eagerly it repeats what it hears.

Moose Mountain went down, and the mesh stayed up

One prominent YYCmesh node was installed on Moose Mountain at roughly 8,000 feet, with line of sight to much of Calgary. When it went offline, we observed no major collapse in communication: flood routing found alternate paths and the wider network continued operating. This was not a controlled failover test, but it was a useful observation that the network behaved as a mesh rather than a hub-and-spoke system.

Experimental TAK users are doing real work

Several individuals are privately testing TAK traffic for experimental first-responder and search-and-rescue applications. Their experience has been strongly positive. These are experiments, not a formal public-safety deployment or an emergency-service endorsement. The observation matters because TAK is an application-level workload: these participants are conducting tests they could not otherwise perform while ordinary communication remains available to the wider mesh.

Frequency placement matters—but “as low as possible” is wrong

Calgary and Philadelphia show that a national default cannot know every local noise environment. A 500 kHz receiver centred at 908.750 MHz and one at 902.6875 MHz may encounter completely different interferers. However, moving downward is not an unlimited race toward 902.000 MHz.

Alex Beal’s measurements illustrate why: a nominal 500 kHz signal does not end perfectly 250 kHz either side of centre. On a Seeed Wio-SX1262, he measured approximately 636 kHz at 6 dB and 746 kHz at 20 dB. Those results are device- and setup-specific, not a specification for every board, amplifier, antenna, or power level.

902.250 − (0.746 ÷ 2) = 901.877 MHz

Using that 746 kHz example, Philly’s original 902.250 MHz centre would place its lower 20 dB edge below the nominal 902 MHz boundary. Applying the same example—not a compliance certification—to YYC’s centre produces:

902.6875 − (0.746 ÷ 2) = 902.3145 MHz

That leaves about 314.5 kHz before 902.000 MHz, and substantially more lower-edge guard even allowing for the example’s oscillator error. It does not prove every YYC device is compliant. Proper evaluation requires suitable test equipment and the applicable jurisdiction’s rules. It does suggest 902.6875 MHz is an interesting middle ground: a different interference environment without sitting directly against the lower edge.

Find the quietest suitable part of the band while preserving adequate guard space, respecting local spectrum users, and testing the actual hardware that will be deployed.

What YYC does—and does not—prove

A 500 kHz Meshtastic network can remain useful and operationally reliable when frequency placement, coding rate, line-of-sight infrastructure, node roles, hop policy, and traffic management are engineered together.

YYC does not prove that 902.6875 MHz is best everywhere, that frequency alone produced our improvement, that Meshtastic is always superior to MeshCore, that MeshCore would not do better on the same infrastructure, that our network has no congestion or packet loss, or that this configuration is regulatory certification. Nor does it mean Calgary’s results can be copied directly into another city. Likewise, Philadelphia’s experience does not prove that 500 kHz Meshtastic is broadly ineffective; it demonstrates that particular configurations performed poorly in its environment.

A better comparison

Survey the local spectrum with appropriate equipment.
Select a centre frequency with adequate upper- and lower-edge guard.
Check for local licensed and unlicensed users.
Use the same hardware, power, antennas, locations, and power systems.
Match bandwidth, SF, and coding rate.
Define comparable traffic loads and test periods.
Record delivery success, latency, hop count, retries, and observable channel activity.
Document firmware versions and node roles.
Change one major variable at a time where possible.
Report failures and limitations alongside successes.
Distinguish public nodes from encrypted or private-channel nodes.

Community networks rarely achieve laboratory control. Transparent observational evidence remains useful when it is labelled honestly.

This should not be a protocol turf war

MeshCore may ultimately suit Philadelphia, and Meshtastic may remain the best fit for Calgary’s current goals. Reticulum or another system may suit other applications.

That distinction is not a rivalry on the ground, either. YYCmesh has a friendly relationship with the Alberta MeshCore community, and members of both communities occasionally collaborate, compare observations, and help one another with infrastructure and RF questions. We may run different protocols, but we operate in the same spectrum, encounter many of the same engineering problems, and have far more to gain by comparing notes than by treating one another as competing teams.

The mistake is turning local engineering decisions into universal declarations—or treating software selection as team loyalty.

Regional communities are beginning to treat LoRa meshes as RF systems rather than interchangeable boxes running worldwide defaults: measuring local noise, selecting spectrum deliberately, installing useful infrastructure, managing traffic, planning migrations, and accepting that one city’s successful setting can fail in another.

YYCmesh did not solve every problem or generate a perfect dataset. We made practical changes, sometimes through deliberate reasoning and sometimes with a little Cully luck, and ended up with a network people can consistently use. That is not proof that our answer is the answer. It is proof that the conversation needs more than “LongTurbo bad, MeshCore good.”

We need better experiments—and quieter turf.