If you’ve spent any time in places where other mesh nerds hang out, you’ve probably witnessed spontaneous arguments breaking out over whether or not the mesh network is illegal. This is not really a new issue, but all of a sudden it has reached a flashpoint. Without much explanation, the latest Meshtastic alpha now defaults to LongTurbo, a 500 kHz setting that is incompatible with the previous default of LongFast. Philly Mesh wrote a long post on their switchover to a 500 kHz bandwidth setting. And regional Discord servers including Colorado, Nebraska, the PNW, and probably many others, are having discussions about whether they should follow suit. Folks are worried these initiatives to move to different settings will fragment existing networks, and many people seem to be mad at the FCC. If this weren’t all happening online, I’m sure it would have escalated to fisticuffs by now.
I’m writing this post not because I want to rehash all the tedious legal arguments around this, but instead because I’d like to take a close look at the technical side of this discussion. What exactly does it mean when the FCC says “the 6 dB bandwidth must be at least 500 kHz”? Even if you know what “bandwidth” means, you might be surprised by some of the bench measurements I take later.
But I’m getting ahead of myself. Unfortunately, I do have to briefly rehash what’s been going on for the rest to make sense. If you’re Terminally Online like me, and already know the backstory, feel free to skip this next section. If you’re still scratching your head, read on.
Wait what? I’m not using enough bandwidth?
The brouhaha begins with this issue on the MeshCore GitHub posted on October 14th, 2025. I could have sworn I’d seen it discussed earlier than that, perhaps with regard to Meshtastic, but I cannot find the source. In any case, the reporter, cpacejo, points out that, according to FCC regulations, devices like MeshCore and Meshtastic are not using enough bandwidth. Quoting the GitHub issue:
The relevant regulation is 47 CFR 15.247(a)(2), which states:
Systems using digital modulation techniques may operate in the 902-928 MHz, 2400-2483.5 MHz, and 5725-5850 MHz bands. The minimum 6 dB bandwidth shall be at least 500 kHz.
So apparently the FCC wants “digital modulation" systems on the 915 MHz ISM band to use a minimum of 500 kHz of bandwidth. MeshCore’s US default uses the 62.5 kHz bandwidth setting and Meshtastic’s LongFast uses 250 kHz. It seems that both of these systems are out of compliance.
The more than 300 posts that follow are too tedious to recount in depth here. Some argue that the regulation doesn’t apply to MeshCore because it’s not a frequency hopping system. Others argue the mesh can’t function reliably at a higher bandwidth setting. Some think it must be a typo. Why would the FCC have a minimum bandwidth requirement? Surely less bandwidth is better? Some think these regulations can’t be understood by mere mortals, and all this armchair lawyering adds up to nothing more than hot air. Some posts are basically the GitHub equivalent of tagging “Fuck the FCC” across the bottom of an overpass. Unsurprisingly, many people excited about “off-grid communications” aren’t interested in the FCC’s opinion on their network.
I hope you’ll be relieved to hear that I don’t plan on offering my own personal manifesto about this. I think these regulations very likely apply to MeshCore and Meshtastic, mostly because Semtech, the company that makes LoRa chips, has published several application notes on how to ensure your LoRa system complies with these rules. While I agree armchair lawyering often gets things wrong, I trust that Semtech understands these regulations. But I’ll leave it at that. If you disagree, that’s fine. On to the technical bits!
What actually happens when you set the bandwidth on your radio?
The bandwidth setting on a LoRa radio roughly corresponds to how much of the spectrum your transmission takes up. If you’re transmitting on 910.250 MHz with a bandwidth of 500 kHz, then you can expect your transmissions to take up the space between 910.00 MHz and 910.500 MHz. In other words, it takes up 500 kHz (half a megahertz) of space centered at 910.250 MHz. Simple, right?
Well, like many technical topics, this is something that gets fuzzier the closer you look at it. I mean that literally: the transmission is fuzzy around the edges.
If you look at the transmission power of a signal on an actual radio, you won’t see some clean break at 910 MHz. It’s not like the transmission power is 0% below that threshold, and 100% above it. Instead you’ll see a gradual roll-off that extends down to the noise floor of your measurement device. Below is a capture I took on my spectrum analyzer of a Seeed Wio-SX1262 set to transmit at 500 kHz.
The horizontal axis is the frequency spectrum and the vertical axis is the measured power at that frequency. The Wio was set to 20 dBm transmit power, and, as expected, you can see the plateau is at 20 dBm. The middle of that plateau is at the frequency I set the device to: 908 MHz. So far, so good.
But what is the bandwidth of the transmission? Well, it depends (the engineer’s favorite answer)! Because it rolls off gradually, it’s not clear where we should say the transmission begins and ends. Maybe we measure to the noise floor, but that doesn’t actually make sense because the noise floor is often a property of the measurement device, not the radio you’re testing. To solve this problem, the FCC sets an arbitrary threshold, which they call the 6 dB bandwidth. This means the edges are defined as the point that’s 6 dB weaker than the measured transmit power. Since transmit power is measured to be 20 dBm, it’s the point where the signal falls below 14 dBm. This is sometimes abbreviated as -6 dBc, meaning “6 decibels below the carrier.”
And so we finally get our answer. The 6 dB bandwidth of this device, with these particular settings, is 636 kHz.
So, according to the FCC’s standards, the transmissions are actually much wider than 500 kHz (over 20% wider!). Since the FCC sets a minimum, this is a good thing. There’s some safety margin, and board-to-board manufacturing differences won’t cause some boards to be non-compliant. The FCC is happy, and the manufacturer is happy that the FCC is happy.
But it can also be a bad thing.
Living life on the edge
The edge of the ISM band, that is.
Suppose your regional mesh group hears about these concerns, and so they get to work finding a new frequency where they can set their bandwidth to 500 kHz. They do a survey of the band and notice something curious: the edges of the band are a ghost town. No one is transmitting there. Weird, but great for our mesh I guess.
So they start transmitting on 902.250 MHz. With 500 kHz of bandwidth, that will put them at 902 to 902.5 MHz, right at the bottom of the 902-928 MHz ISM band. Thing of beauty! Joy forever!
Except we just learned that there’s no sharp cutoff at the edges of the transmission. So some of that signal is going to be outside of the ISM band. How big of a problem is this?
The FCC has a regulation for this, too. Of course they do.
While the FCC does not place any restriction on any spurious emissions that occur within the 902 – 928 MHz band (such as adjacent or alternate channel power limits), any spurious emissions measured in any 100 kHz bandwidth outside of this band must be at least 20 dB below the level measured in a 100 kHz bandwidth within this band. If the conducted output power was measured using averaging techniques, this limit is tightened to 30 dB (ref: 15.247(d))1
That’s a mouthful, but the bottom line is that instead of a -6 dBc threshold, they set a much more stringent threshold for out-of-band emissions: -20 dBc (or -30 dBc depending on how you measure it). So all emissions outside of the band must be -20 dB below the carrier.2
Since the permitted emissions are even lower, the 20 dB bandwidth is going to be even wider.
How much wider? I measured this below.
The end result is around 746 kHz! That’s 50% wider than the 500 kHz setting. Our hapless local mesh group is now around 125 kHz outside of the ISM band. Now we know why the band edges are a demilitarized zone. An RF engineer deciding where to put their system is going to try to select a frequency with sufficient margin so this doesn’t happen.
Unfortunately, this exact thing appears to have happened to the Philly Mesh group, who set their MeshCore frequency to 902.250 MHz with 500 kHz bandwidth. It’s actually a huge bummer. They tried to do the right thing, and potentially ended up in a situation even more likely to get the FCC’s attention. I hope they can sort it out without too much trouble. And as I write this, the global MeshCore discord is also pointing out that the lower edge of the band is used by a lot of amateur radio repeaters, which are allowed to complain when unlicensed users interfere (Part 15 is at the bottom of the pecking order). Aye yai yai. It’s a minefield. I don’t blame anyone for falling into this trap.
And that’s not all
Let’s suppose that we still stay near the edge of the band, but this time we take all the -20 dBc bandwidth stuff into account. We do a bunch of measurements and determine the maximum -20 dBc bandwidth of any radio we use is 1 MHz, and so we set the center frequency to be 500 kHz, half that, from the edge of the band. We’re good this time, right? Right guys?
Well, the first question to ask is, “How do we know what frequency we’re transmitting on?” We know because the radio has an internal oscillator, just like a quartz clock, and it uses that as a frequency reference. But just like a quartz clock, it isn’t perfect. Sometimes it runs a bit fast, sometimes it runs a bit slow. So although we set the center frequency to account for the 20 dBc bandwidth, we forgot that the oscillator isn’t perfect. Aye yai yai.
Just how imperfect? The Semtech datasheet for the SX1262 recommends an oscillator with a drift of no more than 30 parts-per-million. A megahertz is a million hertz, so that means the oscillator might be off by up to 30 hertz per megahertz. And this is just Semtech’s recommendation. Heltec and RAK and Lilygo can use whatever oscillator they want. It might be considerably better, but also could be considerably worse.
At 900 MHz, that gives us 27 kHz of potential drift. So our hypothetical local mesh group might be taking 27 kHz excursions outside the ISM band even though they were careful to take actual bandwidth into account.
To be clear, this is probably a much smaller problem. But I mention it because I think it gives a fuller picture of how radios actually work. And yes, this means receivers have to be flexible when it comes to receiving signals, because transmitters aren’t perfect.
Ok, but this is insane
Yes.
“No mere mortal can be expected to understand this stuff,” you say.
Also, yes.
Part of the issue here is that this is not how these rules were intended to work. Here’s how they were supposed to work: Radio LLC, a manufacturer of fine radio products, wants to sell a newly designed radio. Before selling it, they take their radio to an independent lab and say: “We believe this radio conforms to Part 15 of the FCC regulations, when used with these specific settings.” The lab says, “Yeah ok, I’ve heard that before. For $10,000 we’ll test it and if you pass, we’ll write a nice report you can submit to the FCC.” They happily pass their test and the FCC gives them an “equipment authorization,” which proves they’re allowed to sell their radio. They then ship their radio to customers with the settings that the lab tested. The consumer who buys the radio doesn’t have to worry about FCC regulations at all. The radio is designed in such a way that the consumer can’t use it outside of the tested settings.
You can see the problem. This is not how the mesh hobby works. Hobbyists buy radios that are really development boards. They immediately remove any software the board shipped with and install Meshtastic or Meshcore. They then use whatever settings their local discord group says to use. Even if that dev board has a pretty FCC stamp and FCC ID, that dev board likely isn’t being used with the settings under which the board was tested and authorized under. So then someone creates an issue on GitHub that says “Uh guys are we sure this is legal?” and all hell breaks loose.
But wait a minute, those ham radio guys don’t have to deal with this. Yes! That’s the point of a ham radio license. Those guys are governed by Part 97 of the FCC regs, which is totally different, and they’re given much more leeway when it comes to experimentation. Part 97 lets you skip the $10,000 certification process as long as you pinky swear your homebrew radio doesn’t mess up the spectrum for others (note: actual regulations were condensed for brevity).
So where does this leave us? I’m not sure. Maybe mesh hobbyists do a good job of self-regulating and manage to not piss off the local utility company that also uses the ISM band, and the hobby continues to fly under the FCC’s radar.
Or maybe the FCC starts getting complaints and they go after… someone? I’m not sure who. Maybe they go after the popular online retailers that sell these boards knowing full well they aren’t being used within the FCC’s framework. Or maybe individual hobbyists start getting knocks on their door, and a guy with an FCC badge (is that a thing?) starts asking if there’s a 910.525 MHz transmitter on the property.
Anyway, life is a lesson in impermanence. Enjoy the mesh while it lasts, and try not to get fined by the FCC in the meantime. I hope it’s here for a while longer.
Semtech’s “AN1200.26 LoRa™ and FCC Part 15.247: Measurement Guidance.” https://semtech.my.salesforce.com/sfc/p/#E0000000JelG/a/2R000000HSPM/cSfcw9ia0aHKE7C1zJUfv7TS23FtdzkmBaZ545nraoY
If you wanted to nit-pick, you could argue that “dBc” and “the level measured in a 100 kHz bandwidth within this band” are not strictly speaking the same thing, but even my spectrum analyzer calls this dBc, so I’m going to try and not get too caught up in the minutia here.



This is well documented and explained, thank you for making this post. We are currently in the process of finding a new frequency to move onto after we fell into the trap you described. - Philly Mesher
The preset becoming a social agreement is the part that stayed with me. I recently wrote about homebuilt Meshtastic badges at a hacker conference: a lovely piece of hardware, but the shared settings are what turn a bag of separate gadgets into a conversation. Your measurements make me think an event's badge documentation should record the complete configuration and its version, not just say 'Meshtastic compatible'. Have you seen a good way for a local mesh to coordinate a settings change without splitting its users?