MUSTARDTIGERFPV f0c4c6af00 Enable the on-demand mOTA context for every classic ESP32 build
Move OTA_HEAP_CONTEXT from two hand-edited envs to a pre-script gated on
build.mcu == "esp32", so every classic ESP32 image gets it and none can drift.
S2/S3/C-series and nRF52 keep the .bss singleton: they have no equivalent
static-DRAM ceiling, so there a guaranteed-present workspace is the better
trade for what is ultimately a recovery path. It has to be a build flag rather
than a header default, because OTA_HEAP_CONTEXT must hold the same value in
every translation unit that sees OtaContext.h - OtaContext.cpp included - and a
header test on CONFIG_IDF_TARGET_ESP32 would depend on include order relative
to sdkconfig.h. The script defers to OTA_SHARED_COMPANION_QUEUE where a Full
Companion recipe already owns the storage.

Fix a gap this exposes in the roles that now use it. Only CLI entry points
acquire the context, so once it was released, a repeater with the temporary
radio profile up would no longer serve or announce its own firmware - LoRa OTA
would look enabled and silently do nothing. ota_service_temp_radio_context()
holds the workspace for exactly the temp-radio window and hands it back
outside it, which is where the saving was coming from anyway. Wired into the
repeater, room server and sensor loops; the Companion keeps its own
acquire-on-host-demand policy, since its context is borrowed from the offline
message queue and must not be taken speculatively.

Static DRAM, classic ESP32 (bytes occupied of a 124,580 region):
  Heltec_v2_repeater                   108,332 -> 70,732
  Heltec_v2_room_server                 83,716 -> 68,300
  Heltec_v2_companion_radio_ble        123,236 -> 107,772  (was failing on main)
  Tbeam_SX1262_repeater                 86,932 -> 71,468
  Tbeam_SX1262_repeater_observer_mqtt  121,132 -> 83,532   (was failing)
2026-09-09 01:24:00 -07:00
2026-06-05 09:49:57 -07:00
2025-01-13 14:07:48 +11:00
2025-06-05 20:35:40 +12:00
2026-02-03 13:47:43 +13:00
2026-03-23 14:26:56 +01:00
2025-01-20 10:20:42 +11:00
2026-08-23 00:29:00 -07:00

About MeshCore

For 1.17.1.5 USA Cascade, start with the release guide, firmware picker, and feature switches by role. Use the USB web console for the default ASCII terminal on Full Companion, Repeater, Room Server, and Sensor images.

MeshCore is a lightweight, portable C++ library that enables multi-hop packet routing for embedded projects using LoRa and other packet radios. It is designed for developers who want to create resilient, decentralized communication networks that work without the internet.

[SEARCH] What is MeshCore?

MeshCore now supports a range of LoRa devices, allowing for easy flashing without the need to compile firmware manually. Users can flash a pre-built binary using tools like Adafruit ESPTool and interact with the network through a serial console. MeshCore provides the ability to create wireless mesh networks, similar to Meshtastic and Reticulum but with a focus on lightweight multi-hop packet routing for embedded projects. Unlike Meshtastic, which is tailored for casual LoRa communication, or Reticulum, which offers advanced networking, MeshCore balances simplicity with scalability, making it ideal for custom embedded solutions, where devices (nodes) can communicate over long distances by relaying messages through intermediate nodes. This is especially useful in off-grid, emergency, or tactical situations where traditional communication infrastructure is unavailable.

Upstream Observer WiFi and MQTT - Observer firmware, release notes, and browser-based flashing are available at observer.gessaman.com. See WiFi and MQTT by Firmware Type for the role/build matrix and setup overview. For the complete MQTT command and broker reference, see the MQTT Implementation Guide.

[LIGHTNING] Key Features

  • Multi-Hop Packet Routing
    • Devices can forward messages across multiple nodes, extending range beyond a single radio's reach.
    • Supports up to a configurable number of hops to balance network efficiency and prevent excessive traffic.
    • Companion nodes do not repeat by default. Supported Companion builds can opt into bounded client repeating on permitted frequencies, while dedicated repeaters remain the normal way to extend coverage.
  • Supports LoRa Radios - Works with Heltec, RAK Wireless, and other LoRa-based hardware.
  • Decentralized & Resilient - No central server or internet required; the network is self-healing.
  • Low Power Consumption - Ideal for battery-powered or solar-powered devices.
  • Simple to Deploy - Pre-built example applications make it easy to get started.

[TARGET] What Can You Use MeshCore For?

  • Off-Grid Communication: Stay connected even in remote areas.
  • Emergency Response & Disaster Recovery: Set up instant networks where infrastructure is down.
  • Outdoor Activities: Hiking, camping, and adventure racing communication.
  • Tactical & Security Applications: Military, law enforcement, and private security use cases.
  • IoT & Sensor Networks: Collect data from remote sensors and relay it back to a central location.

[ROCKET] How to Get Started

For developers:

The Simple Secure Chat example can be interacted with through the Serial Monitor in Visual Studio Code, or with a Serial USB Terminal on Android.

[LIGHTNING] MeshCore Flasher

We have prebuilt firmware ready to flash on supported devices.

  • Launch https://meshcore.io/flasher
  • Select a supported device
  • Flash one of the firmware types:
    • Companion, Repeater or Room Server
  • Once flashing is complete, you can connect with one of the MeshCore clients below.

[PHONE] MeshCore Clients

Companion Firmware

The companion firmware can be connected to via BLE, USB or Wi-Fi depending on the firmware type you flashed.

Repeater and Room Server Firmware

The repeater and room server firmware can be set up via USB in the web config tool.

They can also be managed via LoRa in the mobile app by using the Remote Management feature.

[TOOLS] Hardware Compatibility

MeshCore is designed for devices listed in the MeshCore Flasher

[SCROLL] License

MeshCore is open-source software released under the MIT License. You are free to use, modify, and distribute it for personal and commercial projects.

Contributing

Please submit PR's using 'dev' as the base branch! For minor changes just submit your PR and we'll try to review it, but for anything more 'impactful' please open an Issue first and start a discussion. It is better to sound out what it is you want to achieve first, and try to come to a consensus on what the best approach is, especially when it impacts the structure or architecture of this codebase.

Here are some general principles you should try to adhere to:

  • Keep it simple. Please, don't think like a high-level lang programmer. Think embedded, and keep code concise, without any unnecessary layers.
  • No dynamic memory allocation, except during setup/begin functions.
  • Follow the repository's .clang-format and the surrounding source style. Do not retroactively reformat unrelated code; that creates noisy diffs and makes functional changes harder to review.

Help us prioritize! Please react with thumbs-up to issues/PRs you care about most. We look at reaction counts when planning work.

Running unit tests

To run unit tests, run the following command:

pio test --environment native --verbose

Run only one PlatformIO process in a checkout at a time. Do not overlap pio test, pio run, uploads, cleans, or scripts that invoke PlatformIO, even for different environments: they share and may clean .pio/build, which can interrupt another build and produce misleading failures.

Road-Map / To-Do

There are a number of fairly major features in the pipeline, with no particular time-frames attached yet. In very rough chronological order:

  • Companion radio: UI redesign
  • Repeater + Room Server: add ACL's (like Sensor Node has)
  • Standardise Bridge mode for repeaters
  • Repeater/Bridge: Standardise the Transport Codes for zoning/filtering
  • Core + Repeater: enhanced zero-hop neighbour discovery
  • Core + Full Companion: round-trip trace and manual path support
  • Companion: opt-in off-grid client repeat mode
  • Companion + Apps: support for multiple sub-meshes
  • Core + Apps: support for LZW message compression
  • Core: adaptive CR (Coding Rate) for direct retries using recently heard SNR
  • Core: new framework for hosting multiple virtual nodes on one physical device
  • V2 protocol spec: discussion and consensus around V2 packet protocol, including path hashes, new encryption specs, etc

[TELEPHONE] Get Support

  • Report bugs and request features on the GitHub Issues page.
  • Find additional guides and components on my site.
  • Join MeshCore Discord to chat with the developers and get help from the community.
S
Description
No description provided
Readme MIT
163 MiB
0 Stars 1 Watchers 0 Forks
Languages
C 61.2%
C++ 37.7%
Python 0.7%
Shell 0.3%
Linker Script 0.1%