Mirrors/MeshCore-Solo
1
0
Fork 0
mirror of https://github.com/MarekZegare4/MeshCore-Solo.git synced 2026-11-01 02:11:57 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge upstream companion-v1.18.0

Browse Source 
Fixes and features from upstream: MACThenDecrypt / command buffer
overflow fixes, ACK forwarding delay, transport code 0 as unscoped,
hidden nodes don't answer DISCOVER, LR2021/LR1121 fixes, GPS cold-start
detection and waitFor()/drain(), NMEA fix-age counters, ESP32 RTC after a
crash, remote CLI by text message (TXT_TYPE_CLI_COMMAND),
PUSH_CODE_BINARY_RESPONSE, board.loop(), new boards (Wio Tracker L1 1W,
ThinkNode M4/M8, Muzi Base, Waveshare LR1121, Pico W).

Kept ours: NodePrefs, main.cpp, every UI, GxEPDDisplay. The companion CLI
stays MyMeshCli.h's handleCliCommand(); upstream's handleCommand() calls
it. The board's FEM gains go through attachDynamicPrefs() with an adapter
over our NodePrefs fields. Upstream's JSON prefs and MultiSerialInterface
come as their own stages.

Also: the display defaults were inside RADIO_FEM_TXGAIN's #else (a
missing #endif).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Jakub
2026-10-15 13:11:48 +02:00
co-authored by Claude Opus 5.5
parent d1fc6e3fdd 81dbae592f
commit 28be1c6206
188 changed files with 6226 additions and 789 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/cli_commands.md
+11 -6
View File
@@ -211,7 +211,7 @@ This document provides an overview of CLI commands that can be sent to MeshCore
**Set by build flag:** `LORA_FREQ`, `LORA_BW`, `LORA_SF`, `LORA_CR`
**Default:** `869.525,250,11,5`
**Default:** `869.618,62.5,8,5`
**Note:** Requires reboot to apply
@@ -256,7 +256,7 @@ This document provides an overview of CLI commands that can be sent to MeshCore
**Parameters:**
- `frequency`: Frequency in MHz
**Default:** `869.525`
**Default:** `869.618`
**Note:** Requires reboot to apply
**Serial Only:** `set freq <frequency>`
@@ -537,7 +537,7 @@ This document provides an overview of CLI commands that can be sent to MeshCore
**Parameters:**
- `value`: Direct transmit delay factor (0-2)
**Default:** `0.2`
**Default:** `0.3` (Repeater) - `0.2` (Room Server, Sensor)
**Note:** Same collision-avoidance random window as `txdelay`, but applied to direct (non-flood, routed) traffic. The default is lower because direct packets are addressed to a specific next hop, so far fewer nodes compete to retransmit them.
@@ -628,7 +628,7 @@ This document provides an overview of CLI commands that can be sent to MeshCore
- `set agc.reset.interval <value>`
**Parameters:**
- `value`: Interval in seconds rounded down to a multiple of 4 (17 becomes 16). 0 to disable.
- `value`: Interval in seconds, 0-1020, rounded down to a multiple of 4 (17 becomes 16). 0 to disable.
**Default:** `0.0`
@@ -654,7 +654,7 @@ This document provides an overview of CLI commands that can be sent to MeshCore
**Parameters:**
- `hours`: Interval in hours (3-168)
**Default:** `12` (Repeater) - `0` (Sensor)
**Default:** `47` (Repeater, Room Server) - `0`, disabled (Sensor)
---
@@ -666,7 +666,12 @@ This document provides an overview of CLI commands that can be sent to MeshCore
**Parameters:**
- `minutes`: Interval in minutes rounded down to the nearest multiple of 2 (61 becomes 60) (60-240)
**Default:** `0`
**Default:** `2` on a factory-fresh node, then `0` (disabled) once configured.
**Note:** A new install ships with a 2 minute zero-hop advert interval. Saving
any setting resets an interval below the 60 minute minimum to `0`, on the
assumption that the node has now been deliberately configured. To keep zero-hop
adverts running, set an explicit value in the 60-240 range.
---
docs/companion_protocol.md
+39 -15
View File
@@ -206,7 +206,7 @@ Byte 1: 0x03
**Command Format**:
```
Byte 0: 0x1F
Byte 1: Channel Index (0-7)
Byte 1: Channel Index (0 .. max_channels-1)
```
**Example** (get channel 1):
@@ -225,7 +225,7 @@ Byte 1: Channel Index (0-7)
**Command Format**:
```
Byte 0: 0x20
Byte 1: Channel Index (0-7)
Byte 1: Channel Index (0 .. max_channels-1)
Bytes 2-33: Channel Name (32 bytes, UTF-8, null-padded)
Bytes 34-49: Secret (16 bytes)
```
@@ -233,8 +233,12 @@ Bytes 34-49: Secret (16 bytes)
**Total Length**: 50 bytes
**Channel Index**:
- Index 0: Reserved for public channels (no secret)
- Indices 1-7: Available for private channels
- Valid range is `0` to `max_channels - 1`. Read `max_channels` from byte 3 of
the `PACKET_DEVICE_INFO` response; do not assume 8. Builds ship with
`MAX_GROUP_CHANNELS` set to 1, 8 or 40 depending on the board.
- Index 0: pre-populated by the firmware with the built-in "Public" channel.
It can be overwritten like any other slot.
- An out-of-range index is rejected with `PACKET_ERROR` / `ERR_CODE_NOT_FOUND`.
**Channel Name**:
- UTF-8 encoded
@@ -242,8 +246,18 @@ Bytes 34-49: Secret (16 bytes)
- Padded with null bytes (0x00) if shorter
**Secret Field** (16 bytes):
- For **private channels**: 16-byte secret
- For **public channels**: All zeros (0x00)
- Always a real 16-byte key; the firmware derives the channel hash from
`SHA256(secret)` (`BaseChatMesh.cpp:936-942`). There is no "no secret" form.
- Do **not** write an all-zero secret. `SHA256` over 16 zero bytes is a fixed,
globally identical value, so a zero-secret channel is a well-known channel
with an all-zero AES key that any node can read — not a private one. The
firmware skips *unnamed* slots when matching inbound group traffic for
exactly this reason (`BaseChatMesh.cpp:392-401`), but a slot that has been
given a name and a zero secret is not skipped, and will absorb null-key
group traffic from any node on the mesh.
- The built-in public channel uses the well-known key
`izOH6cXN6mrJ5e26oRXNcg==` (base64), i.e.
`8b3387e9c5cdea6ac9e5edbaa115cd72` in hex.
**Example** (create channel "YourChannelName" at index 1 with secret):
```
@@ -265,7 +279,7 @@ Bytes 34-49: Secret (16 bytes)
```
Byte 0: 0x03
Byte 1: 0x00
Byte 2: Channel Index (0-7)
Byte 2: Channel Index (0 .. max_channels-1)
Bytes 3-6: Timestamp (32-bit little-endian Unix timestamp, seconds)
Bytes 7+: Message Text (UTF-8, variable length)
```
@@ -288,7 +302,7 @@ Bytes 7+: Message Text (UTF-8, variable length)
**Command Format**:
```
Byte 0: 0x3E
Byte 1: Channel Index (0-7)
Byte 1: Channel Index (0 .. max_channels-1)
Byte 2: Path Length (0xFF = flood, otherwise actual path length)
Bytes 3 .. 2+path_len: Path (omitted when path_len == 0xFF)
Next 2 bytes (little-endian): Data Type (`data_type`, uint16)
@@ -306,13 +320,23 @@ Remaining bytes: Binary payload (variable length)
- Values `0x0001`–`0xFFFE` are available for registered application/community namespaces. See the [Registered data_type values](#registered-data_type-values) table below.
**Limits**:
- Maximum payload length is `MAX_CHANNEL_DATA_LENGTH = MAX_FRAME_SIZE - 9 = 163` bytes.
- Larger payloads are rejected with `PACKET_ERROR` (`ERR_CODE_ILLEGAL_ARG`).
- Maximum payload length is **165** bytes — `MAX_GROUP_DATA_LENGTH =
MAX_PACKET_PAYLOAD - CIPHER_BLOCK_SIZE - 3` (`src/MeshCore.h:21`). This is the
radio-side limit and the one clients should enforce.
- Two different bounds are checked, and they do not agree. The host-frame check
uses the larger `MAX_CHANNEL_DATA_LENGTH = MAX_FRAME_SIZE - 9 = 167`
(`companion_radio/MyMesh.cpp:1265`); the radio-side check uses 165
(`BaseChatMesh.cpp:544`).
- Payloads **above 167** are rejected with `ERR_CODE_ILLEGAL_ARG` (6).
- Payloads of **166 or 167** pass the frame check, then fail the radio-side
check and return `ERR_CODE_TABLE_FULL` (3). Despite that code's usual
meaning, such a send can never succeed — do not retry it. Keep payloads at
165 bytes or fewer and this case cannot arise.
**Response**: `PACKET_OK` (0x00) on success, or `PACKET_ERROR` (0x01) with one of:
- `ERR_CODE_NOT_FOUND` (2) — unknown `channel_idx`
- `ERR_CODE_ILLEGAL_ARG` (6) — invalid `path_len`, reserved `data_type` (`0x0000`), or payload larger than `MAX_CHANNEL_DATA_LENGTH`
- `ERR_CODE_TABLE_FULL` (3) — outbound send queue is full; retry later
- `ERR_CODE_ILLEGAL_ARG` (6) — invalid `path_len`, reserved `data_type` (`0x0000`), or payload larger than `MAX_CHANNEL_DATA_LENGTH` (167)
- `ERR_CODE_TABLE_FULL` (3) — outbound send queue is full (retry later), **or** a payload of 166-167 bytes that exceeds the radio-side limit (permanent; see Limits above)
**Inbound datagrams** are delivered to the host via `RESP_CODE_CHANNEL_DATA_RECV` (0x1B); see [Receive Channel Data Datagram](#receive-channel-data-datagram).
@@ -341,7 +365,7 @@ Inbound group datagrams (radio-level `PAYLOAD_TYPE_GRP_DATA`, 0x06) are forwarde
Byte 0: 0x1B (packet type)
Byte 1: SNR (signed int8, scaled ×4 — divide by 4.0 to recover dB)
Bytes 2-3: Reserved (clients MUST ignore)
Byte 4: Channel Index (0-7)
Byte 4: Channel Index (0 .. max_channels-1)
Byte 5: Path Length (actual path length when flooded, otherwise 0xFF for direct)
Bytes 6-7: Data Type (uint16 little-endian)
Byte 8: Data Length
@@ -550,7 +574,7 @@ def parse_contact_message(data):
**Standard Format** (`PACKET_CHANNEL_MSG_RECV`, 0x08):
```
Byte 0: 0x08 (packet type)
Byte 1: Channel Index (0-7)
Byte 1: Channel Index (0 .. max_channels-1)
Byte 2: Path Length
Byte 3: Text Type
Bytes 4-7: Timestamp (32-bit little-endian)
@@ -562,7 +586,7 @@ Bytes 8+: Message Text (UTF-8)
Byte 0: 0x11 (packet type)
Byte 1: SNR (signed byte, multiplied by 4)
Bytes 2-3: Reserved
Byte 4: Channel Index (0-7)
Byte 4: Channel Index (0 .. max_channels-1)
Byte 5: Path Length
Byte 6: Text Type
Bytes 7-10: Timestamp (32-bit little-endian)
docs/faq.md
+9 -9
View File
@@ -537,18 +537,18 @@ Mac: python3 should be already installed.
Then it should be the same for all platforms:
```
python3 -m venv meshcore
cd meshcore && source bin/activate
python3 -m venv meshcore-venv
cd meshcore-venv && source bin/activate
pip install -U platformio
git clone https://github.com/ripplebiz/MeshCore.git
cd MeshCore
git clone https://github.com/meshcore-dev/meshcore.git
cd meshcore
```
open platformio.ini and in `[arduino_base]` edit the `LORA_FREQ=867.5`
save, then run:
open platformio.ini and in `[arduino_base]` edit `LORA_FREQ` (it defaults to
`869.618`) to the frequency for your region, save, then run:
```
pio run -e RAK_4631_Repeater
pio run -e RAK_4631_repeater
```
then you'll find `firmware.zip` in `.pio/build/RAK_4631_Repeater`
then you'll find `firmware.zip` in `.pio/build/RAK_4631_repeater`
### 5.10. Q: Are there other MeshCore related open source projects?
@@ -592,7 +592,7 @@ For ESP-based devices (e.g. Heltec V3) you need:
1. Download the firmware file from <https://flasher.meshcore.io>.
- Go to the website in a browser and find the section that has the firmware you need.
- Click the Download button, right-click on the file you need, for example:
- `Heltec_V3_companion_radio_ble-v1.7.1-165fb33.bin`
- `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 and existing Bluetooth pairing database, but keeps configurations.
docs/kiss_modem_protocol.md
+8 -8
View File
@@ -18,10 +18,10 @@ Standard KISS framing per the KA9Q/K3MC specification.
| `0xDD` | TFESC | Escaped FESC (FESC + TFESC = 0xDB) |
```
┌──────┬───────────┬──────────────┬──────┐
│ FEND │ Type Byte │ Data (escaped)│ FEND │
│ 0xC0 │ 1 byte │ 0-510 bytes │ 0xC0 │
└──────┴───────────┴──────────────┴──────┘
┌──────┬───────────┬────────────────┬──────┐
│ FEND │ Type Byte │ Data (escaped) │ FEND │
│ 0xC0 │ 1 byte │ 0-510 bytes │ 0xC0 │
└──────┴───────────┴────────────────┴──────┘
```
### Type Byte
@@ -82,10 +82,10 @@ MeshCore-specific functionality uses the standard KISS SetHardware command. The
### Frame Format
```
┌──────┬──────┬─────────────┬──────────────┬──────┐
│ FEND │ 0x06 │ Sub-command │ Data (escaped)│ FEND │
│ 0xC0 │ │ 1 byte │ variable │ 0xC0 │
└──────┴──────┴─────────────┴──────────────┴──────┘
┌──────┬──────┬─────────────┬────────────────┬──────┐
│ FEND │ 0x06 │ Sub-command │ Data (escaped) │ FEND │
│ 0xC0 │ │ 1 byte │ variable │ 0xC0 │
└──────┴──────┴─────────────┴────────────────┴──────┘
```
### Request Sub-commands (Host to TNC)
docs/nrf52_power_management.md
+9 -1
View File
@@ -193,11 +193,19 @@ Power management status can be queried via the CLI:
| `get pwrmgt.bootreason` | Returns reset and shutdown reason strings |
| `get pwrmgt.bootmv` | Returns boot voltage in millivolts |
On boards without power management enabled, all commands except `get pwrmgt.support` return:
On boards without power management enabled, `get pwrmgt.source` and
`get pwrmgt.bootmv` return:
```
ERROR: Power management not supported
```
`get pwrmgt.support` returns `unsupported`. `get pwrmgt.bootreason` is not
compiled out at all and answers on every board: `getResetReason()` and
`getShutdownReason()` are virtuals on the base board class, so a board that
does not override them reports `Not available` rather than an error. ESP32
boards override the reset half with `esp_reset_reason()`, so they return a real
reset reason and `Not available` for the shutdown reason.
## Debug Output
When `MESH_DEBUG=1` is enabled, the power management module outputs:
docs/number_allocations.md
+1
View File
@@ -19,6 +19,7 @@ Once you have a working app/project, you need to be able to demonstrate it exist
| 0110 - 011F | Ripple | ripple_biz@protonmail.com — https://buymeacoffee.com/ripplebiz |
| 0120 | MCO Advanced | most.original.address@gmail.com — https://hdden.ru/MCOa/ |
| 0130 - 013F | StreamSensor | william@housedillon.com - https://housedillon.com/blog/lora-e5-with-seeed-fusion |
| 0140 | Nelos | support@nelos.app — https://nelos.app |
| FF00 - FFFF | -reserved for testing/dev- | |
(add rows, inside the range 0100 - FEFF for custom apps)
docs/payloads.md
+46 -9
View File
@@ -93,6 +93,7 @@ Returned path messages provide a description of the route a packet took from the
| Field | Size (bytes) | Description |
|--------------|-----------------|------------------------------------------|
| timestamp | 4 | sender time (unix timestamp) |
| req type | 1 | request sub type |
| request data | rest of payload | application-defined request payload body |
For the common chat/server helpers in `BaseChatMesh`, the current request type values are:
@@ -100,7 +101,13 @@ For the common chat/server helpers in `BaseChatMesh`, the current request type v
| Value | Name | Description |
|--------|-----------|----------------------------------------------------|
| `0x01` | get stats | get stats of repeater or room server |
| `0x02` | keepalive | keep-alive request used for maintained connections |
| `0x02` | keepalive | (deprecated) |
| `0x03` | get telemetry | request node telemetry |
| `0x04` | get min/max/avg | get sensor node stats on time series data |
| `0x05` | get acl | node ACL query |
| `0x06` | get neighbors | node neighbors query |
| `0x08` | subscribe | subscribe to telemetry push |
| `0x09` | ubsubscribe | unsubscribe from telemetry push |
#### Get stats
@@ -125,21 +132,50 @@ Gets information about the node, possibly including the following:
* Number posted (?)
* Number of post pushes (?)
#### Get telemetry data
Not defined in `BaseChatMesh`. Sensor- and application-specific request payloads may be implemented by higher-level firmware.
#### Get Telemetry
Not defined in `BaseChatMesh`.
| Field | Size (bytes) | Description |
|----------------|--------------|------------------------------|
| timestamp | 4 | sender time (unix timestamp) |
| req type | 1 | 0x03 (request sub type) |
| permission mask | 1 | bitwise inverse mask to AND to permissions (0 = get ALL telem values) |
#### Get Min/Max/Ave (Sensor nodes)
Not defined in `BaseChatMesh`.
| Field | Size (bytes) | Description |
|----------------|--------------|------------------------------|
| timestamp | 4 | sender time (unix timestamp) |
| req type | 1 | 0x04 (request sub type) |
| start | 4 | starting time, seconds ago |
| end | 4 | ending time, seconds ago |
| reserved | 2 | should be zeroes |
#### Subscribe to Telemetry push - (Sensor nodes)
| Field | Size (bytes) | Description |
|----------------|--------------|------------------------------|
| timestamp | 4 | sender time (unix timestamp) |
| req type | 1 | 0x08 (request sub type) |
| push tag | 4 | 32-bit tag to be used in telemetry push _REPLY payloads |
| timeout secs | 2 | subscription timeout (seconds) |
| reserved | 1 | should be zero |
| min deltas len | 1 | byte length of LPP encoded min_deltas |
| min deltas | (variable) | LPP encoded min_deltas |
#### Unsubscribe from Telemetry push - (Sensor nodes)
| Field | Size (bytes) | Description |
|----------------|--------------|------------------------------|
| timestamp | 4 | sender time (unix timestamp) |
| req type | 1 | 0x09 (request sub type) |
#### Get Access List
Not defined in `BaseChatMesh`.
| Field | Size (bytes) | Description |
|----------------|--------------|------------------------------|
| timestamp | 4 | sender time (unix timestamp) |
| req type | 1 | 0x05 (request sub type) |
| reserved | 2 | should be zeroes |
#### Get Neighbors
@@ -171,8 +207,9 @@ txt_type
| Value | Description | Message content |
|--------|---------------------------|--------------------------------------------------------------------------|
| `0x00` | plain text message | the plain text of the message |
| `0x01` | CLI command | the command text of the message |
| `0x01` | CLI data | CLI command OR reply text |
| `0x02` | signed plain text message | first four bytes is sender pubkey prefix, followed by plain text message |
| `0x03` | CLI command | (since v1.18+) CLI command text (explicit) |
## Anonymous request
docs/radio_presets.md
+66
View File
@@ -0,0 +1,66 @@
# Radio Presets
The radio presets are currently stored on the MeshCore App API server.
This allows us to update the presets without releasing new application updates.
The presets can be fetched from [https://api.meshcore.nz/api/v1/config](https://api.meshcore.nz/api/v1/config)
If you'd like a new radio preset to be added, this will need to be brought up for discussion in the [MeshCore Discord](https://meshcore.gg) server, or via the [issues section](https://github.com/meshcore-dev/MeshCore/issues) in our GitHub repo.
Before a new preset will be considered for being added, local radio regulations must be researched by the person suggesting the preset, and investigation of the frequencies with an SDR is advised to ensure the least interference to provide a decent user experience.
Once a preset is added, it's unlikely to be changed. Adding too many presets can lead to user frustration, as new users won't know which preset to select during setup.
At this time, presets provided by the MeshCore App API are just suggestions, but you are free to configure any radio settings through the companion applications, provided they comply with local laws/regulations.
> Note: We are planning to implement deep linking such as meshcore:// URLs, and QR codes so local mesh networks can easily distribute their own settings, without relying on the internet, or all the companion applications to provide all the settings.
## JSON Response
See the example JSON response below, which shows the expected format provided by the API server.
Your application should be programmed to expect any of the JSON keys to be missing from the response, as the format could change at any time without any notification.
Please configure an appropriate User Agent header string when sending your request to the server. We should be able to reach out to you if needed.
> Note: Some presets contain an optional `network_settings` section which defines the `path_hash_size` to use for this mesh network.
```json
{
"config": {
"suggested_radio_settings": {
"info_message": "These presets are suggested by the community.",
"entries": [
{
"title": "Australia (Narrow)",
"description": "916.575MHz / SF7 / BW62.5 / CR7",
"frequency": "916.575",
"spreading_factor": "7",
"bandwidth": "62.5",
"coding_rate": "7"
},
{
"title": "New Zealand (Narrow)",
"description": "917.375MHz / SF7 / BW62.5 / CR5 / 2B",
"frequency": "917.375",
"spreading_factor": "7",
"bandwidth": "62.5",
"coding_rate": "5",
"network_settings": {
"path_hash_size": 2
}
},
{
"title": "Portugal 868",
"description": "869.618MHz / SF7 / BW62.5 / CR6",
"frequency": "869.618",
"spreading_factor": "7",
"bandwidth": "62.5",
"coding_rate": "6"
}
]
}
}
}
```
docs/terminal_chat_cli.md
+13 -6
View File
@@ -27,15 +27,17 @@ set lon {longitude}
```
Sets your advertisement map longitude. (decimal degrees)
```
set dutycycle {percent}
```
Sets the transmit duty cycle limit (1-100%). Example: `set dutycycle 10` for 10%.
```
set af {air-time-factor}
```
Sets the transmit air-time-factor. Deprecated — use `set dutycycle` instead.
Sets the transmit air-time-factor.
> **Note:** `set dutycycle` is *not* available in Terminal Chat. Every other
> firmware — Repeater, Room Server, Sensor and Companion Radio — routes its
> `set`/`get` commands through the shared radio prefs handler and does support
> it (see [CLI Commands](./cli_commands.md)). Terminal Chat is the sole
> exception: it has its own inline `set` handler covering only the six options
> listed above.
```
@@ -99,3 +101,8 @@ Resets the path to current recipient, for new path discovery.
public {text}
```
Sends the text message to the built-in 'public' group channel
```
help
```
Lists the available commands.