MeshCore Blog

Sensor Node Intro

2026-09-14T00:00:00+00:00

The MeshCore sensor node type is much harder to get going with as we don’t pre-build variants with each release, like we do with repeater, companion and room server, so it requires some developer knowledge.

The reason behind this is because there simply are too many customisations that typically would be required to accommodate, and there would have to be thousands of variants. So, sensor nodes need to be designed for whatever purpose they’re intended for (eg. monitoring water level in a water tank)

Setup

You will need to install VSCode and once that is installed, within VSCode install the PlatformIO extension.

Then use Git to clone the MeshCore firmware repo:

git clone https://github.com/meshcore-dev/MeshCore.git

Starting with the example

The sensor firmware is essentially a starter or ‘template’ firmware, which has most of the components you’re going to need. In the project tree, it is in:

/examples/simple_sensor

Typical customisations should only need to touch the main.cpp module. This has a section which defines a MyMesh class, and this inherits from SensorMesh which provides all the plumbing and hooks which you can utilise.

Choose a board variant

A lot of the boards supported should already have a PlatformIO target env defined for the simple_sensor example firmware, like [env:Heltec_v3_sensor]. But, you may need to add your own env definition in a platformio.ini file in one of the /variant folders.

This sets up the build rules/dependencies, etc for that board+firmware role. You may need to modify the target.h/cpp files of the variant. These target modules assemble various global objects, like this:

EnvironmentSensorManager sensors;

This one is a kind of Swiss Army knife helper class which the other firmwares also use (eg. repeater) for doing the low-level work of managing physical sensors, like BME180’s, etc. So, most of that is done for you, but you typically have to ENABLE which modules your node is expecting to use. These can be enabled in your /variant platformio.ini file like this:

build_flags =
  -D ENV_INCLUDE_GPS=1
  -D ENV_INCLUDE_AHTX0=1
  -D ENV_INCLUDE_BME280=1
  -D ENV_INCLUDE_BMP280=1
  -D ENV_INCLUDE_SHTC3=1
  -D ENV_INCLUDE_SHT4X=1
  -D ENV_INCLUDE_LPS22HB=1
  -D ENV_INCLUDE_INA3221=1
  -D ENV_INCLUDE_INA219=1
  -D ENV_INCLUDE_INA226=1
  -D ENV_INCLUDE_INA260=1
  -D ENV_INCLUDE_MLX90614=1
  -D ENV_INCLUDE_VL53L0X=1
  -D ENV_INCLUDE_BME680=1
  -D ENV_INCLUDE_BMP085=1

Basic concepts

The sensor node can utilise these features:

Alerts (with High or Low priority)
Telemetry queries (ie. other nodes can pull telemetry from this node)
Time series data
Custom CLI command logic (eg. ‘turn switch A on’)
Telemetry push subscriptions (NEW: will be supported soon)

Alerts

In the example this is demonstrated with the Trigger class and alertIf() calls:

  Trigger low_batt, critical_batt;

  void onSensorDataRead() override {
    float batt_voltage = getVoltage(TELEM_CHANNEL_SELF);

    alertIf(batt_voltage < 3.4f, critical_batt, HIGH_PRI_ALERT, "Battery is critical!");
    alertIf(batt_voltage < 3.6f, low_batt, LOW_PRI_ALERT, "Battery is low");
  }

High priority alerts will re-try sending to nodes in the ACL which have the PERM_RECV_ALERTS_HI bit set. The sensor nodes will wait for an ACK, like any other text message.

Low priority alerts only fire off the message once and don’t wait for an ACK. These are sent to nodes in ACL with the PERM_RECV_ALERTS_LO bit set.

Telemetry

This is basically automatic as it’s a core mechanism in MeshCore. The target/variant sensor object will handle LPP encoding all the collected telemetry readings.

Normally, other nodes to need to request telemetry from your sensor node, and a telemetry response is then sent, but very soon you will also be able to subscribe to Telemetry push, where the sensor node sends telemetry packets to subscriber(s) but only when certain values change by some minimum amount. eg. a subscriber can send SUBSCRIBE request, and specify that temperature must change by 2 Celcius.

Telemetry push will have some guard rails to hopefully minimise abuse:

subscription has a timeout (returned in the subscribe response), so subscribers will need to re-subscribe.
must use a region scope (as fallback, if direct path is not established)
subscriber must specify which LPP channels/types and min deltas that these must change by to trigger push

Time series data

The sensor can collect periodic readings, and stores these (in volatile memory, in a circular buffer) using the TimeSeriesData helper class. Example:

  TimeSeriesData  battery_data;

  MyMesh(mesh::MainBoard& board, mesh::Radio& radio, mesh::MillisecondClock& ms, mesh::RNG& rng, mesh::RTCClock& rtc, mesh::MeshTables& tables)
     : SensorMesh(board, radio, ms, rng, rtc, tables), 
       battery_data(12*24, 5*60)    // 24 hours worth of battery data, every 5 minutes
  {
  }

  void onSensorDataRead() override {
    float batt_voltage = getVoltage(TELEM_CHANNEL_SELF);

    battery_data.recordData(getRTCClock(), batt_voltage);   // record battery
  }

  int querySeriesData(uint32_t start_secs_ago, uint32_t end_secs_ago, MinMaxAvg dest[], int max_num) override {
    battery_data.calcMinMaxAvg(getRTCClock(), start_secs_ago, end_secs_ago, &dest[0], TELEM_CHANNEL_SELF, LPP_VOLTAGE);
    return 1;
  }

Remote nodes can then send ‘min/max/average’ queries to the sensor node, specifying a time range. To achieve this, the querySeriesData() method must be overridden as above. The return value is the number of data series supported by this node.

Custom CLI Commands

Remote nodes can also enable actuators of different types, like turning an LED on/off, moving a servo, etc. by adding custom CLI command logic. This is done in the handleCustomCommand() method:

  bool handleCustomCommand(uint32_t sender_timestamp, char* command, char* reply) override {
    if (strcmp(command, "magic") == 0) {    // example 'custom' command handling
      strcpy(reply, "**Magic now done**");
      return true;   // handled
    }
    return false;  // not handled
  }

This should be fairly straight-forward to adapt to whatever your sensor node wants to do. Just return true to indicate the command was intercepted and handled, and place the CLI response in the reply buffer (which is sent to command sender node).

The KISS Modem

2026-08-27T00:00:00+00:00

What the KISS Modem firmware role is, what it isn’t, and who it’s for.

Since v1.16.0 the flasher has had a KISS Modem role for most boards (the role picker calls it “KISS Radio Modem”), and going by the questions on Discord the name confuses people. So, a quick rundown.

It’s the same MeshCore firmware and the same radio underneath. What changes is how you talk to the board: instead of the app, you open a serial port and speak KISS, an old and very simple protocol that amateur radio packet modems (TNCs) have used for decades. The radio stays on the board. Everything that decides what to send, and what to do with whatever comes back, runs on the computer at the other end of the cable. What you end up with is closer to a LoRa dongle for MeshCore than a node in its own right.

Who it’s for

Most people don’t need it. If you want to message from your phone, companion firmware plus the app is where to start.

The KISS Modem is for people building gateways or services on a proper computer. OpenHop (formerly pyMC) is the obvious example and can use a KISS Modem as its radio.

It doesn’t have to be a proper computer though. I have a Commodore 64 chatting on the mesh through one, over the user port at 600 baud, which is about all the stock KERNAL serial routines can keep up with. The C64 builds the packets and draws the screen, the modem does the LoRa and the AES.

It’s also handy if you want to poke at MeshCore packets from a laptop in whatever language you like, without flashing custom firmware for every idea. (The companion firmware can hand you raw packets too, and since 1.16 send them, but here you get the whole radio with nothing in the way.)

What is KISS?

Keep It Simple, Stupid. It’s the framing amateur packet radio has used between a computer and a TNC since the 80s. MeshCore didn’t invent it, it borrowed it because it’s simple and there are libraries for it in every language.

The way I think of it: KISS is the envelope, the MeshCore packet is the letter inside.

A C0 byte on each end, a type byte, and the packet in between. That’s why the protocol doc says any KISS client (Direwolf, APRSdroid and so on) can drive the modem: they’ll happily push raw frames out through the radio. It doesn’t get them onto the mesh though. They can open the envelope, but what’s inside means nothing to them, and the mesh won’t make anything of what they send either.

On top of plain KISS the firmware adds the MeshCore extras (radio settings, signal reports, battery, crypto) through a standard KISS command that plain clients ignore.

What the board does

Quite a lot, it just doesn’t do any of the mesh logic. It sends and receives raw MeshCore packets over LoRa. Received packets come up the serial link exactly as they came off the air, each with a signal report (RSSI and SNR) attached, and your software decides what to do with them.

The host sets the radio up: frequency, bandwidth, spreading factor, coding rate and transmit power. You can also ask the board for its battery voltage, the noise floor, packet counters and whatever sensors it has, and it can estimate how long a packet would take on air at the current settings. The protocol doc has the full list.

None of the radio settings survive a reboot. Apart from the board’s key pair nothing is saved, so your software sets the radio up each time it connects.

It listens before it transmits so it won’t talk over other traffic, and it takes one packet at a time: it tells you when a packet has gone out and refuses a second one until then.

The board has its own key pair, generated on first boot and stored in flash. The private key can’t be read out, so if you want the board’s identity on the mesh you ask the board to sign and do key exchanges for you. It can also encrypt, decrypt and verify with keys you hand it. Or you skip all of that. The board sends whatever bytes you give it and doesn’t check them, so a host that keeps its own key pair builds valid packets without ever touching the board’s crypto. OpenHop does it that way. The C64 goes the other way entirely, it hasn’t got the horsepower for AES so it hands every message to the modem to encrypt or decrypt.

What it leaves out: routing, repeating, chat, room server. All of that lives on the host side.

Flashing it

Flashing is the same as any other role.

Head to flasher.meshcore.io
Pick your board
Choose the KISS Radio Modem role
Flash it
Open the board’s serial port at 115200 baud, 8N1, from software that speaks MeshCore

Step 5 is where the real work lives. On nearly every board that serial port is the USB one. There is a compile-time option (KISS_UART_RX and KISS_UART_TX) to move that onto bare UART pins if you want to wire the board straight to a Pi header, but you’ll need to build the firmware yourself for that.

If you’d rather not write the serial side yourself, OpenHop already has it. If you do want to roll your own, the KISS Modem protocol doc covers the serial side and the packet format page covers what goes inside the frames.

Where to start

Flasher: https://flasher.meshcore.io
Protocol doc: https://docs.meshcore.io/kiss_modem_protocol
Packet format: https://docs.meshcore.io/packet_format
OpenHop: https://github.com/openhop-dev/openhop_repeater

If you get something running on it, post it on the Discord, I’d like to see what people wire it into.

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.0, 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 Blog

Sensor Node Intro

Setup

Starting with the example

Choose a board variant

Basic concepts

Alerts

Telemetry

Time series data

Custom CLI Commands

The KISS Modem

Who it’s for

What is KISS?

What the board does

Flashing it

Where to start

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

New `region def` Command