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, differentbetter retrymessage behaviour,delivery, 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

Distribution	What it is	Pick it when
MeshCore Official MeshCore core team	The upstream firmware. Roles: Companion, Repeater, Room Server, GUI, KISS	You want the reference build. This is the default, and the right answer for most nodes.
EasySkyMesh PowerSaving IoTThinks	A fork tuned for lower power draw. Roles: Companion (BLE), Repeater, Room Server	Solar or battery repeaters, where current draw is the limiting factor.
Keymind Cascade mikecarper	A fork withthat echo-basedattacks retrymessage tuning.deliverability: per-hop retries so a message does not die silently at one bad hop. Development firmware. Roles: Companion (BLE, USB, Wi-Fi), Repeater, Room Server, Terminal Chat, Sensor	YouYour direct messages keep failing on multi-hop paths. This is the fork's whole reason to exist and it is the biggest real problem it solves. Also when you need a role the official flasher does not prebuild, such as Sensor or Wi-Fi companion.prebuild. ItsCosts retry defaults can degrade a busy mesh if set wrong.airtime. Read the section before you deploy it.section.
MCLite laserir	A standalone handheld messenger app. Pre-1.0. Roles: Companion only	You have a T-Deck or T-Watch and you want the device usable on its own, without a phone.
WADAMESH ALLFATHER BV	A touch-screen front end. Beta. Roles: Companion only	You have touchscreen hardware and you want an on-device map and chat.
ZephCore liquidraver	A port of MeshCore to the Zephyr RTOS. Roles: Companion (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.

PowerSaving16 has also picked up the outpath return-path fix described in the Keymind Cascade section below, so some of the deliverability work is reaching this fork too.

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.

It exists to fix one thing, and it is worth understanding properly, because the problem it targets is one most people on a multi-hop mesh have already hit without knowing what caused it.

WhatThe "Halo/Keymindproblem: retrymessages tuning"die doessilently at one bad hop

TheStock coreMeshCore idea:has afterno hop-by-hop acknowledgement and no hop-by-hop retry. A repeater forwarding a nodedirect-routed packet transmits a packet, it listensexactly foronce aand neighbourthen toforgets retransmitabout it. If itthe doesnext hop did not hear that echo,transmission (a collision, a moment of interference, the next repeater was mid-transmit and therefore deaf, a brief fade), the packet is simply gone. No node in the chain knows or cares.

The only retry anywhere in stock MeshCore is end to end: the destination sends an ACK back to the originator, and if the originator does not get that ACK it retries, eventually giving up and falling back to a flood. That has three consequences you have probably experienced:

One missed hop costs the entire message. There is no local repair. A three-hop path where each hop is 90% reliable delivers about 73% of the time, and every failure costs a full retransmission from the origin. A lost ACK makes a delivered message look failed. This is a real, open upstream bug. From the report: "messages showing failed to send on my side but the other party still gets the message and I'm left spamming them thinking it failed." Failure escalates to a flood, which is the expensive, network-wide fallback. So per-hop unreliability converts directly into mesh-wide airtime.

How bad is it in practice? One upstream user measured it: "an unreliability of approximately 45% from my location as soon as the path length is greater than or equal to 2. This means that almost half of the direct messages fail via a partially functioning path with more than 2 nodes." Another upstream user, testing a four-node chain over weak links, got 81 of 100 packets delivered on stock.

mikecarper's own description of the user experience is the clearest statement of it: it is frustrating "if you send out a message only for it to travel as far as you can throw a rock; but the companion says all is good."

The fix: listen for the echo

The central idea is elegant and costs nothing when the network is working.

A repeater forwards a packet, then listens for the next hop to forward that same packet. Overhearing that onward retransmission is an implicit, free, hop-local acknowledgement: an echo. If the echo arrives, the queued retry is cancelled and never transmits. If no echo arrives within a computed window, the repeater assumes the packethop was lost and sends it again.

That single mechanism turns a fire-and-forget forwarding chain into a per-hop-confirmed chain, without adding any new packet type and without a single extra transmission in the success case. Airtime is spent only where a hop actually failed. It applies to text messages, path and trace packets, requests and responses, and to ACK packets themselves, which is what addresses the "failed but actually delivered" bug above.

Everything else in the fork is machinery around that idea:

The recent-repeater table (recent.repeater) tracks the signal quality of neighbours it has heard, and gates retries with it. An unknown next hop gets retried (you have no evidence it is dead). A known-and-too-weak next hop does not (you have evidence, so do not burn airtime on a neighbour that cannot hear you). Repeated failures ratchet a neighbour's estimate down until it drops out of the retry set entirely, which is what stops the mechanism running away. Adaptive coding rate. Retries escalate the LoRa coding rate (CR4, CR5, CR7, then CR8). More coding rate means more forward error correction, which means the packet survives at a lower signal-to-noise ratio, at the cost of longer airtime. There areis separatea settingsnice fordiagnostic direct-routedwrinkle here: a hop that fails on a strong link is almost certainly a collision, so Cascade shortens the preamble and flood-routedgets packets,the packet out faster, while a hop that fails on a weak link is a margin problem, so it adds error correction. Note that the specific signal thresholds are heuristic. The developers of a competing implementation of the same idea say so themselves. outpath and threealtpath shippedfix presets:asymmetric paths, where a request reaches a repeater but the Presetreply Directnever retriescomes Flood retries Intended for infra41Busy backbone sites rooftop153Fixed rooftop nodes mobile1515Handhelds

This trades airtime for reliability,back and the tradeclient reports a timeout on an operation that actually worked. outpath lets you pin the return path by hand. altpath sends the reply over two different routes at once, on the theory that two independent paths are unlikely to fail together. This is real.the Whenpiece mikecarperthat proposedhas already been adopted by the featurePowerSaving upstreamfork.

(MeshCoreFlood discussionretry, #1625),with contributorprefix samm-gitfilters. objected:The "Thissame couldecho easilylogic for flood packets, plus a fix for a subtle false positive: a nearby but useless echo can wrongly satisfy the airretry incondition. noisyThe areas,docs wheregive peersthe hearexact case. If 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. Putrun a mobile preset on a busycar repeater and youa willhouse degraderepeater, your localhouse meshhearing foryour everyonecar onre-flood it.a packet from three metres away proves nothing about whether the packet escaped the valley. flood.retry.ignore lets you discount it; flood.retry.prefixes lets you define success as "a repeater that actually matters heard it", such as the mountain-top site you need to reach. Bucket bridging Theextends fullthat settingsto referencea repeater that is docs/halo_keymind_settings.mdthe ononly link between two halves of a mesh. A packet arriving from the branch.north

Whatthat "Cascadegets defaults"echoed means

by

Itanother northern node would normally cancel the retry, even though it never made it south. Buckets make the retry condition directional so the bridge keeps trying until the far side is aactually build-timereached.

profile that

Half shipsof differentit factory defaults. These are ordinary MeshCore settings,is not new inventions:code

Worth knowing before you flash anything: a good part of the Cascade delivery story is stock MeshCore features that stock ships turned off. Cascade just turns them on.

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=0path.hash.mode=2 uses 3-byte path hashes instead of stock's 1 byte. With one byte there are only 256 possible hop identifiers, so on a large mesh collisions are inevitable, and two repeaters sharing a prefix can both think a packet is for them. Upstream's own issue tracker describes the result as "route drift, blackholing, mis-forwarding, and increased retransmissions". But, as noted in the interop section above, this is also upstream'the setting that makes your traffic invisible to nodes on firmware 1.13.0 or older, and it cuts this node's stockmaximum default,advertised path from 64 hops to 21. multi.acks=1 sends the ACK more than once. The ACK is the most consequential packet in the exchange, and losing it makes a delivered message look failed, so paying a little airtime to protect it is nota reasonable trade. rxdelay=2 holds weak-signal receivers in a Cascadequeue change.)so Twostrong-signal ofpaths theseforward willfirst, surprisewhich yousuppresses ifredundant youretransmissions. doloop.detect=minimal notdrops knowpackets that look like they are set:circulating

in a loop. A fork that adds retransmission has more reason than anyone to make sure packet storms get suppressed. agc.reset.interval=8 periodically resets the SX1262's automatic gain control, which can otherwise go "deaf". A deaf receiver misses echoes, and a missed echo causes a retry that was not needed. 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.

The practical upshot: you can adopt that settings profile on stock firmware right now, without flashing a fork. Only the echo-retry, adaptive coding rate and outpath machinery actually requires Cascade. If you want most of the airtime and routing hygiene without running development firmware, set the stock values by hand and stop there.

Does it actually work? An honest answer

Cascade's own documentation contains no performance numbers at all. No before-and-after delivery rate, nothing. It is a reference manual for the settings, not a results paper. Do not let anyone tell you it ships with a validated claim.

The evidence that exists is mixed, and it splits cleanly:

path.hash.mode=2The concept is well supported. usesA 3-bytecompeting pathimplementation hashesof the same echo-retry idea was tested on real hardware over a chain of weak links and took delivery from 81 of 100 packets to 96 of 100. In simulation the same author took a 71% delivery rate on stock to 95.5% with two retries. Hop-by-hop retry with echo cancellation clearly works. Cascade's specific tuning is contested. The one head-to-head simulation available says Cascade's aggressiveness works against it. With up to 15 retries per repeater, a single message was estimated to generate around 26 direct transmissions, and the resulting collisions reduced delivery compared with a simpler implementation using two retries. mikecarper's own simulator run showed only a +2% delivery improvement, and he acknowledged it "seems to show this helps; better than showing it hurts."

His defence of the high retry counts is worth quoting, because it is directly relevant to us: "I'm in the advertsPNW thisand the mesh here is huge. I need more than 3 tries to get out there; sometimes a lot more." His numbers are tuned for a large, congested, long-path Pacific Northwest mesh. That is the mesh Mesh America is building in.

The cost, and how to set it

Retries are airtime, and in a shared channel your airtime is somebody else's collision. Three presets ship:

Preset Direct retries Flood retries What it assumes infra 4 1 A dense, busy, well-covered mesh. Defensive on every axis, and it only retries toward neighbours it hears strongly. Assumes other routes exist. rooftop (default) 15 3 A fixed node sends.with Twoa consequences.possibly Itmarginal reduceslink into a mesh that mostly works. mobile 15 15 An edge node with changing links and no alternative route, where failing to get the maximumpacket pathout thisis node'worse than the airtime spent trying.

Read that table backwards and it tells you the rule: the denser and busier your RF environment, the fewer retries you should run. In a well-covered mesh your retries are other people's advertscollisions canand recordthere fromare 64other hopsroutes anyway. A rooftop repeater inside a covered metro is arguably an infra node, not a rooftop one, whatever the preset is called. Putting mobile on a busy repeater will degrade the mesh for everyone on it.

Two hard costs to know about:

Text messages are hard-coded to 21 (attempts and you cannot tune that down. It is the pathmost fieldairtime-significant fixed value in the fork. The documentation never quantifies the airtime cost, never mentions the duty-cycle limiter, and gives no "do not enable this if..." rule. The only such guidance comes from mikecarper in the upstream discussion, where he says the features "could be turned off for the more busy locations."

The known weakness of the whole approach was named by upstream contributor samm-git when it was first proposed: "This could easily flood the air in noisy areas, where peers hear you but you don't hear the echo." That is exactly right. On an asymmetric link the next hop did get your packet, you just did not hear its echo, so you retransmit something that was already delivered. The recent-repeater signal gate is a fixedmitigation, 64not bytes,a socure.

bigger

Why hashesupstream meanshas fewernot merged it

Not because the idea was rejected. As of them).writing, And,every perrelevant upstream'spull warning,request nodesis open and unmerged, and dynamic coding rate is on firmwareMeshCore's v1.13.0own published roadmap as a to-do. What has happened instead is that upstream has not converged on whose implementation, or olderon willhow dropaggressive packetsit carryingshould multibytebe. hashes.There Upstreamare alsonow notestwo competing pull requests for the settingsame feature, the Cascade ones are large and carry conflicts (mikecarper calls it his "kitchen sink branch"), and one of them changes 74 files and has attracted no impactreview comments at all.

mikecarper's own position is worth repeating: "I don't care how this gets put into the code as long as we have some kind of retry on whatDM's packetthat's ID/hasha sizewin." He is probably right, and the thing to watch is the upstream discussion rather than this repeaterfork 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. specifically.

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. Direct messages failing on multi-hop paths? That is the problem Keymind Cascade was built for, and no other distribution addresses it. Before you flash a development build, try the stock settings profile from that section (multi.acks, rxdelay, loop.detect, agc.reset.interval), which costs you nothing and needs no fork. If you still need per-hop retries, flash Cascade and pick the preset that matches how busy your area actually is, not how the preset is named.

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. 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. 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, 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 notesnotes, documentation, issues and documentationpull requests of each project:project. github.com/meshcore-dev/MeshCore,For github.com/IoTThinks/EasySkyMesh,the github.com/mikecarper/deliverability section specifically: docs/halo_keymind_settings.md and docs/cli_commands.md on the keymindCascade branch; MeshCore discussion #1625; MeshCore pull requests #2367 (branchHALO keymindCascade)direct retry), github.com/laserir/MCLite,#2501 github.com/ALLFATHER-BV/wadamesh,(Keymind github.com/liquidraver/ZephCore.flood retry), #2586 (outpath), #2670 (competing implementation, with the hardware and simulator delivery figures) and #1923 (competing dynamic coding rate); and MeshCore issues #1342 (the 45% multi-hop failure measurement), #1775 (path instability and hash collisions) and #1834 (delivered messages reported as failed).

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