MeshCore Blog

Release v1.17.1

2026-08-14T00:00:00+00:00

Download

Latest firmwares are in the flasher.meshcore.io

Change Log

New Features

#3137 new ‘get/set radio.fem.rxgain/txgain’ CLI commands (txgain is Station G3 only), fixed pref mapping for radio.fem.rxgain
#3148 added missing kiss radio roles, kiss radio build added to build.sh

Enhancements

#3106 login response no longer sent as flood on direct login, fix for unscoped flood login
#3146 LR2021: PREAMBLE_DETECTED bit and IRQ rx timeout logic
#3154 NRF52 CC310: nRFCrypto.begin()/end() now called only once
#3166 RadioLibWrapper noise floor debug print moved behind new MESH_DEBUG_NOISE_FLOOR flag
#3206 nRF RadioNoiseListener RNG now combines entropy from radio and CC310

Bug fixes and Other

#3140 T-Echo Lite pins aligned to updated Lilygo schematic, TCXO voltage set to 3.0V
#3142 build fix for R1 Neo and Minewsemi repeater
#3158 Rx boosted gain no longer reset to compiled value after AGC reset
#3164 T-Beam Supreme S3 display fix
#3170 ProMicro pinmap tidy up, LoRa pins moved to variant.h
#3185 T-Echo Card TCXO voltage set to 3.0V as per #3140
#3188 Heltec T096 Tx failure fixed (out of bounds PIN_SPI1_MISO)
#3189 Heltec T1 / MeshPocket / T-Echo Lite: unused pin fix (root cause)
#3203 Companion: fem_radio_rx/txgain pref disabled until settable.

Fixes and enhancements for devices with FEM

The radio.fem.rxgain setting was not being persisted properly in v1.17.1, this is now fixed. Repeater admins will want to check that radio.fem.rxgain and radio.rxgain are configured to their liking after updating. Companion firmware currently has no way to configure these settings, so they they will use the default values only for now.

Heltec T096 Transmit issue fix

The Heltec T096 transmit issue was found to be an out of bounds read of the pin map due to PIN_SPI1_MISO being set to -1. It was causing the FEM’s Tx enable pin to stop working. This has been fixed and other NRF52 boards have had their unused pins corrected.

Release v1.17.0

2026-08-09T00:00:00+00:00

Download

Latest firmwares are in the flasher.meshcore.io

Change Log

New Features

#2987 companion, MCU temperature added to sensor telemetry
#3115 LR2021 radio support added. (Also Meshnology W12 added)
#2688 new room server ‘room.post’ CLI command (for server orig posts)
#2883 repeater power off on long button press
#1727 new ‘set cad on/off’ CLI command
#2765 ESP targets now support the ‘get pwrmgt.bootreason’ CLI command
#2140 new ‘get/set radio.fem.rxgain’ CLI command (some Heltec boards)

Enhancements

#3036 fix for missing preamble detect IRQ bit
#2977 preamble and header IRQ rx timeout logic
#2824 nrf52 targets now use CC310 hardware crypto functions
#2982 config now stored in JSON format (all firmwares)
#3034 new color scheme on companion UI
#3023 room server now supports rx boosted gain
#2951 Fast ST7735 disply driver (Heltec T096, Wireless Tracker, etc)
#2895 hibernate/poweroff power draw savings

New device support

#3139 Sensecap X1, QSPI Flash support
#3122 Sensecap X1, LED and haptic feedback
#3112 added Sensecap MeshTracker X1 support
#3049 Thinknode M7 support, plus architecture for universal companion
#2966 added Heltec RC32 board support
#2560 added Heltec V4 R8 board support
#1983 support for RAK ethernet modules
#2942 added Elecrow Thinknode M9 support
#2839 added Elecrow Thinknode M7 support
#1194 added Nibble Zero Connect support
#2752 added Heltec tower V2 support

Bug fixes and Other

#3121 companion, hardware CAD disabled
#3107 ANON_REQ reply path_len check
#2863 Thinknode M6 GPS re-init fix
#3048 ‘start ota’ failure now reported on nRF devices
#2819 kiss modem fixes for stalls under USB backpressure
#3005 ESP32, BLE bonded reconnects fix
#3007 ESP32, BLE receive queue synchronization
#3006 Heltec V4 hardware USB serial
#2815 T-Beam Supreme OLED fixes
#2887 Thinknode M3, GPS LED fixes
#2990 Xiao nrf52 repeater build fix
#2899 T-Echo Lite DC-DC regulator fix
#2905 Heltec T114 DC-DC regulator fix
#2937 fix for GPS time sync stall on long uptime nodes
#2936 external watchdog timer for Heltec Tower V2
#2867 sx1262 LDO support fix
#2844 fixed rx boosted gain on LR1110
GPS time sync fix for Heltec T114
#2763 companion fix when anon contacts full
bad path_len now rejected, in PAYLOAD_TYPE_PATH and ANON_REQ

Packet Collision Improvements

The ‘listen-before-talk’ code has had some pretty big changes, thanks to Taco. He has spent weeks doing diagnostics, and even simulations, testing an improved scheme which involves handling cases where the LoRa radio’s IRQ flags get ‘stuck’, and also the big one being proper preamble detection. This one could be the most significant performance improvement for all meshes.

Also, he found that the new scheme performs on par with hardware CAD, but without the 4 second lock-up glitches that CAD still suffers from. So, we are still leaving hardware CAD off by default.

Companion UI

Various color displays will now sport a new look, and be much more responsive.

JSON Config

The node config should be automatically migrated to a new JSON format upon upgrading to v1.17.0. The old binary-blob config is left intact, however, in case some people need to revert to old firmware.

Steps Toward Universal Companion

With #3049 Liam has paved the way for companions to support multiple serial interfaces, eg. BLE + USB. Up to 4 can now be supported. There are no official multi-interface companion builds yet, but all the ‘plumbing’ for this is now there.

Thank You

2026-07-28T00:00:00+00:00

The GiveALittle fundraiser is now closed, and the results, even after the first 12 hours, were overwhelming!

We were all blown away by the response, and it has been great to know that the community has our back. There we some remarkable donations by individuals, in the thousands of dollars, but even more modest ones that were clearly by battlers not exactly well off. We also had some of the manufacturers get in touch and insisted on being anonymous donors. All of it much appreciated.

Your comments and wishes were very encouraging. Here’s a sample:

There have also been many new Github sponsor supporters, and this is equally appreciated.

Current Status

So, the UK lawyer has now officially submitted the opposition, and the trademark is now in opposed status. We don’t have any definite dates yet, but essentially it’s a waiting game now.

Hopefully there is more than enough evidence presented to determine a ruling, but the law is difficult to understand, and nothing is really guaranteed.

Onwards

The uncertainty is still difficult to deal with at times, but overall we’re positive about the future, and there are many options still available. There are solid improvements coming in the v1.17.0 release, and many more long-term improvements we are busy with. So, the tech goes on regardless.

Once again, thank you all for your generosity and your ongoing commitment to the project.

The MeshCore Team

Help Us Save MeshCore

2026-07-04T00:00:00+00:00

Foreword, by Scott Powell

Many of you got into MeshCore because it answered an as-yet unknown call. The project had its beginnings here in late 2024, when I was frustrated that there was no sufficiently open and permissive mesh protocol which could form the centre of a vibrant ecosystem. From the start, I made my intentions clear, that I wanted an open protocol, an open source core engine, but also permissive of 3rd party products that could build on top of it. I then spent the next two months designing and writing what became the C++ MeshCore engine, and the 3 main firmware roles.

What I also made clear were the principles that project was founded on. What has been great to see is how MeshCore has attracted the right people, as many have noted and found the general spirit of conversations to be very positive and cooperative.

I believe its success has rested on two main pillars:

technical pragmatism (eg. keep it simple)
a positive and appropriate ethic for the times we’re in (eg. heavy gov/corp tracking and censorship)

As many of you know, a team split occurred earlier this year due to a steady erosion of trust, which culminated in a trademark filing that completely went behind the core team’s back. We are now on a war footing as every attempt from us to come to an understanding has been met with contempt by the former member.

All of this could have been avoided with one simple email from him: to state his intentions upon winning the legal mark. That’s it. I’ve made my intentions for MeshCore widely known, but the former member prefers to hide his intentions (and his methods). Part of the huge backlash against him and his derived products is precisely because of his lack of openness. He has plenty of time to rebrand even the latest MeshCore releases, modify them, promote them as his own, but he doesn’t even have time to send us, the core team, a single email?

And the irony is he primarily wants to steer people from the MeshCore brand to his own brand! MeshCore is simply a stepping stone, yet he still has shown no intention of dropping the trademark filing. It begs the question, why?

As a result, we have burned countless days and dollars mounting a legal challenge. This has been very draining, and has been hurting the project. PR’s pile up, and features we’d hoped to have done by now still haven’t been touched. So, we need to get this behind us and get the project back on track.

But, for the next phase, we need your help.

We are approaching the pointy end of the legals, with a deadline looming, and crossing the next threshold is going to cost a lot, so we’re asking for help. The details will be explained further in this post, by Liam and the rest of the team.

I just want to get back to where we keep pushing where MeshCore is going, innovating and seeing just what is possible with a community-run mesh. We have SO much still to do! And hopefully we’ll be back on track again soon.

warm regards,

Scott

Timeline Summary

We’ve included some key information from the timeline of events relating to this dispute below. For the purposes of the timeline, we refer to the former team member as AK.

16/Nov/2024 Scott shares blog post announcing his plans to work on MeshCore.
20/Jan/2025 Scott publishes his open source MeshCore project on GitHub.
(things are going well for more than 1 year, with a thriving community)
(trust with AK was starting to erode)
(some internal disagreements came up)
29/Mar/2026 AK secretly files for UK trademark.
03/Apr/2026 We confronted AK on the filings. Conversation broke down with no resolution.
10/Apr/2026 Liam and Scott start New Zealand company “MeshCore Technologies Limited”.
11/Apr/2026 We file for MeshCore logo trademark in New Zealand.
20/Apr/2026 AK secretly files for EU trademark.
23/Apr/2026 We announce team split.
25/Apr/2026 We start engagements with legal counsel.
06/May/2026 We file for logo trademark in Australia.
06/May/2026 We file for word trademark in Australia, New Zealand, United States and China.
07/May/2026 We ask AK (again) to withdraw the UK/EU trademarks.
07/May/2026 AK responds saying he won’t withdraw the UK/EU trademark applications.
08/May/2026 AK says we will need to form some sort of commercial agreement with him.
09/May/2026 We ask AK for a proposal around trademark rights. He says he’ll have a think about it and get back to us.
19/May/2026 We follow up via email and discord asking again, about a proposal around the trademarks.
04/Jun/2026 We file for subsequent international designations for word trademark in Canada, Switzerland, European Union and United Kingdom.
12/Jun/2026 Our lawyers send notice of threatened opposition and extend UK trademark opposition period from 17/June/2026 to 17/July/2026.
18/Jun/2026 Our lawyers send demand letter to AK. (alleges copyright infringement, stolen assets, and tool cloning, which can be seen in file names and api responses of .uk site)
24/Jun/2026 AK responds to our demand letter. (denies any wrong doing or bad faith, refusing all desist orders)
25/Jun/2026 We reach out to AK one more time via email and discord, giving him another opportunity to provide us with a proposal around the trademarks, however received no reply.

Why Not Just Rename?

We know some of you might be thinking, “Why not just rename the project and move on?”

The short answer is, we shouldn’t have to. We came up with the name, hand crafted the firmware and are still the original core maintainers of the project.

It also sets a dangerous precedent, that if an open source project simply folds and rebrands every time a bad faith actor tries to claim a trademark, it signals that open source developers can always be bullied out of their own hard work.

So instead, we are choosing to stand our ground and fight for the name we earned, and for the future of the project and our community.

If AK becomes successful in registering the trademark, all it will do is fracture an already well established, global ecosystem. It doesn’t make sense why he’s still pursuing this, especially after the massive backlash from the community.

Keeping the Core Human & Open Source

This fight also highlights exactly where things are headed if AK gets control of the name.

While some of the apps/clients in our ecosystem may be closed source, our core firmware and libraries have always been strictly open source, and written by humans.

AK’s version proves his trajectory, taking open source community code, feeding it to an AI, locking it down, and making it closed source, for profit.

Supporting us in this fight is a vote to keep the core firmware free, open, and community driven.

The Next Step

So, now we’re facing the expensive part of all this…

Unfortunately, AK is forcing this with his refusal to provide any workable resolution to this conflict.

As we are getting closer to the deadline, we now need to push ahead with legal opposition of the trademarks. At this stage, we’ve only extended the deadline for submitting our opposition arguments. Should AK try to defend the opposition, we plan to proceed with prosecution through the courts.

We have been given some estimated costs by our lawyers, totalling around $18,000 USD.

~$3,000 USD - Legal fees to oppose the UK trademark application.
~$9,000 USD - Legal fees to proceed to prosecution if the UK trademark opposition is defended.
~$6,000 USD - Legal fees to file an invalidation action for the EU trademark.

In addition to this, we have already personally covered more than $15,000 towards counter-trademark filings (in other jurisdictions), legal fees and extension of opposition deadlines.

Nearly all five of the core team members do MeshCore work part time. And up until recently, the project has had no central revenue earning capability (unlike similar projects like Meshtastic).

Because of this, the project is very underfunded. However, none of us have really minded. We do the work because we want to see it succeed.

Very recently, we started a GitHub Sponsors page, and it’s been great to see so many of you donate to us.

As this hasn’t been running for very long, unfortunately we haven’t accrued anywhere near enough to cover the legal costs. So we’ve now started a crowd funding campaign, in an attempt to raise the required funds to continue the legal challenge.

We are now asking the MeshCore community for any support you may be able to provide us in our fight to protect the MeshCore project’s name and future. Any contribution you are able to provide will be greatly appreciated.

What Happens If We Win

If we win the legal opposition, we will need to start a process to get consensus on what the trademark (and logo) ‘fair use’ policy should be. We would be looking for suggestions from the community, and would reach out for comments when we get to that stage.

We’ve always had a pretty liberal attitude to the use of the name and logo, but we will have to have some formal rules around it, and a means to prohibit any ‘bad faith’ or abusive uses.

Other than that, the project would continue as normal. Instead of dealing with this legal dispute, we’d have more time to put toward working through our growing pile of feature requests!

What Happens If Challenge Is Not Viable

In the event that the trademark opposition is unsuccessful and a prosecution through the courts is not viable, say due to insufficient funding, we would pool any raised funds into the GitHub Sponsors fund, with plans for it to benefit the MeshCore community directly.

We’ve wanted to establish things like bug bounties, and some way of rewarding the top contributors after each release. These funds could end up at least helping the future of the project in more practical ways, by helping the efforts be more sustainable.

So far, from our generous sponsors, we have accrued around ~$1,800.

Our Final Request to Andy

Andy, if you’re reading this, we urge you to withdraw your trademark applications. Please consider the long term health and future of the MeshCore project, and bring this dispute to a close.

All it takes is a quick email to the trademark offices requesting the withdrawal of your filings. If you do that, we will drop our legal challenges, and we can all move on, allowing us more time and energy for the project.

Otherwise, we have compiled all necessary evidence, and are fully prepared to push forward with defending our open source project.

Help Support the MeshCore Team

If you’d like to help support the MeshCore project, please consider donating through our links below.

Crowd Funding Campaign: https://givealittle.co.nz/cause/help-us-save-meshcore
GitHub Sponsors: https://github.com/sponsors/meshcore-dev/

Even if you’re unable to contribute financially, sharing this post will help us tremendously.

We appreciate all the support we can get.

The MeshCore Team

OTA Updates by Drone

2026-06-22T00:00:00+00:00

OTA Updating hard to reach nRF52 based repeaters with a drone

As we added more and more repeaters to our local mesh in Slovakia, we found out it’s not always possible to physically reach some repeater sites often enough. We incrementally got better in addressing this issue by experimenting with different approaches. I built a custom nrf dfu app that works on desktop OSes, so you can use external bluetooth adapters with rp-sma ports and directional antennas.

^{Updating local repeater with uConsole, high-power BLE adapter and directional antenna}

My buddy lucidnx started to experiment with nrf_dfu_py and created a whole framework for drone updating. This solution works well, but the rpi zero approach is not trivial to setup, requires additional DIY and it’s hard to use and debug. That’s why I decided to build more user-friendly version, so the drone doesn’t need to carry whole linux board on its back.

^{Older version of Drone updater - with Raspberry Pi Zero 2W and hefty battery pack. 70g total payload}

The Star of the Show

Xiao nRF52840 packs a perfect combination of things you want for very small low-power repeater updater: nRF MCU is power efficient, it has 2MB of onboard flash and it has full blown USB controller. Inspired with Arduino bootloader that has UF2 mode, I decided to use the external 2MB flash as Mass Storage with real FAT12 filesystem, so you can even use a phone to copy over the firmware file, configure the updater and review the update log - very handy in the field.

^{DJI Neo2 with Xiao nRF52840 updater and 250mAh Li-Ion battery. 7.5g total payload}

How to setup and use the updater

Be sure the repeater you want to update uses oltaco’s OTAFIX bootloader with version at least 2.1 or higher

Get the firmware on Project releases page. There are 2 boards supported: Xiao nRF52840 and RAK3401/RAK4631 with RAK15001 external flash module. We’ll focus on Xiao, as that’s easier to pick up for most of the readers.

Download updater-xiao_nrf52840-vX.X.uf2
Connect Xiao to your computer over USB
Double click the small reset button near the USB port - you might need to use your fingernail to do it
Copy the updater-xiao_nrf52840-vX.X.uf2 to newly opened usb drive
Xiao will restart(you might get error about unsuccessful transfer, disregard)
You will be presented with new empty USB drive labeled “XIAO DFU”
Copy config.txt over to the USB disk
Open the config.txt with text editor
Set the ble_name to OTA name your repeater uses, here are few examples:
- 4631 | 3401 for RAK based boars - covers both RAK4631 and RAK3401 1W
- SENSECAP | SCAP for Seeed SenseCap Solar P1
- XIAO for XIAO NRF52 based repeater(yeah, you can update Xiao with your Xiao!)
- T114 for Heltec T114
- ProMicro | PROM for FakeTec / Promicro based boards
(optional) Set any config parameters you like, but the defaults are well balanced already
Download and copy firmware zip that you want to flash to your repeater
Decide how you want to power your Xiao board.. I would recommend to solder battery leads to battery pads, but you can wing it with USB power if want.
Attach the Xiao to your drone, send start ota to your repeater and make sure Xiao is blinking blue - that means it’s ready to flash your repeater
Fly near the target as close as you can - transfer will start as soon as Updater detects ble_name with min_rssi or better.
Keep Pinging your repeater via LoRa - it will tell you if the process started and later after few minutes, starts to be reachable again.
Get your drone back and look at the Xiao LED color - if it’s GREEN, the update was successful, if it’s RED, it failed. if it still blinks blue, that means the update did not even start - ble_name was not set right, the rssi was too weak or start ota failed
(optional) you can look into the log.txt in Xiao’s USB drive - it should hold update process with timestamps relative to boot. You can look at how successful update log looks like

Let us know if this guide helped you flash your distant repeaters! Don’t hesitate to ask any questions either in the comments or on our Discord.

Release v1.16.0

2026-06-06T00:00:00+00:00

Download

Latest firmwares are in the flasher.meshcore.io

Change Log

New Features

New CLI config var ‘flood.max.unscoped’ #2661
New CLI config var ‘flood.max.advert’ #2702
longer preamble now for lower SF. (32 for SF<=8, 16 for SF>8) #1954
app/companion can now do anon_req/response with non-contact nodes #2672
companion auto-shutdown, disabled when on external power, new UI warning on display #2663
new ‘region def …’ CLI command #2540
extended ACK support #2594
app/companion can now compose and send raw packets #2543
companion can now override default scope to explicit unscoped #2492

Enhancements

All ESP repeaters, power saving improvements #1687
nRF companions, power saving #2286

New device support

NEW: LilyGo T-Echo Card support #2517
NEW: LilyGo T-Impulse Plus support #2522
NEW: Station G3 support #2515
NEW: Heltec Mesh Node T1 support #2520
new Xiao S3 variants (repeater, companion, etc) #2383

Bug fixes and Other

RP2040 target build fixes. #2684
companion protocol max frame size increase (now 176) #2022
RAK Wismesh Tag fixes #2664
Bug fix: repeater neighbor discovery fail when path.hash.mode != 0
RAK4631, now using Bosch driver for BME680 sensor #2634
enable radio.rxgain CLI command for LR1110 (T1000e) #2235
default flood advert interval now 47 hours (was 12) #2608
Client repeat (off-grid) EU freq change (from 869.0 to 869.495) #2604
CLI validation on rxdelay, txdelay and direct.txdelay #2443
Heltec T096, sensor node support #2576
Heltec E290 USB companion fix #2562
WiFi companion, reconnect logic redesigned for non-blocking #2493
RAM usage reduced for older boards #2497
nRF variants, CustomLFS lib upgrade to v2.2 #2519
T-Echo Lite, fixes to RXEN, TXEN and TCXO #2511
KISS modem frame timeout fixes #2490
sensor manager redesign #2327
startup tune suppressed if sound pref off #2460
added KISS Modem variants for most boards #2620 #2432
Adafruit nRF BLE fork, to prevent lockup during rapid connect/disconnect #2430
RAK3401 companion, analog button support #2436
Heltec boards, LNA disabled by default #2439
new splash screens #2424
Sensecap Solar Tx LED fix #2157
new repeater variant: Heltec V4 expansion kit #2326
new T-Echo Lite non-shell companion variants #2503 #2353
T-Echo Lite, battery measure fix #2287
RAK4631, sx1262 reset pin fix #2008
Heltec T096, Wireless Tracker: FEM/LNA enable by default #2340
R1 Neo, shutdown fix #2371
Heltec V4, set adc.multiplier support #2335

Limiting Unscoped Traffic

The new flood.max.unscoped CLI config variable is specifically for limiting unscoped flood traffic. Like flood.max, it drops unscoped flood packets which have already had a given number of hops. By default it is 64, which is essentially off.

The new flood.max.advert CLI config variable is specifically for limiting adverts. Like flood.max, it drops advert packets which have already had a given number of hops. By default it is 8.

New Preamble

When using the lower Spreading Factors, the radio has less time to lock onto an incoming packet, so this change gives the faster SF’s a longer preamble, and thus decreasing the chance of the preamble being missed. For SF <= 8, the preamble is now 32 symbols.

Improved Region Discovery in Mobile App

The new companion firmware, and latest app, will be able to do ad-hoc requests to near by repeaters without having to add them to contacts first. This will streamline both repeater discovery, and region discovery.

New `region def` Command

Defining regions via the CLI is currently quite verbose, and the latest CLI handling introduces a new region def... command which has a short-hand notation for defining regions, especially ones which have deep nesting.

See the CLI Command Reference for more details.

Extended ACK Support

The latest firmwares introduce support for ‘extended ACKs’, which are 6 bytes instead of 4. The extra bytes contain an extended attempt number, and additional random byte. This is in preparation for a later app feature which will enable much more than 4 attempts for direct messages. For now, repeaters will have to be updated first.

Companion Raw Packets

The latest companion firmwares now enable apps to compose the full packet, ie. headers, path and payload. This can correspond with the existing RxLog ability, so app can do its own raw send and receive of packets.

pyMC Introduction

2026-05-12T00:00:00+00:00

What is pyMC? At its core, pyMC is a Python implementation of a MeshCore-compatible stack. It is designed to run on Linux-based systems and connect embedded LoRa radios to higher-level software services. It started as a way to better understand the MeshCore protocol. But pretty quickly, it became something more useful: a reusable core library for building flexible, Linux-powered mesh infrastructure. The pymc core handles the protocol-level work:

Parsing and generating MeshCore packets
Managing identities and addressing
Maintaining compatibility as the protocol evolves
Handling radio interfaces (SPI, KISS, USB-CH341)

with over 15 boards currently supported and many new ones in development, the system has grown from a simple experiment into a practical toolkit for building and running distributed mesh infrastructure.

On top of pyMC core sits pymc repeater, which handles the operational side:

Processing packets
Applying routing and filtering logic
Forwarding traffic
Supporting services like roomservers, companions and observer data output

Embedded firmware is efficient and well suited to dedicated devices, but it operates under tight resource constraints. Running pyMC on Linux expands the design space: more compute, better tooling, easier debugging, and deeper real-time visibility into mesh behaviour.

A key design choice is how identities are handled. Instead of assuming one physical node equals one logical presence, pyMC lets multiple identities exist on the same radio.

In practice, a single device can take on multiple roles. It might act as a repeater, represent different logical endpoints, or host additional services–each with its own context.

This flexibility allows a pymc repeater to evolve into a multi-companion base station. At that point, it behaves less like a simple packet repeater and more like a lightweight message hub for the mesh.

Put another way: pyMC gives MeshCore a Linux-native surface area. It can run repeaters, host services, power analytics, or support entirely new mesh applications–without losing compatibility with the underlying radio layer.

Where pymc_console fits

One example of that larger design space is pymc_console: a browser-based dashboard built on top of pyMC repeater.

Where pyMC handles the protocol and repeater layer, pymc_console turns that activity into something you can actually see and reason about. Packet flow, radio status, connected identities, observer output, airtime utilization, and network behavior can all be surfaced in a more approachable interface.

That matters because a mesh network is difficult to improve if it is invisible. Once packets, routes, signal quality, and utilization patterns become observable, the repeater becomes more than a forwarding node. It becomes a local window into the health and behavior of the mesh.

In that sense, pymc_console is less a separate idea than a natural extension of the pyMC architecture. The same Linux-native foundation that lets pyMC talk to radios also makes it possible to build analytics, dashboards, companion experiences, and new tools around the mesh.

The interesting part isn’t just what pyMC does today, but what it enables in practice.

If you’d like to explore it, run it yourself, or follow along as it evolves, everything you need to get started is available.

Where to start

Source and setup instructions are on https://github.com/pyMC-dev

Or join us in the pyMC Discord https://discord.gg/hRjW9ha6m

Recommended Gear

For a no-fuss pyMC setup, I recommend the following tested and compatible hardware platforms. The MeshToad and MeshTadpole are ideal for lightweight installs, home labs, and desktop usage, while PiMesh provides an excellent Raspberry Pi-based solution for infrastructure and gateway deployments. For repeater-focused installations, the UltraPeater Luckfox Pico Ultra HAT offers a compact and efficient dedicated repeater platform.

MeshToad V3 — https://muzi.works/products/nullhop-meshtoad-v3
MeshTadpole SX1262 USB Stick — https://www.elecrow.com/meshtadpole-sx1262-usb-stick.html
PiMesh — https://meshsmith.net/
UltraPeater — https://zindello.com.au/ultrapeater/

Ripple UI v9.7

2026-04-30T00:00:00+00:00

The latest release of the Ripple UI firmwares has had quite a big overhaul (under the hood) and the UI now sports a Light and Dark mode theming, plus you can now customise the accent colour used throughout the firmware.

Display Preferences

The Display menu now shows these preferences:

The UI Theme preferences is one of: Light, Dark or Auto. The Auto option automatically switches the UI theme depending on the Brightness setting (day or night).

PAID FEATURE: The Accent color lets you customise the accent colour used throughout the firmware. There are 10 fun colour swatches to select from:

Map Theme

Note that the UI Theme preference also determines the light/dark theming for the maps:

Download

The v9.7 is now available for LilyGo T-Deck, T-Pager and the T-Watch S3 Plus. It will be rolling out soon for the other colour devices, like Heltec V4 Expansion kit, etc.

These are now available in the MeshCore.io Flasher, for easy installation.

Meshcore.io - Why The Split?

2026-04-23T00:00:00+00:00

Since inception, the MeshCore development team have been working hard to build MeshCore.

We’ve released more than 85 versions of the MeshCore Companion, Repeater and Room Server firmwares with support for more than 75 hardware variants. All of this has been hand crafted, by humans.

We have always been wary of AI generated code, but felt everyone is free to do what they want and experiment, etc. But, one of our own, Andy Kirby, decided to branch out and extensively use Claude Code, and has decided to aggressively take over all of the components of the MeshCore ecosystem: standalone devices, mobile app, web flasher and web config tools.

And, he’s kept that small detail a secret - that it’s all majority vibe coded.

We ran a poll recently, and asked in the MeshCore Discord about AI and trust, and these are the results:

The team didn’t feel it was our place to protest, until we recently discovered that Andy applied for the MeshCore Trademark (on the 29th March, according to filings) and didn’t tell any of us. We have tried discussing this, and what his intentions are, but those broke down and we now have no communication with Andy.

It’s been a stressful few months trying to sort this out, and is now a sad day to bring this out to the public. It’s been a slap in the face to the team that have worked so hard on this project, to have an insider team up with a robot and a lawyer.

“Official” MeshCore

The use of the ‘official’ status is what is currently being contested. Andy is adamant that he owns the brand, and is using the word very heavily with his MeshOS line.

Meanwhile, in reality, the only ‘official’ MeshCore is the github repo. It’s the source of truth in terms of what is MeshCore, and Andy has never contributed to that.

Since the internal split, we launched the meshcore.io site, as Andy controls the meshcore.co.uk site and original discord server. We’ve been left with little other recourse. And, since launching the site, Andy copied the look and feel (again, using Claude) even though we asked him not to.

Project Growth

The MeshCore project has been on an incredible journey.

Having only started in January 2025, we have grown extremely fast!

As of this post, the official MeshCore Map shows 38,000+ nodes around the world, and the official MeshCore App has more than 100,000+ active users across Android and iOS.

It’s pretty epic how we’ve all built such an incredible community in such as a short time!

As the project grows, so does our need for a dedicated space that provides you with official information from the core team.

In recent times, we’ve seen an explosion of growth in MeshCore web sites dedicated to specific countries and mesh communities.

To name a few, we’ve seen:

MeshCore Portugal over at https://meshcore.pt
MeshCore Switzerland over at https://meshcore.ch
and the first successes with MeshCore UK over at https://meshcore.co.uk

Andy Kirby did do an amazing job helping to promote the MeshCore project on his personal YouTube, but only promotes his own products now.

Where To From Here?

So, the core team are pushing ahead with the meshcore.io website, the ongoing work of firmware feature development, bug fixes, managing PR’s and developer discussions, etc.

We now release change logs, blog posts and technical documentation for all of our new firmware and app releases here.

You’ll also find some familiar faces on our blog posts, such as:

Scott our project founder, lead firmware engineer and developer of the Ripple firmware!
Recrof our official MeshCore Map developer and Firmware Flasher guru. He has shared some insights into the early development of the MeshCore Map.
Liam Cottle the official MeshCore App developer who will be posting useful guides for getting started with the MeshCore App.
FDLamotte who has done epic work on the Python tooling for MeshCore, as well as the STM32 firmware variants.
Oltaco (Che Aporeps) who has done amazing work on the new OTA Fix bootloader that makes firmware updates much more reliable.

The Core Team

The MeshCore team, now consisting of Scott, Liam, Recrof, FDLamotte and now Oltaco remain committed to designing and developing high quality, human-written software.

Our New Home

Please update your bookmarks!

This is where we will be hosting all official releases, technical documentation, and community discussions moving forward.

With the new website, we are also starting fresh with a new Discord server!

This is where you can interact directly with the MeshCore developers, get help with your projects, and contribute to the future of MeshCore.

Official Website: https://meshcore.io
Latest Updates: https://blog.meshcore.io
Technical Docs: https://docs.meshcore.io
Official GitHub: https://github.com/meshcore-dev/MeshCore
Reddit: https://reddit.com/r/meshcore
Facebook: https://facebook.com/groups/meshcore
Discord: https://meshcore.gg

Thanks for being a part of this journey!

The MeshCore Team

Release v1.15.0

2026-04-19T00:00:00+00:00

Download

Latest firmwares are in the flasher.meshcore.io

Change Log

Default Scope support
Support for New GROUP_DATA (binary) packets #1928 #2130
Heltec V4.3 support #1867
Heltec nRF Tracker (T096) support #2097
GAT562 Mesh EVB Pro repeater and room server support #2042
Radio rxgain now ON by default #2124
Radio freq range now supported down to 150Mhz #2126
GPS pref peristence fix #2018
New get|set dutycycle CLI command #1961
Muzi Works R1 Neo support #2007
GAT562 Watch support #2138 #2228
BME680 sensor init fix #2227
Heltec Wireless Paper battery read fix #2164
WiFi companion fixes for Heltec V4,TBeam 1W #1833
Waveshare RP2040: RXEN fix #2298
nRF companion, support for OTA updates #2323
Added companion for Heltec Wireless Paper #2315
Misc #2134 #2190 #1425 #2075 #2302 #2306
Xiao C3 bootloop fix #2328

Documentation Links

For info on the new Default Scope feature, please see this article.

For low level format of the GROUP_DATA packets, please see this docs link.

MeshCore Blog

Release v1.17.1

Download

Change Log

New Features

Enhancements

Bug fixes and Other

Fixes and enhancements for devices with FEM

Heltec T096 Transmit issue fix

Release v1.17.0

Download

Change Log

New Features

Enhancements

New device support

Bug fixes and Other

Packet Collision Improvements

Companion UI

JSON Config

Steps Toward Universal Companion

Thank You

Current Status

Onwards

Help Us Save MeshCore

Foreword, by Scott Powell

Timeline Summary

Why Not Just Rename?

Keeping the Core Human & Open Source

The Next Step

What Happens If We Win

What Happens If Challenge Is Not Viable

Our Final Request to Andy

Help Support the MeshCore Team

OTA Updates by Drone

The Star of the Show

How to setup and use the updater

Release v1.16.0

Download

Change Log

New Features

Enhancements

New device support

Bug fixes and Other

Limiting Unscoped Traffic

Limiting Advert Traffic

New Preamble

Improved Region Discovery in Mobile App

New region def Command

Extended ACK Support

Companion Raw Packets

pyMC Introduction

Where pymc_console fits

Where to start

Recommended Gear

Ripple UI v9.7

Display Preferences

Map Theme

Download

Meshcore.io - Why The Split?

“Official” MeshCore

Project Growth

Where To From Here?

The Core Team

Our New Home

Release v1.15.0

New `region def` Command