Usage: - neighbor.remove <pubkey_prefix>
neighbor.remove <pubkey_prefix>
Parameters: -- pubkey_prefix: The public key of the node to remove from the neighbors list
pubkey_prefix
Note: You can remove all neighbors by sending a space character as the prefix. The space indicates an empty prefix, which matches all existing neighbors.
A list of frequently-asked questions and answers for MeshCore
path.hash.mode
A: MeshCore is a multi platform system for enabling secure text based communications utilising LoRa radio hardware. It can be used for Off-Grid Communication, Emergency Response & Disaster Recovery, Outdoor Activities, Tactical Security including law enforcement and private security and also IoT sensor networks. (source)
MeshCore is free and open source: * MeshCore is the routing and firmware etc, available on GitHub under MIT license * There are clients made by the community, such as the web clients, these are free to use, and some are open source too @@ -3040,17 +2622,18 @@
A: Everything you need for MeshCore is available at:
You need LoRa hardware devices to run MeshCore firmware as clients or server (repeater and room server).
MeshCore is available on a variety of 433MHz, 868MHz and 915MHz LoRa devices. For example, Lilygo T-Deck, T-Pager, RAK Wireless WisBlock RAK4631 devices (e.g. 19003, 19007, 19026), Heltec V3, Xiao S3 WIO, Xiao C3, Heltec T114, Station G2, Nano G2 Ultra, Seeed Studio T1000-E. More devices are being added regularly.
For an up-to-date list of supported devices, please go to https://flasher.meshcore.co.uk/
For an up-to-date list of supported devices, please go to https://flasher.meshcore.io
To use MeshCore without using a phone as the client interface, you can run MeshCore on a LiLygo's T-Deck, T-Deck Plus, T-Pager, T-Watch, or T-Display Pro. MeshCore Ultra firmware running on these devices are a complete off-grid secure communication solution.
MeshCore has four firmware types that are not available on other LoRa systems. MeshCore has the following:
BLE Companion BLE Companion firmware runs on a supported LoRa device and connects to a smart device running the Android or iOS MeshCore client over BLE - https://meshcore.co.uk/apps.html
USB Serial Companion USB Serial Companion firmware runs on a supported LoRa device and connects to a smart device or a computer over USB Serial running the MeshCore web client - https://meshcore.liamcottle.net/#/ - https://client.meshcore.co.uk/tabs/devices
A: - When MeshCore is flashed onto a LoRa device is for the first time, it is necessary to set the server device's frequency to make it utilize the frequency that is legal in your country or region.
Repeater or room server can be administered with one of the options below:
Connect the server device using a USB cable to a computer running Chrome on https://flasher.meshcore.co.uk/, then use the console feature to connect to the device
console
Connect the server device using a USB cable to a computer running Chrome on https://flasher.meshcore.io, then use the console feature to connect to the device
Use a MeshCore smartphone clients to remotely administer servers via LoRa.
Reboot the repeater after set prv.key <hex> command for the new private key to take effect.
set prv.key <hex>
A: You can generate a new private key and specific the first byte of its public key here: https://gessaman.com/mc-keygen/
Having multiple repeaters with the same first byte ID does not negatively affect the mesh or its functionality. Flood and pathed packets will still reach their destinations. First byte ID collision makes traceroute and path analysis harder because these tools don't know exactly which of the two (or more) colliding repeaters is the one in the path.
Best practice is when you set up a new repeater, choose a public key that is not in use. If it is not possible to find a unique first byte for your repeater's public key, choose one that is unique within about 10 miles (16 km) to minimize collision with nearby repeaters.
A: This may be due to the SX1262 radio's auto gain control feature. You can use this command to periodically reset its AGC.
set agc.reset.interval <number>
This is a very low cost operation. AGC reset is done by simply setting state = STATE_IDLE; in function RadioLibWrapper::resetAGC() in RadioLibWrappers.cpp
state = STATE_IDLE;
RadioLibWrapper::resetAGC()
RadioLibWrappers.cpp
A: The observer instruction is available here: https://analyzer.letsmesh.net/observer/onboard
A: +The original MeshCore protocol design uses the first byte of a repeater's public key to denote the repeater in a path. And with 1 byte for each repeater in the path, MeshCore packets can travel as many as 64 hops.
However, with 1 byte, there are only 254 unique IDs (exclude 00 and FF which are reserved). Many meshes group have multiple repeaters with the same first byte in their public keys. Packets continue to pass through repeaters and the mesh is not harmed in anyway. It does make it harder for tools to analyze paths with duplicated repeater IDs.
Firmware version 1.14 and newer introduces the ability for repeaters to advert with 1-, 2-, or 3-byte adverts. Companions can also send out channel and direct messages with 1-, 2-, or 3-byte path. Adverts and messages sent in 1-byte path is compatible with repeater firmware older or newer than 1.14. They will travel up to 64 hops. 2-byte adverts and messages will travel up to 32 hops. 3-byte adverts and messages will travel up to 21 hops.
Repeaters running firmware 1.14+ repeat packets sent with 1-, 2-, or 3-byte path hash. Repeaters on firmware older than 1.14 only repeat 1-byte path hash packets and silently drop 2- and 3-byte packets.
The original packet sender determines the path hash size. The most common original sender is a companion app. The other common original sender is a repeater, when it broadcasts its advert.
As of firmware version 1.14 and MeshCore app version 1.41.0, in the MeshCore app, you can set your companion's message path hash size in Settings (gear icon), Experimental Settings.
Settings (gear icon)
Experimental Settings
Until your regional mesh has the vast majority of the repeaters updated to 1.14+ firmware, it is recommended to keep your companion at the default 1-byte because pre-1.14 repeaters will silently drop messages with larger path hashes.
This CLI command path.hash.mode only controls the path hash size used in a repeater's own advert broadcasts. It does NOT affect which packets the repeater forwards. A repeater with firmware 1.14+ always forward 1-, 2-, and 3-byte packets regardless of this setting.
Usage: set path.hash.mode {0|1|2}:
set path.hash.mode {0|1|2}
┌────────────────┬───────────────────────┐ +│ path.hash.mode │ Advert path hash size │ +├────────────────┼───────────────────────┤ +│ 0 │ 1 byte (default) │ +├────────────────┼───────────────────────┤ +│ 1 │ 2 bytes │ +├────────────────┼───────────────────────┤ +│ 2 │ 3 bytes │ +└────────────────┴───────────────────────┘ +
It is safe to set your 1.14+ repeaters to mode 1 or 2.
A longer path hash helps tools like the LetsMesh.net Analyzer and MeshMapper disambiguate repeaters more reliably. With only 1 byte, the chance of different repeaters having the same first byte in their public key is high, making it harder to tell them apart in mesh network analysis. Since this only affects adverts, there's no downside. 2- and 3-byte adverts don't travel as far as 1-byte adverts, but it is not important for MeshCore nodes to hear a repeater's advert that are 21 or 32 hops away.
You should move to send 2-byte or 3-byte channel and direct messages when the vast majority of the repeaters in your regional mesh are updated to firmware version 1.14 or newer. Setting your repeater's path.hash.mode to 1 (for 2-byte path hash) or 2 (for 3-byte path hash) now helps the community gauge to how many repeaters have updated to 1.14+. Please work with your MeshCore community together to decide when to switch to 2-byte path or 3-byte path for channel and direct messages.
A: For T-Deck Plus, the GPS baud rate should be set to 38400. Also, some T-Deck Plus devices were found to have the GPS module installed upside down, with the GPS antenna facing down instead of up. If your T-Deck Plus still doesn't get any satellite lock after setting the baud rate to 38400, you might need to open the device to check the GPS orientation.
GPS on T-Deck is always enabled. You can skip the "GPS clock sync" and the T-Deck will continue to try to get a GPS lock. You can go to the GPS Info screen; you should see the Sentences: counter increasing if the baud rate is correct.
GPS Info
Sentences:
MeshCore clients would need to reset path constantly and flood traffic across the network which could lead to lots of collisions with something as chatty as ATAK.
This could change in the future if MeshCore develops a client firmware that repeats. Source
A:
To add a BLE Companion radio, connect to the BLE Companion radio from the MeshCore smartphone app. In the app, tap the 3 dot menu icon at the top right corner, then tap Internet Map. Tap the 3 dot menu icon again and choose Add me to the Map
3 dot
Internet Map
Add me to the Map
To add a Repeater or Room Server to the map, go to the Contact List, tap the 3 dot next to the Repeater or Room Server you want to add to the Internet Map, tap Share, then tap Upload to Internet Map.
Share
Upload to Internet Map
Instructions for nRF devices like RAK, T1000-E, T114 are immediately after the ESP instructions
For ESP-based devices (e.g. Heltec V3) you need: -- Download firmware file from flasher.meshcore.co.uk +- Download firmware file from https://flasher.meshcore.io - Go to the web site on a browser, find the section that has the firmware up need - Click the Download button, right click on the file you need, for example, - Heltec_V3_companion_radio_ble-v1.7.1-165fb33.bin - Non-merged bin keeps the existing Bluetooth pairing database - Heltec_v3_companion_radio_usb-v1.7.1-165fb33-merged.bin - Merged bin overwrites everything including the bootloader, existing Bluetooth pairing database, but keeps configurations. - - Right click on the file name and copy the link and note it for later use here is an example: https://flasher.meshcore.dev/releases/download/companion-v1.7.1/Heltec_v3_companion_radio_ble-v1.7.1-165fb33.bin + - Right click on the file name and copy the link and note it for later use here is an example: https://flasher.meshcore.io/releases/download/companion-v1.7.1/Heltec_v3_companion_radio_ble-v1.7.1-165fb33.bin - Run: - - wget https://flasher.meshcore.dev/releases/download/companion-v1.7.1/Heltec_v3_companion_radio_ble-v1.7.1-165fb33.bin to download the firmware file for your device type. or the version you need - USB, BLE, Repeater, Room Server, merged bin or non-merged bin + - wget https://flasher.meshcore.io/releases/download/companion-v1.7.1/Heltec_v3_companion_radio_ble-v1.7.1-165fb33.bin to download the firmware file for your device type. or the version you need - USB, BLE, Repeater, Room Server, merged bin or non-merged bin - If the above wget command only downloads a very small file (10K bytes instead of more than 100K byte, use this command instead: - - wget --user-agent="Mozilla/5.0" --content-disposition "https://flasher.meshcore.dev/releases/download/companion-v1.7.1/Heltec_v3_companion_radio_usb-v1.7.1-165fb33.bin" + - wget --user-agent="Mozilla/5.0" --content-disposition "https://flasher.meshcore.io/releases/download/companion-v1.7.1/Heltec_v3_companion_radio_usb-v1.7.1-165fb33.bin" - Confirm the ttyXXXX device path on your Raspberry Pi: - Go to /dev directory, run ls command to find confirm your device path - They are usually /dev/ttyUSB0 for ESP devices @@ -3353,14 +2967,14 @@ Below are the instructions to flash firmware onto a supported LoRa device using - esptool.py -p /dev/ttyUSB0 --chip esp32-s3 write_flash 0x00000 <merged_firmware>.bin
Heltec_V3_companion_radio_ble-v1.7.1-165fb33.bin
Heltec_v3_companion_radio_usb-v1.7.1-165fb33-merged.bin
https://flasher.meshcore.dev/releases/download/companion-v1.7.1/Heltec_v3_companion_radio_ble-v1.7.1-165fb33.bin
https://flasher.meshcore.io/releases/download/companion-v1.7.1/Heltec_v3_companion_radio_ble-v1.7.1-165fb33.bin
wget https://flasher.meshcore.dev/releases/download/companion-v1.7.1/Heltec_v3_companion_radio_ble-v1.7.1-165fb33.bin
wget https://flasher.meshcore.io/releases/download/companion-v1.7.1/Heltec_v3_companion_radio_ble-v1.7.1-165fb33.bin
wget --user-agent="Mozilla/5.0" --content-disposition "https://flasher.meshcore.dev/releases/download/companion-v1.7.1/Heltec_v3_companion_radio_usb-v1.7.1-165fb33.bin"
wget --user-agent="Mozilla/5.0" --content-disposition "https://flasher.meshcore.io/releases/download/companion-v1.7.1/Heltec_v3_companion_radio_usb-v1.7.1-165fb33.bin"
ttyXXXX
/dev
/dev/ttyUSB0
esptool.py -p /dev/ttyUSB0 --chip esp32-s3 write_flash 0x00000 <merged_firmware>.bin
Instructions for nRF devices:
For nRF devices (e.g. RAK, Heltec T114) you need the following: -- Download firmware file from flasher.meshcore.co.uk +- Download firmware file from https://flasher.meshcore.io - Go to the web site on a browser, find the section that has the firmware up need - You need the ZIP version for the adafruit flash tool (below) - Click the Download button, right click on the ZIP file, for example: - RAK_4631_companion_radio_ble-v1.7.1-165fb33.zip - - Right click on the file name and copy the link and note it for later use here is an example: https://flasher.meshcore.dev/releases/download/companion-v1.7.1/RAK_4631_companion_radio_ble-v1.7.1-165fb33.zip + - Right click on the file name and copy the link and note it for later use here is an example: https://flasher.meshcore.io/releases/download/companion-v1.7.1/RAK_4631_companion_radio_ble-v1.7.1-165fb33.zip - Run: - - wget https://flasher.meshcore.dev/releases/download/companion-v1.7.1/RAK_4631_companion_radio_ble-v1.7.1-165fb33.zip to download the firmware file for your device type. or the version you need - USB, BLE, Repeater, Room Server, ZIP file only + - wget https://flasher.meshcore.io/releases/download/companion-v1.7.1/RAK_4631_companion_radio_ble-v1.7.1-165fb33.zip to download the firmware file for your device type. or the version you need - USB, BLE, Repeater, Room Server, ZIP file only - Confirm the ttyXXXX device path on your Raspberry Pi: - Go to /dev directory, run ls command to find confirm your device path - They are usually /dev/ttyACM0 for nRF devices @@ -3375,74 +2989,12 @@ Below are the instructions to flash firmware onto a supported LoRa device using
RAK_4631_companion_radio_ble-v1.7.1-165fb33.zip
https://flasher.meshcore.dev/releases/download/companion-v1.7.1/RAK_4631_companion_radio_ble-v1.7.1-165fb33.zip
https://flasher.meshcore.io/releases/download/companion-v1.7.1/RAK_4631_companion_radio_ble-v1.7.1-165fb33.zip
wget https://flasher.meshcore.dev/releases/download/companion-v1.7.1/RAK_4631_companion_radio_ble-v1.7.1-165fb33.zip
wget https://flasher.meshcore.io/releases/download/companion-v1.7.1/RAK_4631_companion_radio_ble-v1.7.1-165fb33.zip
/dev/ttyACM0
From here, reference repeater and room server command line commands on MeshCore github wiki here: - https://github.com/meshcore-dev/MeshCore/wiki/Repeater-&-Room-Server-CLI-Reference
A: Yes. Some of them are listed below.
Some resources that by themselves give overviews about MeshCore related projects:
A meta website/ git-repository collecting many projects related to MeshCore, grouped by type. See -https://github.com/samuk/awesome-meshcore.
A Python script to send meshcore debug and packet capture data to MQTT for analysis. Cisien's version is a fork of Andrew-a-g's and is being used to to collect data for https://map.w0z.is/messages and https://analyzer.letsmesh.net/ -https://github.com/Cisien/meshcoretomqtt -https://github.com/Andrew-a-g/meshcoretomqtt
A custom Home Assistant integration for MeshCore mesh radio nodes. It allows you to monitor and control MeshCore nodes via USB, BLE, or TCP connections. -https://github.com/awolden/meshcore-ha
Bindings to access your MeshCore companion radio nodes in python. -https://github.com/fdlamotte/meshcore_py
CLI interface to MeshCore companion radio over BLE, TCP, or serial. Uses Python MeshCore above. - https://github.com/fdlamotte/meshcore-cli
A JavaScript library for interacting with a MeshCore device running the companion radio firmware -https://github.com/liamcottle/meshcore.js
pyMC_Core is a Python port of MeshCore, designed for Raspberry Pi and similar hardware, it talks to LoRa modules over SPI. -https://github.com/rightup/pyMC_core
A TypeScript library for decoding MeshCore mesh networking packets with full cryptographic support. Uses WebAssembly (WASM) for Ed25519 key derivation through the orlp/ed25519 library. It powers the MeshCore Packet Analyzer. -https://github.com/michaelhart/meshcore-decoder
meshcore-pi is another Python port of MeshCore, designed for Raspberry Pi and similar hardware, it talks to LoRa modules over SPI or GPIO. -https://github.com/brianwiddas/meshcore-pi
pyMC_Repeater is a repeater daemon in Python built on top of the pymc_core library. -https://github.com/rightup/pyMC_Repeater
pymc_core
A Node.js software that will upload every repeater or room server to map.meshcore.dev when a connected companion hears new advert. -https://github.com/recrof/map.meshcore.dev-uploader
Open Source companion app for Android, iOS, GNU/Linux (and maybe other Unixes), Windows, macOS, chromium-based browsers. -https://github.com/zjs81/meshcore-open
Standalone client firmware for the "M5Stack Cardputer ADV" with the "M5Stack Cap LoRa-1262" module.
There are two variants:
Multi-protocol mesh firmware for ESP32-S3 LoRa devices (MeshCore, Meshtastic, RNode/KISS (Reticulum)). Protocol is auto-detected from the first bytes over serial or BLE. -https://github.com/STCisGOOD/lunarcore
(Soon to be) Open Source companion firmware for LilyGO T-Deck (Plus) and Seeed Studio SenseCap Indicator (TFT / D1Pro), that can be used both standalone and together with a companion app. -https://github.com/dabeani/meshcore
Companion firmware for LilyGo T-Deck Pro that allows standalone operation and connection to a companion app via Bluetooth Low Energy (BLE). -https://github.com/pelgraine/Meck
Companion firmware for Seeed Studio Wio Tracker L1 Pro with specific UI adjustments that can be used standalone. -https://github.com/sosprz/Meshcore-Wio-Tracker-L1-Pro
(None yet listed here. See overview ressources.)
A: Yes, there are many. MeshCore's protocol is open source using the MIT license. The MIT license and the open source protocol makes it very easy for the MeshCore community to build new firmware for radios, applications on mobile devices, map tools, and analysis tools, and integration with other projects like Home Asistant.
As new MeshCore community projects become available on a weekly basis, we have stopped tracking them here in this FAQ. samuk maintains a very exhausive list of MeshCore community project at https://github.com/samuk/awesome-meshcore/blob/main/README.md. samuk accepts PRs and merges them regularly.
A: Yes, the same iOS and Android client is also available for Windows and Intel Mac (sorry, not available for ARM-based Mac yet). You can find them together with the Android APK here: +
A: Yes, the same iOS and Android client is also available for Windows and Mac. You can find them together with the Android APK here: https://files.liamcottle.net/MeshCore
Both the Windows and Intel Mac versions of the client app are fully unlocked and are free to use.
Both the Windows and Mac versions of the client app are fully unlocked and are free to use.
A: Here is a list of MeshCore comparison resources: The Comms Channel on YouTube: @@ -3475,15 +3027,15 @@ https://www.austinmesh.org/learn/meshcore-vs-meshtastic/
flash_erase*.uf2
Flash_erase-nRF32_softdevice_v6.uf2
Flash_erase-nRF52_softdevice_v7.uf2
Console
Separately, starting in firmware version 1.7.0, there is a CLI Rescue mode. If your device has a user button (e.g. some RAK, T114), you can activate the rescue mode by hold down the user button of the device within 8 seconds of boot. Then you can use the 'Console' on flasher.meshcore.co.uk
Separately, starting in firmware version 1.7.0, there is a CLI Rescue mode. If your device has a user button (e.g. some RAK, T114), you can activate the rescue mode by hold down the user button of the device within 8 seconds of boot. Then you can use the 'Console' on https://flasher.meshcore.io
A: If the usb port doesn't have the right ownership for this task, the process fails with the following error: NetworkError: Failed to execute 'open' on 'SerialPort': Failed to open serial port.
NetworkError: Failed to execute 'open' on 'SerialPort': Failed to open serial port.
A: The steps below work on both Android and iOS as nRF has made both apps' user interface the same on both platforms:
nrf dfu
nRF Device Firmware Update
start ota
OK
After this bootloader is flashed onto the device, you can trigger over the air update using bluetooth by holding the button next to the D-Pad and then click the reset button. The follow the same OTA update instructions above. You can skip pass the start ota instruction and start the update using the DFU app.
A: For ESP32-based devices (e.g. Heltec V3): -1. On flasher.meshcore.co.uk, download the non-merged version of the firmware for your ESP32 device (e.g. Heltec_v3_repeater-v1.6.2-4449fd3.bin, no "merged" in the file name) +1. On https://flasher.meshcore.io, download the non-merged version of the firmware for your ESP32 device (e.g. Heltec_v3_repeater-v1.6.2-4449fd3.bin, no "merged" in the file name) 2. From the MeshCore app, login remotely to the repeater you want to update with admin privilege 4. Go to the Command Line tab, type start ota and hit enter. 5. you should see OK to confirm the repeater device is now in OTA mode @@ -3554,9 +3106,7 @@ Edit WIFI_SSID and WIFI_PWD in ./variants/heltec_v3/platformio.ini
Heltec_v3_repeater-v1.6.2-4449fd3.bin
"merged"
./variants/heltec_v3/platformio.ini
A: For companion radios, you can set these radios' transmit power in the smartphone app. For repeater and room server radios, you can set their transmit power using the command line command set tx. You can get their current value using command line comand get tx
set tx
get tx
-⚠️ WARNING: Set these values at your own risk. Incorrect power settings can permanently damage your radio hardware. -
⚠️ WARNING: Set these values at your own risk. Incorrect power settings can permanently damage your radio hardware.
Welcome to the MeshCore documentation.
Below are a few quick start guides.
If you find a mistake in any of our documentation, or find something is missing, please feel free to open a pull request for us to review.
This document provides an overview of CLI commands that can be sent to MeshCore Repeaters, Room Servers and Sensors.
Usage: - reboot
reboot
Usage: - clkreboot
clkreboot
Usage: - clock sync
clock sync
Usage: - clock
clock
Usage: - time <epoch_seconds>
time <epoch_seconds>
Parameters: - epoch_seconds: Unix epoch time
epoch_seconds
Usage: - advert
advert
Usage: - advert.zerohop
advert.zerohop
Usage: - start ota
Usage: - erase
erase
Serial Only: Yes
Warning: This is destructive!
Usage: - neighbors
neighbors
Note: The output of this command is limited to the 8 most recent adverts.
Note: Each line is encoded as {pubkey-prefix}:{timestamp}:{snr*4}
{pubkey-prefix}:{timestamp}:{snr*4}
Parameters: - pubkey_prefix: The public key of the node to remove from the neighbors list
Usage: clear stats
clear stats
Usage: - stats-core
stats-core
Usage: stats-radio
stats-radio
Usage: stats-packets
stats-packets
Usage: log start
log start
Usage: log stop
log stop
Usage: log erase
log erase
Usage: log
log
Usage: ver
ver
Usage: board
board
Usage: - get radio - set radio <freq>,<bw>,<sf>,<cr>
get radio
set radio <freq>,<bw>,<sf>,<cr>
Parameters: - freq: Frequency in MHz - bw: Bandwidth in kHz - sf: Spreading factor (5-12) - cr: Coding rate (5-8)
freq
bw
sf
cr
Set by build flag: LORA_FREQ, LORA_BW, LORA_SF, LORA_CR
LORA_FREQ
LORA_BW
LORA_SF
LORA_CR
Default: 869.525,250,11,5
869.525,250,11,5
Note: Requires reboot to apply
Usage: - get tx - set tx <dbm>
set tx <dbm>
Parameters: - dbm: Power level in dBm (1-22)
dbm
Set by build flag: LORA_TX_POWER
LORA_TX_POWER
Default: Varies by board
Notes: This setting only controls the power level of the LoRa chip. Some nodes have an additional power amplifier stage which increases the total output. Refer to the node's manual for the correct setting to use. Setting a value too high may violate the laws in your country.
Usage: - tempradio <freq>,<bw>,<sf>,<cr>,<timeout_mins>
tempradio <freq>,<bw>,<sf>,<cr>,<timeout_mins>
Parameters: - freq: Frequency in MHz (300-2500) - bw: Bandwidth in kHz (7.8-500) - sf: Spreading factor (5-12) - cr: Coding rate (5-8) - timeout_mins: Duration in minutes (must be > 0)
timeout_mins
Note: This is not saved to preferences and will clear on reboot
Usage: - get freq - set freq <frequency>
get freq
set freq <frequency>
Parameters: - frequency: Frequency in MHz
frequency
Default: 869.525
869.525
Note: Requires reboot to apply Serial Only: set freq <frequency>
Usage: - get name - set name <name>
get name
set name <name>
Parameters: - name: Node name
name
Set by build flag: ADVERT_NAME
ADVERT_NAME
Note: Max length varies. If a location is set, the max length is 24 bytes; 32 otherwise. Emoji and unicode characters may take more than one byte.
Usage: - get lat - set lat <degrees>
get lat
set lat <degrees>
Set by build flag: ADVERT_LAT
ADVERT_LAT
Default: 0
0
Parameters: - degrees: Latitude in degrees
degrees
Usage: - get lon - set lon <degrees>
get lon
set lon <degrees>
Set by build flag: ADVERT_LON
ADVERT_LON
Parameters: - degrees: Longitude in degrees
Usage: - get prv.key - set prv.key <private_key>
get prv.key
set prv.key <private_key>
Parameters: - private_key: Private key in hex format (64 hex characters)
private_key
Serial Only: - get prv.key: Yes - set prv.key: No
set prv.key
Note: Requires reboot to take effect after setting
Usage: - password <new_password>
password <new_password>
Parameters: - new_password: New admin password
new_password
Set by build flag: ADMIN_PASSWORD
ADMIN_PASSWORD
Default: password
password
Note: Command reply echoes the updated password for confirmation.
Note: Any node using this password will be added to the admin ACL list.
Usage: - get guest.password - set guest.password <password>
get guest.password
set guest.password <password>
Parameters: - password: Guest password
Set by build flag: ROOM_PASSWORD (Room Server only)
ROOM_PASSWORD
Default: <blank>
<blank>
Usage: - get owner.info - set owner.info <text>
get owner.info
set owner.info <text>
Parameters: - text: Owner information text
text
Note: | characters are translated to newlines
|
Note: Requires firmware 1.12.+
Usage: - get adc.multiplier - set adc.multiplier <value>
get adc.multiplier
set adc.multiplier <value>
Parameters: - value: ADC multiplier (0.0-10.0)
value
Default: 0.0 (value defined by board)
0.0
Note: Returns \"Error: unsupported by this board\" if hardware doesn't support it
Usage: get public.key
get public.key
Usage: get role
get role
Usage: - powersaving - powersaving on - powersaving off
powersaving
powersaving on
powersaving off
Parameters: - on: enable power saving - off: disable power saving
on
off
Default: on
Note: When enabled, device enters sleep mode between radio transmissions
Usage: - get repeat - set repeat <state>
get repeat
set repeat <state>
Parameters: - state: on|off
state
Usage: - get path.hash.mode - set path.hash.mode <value>
get path.hash.mode
set path.hash.mode <value>
Parameters: - value: Path hash size (0-2) - 0: 1 Byte hash size (256 unique ids)[64 max flood] - 1: 2 Byte hash size (65,536 unique ids)[32 max flood] - 2: 3 Byte hash size (16,777,216 unique ids)[21 max flood] - 3: DO NOT USE (Reserved)
1
2
3
Note: the 'path.hash.mode' sets the low-level ID/hash encoding size used when the repeater adverts. This setting has no impact on what packet ID/hash size this repeater forwards, all sizes should be forwarded on firmware >= 1.14. This feature was added in firmware 1.14
Temporary Note: adverts with ID/hash sizes of 2 or 3 bytes may have limited flood propogation in your network while this feature is new as v1.13.0 firmware and older will drop packets with multibyte path ID/hashes as only 1-byte hashes are suppored. Consider your install base of firmware >=1.14 has reached a criticality for effective network flooding before implementing higher ID/hash sizes.
Usage: - get loop.detect - set loop.detect <state>
get loop.detect
set loop.detect <state>
Parameters: - state: - off: no loop detection is performed - minimal: packets are dropped if repeater's ID/hash appears 4 or more times (1-byte), 2 or more (2-byte), 1 or more (3-byte) - moderate: packets are dropped if repeater's ID/hash appears 2 or more times (1-byte), 1 or more (2-byte), 1 or more (3-byte) - strict: packets are dropped if repeater's ID/hash appears 1 or more times (1-byte), 1 or more (2-byte), 1 or more (3-byte)
minimal
moderate
strict
Default: off
Note: When it is enabled, repeaters will now reject flood packets which look like they are in a loop. This has been happening recently in some meshes when there is just a single 'bad' repeater firmware out there (prob some forked or custom firmware). If the payload is messed with, then forwarded, the same packet ends up causing a packet storm, repeated up to the max 64 hops. This feature was added in firmware 1.14
Example: If preference is loop.detect minimal, and a 1-byte path size packet is received, the repeater will see if its own ID/hash is already in the path. If it's already encoded 4 times, it will reject the packet. If the packet uses 2-byte path size, and repeater's own ID/hash is already encoded 2 times, it rejects. If the packet uses 3-byte path size, and the repeater's own ID/hash is already encoded 1 time, it rejects.
loop.detect minimal
Usage: - get txdelay - set txdelay <value>
get txdelay
set txdelay <value>
Parameters: - value: Transmit delay factor (0-2)
Default: 0.5
0.5
Usage: - get direct.txdelay - set direct.txdelay <value>
get direct.txdelay
set direct.txdelay <value>
Parameters: - value: Direct transmit delay factor (0-2)
Default: 0.2
0.2
Usage: - get rxdelay - set rxdelay <value>
get rxdelay
set rxdelay <value>
Parameters: - value: Receive delay base (0-20)
Default: 0.0
Usage: - get af - set af <value>
get af
set af <value>
Parameters: - value: Airtime factor (0-9). After each transmission, the repeater enforces a silent period of approximately the on-air transmission time multiplied by the value. This results in a long-term duty cycle of roughly 1 divided by (1 plus the value). For example: - af = 1 \u2192 ~50% duty - af = 2 \u2192 ~33% duty - af = 3 \u2192 ~25% duty - af = 9 \u2192 ~10% duty Yyou are responsible for choosing a value that is appropriate for your jurisdiction and channel plan (for example EU 868 Mhz 10% duty cycle regulation).
af = 1
af = 2
af = 3
af = 9
Default: 1.0
1.0
Usage: - get int.thresh - set int.thresh <value>
get int.thresh
set int.thresh <value>
Parameters: - value: Interference threshold value
Usage: - get agc.reset.interval - set agc.reset.interval <value>
get agc.reset.interval
set agc.reset.interval <value>
Parameters: - value: Interval in seconds rounded down to a multiple of 4 (17 becomes 16)
Usage: - get multi.acks - set multi.acks <state>
get multi.acks
set multi.acks <state>
Parameters: - state: 0 (disable) or 1 (enable)
Usage: - get flood.advert.interval - set flood.advert.interval <hours>
get flood.advert.interval
set flood.advert.interval <hours>
Parameters: - hours: Interval in hours (3-168)
hours
Default: 12 (Repeater) - 0 (Sensor)
12
Usage: - get advert.interval - set advert.interval <minutes>
get advert.interval
set advert.interval <minutes>
Parameters: - minutes: Interval in minutes rounded down to the nearest multiple of 2 (61 becomes 60) (60-240)
minutes
Usage: - get flood.max - set flood.max <value>
get flood.max
set flood.max <value>
Parameters: - value: Maximum flood hop count (0-64)
Default: 64
64
Usage: - setperm <pubkey> <permissions>
setperm <pubkey> <permissions>
Parameters: - pubkey: Companion public key - permissions: - 0: Guest - 1: Read-only - 2: Read-write - 3: Admin
pubkey
permissions
Note: Removes the entry when permissions is omitted
Usage: - get acl
get acl
Usage: - get allow.read.only - set allow.read.only <state>
get allow.read.only
set allow.read.only <state>
Parameters: - state: on (enable) or off (disable)
Usage: - region load - region load <name> [flood_flag]
region load
region load <name> [flood_flag]
Parameters: - name: A name of a region. * represents the wildcard region
*
Note: flood_flag: Optional F to allow flooding
flood_flag
F
Note: Indentation creates parent-child relationships (max 8 levels)
Note: region load with an empty name will not work remotely (it's interactive)
Usage: - region save
region save
Usage: - region allowf <name>
region allowf <name>
Parameters: - name: Region name (or * for wildcard)
Note: Setting on wildcard * allows packets without region transport codes
Usage: - region denyf <name>
region denyf <name>
Note: Setting on wildcard * drops packets without region transport codes
Usage: - region get <name>
region get <name>
Usage: - region home - region home <name>
region home
region home <name>
Parameters: - name: Region name
Usage: - region put <name> [parent_name]
region put <name> [parent_name]
Parameters: - name: Region name - parent_name: Parent region name (optional, defaults to wildcard)
parent_name
Usage: - region remove <name>
region remove <name>
Note: Must remove all child regions before the region can be removed
Usage: - region list <filter>
region list <filter>
Parameters: - filter: allowed|denied
filter
allowed
denied
Usage: - region
region
Serial Only: For firmware older than 1.12.0
Example 1: Using F Flag with Named Public Region
region load\n#Europe F\n<blank line to end region load>\nregion save\n
Explanation: - Creates a region named #Europe with flooding enabled - Packets from this region will be flooded to other nodes
#Europe
Example 2: Using Wildcard with F Flag
region load \n* F\n<blank line to end region load>\nregion save\n
Explanation: - Creates a wildcard region * with flooding enabled - Enables flooding for all regions automatically - Applies only to packets without transport codes
Example 3: Using Wildcard Without F Flag
region load \n*\n<blank line to end region load>\nregion save\n
Explanation: - Creates a wildcard region * without flooding - This region exists but doesn't affect packet distribution - Used as a default/empty region
Example 4: Nested Public Region with F Flag
region load \n#Europe F\n #UK\n #London\n #Manchester\n #France\n #Paris\n #Lyon\n<blank line to end region load>\nregion save\n
Explanation: - Creates #Europe region with flooding enabled - Adds nested child regions (#UK, #France) - All nested regions inherit the flooding flag from parent
#UK
#France
Example 5: Wildcard with Nested Public Regions
region load \n* F\n #NorthAmerica\n #USA\n #NewYork\n #California\n #Canada\n #Ontario\n #Quebec\n<blank line to end region load>\nregion save\n
Explanation: - Creates wildcard region * with flooding enabled - Adds nested #NorthAmerica hierarchy - Enables flooding for all child regions automatically - Useful for global networks with specific regional rules
#NorthAmerica
Usage: - gps - gps <state>
gps
gps <state>
Note: Output format: {status}, {fix}, {sat count} (when enabled)
{status}, {fix}, {sat count}
Usage: - gps sync
gps sync
Usage: - gps setloc
gps setloc
Usage: - gps advert - gps advert <policy>
gps advert
gps advert <policy>
Parameters: - policy: none|share|prefs - none: don't include location in adverts - share: share gps location (from SensorManager) - prefs: location stored in node's lat and lon settings
policy
none
share
prefs
Default: prefs
Usage: sensor list [start]
sensor list [start]
Parameters: - start: Optional starting index (defaults to 0)
start
Note: Output format: <var_name>=<value>\\n
<var_name>=<value>\\n
Usage: - sensor get <key> - sensor set <key> <value>
sensor get <key>
sensor set <key> <value>
Parameters: - key: Sensor setting name - value: The value to set the sensor to
key
Usage: get bridge.type
get bridge.type
Usage: - get bridge.enabled - set bridge.enabled <state>
get bridge.enabled
set bridge.enabled <state>
Usage: - get bridge.delay - set bridge.delay <ms>
get bridge.delay
set bridge.delay <ms>
Parameters: - ms: Delay in milliseconds (0-10000)
ms
Default: 500
500
Usage: - get bridge.source - set bridge.source <source>
get bridge.source
set bridge.source <source>
Parameters: - source: - logRx: bridges received packets - logTx: bridges transmitted packets
source
logRx
logTx
Default: logTx
Usage: - get bridge.baud - set bridge.baud <rate>
get bridge.baud
set bridge.baud <rate>
Parameters: - rate: Baud rate (9600, 19200, 38400, 57600, or 115200)
rate
9600
19200
38400
57600
115200
Default: 115200
Usage: - get bridge.channel - set bridge.channel <channel>
get bridge.channel
set bridge.channel <channel>
Parameters: - channel: Channel number (1-14)
channel
Usage: - get bridge.secret - set bridge.secret <secret>
get bridge.secret
set bridge.secret <secret>
Parameters: - secret: ESP-NOW bridge secret, up to 15 characters
secret
Usage: get bootloader.ver
get bootloader.ver
Usage: get pwrmgt.support
get pwrmgt.support
Usage: get pwrmgt.source
get pwrmgt.source
Note: Returns an error on boards without power management support.
Usage: get pwrmgt.bootreason
get pwrmgt.bootreason
Usage: get pwrmgt.bootmv
get pwrmgt.bootmv
NOTE: This document is still in development. Some information may be inaccurate.
This document provides a comprehensive guide for communicating with MeshCore devices over Bluetooth Low Energy (BLE).
It is platform-agnostic and can be used for Android, iOS, Python, JavaScript, or any other platform that supports BLE.
Please see the following repos for existing MeshCore Companion Protocol libraries.
All secrets, hashes, and cryptographic values shown in this guide are example values only.
MeshCore Companion devices expose a BLE service with the following UUIDs:
6E400001-B5A3-F393-E0A9-E50E24DCCA9E
6E400002-B5A3-F393-E0A9-E50E24DCCA9E
6E400003-B5A3-F393-E0A9-E50E24DCCA9E
Scan for Devices
Connect to GATT
Discover Services and Characteristics
Enable Notifications
Send Initial Commands
CMD_APP_START
CMD_DEVICE_QEURY
CMD_SET_DEVICE_TIME
CMD_GET_CONTACTS
CMD_GET_CHANNEL
CMD_SYNC_NEXT_MESSAGE
PUSH_CODE_MSG_WAITING
PUSH_CODE_ADVERT
Note: MeshCore devices may disconnect after periods of inactivity. Implement auto-reconnect logic with exponential backoff.
When writing commands to the RX characteristic, specify the write type:
Platform-specific:
BluetoothGattCharacteristic.WRITE_TYPE_DEFAULT
WRITE_TYPE_NO_RESPONSE
CBCharacteristicWriteType.withResponse
.withoutResponse
write_gatt_char()
response=True
False
Recommendation: Use write with response for reliability.
The default BLE MTU is 23 bytes (20 bytes payload). For larger commands like SET_CHANNEL (50 bytes), you may need to:
SET_CHANNEL
gatt.requestMtu(512)
peripheral.maximumWriteValueLength(for:)
Critical: Commands must be sent in the correct sequence:
After Connection:
Command-Response Matching:
RESP_CODE_CHANNEL_INFO
For reliable operation, implement a command queue.
Queue Structure:
Error Handling:
The MeshCore protocol uses a binary format with the following structure:
Most packets follow this format:
[Packet Type (1 byte)] [Data (variable length)]\n
The first byte indicates the packet type (see Response Parsing).
Purpose: Initialize communication with the device. Must be sent first after connection.
Command Format:
Byte 0: 0x01\nBytes 1-7: Reserved (currently ignored by firmware)\nBytes 8+: Application name (UTF-8, optional)\n
Example (hex):
01 00 00 00 00 00 00 00 6d 63 63 6c 69\n
Response: PACKET_SELF_INFO (0x05)
PACKET_SELF_INFO
Purpose: Query device information.
Byte 0: 0x16\nByte 1: 0x03\n
16 03\n
Response: PACKET_DEVICE_INFO (0x0D) with device information
PACKET_DEVICE_INFO
Purpose: Retrieve information about a specific channel.
Byte 0: 0x1F\nByte 1: Channel Index (0-7)\n
Example (get channel 1):
1F 01\n
Response: PACKET_CHANNEL_INFO (0x12) with channel details
PACKET_CHANNEL_INFO
Purpose: Create or update a channel on the device.
Byte 0: 0x20\nByte 1: Channel Index (0-7)\nBytes 2-33: Channel Name (32 bytes, UTF-8, null-padded)\nBytes 34-49: Secret (16 bytes)\n
Total Length: 50 bytes
Channel Index: - Index 0: Reserved for public channels (no secret) - Indices 1-7: Available for private channels
Channel Name: - UTF-8 encoded - Maximum 32 bytes - Padded with null bytes (0x00) if shorter
Secret Field (16 bytes): - For private channels: 16-byte secret - For public channels: All zeros (0x00)
Example (create channel \"YourChannelName\" at index 1 with secret):
20 01 53 4D 53 00 00 ... (name padded to 32 bytes)\n [16 bytes of secret]\n
Note: The 32-byte secret variant is unsupported and returns PACKET_ERROR.
PACKET_ERROR
Response: PACKET_OK (0x00) on success, PACKET_ERROR (0x01) on failure
PACKET_OK
Purpose: Send a text message to a channel.
Byte 0: 0x03\nByte 1: 0x00\nByte 2: Channel Index (0-7)\nBytes 3-6: Timestamp (32-bit little-endian Unix timestamp, seconds)\nBytes 7+: Message Text (UTF-8, variable length)\n
Timestamp: Unix timestamp in seconds (32-bit unsigned integer, little-endian)
Example (send \"Hello\" to channel 1 at timestamp 1234567890):
03 00 01 D2 02 96 49 48 65 6C 6C 6F\n
Response: PACKET_MSG_SENT (0x06) on success
PACKET_MSG_SENT
Purpose: Request the next queued message from the device.
Byte 0: 0x0A\n
0A\n
Response: - PACKET_CHANNEL_MSG_RECV (0x08) or PACKET_CHANNEL_MSG_RECV_V3 (0x11) for channel messages - PACKET_CONTACT_MSG_RECV (0x07) or PACKET_CONTACT_MSG_RECV_V3 (0x10) for contact messages - PACKET_NO_MORE_MSGS (0x0A) if no messages available
PACKET_CHANNEL_MSG_RECV
PACKET_CHANNEL_MSG_RECV_V3
PACKET_CONTACT_MSG_RECV
PACKET_CONTACT_MSG_RECV_V3
PACKET_NO_MORE_MSGS
Note: Poll this command periodically to retrieve queued messages. The device may also send PACKET_MESSAGES_WAITING (0x83) as a notification when messages are available.
PACKET_MESSAGES_WAITING
Purpose: Query device battery voltage and storage usage.
Byte 0: 0x14\n
14\n
Response: PACKET_BATTERY (0x0C) with battery millivolts and storage information
PACKET_BATTERY
8b3387e9c5cdea6ac9e5edbaa115cd72
sha256(\"#test\")
#test
9cd8fcf22a47333b591d96a2b848b73f
CMD_SET_CHANNEL
Messages are received via the TX characteristic (notifications). The device sends:
PACKET_CHANNEL_MSG_RECV_V3 (0x11) - Version 3 with SNR
Contact Messages:
PACKET_CONTACT_MSG_RECV_V3 (0x10) - Version 3 with SNR
Notifications:
Standard Format (PACKET_CONTACT_MSG_RECV, 0x07):
Byte 0: 0x07 (packet type)\nBytes 1-6: Public Key Prefix (6 bytes, hex)\nByte 7: Path Length\nByte 8: Text Type\nBytes 9-12: Timestamp (32-bit little-endian)\nBytes 13-16: Signature (4 bytes, only if txt_type == 2)\nBytes 17+: Message Text (UTF-8)\n
V3 Format (PACKET_CONTACT_MSG_RECV_V3, 0x10):
Byte 0: 0x10 (packet type)\nByte 1: SNR (signed byte, multiplied by 4)\nBytes 2-3: Reserved\nBytes 4-9: Public Key Prefix (6 bytes, hex)\nByte 10: Path Length\nByte 11: Text Type\nBytes 12-15: Timestamp (32-bit little-endian)\nBytes 16-19: Signature (4 bytes, only if txt_type == 2)\nBytes 20+: Message Text (UTF-8)\n
Parsing Pseudocode:
def parse_contact_message(data):\n packet_type = data[0]\n offset = 1\n\n # Check for V3 format\n if packet_type == 0x10: # V3\n snr_byte = data[offset]\n snr = ((snr_byte if snr_byte < 128 else snr_byte - 256) / 4.0)\n offset += 3 # Skip SNR + reserved\n\n pubkey_prefix = data[offset:offset+6].hex()\n offset += 6\n\n path_len = data[offset]\n txt_type = data[offset + 1]\n offset += 2\n\n timestamp = int.from_bytes(data[offset:offset+4], 'little')\n offset += 4\n\n # If txt_type == 2, skip 4-byte signature\n if txt_type == 2:\n offset += 4\n\n message = data[offset:].decode('utf-8')\n\n return {\n 'pubkey_prefix': pubkey_prefix,\n 'path_len': path_len,\n 'txt_type': txt_type,\n 'timestamp': timestamp,\n 'message': message,\n 'snr': snr if packet_type == 0x10 else None\n }\n
Standard Format (PACKET_CHANNEL_MSG_RECV, 0x08):
Byte 0: 0x08 (packet type)\nByte 1: Channel Index (0-7)\nByte 2: Path Length\nByte 3: Text Type\nBytes 4-7: Timestamp (32-bit little-endian)\nBytes 8+: Message Text (UTF-8)\n
V3 Format (PACKET_CHANNEL_MSG_RECV_V3, 0x11):
Byte 0: 0x11 (packet type)\nByte 1: SNR (signed byte, multiplied by 4)\nBytes 2-3: Reserved\nByte 4: Channel Index (0-7)\nByte 5: Path Length\nByte 6: Text Type\nBytes 7-10: Timestamp (32-bit little-endian)\nBytes 11+: Message Text (UTF-8)\n
def parse_channel_message(data):\n packet_type = data[0]\n offset = 1\n\n # Check for V3 format\n if packet_type == 0x11: # V3\n snr_byte = data[offset]\n snr = ((snr_byte if snr_byte < 128 else snr_byte - 256) / 4.0)\n offset += 3 # Skip SNR + reserved\n\n channel_idx = data[offset]\n path_len = data[offset + 1]\n txt_type = data[offset + 2]\n timestamp = int.from_bytes(data[offset+3:offset+7], 'little')\n message = data[offset+7:].decode('utf-8')\n\n return {\n 'channel_idx': channel_idx,\n 'timestamp': timestamp,\n 'message': message,\n 'snr': snr if packet_type == 0x11 else None\n }\n
Use the SEND_CHANNEL_MESSAGE command (see Commands).
SEND_CHANNEL_MESSAGE
Important: - Messages are limited to 133 characters per MeshCore specification - Long messages should be split into chunks - Include a chunk indicator (e.g., \"[1/3] message text\")
PACKET_OK (0x00):
Byte 0: 0x00\nBytes 1-4: Optional value (32-bit little-endian integer)\n
PACKET_ERROR (0x01):
Byte 0: 0x01\nByte 1: Error code (optional)\n
PACKET_CHANNEL_INFO (0x12):
Byte 0: 0x12\nByte 1: Channel Index\nBytes 2-33: Channel Name (32 bytes, null-terminated)\nBytes 34-49: Secret (16 bytes)\n
Note: The device returns the 16-byte channel secret in this response.
PACKET_DEVICE_INFO (0x0D):
Byte 0: 0x0D\nByte 1: Firmware Version (uint8)\nBytes 2+: Variable length based on firmware version\n\nFor firmware version >= 3:\nByte 2: Max Contacts Raw (uint8, actual = value * 2)\nByte 3: Max Channels (uint8)\nBytes 4-7: BLE PIN (32-bit little-endian)\nBytes 8-19: Firmware Build (12 bytes, UTF-8, null-padded)\nBytes 20-59: Model (40 bytes, UTF-8, null-padded)\nBytes 60-79: Version (20 bytes, UTF-8, null-padded)\nByte 80: Client repeat enabled/preferred (firmware v9+)\nByte 81: Path hash mode (firmware v10+)\n
def parse_device_info(data):\n if len(data) < 2:\n return None\n\n fw_ver = data[1]\n info = {'fw_ver': fw_ver}\n\n if fw_ver >= 3 and len(data) >= 80:\n info['max_contacts'] = data[2] * 2\n info['max_channels'] = data[3]\n info['ble_pin'] = int.from_bytes(data[4:8], 'little')\n info['fw_build'] = data[8:20].decode('utf-8').rstrip('\\x00').strip()\n info['model'] = data[20:60].decode('utf-8').rstrip('\\x00').strip()\n info['ver'] = data[60:80].decode('utf-8').rstrip('\\x00').strip()\n\n return info\n
PACKET_BATTERY (0x0C):
Byte 0: 0x0C\nBytes 1-2: Battery Voltage (16-bit little-endian, millivolts)\nBytes 3-6: Used Storage (32-bit little-endian, KB)\nBytes 7-10: Total Storage (32-bit little-endian, KB)\n
def parse_battery(data):\n if len(data) < 3:\n return None\n\n mv = int.from_bytes(data[1:3], 'little')\n info = {'battery_mv': mv}\n\n if len(data) >= 11:\n info['used_kb'] = int.from_bytes(data[3:7], 'little')\n info['total_kb'] = int.from_bytes(data[7:11], 'little')\n\n return info\n
PACKET_SELF_INFO (0x05):
Byte 0: 0x05\nByte 1: Advertisement Type\nByte 2: TX Power\nByte 3: Max TX Power\nBytes 4-35: Public Key (32 bytes, hex)\nBytes 36-39: Advertisement Latitude (32-bit little-endian, divided by 1e6)\nBytes 40-43: Advertisement Longitude (32-bit little-endian, divided by 1e6)\nByte 44: Multi ACKs\nByte 45: Advertisement Location Policy\nByte 46: Telemetry Mode (bitfield)\nByte 47: Manual Add Contacts (bool)\nBytes 48-51: Radio Frequency (32-bit little-endian, divided by 1000.0)\nBytes 52-55: Radio Bandwidth (32-bit little-endian, divided by 1000.0)\nByte 56: Radio Spreading Factor\nByte 57: Radio Coding Rate\nBytes 58+: Device Name (UTF-8, variable length, no null terminator required)\n
def parse_self_info(data):\n if len(data) < 36:\n return None\n\n offset = 1\n info = {\n 'adv_type': data[offset],\n 'tx_power': data[offset + 1],\n 'max_tx_power': data[offset + 2],\n 'public_key': data[offset + 3:offset + 35].hex()\n }\n offset += 35\n\n lat = int.from_bytes(data[offset:offset+4], 'little') / 1e6\n lon = int.from_bytes(data[offset+4:offset+8], 'little') / 1e6\n info['adv_lat'] = lat\n info['adv_lon'] = lon\n offset += 8\n\n info['multi_acks'] = data[offset]\n info['adv_loc_policy'] = data[offset + 1]\n telemetry_mode = data[offset + 2]\n info['telemetry_mode_env'] = (telemetry_mode >> 4) & 0b11\n info['telemetry_mode_loc'] = (telemetry_mode >> 2) & 0b11\n info['telemetry_mode_base'] = telemetry_mode & 0b11\n info['manual_add_contacts'] = data[offset + 3] > 0\n offset += 4\n\n freq = int.from_bytes(data[offset:offset+4], 'little') / 1000.0\n bw = int.from_bytes(data[offset+4:offset+8], 'little') / 1000.0\n info['radio_freq'] = freq\n info['radio_bw'] = bw\n info['radio_sf'] = data[offset + 8]\n info['radio_cr'] = data[offset + 9]\n offset += 10\n\n if offset < len(data):\n name_bytes = data[offset:]\n info['name'] = name_bytes.decode('utf-8').rstrip('\\x00').strip()\n\n return info\n
PACKET_MSG_SENT (0x06):
Byte 0: 0x06\nByte 1: Route Flag (0 = direct, 1 = flood)\nBytes 2-5: Tag / Expected ACK (4 bytes, little-endian)\nBytes 6-9: Suggested Timeout (32-bit little-endian, milliseconds)\n
PACKET_ACK (0x82):
Byte 0: 0x82\nBytes 1-6: ACK Code (6 bytes, hex)\n
PACKET_ERROR (0x01) may include an error code in byte 1:
Note: Error codes may vary by firmware version. Always check byte 1 of PACKET_ERROR response.
BLE implementations enqueue and deliver one protocol frame per BLE write/notification at the firmware layer.
Use command queue to prevent concurrent commands
Asynchronous Messages:
GET_MESSAGE
Validate frame length before decoding
Response Matching:
Match responses to commands by expected packet type:
APP_START
DEVICE_QUERY
GET_CHANNEL
GET_BATTERY
Timeout Handling:
Consider longer timeout for channel operations
Error Recovery:
# 1. Scan for MeshCore device\ndevice = scan_for_device(\"MeshCore\")\n\n# 2. Connect to BLE GATT\ngatt = connect_to_device(device)\n\n# 3. Discover services and characteristics\nservice = discover_service(gatt, \"6E400001-B5A3-F393-E0A9-E50E24DCCA9E\")\nrx_char = discover_characteristic(service, \"6E400002-B5A3-F393-E0A9-E50E24DCCA9E\")\ntx_char = discover_characteristic(service, \"6E400003-B5A3-F393-E0A9-E50E24DCCA9E\")\n\n# 4. Enable notifications on TX characteristic\nenable_notifications(tx_char, on_notification_received)\n\n# 5. Send AppStart command\nsend_command(rx_char, build_app_start())\nwait_for_response(PACKET_SELF_INFO)\n
# 1. Generate 16-byte secret\nsecret_16_bytes = generate_secret(16) # Use CSPRNG\nsecret_hex = secret_16_bytes.hex()\n\n# 2. Build SET_CHANNEL command\nchannel_name = \"YourChannelName\"\nchannel_index = 1 # Use 1-7 for private channels\ncommand = build_set_channel(channel_index, channel_name, secret_16_bytes)\n\n# 3. Send command\nsend_command(rx_char, command)\nresponse = wait_for_response(PACKET_OK)\n\n# 4. Store secret locally\nstore_channel_secret(channel_index, secret_hex)\n
# 1. Build channel message command\nchannel_index = 1\nmessage = \"Hello, MeshCore!\"\ntimestamp = int(time.time())\ncommand = build_channel_message(channel_index, message, timestamp)\n\n# 2. Send command\nsend_command(rx_char, command)\nresponse = wait_for_response(PACKET_MSG_SENT)\n
def on_notification_received(data):\n packet_type = data[0]\n\n if packet_type == PACKET_CHANNEL_MSG_RECV or packet_type == PACKET_CHANNEL_MSG_RECV_V3:\n message = parse_channel_message(data)\n handle_channel_message(message)\n elif packet_type == PACKET_MESSAGES_WAITING:\n # Poll for messages\n send_command(rx_char, build_get_message())\n
Store last connected device address for quick reconnection
Secret Management:
Never log or transmit secrets in plain text
Message Handling:
Implement message deduplication to avoid display the same message twice
Channel Management:
RESP_CODE_ERR
This document explains how to build and view the MeshCore documentation locally.
pip install mkdocs\npip install mkdocs-material\n
mkdocs serve
mkdocs build
MeshCore is free and open source: * MeshCore is the routing and firmware etc, available on GitHub under MIT license * There are clients made by the community, such as the web clients, these are free to use, and some are open source too * The cross platform mobile app developed by Liam Cottle for Android/iOS/PC etc is free to download and use * The T-Deck firmware is developed by Scott at Ripple Radios, the creator of MeshCore, is also free to flash on your devices and use
Some more advanced, but optional features are available on T-Deck if you register your device for a key to unlock. On the MeshCore smartphone clients for Android and iOS/iPadOS, you can unlock the wait timer for repeater and room server remote management over RF feature.
These features are completely optional and aren't needed for the core messaging experience. They're like super bonus features and to help the developers continue to work on these amazing features, they may charge a small fee for an unlock code to utilise the advanced features.
Anyone is able to build anything they like on top of MeshCore without paying anything.
Companion radios are for connecting to the Android app or web app as a messenger client. There are two different companion radio firmware versions:
BLE Companion BLE Companion firmware runs on a supported LoRa device and connects to a smart device running the Android or iOS MeshCore client over BLE https://meshcore.co.uk/apps.html
USB Serial Companion USB Serial Companion firmware runs on a supported LoRa device and connects to a smart device or a computer over USB Serial running the MeshCore web client https://meshcore.liamcottle.net/#/ https://client.meshcore.co.uk/tabs/devices
Repeaters are used to extend the range of a MeshCore network. Repeater firmware runs on the same devices that run client firmware. A repeater's job is to forward MeshCore packets to the destination device. It does not forward or retransmit every packet it receives, unlike other LoRa mesh systems.
A repeater can be remotely administered using a T-Deck running the MeshCore firmware with remote administration features unlocked, or from a BLE Companion client connected to a smartphone running the MeshCore app.
A room server is a simple BBS server for sharing posts. T-Deck devices running MeshCore firmware or a BLE Companion client connected to a smartphone running the MeshCore app can connect to a room server.
Room servers store message history on them and push the stored messages to users. Room servers allow roaming users to come back later and retrieve message history. With channels, messages are either received when it's sent, or not received and missed if the channel user is out of range. Room servers are different and more like email servers where you can come back later and get your emails from your mail server.
A room server can be remotely administered using a T-Deck running the MeshCore firmware with remote administration features unlocked, or from a BLE Companion client connected to a smartphone running the MeshCore app.
When a client logs into a room server, the client will receive the previously 32 unseen messages.
Although room server can also repeat with the command line command set repeat on, it is not recommended nor encouraged. A room server with repeat set to on lacks the full set of repeater and remote administration features that are only available in the repeater firmware.
set repeat on
The recommendation is to run repeater and room server on separate devices for the best experience.
A: If you have one supported device, flash the BLE Companion firmware and use your device as a client. You can connect to the device using the Android or iOS client via Bluetooth. You can start communicating with other MeshCore users near you.
If you have two supported devices, and there are not many MeshCore users near you, flash both to BLE Companion firmware so you can use your devices to communicate with your near-by friends and family.
If you have two supported devices, and there are other MeshCore users nearby, you can flash one of your devices with BLE Companion firmware and flash another supported device to repeater firmware. Place the repeater high above ground to extend your MeshCore network's reach.
After you flashed the latest firmware onto your repeater device, keep the device connected to your computer via USB serial, use the console feature on the web flasher and set the frequency for your region or country, so your client can remote administer the repeater or room server over RF:
set freq {frequency}
The repeater and room server CLI reference is here: https://github.com/meshcore-dev/MeshCore/wiki/Repeater-&-Room-Server-CLI-Reference
If you have more supported devices, you can use your additional devices with the room server firmware.
A: All radio firmware versions (e.g. for Heltec V3, RAK, T-1000E, etc) are free and open source developed by Scott at Ripple Radios.
The native Android and iOS client uses the freemium model and is developed by Liam Cottle, developer of meshtastic map at meshtastic.liamcottle.net on GitHub and reticulum-meshchat on github.
The T-Deck firmware is free to download and most features are available without cost. To support the firmware developer, you can pay for a registration key to unlock your T-Deck for deeper map zoom and remote server administration over RF using the T-Deck. You do not need to pay for the registration to use your T-Deck for direct messaging and connecting to repeaters and room servers.
A: It supports the 868MHz range in the UK/EU and the 915MHz range in New Zealand, Australia, and the USA. Countries and regions in these two frequency ranges are also supported.
Use the smartphone client or the repeater setup feature on there web flasher to set your radios' RF settings by choosing the preset for your regions.
Recently, as of October 2025, many regions have moved to the \"narrow\" setting, aka using BW62.5 and a lower SF number (instead of the original SF11). For example, USA/Canada (Recommended) preset is 910.525MHz, SF7, BW62.5, CR5.
After extensive testing, many regions have switched or about to switch over to BW62.5 and SF7, 8, or 9. Narrower bandwidth setting and lower SF setting allow MeshCore's radio signals to fit between interference in the ISM band, provide for a lower noise floor, better SNR, and faster transmissions.
If you have consensus from your community in your region to update your region's preset recommendation, please post your update request on the #meshcore-app channel on the MeshCore Discord server to let Liam Cottle know.
A: Advert means to advertise yourself on the network. In Reticulum terms it would be to announce. In Meshtastic terms it would be the node sending its node info.
MeshCore allows you to manually broadcast your name, position and public encryption key, which is also signed to prevent spoofing. When you click the advert button, it broadcasts that data over LoRa. MeshCore calls that an Advert. There's two ways to advert, \"zero hop\" and \"flood\".
MeshCore clients only advertise themselves when the user initiates it. A repeater sends a flood advert once every 12 hours by default. This interval can be configured using the following command:
set flood.advert.interval {hours}
The separate set advert.interval {minutes} command controls the local zero-hop advert timer.
set advert.interval {minutes}
A: Internally the firmware has maximum limit of 64 hops. In real world settings it will be difficult to get close to the limit due to the environments and timing as packets travel further and further. We want to hear how far your MeshCore conversations go.
A T-Deck running unlocked/registered MeshCore firmware. Remote server administration is enabled through registering your T-Deck with Ripple Radios. It is one of the ways to support MeshCore development. You can register your T-Deck at:
https://buymeacoffee.com/ripplebiz/e/249834
A: While not required, with location set for a repeater it will show up on the MeshCore map in the future. Set location with the following command:
set lat <GPS Lat>
set lon <GPS Lon>
You can get the latitude and longitude from Google Maps by right-clicking the location you are at on the map.
A: The default admin password to a repeater and room server is password. Use the following command to change the admin password:
password {new-password}
A: The default guest password to a room server is hello. Use the following command to change the guest password:
hello
set guest.password {guest-password}
A: You can issue these commands to get or set a repeater's private key using a USB serial connection.
get prv.key to print a repeater's private key on the serial console set prv.key <hex> to set a repeater's private key on the serial console
The <number> unit is in seconds and is incremented by 4. set agc.reset.interval 4 works well to cure deafness.
<number>
set agc.reset.interval 4
A: Yes, it is available on https://buymeacoffee.com/ripplebiz/ultra-v7-7-guide-meshcore-users
A: 1. Device off 2. Connect USB cable to device 3. Hold down trackball (keep holding) 4. Turn on device 5. Hear USB connection sound 6. Release trackball 7. T-Deck in DFU mode now 8. At this point you can begin flashing using https://flasher.meshcore.co.uk/
GPS on T-Deck is always enabled. You can skip the \"GPS clock sync\" and the T-Deck will continue to try to get a GPS lock. You can go to the GPS Info screen; you should see the Sentences: counter increasing if the baud rate is correct.
Source
A: The OG (non-Plus) T-Deck doesn't come with a GPS. If you added a GPS to your OG T-Deck, please refer to the manual of your GPS to see what baud rate it requires. Alternatively, you can try to set the baud rate from 9600, 19200, etc., and up to 115200 to see which one works.
A: Users have had no issues using 16GB or 32GB SD cards. Format the SD card to FAT32.
A: T-Deck uses the same key the smartphone apps use but in base64 izOH6cXN6mrJ5e26oRXNcg==
izOH6cXN6mrJ5e26oRXNcg==
There is no = key on the T-Deck's hardware keyboard. You can use the on-screen software keyboard to enter =. Tap the text box to enable the on-screen software keyboard. The third character is the capital letter O (Oh), not zero 0
=
O
The smartphone app key is in hex: 8b3387e9c5cdea6ac9e5edbaa115cd72
A: You need map tiles. You can get pre-downloaded map tiles here (a good way to support development): - https://buymeacoffee.com/ripplebiz/e/342543 (Europe) - https://buymeacoffee.com/ripplebiz/e/342542 (US)
Another way to download map tiles is to use this Python script to get the tiles in the areas you want: https://github.com/fistulareffigy/MTD-Script
There is also a modified script that adds additional error handling and parallel downloads: https://discord.com/channels/826570251612323860/1330643963501351004/1338775811548905572
UK map tiles are available separately from Andy Kirby on his discord server: https://discord.com/channels/826570251612323860/1330643963501351004/1331346597367386224
Once you have the tiles downloaded, copy the \\tiles folder to the root of your T-Deck's SD card.
\\tiles
A: You can download, install, and use the T-Deck firmware for free, but it has some features (map zoom, server administration) that are enabled if you purchase an unlock code for \\$10 per T-Deck device. Unlock page: https://buymeacoffee.com/ripplebiz/e/249834
**A: ** Space is tight on T-Deck's screen, so the information is a bit cryptic. The format is : {hops} l:{packet-length}({payload-len}) t:{packet-type} snr:{n} rssi:{n}
{hops} l:{packet-length}({payload-len}) t:{packet-type} snr:{n} rssi:{n}
See here for packet-type: https://github.com/meshcore-dev/MeshCore/blob/main/src/Packet.h#L19
#define PAYLOAD_TYPE_REQ 0x00 // request (prefixed with dest/src hashes, MAC) (enc data: timestamp, blob)\n#define PAYLOAD_TYPE_RESPONSE 0x01 // response to REQ or ANON_REQ (prefixed with dest/src hashes, MAC) (enc data: timestamp, blob)\n#define PAYLOAD_TYPE_TXT_MSG 0x02 // a plain text message (prefixed with dest/src hashes, MAC) (enc data: timestamp, text)\n#define PAYLOAD_TYPE_ACK 0x03 // a simple ack #define PAYLOAD_TYPE_ADVERT 0x04 // a node advertising its Identity\n#define PAYLOAD_TYPE_GRP_TXT 0x05 // an (unverified) group text message (prefixed with channel hash, MAC) (enc data: timestamp, \"name: msg\")\n#define PAYLOAD_TYPE_GRP_DATA 0x06 // an (unverified) group datagram (prefixed with channel hash, MAC) (enc data: timestamp, blob)\n#define PAYLOAD_TYPE_ANON_REQ 0x07 // generic request (prefixed with dest_hash, ephemeral pub_key, MAC) (enc data: ...)\n#define PAYLOAD_TYPE_PATH 0x08 // returned path (prefixed with dest/src hashes, MAC) (enc data: path, extra)\n
A: You can customise the sounds on the T-Deck, by placing .mp3 files onto the root dir of the SD card. The files are:
.mp3
root
startup.mp3
error.mp3
alert.mp3
new-advert.mp3
existing-advert.mp3
A: 'Import from Clipboard' is for importing a contact via a file named 'clipboard.txt' on the SD card. The opposite, is in the Identity screen, the 'Card to Clipboard' menu, which writes to 'clipboard.txt' so you can share yourself (call these 'biz cards', that start with \"meshcore://...\")
A: To capture a screenshot on a T-Deck, long press the top-left corner of the screen. The screenshot is saved to the microSD card, if one is inserted into the device.
BW is bandwidth - width of frequency spectrum that is used for transmission
SF is spreading factor - how much should the communication spread in time
CR is coding rate - from: https://www.thethingsnetwork.org/docs/lorawan/fec-and-code-rate/
TL;DR: default CR to 5 for good stable links. If it is not a solid link and is intermittent, change to CR to 7 or 8.
Forward Error Correction is a process of adding redundant bits to the data to be transmitted. During the transmission, data may get corrupted by interference (changes from 0 to 1 / 1 to 0). These error correction bits are used at the receivers for restoring corrupted bits.
The Code Rate of a forward error correction expresses the proportion of bits in a data stream that actually carry useful information.
There are 4 code rates used in LoRaWAN:
4/5 4/6 5/7 4/8
For example, if the code rate is 5/7, for every 5 bits of useful information, the coder generates a total of 7 bits of data, of which 2 bits are redundant.
Making the bandwidth 2x wider (from BW125 to BW250) allows you to send 2x more bytes in the same time. Making the spreading factor 1 step lower (from SF10 to SF9) allows you to send 2x more bytes in the same time.
Lowering the spreading factor makes it more difficult for the gateway to receive a transmission, as it will be more sensitive to noise. You could compare this to two people taking in a noisy place (a bar for example). If you\u2019re far from each other, you have to talk slow (SF10), but if you\u2019re close, you can talk faster (SF7)
So, it's balancing act between speed of the transmission and resistance to noise. things network is mainly focused on LoRaWAN, but the LoRa low-level stuff still checks out for any LoRa project
A: No, MeshCore clients do not repeat. This is the core of MeshCore's messaging-first design. This is to avoid devices flooding the air ware and create endless collisions, so messages sent aren't received. In MeshCore, only repeaters and room server with set repeat on repeat.
A: If you used to reach a node through a repeater and the repeater is no longer reachable, the client will send the message using the existing (but now broken) known path, the message will fail after 3 retries, and the app will reset the path and send the message as flood on the last retry by default. This can be turned off in settings. If the destination is reachable directly or through another repeater, the new path will be used going forward. Or you can set the path manually if you know a specific repeater to use to reach that destination.
In the case if users are moving around frequently, and the paths are breaking, they just see the phone client retries and revert to flood to attempt to re-establish a path.
Routes are stored in sender's contact list. When you send a message the first time, the message first gets to your destination by flood routing. When your destination node gets the message, it will send back a delivery report to the sender with all repeaters that the original message went through. This delivery report is flood-routed back to you the sender and is a basis for future direct path. When you send the next message, the path will get embedded into the packet and be evaluated by repeaters. If the hop and address of the repeater matches, it will retransmit the message, otherwise it will not retransmit, hence minimizing utilization.
A: Yes, group channels are A to B, so there is no defined path. They have to flood. Repeaters can however deny flood traffic up to some hop limit, with the set flood.max CLI command. Administrators of repeaters get to set the rules of their repeaters.
set flood.max
A: The smartphone app key is in hex: 8b3387e9c5cdea6ac9e5edbaa115cd72
T-Deck uses the same key but in base64 izOH6cXN6mrJ5e26oRXNcg== The third character is the capital letter 'O', not zero 0 Source
A: Most of the firmware is freely available. Everything is open source except the T-Deck firmware and Liam's native mobile apps. - Firmware repo: https://github.com/meshcore-dev/MeshCore
A: Provide your honest feedback on GitHub and on MeshCore Discord server. Spread the word of MeshCore to your friends and communities; help them get started with MeshCore. Support Scott's MeshCore development at https://buymeacoffee.com/ripplebiz.
Support Liam Cottle's smartphone client development by unlocking the server administration wait gate with in-app purchase
Support Rastislav Vysoky (recrof)'s flasher web site and the map web site development through PayPal or Revolut
A: See instructions here: https://discord.com/channels/826570251612323860/1330643963501351004/1341826372120608769
Build instructions for MeshCore:
For Windows, first install WSL and Python+pip via: https://plainenglish.io/blog/setting-up-python-on-windows-subsystem-for-linux-wsl-26510f1b2d80
(Linux, Windows+WSL) In the terminal/shell:
sudo apt update\nsudo apt install libpython3-dev\nsudo apt install python3-venv\n
Mac: python3 should be already installed.
Then it should be the same for all platforms:
python3 -m venv meshcore\ncd meshcore && source bin/activate\npip install -U platformio\ngit clone https://github.com/ripplebiz/MeshCore.git\ncd MeshCore\n
open platformio.ini and in [arduino_base] edit the LORA_FREQ=867.5 save, then run:
[arduino_base]
LORA_FREQ=867.5
pio run -e RAK_4631_Repeater\n
then you'll find firmware.zip in .pio/build/RAK_4631_Repeater
firmware.zip
.pio/build/RAK_4631_Repeater
Andy also has a video on how to build using VS Code: How to build and flash Meshcore repeater firmware | Heltec V3 https://www.youtube.com/watch?v=WJvg6dt13hk (Link referenced in the Discord post)
A: Liam Cottle's MeshCore web client and MeshCore Javascript library are open source under MIT license.
Web client: https://github.com/liamcottle/meshcore-web Javascript: https://github.com/liamcottle/meshcore.js
A: ATAK is not currently on MeshCore's roadmap.
Meshcore would not be best suited to ATAK because MeshCore: clients do not repeat and therefore you would need a network of repeaters in place will not have a stable path where all clients are constantly moving between repeaters
You can use the same companion (same public key) that you used to add your repeaters or room servers to remove them from the Internet Map.
** A:** Yes. Below are the instructions to flash firmware onto a supported LoRa device using a Raspberry Pi over USB serial.
For ESP-based devices (e.g. Heltec V3) you need: - Download firmware file from flasher.meshcore.co.uk - Go to the web site on a browser, find the section that has the firmware up need - Click the Download button, right click on the file you need, for example, - Heltec_V3_companion_radio_ble-v1.7.1-165fb33.bin - Non-merged bin keeps the existing Bluetooth pairing database - Heltec_v3_companion_radio_usb-v1.7.1-165fb33-merged.bin - Merged bin overwrites everything including the bootloader, existing Bluetooth pairing database, but keeps configurations. - Right click on the file name and copy the link and note it for later use here is an example: https://flasher.meshcore.dev/releases/download/companion-v1.7.1/Heltec_v3_companion_radio_ble-v1.7.1-165fb33.bin - Run: - wget https://flasher.meshcore.dev/releases/download/companion-v1.7.1/Heltec_v3_companion_radio_ble-v1.7.1-165fb33.bin to download the firmware file for your device type. or the version you need - USB, BLE, Repeater, Room Server, merged bin or non-merged bin - If the above wget command only downloads a very small file (10K bytes instead of more than 100K byte, use this command instead: - wget --user-agent=\"Mozilla/5.0\" --content-disposition \"https://flasher.meshcore.dev/releases/download/companion-v1.7.1/Heltec_v3_companion_radio_usb-v1.7.1-165fb33.bin\" - Confirm the ttyXXXX device path on your Raspberry Pi: - Go to /dev directory, run ls command to find confirm your device path - They are usually /dev/ttyUSB0 for ESP devices - For ESP-based devices, install esptool from the shell: - pip install esptool --break-system-packages - To flash, use the following command: - For non-merged bin: - esptool.py -p /dev/ttyUSB0 --chip esp32-s3 write_flash 0x10000 <non-merged_firmware>.bin - For merged bin: - esptool.py -p /dev/ttyUSB0 --chip esp32-s3 write_flash 0x00000 <merged_firmware>.bin
wget --user-agent=\"Mozilla/5.0\" --content-disposition \"https://flasher.meshcore.dev/releases/download/companion-v1.7.1/Heltec_v3_companion_radio_usb-v1.7.1-165fb33.bin\"
pip install esptool --break-system-packages
esptool.py -p /dev/ttyUSB0 --chip esp32-s3 write_flash 0x10000 <non-merged_firmware>.bin
For nRF devices (e.g. RAK, Heltec T114) you need the following: - Download firmware file from flasher.meshcore.co.uk - Go to the web site on a browser, find the section that has the firmware up need - You need the ZIP version for the adafruit flash tool (below) - Click the Download button, right click on the ZIP file, for example: - RAK_4631_companion_radio_ble-v1.7.1-165fb33.zip - Right click on the file name and copy the link and note it for later use here is an example: https://flasher.meshcore.dev/releases/download/companion-v1.7.1/RAK_4631_companion_radio_ble-v1.7.1-165fb33.zip - Run: - wget https://flasher.meshcore.dev/releases/download/companion-v1.7.1/RAK_4631_companion_radio_ble-v1.7.1-165fb33.zip to download the firmware file for your device type. or the version you need - USB, BLE, Repeater, Room Server, ZIP file only - Confirm the ttyXXXX device path on your Raspberry Pi: - Go to /dev directory, run ls command to find confirm your device path - They are usually /dev/ttyACM0 for nRF devices - For nRF-based devices, install adafruit-nrfutil - pip install adafruit-nrfutil --break-system-packages - Use this command to flash the nRF device: - adafruit-nrfutil --verbose dfu serial --package RAK_4631_companion_radio_usb-v1.7.1-165fb33.zip -p /dev/ttyACM0 -b 115200 --singlebank --touch 1200
pip install adafruit-nrfutil --break-system-packages
adafruit-nrfutil --verbose dfu serial --package RAK_4631_companion_radio_usb-v1.7.1-165fb33.zip -p /dev/ttyACM0 -b 115200 --singlebank --touch 1200
To manage a repeater or room server connected to a Pi over USB serial using shell commands, you need to install picocom. To install picocom, run the following command: - sudo apt install picocom
picocom
sudo apt install picocom
To start managing your USB serial-connected device using picocom, use the following command: - picocom -b 115200 /dev/ttyUSB0 --imap lfcrlf
picocom -b 115200 /dev/ttyUSB0 --imap lfcrlf
A meta website/ git-repository collecting many projects related to MeshCore, grouped by type. See https://github.com/samuk/awesome-meshcore.
A Python script to send meshcore debug and packet capture data to MQTT for analysis. Cisien's version is a fork of Andrew-a-g's and is being used to to collect data for https://map.w0z.is/messages and https://analyzer.letsmesh.net/ https://github.com/Cisien/meshcoretomqtt https://github.com/Andrew-a-g/meshcoretomqtt
A custom Home Assistant integration for MeshCore mesh radio nodes. It allows you to monitor and control MeshCore nodes via USB, BLE, or TCP connections. https://github.com/awolden/meshcore-ha
Bindings to access your MeshCore companion radio nodes in python. https://github.com/fdlamotte/meshcore_py
CLI interface to MeshCore companion radio over BLE, TCP, or serial. Uses Python MeshCore above. https://github.com/fdlamotte/meshcore-cli
A JavaScript library for interacting with a MeshCore device running the companion radio firmware https://github.com/liamcottle/meshcore.js
pyMC_Core is a Python port of MeshCore, designed for Raspberry Pi and similar hardware, it talks to LoRa modules over SPI. https://github.com/rightup/pyMC_core
A TypeScript library for decoding MeshCore mesh networking packets with full cryptographic support. Uses WebAssembly (WASM) for Ed25519 key derivation through the orlp/ed25519 library. It powers the MeshCore Packet Analyzer. https://github.com/michaelhart/meshcore-decoder
meshcore-pi is another Python port of MeshCore, designed for Raspberry Pi and similar hardware, it talks to LoRa modules over SPI or GPIO. https://github.com/brianwiddas/meshcore-pi
pyMC_Repeater is a repeater daemon in Python built on top of the pymc_core library. https://github.com/rightup/pyMC_Repeater
A Node.js software that will upload every repeater or room server to map.meshcore.dev when a connected companion hears new advert. https://github.com/recrof/map.meshcore.dev-uploader
Open Source companion app for Android, iOS, GNU/Linux (and maybe other Unixes), Windows, macOS, chromium-based browsers. https://github.com/zjs81/meshcore-open
Standalone client firmware for the \"M5Stack Cardputer ADV\" with the \"M5Stack Cap LoRa-1262\" module.
Multi-protocol mesh firmware for ESP32-S3 LoRa devices (MeshCore, Meshtastic, RNode/KISS (Reticulum)). Protocol is auto-detected from the first bytes over serial or BLE. https://github.com/STCisGOOD/lunarcore
(Soon to be) Open Source companion firmware for LilyGO T-Deck (Plus) and Seeed Studio SenseCap Indicator (TFT / D1Pro), that can be used both standalone and together with a companion app. https://github.com/dabeani/meshcore
Companion firmware for LilyGo T-Deck Pro that allows standalone operation and connection to a companion app via Bluetooth Low Energy (BLE). https://github.com/pelgraine/Meck
Companion firmware for Seeed Studio Wio Tracker L1 Pro with specific UI adjustments that can be used standalone. https://github.com/sosprz/Meshcore-Wio-Tracker-L1-Pro
A: Yes, the same iOS and Android client is also available for Windows and Intel Mac (sorry, not available for ARM-based Mac yet). You can find them together with the Android APK here: https://files.liamcottle.net/MeshCore
A: Here is a list of MeshCore comparison resources: The Comms Channel on YouTube: https://www.youtube.com/watch?v=guDoKGs02Us MeshCore Advantages by MCarper: https://github.com/mikecarper/meshfirmware/blob/main/MeshCoreAdvantages.md Meshcore vs Meshtastic by austinmesh.org https://www.austinmesh.org/learn/meshcore-vs-meshtastic/
A: - If your client is a T-Deck, it may not have its time set (no GPS installed, no GPS lock, or wrong GPS baud rate). - If you are using the Android or iOS client, the other client, repeater, or room server may have the wrong time.
You can get the epoch time on https://www.epochconverter.com/ and use it to set your T-Deck clock. For a repeater and room server, the admin can use a T-Deck to remotely set their clock (clock sync), or use the time command in the USB serial console with the server device connected.
time
A: You can't connect to a device running repeater firmware via Bluetooth. Devices running the BLE companion firmware you can connect to it via Bluetooth using the android app
A: make sure that you flashed the Bluetooth companion firmware and not the USB-only companion firmware.
A: the default Bluetooth pairing code is 123456
123456
A: Heltec V3 has a very small coil antenna on its PCB for Wi-Fi and Bluetooth connectivity. It has a very short range, only a few feet. It is possible to remove the coil antenna and replace it with a 31mm wire. The BT range is much improved with the modification.
A: 1. Connect USB-C cable to your device, per your device's instruction, get it to flash mode: - For RAK, click the reset button TWICE - For T1000-e, quickly disconnect and reconnect the magnetic side of the cable from the device TWICE - For Heltec T114, click the reset button TWICE (the bottom button) - For Xiao nRF52, click the reset button once. If that doesn't work, quickly double click the reset button twice. If that doesn't work, disconnection the board from your PC and reconnect again (seeed studio wiki) 5. A new folder will appear on your computer's desktop 6. Download the flash_erase*.uf2 file for your device on flasher.meshcore.co.uk - RAK WisBlock and Heltec T114: Flash_erase-nRF32_softdevice_v6.uf2 - Seeed Studio Xiao nRF52 WIO: Flash_erase-nRF52_softdevice_v7.uf2 8. drag and drop the uf2 file for your device to the root of the new folder 9. Wait for the copy to complete. You might get an error dialog, you can ignore it 10. Go to https://flasher.meshcore.co.uk/, click Console and select the serial port for your connected device 11. In the console, press enter. Your flash should now be erased 12. You may now flash the latest MeshCore firmware onto your device
Allow the browser user on it: # setfacl -m u:YOUR_USER_HERE:rw /dev/ttyUSB0
# setfacl -m u:YOUR_USER_HERE:rw /dev/ttyUSB0
Settings
Packets receipt notifications
Number of Packets
OTA
Force Scanning
Upload
A: You can flash this safer bootloader to the Wio Tracker L1 Pro https://github.com/oltaco/Adafruit_nRF52_Bootloader_OTAFIX
A: For ESP32-based devices (e.g. Heltec V3): 1. On flasher.meshcore.co.uk, download the non-merged version of the firmware for your ESP32 device (e.g. Heltec_v3_repeater-v1.6.2-4449fd3.bin, no \"merged\" in the file name) 2. From the MeshCore app, login remotely to the repeater you want to update with admin privilege 4. Go to the Command Line tab, type start ota and hit enter. 5. you should see OK to confirm the repeater device is now in OTA mode 6. The command start ota on an ESP32-based device starts a wifi hotspot named MeshCore OTA 7. From your phone or computer connect to the 'MeshCore OTA' hotspot 8. From a browser, go to http://192.168.4.1/update and upload the non-merged bin from the flasher
\"merged\"
MeshCore OTA
A: Yes, developer che aporeps has an enhanced OTA DFU bootloader for nRF52 based devices. With this bootloader, if it detects that the application firmware is invalid, it falls back to OTA DFU mode so you can attempt to flash again to recover. This bootloader has other changes to make the OTA DFU process more fault tolerant.
che aporeps
Refer to https://github.com/oltaco/Adafruit_nRF52_Bootloader_OTAFIX for the latest information.
Currently, the following boards are supported: - Heltec Automation Mesh Node T114 / HT-nRF5262 - Nologo ProMicro NRF52840 (aka SuperMini NRF52840) - Seeed Studio SenseCAP Card Tracker T1000-E - Seeed Studio Wio Tracker L1 - Seeed Studio XIAO nRF52840 BLE - Seeed Studio XIAO nRF52840 BLE SENSE - RAK 4631 (See note) - RAK WisMesh Tag (new 28/11/2025)
A: Yes, it is on the MeshCore github repo here: https://github.com/meshcore-dev/MeshCore/tree/main/logo
A: Channel: meshcore://channel/add?name=<name>&secret=<secret>
meshcore://channel/add?name=<name>&secret=<secret>
Contact: meshcore://contact/add?name=<name>&public_key=<secret>&type=<type>
meshcore://contact/add?name=<name>&public_key=<secret>&type=<type>
where &type is: chat = 1 repeater = 2 room = 3 sensor = 4
&type
chat = 1
repeater = 2
room = 3
sensor = 4
A: WiFi firmware requires you to compile it yourself, as you need to set the wifi ssid and password. Edit WIFI_SSID and WIFI_PWD in ./variants/heltec_v3/platformio.ini and then flash it to your device.
Standard KISS TNC firmware for MeshCore LoRa radios. Compatible with any KISS client (Direwolf, APRSdroid, YAAC, etc.) for sending and receiving raw packets. MeshCore-specific extensions (cryptography, radio configuration, telemetry) are available through the standard SetHardware (0x06) command.
115200 baud, 8N1, no flow control.
Standard KISS framing per the KA9Q/K3MC specification.
0xC0
0xDB
0xDC
0xDD
\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 FEND \u2502 Type Byte \u2502 Data (escaped)\u2502 FEND \u2502\n\u2502 0xC0 \u2502 1 byte \u2502 0-510 bytes \u2502 0xC0 \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n
The type byte is split into two nibbles:
Maximum unescaped frame size: 512 bytes.
0x00
0x01
0x02
0x03
0x04
0x05
0x06
0xFF
Data frames carry raw packet data only, with no metadata prepended. The Data command payload is limited to 255 bytes to match the MeshCore maximum transmission unit (MAX_TRANS_UNIT); frames larger than 255 bytes are silently dropped. The KISS specification recommends at least 1024 bytes for general-purpose TNCs; this modem is intended for MeshCore packets only, whose protocol MTU is 255 bytes.
The TNC implements p-persistent CSMA for half-duplex operation:
In full-duplex mode, CSMA is bypassed and packets transmit after TXDELAY.
MeshCore-specific functionality uses the standard KISS SetHardware command. The first byte of SetHardware data is a sub-command. Standard KISS clients ignore these frames.
\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 FEND \u2502 0x06 \u2502 Sub-command \u2502 Data (escaped)\u2502 FEND \u2502\n\u2502 0xC0 \u2502 \u2502 1 byte \u2502 variable \u2502 0xC0 \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n
0x07
0x08
0x09
0x0A
0x0B
0x0C
0x0D
0x0E
0x0F
0x10
0x11
0x12
0x13
0x14
0x15
0x16
0x17
0x18
0x19
0x1A
Response codes use the high-bit convention: response = command | 0x80. Generic and unsolicited responses use the 0xF0+ range.
response = command | 0x80
0xF0
0x81
0x82
0x83
0x84
0x85
0x86
0x87
0x88
0x8B
0x8C
0x8D
0x8E
0x8F
0x90
0x91
0x92
0x93
0x94
0x95
0x96
0x97
0x9A
0xF1
0xF8
0xF9
The TNC sends these SetHardware frames without a preceding request:
TxDone (0xF8): Sent after a packet has been transmitted. Contains a single byte: 0x01 for success, 0x00 for failure.
RxMeta (0xF9): Sent immediately after each standard data frame (type 0x00) with metadata for the received packet. Contains SNR (1 byte, signed, value x4 for 0.25 dB precision) followed by RSSI (1 byte, signed, dBm). Enabled by default; can be toggled with SetSignalReport. Standard KISS clients ignore this frame.
All values little-endian.
The modem recalibrates the noise floor every 2 seconds with an AGC reset every 30 seconds.
Returns NoCallback error if the board does not support temperature readings.
NoCallback
Sends an OK response, flushes serial, then reboots the device. The host should expect the connection to drop.
Use 0x07 for all permissions.
Data returned in CayenneLPP format. See CayenneLPP documentation for parsing.
The nRF52 Power Management module provides battery protection features to prevent over-discharge, minimise likelihood of brownout and flash corruption conditions existing, and enable safe voltage-based recovery.
Shutdown reason codes (stored in GPREGRET2): | Code | Name | Description | |------|------|-------------| | 0x00 | NONE | Normal boot / no previous shutdown | | 0x4C | LOW_VOLTAGE | Runtime low voltage threshold reached | | 0x55 | USER | User requested powerOff() | | 0x42 | BOOT_PROTECT | Boot voltage protection triggered |
xiao_nrf52
rak4631
heltec_t114
Notes: - \"Implemented\" reflects Phase 1 (boot lockout + shutdown reason capture). - User power-off on Heltec T114 does not enable LPCOMP wake. - VBUS detection is used to skip boot lockout on external power, and VBUS wake is configured alongside LPCOMP when supported hardware exposes VBUS to the nRF52.
The power management functionality is integrated into the NRF52Board base class in src/helpers/NRF52Board.cpp. Board variants provide hardware-specific configuration via a PowerMgtConfig struct and override initiateShutdown(uint8_t reason) to perform board-specific power-down work and conditionally enable voltage wake (LPCOMP + VBUS).
NRF52Board
src/helpers/NRF52Board.cpp
PowerMgtConfig
initiateShutdown(uint8_t reason)
A static constructor with priority 101 in NRF52Board.cpp captures the RESETREAS and GPREGRET2 registers before: - SystemInit() (priority 102) - which clears RESETREAS - Static C++ constructors (default priority 65535)
NRF52Board.cpp
This ensures we capture the true reset reason before any initialisation code runs.
To enable power management on a board variant:
Enable in platformio.ini: ini -D NRF52_POWER_MANAGEMENT
ini -D NRF52_POWER_MANAGEMENT
Define configuration in variant.h: c #define PWRMGT_VOLTAGE_BOOTLOCK 3300 // Won't boot below this voltage (mV) #define PWRMGT_LPCOMP_AIN 7 // AIN channel for voltage sensing #define PWRMGT_LPCOMP_REFSEL 2 // REFSEL (0-6=1/8..7/8, 7=ARef, 8-15=1/16..15/16)
c #define PWRMGT_VOLTAGE_BOOTLOCK 3300 // Won't boot below this voltage (mV) #define PWRMGT_LPCOMP_AIN 7 // AIN channel for voltage sensing #define PWRMGT_LPCOMP_REFSEL 2 // REFSEL (0-6=1/8..7/8, 7=ARef, 8-15=1/16..15/16)
Implement in board .cpp file: ```cpp #ifdef NRF52_POWER_MANAGEMENT const PowerMgtConfig power_config = { .lpcomp_ain_channel = PWRMGT_LPCOMP_AIN, .lpcomp_refsel = PWRMGT_LPCOMP_REFSEL, .voltage_bootlock = PWRMGT_VOLTAGE_BOOTLOCK };
void MyBoard::initiateShutdown(uint8_t reason) { // Board-specific shutdown preparation (e.g., disable peripherals) bool enable_lpcomp = (reason == SHUTDOWN_REASON_LOW_VOLTAGE || reason == SHUTDOWN_REASON_BOOT_PROTECT);
if (enable_lpcomp) {\n configureVoltageWake(power_config.lpcomp_ain_channel, power_config.lpcomp_refsel);\n }\n\n enterSystemOff(reason);\n
} #endif
void MyBoard::begin() { NRF52Board::begin(); // or NRF52BoardDCDC::begin() // ... board setup ...
#ifdef NRF52_POWER_MANAGEMENT checkBootVoltage(&power_config); #endif } ```
For user-initiated shutdowns, powerOff() remains board-specific. Power management only arms LPCOMP for automated shutdown reasons (boot protection/low voltage).
powerOff()
cpp #ifdef NRF52_POWER_MANAGEMENT void initiateShutdown(uint8_t reason) override; #endif
The LPCOMP (Low Power Comparator) is configured to: - Monitor the specified AIN channel (0-7 corresponding to P0.02-P0.05, P0.28-P0.31) - Compare against VDD fraction reference (REFSEL: 0-6=1/8..7/8, 7=ARef, 8-15=1/16..15/16) - Detect UP events (voltage rising above threshold) - Use 50mV hysteresis for noise immunity - Wake the device from SYSTEMOFF when triggered
VBUS wake is enabled via the POWER peripheral USBDETECTED event whenever configureVoltageWake() is used. This requires USB VBUS to be routed to the nRF52 (typical on nRF52840 boards with native USB).
configureVoltageWake()
LPCOMP Reference Selection (PWRMGT_LPCOMP_REFSEL): | REFSEL | Fraction | VBAT @ 1M/1M divider (VDD=3.0-3.3) | VBAT @ 1.5M/1M divider (VDD=3.0-3.3) | |--------|----------|------------------------------------|--------------------------------------| | 0 | 1/8 | 0.75-0.82 V | 0.94-1.03 V | | 1 | 2/8 | 1.50-1.65 V | 1.88-2.06 V | | 2 | 3/8 | 2.25-2.47 V | 2.81-3.09 V | | 3 | 4/8 | 3.00-3.30 V | 3.75-4.12 V | | 4 | 5/8 | 3.75-4.12 V | 4.69-5.16 V | | 5 | 6/8 | 4.50-4.95 V | 5.62-6.19 V | | 6 | 7/8 | 5.25-5.77 V | 6.56-7.22 V | | 7 | ARef | - | - | | 8 | 1/16 | 0.38-0.41 V | 0.47-0.52 V | | 9 | 3/16 | 1.12-1.24 V | 1.41-1.55 V | | 10 | 5/16 | 1.88-2.06 V | 2.34-2.58 V | | 11 | 7/16 | 2.62-2.89 V | 3.28-3.61 V | | 12 | 9/16 | 3.38-3.71 V | 4.22-4.64 V | | 13 | 11/16 | 4.12-4.54 V | 5.16-5.67 V | | 14 | 13/16 | 4.88-5.36 V | 6.09-6.70 V | | 15 | 15/16 | 5.62-6.19 V | 7.03-7.73 V |
Important: For boards with a voltage divider on the battery sense pin, LPCOMP measures the divided voltage. Use: VBAT_threshold \u2248 (VDD * fraction) * divider_scale, where divider_scale = (Rtop + Rbottom) / Rbottom (e.g., 2.0 for 1M/1M, 2.5 for 1.5M/1M, 3.0 for XIAO).
VBAT_threshold \u2248 (VDD * fraction) * divider_scale
divider_scale = (Rtop + Rbottom) / Rbottom
The power management code checks whether SoftDevice is enabled and uses the appropriate API: - When SD enabled: sd_power_* functions - When SD disabled: Direct register access (NRF_POWER->*)
sd_power_*
This ensures compatibility regardless of BLE stack state.
Power management status can be queried via the CLI:
On boards without power management enabled, all commands except get pwrmgt.support return:
ERROR: Power management not supported\n
When MESH_DEBUG=1 is enabled, the power management module outputs:
MESH_DEBUG=1
DEBUG: PWRMGT: Reset = Wake from LPCOMP (0x20000); Shutdown = Low Voltage (0x4C)\nDEBUG: PWRMGT: Boot voltage = 3450 mV (threshold = 3300 mV)\nDEBUG: PWRMGT: LPCOMP wake configured (AIN7, ref=3/8 VDD)\n
This document describes the MeshCore packet format.
0xYY
YY
0bYY
0000000X
X0000000
This is the protocol level packet structure used in MeshCore firmware v1.12.0
[header][transport_codes(optional)][path_length][path][payload]\n
0bVVPPPPRR
V=Version
P=PayloadType
R=RouteType
0b00
ROUTE_TYPE_TRANSPORT_FLOOD
0b01
ROUTE_TYPE_FLOOD
0b10
ROUTE_TYPE_DIRECT
0b11
ROUTE_TYPE_TRANSPORT_DIRECT
0b0000
PAYLOAD_TYPE_REQ
0b0001
PAYLOAD_TYPE_RESPONSE
REQ
ANON_REQ
0b0010
PAYLOAD_TYPE_TXT_MSG
0b0011
PAYLOAD_TYPE_ACK
0b0100
PAYLOAD_TYPE_ADVERT
0b0101
PAYLOAD_TYPE_GRP_TXT
0b0110
PAYLOAD_TYPE_GRP_DATA
0b0111
PAYLOAD_TYPE_ANON_REQ
0b1000
PAYLOAD_TYPE_PATH
0b1001
PAYLOAD_TYPE_TRACE
0b1010
PAYLOAD_TYPE_MULTIPART
0b1011
PAYLOAD_TYPE_CONTROL
0b1100
0b1101
0b1110
0b1111
PAYLOAD_TYPE_RAW_CUSTOM
transport_codes
transport_code_1
uint16_t
transport_code_2
path_length
0-63
path
hop_count * hash_size
MAX_PATH_SIZE
payload
MAX_PACKET_PAYLOAD
NOTE: see the Payloads documentation for more information about the content of specific payload types.
Bit 0 means the lowest bit (1s place)
0x3C
path_length is not a raw byte count. It packs both hash size and hop count:
hash_size - 1
Hash size codes:
Examples:
0x45
0x8A
Inside each MeshCore Packet is a payload, identified by the payload type in the packet header. The types of payloads are:
This document defines the structure of each of these payload types.
NOTE: all 16 and 32-bit integer fields are Little Endian.
This kind of payload notifies receivers that a node exists, and gives information about the node
Appdata
Appdata Flags
0x20
0x40
0x80
An acknowledgement that a message was received. Note that for returned path messages, an acknowledgement can be sent in the \"extra\" payload (see Returned Path) instead of as a separate ackowledgement packet. CLI commands do not cause acknowledgement responses, neither discrete nor extra.
Returned path, request, response, and plain text messages are all formatted in the same way. See the subsection for more details about the ciphertext's associated plaintext representation.
Returned path messages provide a description of the route a packet took from the original author. Receivers will send returned path messages to the author of the original message.
For the common chat/server helpers in BaseChatMesh, the current request type values are:
BaseChatMesh
Gets information about the node, possibly including the following:
Not defined in BaseChatMesh. Sensor- and application-specific request payloads may be implemented by higher-level firmware.
Not defined in BaseChatMesh.
Response contents are opaque application data. There is no single generic response envelope beyond the encrypted payload wrapper shown above.
txt_type
The plaintext contained in the ciphertext matches the format described in plain text message. Specifically, it consists of a four byte timestamp, a flags byte, and the message. The flags byte will generally be 0x00 because it is a \"plain text message\". The message will be of the form <sender name>: <message body> (eg., user123: I'm on my way).
<sender name>: <message body>
user123: I'm on my way
Custom packets have no defined format.
This document provides an overview of QR Code formats that can be used for sharing MeshCore channels and contacts. The formats described below are supported by the MeshCore mobile app.
Example URL:
meshcore://channel/add?name=Public&secret=8b3387e9c5cdea6ac9e5edbaa115cd72\n
Parameters:
meshcore://contact/add?name=Example+Contact&public_key=9cd8fcf22a47333b591d96a2b848b73f457b1bb1a3ea2453a885f9e5787765b1&type=1\n
public_key
type
4
Binary frame structures for companion radio stats commands. All multi-byte integers use little-endian byte order.
CMD_GET_STATS
The CMD_GET_STATS command uses a 2-byte frame structure: - Byte 0: CMD_GET_STATS (56) - Byte 1: Stats sub-type: - STATS_TYPE_CORE (0) - Get core device statistics - STATS_TYPE_RADIO (1) - Get radio statistics - STATS_TYPE_PACKETS (2) - Get packet statistics
STATS_TYPE_CORE
STATS_TYPE_RADIO
STATS_TYPE_PACKETS
RESP_CODE_STATS
The RESP_CODE_STATS response uses a 2-byte header structure: - Byte 0: RESP_CODE_STATS (24) - Byte 1: Stats sub-type (matches command sub-type): - STATS_TYPE_CORE (0) - Core device statistics response - STATS_TYPE_RADIO (1) - Radio statistics response - STATS_TYPE_PACKETS (2) - Packet statistics response
Total Frame Size: 11 bytes
struct StatsCore {\n uint8_t response_code; // 0x18\n uint8_t stats_type; // 0x00 (STATS_TYPE_CORE)\n uint16_t battery_mv;\n uint32_t uptime_secs;\n uint16_t errors;\n uint8_t queue_len;\n} __attribute__((packed));\n
Total Frame Size: 14 bytes
struct StatsRadio {\n uint8_t response_code; // 0x18\n uint8_t stats_type; // 0x01 (STATS_TYPE_RADIO)\n int16_t noise_floor;\n int8_t last_rssi;\n int8_t last_snr; // Divide by 4.0 to get actual SNR in dB\n uint32_t tx_air_secs;\n uint32_t rx_air_secs;\n} __attribute__((packed));\n
Total Frame Size: 26 bytes (legacy) or 30 bytes (includes recv_errors)
recv_errors
recv = flood_rx + direct_rx
sent = flood_tx + direct_tx
struct StatsPackets {\n uint8_t response_code; // 0x18\n uint8_t stats_type; // 0x02 (STATS_TYPE_PACKETS)\n uint32_t recv;\n uint32_t sent;\n uint32_t flood_tx;\n uint32_t direct_tx;\n uint32_t flood_rx;\n uint32_t direct_rx;\n uint32_t recv_errors; // present when frame size is 30\n} __attribute__((packed));\n
# Send CMD_GET_STATS command\ndef send_get_stats_core(serial_interface):\n \"\"\"Send command to get core stats\"\"\"\n cmd = bytes([56, 0]) # CMD_GET_STATS (56) + STATS_TYPE_CORE (0)\n serial_interface.write(cmd)\n\ndef send_get_stats_radio(serial_interface):\n \"\"\"Send command to get radio stats\"\"\"\n cmd = bytes([56, 1]) # CMD_GET_STATS (56) + STATS_TYPE_RADIO (1)\n serial_interface.write(cmd)\n\ndef send_get_stats_packets(serial_interface):\n \"\"\"Send command to get packet stats\"\"\"\n cmd = bytes([56, 2]) # CMD_GET_STATS (56) + STATS_TYPE_PACKETS (2)\n serial_interface.write(cmd)\n
import struct\n\ndef parse_stats_core(frame):\n \"\"\"Parse RESP_CODE_STATS + STATS_TYPE_CORE frame (11 bytes)\"\"\"\n response_code, stats_type, battery_mv, uptime_secs, errors, queue_len = \\\n struct.unpack('<B B H I H B', frame)\n assert response_code == 24 and stats_type == 0, \"Invalid response type\"\n return {\n 'battery_mv': battery_mv,\n 'uptime_secs': uptime_secs,\n 'errors': errors,\n 'queue_len': queue_len\n }\n\ndef parse_stats_radio(frame):\n \"\"\"Parse RESP_CODE_STATS + STATS_TYPE_RADIO frame (14 bytes)\"\"\"\n response_code, stats_type, noise_floor, last_rssi, last_snr, tx_air_secs, rx_air_secs = \\\n struct.unpack('<B B h b b I I', frame)\n assert response_code == 24 and stats_type == 1, \"Invalid response type\"\n return {\n 'noise_floor': noise_floor,\n 'last_rssi': last_rssi,\n 'last_snr': last_snr / 4.0, # Unscale SNR\n 'tx_air_secs': tx_air_secs,\n 'rx_air_secs': rx_air_secs\n }\n\ndef parse_stats_packets(frame):\n \"\"\"Parse RESP_CODE_STATS + STATS_TYPE_PACKETS frame (26 or 30 bytes)\"\"\"\n assert len(frame) >= 26, \"STATS_TYPE_PACKETS frame too short\"\n response_code, stats_type, recv, sent, flood_tx, direct_tx, flood_rx, direct_rx = \\\n struct.unpack('<B B I I I I I I', frame[:26])\n assert response_code == 24 and stats_type == 2, \"Invalid response type\"\n result = {\n 'recv': recv,\n 'sent': sent,\n 'flood_tx': flood_tx,\n 'direct_tx': direct_tx,\n 'flood_rx': flood_rx,\n 'direct_rx': direct_rx\n }\n if len(frame) >= 30:\n (recv_errors,) = struct.unpack('<I', frame[26:30])\n result['recv_errors'] = recv_errors\n return result\n
// Send CMD_GET_STATS command\nconst CMD_GET_STATS = 56;\nconst STATS_TYPE_CORE = 0;\nconst STATS_TYPE_RADIO = 1;\nconst STATS_TYPE_PACKETS = 2;\n\nfunction sendGetStatsCore(serialInterface: SerialPort): void {\n const cmd = new Uint8Array([CMD_GET_STATS, STATS_TYPE_CORE]);\n serialInterface.write(cmd);\n}\n\nfunction sendGetStatsRadio(serialInterface: SerialPort): void {\n const cmd = new Uint8Array([CMD_GET_STATS, STATS_TYPE_RADIO]);\n serialInterface.write(cmd);\n}\n\nfunction sendGetStatsPackets(serialInterface: SerialPort): void {\n const cmd = new Uint8Array([CMD_GET_STATS, STATS_TYPE_PACKETS]);\n serialInterface.write(cmd);\n}\n
interface StatsCore {\n battery_mv: number;\n uptime_secs: number;\n errors: number;\n queue_len: number;\n}\n\ninterface StatsRadio {\n noise_floor: number;\n last_rssi: number;\n last_snr: number;\n tx_air_secs: number;\n rx_air_secs: number;\n}\n\ninterface StatsPackets {\n recv: number;\n sent: number;\n flood_tx: number;\n direct_tx: number;\n flood_rx: number;\n direct_rx: number;\n recv_errors?: number; // present when frame is 30 bytes\n}\n\nfunction parseStatsCore(buffer: ArrayBuffer): StatsCore {\n const view = new DataView(buffer);\n const response_code = view.getUint8(0);\n const stats_type = view.getUint8(1);\n if (response_code !== 24 || stats_type !== 0) {\n throw new Error('Invalid response type');\n }\n return {\n battery_mv: view.getUint16(2, true),\n uptime_secs: view.getUint32(4, true),\n errors: view.getUint16(8, true),\n queue_len: view.getUint8(10)\n };\n}\n\nfunction parseStatsRadio(buffer: ArrayBuffer): StatsRadio {\n const view = new DataView(buffer);\n const response_code = view.getUint8(0);\n const stats_type = view.getUint8(1);\n if (response_code !== 24 || stats_type !== 1) {\n throw new Error('Invalid response type');\n }\n return {\n noise_floor: view.getInt16(2, true),\n last_rssi: view.getInt8(4),\n last_snr: view.getInt8(5) / 4.0, // Unscale SNR\n tx_air_secs: view.getUint32(6, true),\n rx_air_secs: view.getUint32(10, true)\n };\n}\n\nfunction parseStatsPackets(buffer: ArrayBuffer): StatsPackets {\n const view = new DataView(buffer);\n if (buffer.byteLength < 26) {\n throw new Error('STATS_TYPE_PACKETS frame too short');\n }\n const response_code = view.getUint8(0);\n const stats_type = view.getUint8(1);\n if (response_code !== 24 || stats_type !== 2) {\n throw new Error('Invalid response type');\n }\n const result: StatsPackets = {\n recv: view.getUint32(2, true),\n sent: view.getUint32(6, true),\n flood_tx: view.getUint32(10, true),\n direct_tx: view.getUint32(14, true),\n flood_rx: view.getUint32(18, true),\n direct_rx: view.getUint32(22, true)\n };\n if (buffer.byteLength >= 30) {\n result.recv_errors = view.getUint32(26, true);\n }\n return result;\n}\n
Below are the commands you can enter into the Terminal Chat clients:
set freq {frequency}\n
Set the LoRa frequency. Example: set freq 915.8
set tx {tx-power-dbm}\n
Sets LoRa transmit power in dBm.
set name {name}\n
Sets your advertisement name.
set lat {latitude}\n
Sets your advertisement map latitude. (decimal degrees)
set lon {longitude}\n
Sets your advertisement map longitude. (decimal degrees)
set af {air-time-factor}\n
Sets the transmit air-time-factor.
time {epoch-secs}\n
Set the device clock using UNIX epoch seconds. Example: time 1738242833
advert\n
Sends an advertisement packet
clock\n
Displays current time per device's clock.
ver\n
Shows the device version and firmware build date.
card\n
Displays your 'business card', for other to manually import
import {card}\n
Imports the given card to your contacts.
list {n}\n
List all contacts by most recent. (optional {n}, is the last n by advertisement date)
to\n
Shows the name of current recipient contact. (for subsequent 'send' commands)
to {name-prefix}\n
Sets the recipient to the first matching contact (in 'list') by the name prefix. (ie. you don't have to type whole name)
send {text}\n
Sends the text message (as DM) to current recipient.
reset path\n
Resets the path to current recipient, for new path discovery.
public {text}\n
Sends the text message to the built-in 'public' group channel
Parameters: - pubkey_prefix: The public key of the node to remove from the neighbors list. This can be a short prefix or the full key. All neighbors matching the provided prefix will be removed.
BLE Companion BLE Companion firmware runs on a supported LoRa device and connects to a smart device running the Android or iOS MeshCore client over BLE https://meshcore.io/
USB Serial Companion USB Serial Companion firmware runs on a supported LoRa device and connects to a smart device or a computer over USB Serial running the MeshCore web client https://app.meshcore.nz/
A: The original MeshCore protocol design uses the first byte of a repeater's public key to denote the repeater in a path. And with 1 byte for each repeater in the path, MeshCore packets can travel as many as 64 hops.
\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 path.hash.mode \u2502 Advert path hash size \u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 0 \u2502 1 byte (default) \u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 1 \u2502 2 bytes \u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 2 \u2502 3 bytes \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518 \n
A: 1. Device off 2. Connect USB cable to device 3. Hold down trackball (keep holding) 4. Turn on device 5. Hear USB connection sound 6. Release trackball 7. T-Deck in DFU mode now 8. At this point you can begin flashing using https://flasher.meshcore.io
For ESP-based devices (e.g. Heltec V3) you need: - Download firmware file from https://flasher.meshcore.io - Go to the web site on a browser, find the section that has the firmware up need - Click the Download button, right click on the file you need, for example, - Heltec_V3_companion_radio_ble-v1.7.1-165fb33.bin - Non-merged bin keeps the existing Bluetooth pairing database - Heltec_v3_companion_radio_usb-v1.7.1-165fb33-merged.bin - Merged bin overwrites everything including the bootloader, existing Bluetooth pairing database, but keeps configurations. - Right click on the file name and copy the link and note it for later use here is an example: https://flasher.meshcore.io/releases/download/companion-v1.7.1/Heltec_v3_companion_radio_ble-v1.7.1-165fb33.bin - Run: - wget https://flasher.meshcore.io/releases/download/companion-v1.7.1/Heltec_v3_companion_radio_ble-v1.7.1-165fb33.bin to download the firmware file for your device type. or the version you need - USB, BLE, Repeater, Room Server, merged bin or non-merged bin - If the above wget command only downloads a very small file (10K bytes instead of more than 100K byte, use this command instead: - wget --user-agent=\"Mozilla/5.0\" --content-disposition \"https://flasher.meshcore.io/releases/download/companion-v1.7.1/Heltec_v3_companion_radio_usb-v1.7.1-165fb33.bin\" - Confirm the ttyXXXX device path on your Raspberry Pi: - Go to /dev directory, run ls command to find confirm your device path - They are usually /dev/ttyUSB0 for ESP devices - For ESP-based devices, install esptool from the shell: - pip install esptool --break-system-packages - To flash, use the following command: - For non-merged bin: - esptool.py -p /dev/ttyUSB0 --chip esp32-s3 write_flash 0x10000 <non-merged_firmware>.bin - For merged bin: - esptool.py -p /dev/ttyUSB0 --chip esp32-s3 write_flash 0x00000 <merged_firmware>.bin
wget --user-agent=\"Mozilla/5.0\" --content-disposition \"https://flasher.meshcore.io/releases/download/companion-v1.7.1/Heltec_v3_companion_radio_usb-v1.7.1-165fb33.bin\"
For nRF devices (e.g. RAK, Heltec T114) you need the following: - Download firmware file from https://flasher.meshcore.io - Go to the web site on a browser, find the section that has the firmware up need - You need the ZIP version for the adafruit flash tool (below) - Click the Download button, right click on the ZIP file, for example: - RAK_4631_companion_radio_ble-v1.7.1-165fb33.zip - Right click on the file name and copy the link and note it for later use here is an example: https://flasher.meshcore.io/releases/download/companion-v1.7.1/RAK_4631_companion_radio_ble-v1.7.1-165fb33.zip - Run: - wget https://flasher.meshcore.io/releases/download/companion-v1.7.1/RAK_4631_companion_radio_ble-v1.7.1-165fb33.zip to download the firmware file for your device type. or the version you need - USB, BLE, Repeater, Room Server, ZIP file only - Confirm the ttyXXXX device path on your Raspberry Pi: - Go to /dev directory, run ls command to find confirm your device path - They are usually /dev/ttyACM0 for nRF devices - For nRF-based devices, install adafruit-nrfutil - pip install adafruit-nrfutil --break-system-packages - Use this command to flash the nRF device: - adafruit-nrfutil --verbose dfu serial --package RAK_4631_companion_radio_usb-v1.7.1-165fb33.zip -p /dev/ttyACM0 -b 115200 --singlebank --touch 1200
A: 1. Connect USB-C cable to your device, per your device's instruction, get it to flash mode: - For RAK, click the reset button TWICE - For T1000-e, quickly disconnect and reconnect the magnetic side of the cable from the device TWICE - For Heltec T114, click the reset button TWICE (the bottom button) - For Xiao nRF52, click the reset button once. If that doesn't work, quickly double click the reset button twice. If that doesn't work, disconnection the board from your PC and reconnect again (seeed studio wiki) 5. A new folder will appear on your computer's desktop 6. Download the flash_erase*.uf2 file for your device on https://flasher.meshcore.io - RAK WisBlock and Heltec T114: Flash_erase-nRF32_softdevice_v6.uf2 - Seeed Studio Xiao nRF52 WIO: Flash_erase-nRF52_softdevice_v7.uf2 8. drag and drop the uf2 file for your device to the root of the new folder 9. Wait for the copy to complete. You might get an error dialog, you can ignore it 10. Go to https://flasher.meshcore.io, click Console and select the serial port for your connected device 11. In the console, press enter. Your flash should now be erased 12. You may now flash the latest MeshCore firmware onto your device
A: For ESP32-based devices (e.g. Heltec V3): 1. On https://flasher.meshcore.io, download the non-merged version of the firmware for your ESP32 device (e.g. Heltec_v3_repeater-v1.6.2-4449fd3.bin, no \"merged\" in the file name) 2. From the MeshCore app, login remotely to the repeater you want to update with admin privilege 4. Go to the Command Line tab, type start ota and hit enter. 5. you should see OK to confirm the repeater device is now in OTA mode 6. The command start ota on an ESP32-based device starts a wifi hotspot named MeshCore OTA 7. From your phone or computer connect to the 'MeshCore OTA' hotspot 8. From a browser, go to http://192.168.4.1/update and upload the non-merged bin from the flasher
\u26a0\ufe0f WARNING: Set these values at your own risk. Incorrect power settings can permanently damage your radio hardware.