MeshCore Firmware Distributions (Forks and Ports)

There are two separate questions to answer before you flash a MeshCore node, and people often confuse them.

Which distribution do you flash? That is what this page covers. Stock MeshCore is one option. Several independent projects also build MeshCore firmware, each with a different priority: lower power draw, a touch UI, better retry behaviour, a different operating system underneath.

Which role does the node run? Companion, Repeater, Room Server and so on. That is covered on MeshCore Firmware Variants Explained. Every distribution below ships some subset of those roles, so you pick a distribution first, then a role within it.

The six distributions here are the ones offered by the Mesh America Device Configurator. There are other MeshCore forks in the wild; these are the ones you can flash from our tooling.

They all speak the same protocol

This is the part that matters most and the part people worry about. All six run the MeshCore protocol and interoperate on the same mesh. A ZephCore repeater will forward packets from a stock companion node. A WADAMESH handset will DM an MCLite handset. You do not need everyone in your local mesh on the same firmware.

What does vary is settings, defaults, and how much airtime a node uses. Those can affect the mesh even when the packets themselves are valid. The Keymind Cascade section below has a concrete example.

The six at a glance

Distribution	Maintainer	What it is	Pick it when
MeshCore Official	MeshCore core team	Upstream firmware	You want the reference build. This is the default and the right answer for most nodes.
EasySkyMesh PowerSaving	IoTThinks	Fork tuned for power	Solar or battery repeaters where current draw is the limiting factor.
Keymind Cascade	mikecarper	Dev fork, retry tuning	You want echo-based retries or a role the official flasher does not prebuild. Read the caveats first.
MCLite	laserir	Standalone handheld app	T-Deck or T-Watch, and you want the device usable without a phone.
WADAMESH	ALLFATHER BV	Touch UI front end	Touchscreen hardware, and you want an on-device map and chat.
ZephCore	liquidraver	Port to Zephyr RTOS	Power-sensitive nodes, or a board only ZephCore supports.

MeshCore Official

The upstream project, maintained by the MeshCore core team at github.com/meshcore-dev/MeshCore and originally created by Scott Powell (Ripple Radios). MIT licensed. This is what flasher.meshcore.io serves, and what the Mesh America configurator serves under "MeshCore Official".

Roles built by the official flasher: Companion (BLE), Companion (USB), Repeater, Room Server, plus GUI builds for screen-equipped boards and a KISS radio build.
Hardware: roughly 59 device entries across 12 manufacturers in the current flasher catalog, covering Heltec, LilyGo, RAK, Seeed, Elecrow and others.
Why start here: it is the build every other project tracks. Bug reports get triaged against it, the phone apps are developed against it, and the community assumes it unless told otherwise.

Note on Sensor firmware. The upstream repository contains a simple_sensor example application, but the official flasher does not build it. If you want a prebuilt sensor binary you have to get it from a fork (Keymind Cascade ships them) or build it yourself. See MeshCore Sensor Nodes for how sensor telemetry actually works.

EasySkyMesh PowerSaving

Maintained by IoTThinks at github.com/IoTThinks/EasySkyMesh, with the source changes in github.com/IoTThinks/MeshCore. The project's own description of it:

PowerSaving firmware is MeshCore firmware that has been highly optimized for lower power usage. Functionally it works the same as MeshCore, and eventually many of the changes make their way into the MeshCore official firmware.

That last clause is the important one. This is not a permanent divergence. It is a proving ground, and its power work has a track record of landing upstream.

Roles: Repeater, Companion (BLE), Room Server.
Hardware: around 42 device entries, both nRF52 and ESP32, including the GAT562 kits, Heltec T114 and MeshSolar, LilyGo T-Echo, and RAK boards.
Versioning: its own scheme, currently the PowerSaving16 series. The headline claim on the PowerSaving15 release was 15 mA for ESP32 BLE companions, and no time drift on repeaters.
Pick it for: a repeater on solar with a marginal power budget, where every milliamp of idle draw shortens the winter runtime.

We have a separate page on this one: EasySkyMesh: Third-Party Power-Optimized MeshCore Fork. Note that EasySkyMesh is not available through the official MeshCore flasher.

Keymind Cascade

A fork of meshcore-dev/MeshCore by GitHub user mikecarper, on the keymindCascade branch. MIT licensed, tracking upstream v1.16.x. This is the most involved of the six and the one that needs the most care, so it gets the most space.

It is explicitly development firmware. Every GitHub release is marked pre-release, every version string contains -dev-, and builds are pinned to a commit hash rather than a stable tag. Treat it accordingly.

What "Halo/Keymind retry tuning" does

The core idea: after a node transmits a packet, it listens for a neighbour to retransmit it. If it does not hear that echo, it assumes the packet was lost and sends it again. There are separate knobs for direct-routed and flood-routed packets, and three shipped presets:

Preset	Direct retries	Flood retries	Intended for
`infra`	4	1	Busy backbone sites
`rooftop`	15	3	Fixed rooftop nodes
`mobile`	15	15	Handhelds

This trades airtime for reliability, and that trade is real. When mikecarper proposed the feature upstream (MeshCore discussion #1625), contributor samm-git pushed back: it could flood the air in noisy areas, where peers hear you but you do not hear the echo. mikecarper's answer was that it can be turned off. Both are right. If you put a mobile preset on a busy repeater you will hurt your local mesh. The full settings reference is at docs/halo_keymind_settings.md on the branch, and it is a genuinely good document.

What "Cascade defaults" means

Nothing exotic. It is a build-time profile that ships different factory defaults. Every one of these is a normal MeshCore CLI setting you could set by hand on stock firmware:

path.hash.mode=2      loop.detect=minimal    rxdelay=2
agc.reset.interval=8  advert.interval=0      flood.advert.interval=83
multi.acks=1          companion.manual.add=1 companion.autoadd=0

Two of those will surprise you if you do not know they are set:

companion.autoadd=0 means your contact list does not fill itself in from adverts. You add contacts manually. New users read this as a broken radio. It is not.
path.hash.mode=2 uses 3-byte path hashes. Upstream's own CLI docs warn that this caps flood propagation at 21 hops (down from 64 at the default) and that nodes running firmware 1.13.0 or older will drop packets carrying multibyte path hashes. On a modern mesh this is fine. On a mixed-vintage mesh it is something to check.

Roles, builds and gotchas

Roles: Companion (BLE), Companion (USB), Companion (Wi-Fi), Repeater, Room Server, Terminal Chat, Sensor. Seven, against the official flasher's smaller set. Terminal Chat, Sensor and Companion Wi-Fi are not Keymind inventions; they are upstream MeshCore example applications that the official flasher does not build. Keymind's contribution is shipping them as prebuilt binaries, which is a real convenience.
Hardware: the widest catalog of the six, roughly 84 devices across 23 manufacturers.
Two builds: a standard one and a Logging one. The Logging build adds diagnostic logging and the MQTT observer builds.
Gotcha: the Logging catalog contains no BLE companion builds at all. If you want BLE and logging together, this catalog cannot give it to you. The repo does not say whether that is deliberate.
Gotcha: as of writing, the catalogs the configurator serves are pinned a couple of point releases behind the fork's newest builds.

Unverified: the repository does not state anywhere what "Halo", "Keymind" or "Cascade" refer to, and there is no third-party coverage of this fork. We are not going to guess. Wire compatibility with stock MeshCore 1.14 and newer is a reasonable inference (it is the same codebase, the retry logic is local transmit behaviour, and the Cascade settings all exist upstream), but no primary source states it outright.

MCLite

Maintained by GitHub user laserir at github.com/laserir/MCLite. MIT licensed. This one is not a fork: it is a separate application that pulls MeshCore in as a library and puts its own interface on top.

The point of MCLite is a radio that works on its own. No phone, no pairing, no account. Turn it on and message people.

Hardware: two boards only. LilyGo T-Deck Plus and LilyGo T-Watch Ultra. An SD card is required.
Configuration: a single config.json on the SD card, built with an offline HTML config tool. Fleet Mode generates a folder and keypair per device, so one person can configure a whole group and hand out cards. Boot with a blank card and it generates its own identity and a usable default config.
Features stock does not have: SOS broadcast, low-battery alerts to contacts, MGRS location format, offline map tiles from SD, quick replies, night-vision themes.
Contacts are curated, not automatic. Overheard nodes land in a Heard Adverts list and you promote the ones you want. The project is explicit that this differs from the stock apps. A sparse contact list on a fresh device is expected behaviour, not weak reception.
Compatibility: fully compatible with other MeshCore devices and with the official iOS and Android apps. It also acts as a normal companion radio over BLE, Wi-Fi or USB.

The limitation you need to know about. Messages you type on the device do not show up in the companion phone app. Sending works fine over the mesh; the message just never appears in the app's history. This is a limit of the MeshCore companion protocol, which has no frame for an outgoing message composed on the firmware side. MCLite cannot fix it. If you want a complete, correctly-sided history in the app, compose from the app.

Pre-1.0 and described by its own author as experimental software, not a certified radio product. Current release is the 0.4.x series.

WADAMESH

Maintained by ALLFATHER BV (Belgium) at github.com/ALLFATHER-BV/wadamesh, with a project site at wadamesh.com. GPL-3.0-or-later. Like MCLite it is an application rather than a fork: an LVGL touch interface built against an MIT-licensed MeshCore fork the same org maintains.

Its own summary: a full touch-screen interface for MeshCore, with the same protocol and the same phone-app companion as stock, just a richer front end on the device.

Hardware: through the Mesh America configurator, Heltec V4 with the touch expansion kit, and LilyGo T-Deck. The project's own flasher additionally lists ThinkNode M9, RAK WisMesh Tap V2 and Tanmatsu, though those sit on its beta channel.
What you get: on-device chat with delivery receipts, contacts with route trace and telemetry, a pannable OpenStreetMap view with offline tile packs and contact positions plotted on it, and full radio settings without a phone.
Companion at the same time: it is a standalone touch device and a companion radio simultaneously, and it will take BLE, Wi-Fi and USB connections at once.
Languages: 11 non-English translations as of the current stable.

Everything is beta. There is no 1.0; releases are numbered beta_NN and the test channel moves quickly. The current stable is beta_40.

The Heltec V4 is the constrained board. It has 2 MB of PSRAM and no SD card slot, and several features are reduced or absent on it. If you have the choice, the T-Deck is the better WADAMESH target.

ZephCore

Maintained by GitHub user liquidraver at github.com/liquidraver/ZephCore. MIT licensed. This is the most architecturally different of the six: a port of MeshCore from Arduino to the Zephyr RTOS, aiming at full protocol compatibility with the Arduino firmware and the MeshCore mobile apps.

The reason that matters is power. The Arduino build runs a cooperative loop() and the CPU busy-waits unless something explicitly sleeps it. ZephCore is event driven, so the CPU sits in a wait-for-interrupt state between events. On top of that:

LoRa RX duty cycling. CAD-based receive windowing takes LoRa receive current from roughly 10 to 15 mA down to roughly 3 to 5 mA. On by default for SX1262 companion and repeater builds. Not enabled for LR1110 (a mid-preamble lock issue) or SX127x.
Adaptive contention window. Stock MeshCore has three static delay settings (txdelay, rxdelay, direct.txdelay) that apply the same retransmit jitter no matter what the local conditions are. ZephCore replaces them with a system that measures actual contention: it counts how many neighbours retransmit the same flood packet it just sent, and sizes its delay from that. Near-zero delay in a quiet linear chain, more in a dense cluster. This is local behaviour with no wire changes, so it works alongside Arduino repeaters.
Adaptive Power Control. Compiled in, off by default. Turn it on per node and it drops TX power when echo SNR shows excess margin.

Roles: Companion (BLE, USB and TCP), Repeater, Room Server, and an ESP32-only Observer role that publishes received packets to MQTT over Wi-Fi. The Mesh America configurator currently serves the companion and repeater builds.
Hardware: around 31 device entries, and the list includes boards the other distributions do not reach, such as the nRF54L15 and the EFR32MG24.
Worth knowing: the README states plainly that the project is almost entirely AI-assisted code, leaning heavily on the official MeshCore repository. That is the maintainer's own disclosure, not our characterisation. Judge it on the same terms as any other firmware: read the code, test before you deploy.

How to choose

Ordinary advice, in order:

Default to MeshCore Official. If nothing below applies to you, flash the official build and stop reading.
Solar or battery repeater with a tight power budget? Look at EasySkyMesh PowerSaving or ZephCore. Both attack idle draw, from different angles.
T-Deck, T-Watch or a touchscreen board, and you want it usable without a phone? MCLite for the keyboard-and-SOS, field-deployment angle. WADAMESH for the map-and-touch-UI angle.
Your board is not on the official flasher? Check the Keymind Cascade and ZephCore catalogs. Between them they cover a lot of hardware upstream does not build for.
You want a Sensor or Terminal Chat binary without setting up a build environment? Keymind Cascade prebuilds them.

Whatever you pick, the node still has to be on the right frequency, bandwidth, spreading factor and coding rate for your region and your local mesh. Firmware choice does not change that, and getting it wrong is still the most common reason a new node hears nothing.

A note on maintenance

Five of these six are single-maintainer projects. Several are explicitly beta or pre-release. That is not a reason to avoid them, but it is a reason to keep a stock build handy, to know how to reflash a node you cannot reach easily, and to think twice before putting experimental firmware on a repeater at the top of a tower. See Flashing MeshCore Firmware OTA before you deploy anything you cannot get back to.

Sources: the Mesh America Device Configurator provider catalogs (apps.meshamerica.com); the official MeshCore flasher catalog (flasher.meshcore.io); and the repositories, release notes and documentation of each project: github.com/meshcore-dev/MeshCore, github.com/IoTThinks/EasySkyMesh, github.com/mikecarper/MeshCore (branch keymindCascade), github.com/laserir/MCLite, github.com/ALLFATHER-BV/wadamesh, github.com/liquidraver/ZephCore.

Firmware projects move fast. Device counts, version numbers and role availability were accurate when this page was written and should be checked against the configurator and each project's releases page before you rely on them.