Two Radios, Two Philosophies, One Band
If you are flashing your first LoRa radio in 2026 and you have no existing local network to join, flash MeshCore. It has the better routing design, the more sensible default about which nodes are allowed to talk, and it is noticeably quicker in practice. If your town already has twenty Meshtastic nodes on a hilltop and a Discord full of people running them, flash Meshtastic, because a technically superior protocol with nobody to talk to is a paperweight with a nice antenna.
That is the whole decision, and it is a local one. Both projects run on the same radios, in the same license-free sub-GHz bands, using the same Semtech chips. What separates them is a set of architectural choices about who repeats traffic and how paths get discovered, and those choices produce very different networks once you get past three nodes in the same room.
I have not run either of these across a town for a year. What follows is the architecture, pulled from the projects’ own docs and from community groups who have deployed both at metro scale, with version numbers pinned so you can tell how stale this is when you find it.
The 30-Second Version
| Meshtastic | MeshCore | |
|---|---|---|
| Broadcast routing | Managed flood | Flood (group channels always flood) |
| Direct messages | Flood to discover, then next-hop (since 2.6) | Flood to learn, then explicit stored path |
| Who rebroadcasts | Every node by default (CLIENT role) | Only dedicated repeaters |
| Max hops | 3 default, 7 ceiling | 64, 32, or 16 depending on path hash size |
| US default preset | LongFast, 250 kHz bandwidth | 62.5 kHz narrow bandwidth |
| Firmware variants | One image, roles set in config | Four separate images |
| License | GPL-3.0 | MIT |
| Ecosystem | Large, years of tooling, huge hardware matrix | Younger, growing fast, freemium edges |
Routing Is the Real Difference
Everything else downstream of this is detail.
Meshtastic: Managed Flooding
Meshtastic broadcasts by flooding, with manners. When a node hears a packet it has not seen, it waits a calculated moment and then rebroadcasts. The delay is weighted by signal quality, so the node that heard the message worst rebroadcasts first. That sounds backwards until you think about it: the distant node with poor SNR is the one most likely to reach listeners the sender could not, so it gets priority. Any node that hears somebody else rebroadcast the packet first stays quiet.
It is a clever design for a network of unknown, possibly moving nodes with no infrastructure. It also means every packet gets multiplied by roughly the number of nodes in earshot, and airtime on LoRa is a scarce, shared resource.
Since version 2.6, direct messages get better treatment. The first DM from A to B still floods to find B. Along the way, nodes observe which neighbor actually succeeded in relaying, and A designates that neighbor as its next hop for future messages to B. It is decided per hop, so an asymmetric link or a neighbor on old firmware just falls back to managed flooding for that hop. A node also falls back to flooding on its last retransmission attempt if it does not hear its next hop relay. The whole thing is backwards compatible, which is admirable engineering and also why it is complicated.
MeshCore: Learn the Path, Then Use It
MeshCore floods the first message to learn a route, then embeds the discovered path in subsequent packets and sends them along it. If that path fails, after about four retries it falls back to flooding and re-learns. Crucially, paths are observable and manually configurable, so operators running regional infrastructure can inspect and tune routing instead of hoping the heuristics work out.
Group channels are the exception. A group message has no single destination, so there is no path to store, and group traffic always floods. Repeater operators can put a lid on this with a hop ceiling:
set flood.max 3Repeater admins set the rules for their own repeaters, which is a recurring theme in MeshCore’s design.
Who Gets to Repeat
This is the choice I find most defensible, and it is the one I would point at if somebody asked why MeshCore feels faster.
In Meshtastic, the default device role is CLIENT, and clients rebroadcast when no other node has already done so. Every handheld in your pocket is participating in routing. For an ad-hoc group hiking together with no fixed infrastructure, that is exactly right, and it is a real capability MeshCore gives up.
In MeshCore, companion radios (the thing your phone talks to over Bluetooth) do not rebroadcast at all. Only repeaters do. The project’s stated philosophy is that repeaters route and edge nodes stay off the air. The practical effect is that a city of two hundred MeshCore users produces far less noise than a city of two hundred Meshtastic users, because the airtime is concentrated in a handful of well-placed nodes on tall things instead of being sprayed from every jacket pocket.
The tradeoff is honest and worth stating plainly: MeshCore assumes somebody put up infrastructure. No repeaters, no multi-hop network. Meshtastic works out of the box with nothing but the radios in your group’s hands.
Hop Limits
Meshtastic defaults to 3 hops and caps at 7. For most suburban meshes that is fine. For a metro with hills and valleys, seven can be a hard ceiling you actually hit.
MeshCore’s ceiling depends on how many bytes each hop consumes in the path field. One-byte hashes get you 64 hops, two-byte 32, three-byte 16. Longer hashes buy you more specific path identification once your network has enough nodes that short hashes start colliding. Austin Mesh, running both, reports regularly seeing 10 or more hops in their terrain, which puts Meshtastic’s ceiling in the way and MeshCore’s nowhere near it.
Airtime, Presets, and Why MeshCore Feels Snappier
Both stacks use LoRa’s chirp spread spectrum, where bandwidth, spreading factor, and coding rate trade range against speed against airtime.
Meshtastic’s standard US preset is LongFast at 250 kHz bandwidth with a conservative spreading factor and coding rate. Robust, long range, and expensive in airtime per message, which compounds over multiple hops. You can absolutely switch to MediumFast or ShortFast or a custom narrow bandwidth, and plenty of organized meshes do.
MeshCore’s US default is 62.5 kHz, narrower, with a moderate SF and CR mix chosen partly to sit in a quieter slot of the band. Combine the higher effective data rate with dramatically less background traffic from non-repeating edge nodes and you get the numbers Austin Mesh has been reporting since September 2025: sub-second delivery to nearby peers and roughly five seconds across a nine-hop route, against ten to twenty seconds for Meshtastic. Your terrain, antennas, and infrastructure density will move those numbers around, but the airtime arithmetic points the same direction regardless.
Four Firmware Images vs One
Meshtastic ships one firmware image and you pick a role in config: CLIENT, ROUTER, REPEATER, ROUTER_LATE, and friends. Simple to flash, simple to change your mind.
MeshCore ships four distinct builds, which is unusual and takes a minute to get used to:
- BLE Companion: your everyday radio, talks to the Android or iOS app over Bluetooth
- USB Serial Companion: same job, but over USB to the web client at
app.meshcore.nz - Repeater: relay only, no user interface, put it somewhere high
- Room Server: hosts persistent group chats, so messages posted while you were out of range are waiting when you return
Room Server is the one with no clean Meshtastic equivalent, and if you have ever wanted a store-and-forward channel for a neighborhood, it is the feature that will sell you.
Repeaters and room servers are configured over USB via config.meshcore.dev (the screenless-device config tool) or the console on flasher.meshcore.io, or remotely over the air from the phone app. Companion radios running the USB serial build get a browser client at app.meshcore.nz. Two things to do on day one:
set freq {your region's frequency}password {something other than the default}The default admin password on a fresh repeater is literally password. Change it before you bolt the thing to a mast.
nRF52 devices (RAK, Heltec T114, Seeed Xiao) can be updated over the air using Nordic’s nRF DFU app, with the repeater put into OTA mode via start ota from the command line tab. Companion firmware needs to be at v1.15 or newer to update itself that way.
MeshCore firmware moves quickly, so pin your expectations to a version. v1.15.0 (April 2026) brought the OTA support above plus a batch of new boards and a wider frequency range, and v1.16.0 (June 2026) added power saving for ESP32-based repeaters, which matters if you are running one on solar. There are also community forks, MeshCore-Evo among them, aimed at more robust repeater behaviour on larger networks. Check the flasher for what is current before assuming any of this is still true.
Identity and Encryption
Meshtastic is channel-centric. Channels have pre-shared keys, and the default public channel’s key ships with the firmware, so treat the default channel as a public square with a lock painted on it.
MeshCore is key-centric. Each node has a public key, and an “advert” broadcasts your name, position, and public key, signed so it cannot be trivially spoofed. Adverts are either zero hop (only direct neighbors hear it) or flooded (repeaters propagate it). Clients only advert when you press the button. Repeaters flood an advert every 12 hours by default:
set flood.advert.interval 12set advert.interval 30The first controls the flooded advert in hours, the second the local zero-hop timer in minutes.
MeshCore also has a default public channel with a published key (8b3387e9c5cdea6ac9e5edbaa115cd72 in hex for the phone app, the same key base64-encoded for T-Deck firmware). Same rule applies: public means public.
Where Meshtastic Still Wins
MeshCore has the better protocol. Meshtastic has the better everything-else, and if you are the kind of person who values a mature ecosystem over an elegant design, that is a completely rational reason to pick it.
Meshtastic’s supported hardware matrix is enormous and well documented, spanning RAK WisBlock, LILYGO T-Beam and T-Echo and T-Deck, Heltec, Seeed, B&Q Consulting, Elecrow, M5Stack, and a Raspberry Pi path via meshtasticd. There are years of accumulated integrations, map services, telemetry tooling, Home Assistant work, and a Discord large enough that someone has already hit your problem. The firmware moves fast (the 2.7.x stream was at v2.7.26 as of late June 2026, adding things like multi-message storage, API port config, and RAK3112 support along the way).
MeshCore’s hardware list is real but shorter: T-Deck and T-Deck Plus, T-Pager, RAK4631 WisBlock combos, Heltec V3 and T114, Seeed Xiao S3 and C3, Station G2, Nano G2 Ultra, Seeed T1000-E, with more arriving regularly. Check flasher.meshcore.io for the current list rather than trusting any blog post, including this one.
The Money Question
Both are free and open source. MeshCore’s protocol and radio firmware are MIT licensed, written by Scott at Ripple Radios. Meshtastic is GPL-3.0.
MeshCore has freemium edges that occasionally get people worked up, so here is the actual shape of it. The radio firmware is free. The cross-platform mobile app is free to download. The T-Deck firmware is free and does messaging, repeaters, and room servers without paying. What money unlocks is a small set of extras: deeper map zoom and remote server administration over RF from a registered T-Deck, and removing a wait timer on remote repeater management in the mobile app. None of it gates core messaging. Whether a small paid unlock in an otherwise MIT-licensed project bothers you comes down to your own values, and I am not going to tell you how to feel about it.
So What Does a LoRa Mesh Actually Give You?
Time to deflate this a little, because the marketing around off-grid mesh is doing heavy lifting that the physics will not support.
You are getting text messages. Short ones. Over a link measured in kilobits per second on a good day, shared with everyone else in earshot, at a latency measured in seconds to tens of seconds across a real multi-hop path. Position beacons, small telemetry payloads, and a group chat that works when the towers are down. That is the product.
You are not getting voice, images, web browsing, or anything resembling internet access. Range claims of “up to 10 km” are line-of-sight numbers from a hilltop to another hilltop with a decent antenna. In a suburb with trees and houses, a handheld at hip height talking to another handheld at hip height is doing a few hundred meters to maybe a couple of kilometers, and that is why the whole model depends on somebody mounting repeaters up high.
The genuinely useful version of this is a local network with a handful of well-sited repeaters and a community that maintains them. A drawer full of radios and nobody within range is a hobby project, not a communications plan. Which loops back to the opening: find out what your area is running before you order anything, because the protocol argument matters far less than whether there is anyone to talk to.
My lean, for what it is worth, is MeshCore. Better routing, saner defaults about who floods the airwaves, room servers, and a hop ceiling that does not get in the way. But I would cheerfully flash Meshtastic instead if that were what the people around me were using, and so should you.
