MeshCore Firmware at a Glance: Official Version vs. Evo Fork

The official MeshCore firmware (meshcore-dev/MeshCore)

MeshCore is a lightweight, portable C++ library for multi-hop packet routing over LoRa and other packet radios, designed for decentralized, internet-independent communication networks. The project deliberately positions itself between Meshtastic (which is geared more toward chat traffic) and Reticulum (a comprehensive networking framework), focusing on lightweight multi-hop routing for embedded applications.

The firmware is provided in several roles that differ significantly in behavior:

• Companion Radio — A client device that connects to a chat app via BLE, USB, or Wi-Fi. Companion nodes deliberately do not forward packets to avoid unfavorable routing paths.
• Repeater — Extends the network range by forwarding messages.
• Room Server — a type of BBS server for shared posts.
• Sensor — A telemetry node with ACL support.
• KISS Modem — A serial KISS bridge for host applications.

Pre-compiled binaries can be flashed to a wide range of LoRa hardware (Heltec, RAK Wireless, Ebyte, Seeed, etc.) using the Web Flasher at flasher.meshcore.dev or https://meshcore.io/flasher, without having to compile them yourself. Repeater and Room Server firmware is configured via config.meshcore.io (USB) or remotely via LoRa from the mobile apps. The roadmap includes, among other things, ACLs for repeaters, standardized bridge mode, advanced zero-hop neighbor discovery, LZW message compression, dynamic coding rate, and, in the long term, a V2 protocol specification.

Airtime management in the official firmware relies on classic duty-cycle checks per transmission, a fixed hop limit, and role-based routing (companion nodes do not repeat). A rolling duty-cycle window and adaptive flood-advert limit are open as pull requests (PR #1297, #1338), but are not yet included in the main branch.

MeshCore-Evo (mattzzw/MeshCore-Evo)

MeshCore-Evo is explicitly intended as a friendly fork of the official codebase. The goal is not to build an alternative mesh platform, but to provide repeater firmware with selected, not-yet-merged upstream PRs and additional patches—especially for operators of large or dense networks. The fork is regularly updated to the latest version of the official dev- or main-branch and transparently discloses which changes have been incorporated in each release.

The recurring core changes compared to the official build are:

1. Token-Bucket Duty-Cycle Enforcement (Upstream PR #1297). This means that the TX airtime budget is no longer managed per transmission but within a rolling time window. This allows central, heavily trafficked repeaters to operate more robustly without violating the regulatory 1% or 10% duty cycle limits (ETSI 868 MHz).
2. Limit Flood Advert Packet Forwarding (PR #1338). A new parameter flood.advert.base (floating between 0 and 1, default ~0.308) probabilistically determines what proportion of received flood ads are forwarded at all. 0 completely disables flood ad forwarding; 1 forwards everything. The reason for this is that, in dense meshes, flood ads consume a significant portion of airtime.
3. Longer advert intervals: flood.advert.interval and advert.interval can be set significantly higher than in the upstream—up to 168 hours (weekly flood ads). The release notes recommend, for example, flood.advert.interval=168 and advert.interval=240 (every 4 hours).
4. EU/Narrow LoRa defaults on freshly flashed boards, which prevents misconfigurations in European deployments.
5. Hardware-specific patches: For the RAK4631 variant, the boot lockout voltage has been lowered (e.g., from 3.3 V to 3.1 V or 0 V), so that boards with LiFePo4 or LTO cells (such as the uart.cz boards) can boot at all. In addition, earlier builds contained an undocumented register patch to improve the RX sensitivity of the Heltec V4 (PR #1398, now merged into upstream).

The current Evo releases are based on MeshCore 1.13/1.14 and provide only repeater firmware—no companion or room server builds. The supported hardware set (Ebyte EoRa-S3, Heltec CT62, Heltec Mesh Solar, RAK4631, generic E22 SX1262/SX1268, etc.) is a subset of the official hardware list, focused on common repeater platforms.

Direct Comparison

Important to note: MeshCore-Evo is protocol-compatible with the official firmware. An Evo repeater communicates with Companion nodes and Room servers from the upstream build without any modifications. The fork therefore does not replace the ecosystem, but rather optimizes a specific node type for networks where airtime and ad flood would otherwise become a problem.

Hardware Dependencies

Both firmwares essentially support the same hardware base: nRF52840-based boards (RAK4631, Heltec Mesh Node T114, Heltec Mesh Solar), ESP32/ESP32-S3 boards (Heltec V3/V4, Ebyte EoRa-S3, LilyGo T-Beam, T3-S3), as well as generic SX1262/SX1268 modules. Since Evo is based on the official board definitions, newly added devices in the upstream are automatically buildable for Evo as well—however, the published binaries only cover a curated subset. Those using exotic or very new hardware are better off with the official flasher; those operating central repeaters on standard hardware benefit from the Evo feature set.

Alternatives in the MeshCore ecosystem and beyond

There are several relevant projects related to MeshCore itself:

• liamcottle/meshcore.js — Node.js library and web client (app.meshcore.nz) for companion firmware.
• fdlamotte/meshcore-cli — Python command-line client.
• config.meshcore.dev / config.meshcore.io — Web-based configuration tools for repeaters and room servers.

Notable alternative mesh protocols and firmwares outside of MeshCore include:

• Meshtastic (meshtastic.org) — the market leader in the LoRa mesh sector, with a broader app ecosystem and larger community, but featuring a different routing approach and higher overhead, which leads to airtime issues more quickly in dense networks.
• Reticulum / RNS (reticulum.network) — a universal, cryptographically secure networking stack that is not limited to LoRa. Significantly more comprehensive than MeshCore, but more resource-intensive.
• disaster.radio — an older open-source project for emergency communications via LoRa, now less active.
• LoRa APRS / OE5BPA firmware — for amateur radio operators in the APRS context; not a classic mesh, but part of the same hardware ecosystem.

For pure repeater operation in large MeshCore networks, Evo is currently the most obvious alternative to the Upstream firmware. On the other hand, if you’re running Companion or Room Server nodes or need the latest Flasher integration, meshcore-dev/MeshCore is your best bet—and you can deploy Evo specifically where it’s needed most: on the central, heavily trafficked repeaters.

Sources

• meshcore-dev/MeshCore — official repository: https://github.com/meshcore-dev/MeshCore
• mattzzw/MeshCore-Evo — fork repository: https://github.com/mattzzw/MeshCore-Evo
• MeshCore-Evo Release Notes: https://github.com/mattzzw/MeshCore-Evo/releases
• PR #1297 “Implement token bucket duty cycle enforcement”: https://github.com/meshcore-dev/MeshCore/pull/1297
• PR #1338 “Limit flood advert packet forwarding”: https://github.com/meshcore-dev/MeshCore/pull/1338
• Issue #817 “Rolling window duty cycle management”: https://github.com/meshcore-dev/MeshCore/issues/817
• Issue #1223 (Flood-Advert-Proposal): https://github.com/meshcore-dev/MeshCore/issues/1223
• Issue #1572 (RAK4631 lockout voltage): https://github.com/meshcore-dev/MeshCore/issues/1572
• MeshCore Documentation: https://docs.meshcore.io
• MeshCore Flasher: https://meshcore.io/flasher