Meshcore on Philly Mesh

Meshcore 500 Changes

RightSizedAlpaca — Fri, 02 Oct 2026 00:00:01 +0000

(tl;dr - Based on Philly testing, in Philly for MeshCore (primary mesh) we will move to freq=919.500, bw=500, sf=10, cr=5. In Philly for Meshtastic (secondary mesh) we will stay on LongTurbo-0.)

Hey Philly Mesh nerds (affectionate),

We’ve been on MC500 for the past month, and the mesh itself has been working amazingly well with the community on board. It was a hurdle for many of us to get nodes flashed to new firmware, install new apps, learn new lingo, and just overall change everything. Change is hard, change is tiring, but y’all have also made change fun. So thank you for that.

We have gotten a LOT of outside-of-the-mesh feedback on our change as well. There is a raging debate as to whether the previous 62.5 kHz (MeshCore) or 250 kHz (Meshtastic) settings are actually non-compliant (we’re not lawyers but we think they are), whether the FCC will enforce the regs (still doesn’t change the non-compliance), whether we should care (we do), and whether the changes are good for the nationwide mesh (we don’t know, our work and decisions were focused on Philly alone).

Our 9/4/2026 post and proposed change was for the local PhillyMesh community, and we didn’t expect people to think we were trying to propose a new nationwide standard. We still believe one default frequency for everyone in the US on MeshCore at the 500 kHz bandwidth isn’t feasible (more about that below), but we love folks from all over the country popping in to discuss what we’ve found on Discord.

There are two very important points that have been brought up to us that are significant and need to be addressed. In our initial rush to become FCC compliant, we missed the mark, and because of that, we will have to move frequencies one more time. Additionally, we made a region-wide recommendation on a timeline that left no room to hear objections from the community, or from each other. We should have asked first, and we’d likely have caught some of this if we had.

Issue 1: We’re Not Alone eerie alien static

Okay, so we don’t share the airwaves with extraterrestrials (that we know of) but we do share them with Amateur Radio Operators, affectionately known as hams. The 902-928 ISM Band that we’ve been using for Meshtastic and MeshCore is also known as the 33cm Amateur Radio Band. We knew this when we picked the new frequency and we listened and listened and we heard no one using the frequency we picked for MC500. BUT, we have since learned, the frequency we picked is where hams do “weak signal work” aka the worst possible place for us to add interference. It’s also in conflict with a repeater uplink frequency that – while infrequently used in the Philly area – is rude of us to knowingly interfere with now that we know it’s there. The hams in OpsDiv also had a misunderstanding of prioritization of the band: we thought Amateur Radio and unlicensed mesh activities were both secondary on the ISM band, when in fact Amateur Radio is secondary and unlicensed activity is last priority.

We messed this up in our original frequency pick, but we’ve put a lot more work and outreach into the new choice, and we’ve reached out to other ham clubs that operate in 33cm (and everywhere else) for better coordination with our new frequency selection. We’re also getting their input to make sure there aren’t any other *Rumsfeld voice* “unknown unknowns” since none of the hams in PRM OpsDiv regularly work the 33cm band.

Issue 2: Our Radios Are Dirtier Than a PHL Terminal E Restroom

This one caught us off guard, pun intended. There is a great writeup here that describes the issue (and our folly) nicely and fairly.

We had assumed that the channelization of Meshtastic meant that operating within those channels on devices that are FCC approved was safe and legal. Kinda like when you get a walkie talkie (aka FRS radio) and it’s got channels 1 through 14, you can operate on channel 1 without issue.

We improperly put that trust in the firmware and we have since learned that the hardware has been found in testing to NOT be clean enough to run like this. Some radios aren’t too dirty, some are very dirty. This means Meshtastic Frequency Slot 1 and 2 (or just Slot 1 on LongTurbo) is transmitting outside of the 902-928 ISM Band on some radios, which is against FCC regs. So yeah, we assumed using MeshCore at these same frequencies was okay but we messed this up too and we apologize.

This is a problem we knew ham radios have, but they’re blasting 20, 100, 1500W of output power on an antenna not perfectly tuned for the frequency. We didn’t know, say, a teeeeeny tiny lil’ Seeed Xiao radio outputting 0.125W on a perfect SWR antenna also has this problem. And it’s exacerbated by the wider bandwidth we’re using. So yeah, we moved to 902.250 to be complaint (compared to previous bandwidth settings) and yet even after that some radios are still on the edge of non-compliance.

What We’re Doing About It

As described in Issue #1, we’ve already reached out to more ham clubs. We had already received input from GCARC, but now we’ve reached out to the clubs that operate the 33cm band repeaters in Philly too with not a lot of response back. If you’re operating or using a 33cm repeater - and reading this and you’ve got input, send us an email at hello@phillymesh.net or join our Discord to chat. Regardless, to proactively avoid interfering with 33cm usage, the best spot in the band plan is middle-ish of the 902-928 ISM Band (which also fixes Issue #2 because we’re far away from the band edge).

In the Philly area, we have spent a LOT of time this past month listening to SDRs, comparing where interference is bad in the Philly area vs where it isn’t, and then putting those observations into action by trying a few of the promising spots. Many of the potential “national presets” being discussed, including using the existing 910.525 at 500 kHz bandwidth, have been proven by our testing to NOT work well in the Philly area.

After our testing, we have a few changes that we will be making for where/how we operate our mesh going forward.

Frequency: Based on the issues with being on the band edge and in the weak-signal-work zone of the 902-928 ISM Band, we looked for a spot in the middle of the 902-928 ISM Band and we have landed on 919.500 MHz for a center frequency. We have confirmed that there are no listed conflicts with hams at this specific spot via RepeaterBook and the ham clubs we’re in contact with. Again if there is something we missed, PLEASE reach out to us.
Spreading Factor: Also abbreviated to SF, this is a parameter that describes how a LoRa transmission encodes its signal over time. High number SFs mean that the chirp signal is spread over a longer duration, so the data rate is lower but can travel farther. Lower number SFs mean the signal is compressed into a shorter duration, so the data rate is higher but it typically results in shorter ranges.
- Our assumption when moving to 500 kHz bandwidth (and corroborated by some of the MeshCore and Meshtastic blogs) was that we would have to use SF11 for links to survive the wider bandwidth (which impacts range) as well as the higher interference. Basically “talk slower to be better understood”
- That assumption was proven incorrect based on our testing. Faster SF10 (instead of slower SF11) has shown to work best with our settings. Our theory is that the longer SF11 transmit time means that there is more likelihood that the packet will get interfered with by 902-928 ISM Band noise. Finishing the transmission quicker using SF10 means less opportunity for random 902-928 ISM Band noise to interfere. This is a balance because moving even lower in SF does indeed degrade link quality. This balance is something we’re going to continue to monitor and OpsDiv may prescribe additional testing in the future. For now we believe we’ve struck the right balance for the mesh we have now with SF10.
- A nice upside of this SF pick is that it is noticeably faster and “snappier” for the end-user to manage repeaters over LoRa.
Hashtag Channels: To help keep the future mesh’s conversations and messages organized, we are asking all MeshCore users to make a behavior change from the previous Meshtastic “post everything on LongFast”. MeshCore lets you add “hashtag” channels, aka you don’t need a PSK like in Meshtastic.
- Public - This is the default channel that is pre-setup (you don’t need to add this). Also the one most likely to be used by neighboring meshes once we interconnect.
- #prm - Please add this one and use it as the main channel to talk within the Philly metro area. The mindset here is if neighboring meshes use the same MeshCore preset/settings, the Public channel may get busy with wide-area traffic and may inhibit some of the great local conversations we had when testing a Philly-only mesh.
- #test - For the “Can you hear me now?” that inevitably comes with setting up a new node, traveling, etc. Quarantining it in a separate channel prevents those tests from distracting the #prm conversations, as well as letting you spam “CENTRAL JERSEY ACK” as many times as you want. There are also bots setup in several places in the mesh to auto-respond to messages in this channel. In other words, please do not type “testing”, “test 123”, “can anyone hear me?”, etc into either Public or #prm. This also allows folks to setup per-channel notification settings and mute this channel.
- Other commonly used (but totally optional) hashtag channels are listed in this pinned post on the Discord here.
MeshCore vs Meshtastic: We’ve fielded a lot of questions about our plans for Meshtastic going forward. “Are you abandoning Meshtastic?” “What if I want to keep using Meshtastic?” We’ll try to answer them below:
- We are shifting to a MeshCore = Primary Network … Meshtastic = Secondary Network strategy due to MeshCore’s “messaging first” basis and Meshtastic’s LongTurbo challenges we experienced during testing. We are not abandoning Meshtastic.
- We will continue to support Meshtastic on dual-radio infrastructure nodes as we can (especially going forward).
- We will only use Meshtastic on its LongTurbo default FreqSlot of 0. We have no plans of doing a similar frequency search for something non-default. Nor will we support presets that are not FCC-compliant on our infrastructure.
- Many of us will continue running both MeshCore and Meshtastic in our home setups. We encourage others to as well, each has its pros/cons and uses!
- Our previous stance against the “us versus them” tribalism some communities exhibited will continue to be the policy of PhillyMesh. We think both protocols have different use cases and understand how different people could gravitate towards one or the other. Just because we chose MeshCore as our primary network does not mean we will “peer pressure” folks to move from Meshtastic if they don’t want to. If you want to use Meshtastic, please do! And you’ll continue to get our same help and support to set up and run your node.

We will be moving the mesh to these new settings first thing on Friday 10/2/26. We are all incredibly appreciative for the mesh community’s help with all of the SDR inputs/listening, testing, and feedback this past month. We are all looking forward to moving to a home that works for the entire community (including non-mesh stakeholders like ham 33cm band users) and shifting our focus to infrastructure buildout to continue making Philly Mesh more reliable and connected for all in the area.

How We Determined Our New Frequency/Settings

A quick summary of Philly’s methodology is below:

RTL-SDR data collection across region
Data analysis for lowest noise floors
Automated Lora packet delivery testing
Validation of results with hands-on SDR monitoring to select final proposed frequency
Mesh-wide test of new settings with end-users

1) RTL-SDR data collection

In the MeshCore Discord, some of our members and others from outside started trying to find ways to collect data, locally and even on a larger scale. We knew it wouldn’t be perfect, and we knew others would have opinions on better methods, now and in the future. But we had to start SOMEWHERE with a unified data set. One of the ways we did that was with a scripted version of RTL_POWER, something that can be run with a cheap RPi and RTL-SDR dongle.

rtl_power -f 902M:928M:5k -i 5 -e 30m -g 32
902M:928M Scan the entire 902-928 MHz band
5k Target roughly 5 kHz frequency-bin resolution
-i 5 Complete/report a sweep every 5 seconds
-e 30m Keep collecting for 30 minutes
-g 32 Fixed RTL-SDR gain of 32 dB

The downside to lots of collections across multiple regions, was that the larger meshcore community went from not enough data, to waaaaaaaaaaaaay too much data, and everyone had different opinions on how to wrangle it.

2) Data analysis for lowest noise floors

For PhillyMesh, after going crazy looking at the data specific to our region every which way, we decided to combine a lot of our previous methods. We took a top-down approach, using the simplest tools already at our members’ disposal and trying not to over complicate or re-invent things that were already accessible. With so much information, it’s easy to get overwhelmed.

We took all the RTL_POWER data and looked for the regions with the lowest noise floors in general. And then manually scoped them with our SDRs and tossed any false positives from compression/artifacts/skewed data. (Another flaw we later found in the data collection method, thanks again to the great post by Alex Beal describing this in further detail.)

Our next step was to have people spread out across the region manually look at their SDRs in the three areas with the lowest noise floors identified above. The goal was to try and find region-wide low-interference spots we have here in Philly.

3) Automated Lora packet delivery testing

After we distilled it down to 3-4 top areas, we ran a custom packet test script based on the awesome concept from cisien on the MeshCore discord, tweaked to match our Pi-based infrastructure, using two nodes that had line of sight: one at our worst location (in terms of interference) and our best.

At its core, the script automated the testing of small, medium, and large packets between the two sites. The two devices linked via TCP so they knew when to start, when to expect packets, etc. The script fired off 20 packets of each size from one site to another and then recorded how many LoRa packets arrived successfully, which ones produced CRC/header errors, and how many were missed. Obviously, you want the best delivery rate with zero errors and misses, but everything is relative.

The custom script loaded a CSV with frequencies and SFs to test. At first it was just general areas on the 902-928 ISM Band, then slowly it was dialed in to slide the centers around slightly. Every test began with testing our current 902.25 MHz frequency, so you were always comparing apples to apples in terms of general interference/conditions and propagation. The idea behind it was sometimes RF sucks, weather sucks, interference sucks, but if we always started with what we were on NOW and were messaging successfully with, you always knew how to stack the others against it.

4) Validation of results with hands-on SDR monitoring to select final proposed frequency

Our top pick that came out of all of that was 919.5 MHz. It had the best symmetry on RX/TX between the two sites that were 7 miles apart (one of our longer links), and that was traversing a region we know has heavy interference due to known RFID sources. The idea being if it can work passing through that RF hellscape, it should probably be pretty damn good in areas without it.

One thing to note: we also had members check for Philly-specific conflicts with repeater inputs/output and coordinated systems, and talked to our local ARCs (Amateur Radio Clubs) about our proposed new settings. We want to make sure we’re good neighbors on the airwaves and not knowingly (or unknowingly) causing interference.

5) Mesh-wide test of new settings with end-users

But at the end of the day, theoretical picture-perfect packets and delivery rates mean little, compared to the metric of “can an end user message, and be heard”? So it came down to actually testing with real nodes and people.

After some quick checking to ensure the data lined up with reality between 3 devices over the long link, we shared the available options with the community for larger scale testing, one frequency at a time. For each test, a meaningful number of nodes changed their repeater settings for hours at a time to test if they could message each other as they could before on 902.250. Use of the PhillyMesh CoreScope aided greatly in users being able to see the reach of their messages during these tests and what messages they may be missing.

Our awesome community members jumped in and really did an amazing job putting them all through their paces. In the end, the top pick across the data held true. 919.5 MHz SF10 was the best candidate for our real-world mesh testing and communications.

FCC Regulations and MeshCore 500

Emily Boda — Wed, 02 Sep 2026 00:00:01 +0000

2026-09-10 Clarification

This document is only for sharing what in our experience works best for the immediate area around Philadelphia, PA. During our testing we found no traffic; using this preset in other areas may cause interference in the 33cm band, and we argue that it should not be a national preset for Meshcore or Meshtastic - please do not use without testing.

Please use proper tools, such as a software defined radio, to identify the quietest part of the band. Additionally, reach out to your local 33cm amateur radio groups and frequency coordinators to confirm no interference occurs while testing. The center of the band is less likely to interfere with their operations, but other sources of interference may impact performance.

We do not see a change in FCC regulations or a new mesh band being created as realistic; more on that in our FAQ.

Also, as a quick disclaimer, none of the Operations Division are lawyers, and none of us play lawyers on TV. Even though we discuss FCC regulations throughout this document, nothing in this document or FAQ is legal analysis or legal advice to anyone reading it. Please, for the love of heaven, always consult an actual lawyer when you have questions about the law, or FCC regulations.

Hey PhillyMesh community,

Our mesh is about to become a lot more fragmented

We, (along with many in the Meshtastic community) recently found out that most of Meshtastic’s presets are not in compliance with the FCC when the newest build of the Meshtastic app changed the USA default preset to LongTurbo. We don’t yet have any official word from the Meshtastic developers about this, but the following is our understanding.

Meshtastic uses a 250 kHz bandwidth by default, and FCC regulations state that devices in the 900 MHz ISM frequency band (that’s us) must use a bandwidth of 500 kHz or higher. The only Meshtastic preset that is in compliance and potentially viable for this area is LongTurbo, which we have tested extensively and determined doesn’t work well for long distance mesh communication in Philly. Other metro areas have corroborated this; LongTurbo doesn’t work well just about anywhere.

We have a blog post with all details of our LongTurbo test, but the summary is that there is a lot of interference within the ISM band, much of which is concentrated every 250 kHz (so, on .000, .250, .500, and .750 on each MHz frequency, with the worst of it being on .250/.750). Using only a 250 kHz slice of bandwidth (for example, from 915.000 to 915.250 MHz) allowed us to keep that interference on the edge of our communication spectrum. However, if we have to use 500 kHz bandwidth, we can’t avoid that interference (we’ve looked all over the ISM Band) and we confirmed (with your help in this summer’s tests) that our ability to communicate with Meshtastic is severely compromised.

So, what are we going to do?

We’re wrapping up our LF910 test and now moving to compliant presets. Because our Meshtastic LongTurbo testing went so poorly, the OpsDiv started scrambling to find options that might work better to achieve the goal of a Philadelphia-area-wide mesh network that allows us to communicate from the city to the burbs. We started informally testing some custom settings for MeshCore at 500 kHz (we’re calling it “MeshCore 500”) and found that it worked surprisingly well.

One of the biggest reasons we’ve seen better results with MeshCore is because it is more resilient due to its message-prioritized routing. The settings we’ve been tweaking during this summer’s testing period to try to improve Meshtastic’s performance (reducing position, telemetry, nodeinfo announcements, and more) are pre-baked into the MeshCore firmware. The additional hops MeshCore allows should mitigate the loss of reach/distance nodes that is caused by operating with a bandwidth that has more interference.

Based on that testing, going forward, the handful of PhillyMesh infrastructure nodes that are currently installed will be tuned to MeshCore 500 because we believe this gives us a better chance to create a Philadelphia-area-wide network. Additionally, we have leads on installing several dual-radio nodes at high sites and these will feature both Meshtastic LongTurbo and MeshCore 500. We expect that given time, Meshtastic LongTurbo may become a more viable short-distance mesh network, especially as Meshtastic firmware matures and resolves some of the issues with overly-frequent position/telemetry/nodeinfo reports. However, MeshCore 500 is currently performing much better and will likely always be better for long-distance mesh communication. As has always been the case, you’re welcome to install whatever preset and mesh technology you’re comfortable with running on your personal nodes.

We considered announcing MeshCore 500 as a test, but we’ve been doing a lot of testing this summer and, honestly, a week-long test for something we already know initially shows promise won’t get us the results we need. We decided to announce this as a transition (kind of like our indefinite LF910 test) and let the people decide if they want to participate. If things go poorly with MeshCore 500 or the technology changes in six months or a year (or the Meshtastic project sorts this whole thing out next week and makes LongFast FCC-compliant in a way that doesn’t nuke its effectiveness) we might just go back to Meshtastic LongFast as our default. But we wanted to make one unified recommendation for right now, for those who want to test out something new with us, since we won’t be able to use LongFast for the foreseeable future. Plus, trying new mesh networks is fun!

Unfortunately, the days of defaulting to Meshtastic LongFast and everyone being on the same mesh network are likely behind us. We expect some people will stay on Meshtastic LongFast, and once Meshtastic’s default preset becomes LongTurbo, we expect many people new to the hobby (an estimated 20 people per week in our area) to be on LongTurbo. We also expect many of those who have been dabbling in MeshCore and seeing how well it performs to keep tinkering with MeshCore 500. There will likely not be one consensus network going forward, but we hope that you’ll try out MeshCore 500 with us.

You do not have to buy new hardware to try out MeshCore 500: almost all Meshtastic node hardware models are compatible with MeshCore and you can flash between the two as easily as you can flash between versions of the Meshtastic firmware. If you try MeshCore and want to go back to Meshtastic, it’s completely and easily reversible in a minute or so. After reading the guide to flashing your node below, if you have any questions about converting your node and changing settings, please reach out on the #meshcore-philly channel in the Discord. We are happy to help guide folks through this transition!

“But I thought this was a Meshtastic server?” Technically, the server name is just “Philly Radio & Mesh”… and if you take a look at the PhillyMesh website, you’ll see posts as far back as 2016 (before Meshtastic was invented) exploring mesh networks in the Philadelphia area. Meshtastic has been a focus lately because it’s been more popular in the Philadelphia area. We’re here to have a good time with all kinds of mesh networks.

Fractured PhillyMesh on the airwaves, unified PhillyMesh in our hearts

This is not a change we’re introducing lightly. Many of us have poured time, energy, passion, tears, and money into testing Meshtastic nodes and settings. We want to ensure that you (the mesh users), the PRM Ops Division, and especially the gracious hosts of our infrastructure nodes do not run astray of FCC regulations.

Large mesh networks like PhillyMesh rely on the power of numbers and agreement between its users to work. We each rely on each other’s nodes to relay our messages. Most of us remember the days when you’d leave a node in your window and not see another node for weeks. We knew a default preset change was coming and that it would cause our mesh to become fragmented, whether we wanted it to or not.

We had been preparing for that preset change, like many other metro areas have been doing, by testing to find a preset that works best for our area. With our better understanding of the rules, we realize that our previous choice of the best preset is no longer an option. We think that our best hope for FCC-compliant survival in the short term is MeshCore 500.

Love,

The PhillyMesh Operations Division

MeshCore and Meshtastic FCC-Compliant Settings

MeshCore

Meshtastic

These are the new default, FCC-compliant settings, that the Meshtastic project recommends for the US. Please update your firmware to the latest stable/beta version first!

Frequency: 908.75 MHz (this is the default slot, which you can enter as 0 or 14)
Preset: LongTurbo

FAQ

I’m sure you have a lot more questions! Hopefully we answer a good number of them below, otherwise please ask/vent/grieve the loss of 250 kHz bandwidth in the Discord.

What is this “PhillyMesh Operations Division”/“OpsDiv”? Just who the heck are you folks?

The PhillyMesh Operations Division is some of the OGs from the Philly Radio & Mesh Discord server. The name “Operations Division” came about because the server admin is a Trekkie, and she couldn’t resist the name. If you’ve seen anyone teach a class about Meshtastic, foot the bill for the website, table for the group at a local event, organize a PhillyMesh happy hour, or coordinate an infrastructure node install with another local org; that was one of the Ops folks. Feel free to bribe us with good node locations, bad puns, and Malort.

What are presets and what is LongFast?

Meshtastic has many settings that allow you to change what slice of frequency you send messages in. You can customize these settings almost indefinitely, but most of the time people choose between a few different presets which are a standardized set of settings. Other Meshtastic users must (for the most part) have the same settings as you in order to receive your messages and be on the same mesh network.

Meshtastic’s default settings are a preset called LongFast. This preset uses a bandwidth of 250 kHz, which we now know is in violation of FCC regulations.

Can you tell me more about this bandwidth thing?

Meshtastic (and MeshCore) packets are sent across a frequency spectrum. That spectrum is determined by choosing a starting frequency (or, with Meshtastic, you often choose a “Frequency Slot” and the firmware uses that to calculate your starting frequency) and then setting a bandwidth which determines how large the range of the spectrum will be. The frequency you set is the middle of your range. For example, if your frequency is 906.500 MHz and your bandwidth is 250 kHz (0.250 MHz), you will be transmitting from 906.375 MHz to 906.625 MHz.

The only presets that uses a 500 kHz or higher bandwidth are LongTurbo and ShortTurbo, the rest use 250 kHz. In our region there is a lot of interference put off by devices using RFID, among many other things. The interference exists every 250 kHz (at the .000, .250, .500, and .750 points of each frequency) and is strongest at .250 and .750. Using a smaller bandwidth like 250 kHz, Meshtastic packets are able to keep that interference at the edges and not be affected too much by it. However, because the Turbo presets use 500 kHz, no matter what starting frequency is chosen, it will always overlap with some of the interference.

Who is the FCC and why do I care about them?

The FCC makes and enforces the regulations regarding which frequency bands people and companies can use and what the rules are for the packets they send. As with all regulations in the US, it’s possible to get in trouble for unknowingly violating them (regardless of motive/intent), and that’s what we’ve all been doing while using Meshtastic on LongFast.

The FCC requires all packets sent in the ISM band (the band Meshtastic and MeshCore use) to have a bandwidth of 500 kHz or more. The only Meshtastic presets that uses a 500 kHz bandwidth are LongTurbo and ShortTurbo (LongTurbo is the only viable one for long distance communication), and LongTurbo is now what the Meshtastic project will be suggesting as the default in the US. The default MeshCore setting uses a 62.5 kHz bandwidth and is even less compliant, hence the custom settings to use a 500 kHz bandwidth.

Is this a new FCC regulation?

No. It seems that most people did not understand the FCC regulations. This includes Meshtastic devs, MeshCore devs, and device manufacturers selling devices where the default settings were out of compliance.

There was a misunderstanding among users that did read the regulations about how Meshtastic was operating, FHSS mode vs DTS mode, and the regulations are different for each. Those users who didn’t read the regulations figured if a project as big as this one was not in compliance with the FCC, we’d know about it. Well, now we know.

Does the FCC even care if we keep using Meshtastic LongFast?

At this point we don’t know what enforcement the FCC will have for these regulations. You, as an individual, can make your own determination if you want to continue to operate on Meshtastic LongFast and be in violation of FCC regulations. It is important to note that if you are a licensed ham radio operator your license could be at risk for knowingly operating devices in violation of FCC regulations. The risk of punishment for past actions is probably low in this case, however, you are now aware and must make your own decisions going forward.

As the group that is Philly Radio & Mesh, we feel it is important to stay in compliance for many reasons. Besides the obvious fact that violating FCC regulations is illegal, we have been partnering with non-profits such as Philly Community Wireless to host nodes, and we don’t want to get them or any of the building owners in legal trouble. We’ve been asked by local businesses and libraries to do talks about Meshtastic; we can’t in good conscience encourage new users to try something that we now know is illegal, and if people think we’re doing that, we won’t be asked back. Many of us are also licensed ham radio operators, and don’t want that hobby to be put into jeopardy by affiliation with this group. Even for non-hams, using the ISM band irresponsibly could result in the privilege of using that spectrum being revoked for everyone, especially in today’s environment of companies looking for spectrum to pivot to cellular 5G use.

What is MeshCore?

Meshtastic is a project that allows you to send messages over LoRa. There are other projects that do the same thing, one of which is MeshCore.

MeshCore and Meshtastic have recently grown side by side, learning and improving based on the other’s work. In general, MeshCore has been optimized for nodes to be placed in a stationary routing and learns what the most efficient way to route messages between nodes is to get the furthest reach. Meshtastic has historically assumed that all nodes are mobile and hasn’t added that routing part until recently.

In Philadelphia, Meshtastic has historically been more popular. In other areas, such as NE PA, MeshCore is more popular. And as an individual, it’s always more fun to join a mesh network that has more people on it, so the popularity is self-perpetuating.

More details about why we think MeshCore 500 is performing better than Meshtastic LongTurbo are in another FAQ below.

What is MeshCore 500?

Most people on MeshCore operate at a 62.5 kHz bandwidth (these are the USA default settings), which, it turns out, is also in violation of those pesky FCC regulations, but the technology supports a 500 kHz bandwidth just like Meshtastic does. We have been calling using MeshCore at 500 kHz “MeshCore 500” to differentiate it from the usual MeshCore at 62.5 kHz settings that most people are currently using.

I don’t want to try out MeshCore, but I do want to make sure I’m in compliance with the FCC. What should I do?

You should switch your Meshtastic node’s preset to LongTurbo. We recommend leaving your other frequency settings at default, so you can see as many other people on LongTurbo as possible. You will soon also see our dual-radio infrastructure nodes on Meshtastic LongTurbo as well, but the single-radio nodes will be on MeshCore 500.

Do I have to pay to use MeshCore?

No. MeshCore, unlike Meshtastic, has many third-party apps you can use to interface with your nodes. Some are paid and some have paid features, but there are some great ones you can use that are entirely free.

Dusty, who has been using MeshCore for a while, recommends the apps MeshCore One for iOS and MeshCore Open for Android. Both are entirely free to use.

If you’re a power user, RemoteTerm is a docker app like MeshMonitor and Kyle Yank has set up an instance of CoreScope, which is like Malla. Feel free to turn MQTT on and contribute (as long as you’re on 500 kHz).

Can licensed amateur radio operators continue to use Meshtastic and MeshCore at 250 kHz?

Yes. However, using Meshtastic as a licensed amateur radio operator requires you to not use encryption which means dropping packets from private channels and only using the default public channel (with the published key of AQ==). Setting your node to “ham mode” will do all of these things.

This is not compatible with the default Meshtastic network and won’t allow you to chat with non-licensed users on LongFast. If you’re intersted in getting your ham radio license, JawnCon, Philly’s local cybersecurity conference in October, has free classes and exams most years.

Amateur radio has several alternatives to the ISM band that have similar messaging functionality, including normal VHF APRS, UHF, LoRa APRS, FT8 (and derivatives), JS8 Call, VARA modes, Winlink, etc. Ask your friendly neighborhood ham in #amateur-radio in our Discord to learn more.

What settings are being recommended for MeshCore 500?

Some MeshCore apps have recommended presets and some don’t, but there are generally agreed upon default settings that most people use so they can communicate with each other. Those settings use 62.5 kHz as the bandwidth, which is in violation of FCC regulations.

We have outlined our custom settings in the next section below, which use a 500 kHz bandwidth. This means that, for the time being, the only other MeshCore nodes you’ll be able to communicate with are folks who heard about these settings from PhillyMesh. We do anticipate that once word gets out about the FCC regulations, we will see some current MeshCore users transition to 500 kHz bandwidth and find us. We are not making this change to be isolated or exclusionary, we are making this change for FCC compliance and sharing the settings that worked best in hopes of re-connecting with neighboring meshes again.

MeshCore’s reach is much wider than Meshtastic LongFast; the current most widely used (and non-FCC-compliant) settings result in Philly being reachable from as far north as New Hampshire and as far south as Kentucky, depending on the weather (check Kyle’s instance of CoreScope that uses MeshCore’s default settings to see all the repeaters he’s seen recently and you’ll get an idea of the reach). In order to keep the community we’ve had on Meshtastic LongFast together, we recommend everyone joins the #prm channel and uses that as the default comms channel. Once other meshes join our settings and the Public channel gets busy again, #prm can be a way to ensure our area’s unique culture has a home.

Why do we expect MeshCore to perform better at 500 kHz than Meshtastic does?

MeshCore has some key benefits compared to Meshtastic that will increase chances of success at this wider, more interference-heavy bandwidth.

Reduced Non-Message Traffic. Baked into the firmware are the settings we were asking Meshtastic users to change as part of this summer’s tests to reduce position reporting, telemetry, NodeInfo, etc. Without these packets clogging the mesh, there is more room for messages to reliably flow.
Higher Hop Limit. Where Meshtastic had a hop limit of 7 (and realistically only 4-5ish hops were viable), MeshCore has a hop limit of 64. We won’t need all 64 of those hops to talk across the Philly Mesh, but we know we will need more than the 4-5ish viable hops Meshtastic had. An increased hop limit will increase the functionality of the mesh to counter the degradation of node transmit/receive distance at 500 kHz bandwidth.
Better Routing. MeshCore prioritizes static routing compared to Meshtastic’s ad-hoc flood routing. There is still flood routing in MeshCore, but it uses it sparingly and instead focuses on building stable paths from router-to-router to reduce unnecessary retransmits. This means many nodes, especially in Center City who can reach a repeater, can stay in Bluetooth Companion mode (the equivalent of CLIENT_MUTE in Meshtastic). The reduction in unnecessary rebroadcasting also helps reduce packet collisions and noise floor, also mitigating the impacts of the higher interference on the 500 kHz bandwidth.
Better Battery Life. Because most nodes in Center City can stay in Bluetooth Companion mode, they won’t unnecessarily waste battery life rebroadcasting. This is a significant win for battery-run nodes, pocket nodes, small solar nodes, etc as they will live longer.

And we’ve seen this in practice. Compare our Malla instance (Meshtastic) to Kyle’s CoreScope instance (MeshCore). While on Meshtastic we see a couple of nodes further away, these are likely to be airplane nodes, or nodes that had their location incorrect. On MeshCore we see hundreds of repeaters further north than New York City and a handful down in North Carolina.

Could we just roll our own Meshtastic firmware to make Meshtastic on 500 kHz perform better?

We actually thought about this; we’ve been joking about making MalortCore for a while. However, in order to make Meshtastic on 500 kHz perform better we’d be doing things like increasing the number of allowed hops and improving routing, and we’d basically just be recreating MeshCore. We’d rather spend our energy building out local infrastructure that will benefit everyone in the area, instead of developing and administrating a third competing LoRa mesh project, which would just serve to further fragment the PhillyMesh.

I haven’t seen anything about a new Meshtastic preset. What’s your sourcing on this?

It seems a lot of this discussion has been happening in private Discords, so sourcing this is hard. However, it became clear when we saw that starting in Meshtastic version 2.8, the Meshtastic firmware will default to LongTurbo for users in the US. Mobile apps will warn users on the LongFast preset that their preset is violating FCC regulations and push them to move to LongTurbo. We believe this will cause many Meshtastic users, especially new ones, to use Meshtastic LongTurbo and effectively kill the current default Meshtastic LongFast network.

Meshtastic’s leadership has discussed on other Discords that further “friction” will come in version 3.0 and later.

Did some people know about this? It’s suspicious that we did LongTurbo tests a month before we found out that LongTurbo will be the new default.

Some folks who follow the Meshtastic firmware GitHub repo and are part of other Meshtastic Discords had heard rumors that the default preset might be changing. No one knew why; we’re not even sure if the default preset change was because of the FCC regulations or because of this meshtastic.org post about LongFast not being the best default for cities.

We realized this default change would fracture the mesh significantly and our Discord would play a key role in informing users about the changes and helping support users change their existing nodes. We thought about it and decided to take the opportunity to not blindly trust the new recommended default, but to find a preset and custom settings that would actually improve PhillyMesh’s performance.

It wasn’t until we saw version 2.8 and this heated discussion in the MeshCore Github that the violation of FCC regulations became clear. This resulted in a few days of waiting to see if the Meshtastic project would say anything about it before we decided to stop waiting and make this post ourselves.

Shouldn’t someone be fixing this?

Meshtastic is a global project. Many of the developers are based in Europe, where the regulations are actually the opposite (in their 433 MHz frequency band the bandwidth must be less than 500 kHz). Only a small subset of the devices that hardware manufacturers sell are being used for Meshtastic, so they leave it up to the users to make sure their devices are in compliance. If there is a better solution to this issue, such as a different frequency band to use in North America for Meshtastic, we don’t see it arriving quickly.

Could lowering the power on Meshtastic transmissions allow us to still have a bandwidth of 250 kHz and be FCC-compliant?

Yes, but we’re pretty sure it would have to be lowered so much that Meshtastic LongFast would be completely useless. Some math by one of our members, KT3H, says that the power would be limited to something like 0.0006 Watts, which is tiny compared to the ~1 Watt we have been using. Lowering the power on Meshtastic LongFast that much would severely compromise our ability to communicate using Meshtastic. Messages wouldn’t be able to travel as far and the mesh would perform significantly worse. Using Meshtastic LongFast at a fraction of the power would be even worse than using Meshtastic LongTurbo.

That 0.0006 Watt number is very specific, how did you calculate it? Also, what are the actual regulations we’re discussing here?

Our understanding of the regulation is as follows (with the usual caveat that we are not lawyers and are awaiting official word on guidance): Unlicensed operation in the 902 MHz band is governed by 47 CFR Part 15 Subpart C. There are two sections that apply, and you must pick one to operate under. Under §15.247 the bandwidth must be no less than 500 kHz, but the power can be up to 1 Watt. Under §15.247 there is no bandwidth restriction, but the maximum field strength is 50 mV/m at a distance of 3 meters. This is equivalent to an output power of 0.0006 Watts.

Can we move to another frequency band that has different regulations?

Potentially. But that would require, first, a research effort to find one compatible with the Meshtastic project. Second, it would almost certainly require purchasing new antennas for all our nodes. And third, it would likely require us to purchase entirely new nodes (which would first need to be designed and manufactured) that are compatible with the new frequency. Unfortunately, we don’t see that happening anytime soon.

Is there a chance the FCC will change their regulations?

The FCC is largely concerned with regulating the frequency bands that they license for commercial use. While using amateur bands brings us nerds a lot of joy, it actually results in less money in licensing for the government. Furthermore, NextNav has been lobbying the FCC to further restrict amateur usage of the 900 MHz ISM band and reserve parts of it for commercial use. We consider ourselves lucky that NextNav hasn’t succeeded thus far, and unless an independently wealthy Meshtastic user wants to fund their own lobbying campaign, we see a change in FCC regulation to be unlikely.

Do we expect Meshtastic LongTurbo to perform better in the future than it did during our testing?

We do expect Meshtastic LongTurbo to perform marginally better once more people switch over to it. We didn’t have a large number of nodes participating in this test, and because LongTurbo messages don’t go very far we needed more nodes than we had to get a proper mesh going. We expect that as Meshtastic LongTurbo adoption increases (and as we install more well-placed infrastructure dual-radio nodes that support LongTurbo) we will be able to communicate better over short distances using LongTurbo. The reason we’re also focusing on building out MeshCore at 500 kHz is because those messages seem to be able to go a lot further, and that gives us the best shot to be able to communicate across our wide metro area, from Jersey to Delco and beyond.

A core goal of the group is to be accessible to those who are new to mesh networks and be in touch with whatever is most used in our area. That’s why our dual-radio infrastructure nodes will have one radio tuned to whatever the current Meshtastic default preset is (as long as it’s FCC-compliant) and the other will be on MeshCore at 500 kHz. We may move somewhere else in the future, but that’s what we expect to be using until the next big revelation or new technology release.

I have a good place for a node, or a resource/skill I can bring to PhillyMesh!

Please let the Ops Division know by tagging @PhillyMesh Operations Division on Discord! For node locations to be officially associated with PhillyMesh, you must have explicit permission from the property owner to install the node, and if you have internet and/or power at the location that’s a huge plus.

How to Flash MeshCore

RightSizedAlpaca — Wed, 02 Sep 2026 00:00:01 +0000

How to flash a Meshtastic node to MeshCore

1. Back up your previous Meshtastic settings

Before doing anything, it is recommended to backup your current Meshtastic node config.
From your phone app while connected to your Meshtastic node, go to Settings > Export Configuration, select all toggles, and then save that .cfg file somewhere safe.
If ever you want to change your node back to Meshtastic, you can use this config file with the “Import Configuration” to more quickly return it to its current state.

2. Grab your node and a GOOD data-enabled USB cable

Just like when doing firmware updates via serial, you’re going to want a good cable that enables data transmission (many cables are charge-only).
- If you have a cable that worked for Meshtastic flashing, it should work for MeshCore as well.
- So many instances of “flashing failed” are cable-related. If the thing is old, wobbly, been chewed on by your cat, filled with lint, been through the washing machine, been used by Gritty, etc… get a better cable, otherwise you’re gonna have a bad time.

3. Connect your node to your computer

If it’s USB-A, it’s upside-down, flip it. Now flip it again. GUESS WHAT, IT WAS RIGHT THE FIRST TIME, flip it one more time.

4. Open the MeshCore Flasher

Go to https://flasher.meshcore.io/

Note that you’ll need to use a Chromium-based browser, like Chrome or Edge. Firefox isn’t going to work.

5. Select Device Type

Find your exact node (exact model) and click on it.

If you can’t find your exact model, ask in the Discord.

6. Select Device Role

Unlike Meshtastic where you could change between CLIENT and CLIENT_MUTE in the app, MeshCore requires specific firmware for each role.

If you only have one single device/node, select “Companion Bluetooth”.
If you have a multi-node setup
- Select “Companion Bluetooth” for your pocket node.
- Select “Repeater” for the powerful/stationary node (the node on your roof, in your tree, in your attic, etc.)
  - Note that repeater nodes cannot be configured via bluetooth, but once configured over USB you can make changes from your companion node.

7. Flash the MeshCore Firmware

For NRF-based nodes

There is a warning at the top that says “We strongly recommend installing OTAFIX BOOTLOADER … for more reliable Bluetooth OTA DFU.” Click on “OTAFIX BOOTLOADER” and it will download a .uf2 file that does this. Follow the instructions here: Installing the OTAFix Bootloader - MeshCore Blog. When it comes time to update the node, you will be happy you did this.
Click “Enter DFU Mode” (in theory there is no need to double click the reset button anymore). If nothing happens (no pop up), ensure you are using a Chromium based browser like Chrome or Edge.
When the pop-up with devices shows up, select the COM port of your device. It is typically something like “nRF Serial” but may be something different depending on your device. When it is connected, the previous “Enter DFU Mode” button will now have a check and say “DFU Mode Active”.
Click “Erase Flash”. When complete, a popup will show “Device erase firmware has been flashed and flash has been erased. You can flash MeshCore now.” Click OK.
Click the Flash button. A similar popup with COM ports will allow you to select the device. A warning that the COM port number and/or device name may have changed now that it has been erased.

For ESP32-based nodes

Select “Erase Device” because the current firmware on your node is Meshtastic and must be erased.
Click “Flash”
In the pop-up, select your node based on the COM port. Click OK.
Watch the progress. Beware that erasing flash may take some time (minutes) where it appears little progress is occurring, then it will then progress to flashing.

DON’T CLOSE THE WINDOW OR DISCONNECT THE DEVICE YET

8. Configure your new MeshCore Node

For Companion Nodes

After flashing in step 7, disconnect the node from your computer and pair it to your phone using Bluetooth.
- If the device has a screen, the PIN is displayed there as a randomized six digit number.
- If the device has no screen, 123456 is the default PIN.
Configure the radio to match the settings listed in our post about “MeshCore500”

For Repeater Nodes

After flashing in step 7, DO NOT DISCONNECT the node from your computer. Initial settings must be made over serial first!
Click on “Configure via USB”.
A new window will pop up. Click “Connect” in the top right. Yet another pop up will let you select the device via COM port, and yet again the number and/or name may have changed.
The repeater setup page has a few settings you MUST setup before you disconnect, we’ll start with those:
- Under ACCESS, create a new admin password and keep it somewhere safe. This is how you will access your repeater via LoRa. If you lose this, you can’t get back into the repeater without plugging it back into your computer again.
- Under RADIO SETTINGS, change the settings to match the settings listed in our post about “MeshCore500”. These settings (freq, bandwidth, SF, coding rate) must match your companion node for the two to see each other and the rest of the mesh.
- Click SAVE SETTINGS at the bottom. A toast message with “Data successfully saved” should pop up for a second.
At this point you can disconnect your repeater and configure the rest over LoRa (using the password you just set), or finish setting it up here on a bigger screen while you’re already connected.
- Copy the Public and Private keys and keep them somewhere safe.
- In NAME & LOCATION, at least change the name to something unique. A warning that when you set the location (now or later on) it will truncate the name from 32 bytes to 24 bytes.
- Under ADVERTISING, change the Advert Interval to 240. Leave the Flood Advert at 47.
- In Owner Info, feel free to put in your Discord username or Ham call sign or leave it blank, whatever you’re comfortable with!
- Click on the SHOW ADVANCED SETTINGS checkbox and change LOOP DETECTION to Minimal. Change PATH HASH MODE from 1-byte (0) to 2-byte (1).
- Hit SAVE SETTINGS in the bottom left.
- Hit Reboot in the top middle (some of the settings don’t take effect until after a reboot). Rebooting also has the effect of disconnecting the device from the computer. You can now unplug and place the repeater back into its strategic location!
Your repeater should now be automatically repeating packets, and when you send a message using your companion node, you should see your repeater as the first hop out.

Update Time and Location

Look for a setting similar to “sync/set device clock to phone time” and click it.

MeshCore can be weird with time settings, it is a good practice to occasionally do this so your node’s clock doesn’t become too out-of-sync with the mesh.
Some apps have a setting to sync automatically.

Set a location for your node, especially if it’s a repeater.

The easiest way to do this is from the map view, where you can select a location and set it as your node location.
Note that the location does not get “fuzzed” like in Meshtastic, please do not use your exact home address if you are not comfortable doing so.

So I’m on MeshCore… What now?

First, let us be the first to welcome you to the mesh!

It may seem a bit empty at first, remember the default advertising intervals are much longer than on a Meshtastic mesh!
If you are on or near PhillyMesh open our Live CoreScope Map to watch the current mesh traffic.
If you are on your companion you should manually send out a flood & zero hop advertisement.
Under your tools or settings menu (depending on app) there should be a “Discover Nearby Nodes” option, click that.
Try saying hello in the public channel!
Add your first hashtag channel “#test” and try sending out a message with “test” or “ping” in it. We have members running bots in there that should reply if they hear your message.
Be patient! The first day can take a while for your map to fill in and local devices to discover your new devices and their routes!

Done! Unless…

For any step, when in doubt, feel free to reach out! We’re happy to help on the Discord.