MeshCore Firmware

Firmware variants, flashing procedures, and update management for MeshCore nodes.

MeshCore Firmware Variants Explained

Accurate as of 13 July 2026. Firmware version numbers below should be checked against the current releases before you rely on them.

MeshCore is built in several distinct firmware types, each designed for a specific role in the mesh. Choosing the right one matters: the roles are not interchangeable, and a node flashed as a Repeater cannot be used as a personal messenger.

This page covers node roles. On this page, "variant" always means role. There is a second, separate choice: which distribution you flash. Stock MeshCore is one option, and several independent projects (EasySkyMesh, Keymind Cascade, MCLite, WADAMESH, ZephCore) build their own MeshCore firmware with different priorities. See MeshCore Firmware Distributions. Pick a distribution first, then a role within it.

The Firmware Variants

Companion

The Companion firmware is for user-facing nodes. It is what you run on your personal device to send and receive messages through the MeshCore mobile app.

Repeater

The Repeater firmware turns a node into dedicated mesh infrastructure. It has no user interface and no messaging capability of its own.

A MeshCore repeater is not a repeat-everything flood relay. This is the single most common misunderstanding, and it is MeshCore's main architectural difference from other LoRa mesh systems. Upstream's FAQ puts it in bold: a MeshCore repeater "does not forward or retransmit every packet it receives, unlike other LoRa mesh systems."

Room Server

The Room Server firmware creates a store-and-forward message room. It works like a small BBS or persistent group chat reachable over LoRa.

GUI

For boards with a screen, the official flasher builds GUI firmware (and a GUI-with-SD-card variant). A GUI node is a Companion with an on-device interface, not a separate network role: it messages and it does not relay.

KISS Radio

A KISS TNC build. It turns the node into a plain modem driven by a host computer, rather than a participant in the mesh in its own right. See MeshCore KISS Modem Protocol.

Sensor: read this carefully

Sensor firmware is the most misunderstood item in this list, so be precise about what exists.

Summary Table

Role Messages Relays for others Stores messages Prebuilt by official flasher
Companion (BLE / USB) Yes No Its own only Yes
Companion (Wi-Fi) Yes No Its own only No
Self-compiled, or from a fork
Repeater No Yes, along known paths. Not everything No Yes
Room Server No No Yes, that room's posts Yes
GUI Yes, on device No Its own only Yes, on screen-equipped boards
KISS Radio No, host-driven No No Yes
Sensor No No No No
Source is upstream; binaries from forks or your own build

Sources: the official MeshCore flasher catalog (flasher.meshcore.io), the MeshCore FAQ, and the firmware repository at github.com/meshcore-dev/MeshCore.

MeshCore Firmware Distributions

Accurate as of 13 July 2026. Firmware moves fast. Check versions and device counts against the configurator before relying on them.

Two different choices get confused with each other.

Which distribution? That is this page. Stock MeshCore, or one of five community builds that each do something different: save power, add a touchscreen, make messages more likely to arrive.

Which role? Companion, Repeater, Room Server. That is MeshCore Firmware Variants Explained. Pick a distribution first, then a role inside it.

These six are the ones you can flash from the Mesh America Device Configurator. There are more distributions being added all the time.

You can always change your mind

Flashing is reversible. You are not going to brick your radio, and you can always go back to stock.

What you can lose is your node identity and contact list. A clean install usually gives the node a new identity, so your contacts will see you as a new person and have to add you again. Write down your radio settings (frequency, bandwidth, spreading factor, coding rate) before you start.

See Flashing MeshCore Firmware, or Flashing OTA for a node you cannot reach.

Do they all work together?

All of the distributions listed on this page attempt to adhere to the official MeshCore protocol.

The six at a glance

Distribution

What it is

Pick it when

MeshCore Official

The standard firmware.

Almost always. This is the right answer for most nodes.

EasySkyMesh PowerSaving

Tuned to use less power.

Solar or battery repeaters, where battery life is your limit.

Keymind Cascade

Improves deliverability and network performance

Experimental.

Your Direct Messages keep failing to send.

MCLite

Turns a T-Deck or T-Watch into a standalone messenger. Early days.

You want to use the radio on its own, without a phone.

WADAMESH

A touchscreen interface with a map.

You have a touchscreen device and want chat and a map on it.

ZephCore

A rebuild of MeshCore on the Zephyr operating system.

Battery life matters, or your board only works with ZephCore.

MeshCore Official

The standard firmware, from the MeshCore team. MIT licensed. This is what flasher.meshcore.io gives you. Everything else on this page is built on top of it.

Start here. It is what the phone apps are built against and what everyone assumes you are running. 59 devices, 12 manufacturers.

Two things it does not give you. There is no Sensor build and no Wi-Fi Companion build in the official flasher. The code for both exists upstream, but you have to compile it yourself or get a ready-made copy from a fork. Keymind Cascade prebuilds both.

EasySkyMesh PowerSaving

A version of MeshCore tuned to draw less power, from IoTThinks. Same features, longer battery life. Roles: Companion (BLE), Repeater, Room Server. 42 devices.

About the "15 mA" headline. Its own test table is more varied than the headline suggests: Heltec v3 at 19.6 mA, Heltec v4.3 at 24.9 mA, Xiao S3 at 16.3 mA. Only the Xiao C3 actually hits 15 mA. Real savings, but plan your solar around the number for your board, not the headline. These are the project's own measurements and nobody else has checked them.

More: EasySkyMesh.

Keymind Cascade

The problem

Each repeater passes your message on exactly once, then forgets about it. If the next repeater misses it, the message is gone and nothing retries. One user measured roughly 45% of direct messages failing once the path was two or more hops. Sometimes it did arrive and only the receipt got lost on the way back, so your app says "failed" while the other person is reading it.

The fix

Cascade makes each repeater listen to check the message got picked up, the way you would watch to make sure the next person in a line actually takes what you handed them. If it hears the next repeater pass the message on, it knows it worked. If it hears nothing, it sends it again.

When the mesh is healthy, this costs nothing. Nothing extra goes out unless something was genuinely lost. It does the same for delivery receipts, and it can send replies by two routes at once, which fixes one-way paths where your message arrives but the reply never finds its way home.

Try this first, no fork needed

Some of Cascade is just MeshCore settings tuned for deliverability and performance. You can set them on official firmware from the repeater command line, without actually re-flashing to Keymind Cascade.

set multi.acks 1          send delivery receipts more than once
set rxdelay 2             let the strongest repeater go first
set loop.detect minimal   drop messages stuck going in circles
set agc.reset.interval 8  stop the radio going deaf over time

Only the listen-and-retry behaviour actually requires Cascade.

The catch

Retries cost airtime, and airtime is shared. Your retries are everyone else's interference. Cascade ships three profiles:

Profile

Retries

Use it when

infra

Few

Busy area, lots of nodes. Other routes exist, so do not shout.

rooftop

 (default)

Many

A fixed node with a weak-ish link into a mesh that mostly works.

mobile

Most

Out at the edge with no other way through, where getting the message out beats being polite.

The busier your area, the fewer retries you should use. A rooftop repeater in a well-covered city wants infra, not rooftop, whatever the name suggests. Putting mobile on a busy repeater makes things worse for everyone around you.

MCLite

Turns a LilyGo T-Deck Plus or T-Watch Ultra into a messenger that works entirely on its own. No phone, no pairing, no account. Turn it on and text people. MIT licensed, still pre-1.0, and its author calls it experimental.

The one real catch: messages you type on the device do not show up in the phone app. They send fine over the mesh, they just never appear in the app's history. This is a limit of MeshCore itself and MCLite cannot fix it. If you want a complete history in the app, type in the app.

WADAMESH

A full touchscreen interface: chat, contacts, and a real pannable map with offline tiles, all on the device. Works with the phone app at the same time. GPL licensed, from ALLFATHER BV in Belgium.

ZephCore

MeshCore rebuilt on different underlying software (the Zephyr operating system), which lets the radio sleep properly between messages instead of idling. MIT licensed. Aims to be fully compatible with normal MeshCore and the phone apps.

How to choose

  1. Just use MeshCore Official. If nothing below applies, flash the official build and stop reading.
  2. Messages keep failing? First try the four stock settings in the Keymind section. They are free. If it is still bad, flash Keymind Cascade and pick the profile that matches how busy your area really is.
  3. Solar or battery repeater? EasySkyMesh PowerSaving or ZephCore. With ZephCore, remember to turn on rxduty.
  4. T-Deck, T-Watch or a touchscreen? MCLite to use it without a phone. WADAMESH if you want the map.
  5. Board not in the official flasher? Try the Keymind Cascade or ZephCore catalogs.

One last thing. None of this matters if your radio settings are wrong, your radios are not in an ideal location (height is might) or your antenna is not tuned. Your node has to be on the same frequency, bandwidth, spreading factor and coding rate as everyone else in your area. That is the most common reason a new node hears nothing at all. Get those four numbers from your local mesh group before you go blaming the firmware.

A word of caution

Four of these are small community projects and several are openly experimental. That is not a reason to avoid them, but it is a reason to keep a stock build handy, know how to reflash a node you cannot reach, and think twice before putting experimental firmware on a repeater at the top of a tower.

Sources: the Mesh America Device Configurator catalogs; the official MeshCore flasher catalog; and the repositories, release notes, issues and pull requests of each project.

Flashing MeshCore Firmware

MeshCore firmware can be installed on supported hardware using two primary methods: the MeshCore Web Flasher (browser-based) and UF2 drag-and-drop (for nRF52840 boards only).

Method 1: MeshCore Web Flasher

The MeshCore Web Flasher is the recommended method for most users. It runs entirely in a browser and uses the WebSerial API to communicate with the board over USB.

URL: https://flasher.meshcore.io  (the canonical flasher, run by the MeshCore core team. flasher.meshcore.co.uk is a separate downstream flasher for the MeshOS variant - use the .io address for standard MeshCore.)

Browser Requirements

The WebSerial API is only available in Chromium-based browsers (the WebSerial API shipped in Chrome/Edge 89 - see MDN/Can I Use):

Step-by-Step: Initial Flash

  1. Open flasher.meshcore.io in Chrome or Edge.
  2. Connect your board to your computer via USB.
  3. Select your board type from the dropdown (e.g., RAK4631, T114, Heltec V3).
  4. Select the firmware variant you want to flash:
    • Companion - for personal use nodes (connects to MeshCore app)
    • Repeater - for dedicated packet relay infrastructure nodes
    • Room Server - for store-and-forward message hub nodes
    • Sensor - for telemetry/environmental monitoring nodes
  5. Select the firmware version (latest stable is selected by default).
  6. Click Connect. A browser dialog will appear listing available serial ports - select your device.
  7. Click Flash. The flasher will download the firmware and write it to the device. This typically takes 30-90 seconds.
  8. The board will reboot automatically after flashing.
  9. First-boot setup: connect via BLE using the MeshCore app to configure the node name and radio parameters (frequency, spreading factor, bandwidth, coding rate).

Method 2: UF2 Drag-and-Drop (nRF52840 boards only)

Boards based on the nRF52840 MCU (RAK4631, T114, Heltec HT-n62) support UF2 flashing without needing a browser or WebSerial.

  1. Download the correct .uf2 file for your board and firmware variant from the MeshCore firmware releases page on GitHub.
  2. Put the board into bootloader mode: double-tap the reset button rapidly. The board will appear as a USB mass storage drive whose name depends on the board's bootloader (for example, a RAK4631 mounts under its own board-specific label, while a nice!nano mounts as NICENANO) - the exact label varies by board, so look for any newly-appeared USB drive.
  3. Copy the .uf2 file onto the USB drive. The board will automatically flash and reboot.

Platform-Specific Setup Notes

Windows

Many LoRa development boards use USB-to-serial bridge chips (CP2102, CH340, FTDI). If the board is not recognized, you may need to install the driver for your specific USB chip. Check Device Manager for unknown devices. Common driver sources:

Linux

Most USB-serial chips work out of the box on modern Linux. If you get permission errors with WebSerial or serial tools, add your user to the dialout group: sudo usermod -a -G dialout $USER and log out/in.

macOS

macOS 11+ includes a built-in CP210x (CP2102) driver. CH340/CH341 support varies by macOS version (it is absent or unreliable on several releases); if a CH340-based device is not recognized, install the WCH CH34x macOS driver. If the device doesn't appear, check System Information > USB.

Keeping MeshCore Firmware Updated

Keeping your MeshCore nodes on current firmware is important for stability, interoperability, and security. This page covers why updates matter, how to check your current version, update strategies for deployed infrastructure, and how to handle rollbacks.

Why Updates Matter

Bug Fixes

MeshCore is actively developed software. Each release typically resolves routing edge cases, BLE connectivity issues, memory leaks, and hardware-specific quirks. Running old firmware means running known bugs that may have already been fixed.

Performance Improvements

Routing algorithm refinements, radio parameter tuning, and message handling optimizations are regularly incorporated. A network of nodes all running the same recent firmware will generally route more efficiently than one running a mixture of old builds.

New Features

New capabilities - new sensor types, new room server features, new CLI commands, new position reporting formats - are only available in the firmware version that introduced them. Staying reasonably current ensures you can use new functionality as it becomes available.

Security Patches

While MeshCore is a mesh radio protocol rather than an internet-facing service, vulnerabilities can still exist. Malformed packet handling bugs, cryptographic implementation issues, and BLE pairing weaknesses are all possible attack surfaces. Security-relevant fixes are tagged in release notes; apply them promptly.

Version Compatibility

MeshCore nodes on significantly different firmware versions may have interoperability limitations. Keeping your infrastructure nodes current minimizes the risk of incompatibility with nodes running newer client firmware.

Checking Your Current Firmware Version

There are two ways to check the firmware version on a node:

Via the MeshCore App

Connect to the node via the MeshCore app. Navigate to the node's detail or settings view. The firmware version is displayed in the device information section.

Via the MeshCore CLI

Connect to your node using a BLE serial terminal or the MeshCore CLI tool and run:

ver

This prints the node's firmware version. MeshCore firmware is currently in the 1.x series, so the output is an illustrative line such as:

v1.15.0

The ver command reports the firmware version. To see the hardware/board name, use the separate board command. For runtime health (battery, uptime, queue) use stats-core.

Update Strategy for Infrastructure Nodes

Repeaters and room servers are infrastructure - other users depend on them. Updating carelessly can cause network disruption. Follow this strategy:

1. Test on a Non-Critical Node First

If you operate multiple nodes, update one non-critical node (a spare, or the lowest-traffic repeater) to the new firmware first. Run it for 24 - 48 hours and verify:

2. Preserve Configuration Before Updating

Before updating any node, record its current configuration:

Use the CLI get queries (for example get radio, get tx) and infos to read back the current settings, and screenshot or copy the output. While configuration is generally preserved across firmware updates (stored in non-volatile flash separate from the firmware), a failed or interrupted flash can result in settings being wiped.

3. Update During Low-Traffic Periods

Infrastructure nodes go offline during flashing (typically 30 - 90 seconds). Schedule updates during periods when the network is least used to minimize impact on other users.

4. Update Infrastructure Before Clients

When a new major or minor version is released, update repeaters and room servers before client nodes. Infrastructure nodes carry traffic for all clients; having them on newer firmware ensures they can handle any new packet formats clients may start using.

How to Update

How you update depends on the board. ESP32 boards typically require USB flashing (the same process as initial flashing). nRF52 boards (RAK4631, T114, Seeed XIAO nRF52) additionally support over-the-air updates via the DFU app and the start ota CLI command, which avoids needing a USB connection. The USB web-flasher steps are:

  1. Connect the node to a computer via USB.
  2. Open the MeshCore Web Flasher at flasher.meshcore.io in Chrome or Edge.
  3. Select your board type and firmware variant.
  4. Select the new firmware version.
  5. Click Connect, select the serial port, then click Flash.
  6. Wait for the flash to complete and the board to reboot.
  7. Verify the node is operational using ver (firmware version) and stats-core (battery/uptime/queue health).

For nRF52840 boards (RAK4631, T114, HT-n62): UF2 drag-and-drop is available as an alternative. Download the new .uf2 file, enter bootloader mode (double-tap reset), and copy the file to the USB drive.

Rollback: Returning to a Previous Version

If a firmware update causes problems, you can return to any previous version:

  1. Open the MeshCore Web Flasher.
  2. Select your board and variant.
  3. Use the version selector to choose the previous known-good version (older versions are retained in the flasher's version history).
  4. Flash as normal.

For UF2 boards: download the previous version's .uf2 file from the MeshCore GitHub releases page and flash it via drag-and-drop.

Note: Configuration is generally preserved across rollbacks. However, if a newer firmware version introduced a new configuration key that older firmware does not understand, the old firmware may ignore or reset that setting.

Coordinating Community Network Updates

If you operate nodes on a shared community network, coordinate updates with other network operators:

Same Version Compatibility Notes

Within the same major version, MeshCore nodes running different minor versions can generally communicate. However:

Flashing MeshCore Firmware OTA: The Definitive Guide

image.png

Step-by-Step: OTA Update

Over-the-air (OTA) updating lets you reflash a deployed MeshCore node; a repeater, room server, or companion, without connecting it to a computer over USB. The method depends on the board's chip family: nRF52 boards update over Bluetooth using Nordic's DFU app, while ESP32 boards update over a temporary Wi-Fi access point in your browser. Both are covered below, followed by notes specific to companions.

OTA is convenient for nodes that are hard to reach physically (a repeater on a roof or tower). If a node is within easy reach, a USB flash from flasher.meshcore.io is faster and more reliable than OTA. Reserve OTA for when getting a cable to the device is impractical.

nRF52 Boards

nRF52 boards (RAK4631, Heltec Mesh Node T114, Seeed XIAO nRF52840, and similar) update over Bluetooth LE using Nordic's DFU app. The same process works for repeater, room server, and companion firmware, only the firmware image differs (see the Companions section for the companion firmware-version requirement).

Browser Requirements

The WebSerial API is only available in Chromium-based browsers (the WebSerial API shipped in Chrome/Edge 89 - see MDN/Can I Use):

Mobile App Requirements

Download the nRF Device Firmware Update app (you can find it by searching nrf dfu in your app store).

Note: After installation, this app is listed as "DFU" in the apps list, NOT nRF Device Firmware Update.

Get the OTAFIX Bootloader

The OTAFIX bootloader (by oltaco: Huw "Taco" Duddy, a MeshCore firmware developer) replaces the stock nRF52 bootloader and makes Bluetooth OTA DFU far more reliable: significantly faster OTA, automatic fallback to OTA DFU mode if an update fails, and the ability to enter OTA DFU mode by holding a button while resetting. It is strongly recommended before doing OTA on nRF52 boards. You install it once, over USB.

Download firmware images to your mobile device

On flasher.meshcore.io, download the firmware image for the device you want to flash. For OTA with the DFU app, choose the DFU package (.zip) variant of the firmware (not the .uf2, which is for USB drag-and-drop).

Flash the Device OTA!

Progress is slow. Ensure you have an unobstructed path to the device. External Bluetooth antennas help tremendously.

ESP32 Boards

ESP32 boards (Heltec V3, LilyGo T-Beam and T-Deck, Station G2, RAK11200, and similar) do not use the DFU app or Bluetooth for OTA. Instead, the device hosts a temporary Wi-Fi access point and you upload the firmware to it from a browser. You start this mode with a command, so you need admin access to the node in the MeshCore app.

Requirements

Get the firmware image

Start OTA mode on the device

Upload the firmware

While in OTA mode the device's only job is hosting this upload page, so it is briefly off the mesh. Keep your phone or laptop close to the node for a stable Wi-Fi link.

Companions

A companion is the node you pair with the MeshCore phone app. Companion firmware updates OTA using the same mechanism as repeaters and room servers. The difference is the firmware image you flash and, on nRF52, a minimum firmware version.

The actual firmware transfer happens in Nordic's DFU app (nRF52) or on the Wi-Fi upload page (ESP32). There is no separate "update firmware" button inside the MeshCore app itself. As always, if the companion is in your hand, a USB flash is the simplest path.