The 900 MHz Band Fight: What's Actually Happening to Meshtastic's Spectrum

There's been real noise lately about the FCC and the 900 MHz band, the same band every Meshtastic radio on NEPAMesh transmits on. Some of it is serious. Some of it got tangled up with something else entirely on the way to Reddit. This post separates the two, explains each one in plain terms, and lays out what NEPAMesh is actually going to do about it. Standard disclaimer applies: nobody writing this is a lawyer, and nothing here is legal advice, shocking as that may be for a hobbyist radio blog to have to clarify. Read the actual regulations yourself before you bet your node on our summary of them.

Two different things are happening at once, and they get conflated constantly because they both involve the words "FCC" and "900 MHz."

1. A company called NextNav wants the FCC to carve up part of that band for a paid positioning network, which could crowd out or interfere with the unlicensed gear already living there. This is a real regulatory fight, still unresolved.
2. Separately, a lot of Meshtastic nodes, quite possibly including ones on this mesh, have been running a setting that doesn't meet an FCC bandwidth rule that's been on the books since 2002. This isn't a new rule. It's an old one the community only recently noticed.

Neither one means your node is about to get raided. Both are worth understanding.

Quick Primer: What's in the 900 MHz Band

The 902 to 928 MHz range is unlicensed spectrum, part of what the FCC calls the ISM band (industrial, scientific, and medical). Anyone can transmit there without a license, provided their equipment follows the technical rules for that band. It's shared by an odd mix of tenants: Meshtastic and other LoRa gear, Z-Wave smart home devices, RFID readers, some cordless phones, amateur radio on a secondary basis, and a federal licensing system called the Location and Monitoring Service (LMS) that predates all of it.

Meshtastic uses this band because unlicensed spectrum is free to use and LoRa's long range comes from very low data rates and wide-area propagation, both of which the 900 MHz band supports well. No license, no fee, no application. That's also exactly why it's contested territory: everybody wants a piece of spectrum nobody has to pay for.

Thing One: NextNav Wants a Slice of It

In April 2024, a company called NextNav filed a petition asking the FCC to reconfigure the lower half of the 900 MHz band. Their pitch: a 5G-based terrestrial positioning network that backs up GPS, built on a 5 MHz uplink carved from 902 to 907 MHz and a 10 MHz downlink carved from 918 to 928 MHz. The FCC opened a public comment docket on it that August.

The problem for Meshtastic, and for the RFID, Z-Wave, and Zigbee gear that share the band, is that NextNav's plan would hand priority and higher power to a licensed network sitting right in the middle of spectrum that unlicensed, low-power devices depend on. Meshtastic's project maintainers filed a formal opposition, arguing the change threatens community mesh networks, disaster-response communication, and equitable access to spectrum that doesn't require a subscription. They weren't alone. A coalition of roughly sixty businesses and trade groups, spanning retailers, utilities, security system makers, and freight companies, has also pushed back, and reporting from Location Business News says SpaceX has thrown its support behind NextNav's side of the fight.

As of this writing in September 2026, nothing has been decided. The FCC sent a draft Notice of Proposed Rulemaking for interagency review back in March 2026, which is a procedural step, not a ruling. No vote has been scheduled. This could still take years, or it could stall out entirely the way plenty of FCC petitions do. We'll keep watching the docket (WT Docket No. 24-240) and post here if that changes.

Thing Two: The Bandwidth Rule Nobody Was Following

This is the one that actually affects gear running today, and it has nothing to do with NextNav.

FCC rule 47 CFR 15.247(a)(2), in place since 2002, sets a minimum bandwidth for digitally modulated devices operating in the 900 MHz band: at least 500 kHz, measured 6 dB down from the peak. Here's the rule itself, straight from the current Code of Federal Regulations.

LongFast, the preset Meshtastic has shipped as its US default for years, runs a 250 kHz bandwidth. Half of what the rule requires. This wasn't a secret hidden in the fine print so much as a detail nobody in the community had cross-checked against the actual regulation until members of Philly Mesh did the math and wrote it up. Once that post made the rounds, it became clear that most of the standard Meshtastic presets people have been running for years share the same problem.

To be clear about what this is and isn't: it's not a new restriction, and nobody's LongFast node suddenly became illegal last month. The rule was already there. What changed is that people started reading it.

What Firmware Is Doing About It

Meshtastic's developers responded by changing the default. Starting with firmware 2.8, new US devices default to LongTurbo instead of LongFast on first setup. LongTurbo runs at the required 500 kHz bandwidth, at the cost of range compared to LongFast's wider spread. It's a real tradeoff, not a free fix: several regional mesh groups, Philly Mesh included, have reported that LongTurbo doesn't hold up over the same distances LongFast covered.

The wider community hasn't settled on one answer. Philly Mesh built a custom configuration they're calling MeshCore 500, tuned specifically to hit the 500 kHz floor while trying to claw back some of the performance LongTurbo gives up. It runs on MeshCore, a separate open-source mesh firmware project from Meshtastic, not a Meshtastic mode. A separate firmware proposal for a preset nicknamed LongModTurbo, aimed at the same goal, made it to GitHub but stalled and was closed as inactive. None of this is finished. Expect more churn here before it settles.

What About RNodes?

If you run Reticulum instead of, or alongside, Meshtastic, the same rule applies to you, and it's arguably a messier situation.

An RNode is the open-source LoRa radio hardware Reticulum uses to get onto the air, the same kind of device behind NEPAMesh's own Reticulum gateway. Unlike Meshtastic, Reticulum doesn't ship a small menu of named presets. Bandwidth, spreading factor, and coding rate are set by hand in a plain text config file, one interface at a time. There's no "LongFast" to quietly swap out from under everyone with a firmware update, because there's no shared default to begin with.

That cuts both ways. Nobody's going to push you onto a noncompliant setting without your knowledge, but nobody's going to fix it for you either. A lot of the example configurations floating around in Reticulum documentation and community write-ups use 125 kHz or 250 kHz bandwidth, the same range Meshtastic's old default sat in, because narrower bandwidth trades speed for range and that's what people are usually optimizing for. If your RNode is set up that way and it's operating in the 902-928 MHz band using digital modulation, it's sitting in the same spot as a LongFast Meshtastic node: outside what 15.247(a)(2) requires.

Frequency hopping RNode setups are a separate case with their own bandwidth rules under the same section, and worth checking against the regulation directly if that's what you're running. Either way, the fix looks the same as it does for Meshtastic: check your actual configured bandwidth against the 500 kHz floor, and don't assume a config you copied from a guide or a friend's node was written with this rule in mind.

What This Means for NEPAMesh

Practically, here's where we land on each one.

On NextNav: nothing to do yet. It's a multi-year regulatory process, not an emergency, and jumping to reconfigure anything now would be reacting to a proposal that may never take effect in its current form. We'll flag it here if the docket moves toward a real decision, and if the FCC reopens public comment, we'll post how to file one.

On the bandwidth rule: this one's real, and we don't think it's a decision to make quietly from behind a keyboard. NEPAMesh has a meeting scheduled for Sunday, September 13, at HackWorks in Luzerne to talk through the actual options for compliant presets, what we'd gain and lose with each one, and how we'd roll a change out across the mesh without stranding half the network on the way. HackWorks is a local makerspace, and this is an open discussion, not a closed-door vote. If you run a node, or you're just curious how this shakes out, come out and put in your comment. We'd rather land on a direction the community actually weighed in on than one three people decided on a Discord thread.

What You Can Actually Do This Week

• Show up. Saturday, September 13, at HackWorks in Luzerne. This is where the actual direction gets decided, and it's open to anyone running a node, not just the people who maintain infrastructure.
• Check what preset your own node is running. In the Meshtastic app: Settings, then Radio Configuration, then LoRa.
• If you're on a fresh install and it defaulted to LongTurbo, that's the compliant option; leave it unless a specific mesh group tells you otherwise.
• If you're on an older node still running LongFast, hold off on changing it alone. Switching your preset without the rest of the local mesh doing the same just disconnects you from everyone else; wait for a coordinated update announcement here or in the Discord.
• If you build or maintain a repeater node, keep an eye on this space. Infrastructure nodes are where the compliance question actually matters most, and where we'll need volunteers to help test alternate presets against real coverage.

Where to Watch This

For NextNav: the FCC's own docket page for WT Docket No. 24-240 is the primary source, though it's dense reading. Meshtastic's official blog post on the opposition filing is the easier version.

For the bandwidth question: Philly Mesh's write-up on MeshCore 500 is a good technical read if you want the details, Meshtastic's post on the LongTurbo default switch covers the firmware side, and the MeshCore GitHub repository is where that project's own compliant presets actually live.

We'll keep posting here as either thread moves. If you want to dig into the regulatory side yourself or help test presets locally, come find us in the Discord.

NEPAMesh is a community Meshtastic network covering Northeastern Pennsylvania's Wyoming Valley. Live map at map.nepamesh.com. Questions in the Discord.

Meshtastic is a registered trademark of Meshtastic LLC. No warranty is provided. Use at your own risk. This post is not endorsed by or affiliated with Meshtastic LLC.