MeshCore Blog

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.

Default Scope Region

2026-04-17T00:00:00+00:00

NOTE: Refer to the previous blog post if you are unfamiliar with regions/scopes

Since the v1.12.0 firmware release, scoping group channel messages has been possible, but there are still a number of road-blocks to using regions more effectively, especially for meshes like in Germany who are trying to disable un-scoped traffic (ie. region denyf *)

In the next release (v1.15.0) there will be a new concept of ‘default scope’, for both companion nodes and repeater/room server. This will make it possible to do scoped DM messages, login requests, stats request, etc. (even in a mesh that has disabled un-scoped flood traffic)

Mobile App

The MeshCore app ver 1.43.0 will have a new setting in the Experimental Settings screen. Here you can set the default scope region name.

When set, ALL flood packets the companion sends (eg. adverts, DM’s/logins/requests when path is unknown) will be scoped to this region.

Group channel scope, if set, will override the default scope. So, you can still have (typically) smaller region/scope for individual channels.

Repeater and Room Server Admin

From v1.15.0 there will be a new cli command:

region default {name | <null>}

This sets the given region as the default scope, or clears if you specify <null>. Note that the region is auto-created if currently not in the regions list. Also, an implicit region save is automatically performed!

Default scope is only applied to packets which originate from the repeater/room server. So, only adverts for repeater. Adverts and room posts for room server.

Logins/Requests/Commands and Responses

From v1.15.0 there is a new rule for responses. These originate from repeater/room server, but have this rule:

If request packet scope can be resolved (ie. Region is in its list) then same scope is used for reply
Otherwise, reply is sent un-scoped.

This includes the case of un-scoped request will have an un-scoped reply.

For now, this is the safer option, instead of having the replies default to the default-scope. While in this transition period, there are too many ways a repeater admin could shoot themselves in the foot and lock themselves out of their own repeater!

EXTRA: new ‘put’ default

The region put ... CLI command now defaults the new region to ‘allow’ for flood. So, you won’t need to also follow with region allowf ...

Standalone Devices

For Ripple GUI supported devices, like the T-Deck, the next release (v9.6) will have default-scope support. From the Regions screen, just select a plain region (or ‘*’) and in the details screen, select the menu:

(If needed, create a new region from the main region list, for the default scope)

Back in the Regions list screen, you should see a (S) displayed next to the current default scope region:

FAQ

Q: As a repeater admin, what should I set default scope to?

It should typically be a large region, eg. your city. Or, whatever the region that you wish to confine adverts to (for instance).

Q: As an app/chat user, what should I set default scope to?

This should be a large region which will safely include both yourself and the contact(s) you wish to DM. Both your messages, and the returning ACKs will be scoped to this region.

Q: I manage regional MeshCore firmware builds, with best defaults for the region. Can I configure a custom default region in my builds?

Yes. In the relevant .ini files, just add to build_flags -D DEFAULT_FLOOD_SCOPE_NAME='" .. "' (with the name in quotes)

Installing the OTAFix Bootloader

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

Background

When I was first getting into MeshCore I realised that nRF52 devices had the ability to do OTA updates via BLE, which is obviously a great feature when you need to update a repeater which is on a roof.

Unfortunately I never had much luck getting this to work. If you were lucky and used the right settings it might work with RAK4631 but particularly with ProMicro devices it never worked at all. This led me to dig around in github where I found some ancient forgotten PRs to fix some of these issues.

Since they weren’t getting any attention on the official Adafruit github I took it upon myself to fork the bootloader and include these fixes myself.

Installing the OTAFIX Bootloader for nRF52 devices

For the best nRF52 OTA update experience, it’s recommended to upgrade your device to the OTAFIX bootloader. This version includes:

Automatic fallback to OTA DFU mode if an update fails
Significantly faster OTA update speeds
Additional quality-of-life improvements for certain devices, like to the ability to enter OTA DFU mode by holding a button while resetting.

1. Enter UF2 DFU Mode

First, put your device into UF2 DFU mode.

For most nRF52 devices:

Plug the device into your computer
Quickly double-press the reset button (twice within 0.5 seconds)
A UF2 USB drive should appear, the name of the drive will differ depending on the device.

Some devices use different methods, see the notes at the end of this guide.

2. Check Your Current Bootloader (Optional but Recommended)

This step is important for devices like the Seeed Studio XIAO nRF52840, which often ship with the SENSE bootloader variant.

To check:

Enter UF2 DFU mode
Open the INFO_UF2.TXT file on the mounted drive

This file contains details about your current bootloader.

Example: If the file shows: Board-ID: nRF52840-SeeedXiaoSense-v1 then you will need to install the SENSE variant.

3. Download the OTAFIX Bootloader

You can now download the OTAFIX bootloader directly from the MeshCore flasher site! Go to https://flasher.meshcore.io

Select your device
Choose Repeater
A download link for the OTAFIX bootloader will appear in a highlighted banner, the file will be titled update-xxxx.uf2

Alternatively the OTAFIX bootloader is also available from the official site. Go to:
https://github.com/oltaco/Adafruit_nRF52_Bootloader_OTAFIX/releases

Download the correct UF2 file for your device from the Assets section.

Files are named like: update-xxxx.uf2
You may need to click “Show more” to see all available files

Example: For the Seeed Xiao Sense variant as discussed above you will want to download update-xiao_nrf52840_ble_sense_bootloader-0.9.2-OTAFIX2.1-BP1.2_nosd.uf2

4. Install the Bootloader

Drag and drop the update-xxxx.uf2 file onto the UF2 drive
The device will automatically:
- Update the bootloader
- Reboot when complete

5. Verify the Update

Re-enter UF2 DFU mode
Open INFO_UF2.TXT again

The version line should now include OTAFIX.

Device-Specific Notes

T1000-e DFU Mode

To enter DFU mode:

Attach the magnetic USB cable
Hold the button
Quickly disconnect and reconnect the cable twice

Video reference: https://www.youtube.com/shorts/D6uo93-RcaY

ThinkNode M3 DFU Mode

To enter DFU mode:

Attach the magnetic USB cable
Hold the button for ~25–30 seconds

Ripple v9.4 for HeltecV4

2026-04-05T00:00:00+00:00

I’ve now added map tiles support for the Heltec V4 Expansion Kit.

Download

You can download + flash in one easy step using this direct link to the MeshCore Flasher target.

NOTE: there are two firmware variants now; one for existing uses who don’t want map tiles support, and a new ‘LittleFS’ variant for map tiles support.

WARNING: The LittleFS variant uses a different flash storage partition scheme, and you will lose all your settings if you switch to this one. However, once on this variant it’s safe to do future upgrades and not lose settings.

General Guide

The Heltecv4 has a UI which mostly like the other Ultra devices, like the T-Deck, so refer to the general user guide here for details.

The ‘LittleFS’ Firmware

This new variant, it carves out a LittleFS partition about 14Mb in size. So, you can drop map tiles up to about that size. This is fairly limited, but you should be able to drop some subset of your local geography for a few zoom levels.

Please see the FAQ about how to get map tiles.

Copying Files to LittleFS

There is a handy online tool called ESPConnect which makes it easy to connect the HeltecV4 via USB to your computer, then add/modify/delete the files in the LittleFS partition.

Just click on the CONNECT button at the top, select the port for your USB connection, then click on the LittleFS Tools tab:

You’ll need to be patient while it does a full read of the partition, but once done, it will ask you to click BACKUP (which is very handy), that saves the entire partition to a .bin file.

If you look below, you should then see the various files/folders in the file system. For the map tiles, just drag/drop the whole ‘tiles’ folder you have prepared on your computer. NOTE: you will see this warning if you’ve blown the size limit:

You should see the orange warning Unsaved changes after adding/removing files/folder, and once you have made all the changes need, just click the blue SAVE TO FLASH button:

Again, you’ll need to be patient as it writes the entire partition back to the device. But, once it’s done just disconnect the device, then press the Reset button on the device.

MeshCore Blog

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

Default Scope Region

Mobile App

Repeater and Room Server Admin

Standalone Devices

FAQ

Installing the OTAFix Bootloader

Background

Installing the OTAFIX Bootloader for nRF52 devices

1. Enter UF2 DFU Mode

2. Check Your Current Bootloader (Optional but Recommended)

3. Download the OTAFIX Bootloader

4. Install the Bootloader

5. Verify the Update

Device-Specific Notes

T1000-e DFU Mode

ThinkNode M3 DFU Mode

Ripple v9.4 for HeltecV4

Download

General Guide

The ‘LittleFS’ Firmware

Copying Files to LittleFS

New `region def` Command