Skip to main content

MeshCore Firmware Distributions

Accurate as of 13 July 2026. Firmware projects move fast. Every version number, device count and current figure below should be re-checked against the configurator and each project's releases page before you rely on it.

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, different retry behaviour, a different operating system underneath. Some are forks of the upstream code, some are ports, and two are separate applications that link MeshCore as a library. "Distribution" is our umbrella word for all of them.

Which role does the node run? Companion, Repeater, Room Server and so on. That is covered on MeshCore Firmware Variants Explained. 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.

First: none of this is permanent

Flashing is reversible. If you do not like a distribution, flash a different one. You are not going to brick a node by changing firmware through the web flasher, and going back to stock is always available.

What you can lose is state. A node's identity keypair, its contact list and its saved radio settings live in flash storage, and some install paths wipe that storage while others preserve it. A full or "clean" install typically resets the node to a new identity, which means your contacts will see you as a new node and will have to re-add you. Assume a distribution change resets your identity unless the project says otherwise, and write down your radio settings (frequency, bandwidth, spreading factor, coding rate) before you start so you can put them back.

Start here before you flash anything: Flashing MeshCore Firmware, and for a node you cannot physically reach, Flashing MeshCore Firmware OTA.

Do they all interoperate?

That is the question everyone asks, so here is a careful answer rather than a comfortable one.

All six are built on the MeshCore protocol and all six are intended to interoperate on the same mesh. Each project says so about itself: ZephCore describes itself as "aiming for full protocol compatibility" with the Arduino firmware and the mobile apps, WADAMESH says it uses "the same MeshCore protocol and phone-app companion as stock", and MCLite says it is compatible with other MeshCore devices and the official apps.

Those are the projects' own claims about themselves. We are not aware of any independent, published interoperability test across all six, and we have not run one. Treat the general claim as well-founded but not proven.

There is at least one known case where compatibility genuinely breaks, and it is not hypothetical:

  • Path hash size. MeshCore's path.hash.mode setting controls how many bytes a node uses for path hashes in the adverts it sends. Upstream's own CLI documentation warns that firmware v1.13.0 and older will drop packets carrying multibyte path hashes. Keymind Cascade ships path.hash.mode=2 (3-byte) as a factory default, and MCLite's README tells you to keep it at 0 "for compatibility with pre-v1.15 peers". If your local mesh still has old nodes on it, this setting will make some traffic silently disappear.

What else varies between distributions is settings, defaults, and how much airtime a node spends. Those affect the mesh even when every packet is valid. The Keymind Cascade section has a worked example.

The six at a glance

DistributionMaintainer What it isRoles Pick it when MeshCore Official
MeshCore core team UpstreamThe firmwareupstream firmware.

Roles: Companion, Repeater, Room Server, GUI, KISS You want the reference build. TheThis is the default, and the right answer for most nodes. EasySkyMesh PowerSaving
IoTThinks IoTThinksForkA fork tuned for lower power draw.

Roles: Companion (BLE), Repeater, Room Server Solar or battery repeatersrepeaters, where current draw is the limiting factor. Keymind Cascade
mikecarper mikecarperFork.A Retryfork with echo-based retry tuning. Development firmwarefirmware.

Roles: Companion (BLE/USB/BLE, USB, Wi-Fi), Repeater, Room Server, Terminal Chat, Sensor You need a role the official flasher does not prebuild.prebuild, such as Sensor or Wi-Fi companion.

Its retry defaults can harmdegrade a busy mesh if set wrong. Read the section.section before you deploy it. MCLite
laserir laserirStandaloneA standalone handheld messenger app. Pre-1.00.

Roles: Companion only You have a T-Deck or T-Watch,Watch and you want the device usable on its own, without a phone. WADAMESH
ALLFATHER BV TouchA UItouch-screen front end. BetaBeta.

Roles: Companion only TouchscreenYou hardware,have touchscreen hardware and you want an on-device map and chat. ZephCore
liquidraver liquidraverPortA port of MeshCore to the Zephyr RTOSRTOS.

Roles: Companion (BLE/USB/BLE, USB, TCP), Repeater, Room Server, Observer Power-sensitive nodes, or a board that only ZephCore supports.

Each distribution ships its own selection of roles. Some build roles the official flasher does not (Keymind Cascade builds Sensor, Terminal Chat and Companion Wi-Fi; ZephCore builds a TCP companion and an Observer). It is not a strict subset of the official set.

MeshCore Official

The upstream project, at github.com/meshcore-dev/MeshCore, created by Scott Powell (Ripple Radios) and now maintained by the MeshCore core team. 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, GUI (and a GUI-with-SD variant) for screen-equipped boards, and a KISS radio build. Seven role keys, exactly.
  • Hardware: 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, so the source exists. The official flasher does not build it: there is no Sensor role in the flasher catalog, and no sensor binaries in the upstream releases. If you want a prebuilt sensor binary you either build it yourself or take one from a fork (Keymind Cascade ships them). See MeshCore Sensor Nodes for how sensor telemetry actually works.

Note on Wi-Fi companion. Same story. Wi-Fi companion is a real, separate build, but the official flasher does not ship it, because the SSID and password are compiled in. You build it yourself or take a prebuilt binary from a fork.

EasySkyMesh PowerSaving

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

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 project's stated intent. We have not independently confirmed which of its changes have actually been merged upstream, so read it as an aim rather than a record.

  • Roles: Repeater, Companion (BLE), Room Server.
  • Hardware: 42 device entries, split evenly between 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.

About the power numbers. The PowerSaving15 release is titled "15mA for ESP32 BLE Companions and no time-drift for repeaters". Read the release's own table before you budget a solar install on that headline: it reports Heltec v3 at 19.6 mA, Heltec v4.3 at 24.9 mA with the front-end module on and 18 mA with it off, Xiao S3 at 16.3 mA, and Xiao C3 at 15.1 mA. Only the Xiao C3 actually lands near 15 mA. The "no time drift" fix is tagged BETA in that same release. These are the project's own measurements; we know of no independent verification. The direction is right and the work is real, but size your battery off the figure for your board, not the headline.

See also EasySkyMesh: Third-Party Power-Optimized MeshCore Fork. 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 (the copyright line is inherited from upstream, Scott Powell / rippleradios.com). Tracks upstream v1.16.x.

It is development firmware. Every version string carries -dev-, builds are pinned to a commit hash rather than a stable tag, and some releases are flagged pre-release. It moves fast. Treat it accordingly, and do not put it on a node you cannot easily reflash.

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 settings for direct-routed and flood-routed packets, and three shipped presets:

Preset Direct retries Flood retries Intended for infra41Busy backbone sites rooftop153Fixed rooftop nodes mobile1515Handhelds

This trades airtime for reliability, and the trade is real. When mikecarper proposed the feature upstream (MeshCore discussion #1625), contributor samm-git objected: "This could easily flood the air in noisy areas, where peers hear you but you don't hear the echo." mikecarper's reply was "Yep. That's why it can be turned off," and he acknowledged in the same thread that the feature "will use up more airtime". Both positions are correct. Put a mobile preset on a busy repeater and you will degrade your local mesh for everyone on it. The full settings reference is docs/halo_keymind_settings.md on the branch.

What "Cascade defaults" means

It is a build-time profile that ships different factory defaults. These are ordinary MeshCore settings, not new inventions:

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

(advert.interval=0 is also upstream's stock default, so it is not a Cascade change.) Two of these 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 by hand. New users read this as a broken radio. It is not.
  • path.hash.mode=2 uses 3-byte path hashes in the adverts this node sends. Two consequences. It reduces the maximum path this node's adverts can record from 64 hops to 21 (the path field is a fixed 64 bytes, so bigger hashes means fewer of them). And, per upstream's warning, nodes on firmware v1.13.0 or older will drop packets carrying multibyte hashes. Upstream also notes the setting "has no impact on what packet ID/hash size this repeater forwards", so it governs what this node emits, not what it relays. On an all-modern mesh this is fine. On a mixed-vintage mesh, check before you deploy.

Roles, builds and gotchas

  • Roles: Companion (BLE), Companion (USB), Companion (Wi-Fi), Repeater, Room Server, Terminal Chat, Sensor. Terminal Chat, Sensor and Companion Wi-Fi are not Keymind inventions. They are upstream MeshCore build targets that the official flasher does not prebuild for you. Keymind's contribution is shipping them as ready binaries, which is a genuine convenience.
  • Hardware: the widest catalog of the six, 84 devices across 23 manufacturers.
  • Two builds: standard, and a Logging build that adds diagnostic logging plus the MQTT observer binaries.
  • Gotcha: the Logging catalog lists no BLE companion builds, so you cannot select one from the configurator, even though the Logging release does contain BLE binaries. The repo does not say whether that gap is deliberate.
  • Gotcha: the catalogs the configurator serves are pinned a couple of point releases behind the fork's newest builds.

Not documented anywhere: what "Halo", "Keymind" and "Cascade" actually refer to. The repository does not say and there is no third-party coverage of this fork. We are not going to guess.

MCLite

Maintained by GitHub user laserir at github.com/laserir/MCLite. MIT licensed. Not a fork: it is a separate application that pulls MeshCore in as a library and puts its own interface on top. Pre-1.0, currently the 0.4.x series, and described by its own author as experimental software, not a certified radio product.

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

  • Role: companion only. It is not a repeater, room server or sensor. It talks to those.
  • Hardware: two boards. 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 ship: 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. A sparse contact list on a fresh device is expected behaviour, not weak reception.

Compatibility, with the caveat. MCLite says it is compatible with other MeshCore devices and the official iOS and Android apps, and it works as a normal companion radio over BLE, Wi-Fi or USB (one transport, one client at a time). But "fully compatible" overstates it, and the project's own documentation shows why:

  • Messages you type on the device do not appear in the companion phone app. Sending works fine over the mesh. The message simply never shows up in the app's history. This is a limit of the MeshCore companion protocol, whose frame set has no type 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.
  • Keep path_hash_mode at 0 if your mesh has pre-v1.15 nodes on it.

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 organisation 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.

  • Role: companion only, with an on-device UI.
  • Hardware, through the Mesh America configurator: Heltec V4 with the touch expansion kit, and LilyGo T-Deck. The project's own flasher covers more: ThinkNode M9 and RAK WisMesh Tap V2 are beta-channel only, and the Tanmatsu is not USB-flashed at all (it installs from the Tanmatsu app store).
  • 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: the project states it serves BLE, Wi-Fi and USB connections simultaneously while still working as a standalone touch device.
  • Languages: the beta_40 release notes claim 11 non-English translations. The project website says "11 languages" and lists only 10 non-English ones. The two sources disagree; the release notes are the newer of the two.

Everything is beta. There is no 1.0. Releases are numbered beta_NN. beta_40 was the current stable at the time of writing, with beta_41 through beta_44 already out as pre-releases on the test channel.

The Heltec V4 is the constrained board. 2 MB of PSRAM and no SD card slot, and several features are reduced or absent on it as a result. 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. The most architecturally different of the six: a port of MeshCore from Arduino to the Zephyr RTOS (a real-time operating system), 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 idles between events instead of spinning. On top of that:

  • LoRa receive duty cycling. The radio sleeps between short listening windows instead of receiving continuously. The project reports this cutting LoRa receive current from roughly 10 to 15 mA down to roughly 3 to 5 mA. That is the project's own figure, with no stated method, and we know of no independent measurement. It is off by default. You turn it on per node at runtime with set rxduty on. It is not available on LR1110 (a mid-preamble lock issue) or SX127x radios. If you are choosing ZephCore for battery life, this is the switch you came for, and it is not thrown for you.
  • Adaptive contention window. Stock MeshCore has three static delay settings (txdelay, rxdelay, direct.txdelay) that apply the same retransmit jitter regardless of local conditions. 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. The project states this is local behaviour with no changes to what goes over the air, so it works alongside Arduino repeaters.
  • Adaptive Power Control. Compiled in, off by default. Enable it per node and it reduces transmit power when echo signal-to-noise 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: 31 device entries in the catalog. The README additionally lists boards you can build for yourself but which are not in the catalog, including the nRF54L15 and the EFR32MG24. Do not go looking for those in the configurator.
  • Worth knowing: the README discloses, in its own words, that the project is "99,9% claude and cursor backed" and relies heavily on the official MeshCore repository. That is the maintainer's own note, not our characterisation. Judge it the way you would judge any firmware: read the code, test before you deploy.

How to choose

  1. Default to MeshCore Official. If nothing below applies, flash the official build and stop reading. If your board has a screen, the official GUI build is included.
  2. Solar or battery repeater on a tight power budget? EasySkyMesh PowerSaving or ZephCore. Both attack idle draw, from different angles. Size your battery off the figure for your specific board, not the headline. If you use ZephCore, remember to actually turn on rxduty.
  3. T-Deck, T-Watch or another 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. Both are companion-only and both are pre-1.0.
  4. 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.
  5. You want a Sensor, Terminal Chat or Wi-Fi companion binary without setting up a build environment? Keymind Cascade prebuilds them. Remember it is development firmware, and read its retry section before putting it on anything that repeats.

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 a mismatch here is a very common reason a new node hears nothing at all. Get those four values from your local mesh community before you go looking for firmware bugs.

A note on maintenance

These are community projects of varying size. Upstream MeshCore has a large contributor base; ZephCore and WADAMESH have several contributors each; MCLite and EasySkyMesh are very small teams. Several of these distributions are explicitly beta or pre-release.

That is not a reason to avoid them. It is a reason to keep a stock build handy, to know how to reflash a node you cannot easily reach, and to think hard before putting experimental firmware on a repeater at the top of a tower.

Sources: the Mesh America Device Configurator provider catalogs (apps.meshamerica.com); the official MeshCore flasher catalog (flasher.meshcore.io); MeshCore discussion #1625; 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.

Where a figure comes from a project's own testing and has not been independently verified, this page says so.

Back to top