I chose MeshCore

I have been interested in off-grid mesh networking for a while. The idea that you could send a message to someone across a city without touching the internet, without a mobile signal, without any infrastructure beyond a small radio device and a bit of forward planning, appeals to me in a way that is hard to fully articulate. Part practical, part philosophical. The same instinct that drives the rest of what I build: own your infrastructure, understand your tools, do not depend on systems you cannot see or control.

For most of the last year, if you were interested in LoRa mesh networking, the answer was Meshtastic. It is the established platform, the one with the large community, the mature apps, the years of documentation. If someone handed you a LoRa board and asked what to flash on it, Meshtastic was the obvious answer.

Then MeshCore appeared, and the conversation got more interesting.

Two protocols, one hardware platform, fundamentally different philosophies about how messages should move.

I spent some time comparing them properly before making a decision, and the comparison is worth writing down because the right answer genuinely depends on what you are trying to build. Meshtastic uses a managed flood routing model: every node rebroadcasts messages until they reach their destination or hit the hop limit. It is resilient, self-organising, and works without any pre-planned infrastructure. Hand someone a flashed device and they are on the mesh immediately. That is a real strength, particularly for roaming groups, events, or any scenario where the network needs to form spontaneously around moving people.

MeshCore makes a different bet. It separates devices into companions, which are personal devices carried by users, and repeaters, which are fixed infrastructure nodes. Companions do not relay traffic for other people. Messages travel learned paths through the repeater infrastructure rather than flooding every node in range. The result is less radio congestion, better battery life, more efficient use of the duty cycle limits that apply on the 868MHz band in the UK, and a hop count of 64 rather than 7. The trade-off is that the network requires someone to plan and deploy the repeater infrastructure. Two companions out of direct range cannot communicate without a repeater between them.

That trade-off is exactly why the decision is personal rather than universal. For someone who wants to join an existing community network with minimal friction, Meshtastic is almost certainly the right choice. The UK has a substantial and growing Meshtastic presence. You can flash a device and potentially be on a mesh the same day.

But I am not trying to join someone else’s network. I am trying to build one.

I have a homelab. I have three sites connected by VPN across Greater Manchester. I have a rack with always-on infrastructure and a roof with a reasonable line of sight. The MeshCore architecture is designed for exactly this kind of deliberate deployment. A repeater on the homelab, a room server for persistent messaging, a companion device to carry around.

The UK’s geography also factors in. The density of England’s cities creates channel congestion issues in dense Meshtastic deployments that MeshCore’s lower per-device transmission overhead sidesteps. The 1% duty cycle limit on 868MHz, which constrains how often any device can transmit, is a meaningful consideration when building fixed infrastructure, and MeshCore’s structured routing is considerably more conservative with airtime than flood routing.

There is also something appealing about being early to something. MeshCore is younger than Meshtastic, the ecosystem is still building, and there is a distinct lack of documentation which means more friction, and more figuring things out when the answer is not already written down somewhere.

The UK was among the first regions outside the US where MeshCore nodes appeared. There is a network here to connect to and to contribute to.

So: two Heltec WiFi LoRa 32 V3 boards, one flashed with repeater firmware and one with room server firmware, both destined for the homelab rack with a coaxial run out to an external antenna. A third board as a companion device to carry. An antenna on the roof if I can manage it. A room for people I trust to join, with store-and-forward so nobody misses a message just because they were out of range when it was sent.

It will take some time to get right. There will be configuration decisions I have not made yet, coverage gaps I have not discovered yet, things that do not work the way I expect. That is fine. This is the part of building infrastructure that I actually enjoy: the iterative process of making something work, documenting what I learn, and sharing it with people who are working through the same questions.

The community is better served by people understanding that than by treating it as a format war. If your situation is different from mine, your answer might be different too. Read the comparison, sit with it, decide based on what you are actually trying to build.