From 077ebeb85ee4d35a58c2fa1de9c3789e58cd5a48 Mon Sep 17 00:00:00 2001
From: mikecarper <mikecarper@users.noreply.github.com>
Date: Fri, 4 Sep 2026 09:05:18 +0000
Subject: [PATCH] deploy: 69d9d9e62a0ebf83b98d71e9794893e1aac57534

---
 cli_command_availability/index.html      |  4 ++
 cli_commands/index.html                  |  4 +-
 hardware_validation_checklist/index.html | 52 +++++++++++++++++++-----
 search/search_index.json                 |  2 +-
 4 files changed, 49 insertions(+), 13 deletions(-)

diff --git a/cli_command_availability/index.html b/cli_command_availability/index.html
index 3e0a1ec7..0c875ecb 100644
--- a/cli_command_availability/index.html
+++ b/cli_command_availability/index.html
@@ -1833,6 +1833,10 @@ over the normal binary USB, BLE, or TCP connection:</p>
 <td><a href="../cli_commands/#view-or-change-the-independent-bluetooth-name-companion"><code>get/set bluetooth.name</code></a></td>
 <td>Companion firmware</td>
 </tr>
+<tr>
+<td><a href="../cli_commands/#enter-the-uf2-bootloader-nrf52-only"><code>uf2reset</code></a></td>
+<td>Every nRF52 Companion text terminal and local command <code>0x42</code>; local only</td>
+</tr>
 </tbody>
 </table>
 <p>Deprecated binary aliases remain receive-only for older clients; new clients
diff --git a/cli_commands/index.html b/cli_commands/index.html
index e8cd51de..28e955c8 100644
--- a/cli_commands/index.html
+++ b/cli_commands/index.html
@@ -5341,7 +5341,9 @@ arguments such as node names, passwords, and keys is left unchanged.</p>
 <p><strong>Usage:</strong>
 - <code>uf2reset</code></p>
 <p><strong>Serial Only:</strong> Yes</p>
-<p><strong>Note:</strong> Reboots directly into the UF2 bootloader on supported nRF52 boards.</p>
+<p><strong>Note:</strong> Reboots directly into the UF2 bootloader on supported nRF52 boards.
+This includes the Repeater, Room Server, Sensor, Companion, and Terminal Chat
+local serial command surfaces. It is never accepted as a remote mesh command.</p>
 <hr />
 <h3 id="reset-the-clock-and-reboot">Reset the clock and reboot</h3>
 <p><strong>Usage:</strong>
diff --git a/hardware_validation_checklist/index.html b/hardware_validation_checklist/index.html
index 2b4cf8d9..fb8af85e 100644
--- a/hardware_validation_checklist/index.html
+++ b/hardware_validation_checklist/index.html
@@ -724,10 +724,10 @@
     <ul class="md-nav__list" data-md-component="toc" data-md-scrollfix>
       
         <li class="md-nav__item">
-  <a href="#current-marathon-ledger-through-2026-09-01" class="md-nav__link">
+  <a href="#current-marathon-ledger-through-2026-09-04" class="md-nav__link">
     <span class="md-ellipsis">
       
-        Current marathon ledger (through 2026-09-01)
+        Current marathon ledger (through 2026-09-04)
       
     </span>
   </a>
@@ -1512,10 +1512,10 @@
     <ul class="md-nav__list" data-md-component="toc" data-md-scrollfix>
       
         <li class="md-nav__item">
-  <a href="#current-marathon-ledger-through-2026-09-01" class="md-nav__link">
+  <a href="#current-marathon-ledger-through-2026-09-04" class="md-nav__link">
     <span class="md-ellipsis">
       
-        Current marathon ledger (through 2026-09-01)
+        Current marathon ledger (through 2026-09-04)
       
     </span>
   </a>
@@ -1701,7 +1701,7 @@
 when its log identifies the physical device, firmware artifact, artifact hash,
 command result, and cold/warm boot outcome. Do not infer success from a tool's
 exit code when the tool has a documented false-success mode.</p>
-<h2 id="current-marathon-ledger-through-2026-09-01">Current marathon ledger (through 2026-09-01)</h2>
+<h2 id="current-marathon-ledger-through-2026-09-04">Current marathon ledger (through 2026-09-04)</h2>
 <table>
 <thead>
 <tr>
@@ -1715,14 +1715,14 @@ exit code when the tool has a documented false-success mode.</p>
 <tr>
 <td>Seeed XIAO nRF52840</td>
 <td><code>B35E71C1C3726CE7</code></td>
-<td>A stalled Companion transport survived the stop token and exact USB reset, then recovered after a 36-second exact application DFU. Current Full Companion USB, bonded BLE, clock sync, terminal/Binary switching, serial-mOTA folder attach, and reversible dual-CDC logging all pass</td>
-<td>Prove current-build cold persistence; separately reproduce the stall before using a power cut to test whether power alone clears it; then transfer an actual image through BLE-controlled LoRa OTA</td>
+<td>OTAFIX candidate <code>0x02040405</code> passed exact serial install and corrected Legacy DIS model gates; the patched Bluetooth repeater-updater application was restored over BLE and returned as exact <code>2886:8044</code> USB</td>
+<td>Use the updater for an identity-gated Bluetooth transfer to another repeater, then prove current-build cold persistence</td>
 </tr>
 <tr>
 <td>Seeed Tracker T1000-E</td>
 <td><code>34A9141999729D5D</code></td>
-<td>A temporary Full Companion and one of two same-visible-version OTAFIX candidates are running; the exact candidate bytes are not yet proven. The bonded warm baseline passed at 3.34 kB/s. Two lab-only pre-START 15 ms/latency-0 DFUs with <code>0/0</code> no-preference event-length hints passed at 6.23 and 6.52 kB/s; a 10 ms event-length control timed out before START</td>
-<td>Prove installed bootloader bytes by readback, exercise a physical cold 20-to-244-byte readiness transition, restore the protected Repeater identity, cold boot, then force LR1110 reset</td>
+<td>OTAFIX candidate <code>0x02040405</code> and the <code>uf2reset</code>-fixed Full Companion are installed. The real text command returned exact <code>2886:0057</code> boot USB, the same fixed app was restored, and refreshed bonded BLE services pass as <code>MeshCore-09848C15</code></td>
+<td>Restore the protected Repeater identity when Companion qualification is complete; cold boot, then force LR1110 reset</td>
 </tr>
 <tr>
 <td>RAK3401</td>
@@ -1733,13 +1733,13 @@ exit code when the tool has a documented false-success mode.</p>
 <tr>
 <td>Heltec T096</td>
 <td><code>651F8E496197F882</code></td>
-<td>OTAFIX HIL candidate <code>0x02040401</code>, serial DFU, signed LoRa bootloader OTA, warm-watchdog recovery, physical power-removal cold persistence, bonded Legacy BLE application DFU, serial mOTA ownership, button/display wake, and Full Companion dual-CDC reconnect checks pass on <code>keymindCascade</code> <code>fcd1f8cc</code>. The final T096-only no-footer Full Companion image is installed</td>
+<td>OTAFIX candidate <code>0x02040405</code> and the <code>uf2reset</code>-fixed no-footer Full Companion are installed. The real text command returned exact boot USB, and final USB terminal/Binary mode, dual CDC, version, help, and BLE identity pass</td>
 <td>Perform a privileged or physical host-driven USB bus reset without resetting the MCU; complete the deferred multi-click/long-press physical matrix</td>
 </tr>
 <tr>
 <td>Heltec MeshTower V2 with SD</td>
 <td><code>9352162A72082314</code></td>
-<td>Exact SD LoRa-OTA Repeater <code>e26d48e4</code> is running after identity-gated BLE recovery. Card format/cooldown/forced-format/raw-erase/remount pass; live bootloader contract reports ABI 3, FULL+INPLACE, and SD apply</td>
+<td>OTAFIX candidate <code>0x02040405</code> passed serial combined install, the historical cached DIS handles, BLE application restore, and exact application USB return. Card format/cooldown/forced-format/raw-erase/remount and the live SD apply contract passed earlier</td>
 <td>Signed interrupted-download resume, corruption/signature rejection, then full/delta apply</td>
 </tr>
 <tr>
@@ -2365,6 +2365,26 @@ network, and reboot record in that manifest.</p>
 </ul>
 <h2 id="seeed-tracker-t1000-e">Seeed Tracker T1000-E</h2>
 <ul>
+<li>[x] The cross-role <code>uf2reset</code> repair was hardware-qualified with Full
+      Companion ZIP SHA-256
+      <code>16e470c0d66bec14e1e9f2d4ebe04d83ffb30efa606465f885cbe9fc3d004a14</code>.
+      It was built from <code>f2c15225</code> with GCC 14.2.1, the USA Cascadia/Cascade
+      profile, and embedded version
+      <code>v1.17.1-uf2reset-f2c15225-f2c15225</code>. Serial DFU took 32.196 seconds and
+      stable application USB returned in 35.888 seconds. Terminal entry,
+      version, help, the exact no-argument command, application disconnect, and
+      stable <code>2886:0057</code> boot USB all passed in one 8.898-second script. The same
+      image was restored in 32.204 seconds and stable <code>239a:8029</code> USB returned
+      in 36.313 seconds; a final terminal check returned Binary mode cleanly.</li>
+<li>[x] The fixed application advertises live as <code>MeshCore-09848C15</code> at
+      <code>D1:A0:86:CD:BB:C6</code>. The obsolete Pi bond for the earlier temporary
+      identity was removed, and the exact address was paired again with the
+      qualification PIN. Paired, bonded, and trusted state, an encrypted BLEDfu
+      revision read, and the Nordic UART service all passed. The pre-run old
+      application enumerated but produced neither a terminal response nor a
+      live advertisement, so this run does not claim continuity of that
+      temporary identity or of application-owned settings across a combined
+      SoftDevice/bootloader recovery install.</li>
 <li>[x] Stable application identity <code>34A9141999729D5D</code> is recorded and is not
       confused with the RAK3401 even though both currently enumerate with USB
       product ID <code>239a:8029</code>. Application is <code>239a:8029</code>; the exercised
@@ -2667,6 +2687,16 @@ network, and reboot record in that manifest.</p>
 </ul>
 <h2 id="heltec-t096">Heltec T096</h2>
 <ul>
+<li>[x] The cross-role <code>uf2reset</code> repair was hardware-qualified on the exact
+      no-footer Full Companion image. ZIP SHA-256 is
+      <code>0585bee1c0b278a68788f78af384bcbdb5633d57f9ea301fc14f1c80c4275489</code>;
+      embedded version is <code>v1.17.1-uf2reset-f2c15225-f2c15225</code>. Terminal entry
+      and help passed, the exact command disconnected application USB in
+      1.031 seconds, and stable boot USB returned in 2.026 seconds. The final
+      Full image installed over serial in 38.900 seconds and stable application
+      USB returned in 41.672 seconds. Final primary terminal/Binary switching,
+      dedicated logging interface, version, help entry, and live
+      <code>MeshCore-8E229D0A</code> advertisement at <code>CF:A8:18:36:DE:8B</code> all passed.</li>
 <li>[x] Stable USB serial <code>651F8E496197F882</code> distinguishes the application
       (<code>239A:8029</code>) from the OTAFIX serial-DFU interface. Every flash followed
       that identity across the host-assigned <code>COM9 -&gt; COM6 -&gt; COM9</code> transition;
diff --git a/search/search_index.json b/search/search_index.json
index d9f6a507..d7db0aef 100644
--- a/search/search_index.json
+++ b/search/search_index.json
@@ -1 +1 @@
-{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"],"fields":{"title":{"boost":1000.0},"text":{"boost":1.0},"tags":{"boost":1000000.0}}},"docs":[{"location":"","title":"Introduction","text":"<p>Welcome to the MeshCore documentation.</p> <p>Below are a few quick start guides.</p> <ul> <li>Frequently Asked Questions</li> <li>Firmware Picker</li> <li>CLI Commands</li> <li>LoRa CLI Host Service</li> <li>Filter Policy Playground</li> <li>Telemetry Decoder</li> <li>CLI Availability by Firmware Build</li> <li>Easy LoRa OTA: ESP32 and nRF52 firmware updates</li> <li>Scripted LoRa OTA: Bash and PowerShell</li> <li>nRF52 repeater OTA with external QSPI</li> <li>nRF52 bootloader updates over LoRa</li> <li>MeshTower V2 microSD self-updates</li> <li>GPS Tracking</li> <li>Companion Protocol</li> <li>Companion Offline Message Queue</li> <li>Full Companion: ESP32 and nRF52</li> <li>Full Companion USB CLI and binary switcher</li> <li>Packet Format</li> <li>QR Codes</li> </ul> <p>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.</p> <ul> <li>Documentation Source</li> </ul>"},{"location":"WiFi/","title":"WiFi and MQTT by Firmware Type","text":"<p>MeshCore itself does not require WiFi or the internet. LoRa packet exchange, repeating, room servers, companions, and sensors can all operate without either. WiFi is added by particular ESP32 firmware targets for one or more of these purposes:</p> <ul> <li>a TCP connection between a WiFi companion and a phone or computer;</li> <li>the WebConfig browser interface;</li> <li>MQTT uplinking from the radio to internet or LAN brokers;</li> <li>WiFi-assisted OTA services on builds that include them;</li> <li>ESP-NOW bridging, which uses the ESP32's 2.4 GHz radio but is not a connection   to a WiFi access point.</li> </ul> <p>The firmware role and the build profile are separate choices. For example, a logging repeater is not an MQTT observer, and a WiFi companion does not publish to MQTT unless its target name also contains <code>mqtt</code>.</p>"},{"location":"WiFi/#quick-reference","title":"Quick reference","text":"Firmware target or role Infrastructure WiFi MQTT What WiFi does <code>*_repeater</code> Build-dependent on ESP32 No FULL builds provide WebConfig, browser OTA, and the TCP 5001 LoRa-OTA seeder while WiFi is active <code>*_repeater_observer_mqtt</code> Yes Yes Uplinks heard and selected transmitted LoRa packets; repeating remains enabled by default <code>*_room_server</code> Build-dependent on ESP32 No FULL builds provide WebConfig, browser OTA, and the TCP 5001 LoRa-OTA seeder while WiFi is active <code>*_room_server_observer_mqtt</code> Yes Yes Runs the room server and uplinks radio traffic <code>*_companion_radio_wifi</code> Yes No Exposes the MeshCore companion protocol on TCP port 5000 <code>*_companion_radio_wifi_mqtt</code> Yes Yes Runs both the TCP companion interface and the MQTT uplink USB, BLE, or serial companion No No Uses the transport named by the target instead <code>*_repeater_bridge_espnow</code> Build-dependent on ESP32 No Uses ESP-NOW for its bridge; <code>bridge.format wrapped|raw</code> selects legacy bridge framing or primary-ESP-NOW compatibility; a FULL build also exposes the TCP 5001 LoRa-OTA seeder whenever WiFi is usable RS232 bridge No No Bridges through a serial interface Ethernet repeater/room server No WiFi No Uses wired Ethernet for its role-specific network interface <code>*_sensor</code> Build-dependent on ESP32 No A FULL ESP32 sensor can expose the TCP 5001 LoRa-OTA seeder through its browser-OTA setup AP Terminal-chat or KISS modem No in current targets No Uses LoRa and its role-specific local interface <code>*_lora_ota_no_external_sensors</code> On demand on ESP32 No Lean LoRa-OTA repeater image; ESP32 builds retain the compact <code>start ota</code> browser uploader <p>Direct on-device WiFi and MQTT are currently ESP32 features. nRF52, STM32, and the currently enabled RP2040 targets do not run this MQTT bridge. An nRF52 connected to a Raspberry Pi can still be logged or uplinked by software on the Pi, but that is a separate host-side bridge rather than MQTT running in the radio firmware.</p>"},{"location":"WiFi/#how-the-mqtt-bridge-works","title":"How the MQTT bridge works","text":"<p>The MQTT bridge is an outbound observer. It does not subscribe to MQTT topics and does not inject broker messages into LoRa.</p> <p>For a received packet, the flow is:</p> <pre><code>LoRa radio -&gt; successful packet parse -&gt; MQTT capture queue -&gt; broker slots\n                                  \\----&gt; normal MeshCore filtering/handling\n</code></pre> <p>Packets transmitted by the node can also be queued according to <code>mqtt.tx</code>. Receive capture happens before the packet is passed to the normal MeshCore flood filters and forwarding decision. A packet may therefore be observed on MQTT even when a later scope, path, region, duplicate, or repeat rule prevents the node from forwarding it over LoRa.</p> <p>MQTT publication and LoRa repetition are separate:</p> <ul> <li><code>set repeat on|off</code> controls whether an observer repeats eligible LoRa   packets;</li> <li><code>set bridge.enabled on|off</code> starts or stops the MQTT bridge;</li> <li><code>set mqtt.rx on|off</code> controls uplinking of received packets;</li> <li><code>set mqtt.tx off|advert|on</code> controls uplinking of transmitted packets.</li> </ul> <p>Fresh MQTT observer settings are:</p> <ul> <li>bridge and repeating enabled;</li> <li>received packet uplinking enabled;</li> <li>transmitted packet uplinking set to <code>advert</code>, meaning only the node's own   adverts are included;</li> <li>packet and status publishing enabled;</li> <li>raw publishing disabled;</li> <li>slot 1 set to <code>analyzer-us</code>;</li> <li>slot 2 set to <code>analyzer-eu</code>;</li> <li>slots 3 through 6 disabled;</li> <li>WiFi modem power saving set to <code>min</code> in the Cascade profile and <code>none</code> in   target-default builds;</li> <li>WiFi SSID and IATA code empty.</li> </ul> <p>Up to six broker configurations can be saved. The number that can be active at once depends on the target and available memory. A non-PSRAM ESP32 should normally use no more than two TLS/WSS brokers; some classic ESP32 targets are reliable with only one. Excess configured slots remain saved but show as inactive in <code>get mqtt.status</code>.</p> <p>The bridge has a bounded packet queue for broker or WiFi outages and reconnects automatically. A non-PSRAM build holds 6 packets and a PSRAM build holds 50. When the queue is full, the oldest item is replaced; after five minutes with no broker connected, stale queued packets are flushed. MQTT packet delivery is best effort rather than durable storage. Each enabled slot publishes independently, so one failed broker does not intentionally stop the other slots.</p> <p>See MQTT_IMPLEMENTATION.md for the complete preset list, custom broker configuration, topic formats, authentication, diagnostics, and memory limits.</p>"},{"location":"WiFi/#mqtt-observer-setup","title":"MQTT observer setup","text":"<p>Most full-size ESP32 MQTT observer builds have the shared WebConfig portal. On a fresh device with no saved SSID:</p> <ol> <li>Join the open <code>MeshCore-Setup-XXXX</code> access point.</li> <li>If the captive page does not open, browse to <code>http://192.168.4.1/</code>.</li> <li>Enter WiFi, radio, identity, and MQTT settings.</li> <li>Select Save &amp; Reboot.</li> <li>After reboot, check <code>get wifi.status</code> and <code>get mqtt.status</code>.</li> </ol> <p>The setup AP is unauthenticated unless the firmware was built with <code>WEBCONFIG_AP_PASSWORD</code>. It uses plain HTTP, so provision it in a trusted location. When WebConfig is running on the normal LAN, repeater and room-server builds require the node's admin password.</p> <p>On an expanded FULL profile with no saved SSID, this automatic setup AP has an absolute 30-minute window. Browser activity or a phone left associated with the AP does not extend it. If no SSID has been saved when the window expires, WebConfig closes and the ESP32 WiFi radio remains off automatically for the remainder of that boot. A reboot or power cycle starts a new 30-minute setup window; the timeout is deliberately not written to preferences. An administrator can still override the automatic cutoff with an explicit <code>start webconfig</code> command.</p> <p>Once an SSID is saved, the provisioning cutoff no longer applies. When WiFi is selected by <code>logging.output wifi|both</code>, the station stays enabled and keeps trying the saved network indefinitely: ESP automatic reconnect remains on and the explicit fallback advances through 15, 30, 60, 120, then 300-second retry intervals, remaining at five minutes until it reconnects. MQTT broker retries use their own backoff; a repeatedly failing broker eventually receives one probe every 30 minutes. Selecting <code>logging.output off|usb</code> keeps the MQTT bridge off, so saved credentials alone do not force WiFi on unless WebConfig is also enabled explicitly.</p> <p>The equivalent MQTT observer CLI setup is:</p> <pre><code>set wifi.ssid Your WiFi Name\nset wifi.pwd Your WiFi Password\nset mqtt.iata SEA\nset name MyObserver\nreboot\n</code></pre> <p>The SSID and password values are the rest of the command line. Spaces are allowed and quotes must not be added. SSIDs may contain at most 31 characters and passwords at most 63. Leave the password value empty for an open network.</p> <p>Useful checks are:</p> <pre><code>get wifi.ssid\nget wifi.status\nget wifi.powersave\nget wifi.cli\nget bridge.enabled\nget mqtt.rx\nget mqtt.tx\nget mqtt.status\nget mqtt1.diag\nget mqtt2.diag\n</code></pre> <p>To change a configured observer through WebConfig without leaving the portal enabled after every reboot:</p> <pre><code>start webconfig\n</code></pre> <p>This uses the LAN when WiFi is connected. To force the setup AP, the MQTT bridge must release WiFi first:</p> <pre><code>set bridge.enabled off\nstart webconfig ap\n</code></pre> <p>After provisioning, use Save &amp; Reboot, or stop the temporary portal and restart the bridge:</p> <pre><code>stop webconfig\nset bridge.enabled on\n</code></pre> <p>Current MQTT observer artifacts use the expanded FULL partition profile so WebConfig and the complete role CLI are retained. Install the matching merged image over USB once when moving a device from the legacy partition layout.</p>"},{"location":"WiFi/#wifi-companion-setup","title":"WiFi companion setup","text":"<p>A <code>*_companion_radio_wifi</code> build replaces the BLE or USB companion link with the MeshCore companion protocol over TCP port 5000. The phone or computer must be able to reach the device on the same LAN.</p> <p>Most ESP32 <code>*_companion_radio_full</code> targets keep all three Companion links at once: USB, BLE, and TCP port 5000. The two SenseCAP Indicator Full targets are the exception: USB remains available, while a saved next-boot selector starts exactly one secondary wireless Companion transport, either BLE or infrastructure WiFi/TCP. On the ESP-NOW Indicator, this selector never stops the primary ESP-NOW mesh radio. Full ESP32 images also provide a source-only LoRa mOTA service on ports 5001 and 5002 whenever their WiFi transport is active. See the full Companion guide for its build, terminal mode, and complete update-source workflow.</p> <p>The LilyGo T-Beam 1W Full Companion maps one press of the physical <code>BOOT</code> button (GPIO0) to a persistent WiFi on/off toggle. Turning WiFi off closes WebConfig, Companion TCP, mOTA, and MQTT network services while USB, BLE, the display, GPS, and LoRa remain available. Another BOOT press turns WiFi back on even after reboot. WiFi/WebConfig starts first; BLE starts two seconds later so the ESP32-S3 can reserve the setup server's internal heap before both radios run together.</p> <p>The companion loads runtime credentials saved in NVS. A non-placeholder compile-time <code>WIFI_SSID</code>/<code>WIFI_PWD</code> can be used as a first-boot fallback, but saved credentials take priority. With no credentials, its WebConfig portal starts in setup-AP mode. With credentials, the WebUI is enabled by default on the station IP.</p> <p>Full Companion can also be provisioned from its USB terminal or TCP port 5002:</p> <pre><code>get wifi.ssid\nget wifi.status\nset wifi.ssid SlowFi\nset wifi.pwd your-password\n</code></pre> <p>Credential writes are persisted immediately. After the reply has drained, the Companion restarts its WiFi station with the saved pair. A port-5002 client is expected to disconnect and can reconnect at the new LAN IP. USB masks the password as it is entered; <code>get wifi.pwd</code> is intentionally unavailable. The standalone credential store accepts an empty password, ordinary passphrases up to 63 characters, or an exact 64-character hexadecimal WPA/WPA2 PSK. A non-hexadecimal 64-character value and every longer value are rejected.</p> <p>After the saved station first connects following boot, every ESP32 WiFi Companion requests a fresh UTC time from NTP. A verified reply updates both the MeshCore clock and any detected hardware RTC; the next explicit refresh is due 24 hours after that success. A failed request times out without blocking the radio loop and retries after five minutes. While WiFi is disconnected or only the setup AP is available, the request waits for a station connection. Builds with a configured MQTT bridge use its boot-and-daily NTP owner instead, so two firmware services never reconfigure the ESP32 SNTP client at the same time. A later WiFi reconnect does not add another successful-sync request; it preserves the existing 24-hour deadline. Until a fresh internet reply succeeds, LoRa clock consensus remains available as the fallback.</p> <p>On Full Companion targets whose primary mesh radio is ESP-NOW, ESP-NOW, the setup AP, and the infrastructure-WiFi station must share one 2.4 GHz channel. The persisted channel defaults to 1 and can be inspected or changed from the text terminal:</p> <pre><code>get espnow.channel\nset espnow.channel 6\nreboot\n</code></pre> <p>Valid values are 1 through 13; use only a channel permitted in your region and supported by the router. <code>set espnow.channel</code> saves the new value but does not move the running radio; reboot the node to apply it. Every primary ESP-NOW node that should communicate with it must use the same channel, and the configured router's 2.4 GHz radio must be fixed to that channel as well. A router left on automatic channel selection can move the infrastructure connection away from the ESP-NOW mesh.</p> <p><code>espnow.channel</code> configures the node's primary ESP-NOW mesh radio. It is distinct from <code>bridge.channel</code>, which applies only to the separate ESP-NOW bridge feature. WiFi power saving does not let ESP-NOW and infrastructure WiFi operate on different channels. On an ESP32 Full build whose primary radio is ESP-NOW, <code>wifi.powersave max</code> is unavailable because a station using maximum modem sleep can miss ESP-NOW broadcasts; use <code>min</code> for coexistence. The primary mesh transport holds the driver's RF wake reference continuously, so <code>min</code> does not suspend its ESP-NOW receiver.</p> <p>ESP-NOW compatibility also depends on the bytes and PHY used above the common Espressif transport. The historical <code>*_repeater_bridge_espnow</code> firmware wraps each MeshCore packet with a magic value, checksum, and secret-based XOR, while <code>Generic_ESPNOW</code> and <code>SenseCapIndicator-ESPNow</code> send the serialized MeshCore packet directly using the ESP-NOW LR PHY. Updated bridge firmware can select either behavior without changing the board target:</p> <pre><code>get bridge.format\nset bridge.channel 1\nset bridge.format raw\n</code></pre> <p>On a Heltec V4, the ordinary <code>companion_radio_full</code> image remains a LoRa-primary Companion and does not instantiate this bridge. Select and flash the existing <code>heltec_v4_repeater_bridge_espnow</code> role before using these commands. Treat that Companion-to-repeater change as a role/partition migration: back up the node and use the exact V4 merged install artifact.</p> <p><code>wrapped</code> remains the default and interoperates with existing bridge nodes that use the same channel and <code>bridge.secret</code>. <code>raw</code> interoperates with primary-ESP-NOW nodes and other raw bridges; it requires channel 1-13, enables LR reception, forces LR transmission, and ignores <code>bridge.secret</code>. Receive parsing is strict to the selected format, so migrate peers deliberately rather than expecting one bridge to accept both. Match <code>bridge.channel</code> on the LoRa gateway to the primary nodes' <code>espnow.channel</code>; a primary-node channel change takes effect after its reboot.</p> <p>Raw mode retains MeshCore's normal packet parsing, authentication/encryption, and the bridge's duplicate suppression, but it does not provide the wrapper's secret-based network isolation. That XOR wrapper is itself only lightweight isolation, not cryptographic security. Multiple LoRa/ESP-NOW gateways covering the same nodes can temporarily amplify duplicates, even though seen-packet tracking prevents an individual bridge from immediately echoing a packet back.</p> <p>If the configured network remains unavailable for two minutes, the companion opens its setup AP so the credentials can be repaired. It continues retrying the saved network. WiFi modem sleep has its own persisted <code>wifi.powersave</code> setting and is independent of the Companion device <code>powersaving</code> setting. The WiFi card in Companion WebConfig exposes <code>none</code>, <code>min</code>, and <code>max</code>. Fresh Cascade-profile builds select <code>min</code>; target-default builds select <code>none</code>. A saved setting takes precedence after an upgrade.</p> <p>WiFi-only Companions can use all three modes. A Full Companion that runs WiFi and BLE simultaneously requires at least minimum modem sleep. It reports <code>min</code> when an old or target-default <code>none</code> value is found and rejects a new <code>none</code> selection. When ESP-NOW is also the primary mesh radio, <code>max</code> is unavailable: the access point does not buffer ESP-NOW broadcasts for a sleeping station, so maximum modem sleep can lose them. Firmware caps a previously saved <code>max</code> value to and reports it as <code>min</code>, and rejects a new <code>max</code> selection.</p> <p>The SenseCAP Indicator Full targets select BLE or infrastructure WiFi instead of running both. On a WiFi-selected boot, the LoRa layout accepts <code>none|min|max</code>, while the ESP-NOW layout accepts <code>none|min</code> and still rejects <code>max</code>. On a BLE-selected boot infrastructure WiFi is off; the LoRa layout accepts <code>min|max</code> for the saved WiFi setting, while ESP-NOW + BLE requires <code>min</code>. Device power saving remains independent of this modem policy.</p> <p>WiFi companions do not have the repeater/room-server admin CLI password model, so their LAN WebConfig page is intentionally unauthenticated. Use them only on a trusted LAN.</p> <p>The WebConfig Advanced card exposes device power saving on WiFi Companion, repeater, and room-server builds. It also exposes RX power saving on radio chips that support receive duty cycling. RXPS can select continuous receive, levels 1-10, automatic or explicit 16/32-symbol timing assumptions, or manual receive/sleep windows. The timing assumption does not change the radio's actual wire preamble. The WebConfig WiFi card exposes WiFi modem power saving. All three settings are persisted across reboots.</p> <p>The three settings are independent. A WiFi Companion keeps its transports available while device power saving reduces CPU and GPS idle power. An infrastructure node can sleep when device power saving is enabled, so its WiFi services may be temporarily unavailable. RXPS only duty-cycles the LoRa receiver. Fresh Cascade-profile builds default to device power saving on, RXPS on at level 8 with a 16-symbol preamble, and WiFi modem power saving at <code>min</code> on every build that includes ESP32 WiFi. The RXPS preamble value is a saved timing assumption, not the wire length: starting with v1.17.1.5, SF5-SF8 packets normally use a 32-symbol physical preamble. Firmware selects 64 for the whole SF/BW tuple only when 32 cannot enable RXPS at any level and 64 can (SF5/BW250 and SF6/BW500), then 128 only when neither shorter length works (SF5/BW500).</p> <p>When <code>ENABLE_OTA</code> is included, a WiFi companion also listens on:</p> <ul> <li>TCP 5001 for the OTA folder seeder used by <code>motatool serve --tcp</code>;</li> <li>TCP 5002 for a text management console.</li> </ul> <p>These ports do not replace the companion protocol on TCP 5000. On a <code>companion_radio_full</code> build, port 5002 is the same role-specific text terminal available over USB, including chat, remote administration, radio and power settings, WiFi/WebConfig management, <code>tempradio</code>, and the source-only <code>ota</code> commands. Other OTA-enabled Companion builds keep the bounded <code>ota ...</code> console. LoRa staging and installation on the Full Companion itself remain disabled.</p> <p>Port 5002 is plaintext and has no independent login gate. Use it only on a trusted LAN or temporary setup network, especially when entering a remote-node admin password with the terminal's <code>login</code> command.</p> <p>FULL ESP32 builds share the port 5001 folder seeder. It starts whenever that role has a usable WiFi station or setup access point and stops when WiFi stops. For example, a FULL repeater can run <code>start webconfig</code> to join its saved network, then accept:</p> <pre><code>motatool serve --dir ./motas --tcp &lt;repeater-ip&gt;:5001 -v\n</code></pre> <p>The TCP connection supplies <code>.mota</code> files for the node to advertise and relay over LoRa; it is not a raw <code>.bin</code> uploader. <code>start ota</code> continues to provide the direct browser uploader on HTTP port 80. A FULL role without WebConfig but with browser OTA support can use the <code>MeshCore-OTA</code> access point raised by <code>start ota</code>; its seeder address is <code>192.168.4.1:5001</code>.</p> <p>Only one external folder link can be active. A TCP client is rejected while <code>ota folder on</code> is using USB serial, and disconnecting <code>motatool</code> automatically removes the TCP folder. Port 5001 has no login layer, so expose it only on a trusted LAN or temporary setup network. Firmware target and hash checks still apply at the receiving node, along with its configured signature/trust policy.</p> <p>When the shared seeder is running, <code>get wifi.status</code> appends its live state:</p> <pre><code>OTA TCP 5001: listening\nOTA TCP 5001: client connected\n</code></pre> <p>The first state means WiFi is usable and the node is waiting for <code>motatool serve --tcp</code>. The second means a <code>motatool</code> folder is currently attached and available for LoRa OTA service.</p>"},{"location":"WiFi/#wifi-companion-with-mqtt","title":"WiFi companion with MQTT","text":"<p>A <code>*_companion_radio_wifi_mqtt</code> build combines both systems:</p> <ul> <li>the companion protocol remains available to the phone/computer on TCP 5000;</li> <li>the same WiFi station connection is shared with the MQTT bridge;</li> <li>received and selected transmitted LoRa packets can be published to the   configured MQTT slots.</li> </ul> <p>The companion owns WiFi connection and recovery in this build. The MQTT bridge waits for that connection rather than creating a second one. Stopping MQTT does not disable the TCP companion service.</p> <p>The same WebConfig page contains the MQTT settings. MQTT companions have no text admin CLI, so browser configuration is the normal setup method.</p>"},{"location":"WiFi/#webconfig-without-mqtt","title":"WebConfig without MQTT","text":"<p>Full-size ESP32 repeater and room-server builds can include WebConfig even when MQTT is absent. The portal then shows node, radio, and WiFi-related controls but removes the MQTT wizard step and MQTT tab.</p> <p>In this case WebConfig owns WiFi only while it is needed. Stopping the portal disconnects WiFi and turns the WiFi radio off. There is no persistent MQTT connection keeping WiFi active.</p> <p>Unified FULL USB + WiFi and FULL logging-fallback repeater/room-server builds both provide these CLI controls and status checks. The unified profile includes the MQTT bridge; the fallback is used only where no matching MQTT environment exists:</p> <pre><code>get wifi.ssid\nget wifi.status\nget wifi.powersave\nget wifi.cli\nget webui\nset wifi.ssid SlowFi\nset wifi.pwd your-password\nset wifi.powersave none\nset wifi.cli on\n</code></pre> <p><code>get wifi.status</code> distinguishes an unconfigured node, an inactive WiFi radio, a station connection attempt, the setup AP, a connection failure, and a working LAN connection. For a LAN connection it reports the SSID, IP address, and RSSI. If the shared OTA seeder is active, the same reply also reports whether TCP port 5001 is listening or has a <code>motatool</code> client attached. <code>get wifi.powersave</code> reports the saved standalone WebConfig setting as <code>none</code>, <code>min</code>, or <code>max</code>. An inactive status is normal when <code>webui</code> is off: run <code>start webconfig</code> to connect temporarily. Standalone credentials can be changed through WebConfig or with the listed CLI commands. Changing the SSID or password stops an active WebConfig session; start it again to connect with the new values. Use <code>set wifi.pwd</code> with no value for an open network. The password is write-only and is never returned by <code>get</code>. Standalone WiFi accepts ordinary passphrases up to 63 characters and exact 64-character hexadecimal WPA/WPA2 PSKs; other 64-character values and all longer values are rejected. MQTT observer WiFi passwords remain limited to 63 characters by their fixed persisted layout.</p> <p><code>get webui</code> starts with the saved boot setting, then reports the current session. For example, <code>&gt; off, http://192.168.1.130/</code> means automatic WebConfig startup is saved as off, but a temporary session started by <code>start webconfig</code> is currently active at that URL.</p>"},{"location":"WiFi/#webconfig-cli-terminal","title":"WebConfig CLI terminal","text":"<p>The terminal defaults to on. Enable or disable it from an existing admin CLI:</p> <pre><code>set wifi.cli on\nset wifi.cli off\nget wifi.cli\n</code></pre> <p>The saved <code>on</code> setting becomes active only when the WiFi station client is connected and WebConfig is running in LAN mode. It is never exposed on the open setup access point. When active, the WebConfig page has a CLI tab for sending commands directly to the repeater or room server. It uses the local administrator command parser and displays one reply at a time. The terminal is protected by the WebConfig admin login and uses remote-administrator permissions, so commands explicitly restricted to a physical serial connection remain unavailable.</p> <p>Use Single command for the normal prompt, or select Command block to paste up to 100 commands with one command per line. Blank lines are ignored. The browser validates all lines first, then sends one command at a time and waits for its reply before sending the next. The block queue is kept in the browser only, so closing the page or losing its WiFi connection stops the commands that have not yet been sent. Ctrl+Enter or Command+Enter starts a block.</p> <p>The up/down arrow keys recall commands entered during the current browser session in single-command mode. Commands available in the terminal still depend on the firmware role and build profile. Commands such as <code>stop webconfig</code>, <code>set wifi.cli off</code>, WiFi credential changes, and reboot operations stop the remaining block and can disconnect the page before it receives their final reply.</p>"},{"location":"WiFi/#build-profiles","title":"Build profiles","text":"<p><code>build.sh</code> produces several profiles. A profile changes the features compiled into a selected target; it does not change that target into another firmware role.</p> <p>This fork defaults every <code>build.sh</code> target to the USA Cascadia radio preset and the Cascade firmware profile. The script resolves the live <code>USA/Canada</code> entry by name, so its changing number in the downloaded menu does not affect builds. If the preset service is unavailable, it falls back to <code>910.525 MHz / BW62.5 / SF7 / CR5</code>. Use <code>--radio-preset target --profile default</code> only when a build intentionally needs the target's original radio and profile defaults. <code>--radio-preset usa-cascadia</code> is the stable explicit name; legacy numbered choices remain accepted but their meaning can change when the service reorders or adds presets.</p> Build profile WiFi/MQTT behavior Standard Uses the selected target's role. Where USB is a safe plaintext console, the same artifact embeds debug/packet logging behind persistent <code>get/set usb.logging</code>. Ordinary legacy-slot ESP32 repeater/room-server artifacts omit WebConfig when needed to fit. ESP32 MQTT observer and ESP-NOW bridge targets are automatically promoted to FULL; WiFi-companion targets keep their companion partition profile. Legacy logging No separate artifact is emitted; USB logging is part of the ordinary image. Logging output itself is not a direct MQTT uplink. MQTT Builds explicit MQTT observer or WiFi-companion-MQTT targets with USB packet logging off. Non-companion ESP32 MQTT observers always use FULL expanded partitions. FULL ESP32 USB + WiFi Uses the board's MQTT target with USB packet logging and direct WiFi MQTT together, expanded dual-OTA partitions, up to 254 neighbors, LoRa OTA, and full-size ESP32 features such as WebConfig where supported. <code>get/set logging.output off\\|usb\\|wifi\\|both</code> persists the active paths. Classic T-Beam MQTT observers retain their 50-entry table because their persistent discovery state exhausts internal DRAM at 254. FULL ESP32 logging fallback Uses the board's non-MQTT target only when no matching WiFi MQTT environment exists. It keeps debug and packet logging, expanded dual-OTA partitions, up to 254 neighbors, and LoRa OTA. Persistent <code>usb.logging off</code> also provides normal output-off operation, so ESP-NOW FULL roles need no second non-logging image. LoRa-OTA no-external-sensors A lean repeater image with no MQTT; ESP32 builds retain the compact on-demand browser WiFi uploader and 254 neighbors. <p>All repeater profiles use the full 254-entry neighbor table, including standard, logging, bridge, and LoRa-OTA builds on every supported platform. The classic T-Beam SX1262 and SX1276 MQTT observer repeaters retain 50 entries because their persistent MQTT discovery state leaves insufficient internal-DRAM margin at 254.</p> <p>The interactive Option 1 FULL everything choice and the standalone FULL command select the unified USB + WiFi image when a matching MQTT target exists; otherwise they select the logging fallback. The build matrix no longer emits any separate standard logging image, or a non-MQTT FULL twin for a role covered by the unified image. All FULL profiles include LoRa OTA, WebConfig where supported, up to 254 neighbors, and expanded dual-OTA partitions. Target-specific internal-DRAM limits still apply.</p> <p>FULL images change the ESP32 partition layout. Flash the matching <code>*-merged.bin</code> once when installing that layout. A partition-layout change can invalidate NVS, including saved WiFi, MQTT, name, and admin settings. Later updates using the same layout normally preserve them.</p>"},{"location":"WiFi/#wifi-power-behavior","title":"WiFi power behavior","text":"<p>MQTT observers and FULL standalone ESP32 repeater/room-server builds support:</p> <pre><code>set wifi.powersave none\nset wifi.powersave min\nset wifi.powersave max\n</code></pre> <p>Fresh Cascade-profile builds default to <code>min</code>; target-default builds use <code>none</code>, which gives the most predictable MQTT and radio performance at the highest power use. <code>min</code> and <code>max</code> reduce power but may add latency or reduce reliability on busy nodes. A saved operator setting takes precedence on an upgrade. ESP32 WiFi Companions expose the same values in their WebConfig WiFi card and USB text terminal. Full Companion also accepts the text commands from TCP port 5002. The normal binary Companion protocol can read or write the setting over USB, BLE, or TCP port 5000 without entering terminal mode. A Full Companion that runs BLE and infrastructure WiFi simultaneously rejects <code>none</code> because coexistence requires WiFi modem sleep. An ESP32 Full Companion whose primary mesh radio is ESP-NOW also rejects <code>max</code>; maximum modem sleep can cause the station to miss ESP-NOW broadcasts because the access point does not buffer them. A previously saved <code>max</code> value is capped to and reported as <code>min</code>. The SenseCAP Indicator exception uses the active-mode rules above rather than assuming BLE and infrastructure WiFi are active together. ESP-NOW and infrastructure WiFi still must use the same fixed channel.</p> <p>MQTT observer targets normally limit ESP32 WiFi transmit power to 11 dBm unless the board configuration overrides <code>MQTT_WIFI_TX_POWER</code>. This setting affects WiFi only, not LoRa transmit power.</p>"},{"location":"WiFi/#recognizing-the-wrong-firmware","title":"Recognizing the wrong firmware","text":"<p><code>get wifi.status</code>, <code>get wifi.ssid</code>, <code>get wifi.powersave</code>, and <code>get wifi.cli</code> are available on MQTT observers and on FULL non-MQTT repeater/room-server builds with WebConfig. ESP32 WiFi Companions expose the first three commands, credential setters, and <code>start webconfig [ap]</code> through their USB text terminal; <code>get/set wifi.cli</code> explicitly report that the repeater/room-server browser CLI is unavailable. Full Companion instead exposes its complete role-specific text terminal on TCP port 5002. MQTT commands such as <code>get mqtt.status</code> and <code>set mqtt1.preset ...</code> still require an MQTT observer target. Unknown settings return <code>Error: unknown setting: &lt;name&gt;</code>. Older firmware that used the discontinued compact CLI can instead report <code>Unsupported in this firmware</code> when a command was cut for space.</p> <p>Check the complete firmware filename and role. In particular:</p> <ul> <li><code>logging</code> does not mean MQTT;</li> <li><code>ota</code> does not mean MQTT;</li> <li><code>companion_radio_wifi</code> does not mean MQTT;</li> <li>the filename must contain <code>observer_mqtt</code> or <code>wifi_mqtt</code> for the corresponding   on-device MQTT feature.</li> </ul> <p>Rolling firmware back does not restore settings erased by a full flash or a partition-table change. If the correct MQTT target still has no configuration, provision WiFi and MQTT again.</p>"},{"location":"WiFi/#troubleshooting","title":"Troubleshooting","text":"<p>For an MQTT observer:</p> <pre><code>get wifi.status\nget bridge.enabled\nget mqtt.status\nget mqtt1.diag\nget mqtt2.diag\n</code></pre> <p>Common causes are:</p> <ul> <li>no saved SSID or a changed password;</li> <li>blank/invalid IATA for a preset that requires it;</li> <li>the bridge disabled;</li> <li>all MQTT slots disabled;</li> <li>too many TLS/WSS slots for the available internal memory;</li> <li>WiFi power saving being too aggressive;</li> <li>the wrong firmware role or an older compact-CLI build without WebConfig.</li> </ul> <p>For a WiFi companion, find its station IP in the router, connect the client to TCP port 5000, and use the open <code>MeshCore-Setup-XXXX</code> AP at <code>http://192.168.4.1/</code> if it cannot join the saved network. Current firmware normalizes both ESP32 WiFi interfaces to standard b/g/n before advertising the setup AP. Full Companion targets whose primary mesh radio is ESP-NOW use b/g/n+LR instead and keep the setup AP, infrastructure station, and mesh on the persisted <code>espnow.channel</code> (channel 1 by default). Their configured 2.4 GHz router and every other primary ESP-NOW node must use that same channel. MQTT diagnostics apply only to a <code>wifi_mqtt</code> companion target.</p>"},{"location":"cli_build_matrix/","title":"CLI Availability by Firmware Build","text":"<p>MeshCore command availability is determined in three layers:</p> <ol> <li>Role - repeater, room server, sensor, companion, bridge, or KISS modem.</li> <li>Build profile - standard, logging, OTA, or FULL.</li> <li>Compiled hardware features - WiFi, MQTT, GPS, external sensors, PSRAM,    Ethernet, and similar optional support.</li> </ol> <p>The complete command descriptions are in CLI Commands. This page describes the commands intentionally omitted or limited by build profile. The CLI Command Availability Matrix expands this summary into separate nRF52 and ESP32 command tables.</p>"},{"location":"cli_build_matrix/#selecting-a-build-profile","title":"Selecting a build profile","text":"<p>The runtime settings profile and the feature profile are separate switches:</p> <pre><code>bash build.sh build-firmware RAK_3401_repeater \\\n  --profile cascade \\\n  --build-profile auto\n</code></pre> <p><code>--profile default|cascade</code> selects saved-setting defaults. It does not select which code is linked. <code>--build-profile auto|standard|full</code> controls features and partition policy:</p> Selection Behavior <code>auto</code> For one explicit target, pass 1 builds the complete supported LoRa-OTA-capable recipe. ESP32 boards with a qualified expanded profile use it; other repeaters attempt the complete recipe in their current application region. A non-repeater keeps every capability declared by its resolved PlatformIO recipe, including LoRa OTA, and fails instead of silently removing one that does not fit. A measured repeater flash/partition overflow starts the standard <code>no_external_sensors</code> LoRa OTA pass. Internal-flash nRF52 repeaters publish that reduced pass even when the complete image fits, because the smaller running image leaves more room to stage a delta; matched QSPI/SD repeaters do not need the redundant artifact. Compiler errors and missing-capability checks never trigger or conceal a reduced build. Canonical bulk commands keep their established standard partition contract. <code>standard</code> Immediately uses the deployed/portable partition contract and its documented reductions. This is useful when the operator already knows the expanded or complete image is unsuitable. <code>full</code> Requires a qualified ESP32 expanded-partition target (or an explicitly named Full Companion). Install a matching merged image when this changes the partition table. <p>Successful builds also emit <code>&lt;firmware&gt;.capabilities.json</code>. The sidecar records the effective profile, logical OTA target, actual PlatformIO base, artifact name target, promised capabilities, and every reduction selected by the script. The build fails if a promised linked marker is absent. Current invariants include <code>retry.preset</code> for repeater/room-server roles, WebConfig for the Indicator and ESP32 Full Companion, TempRadio/OTA controls for install-capable Companions, host-mOTA controls for Full Companion, and the advanced flood-rule engine for Full room servers. Resume mode will not accept an old or failed artifact without a verified sidecar.</p>"},{"location":"cli_build_matrix/#role-comes-first","title":"Role comes first","text":"Role Text administration CLI Repeater Full repeater administration surface, subject to the profile differences below Room server Room-server administration surface, subject to the profile differences below Sensor Sensor command surface; it does not acquire the repeater administration tree Full, serial, Ethernet, USB, BLE, or WiFi companion Uses the companion protocol; Full combines every qualified transport for that exact board KISS modem Uses the KISS/TNC frame interface, not the repeater text CLI Bridge Uses its base role plus commands for the bridge transport compiled into that target <p>A command belonging to a different role is not considered a profile cut. For example, adding FULL features to a sensor does not turn it into a repeater administrator.</p> <p>Repeater profiles use 254 neighbor entries across supported platforms. The classic T-Beam SX1262 and SX1276 MQTT observer repeaters are the exception and retain 50 because their MQTT discovery tables are constrained by internal DRAM.</p>"},{"location":"cli_build_matrix/#profile-matrix","title":"Profile matrix","text":"Build/profile Command availability Standard non-MQTT repeater or room server Keeps the normal role CLI and, where USB is a safe plaintext console, embeds debug/packet logging behind persistent <code>get/set usb.logging</code>. The explicitly selected portable policy can omit WebConfig and browser WiFi OTA, so those commands are unavailable and the omission is recorded in the capability manifest. Legacy standard logging No longer emitted separately. Its behavior is compiled into the ordinary artifact. Size-constrained STM32 targets embed packet logging without verbose <code>MESH_DEBUG</code>. LoRa-OTA (<code>-ota-</code>) LoRa OTA adds the <code>ota ...</code> commands; it does not otherwise reduce the role CLI. ESP32 <code>no_external_sensors</code> artifacts retain the compact browser WiFi uploader, the complete CLI, and a 254-entry neighbor table. Internal-flash nRF52 repeater auto pair <code>full-ota</code> retains the board's external-sensor drivers; <code>reduced-ota</code> omits the declared optional sensors to leave additional internal-flash staging room. RAK3401 and RAK4631 reduced builds retain INA219, INA226, INA260, and INA3221 I2C voltage/current monitors at a measured cost below 5 KiB. Both artifacts carry the same stable OTA target identity and are checked for <code>ota ...</code> and <code>retry.preset</code>; RAK artifacts also verify the retained monitor drivers. ESP32 MQTT observer or ESP-NOW bridge Always uses the expanded FULL partition profile. The build never substitutes a reduced CLI to fit the legacy application slot. FULL ESP32 USB + WiFi Uses the matching MQTT target with packet logging on, verbose debug off, and the complete command surface supported by that role and hardware. <code>get/set logging.output off\\|usb\\|wifi\\|both</code> selects and persists the active output paths. FULL ESP32 logging fallback Uses the matching non-MQTT target only when no WiFi MQTT sibling exists, with debug and packet logging enabled and the complete command surface supported by that role and hardware. Its persistent USB gate also covers output-off operation, avoiding a second FULL ESP-NOW image. nRF52 dual-CDC Full Companion Fresh installs expose only interface <code>00</code>; it starts as an ASCII terminal and automatically hands a complete <code>&lt;</code> frame to framed Companion. The same interface also carries exclusive serial mOTA traffic. Enabling logging and rebooting adds interface <code>02</code> for plaintext logs. BLE and source-only LoRa OTA remain available. <code>get/set usb.logging</code> persistently controls whether the logging interface is present. ESP32 single-TTY Full Companion Every ESP32 Full image starts with the ASCII terminal on its one USB TTY and automatically hands a complete <code>&lt;</code> frame to framed Companion. <code>set usb.logging on</code> switches that TTY to an input-capable plaintext logging terminal and makes framed Companion unavailable on USB; <code>set usb.logging off</code> stops logging but leaves the TTY in normal ASCII mode. The terminal stop token or a valid incoming framed probe then performs the ordinary switch to Binary Companion. A saved logging-on setting starts directly in that logging terminal and disables automatic frame detection. BLE, WiFi, and source-only LoRa OTA remain available. ESP32 Full uses Arduino-ESP32 2.x where supported; RC32 and ESP32-C6 keep their board-required Arduino 3.x platform but still expose only one TTY. <code>no_external_sensors</code> Trims selected optional environmental/ranging drivers and their settings; it does not remove generic I2C, core repeater discovery, routing, or runtime RS-232 commands. RAK3401 and RAK4631 profiles retain the four common INA I2C voltage/current monitors. GPS-preserving RAK nRF52 OTA profiles retain their GPS commands and provider; RAK4631 defaults the bridge to UART 2 because RAK12501/L76K GPS uses UART 1. Legacy target suffixes remain stable for OTA identity compatibility. <p>The four retained INA drivers are entries in the optional environmental-sensor table, not the complete set of RAK I2C consumers. Compatible reduced profiles also retain the SSD1306 OLED, supported autodiscovered RTCs, and RAK12500 I2C GPS as separate board peripherals. RAK12501/L76K GPS uses UART Serial1. The explicit RAK4631 Serial1 bridge omits the combined GPS provider, including the otherwise non-UART RAK12500 path.</p> <p>The firmware-configured INA3221 and RAK12500 addresses are both <code>0x42</code>. To use both devices on one bus, leave RAK12500 at <code>0x42</code>, strap INA3221 A0 to SCL for <code>0x43</code>, and build with <code>-DTELEM_INA3221_ADDRESS=0x43</code>.</p> <p><code>logging</code>, <code>OTA</code>, and <code>FULL</code> describe independent build features in historical filenames. Current standard artifacts use no <code>-logging-</code> infix because their USB logging is runtime controlled.</p>"},{"location":"cli_build_matrix/#canonical-bulk-build-policy","title":"Canonical bulk-build policy","text":"<p>Bulk and release-matrix commands omit legacy names whose behavior is already available from a canonical image:</p> <ul> <li>Companion <code>_ps</code> names are replaced by the ordinary Companion image plus the   persisted <code>powersaving on|off</code> setting.</li> <li>Companion <code>_femoff</code> names are replaced by the matching controllable-FEM   image plus <code>radio.fem.rxgain on|off</code>. The old names remain explicit build   targets for compatibility.</li> <li><code>Station_G2_logging_*</code> and <code>Station_G3_ESP32_logging_*</code> hardware names are   replaced by their ordinary Station target. G2 boosted receive gain is the   persisted <code>radio.rxgain on|off</code> setting; the G3 alias changed only the   advertised default name.</li> <li> <p>When a board has a Full Companion, that one artifact replaces its   separate USB, BLE, ordinary WiFi, hardware-serial, Ethernet Companion, and   USB packet-logging Companion artifacts.   It provides BLE and source-only LoRa OTA; ESP32 also provides ordinary WiFi.   nRF52 keeps framed traffic on interface <code>00</code> and can add logging on interface   <code>02</code> after a reboot. Every ESP32 Full build instead switches its one USB TTY   into an input-capable logging terminal. Turning logging off restores the   normal ASCII terminal; the usual stop token or a valid framed probe then   switches it to Binary Companion.   Its LoRa OTA support is source-only: it can serve a host file to another node   but has no staging store and cannot update itself over LoRa.   Installing an ESP32 Full Companion may require one merged-image erase/flash   to adopt its expanded partition table. Once migrated, later Full Companion   releases use normal app updates. The transport-specific non-Full images stay   available as explicit build targets, but are not canonical release artifacts   when the qualified Full image fits.</p> </li> <li> <p>Standalone Terminal Chat is omitted when the same exact hardware has either   Full Companion or a USB Companion, because their local text terminal supplies   the same role. Heltec E290 and T190 similarly publish one combined USB + BLE   Companion. RAK4631 repeater and room-server Ethernet builds stay separate;   only the RAK4631 Ethernet Companion is folded into Full Companion.</p> </li> <li>Matching RS-232 bridge roles are compiled into the normal repeater and   selected at runtime with <code>bridge.enabled</code>, <code>bridge.baud</code>, and <code>bridge.uart</code>.   Historical bridge names remain directly buildable but are omitted from bulk   releases. Wio-E5 remains separate because its normal image has only 916   bytes free, while the combined image exceeds the fixed 240 KiB application   partition by 2,192 bytes.</li> </ul> <p>The old aliases still work with <code>build-firmware</code> and <code>build-matching-firmwares</code>. Dedicated LoRa OTA repeater images are not collapsed; they retain their exact storage, bootloader, role, and target identity contracts. Companion boards keep transport-specific canonical images only when no exact Full recipe has passed the combined flash/RAM qualification. ESP32 deliberately uses one TTY: Binary Companion and plaintext USB logging are mutually exclusive there. nRF52 retains its optional second CDC port.</p>"},{"location":"cli_build_matrix/#complete-cli-policy","title":"Complete CLI policy","text":"<p>The compact ESP32 CLI has been removed. <code>retry.preset</code> is a checked invariant for every repeater and room-server artifact, not a FULL-only command. MQTT observers and ESP-NOW bridges are automatically promoted to FULL builds with expanded partitions rather than dropping administration commands. This keeps <code>tempradio</code>, LoRa OTA, power saving, RXPS, logging, statistics, sensor, ACL, routing, and advanced radio commands whenever the role and compiled hardware support them.</p> <p>Some commands still have hardware or feature limits. MQTT neighbor-table publishing and <code>discover.scopes</code> require the compiled <code>WITH_MQTT_NEIGHBORS</code> feature. PSRAM boards enable it automatically, and selected non-PSRAM variants opt in with <code>MQTT_NEIGHBORS_WITHOUT_PSRAM</code>. <code>discover.neighbors</code> does not require MQTT or PSRAM.</p>"},{"location":"cli_build_matrix/#discovery-invariant","title":"Discovery invariant","text":"<p><code>discover.neighbors</code> sends the zero-hop node-discovery request used to refresh the repeater neighbor table. It is available in every repeater build profile, including standard, logging, OTA, unified FULL, and FULL logging-fallback builds.</p> <p>The exact command is:</p> <pre><code>discover.neighbors\n</code></pre> <p>It accepts no options and returns:</p> <pre><code>OK - Discover sent\n</code></pre> <p>Some MQTT room-server targets also expose the command as part of their compiled neighbor-table feature. It is not a cross-role guarantee: companion, KISS, sensor, and ordinary room-server firmware use different interfaces or do not maintain the repeater administrator neighbor table.</p>"},{"location":"cli_build_matrix/#feature-dependent-commands","title":"Feature-dependent commands","text":"<p>Even in a FULL build, a command can be unavailable when its underlying feature does not exist on that target:</p> <ul> <li>WebConfig and the <code>wifi.ssid</code>, <code>wifi.status</code>, and <code>wifi.powersave</code> command   family require an ESP32 WebConfig build. FULL standalone repeater and   room-server builds support the corresponding WiFi setters and status   commands. ESP32 WiFi Companions with WebConfig expose WiFi credentials,   connection status, WebConfig, and power-save controls from their USB   text terminal as well as power saving through WebConfig and the binary   protocol. The browser CLI tab and <code>wifi.cli</code> setting are repeater/room-server   features. Full Companion instead exposes its complete role-specific text   terminal on TCP port 5002.</li> <li>MQTT commands require an MQTT observer target.</li> <li><code>discover.scopes</code> requires an MQTT observer with compiled neighbor support;   it does not independently require PSRAM or the FULL parser.</li> <li>GPS and external-sensor commands require their drivers and pins.</li> <li>Ethernet and bridge commands require the corresponding transport.</li> <li>LoRa OTA commands require an artifact with OTA enabled.</li> <li><code>uf2reset</code> applies only to nRF52.</li> </ul> <p>When diagnosing an unavailable command, check the role first, then the filename profile, then the target's compiled hardware features and its adjacent <code>.capabilities.json</code> file. A current artifact that promises the command but does not contain its linked marker is rejected during the build.</p>"},{"location":"cli_command_availability/","title":"CLI Command Availability Matrix","text":"<p>This page is the command-by-command companion to CLI Availability by Firmware Build. Each command name links to its detailed documentation.</p> <p>The tables cover the text administration CLI used by repeater, room-server, sensor, and bridge firmware. Companion firmware uses the companion protocol, KISS firmware uses framed KISS/TNC commands, and terminal-chat firmware has its own interface, so those build roles are not represented here.</p> <p>Build columns mean:</p> <ul> <li>Standard - the ordinary non-MQTT artifact, without an explicit <code>ota</code>   filename marker. Safe plaintext-USB roles embed runtime USB logging.</li> <li>Logging - the legacy <code>-logging-</code> profile, now represented by the same   ordinary artifact and retained as a comparison column only.</li> <li>LoRa OTA - the explicit <code>-ota-</code> repeater or repeater-bridge artifact. A   legacy <code>no_external_sensors</code> profile trims selected optional environmental   and ranging drivers; it does not disable the generic I2C bus or unrelated   board-integrated peripherals. Reduced RAK3401 and RAK4631 profiles retain   INA219/INA226/INA260/INA3221 as voltage/current entries in the optional sensor   table. The SSD1306 OLED, supported autodiscovered RTCs, and RAK12500 GPS are   separate I2C peripherals in compatible recipes. RAK12501/L76K GPS instead   uses UART Serial1. The plain RAK profiles and RAK4631 Serial2 bridge retain   the combined GPS provider; the explicit RAK4631 Serial1 bridge omits that   provider, including RAK12500, because the bridge owns the RAK12501 UART.</li> <li>FULL unified - the expanded-partition ESP32 artifact with LoRa OTA, the   complete parser, USB packet logging, and direct WiFi MQTT. Its saved output   mode can be off, USB, WiFi, or both. MQTT observers use this profile.</li> <li>FULL fallback - the expanded-partition ESP32 non-MQTT artifact used only   where there is no MQTT sibling. It has the complete parser and a saved   USB-logging on/off gate. ESP-NOW bridges use this profile.</li> </ul> <p>The firmware-configured INA3221 and RAK12500 addresses are both <code>0x42</code>; they cannot coexist on one bus at those addresses. Leave RAK12500 at <code>0x42</code>, strap INA3221 A0 to SCL for <code>0x43</code>, and use a build with <code>-DTELEM_INA3221_ADDRESS=0x43</code> when both are installed.</p> <p>Cell values mean:</p> <ul> <li>Yes - the parser includes the command. The Scope column still applies.</li> <li>No - the profile does not expose the command.</li> <li>Feature - available only when the target compiles the feature or hardware   named in Scope.</li> <li>Serial - available only from the local serial console.</li> <li>Manifest - available only when the MQTT target defines   <code>OTA_MANIFEST_BASE</code>.</li> <li>Limited - the family exists, but the limitation in Scope applies.</li> </ul> <p>Runtime state can still make an included command fail. Examples include no GPS fix, no WiFi connection, an inactive bridge, or an nRF52 bootloader without <code>.mota</code> apply support.</p>"},{"location":"cli_command_availability/#companion-framed-cli","title":"Companion framed CLI","text":"<p>Companion builds are not represented by the role/profile matrices below. Their local terminal and command <code>0x42</code> (<code>CMD_RUN_CLI_COMMAND</code>) expose these settings over the normal binary USB, BLE, or TCP connection:</p> Command Availability <code>board</code> Every Companion text terminal and command <code>0x42</code> <code>version</code> Every Companion text terminal and protocol-v14 command <code>0x42</code>; returns the untruncated build identity <code>get storage.layout</code> Every Companion text terminal and command <code>0x42</code>; reports the running platform's storage layout <code>memory</code> ESP32 Full Companion text terminal and command <code>0x42</code> <code>get/set radio.rxgain</code> Companion with a supported radio <code>get/set radio.fem.rxgain</code> Companion on a board with controllable LoRa FEM LNA <code>get/set wifi.powersave</code> ESP32 WiFi Companion; active transport constraints still apply <code>get/set bluetooth.name</code> Companion firmware <p>Deprecated binary aliases remain receive-only for older clients; new clients should use command <code>0x42</code>. See Companion radio binary protocol.</p>"},{"location":"cli_command_availability/#nrf52","title":"nRF52","text":"Area Command Scope Standard Logging LoRa OTA Operational <code>reboot</code> All text CLI roles Yes Yes Yes Operational <code>poweroff</code>; <code>shutdown</code> Board power-off support Yes Yes Yes Operational <code>uf2reset</code> Local serial; supported UF2 boards Serial Serial Serial Operational <code>clkreboot</code> All text CLI roles Yes Yes Yes Operational <code>clock sync</code> All text CLI roles Yes Yes Yes Operational <code>clock</code> All text CLI roles Yes Yes Yes Operational <code>time &lt;epoch_seconds&gt;</code> Clock only moves forward Yes Yes Yes Operational <code>advert</code> Advert-capable role Yes Yes Yes Operational <code>advert.zerohop</code> Advert-capable role Yes Yes Yes Operational <code>erase</code> Local serial Serial Serial Serial Information <code>ver</code> All text CLI roles Yes Yes Yes Information <code>board</code> All text CLI roles Yes Yes Yes Diagnostics <code>get storage.layout</code> Internal layout and configured QSPI or SD storage Yes Yes Yes Diagnostics <code>memory</code> ESP32 only No No No Diagnostics <code>sensor</code> Hardware wiring summary Yes Yes Yes Diagnostics <code>powerlog</code> Reset, shutdown, and boot-voltage summary Yes Yes Yes Neighbors <code>neighbors</code> Role with a neighbor table Yes Yes Yes Neighbors <code>neighbor.remove &lt;pubkey_prefix&gt;</code> Role with a mutable neighbor table Yes Yes Yes Neighbors <code>discover.neighbors</code> Repeater; some MQTT room servers Yes Yes Yes Neighbors <code>discover.scopes</code> MQTT observer with compiled neighbor support No No No Statistics <code>clear stats</code> All full-parser text CLI roles Yes Yes Yes Statistics <code>stats-core</code> Local serial Serial Serial Serial Statistics <code>stats-radio</code> Local serial Serial Serial Serial Statistics <code>stats-radio-diag</code> Local serial Serial Serial Serial Statistics <code>stats-packets</code> Local serial Serial Serial Serial Statistics <code>get telemetry.temp/volt/volt.i2c</code>; optional GPS history Non-STM32 repeater or room server; I2C command requires a detected voltage monitor; GPS requires a provider; remote access requires administrator Yes Yes Yes Statistics <code>set telemetry.gps</code>; <code>get/set/send telemetry.tx</code> Non-STM32 repeater; GPS setting requires a provider; remote access requires administrator Yes Yes Yes Logging <code>log start</code>; <code>log stop</code>; <code>log erase</code> Storage-backed roles retain data; other roles can return empty data Yes Yes Yes Logging <code>log</code> Local serial Serial Serial Serial Logging <code>get/set usb.logging</code>; unified FULL <code>get/set logging.output</code> Ordinary safe-USB artifacts; CommonCLI USB gate is persistent; unified ESP32 FULL selects off/USB/WiFi/both; nRF52 Full Companion can add a reboot-controlled second CDC Yes Yes No Radio <code>get radio</code>; <code>set radio ...</code> All text CLI roles Yes Yes Yes Radio <code>get tx</code>; <code>set tx &lt;dbm&gt;</code> Board TX-power limits apply Yes Yes Yes Radio <code>tempradio ...</code>; <code>normalradio</code> Full parser Yes Yes Yes Radio <code>get/set/del radioat</code>; <code>get/set/del tempradioat</code> Full parser Yes Yes Yes Radio <code>get freq</code>; <code>set freq &lt;mhz&gt;</code> <code>set</code> is local serial only Yes Yes Yes Radio <code>get/set radio.rxgain</code> Supported radio Feature Feature Feature Radio <code>get/set radio.fem.rxgain</code> Controllable LoRa FEM Feature Feature Feature Radio <code>get/set radio.fem.txgain</code> Controllable LoRa FEM Feature Feature Feature Radio <code>get/set radio.rxps</code>; <code>get rxps.wd</code> RX power-saving support Feature Feature Feature System <code>get/set name</code> All text CLI roles Yes Yes Yes System <code>get/set lat</code> All text CLI roles Yes Yes Yes System <code>get/set lon</code> All text CLI roles Yes Yes Yes System <code>get/set prv.key</code> <code>get</code> is local serial only Yes Yes Yes System <code>password &lt;new_password&gt;</code> Administrator Yes Yes Yes System <code>get/set guest.password</code> Role with guest administration Yes Yes Yes System <code>get/set owner.info</code> All text CLI roles Yes Yes Yes System <code>get/set adc.multiplier</code> Board ADC override support Feature Feature Feature System <code>send text.flood &lt;message&gt;</code> Repeater Yes Yes Yes System <code>host &lt;text&gt;</code>; <code>get host</code> Repeater with host bridge; <code>host</code> requires a remote administrator and a USB/MQTT service Yes Yes Yes System <code>get/set battery.alert</code>; <code>get battery.alert.region</code> Repeater Yes Yes Yes System <code>get/set battery.alert.low</code>; <code>get/set battery.alert.critical</code> Repeater Yes Yes Yes System <code>get/set rx.watchdog</code> Repeater Yes Yes Yes System <code>get/set system.watchdog</code> nRF52 Yes Yes Yes System <code>get public.key</code> All text CLI roles Yes Yes Yes System <code>get role</code> All text CLI roles Yes Yes Yes System <code>powersaving</code>; <code>powersaving on/off</code> Supported repeater board Feature Feature Feature System <code>get/set reboot.interval</code> Full parser Yes Yes Yes Clock sync <code>get/set clock.sync.*</code>; <code>clock.sync.mesh now</code> Repeater, sensor, and room server; <code>clock.sync.internet</code> needs MQTT repeater Yes Yes Yes Routing <code>get/set repeat</code> Forwarding-capable role Yes Yes Yes Routing <code>get/set path.hash.mode</code> Role that supports path-hash selection Yes Yes Yes Routing <code>get/set loop.detect</code> Repeater Yes Yes Yes Routing <code>get/set txdelay</code> All text CLI roles, including bridges Yes Yes Yes Routing <code>get/set direct.txdelay</code> Full parser Yes Yes Yes Routing <code>get/set rxdelay</code> All text CLI roles, including bridges Yes Yes Yes Routing <code>get/set dutycycle</code> Full parser Yes Yes Yes Routing <code>get/set af</code> Full parser Yes Yes Yes Routing <code>get/set int.thresh</code> All text CLI roles Yes Yes Yes Routing <code>get/set cad</code> Radio CAD support Feature Feature Feature Routing <code>get/set agc.reset.interval</code> All text CLI roles Yes Yes Yes Routing <code>get/set radio.watchdog</code> MQTT observer No No No Routing <code>get/set multi.acks</code> Full parser Yes Yes Yes Routing <code>get/set flood.advert.interval</code> Repeater Yes Yes Yes Routing <code>get/set advert.interval</code> Advert-capable role Yes Yes Yes Routing <code>get/set flood.max</code> Repeater Yes Yes Yes Routing <code>get/set flood.max.unscoped</code> Repeater Yes Yes Yes Routing <code>get/set flood.max.advert</code> Repeater Yes Yes Yes Routing <code>get/set flood.channel.data</code>; <code>get/set flood.channel.data.hops</code> Repeater Yes Yes Yes Routing <code>get/set/del flood.channel.scope*</code> Repeater Yes Yes Yes Routing <code>get/set/del flood.channel.scope.require*</code> Repeater Yes Yes Yes Routing <code>get/set/del flood.rule*</code>; <code>get/set/del flood.filter*</code>; <code>get/set/del flood.filter.blacklist*</code> Repeater; <code>flood.rule</code>/<code>flood.filter</code> also on FULL ESP32 room server (no blacklist) Yes Yes Yes Routing <code>get/set/del flood.moderation*</code> Repeater Yes Yes Yes Routing <code>get/set outpath</code> Repeater remote-client context Yes Yes Yes Routing <code>get/set altpath</code> Repeater remote-client context Yes Yes Yes ACL <code>setperm &lt;pubkey&gt; &lt;permissions&gt;</code> Repeater, room server, or sensor Yes Yes Yes ACL <code>get acl</code> Local serial Serial Serial Serial ACL <code>get/set allow.read.only</code> Room server Yes Yes No Regions <code>region load</code>; <code>region save</code> Role with region storage Yes Yes Yes Regions <code>region allowf</code>; <code>region denyf</code> Role with region storage Yes Yes Yes Regions <code>region get</code>; <code>region list</code>; <code>region</code> Role with region storage Yes Yes Yes Regions <code>region home</code>; <code>region default</code> Role with region storage Yes Yes Yes Regions <code>region put</code>; <code>region def</code>; <code>region remove</code> Role with region storage Yes Yes Yes Retry <code>get/set direct.retry</code>; <code>get/set direct.retry.heard</code> Role with basic retry support Yes Yes Yes Retry <code>get/set retry.preset</code> Role with retry support Yes Yes Yes Retry <code>get/set flood.retry.count</code>; <code>get/set flood.retry.path</code>; <code>get/set flood.retry.group.path</code> Repeater Yes Yes Yes Retry <code>get/set flood.retry.advert</code>; <code>get/set flood.retry.prefixes</code>; <code>get/set flood.retry.ignore</code> Repeater Yes Yes Yes Retry <code>get/set flood.retry.bridge</code>; <code>get/set flood.retry.bucket</code> Repeater bridge retry support Feature Feature Feature Retry <code>get/set direct.retry.count</code>; <code>get/set direct.retry.base</code>; <code>get/set direct.retry.step</code> Role with retry support Yes Yes Yes Retry <code>get/set direct.retry.margin</code>; <code>get/set direct.retry.cr</code> Role with retry support Yes Yes Yes Retry <code>get/set/clear recent.repeater</code>; <code>get recent.repeaters</code> Repeater Yes Yes Yes GPS <code>gps</code>; <code>gps on/off</code> Compiled GPS Feature Feature Feature GPS <code>gps sync</code> Compiled GPS Feature Feature Feature GPS <code>gps setloc</code> Compiled GPS Feature Feature Feature GPS <code>gps advert [none/share/prefs]</code> Compiled GPS Feature Feature Feature Sensors <code>get/set telemetry.access</code> Sensor-capable role Feature Feature Limited Sensors <code>sensor list [start]</code> Compiled sensor manager; reduced OTA trims target-selected optional environmental/ranging drivers Feature Feature Limited Sensors <code>sensor get</code>; <code>sensor set</code> Compiled sensor setting; reduced OTA trims target-selected optional environmental/ranging drivers Feature Feature Limited Sensors <code>io [r/s/t]&lt;hex&gt;</code> Simple sensor role with board GPIO support Feature Feature No Bridge <code>get bridge.type</code> Compiled bridge Feature Feature Feature Bridge <code>get/set bridge.enabled</code>; <code>get bridge.running</code> Compiled bridge Feature Feature Feature Bridge <code>get/set bridge.delay</code> Compiled bridge Feature Feature Feature Bridge <code>get/set bridge.source</code> Compiled bridge Feature Feature Feature Bridge <code>get/set bridge.baud</code> RS-232 bridge Feature Feature Feature Bridge <code>get/set bridge.uart</code> RS-232 bridge Feature Feature Feature Bridge <code>get/set bridge.channel</code> ESP-NOW is ESP32 only No No No Bridge <code>get/set bridge.format</code> ESP-NOW bridge No No No Bridge <code>get/set bridge.secret</code> ESP-NOW is ESP32 only No No No Board <code>get bootloader.ver</code> nRF52 bootloader metadata Yes Yes Yes Board <code>get pwrmgt.support</code>; <code>get pwrmgt.source</code>; <code>get pwrmgt.bootreason</code>; <code>get pwrmgt.bootmv</code> Board power-management implementation Feature Feature Feature Ethernet <code>eth.status</code> Ethernet target Feature Feature No Browser OTA <code>start ota [ap]</code>; <code>stop ota</code> ESP32 browser uploader No No No WebConfig <code>start webconfig [ap]</code>; <code>stop webconfig</code>; <code>get/set webui</code> ESP32 WebConfig No No No WiFi <code>get/set wifi.ssid</code>; <code>set wifi.pwd</code>; <code>get wifi.status</code>; <code>get/set wifi.powersave</code> ESP32 WiFi No No No WiFi <code>get/set wifi.cli</code> ESP32 WebConfig No No No LoRa OTA <code>ota help</code>; <code>ota ?</code>; <code>ota h</code> LoRa OTA build No No Yes LoRa OTA <code>ota</code>; <code>ota status</code>; <code>ota st</code> LoRa OTA build No No Yes LoRa OTA <code>ota stats</code> LoRa OTA build No No Yes LoRa OTA <code>ota ls</code>; <code>ota neighbors</code>; <code>ota nbrs</code>; <code>ota updates</code>; <code>ota n</code> LoRa OTA build No No Yes LoRa OTA <code>ota get</code>; <code>ota pull</code>; <code>ota download</code> LoRa OTA build; internal-store nRF52 installs in-place deltas, while matched SD/QSPI nRF52 also accepts full images No No Yes LoRa OTA <code>ota install</code>; <code>ota apply</code>; <code>ota applydelta</code> Compatible bootloader and completed update No No Yes LoRa OTA <code>ota rescue install &lt;base_hash16&gt;</code> Legacy internal-flash nRF52 LoRa OTA build with failed app-side EndF validation; shared bootloader-update builds require valid EndF No No Feature LoRa OTA <code>ota bootloader</code>; <code>ota bootloader install &lt;MID8&gt; &lt;HASH16&gt;</code> Allowlisted internal-flash, XIAO-QSPI, or exact MeshTower V2 microSD nRF52 repeater with ABI-3 exact-board OTAFIX No No Feature LoRa OTA <code>ota cancel</code>; <code>ota drop</code>; <code>ota stop</code> LoRa OTA build No No Yes LoRa OTA <code>ota announce</code>; <code>ota adv</code> LoRa OTA build No No Yes LoRa OTA <code>ota self</code>; <code>ota id</code> Firmware with EndF trailer No No Yes LoRa OTA <code>ota qspi</code>; <code>ota storage</code> nRF52 build with raw-QSPI OTA staging Feature Feature Feature LoRa OTA <code>ota folder</code>; <code>ota fold</code> <code>on</code> needs compiled folder transport No No Feature LoRa OTA <code>ota config</code>; <code>ota cfg</code>; <code>ota set</code> LoRa OTA build No No Yes LoRa OTA <code>ota key</code>; <code>ota keys</code> LoRa OTA build No No Yes LoRa OTA <code>ota dev ...</code> Developer diagnostics No No Yes MQTT <code>get/set mqttN.preset</code> MQTT observer No No No MQTT <code>get/set mqttN.server</code>; <code>get/set mqttN.port</code>; <code>get/set mqttN.username</code>; <code>get/set mqttN.password</code> MQTT observer No No No MQTT <code>get/set mqttN.token</code>; <code>get/set mqttN.topic</code>; <code>get/set mqttN.audience</code> MQTT observer No No No MQTT <code>get mqttN.diag</code> MQTT observer No No No MQTT <code>get/set mqtt.origin</code>; <code>get/set mqtt.iata</code>; <code>get mqtt.presets</code> MQTT observer No No No MQTT <code>get mqtt.stats</code> MQTT observer No No No MQTT <code>get/set mqtt.status</code>; <code>get/set mqtt.packets</code>; <code>get/set mqtt.raw</code>; <code>get/set mqtt.interval</code> MQTT observer No No No MQTT <code>get/set mqtt.rx</code>; <code>get/set mqtt.tx</code> MQTT observer No No No MQTT <code>get/set mqtt.neighbors</code>; <code>get/set mqtt.neighbors.interval</code> MQTT observer with compiled neighbor support No No No MQTT <code>get/set mqtt.ntp</code> MQTT observer No No No MQTT <code>get mqtt.ntp.diag</code> Full MQTT observer No No No MQTT <code>get/set timezone</code>; <code>get/set timezone.offset</code> MQTT observer No No No MQTT <code>get/set mqtt.analyzer.us</code>; <code>get/set mqtt.analyzer.eu</code> Legacy MQTT aliases No No No MQTT <code>get/set mqtt.owner</code>; <code>get/set mqtt.email</code> MQTT observer; <code>get</code> is local serial only No No No MQTT <code>get mqtt.config.valid</code> MQTT observer No No No SNMP <code>get/set snmp</code>; <code>get/set snmp.community</code> MQTT target compiled with SNMP No No No Alerts <code>get/set alert</code>; <code>get/set alert.psk</code>; <code>get/set alert.hashtag</code>; <code>get/set alert.region</code>; <code>get/set alert.wifi</code>; <code>get/set alert.mqtt</code>; <code>get/set alert.interval</code> MQTT observer No No No Alerts <code>alert test [message]</code> MQTT observer with configured alert channel No No No TLS <code>tls.bundletest &lt;host&gt;</code> MQTT target with embedded certificate bundle No No No Manifest OTA <code>ota check</code> MQTT target with <code>OTA_MANIFEST_BASE</code> No No No Manifest OTA <code>ota update</code> MQTT target with <code>OTA_MANIFEST_BASE</code> No No No"},{"location":"cli_command_availability/#esp32","title":"ESP32","text":"Area Command Scope Standard Logging LoRa OTA FULL unified FULL fallback Operational <code>reboot</code> All text CLI roles Yes Yes Yes Yes Yes Operational <code>poweroff</code>; <code>shutdown</code> Board power-off support Yes Yes Yes Yes Yes Operational <code>uf2reset</code> nRF52 only No No No No No Operational <code>clkreboot</code> Full parser Yes Yes Yes Yes Yes Operational <code>clock sync</code> All text CLI roles Yes Yes Yes Yes Yes Operational <code>clock</code> All text CLI roles Yes Yes Yes Yes Yes Operational <code>time &lt;epoch_seconds&gt;</code> Clock only moves forward Yes Yes Yes Yes Yes Operational <code>advert</code> Advert-capable role Yes Yes Yes Yes Yes Operational <code>advert.zerohop</code> Advert-capable role Yes Yes Yes Yes Yes Operational <code>erase</code> Local serial Serial Serial Serial Serial Serial Display <code>get/set display.timeout</code>; <code>get/set display.flip</code> MQTT observer with display; flip needs a supported driver No No No Feature No Information <code>ver</code> All text CLI roles Yes Yes Yes Yes Yes Information <code>board</code> All text CLI roles Yes Yes Yes Yes Yes Diagnostics <code>get storage.layout</code> Detected flash size and live partition table Yes Yes Yes Yes Yes Diagnostics <code>memory</code> ESP32 heap and PSRAM summary Yes Yes Yes Yes Yes Diagnostics <code>sensor</code> Hardware wiring summary Yes Yes Yes Yes Yes Diagnostics <code>powerlog</code> Reset-reason summary Yes Yes Yes Yes Yes Neighbors <code>neighbors</code> Role with a neighbor table Yes Yes Yes Yes Yes Neighbors <code>neighbor.remove &lt;pubkey_prefix&gt;</code> Role with a mutable neighbor table Yes Yes Yes Yes Yes Neighbors <code>discover.neighbors</code> Repeater; some MQTT room servers Yes Yes Yes Yes Yes Neighbors <code>discover.scopes</code> MQTT observer with compiled neighbor support No No No Feature No Statistics <code>clear stats</code> Full parser Yes Yes Yes Yes Yes Statistics <code>stats-core</code> Local serial Serial Serial Serial Serial Serial Statistics <code>stats-radio</code> Local serial Serial Serial Serial Serial Serial Statistics <code>stats-radio-diag</code> Local serial Serial Serial Serial Serial Serial Statistics <code>stats-packets</code> Local serial Serial Serial Serial Serial Serial Statistics <code>get telemetry.temp/volt/volt.i2c</code>; optional GPS history Non-STM32 repeater or room server; I2C command requires a detected voltage monitor; GPS requires a provider; remote access requires administrator Yes Yes Yes Yes Yes Statistics <code>set telemetry.gps</code>; <code>get/set/send telemetry.tx</code> Non-STM32 repeater; GPS setting requires a provider; remote access requires administrator Yes Yes Yes Yes Yes Logging <code>log start</code>; <code>log stop</code>; <code>log erase</code> Storage-backed roles retain data Yes Yes Yes Yes Yes Logging <code>log</code> Local serial Serial Serial Serial Serial Serial Logging <code>get/set usb.logging</code>; unified FULL <code>get/set logging.output</code> Ordinary safe-USB artifacts; CommonCLI USB gate is persistent; unified ESP32 FULL selects off/USB/WiFi/both; every ESP32 Full Companion uses an input-capable single-TTY logging terminal with framed USB Companion disabled while logging Yes Yes No No Yes Radio <code>get radio</code>; <code>set radio ...</code> All text CLI roles Yes Yes Yes Yes Yes Radio <code>get tx</code>; <code>set tx &lt;dbm&gt;</code> Board TX-power limits apply Yes Yes Yes Yes Yes Radio <code>tempradio ...</code>; <code>normalradio</code> Full parser Yes Yes Yes Yes Yes Radio <code>get/set/del radioat</code>; <code>get/set/del tempradioat</code> Full parser Yes Yes Yes Yes Yes Radio <code>get freq</code>; <code>set freq &lt;mhz&gt;</code> <code>set</code> is local serial only Yes Yes Yes Yes Yes Radio <code>get/set radio.rxgain</code> Supported radio Feature Feature Feature Feature Feature Radio <code>get/set espnow.channel</code> Primary ESP-NOW mesh radio Feature Feature Feature Feature Feature Radio <code>get/set radio.fem.rxgain</code> Controllable LoRa FEM Feature Feature Feature Feature Feature Radio <code>get/set radio.fem.txgain</code> Controllable LoRa FEM Feature Feature Feature Feature Feature Radio <code>get/set radio.rxps</code>; <code>get rxps.wd</code> Full parser and RX power-saving support Feature Feature Feature Feature Feature System <code>get/set name</code> All full-parser text CLI roles Yes Yes Yes Yes Yes System <code>get/set lat</code> All full-parser text CLI roles Yes Yes Yes Yes Yes System <code>get/set lon</code> All full-parser text CLI roles Yes Yes Yes Yes Yes System <code>get/set prv.key</code> <code>get</code> is local serial only Yes Yes Yes Yes Yes System <code>password &lt;new_password&gt;</code> Administrator Yes Yes Yes Yes Yes System <code>get/set guest.password</code> Role with guest administration Yes Yes Yes Yes Yes System <code>get/set owner.info</code> Full parser Yes Yes Yes Yes Yes System <code>get/set adc.multiplier</code> Board ADC override support Feature Feature Feature Feature Feature System <code>send text.flood &lt;message&gt;</code> Repeater Yes Yes Yes Yes Yes System <code>host &lt;text&gt;</code>; <code>get host</code> Repeater with host bridge; <code>host</code> requires a remote administrator and a USB/MQTT service Yes Yes Yes Yes Yes System <code>get/set battery.alert</code>; <code>get battery.alert.region</code> Repeater Yes Yes Yes Yes Yes System <code>get/set battery.alert.low</code>; <code>get/set battery.alert.critical</code> Repeater Yes Yes Yes Yes Yes System <code>get/set rx.watchdog</code> Repeater Yes Yes Yes Yes Yes System <code>get/set system.watchdog</code> nRF52 only No No No No No System <code>get public.key</code> Full parser Yes Yes Yes Yes Yes System <code>get role</code> All text CLI roles Yes Yes Yes Yes Yes System <code>powersaving</code>; <code>powersaving on/off</code> Supported repeater board Feature Feature Feature Feature Feature System <code>get/set reboot.interval</code> Full parser Yes Yes Yes Yes Yes Clock sync <code>get/set clock.sync.*</code>; <code>clock.sync.mesh now</code> Repeater, sensor, and room server; <code>clock.sync.internet</code> needs MQTT repeater Yes Yes Yes Yes Yes Routing <code>get/set repeat</code> Forwarding-capable role Yes Yes Yes Yes Yes Routing <code>get/set path.hash.mode</code> Full parser Yes Yes Yes Yes Yes Routing <code>get/set loop.detect</code> Repeater, full common parser Yes Yes Yes Yes Yes Routing <code>get/set txdelay</code> All text CLI roles, including bridges Yes Yes Yes Yes Yes Routing <code>get/set direct.txdelay</code> Full parser Yes Yes Yes Yes Yes Routing <code>get/set rxdelay</code> All text CLI roles, including bridges Yes Yes Yes Yes Yes Routing <code>get/set dutycycle</code> Full parser Yes Yes Yes Yes Yes Routing <code>get/set af</code> Full parser Yes Yes Yes Yes Yes Routing <code>get/set int.thresh</code> All text CLI roles Yes Yes Yes Yes Yes Routing <code>get/set cad</code> Radio CAD support Feature Feature Feature Feature Feature Routing <code>get/set agc.reset.interval</code> All text CLI roles Yes Yes Yes Yes Yes Routing <code>get/set radio.watchdog</code> MQTT observer No No No Yes No Routing <code>get/set multi.acks</code> Full parser Yes Yes Yes Yes Yes Routing <code>get/set flood.advert.interval</code> Repeater, full common parser Yes Yes Yes Yes Yes Routing <code>get/set advert.interval</code> Full common parser Yes Yes Yes Yes Yes Routing <code>get/set flood.max</code> Repeater, full common parser Yes Yes Yes Yes Yes Routing <code>get/set flood.max.unscoped</code> Repeater, full common parser Yes Yes Yes Yes Yes Routing <code>get/set flood.max.advert</code> Repeater, full common parser Yes Yes Yes Yes Yes Routing <code>get/set flood.channel.data</code>; <code>get/set flood.channel.data.hops</code> Repeater, full common parser Yes Yes Yes Yes Yes Routing <code>get/set/del flood.channel.scope*</code> Repeater role handler Yes Yes Yes Yes Yes Routing <code>get/set/del flood.channel.scope.require*</code> Repeater role handler Yes Yes Yes Yes Yes Routing <code>get/set/del flood.rule*</code>; <code>get/set/del flood.filter*</code>; <code>get/set/del flood.filter.blacklist*</code> Repeater role handler; <code>flood.rule</code>/<code>flood.filter</code> also on FULL ESP32 room server (no blacklist) Yes Yes Yes Yes Yes Routing <code>get/set/del flood.moderation*</code> Repeater role handler Yes Yes Yes Yes Yes Routing <code>get/set outpath</code> Repeater remote-client context Yes Yes Yes Yes Yes Routing <code>get/set altpath</code> Repeater remote-client context Yes Yes Yes Yes Yes ACL <code>setperm &lt;pubkey&gt; &lt;permissions&gt;</code> Repeater, room server, or sensor Yes Yes Yes Yes Yes ACL <code>get acl</code> Local serial Serial Serial Serial Serial Serial ACL <code>get/set allow.read.only</code> Room server Yes Yes No Yes Yes Regions <code>region load</code>; <code>region save</code> Role with region storage Yes Yes Yes Yes Yes Regions <code>region allowf</code>; <code>region denyf</code> Role with region storage Yes Yes Yes Yes Yes Regions <code>region get</code>; <code>region list</code>; <code>region</code> Role with region storage Yes Yes Yes Yes Yes Regions <code>region home</code>; <code>region default</code> Role with region storage Yes Yes Yes Yes Yes Regions <code>region put</code>; <code>region def</code>; <code>region remove</code> Role with region storage Yes Yes Yes Yes Yes Retry <code>get/set direct.retry</code>; <code>get/set direct.retry.heard</code> Role with basic retry support Yes Yes Yes Yes Yes Retry <code>get/set retry.preset</code> Role with retry support Yes Yes Yes Yes Yes Retry <code>get/set flood.retry.count</code>; <code>get/set flood.retry.path</code>; <code>get/set flood.retry.group.path</code> Repeater Yes Yes Yes Yes Yes Retry <code>get/set flood.retry.advert</code>; <code>get/set flood.retry.prefixes</code>; <code>get/set flood.retry.ignore</code> Repeater Yes Yes Yes Yes Yes Retry <code>get/set flood.retry.bridge</code>; <code>get/set flood.retry.bucket</code> Repeater bridge retry support Feature Feature Feature Feature Feature Retry <code>get/set direct.retry.count</code>; <code>get/set direct.retry.base</code>; <code>get/set direct.retry.step</code> Role with retry support Yes Yes Yes Yes Yes Retry <code>get/set direct.retry.margin</code>; <code>get/set direct.retry.cr</code> Role with retry support Yes Yes Yes Yes Yes Retry <code>get/set/clear recent.repeater</code>; <code>get recent.repeaters</code> Repeater Yes Yes Yes Yes Yes GPS <code>gps</code>; <code>gps on/off</code> Compiled onboard GPS Feature Feature Feature Feature Feature GPS <code>gps sync</code> Compiled onboard GPS Feature Feature Feature Feature Feature GPS <code>gps setloc</code> Compiled onboard GPS Feature Feature Feature Feature Feature GPS <code>gps advert [none/share/prefs]</code> Compiled onboard GPS Feature Feature Feature Feature Feature Sensors <code>get/set telemetry.access</code> Sensor-capable full parser Feature Feature Limited Feature Feature Sensors <code>sensor list [start]</code> Compiled sensor manager; <code>no_external_sensors</code> trims target-selected environmental/ranging drivers, not generic I2C Feature Feature Limited Feature Feature Sensors <code>sensor get</code>; <code>sensor set</code> Compiled sensor setting; <code>no_external_sensors</code> trims target-selected environmental/ranging drivers, not generic I2C Feature Feature Limited Feature Feature Sensors <code>io [r/s/t]&lt;hex&gt;</code> Simple sensor role with board GPIO support Feature Feature No No Feature Bridge <code>get bridge.type</code> Compiled bridge Feature Feature Feature Yes Feature Bridge <code>get/set bridge.enabled</code>; <code>get bridge.running</code> Compiled bridge Feature Feature Feature Yes Feature Bridge <code>get/set bridge.delay</code> Compiled bridge Feature Feature Feature Yes Feature Bridge <code>get/set bridge.source</code> Compiled bridge Feature Feature Feature Yes Feature Bridge <code>get/set bridge.baud</code> RS-232 bridge Feature Feature Feature No Feature Bridge <code>get/set bridge.uart</code> RS-232 bridge Feature Feature Feature No Feature Bridge <code>get/set bridge.channel</code> ESP-NOW bridge No No No Feature Feature Bridge <code>get/set bridge.format</code> ESP-NOW bridge No No No Feature Feature Bridge <code>get/set bridge.secret</code> ESP-NOW bridge No No No Feature Feature Board <code>get bootloader.ver</code> nRF52 only No No No No No Board <code>get pwrmgt.support</code>; <code>get pwrmgt.source</code>; <code>get pwrmgt.bootreason</code>; <code>get pwrmgt.bootmv</code> nRF52 only No No No No No Ethernet <code>eth.status</code> Ethernet target Feature Feature No No Feature Browser OTA <code>start ota [ap]</code>; <code>stop ota</code> Compiled browser uploader No No Yes Feature Feature WebConfig <code>start webconfig [ap]</code>; <code>stop webconfig</code>; <code>get/set webui</code> Compiled WebConfig No No No Feature Feature WiFi <code>get/set wifi.ssid</code>; <code>set wifi.pwd</code>; <code>get wifi.status</code>; <code>get/set wifi.powersave</code> MQTT WiFi, or standalone FULL WebConfig; standalone has no <code>get wifi.pwd</code> No No No Yes Feature WiFi <code>get/set wifi.cli</code> Compiled WebConfig No No No Feature Feature LoRa OTA <code>ota help</code>; <code>ota ?</code>; <code>ota h</code> LoRa OTA build No No Yes Yes Yes LoRa OTA <code>ota</code>; <code>ota status</code>; <code>ota st</code> LoRa OTA build No No Yes Yes Yes LoRa OTA <code>ota stats</code> LoRa OTA build No No Yes Yes Yes LoRa OTA <code>ota ls</code>; <code>ota neighbors</code>; <code>ota nbrs</code>; <code>ota updates</code>; <code>ota n</code> LoRa OTA build No No Yes Yes Yes LoRa OTA <code>ota get</code>; <code>ota pull</code>; <code>ota download</code> LoRa OTA build No No Yes Yes Yes LoRa OTA <code>ota install</code>; <code>ota apply</code>; <code>ota applydelta</code> Compatible completed update No No Yes Yes Yes LoRa OTA <code>ota rescue install &lt;base_hash16&gt;</code> Legacy internal-flash nRF52 LoRa OTA build with failed app-side EndF validation; shared bootloader-update builds require valid EndF No No Feature No No LoRa OTA <code>ota bootloader</code>; <code>ota bootloader install &lt;MID8&gt; &lt;HASH16&gt;</code> Allowlisted nRF52 internal/QSPI repeater feature No No No No No LoRa OTA <code>ota cancel</code>; <code>ota drop</code>; <code>ota stop</code> LoRa OTA build No No Yes Yes Yes LoRa OTA <code>ota announce</code>; <code>ota adv</code> LoRa OTA build No No Yes Yes Yes LoRa OTA <code>ota self</code>; <code>ota id</code> Firmware with EndF trailer No No Yes Yes Yes LoRa OTA <code>ota qspi</code>; <code>ota storage</code> nRF52 build with raw-QSPI OTA staging No No No No No LoRa OTA <code>ota folder</code>; <code>ota fold</code> <code>on</code> needs compiled serial or TCP folder transport No No Feature Feature Feature LoRa OTA <code>ota config</code>; <code>ota cfg</code>; <code>ota set</code> LoRa OTA build No No Yes Yes Yes LoRa OTA <code>ota key</code>; <code>ota keys</code> LoRa OTA build No No Yes Yes Yes LoRa OTA <code>ota dev ...</code> Developer diagnostics No No Yes Yes Yes MQTT <code>get/set mqttN.preset</code> MQTT observer No No No Yes No MQTT <code>get/set mqttN.server</code>; <code>get/set mqttN.port</code>; <code>get/set mqttN.username</code>; <code>get/set mqttN.password</code> MQTT observer No No No Yes No MQTT <code>get/set mqttN.token</code>; <code>get/set mqttN.topic</code>; <code>get/set mqttN.audience</code> MQTT observer No No No Yes No MQTT <code>get mqttN.diag</code> MQTT observer No No No Yes No MQTT <code>get/set mqtt.origin</code>; <code>get/set mqtt.iata</code>; <code>get mqtt.presets</code> MQTT observer No No No Yes No MQTT <code>get mqtt.stats</code> MQTT observer No No No Yes No MQTT <code>get/set mqtt.status</code>; <code>get/set mqtt.packets</code>; <code>get/set mqtt.raw</code>; <code>get/set mqtt.interval</code> MQTT observer No No No Yes No MQTT <code>get/set mqtt.rx</code>; <code>get/set mqtt.tx</code> MQTT observer No No No Yes No MQTT <code>get/set mqtt.neighbors</code>; <code>get/set mqtt.neighbors.interval</code> MQTT observer with compiled neighbor support No No No Feature No MQTT <code>get/set mqtt.ntp</code> MQTT observer No No No Yes No MQTT <code>get mqtt.ntp.diag</code> MQTT observer No No No Yes No MQTT <code>get/set timezone</code>; <code>get/set timezone.offset</code> MQTT observer No No No Yes No MQTT <code>get/set mqtt.analyzer.us</code>; <code>get/set mqtt.analyzer.eu</code> Legacy MQTT aliases No No No Yes No MQTT <code>get/set mqtt.owner</code>; <code>get/set mqtt.email</code> MQTT observer; <code>get</code> is local serial only No No No Yes No MQTT <code>get mqtt.config.valid</code> MQTT observer No No No Yes No SNMP <code>get/set snmp</code>; <code>get/set snmp.community</code> MQTT target compiled with SNMP No No No Feature No Alerts <code>get/set alert</code>; <code>get/set alert.psk</code>; <code>get/set alert.hashtag</code>; <code>get/set alert.region</code>; <code>get/set alert.wifi</code>; <code>get/set alert.mqtt</code>; <code>get/set alert.interval</code> MQTT observer No No No Yes No Alerts <code>alert test [message]</code> MQTT observer with configured alert channel No No No Yes No TLS <code>tls.bundletest &lt;host&gt;</code> MQTT target with embedded certificate bundle No No No Feature No Manifest OTA <code>ota check</code> MQTT target with <code>OTA_MANIFEST_BASE</code> No No No Manifest No Manifest OTA <code>ota update</code> MQTT target with <code>OTA_MANIFEST_BASE</code> No No No Manifest No"},{"location":"cli_command_availability/#supplemental-command-notes","title":"Supplemental command notes","text":"<p>These short entries cover implemented commands that do not yet have their own section in the primary command reference.</p>"},{"location":"cli_command_availability/#memory","title":"<code>memory</code>","text":"<p>ESP32 only. Prints free heap, minimum heap, largest allocation, queue depth, internal heap, and PSRAM totals.</p>"},{"location":"cli_command_availability/#sensor-hardware-summary","title":"<code>sensor</code> hardware summary","text":"<p>Prints the configured I2C pins and GPS serial pins. This is a wiring/build diagnostic, distinct from <code>sensor list</code>, <code>sensor get</code>, and <code>sensor set</code>.</p>"},{"location":"cli_command_availability/#powerlog","title":"<code>powerlog</code>","text":"<p>Prints the last reset reason. nRF52 also prints the captured shutdown reason and boot voltage.</p>"},{"location":"cli_command_availability/#stats-radio-diag","title":"<code>stats-radio-diag</code>","text":"<p>Local-serial diagnostic that prints the extended radio diagnostic counters.</p> <p></p>"},{"location":"cli_command_availability/#radiorxps-and-rxpswd","title":"<code>radio.rxps</code> and <code>rxps.wd</code>","text":"<p><code>get radio.rxps</code> reports RX power-saving state and timing. <code>set radio.rxps ...</code> changes that configuration. <code>get rxps.wd</code> reports the soft and hard RX power-saving watchdog counters.</p> <p></p>"},{"location":"cli_command_availability/#rebootinterval","title":"<code>reboot.interval</code>","text":"<p><code>get reboot.interval</code> shows the scheduled reboot interval. Use <code>set reboot.interval &lt;hours&gt;</code> for 1-255 hours, or <code>set reboot.interval 0</code> to disable it.</p> <p></p>"},{"location":"cli_command_availability/#sensor-io","title":"Sensor <code>io</code>","text":"<p>The simple-sensor role exposes its board GPIO word as hexadecimal. <code>io</code> reads it; <code>io &lt;hex&gt;</code> replaces it; and <code>io r&lt;hex&gt;</code>, <code>io s&lt;hex&gt;</code>, or <code>io t&lt;hex&gt;</code> clear, set, or toggle selected bits.</p> <p></p>"},{"location":"cli_command_availability/#get-mqttndiag","title":"<code>get mqttN.diag</code>","text":"<p>Prints the runtime diagnostic summary for MQTT slot N, including its connection state and failure history.</p> <p></p>"},{"location":"cli_command_availability/#get-mqttstats","title":"<code>get mqtt.stats</code>","text":"<p>Prints the MQTT bridge runtime statistics summary.</p> <p></p>"},{"location":"cli_command_availability/#get-mqttconfigvalid","title":"<code>get mqtt.config.valid</code>","text":"<p>Reports whether the saved MQTT configuration has the minimum values needed to run.</p> <p></p>"},{"location":"cli_command_availability/#tlsbundletest","title":"<code>tls.bundletest</code>","text":"<p><code>tls.bundletest &lt;host[:port]|url&gt;</code> tests the embedded TLS certificate bundle against a remote host without changing the MQTT configuration.</p> <p></p>"},{"location":"cli_command_availability/#manifest-ota-check-and-ota-update","title":"Manifest <code>ota check</code> and <code>ota update</code>","text":"<p>On MQTT targets with <code>OTA_MANIFEST_BASE</code>, <code>ota check</code> fetches and checks the target manifest. <code>ota update</code> downloads and applies the compatible update selected by that manifest.</p>"},{"location":"cli_commands/","title":"CLI Commands","text":"<p>This document provides an overview of CLI commands that can be sent to MeshCore Repeaters, Room Servers and Sensors.</p> <p>See CLI Availability by Firmware Build for the role and profile matrix, including the commands intentionally omitted from portable firmware.</p> <p>See CLI Command Availability Matrix for the command-by-command nRF52 and ESP32 build tables.</p> <p>The first word of a command is case-insensitive, so <code>set</code>, <code>Set</code>, and <code>SET</code> are equivalent, as are <code>get</code>, <code>Get</code>, and the other command verbs. The case of arguments such as node names, passwords, and keys is left unchanged.</p>"},{"location":"cli_commands/#navigation","title":"Navigation","text":"<ul> <li>Operational</li> <li>Neighbors</li> <li>Statistics</li> <li>Logging</li> <li>Information</li> <li>Configuration</li> <li>Radio</li> <li>System<ul> <li>GPIO</li> </ul> </li> <li>Routing</li> <li>Flood Rules</li> <li>Group Text Moderation</li> <li>ACL</li> <li>Region Management<ul> <li>Region Examples</li> </ul> </li> <li>GPS</li> <li>Sensors</li> <li>Bridge</li> <li>Ethernet</li> </ul>"},{"location":"cli_commands/#operational","title":"Operational","text":""},{"location":"cli_commands/#reboot-the-node","title":"Reboot the node","text":"<p>Usage:  - <code>reboot</code></p> <p>Note: No reply is sent.</p>"},{"location":"cli_commands/#power-off-the-node","title":"Power-off the node","text":"<p>Usage: - <code>poweroff</code>, or - <code>shutdown</code></p> <p>Note: No reply is sent.</p>"},{"location":"cli_commands/#enter-the-uf2-bootloader-nrf52-only","title":"Enter the UF2 bootloader (nRF52 only)","text":"<p>Usage: - <code>uf2reset</code></p> <p>Serial Only: Yes</p> <p>Note: Reboots directly into the UF2 bootloader on supported nRF52 boards.</p>"},{"location":"cli_commands/#reset-the-clock-and-reboot","title":"Reset the clock and reboot","text":"<p>Usage: - <code>clkreboot</code></p> <p>Note: No reply is sent.</p>"},{"location":"cli_commands/#sync-the-clock-with-the-remote-device","title":"Sync the clock with the remote device","text":"<p>Usage:  - <code>clock sync</code></p>"},{"location":"cli_commands/#display-current-time-in-utc","title":"Display current time in UTC","text":"<p>Usage: - <code>clock</code></p>"},{"location":"cli_commands/#set-the-time-to-a-specific-timestamp","title":"Set the time to a specific timestamp","text":"<p>Usage:  - <code>time &lt;epoch_seconds&gt;</code></p> <p>Parameters: - <code>epoch_seconds</code>: Unix epoch time</p>"},{"location":"cli_commands/#send-a-flood-advert","title":"Send a flood advert","text":"<p>Usage:  - <code>advert</code></p>"},{"location":"cli_commands/#send-a-zero-hop-advert","title":"Send a zero-hop advert","text":"<p>Usage: - <code>advert.zerohop</code></p>"},{"location":"cli_commands/#ask-a-usb-connected-host-service-over-lora-repeater-only","title":"Ask a USB-connected host service over LoRa (Repeater Only)","text":"<p>Usage:</p> <ul> <li><code>host &lt;text&gt;</code> - authenticated remote administrator only</li> <li><code>get host</code> - show bridge state and byte limits</li> </ul> <p><code>host</code> hands one remote LoRa CLI request to a service on the repeater's USB host and returns that service's reply over LoRa. It does not execute the text inside the firmware. The service has 4 seconds to prove the exact request is still pending, then 6 seconds to execute and reply. A second remote command receives busy while either phase is pending.</p> <p>Request text is limited to 155 UTF-8 bytes, or 152 bytes when a companion uses its legacy three-byte correlation prefix. The complete LoRa reply is limited to 162 bytes. USB records use Base64URL text, a random 64-bit nonce, and the repeater identity's Ed25519 signature. Before executing anything, the service must return a random one-time challenge and receive the repeater's signed live proof. This avoids any dependency on repeater/Pi clock agreement. Every <code>host.reply</code> USB command must carry the matching request ID and nonce; it is not accepted from LoRa or the Ethernet CLI.</p> <p>The included Raspberry Pi endpoint supports exact commands for <code>help</code>, <code>cpu-temp</code>, <code>hostname</code>, <code>uptime</code>, <code>load</code>, <code>memory</code>, <code>disk-free</code>, and <code>clock status</code>. It also provides strictly validated <code>clock sync</code> and <code>clock set &lt;unix_epoch&gt;</code> recovery actions, opt-in <code>network restart</code> and <code>reboot</code> actions, <code>action status &lt;operation_id&gt;</code>, and <code>run &lt;alias&gt; [arguments]</code> for locally allowlisted executables with typed arguments. Clock changes and host recovery actions are disabled by default, arbitrary executables are never accepted, and no action uses a shell. Clock set accepts only canonical unsigned decimal epochs from 2020 through 2099; a root-owned Unix-socket service revalidates the request and authenticates the local service account with <code>SO_PEERCRED</code> before changing system time. Network restart and reboot use a separate root-owned Unix-socket broker with fixed systemd units; installing clock control does not grant those actions. The endpoint never uses <code>sudo</code> for privileged host actions. See LoRa CLI host service for the complete <code>meshcoretomqtt</code> setup and security model.</p>"},{"location":"cli_commands/#start-or-stop-an-over-the-air-ota-firmware-update","title":"Start or stop an Over-The-Air (OTA) firmware update","text":"<p>Usage: - <code>start ota</code> - <code>start ota ap</code> - <code>stop ota</code></p> <p><code>start ota</code> serves the web upload page on the station IP when connected to WiFi; otherwise it raises the <code>MeshCore-OTA</code> access point. <code>start ota ap</code> always raises the access point, which is useful when the normal network uses client isolation.</p> <p>On an ESP32 build with WebConfig, the manual OTA uploader and WebConfig both use HTTP port 80 and cannot run together. Stop WebConfig before <code>start ota</code>, or stop OTA before <code>start webconfig</code>.</p> <p>FULL ESP32 builds also expose the <code>.mota</code> folder seeder on TCP port 5001 whenever WiFi is usable. This listener is independent of port 80, so a host can run <code>motatool serve --dir ./motas --tcp &lt;node-ip&gt;:5001</code> while WebConfig is active. The TCP connection auto-attaches and detaches the folder; do not run <code>ota folder on</code> at the same time because that command selects the USB-serial folder transport.</p>"},{"location":"cli_commands/#browser-configuration-portal-esp32-repeater-and-room-server","title":"Browser configuration portal (ESP32 repeater and room server)","text":"<p>Usage:</p> <ul> <li><code>start webconfig</code></li> <li><code>start webconfig ap</code></li> <li><code>stop webconfig</code></li> <li><code>set webui on</code></li> <li><code>set webui off</code></li> <li><code>get webui</code></li> <li><code>get wifi.ssid</code></li> <li><code>get wifi.status</code></li> <li><code>get wifi.powersave</code></li> <li><code>get wifi.cli</code></li> <li><code>set wifi.ssid &lt;network name&gt;</code></li> <li><code>set wifi.pwd [password]</code></li> <li><code>set wifi.powersave &lt;none|min|max&gt;</code></li> <li><code>set wifi.cli &lt;on|off&gt;</code></li> </ul> <p><code>set webui on</code> is the persistent master switch. It starts the portal now and again after future reboots; <code>set webui off</code> closes it and disables that boot start. <code>get webui</code> reports the saved on/off state plus whether the portal is inactive, joining WiFi, serving a setup AP, or serving a LAN URL. The default is <code>off</code> on repeater and room-server builds. On display-equipped repeaters, an otherwise-unused triple click toggles the same saved setting. Consequently, <code>&gt; off, http://192.168.1.130/</code> means the saved boot setting is off while a temporary WebConfig session is currently active at that URL.</p> <p><code>start webconfig</code> is a temporary start that does not change the saved switch. It serves the shared WiFi, radio, flood, loop, and status page and reports its URL. MQTT builds also show the MQTT tab and wizard step; non-MQTT builds remove them entirely. Sign in with the node's admin password. If the node has no saved WiFi SSID, the command starts the open <code>MeshCore-Setup-XXXX</code> captive AP at http://192.168.4.1/ instead.</p> <p><code>start webconfig ap</code> forces captive-AP mode. It will not interrupt an active MQTT bridge, so run <code>set bridge.enabled off</code> first. Use <code>stop webconfig</code> to close either mode for the current boot. (<code>stop webconfig</code> does not change a saved <code>webui on</code>.) LAN mode otherwise remains active until reboot. On expanded FULL builds, an unconfigured automatic setup AP receives one absolute 30-minute window per boot, then powers WiFi off even if a client remains attached; rebooting starts a new automatic window. An administrator can explicitly run <code>start webconfig</code> again without rebooting. Once an SSID is saved, the cutoff no longer applies and the selected WiFi/MQTT mode keeps reconnecting. Other setup sessions retain their profile's idle timeout.</p> <p>The saved <code>wifi.cli</code> setting defaults to <code>on</code>. Use <code>set wifi.cli off</code> to disable the CLI tab. <code>get wifi.cli</code> reports <code>off</code>, <code>on, waiting for WiFi client</code>, or <code>on, active</code>. The saved setting becomes active only in station/LAN mode while the WiFi client is connected. It is deliberately unavailable on the open setup access point. The tab sends one command at a time through the local administrator command parser and displays the reply in the browser. It uses remote-administrator command permissions, so commands explicitly restricted to a physical serial connection remain unavailable. Select Command block to paste up to 100 commands with one command per line. Blank lines are ignored, and every nonblank line must fit the normal 159-byte CLI command limit. The browser sends the lines sequentially and waits for each reply before sending the next line. The queue exists only in that browser page; closing it stops any commands that have not yet been sent. A lost connection also stops the remaining block.</p> <p>Up/down arrow keys recall commands from the current browser session in single-command mode. A command that stops WebConfig, changes its WiFi connection, disables <code>wifi.cli</code>, or reboots the node stops the remaining block and can close the page before its reply is collected.</p> <p>On unified FULL USB + WiFi and FULL logging-fallback ESP32 repeater/room-server builds, <code>get wifi.ssid</code> reports the saved standalone WebConfig network and <code>get wifi.status</code> reports whether WiFi is unconfigured, off, connecting, running the setup AP, failed, or connected. A connected result includes the SSID, LAN IP, and RSSI. When the shared OTA seeder is running, the reply appends <code>OTA TCP 5001: listening</code> or <code>OTA TCP 5001: client connected</code>. WiFi being off is normal while WebConfig is inactive; run <code>start webconfig</code> when a temporary connection is wanted. <code>get wifi.powersave</code> reports the saved standalone setting as <code>none</code>, <code>min</code>, or <code>max</code>. Fresh Cascade-profile builds default to <code>min</code>; target-default builds use <code>none</code>. A saved setting takes precedence after an upgrade.</p> <p>The WiFi <code>set</code> commands work on MQTT observers and on FULL standalone ESP32 repeater/room-server builds. On a standalone build, changing the SSID or password stops an active WebConfig session; run <code>start webconfig</code> again to use the new credentials. <code>set wifi.pwd</code> with no value selects an open network. Standalone WiFi also accepts an exact 64-character hexadecimal WPA/WPA2 PSK; ordinary passphrases remain limited to 63 characters. Other 64-character values and all longer values are rejected. MQTT observer WiFi passwords retain their fixed 63-character limit. Power-save changes are applied immediately when WiFi is running and otherwise take effect on the next connection. <code>get wifi.pwd</code> is intentionally unavailable so the standalone password is never returned by the CLI.</p> <p>ESP32 WiFi Companion WebConfig exposes the same <code>wifi.powersave</code> values in its WiFi card. Every ESP32 WiFi Companion with WebConfig exposes the standalone <code>wifi.ssid</code>, <code>wifi.status</code>, <code>wifi.powersave</code>, <code>wifi.cli</code>, and WebConfig command families through its USB text terminal. Full Companion exposes the same role-specific terminal on TCP port 5002. Credential writes reply before restarting the WiFi station, so a TCP client should expect to reconnect at the new address; USB password input is masked. Binary Companion clients can use USB, BLE, or TCP port 5000 without the terminal-start token: send command <code>0x42</code> (<code>CMD_RUN_CLI_COMMAND</code>) followed by the same CLI text, such as <code>get wifi.powersave</code> or <code>set wifi.powersave min</code>. WiFi-only Companions accept all three modes. A Full Companion that runs BLE and infrastructure WiFi simultaneously rejects <code>none</code> because coexistence requires modem sleep. Companion device <code>powersaving</code> and LoRa <code>radio.rxps</code> remain independent. On an ESP32 Full Companion whose primary mesh radio is ESP-NOW, <code>max</code> is also unavailable: a station using maximum modem sleep can miss ESP-NOW broadcasts, which the access point does not buffer for it. A previously saved conflicting value is capped to and reported as <code>min</code>, and a new conflicting selection is rejected. The primary mesh radio also holds the ESP-IDF WiFi wake reference continuously so unsolicited ESP-NOW frames remain receivable; selecting <code>min</code> does not put that primary receiver to sleep.</p> <p>SenseCAP Indicator Full is the exclusive-secondary exception. On a WiFi-selected boot, LoRa accepts <code>none|min|max</code> and ESP-NOW accepts <code>none|min</code>. On a BLE-selected boot infrastructure WiFi is not started; LoRa accepts <code>min|max</code> for the saved WiFi setting, while ESP-NOW + BLE requires <code>min</code>. USB and the primary LoRa or ESP-NOW radio remain available in every mode.</p>"},{"location":"cli_commands/#view-or-change-the-primary-esp-nowwifi-channel","title":"View or change the primary ESP-NOW/WiFi channel","text":"<p>Usage:</p> <ul> <li><code>get espnow.channel</code></li> <li><code>set espnow.channel &lt;channel&gt;</code></li> </ul> <p>Parameters:</p> <ul> <li><code>channel</code>: Shared 2.4 GHz WiFi channel from <code>1</code> through <code>13</code>; choose one   permitted in your region and supported by the router.</li> </ul> <p>Default: <code>1</code></p> <p>This command is available when ESP-NOW is the node's primary mesh radio. The setting is persisted. A <code>set</code> reply reports that reboot is required; until reboot, the running ESP-NOW radio remains on its previous channel. On builds that also provide ordinary WiFi, its station and setup AP share that channel.</p> <p>After reboot, ESP-NOW, the setup AP, and the infrastructure-WiFi station use the selected channel. Every primary ESP-NOW node that must communicate with this node, plus the configured router's 2.4 GHz radio, must use the same fixed channel. WiFi power saving does not allow the transports to use different channels. On an ESP32 Full build with primary ESP-NOW, <code>wifi.powersave max</code> is unavailable because maximum modem sleep can miss ESP-NOW broadcasts; use <code>min</code> for coexistence. The firmware keeps the primary ESP-NOW receiver awake while still using the <code>min</code> WiFi/Bluetooth coexistence policy.</p> <p><code>espnow.channel</code> is the channel of the primary ESP-NOW mesh transport. It is separate from <code>bridge.channel</code>, which configures only an ESP-NOW bridge on a firmware role whose primary mesh radio is LoRa.</p> <p>The browser portal is not compiled into the two 4 MB <code>LilyGo_TLora_V2_1_1_6_*_observer_mqtt</code> targets because it does not fit while retaining the two app slots required for LoRa OTA. Their normal CLI settings remain available.</p>"},{"location":"cli_commands/#erasefactory-reset","title":"Erase/Factory Reset","text":"<p>Usage: - <code>erase</code></p> <p>Serial Only: Yes</p> <p>Warning: This is destructive!</p>"},{"location":"cli_commands/#neighbors-repeater-only","title":"Neighbors (Repeater Only)","text":""},{"location":"cli_commands/#list-nearby-neighbors","title":"List nearby neighbors","text":"<p>Usage:  - <code>neighbors</code></p> <p>Note: The output of this command is limited to the 8 most recent adverts.</p> <p>Note: Each line is encoded as <code>{pubkey-prefix}:{timestamp}:{snr*4}</code></p>"},{"location":"cli_commands/#remove-a-neighbor","title":"Remove a neighbor","text":"<p>Usage:  - <code>neighbor.remove &lt;pubkey_prefix&gt;</code></p> <p>Parameters:  - <code>pubkey_prefix</code>: The public key of the node to remove from the neighbors list</p>"},{"location":"cli_commands/#discover-zero-hop-neighbors","title":"Discover zero hop neighbors","text":"<p>Usage:  - <code>discover.neighbors</code></p> <p>This command is available in every repeater build profile, including portable MQTT, standard, logging, OTA, unified FULL, and FULL logging-fallback artifacts. It does not require MQTT or PSRAM.</p>"},{"location":"cli_commands/#discover-neighbor-scopes-mqtt-observer-neighbors-feature","title":"Discover neighbor scopes (MQTT observer, neighbors feature)","text":"<p>Refreshes the zero-hop neighbor table, then queries each neighbor for its region scopes and publishes the assembled table to the MQTT <code>neighbors</code> topic once.</p> <p>Usage: - <code>discover.scopes</code></p> <p>Note: Requires an MQTT observer build with the neighbors feature compiled in (all PSRAM boards, plus non-PSRAM boards built with <code>MQTT_NEIGHBORS_WITHOUT_PSRAM</code>). Elsewhere it replies <code>Err - neighbors not enabled in this build</code>. If a <code>discover.neighbors</code> refresh is already in flight, the scope pass is queued behind it.</p>"},{"location":"cli_commands/#statistics","title":"Statistics","text":""},{"location":"cli_commands/#clear-stats","title":"Clear Stats","text":"<p>Usage: <code>clear stats</code></p> <p></p>"},{"location":"cli_commands/#system-stats-battery-uptime-queue-length-and-debug-flags","title":"System Stats - Battery, Uptime, Queue Length and Debug Flags","text":"<p>Usage:  - <code>stats-core</code></p> <p>Serial Only: Yes</p> <p></p>"},{"location":"cli_commands/#radio-stats-noise-floor-last-rssisnr-airtime-receive-errors","title":"Radio Stats - Noise floor, Last RSSI/SNR, Airtime, Receive errors","text":"<p>Usage: <code>stats-radio</code></p> <p>Serial Only: Yes</p> <p></p>"},{"location":"cli_commands/#packet-stats-packet-counters-received-sent","title":"Packet stats - Packet counters: Received, Sent","text":"<p>Usage: <code>stats-packets</code></p> <p>Serial Only: Yes</p> <p></p>"},{"location":"cli_commands/#read-repeater-and-room-server-telemetry-history","title":"Read repeater and room-server telemetry history","text":"<p>Repeater and room-server firmware record one UTC-aligned sample every 30 minutes. Temperature and battery voltage retain 336 samples (seven rolling days). Each detected INA219, INA226, INA260, or INA3221 voltage channel retains 192 samples (four rolling days). GPS-capable builds retain three GPS days by default; repeaters request a seven-day default at startup. Builds without a GPS provider omit the GPS history commands to conserve flash. All history and any runtime retention change are held in RAM and reset after a reboot.</p> <p>The feature is omitted from flash-constrained STM32 repeater and room images.</p> <p>Usage:</p> <ul> <li><code>get telemetry.temp [page]</code></li> <li><code>get telemetry.volt [page]</code></li> <li><code>get telemetry.volt.i2c [channel [page]]</code></li> <li><code>get telemetry.gps [page]</code></li> <li><code>set telemetry.gps &lt;days&gt;</code></li> <li><code>get telemetry.tx</code></li> <li><code>set telemetry.tx &lt;off|direct|path&gt;</code></li> <li><code>set telemetry.tx schedule &lt;off|1-30d&gt;</code></li> <li><code>send telemetry.tx now</code></li> </ul> <p>Parameters:</p> <ul> <li><code>page</code>: Page <code>1</code> is always newest. Temperature and voltage pages each hold   24 hours and accept <code>1</code>-<code>7</code>. GPS pages each hold 12 hours and accept <code>1</code>   through twice the current GPS retention in days. Omitting the page selects   page <code>1</code>.</li> <li><code>channel</code>: Cayenne LPP channel assigned to an external voltage monitor.   <code>get telemetry.volt.i2c</code> lists channels that have at least one non-zero   sample. Supplying a channel returns 48 points (24 hours) per page; pages   <code>1</code>-<code>4</code> cover all four days. A detected input whose complete retained history   is zero is treated as disconnected and is omitted until it reports a   non-zero voltage. An INA3221 contributes three consecutive entries, in   hardware-input order. If it is the only detected external sensor these are   normally LPP channels <code>2</code>, <code>3</code>, and <code>4</code>; always use the no-argument command   as the authoritative list because earlier detected sensors shift the LPP   numbers.</li> <li><code>days</code>: Requested GPS retention from <code>1</code> through <code>30</code> days. Retention above   three days uses heap memory. The allocator reduces the requested value as   needed to leave at least 2048 bytes free and replies with the days and pages   actually available. For example, a request can return   <code>OK - telemetry.gps days=18 pages=36 requested=30</code>.</li> <li><code>direct</code>: Send the binary temperature and voltage snapshots zero-hop to a   neighboring MQTT observer.</li> <li><code>path</code>: A comma-separated direct route using the same one-, two-, or   three-byte hop hashes accepted by <code>set outpath</code>.</li> <li><code>schedule</code>: Automatic interval in whole days. The default is <code>2d</code>; <code>off</code>   retains the configured direct path for manual test sends.</li> </ul> <p>Local serial and remote administrator CLI sessions can read the history on both roles. Collection uses the MCU temperature, battery voltage, external I2C voltage monitors, and an already-valid onboard GPS fix. It does not wake GPS, so an off, sleeping, or unfixed GPS produces a missing location sample without changing its power-saving schedule.</p> <p>External voltage history allocates 360 bytes for each detected monitor channel (1,080 bytes for all three INA3221 inputs). The allocation reserves all detected inputs so a sensor connected later can start recording, but all-zero inputs are omitted from command replies and LoRa transmission.</p> <p>Replies contain <code>&gt;</code> followed by standard padded Base64. After decoding, all multi-byte integers are little-endian. Packed fields are written most significant bit first, oldest sample first.</p> <p>Use the browser-based Telemetry history decoder to turn a reply into a timestamped table or downloadable CSV without uploading the data.</p> <p><code>telemetry.tx</code> is disabled by default. Its schedule and direct path are stored across reboots. Configuring <code>direct</code> or a routed path enables the default <code>2d</code> schedule; <code>set telemetry.tx schedule</code> changes it from one through 30 days or turns it off. An automatic run waits until 165 half-hour positions are available, then sends one maximum-size temperature packet, one maximum-size battery-voltage packet, and up to three <code>IVB1</code> packets for every populated I2C voltage channel. GPS is never included in this raw transmission. The history remains boot-local, so the first scheduled run after a reboot needs about 82.5 hours to fill. On the default two-day interval, each 82.5-hour temperature or battery packet overlaps its predecessor by 34.5 hours. Packets are paced two seconds apart. A queue failure is retried after 30 minutes only for the packet that did not queue; successfully queued packets are not duplicated.</p> <p><code>send telemetry.tx now</code> is an administrator-only test action. It queues temperature and battery-voltage snapshots plus the available I2C voltage chunks over the configured path. It uses all currently available base positions up to 165 and all available I2C positions up to 192 per populated channel. It works while the schedule is off and does not move the next scheduled send time. RAW_CUSTOM direct packets do not enter the normal encrypted direct-message retry mechanism.</p> <p>Full snapshots are 184-byte RAW_CUSTOM payloads. Manual tests can be shorter while history fills. Both formats are binary, not Base64 and not encrypted:</p> Bytes Meaning <code>0</code>-<code>3</code> ASCII magic <code>TTB1</code> for temperature or <code>TVB1</code> for voltage <code>4</code>-<code>11</code> First eight bytes of the repeater public key <code>12</code>-<code>15</code> First sample UTC epoch, unsigned 32-bit little-endian <code>16</code>-<code>17</code> Sample interval in minutes, unsigned 16-bit little-endian (<code>30</code>) <code>18</code> Sample count (<code>1</code>-<code>165</code>) <code>19</code> onward Oldest-to-newest encoded samples for the selected series <p>Temperature codes reserve <code>0</code> for no reading, <code>1</code> for below <code>-50 C</code>, and <code>2</code> for above <code>+77 C</code>. Codes <code>3</code> through <code>130</code> represent exact whole degrees from <code>-50 C</code> through <code>+77 C</code>; decode them as <code>code - 53</code>. Voltage codes use the same encoding as the paged voltage payload documented below.</p> <p>External voltage snapshots use a separate packed layout. A full four-day channel takes three 140-byte <code>IVB1</code> payloads of 64 points each:</p> Bytes Meaning <code>0</code>-<code>3</code> ASCII magic <code>IVB1</code> <code>4</code>-<code>11</code> First eight bytes of the source public key <code>12</code>-<code>15</code> First sample UTC epoch, unsigned 32-bit little-endian <code>16</code>-<code>17</code> Sample interval in minutes, unsigned 16-bit little-endian (<code>30</code>) <code>18</code> Cayenne LPP voltage channel <code>19</code> Sample count (<code>1</code>-<code>64</code>) <code>20</code> onward Oldest-to-newest packed 15-bit voltage codes <p>Code <code>0</code> means missing or disconnected. Codes <code>1</code>-<code>32767</code> represent <code>0.02 V</code> through <code>655.34 V</code> in <code>0.02 V</code> steps; decode millivolts as <code>code * 20</code>.</p> <p>Match bytes <code>4</code>-<code>11</code> to the first 16 hex characters of the repeater public key shown by its advert or <code>get public.key</code>. This compact identifier is useful for association but is not authenticated and can be spoofed. An MQTT observer can upload the received raw packet to LetsMesh Analyzer <code>/packets</code>; its packet hex contains the direct-route header and path followed by this payload.</p> <p>Temperature payload (<code>0x11</code>, 61 bytes):</p> Bytes Meaning <code>0</code> Format/type <code>0x11</code> <code>1</code>-<code>4</code> First sample UTC epoch, unsigned 32-bit <code>5</code> Sample interval in minutes (<code>30</code>) <code>6</code> Sample count (<code>48</code>) <code>7</code>-<code>18</code> 48 packed 2-bit temperature statuses <code>19</code>-<code>60</code> 48 packed 7-bit temperatures <p>Temperature status codes are <code>0</code> none, <code>1</code> value, <code>2</code> below range, and <code>3</code> above range. For status <code>1</code>, the 7-bit temperature is an exact whole-degree integer from <code>-50 C</code> through <code>+77 C</code>; decode it as <code>code - 50</code>. Low values use code <code>0</code>, and high values use code <code>127</code>. The separate status map is required because 7 bits contain exactly 128 codes, leaving no spare code for none, low, or high when the complete range is represented at 1 C resolution. No fractional temperature is stored or transmitted.</p> <p>Voltage payload (<code>0x12</code>, 55 bytes):</p> Bytes Meaning <code>0</code> Format/type <code>0x12</code> <code>1</code>-<code>4</code> First sample UTC epoch, unsigned 32-bit <code>5</code> Sample interval in minutes (<code>30</code>) <code>6</code> Sample count (<code>48</code>) <code>7</code>-<code>54</code> 48 8-bit voltage codes <p>Voltage codes reserve <code>0</code> for no reading, <code>1</code> for below <code>1.88 V</code>, and <code>255</code> for above <code>4.40 V</code>. Codes <code>2</code>-<code>254</code> represent <code>1.88 V</code> through <code>4.40 V</code> in <code>0.01 V</code> steps; decode millivolts as <code>1880 + (code - 2) * 10</code>.</p> <p>External I2C voltage payload (<code>0x14</code>, 98 bytes):</p> Bytes Meaning <code>0</code> Format/type <code>0x14</code> <code>1</code>-<code>4</code> First sample UTC epoch, unsigned 32-bit <code>5</code> Sample interval in minutes (<code>30</code>) <code>6</code> Sample count (<code>48</code>) <code>7</code> Cayenne LPP voltage channel <code>8</code>-<code>97</code> 48 packed 15-bit voltage codes <p>The codes have the same <code>0.02 V</code> through <code>655.34 V</code> meaning as <code>IVB1</code>.</p> <p>GPS payload (<code>0x13</code>, 101 bytes):</p> Bytes Meaning <code>0</code> Format/type <code>0x13</code> <code>1</code>-<code>4</code> First sample UTC epoch, unsigned 32-bit <code>5</code> Sample interval in minutes (<code>30</code>) <code>6</code> Sample count (<code>24</code>) <code>7</code>-<code>10</code> Page origin latitude in signed degrees times <code>10^7</code> <code>11</code>-<code>14</code> Page origin longitude in signed degrees times <code>10^7</code> <code>15</code> Origin sample index, or <code>255</code> when the page has no GPS fix <code>16</code> Flags; bit 0 means at least one differential was clipped <code>17</code>-<code>100</code> 24 records: signed 14-bit north then signed 14-bit east <p>GPS differentials use signed 14-bit two's-complement values at 10-meter resolution and are applied to the preceding decoded valid point. The origin sample begins at the header coordinates. A no-fix slot encodes <code>0,0</code> and does not advance the reference; a stationary valid fix also quantizes to <code>0,0</code>. When a page has no fixes, its origin is <code>0,0</code>, origin index is <code>255</code>, and all differentials are <code>0,0</code>. Values outside <code>-8192</code> through <code>8191</code> are clipped and set flag bit 0.</p>"},{"location":"cli_commands/#set-companion-display-rotation","title":"Set Companion display rotation","text":"<p>SSD1306 Full Companion builds support a persisted runtime orientation:</p> <pre><code>get display.rotation\nset display.rotation 0\nset display.rotation 90\nset display.rotation 180\nset display.rotation 270\n</code></pre> <p>The values are clockwise degrees. <code>0</code> clears the override and restores the board's compiled default. Unsupported display drivers return an error.</p>"},{"location":"cli_commands/#set-mqtt-observer-display-timeout-and-flip","title":"Set MQTT observer display timeout and flip","text":"<p>MQTT observer builds with a display support a persisted inactivity timeout:</p> <pre><code>get display.timeout\nset display.timeout 0\nset display.timeout 60\n</code></pre> <p>The value is seconds. <code>0</code> keeps the display on; <code>1</code> through <code>3600</code> blanks it after that much inactivity. The default is <code>60</code>. A change applies immediately and restarts the countdown. On the Heltec V4 R8 Expansion Kit V2 observer, a panel tap or USER-button click can also blank or wake the display.</p> <p>Supported observer displays, including the R8 OLED and ST7789 panels, can also be turned 180 degrees relative to their compiled orientation:</p> <pre><code>get display.flip\nset display.flip off\nset display.flip on\n</code></pre> <p><code>0</code> and <code>1</code> are accepted aliases for <code>off</code> and <code>on</code>. This is intentionally different from Full Companion <code>display.rotation</code>: observer <code>display.flip</code> is a relative 180-degree mounting choice and cannot switch between portrait and landscape. The value is harmless on an observer display driver that does not support flipping.</p> <p>Both settings survive reboot and firmware updates that preserve the filesystem; erasing flash restores the <code>60</code>/<code>off</code> defaults. The boot log reports the saved flip state on display-enabled observer builds.</p>"},{"location":"cli_commands/#logging","title":"Logging","text":"<p>Builds compiled with <code>MESH_PACKET_LOGGING</code> emit one <code>RAW:</code> line for every received radio frame. Serial output uses backpressure: if a connected host temporarily stops reading, packet processing waits for USB transmit space instead of silently omitting the record. A disconnected host cannot retain an unbounded capture, so logging deployments should keep the reader attached and draining the serial port.</p> <p>Every valid received frame also emits the decoded RX summary, including signal, timing, hash, type, route, and payload information. Frames that cannot be decoded still emit their <code>RAW:</code> line. Transmitted packets emit the decoded TX summary.</p> <p>Ordinary non-OTA artifacts compile packet logging into the canonical image and control its live USB output at runtime; no separate <code>-logging-</code> artifact is emitted. Use the separately named <code>-ota-</code> artifact when LoRa OTA is required. A <code>-full-usb-wifi-ota-</code> artifact combines USB packet logging, direct WiFi MQTT, LoRa OTA, and the expanded FULL feature set. A <code>-full-logging-ota-</code> artifact is emitted only when that hardware/role has no matching WiFi MQTT environment.</p>"},{"location":"cli_commands/#control-live-usb-logging","title":"Control live USB logging","text":"<p>Usage:</p> <pre><code>get usb.logging\nset usb.logging on\nset usb.logging off\nset usb.logging on reboot\nset usb.logging off reboot\n</code></pre> <p>These commands are compiled into ordinary USB-loggable artifacts and every Full Companion. They control live USB debug and packet output. CommonCLI roles save the setting in <code>/com_prefs</code>, so it survives reboot; their first boot defaults to on. Full Companion and ordinary USB Companion start off on a fresh installation so diagnostics cannot corrupt framed traffic.</p> <p>On Full Companion these lines belong to its text terminal, not <code>meshcli</code>'s Binary <code>get/set</code> parameter namespace. Open interface <code>00</code>, send <code>+++MESHCORE-TERM-START</code>, and then issue the command. Running <code>meshcli ... get usb.logging</code> directly can instead return <code>Unknown var usb.logging</code> because that is a different protocol operation.</p> <p>nRF52 Full Companion defaults logging to off and enumerates only USB interface <code>00</code>, which carries Companion, terminal, and serial mOTA traffic. Enabling logging adds interface <code>02</code>, its dedicated plaintext logging port, on the next boot. Disabling it removes interface <code>02</code> on the next boot. A command without the optional <code>reboot</code> argument saves the choice and reports that a reboot is required when the USB interface count must change. The exact <code>set usb.logging on reboot</code> and <code>set usb.logging off reboot</code> forms save the choice, send their reply, and reboot one second later only when needed.</p> <p>On every ESP32 Full Companion, enter the USB text terminal and use <code>set usb.logging on</code> to turn that TTY into a logging-repeater-style plaintext stream. Framed Binary Companion is unavailable on USB while logging is on. The TTY remains an input-capable CLI, so <code>set usb.logging off</code> works on the same TTY. After its reply, logging stops and the TTY remains in the normal ASCII terminal, just as it does after a fresh Full installation. Send <code>+++MESHCORE-TERM-STOP</code>, or let a Companion app send a valid framed probe, to switch it to Binary Companion. No reboot is needed because the USB interface count does not change.</p> <p>Turning USB logging off does not disable CLI replies. nRF52 keeps Companion frames active on interface <code>00</code>; ESP32 resumes the ordinary ASCII/Binary switcher after the logging terminal turns logging off. This setting does not change the node-storage capture controlled by <code>log start</code> and <code>log stop</code>.</p> <p>Unified non-Companion ESP32 FULL USB+WiFi observer builds add one saved selector for both output paths. Full Companion builds control USB diagnostics with <code>usb.logging</code> instead; their text-command parser does not expose <code>logging.output</code>:</p> <pre><code>get logging.output\nset logging.output off\nset logging.output usb\nset logging.output wifi\nset logging.output both\n</code></pre> <p><code>usb</code> emits <code>RAW:</code> packets for a USB-connected service such as meshcoretomqtt. <code>wifi</code> enables the direct MQTT bridge configured by the <code>wifi.*</code> and <code>mqtt.*</code> commands. <code>both</code> intentionally duplicates the radio stream to both consumers; do not point both consumers at the same broker unless the downstream setup deduplicates messages. Fresh unified FULL installs start in <code>both</code> mode.</p>"},{"location":"cli_commands/#begin-capture-of-rx-log-to-node-storage","title":"Begin capture of rx log to node storage","text":"<p>Usage: <code>log start</code></p>"},{"location":"cli_commands/#end-capture-of-rx-log-to-node-storage","title":"End capture of rx log to node storage","text":"<p>Usage: <code>log stop</code></p>"},{"location":"cli_commands/#erase-captured-log","title":"Erase captured log","text":"<p>Usage: <code>log erase</code></p>"},{"location":"cli_commands/#print-the-captured-log-to-the-serial-terminal","title":"Print the captured log to the serial terminal","text":"<p>Usage: <code>log</code></p> <p>Serial Only: Yes</p>"},{"location":"cli_commands/#info","title":"Info","text":""},{"location":"cli_commands/#get-the-version","title":"Get the Version","text":"<p>Usage: <code>ver</code></p> <p>On Full Companion, the Binary device-info frame retains its legacy fixed-width version field. Use <code>version</code> in the text terminal, or send <code>version</code> through Binary protocol command <code>0x42</code> (<code>CMD_RUN_CLI_COMMAND</code>), to read the complete untruncated firmware string together with protocol and build date.</p>"},{"location":"cli_commands/#show-the-hardware-name","title":"Show the hardware name","text":"<p>Usage: <code>board</code></p>"},{"location":"cli_commands/#show-the-storage-layout","title":"Show the storage layout","text":"<p>Usage: <code>get storage.layout</code></p> <p>Reports a compact, read-only summary of the storage compiled into the running firmware:</p> <ul> <li>ESP32 reports the detected internal flash size and the live partition table.   Partition addresses after <code>@</code> are hexadecimal, sizes after <code>+</code> are KiB, and   <code>*</code> marks the running application. <code>...</code> means later entries did not fit in   the CLI reply.</li> <li>nRF52 reports the physical internal flash size, linked application range,   InternalFS range, and any configured external store. Raw QSPI OTA storage   includes its detected size and JEDEC ID; SD storage includes total, used, and   free space.</li> <li>RP2040 and STM32 report their fixed internal flash and filesystem geometry.</li> </ul> <p>The command does not write, format, or resize storage. A raw-QSPI or SD build may briefly probe, wake, or mount its configured external storage to read its capacity. Remote use follows the existing administrator-command permissions.</p>"},{"location":"cli_commands/#configuration","title":"Configuration","text":""},{"location":"cli_commands/#radio","title":"Radio","text":""},{"location":"cli_commands/#view-or-change-this-nodes-radio-parameters","title":"View or change this node's radio parameters","text":"<p>Usage: - <code>get radio</code> - <code>set radio &lt;freq&gt;,&lt;bw&gt;,&lt;sf&gt;,&lt;cr&gt;</code></p> <p>Parameters: - <code>freq</code>: Frequency in MHz - <code>bw</code>: Bandwidth in kHz. Most targets allow <code>7.8</code>, <code>10.4</code>, <code>15.6</code>, <code>20.8</code>, <code>31.25</code>, <code>41.7</code>, <code>62.5</code>, <code>125</code>, <code>250</code>, <code>500</code>. LR1110 targets allow <code>62.5</code>, <code>125</code>, <code>250</code>, <code>500</code>. - <code>sf</code>: Spreading factor (5-12) - <code>cr</code>: Coding rate (5-8)</p> <p>Set by build flag: <code>LORA_FREQ</code>, <code>LORA_BW</code>, <code>LORA_SF</code>, <code>LORA_CR</code></p> <p>Default: <code>869.525,250,11,5</code></p> <p>Note: Requires reboot to apply. If RXPS is enabled and the saved minimum level/preamble cannot safely cover the new radio timing, the command reply reports the effective level and preamble, or <code>RXPS continuous-fast</code> when no level through 10 is safe. Slower settings recalculate from the saved RXPS minimum and return to it exactly when it is safe.</p>"},{"location":"cli_commands/#view-or-change-this-nodes-transmit-power","title":"View or change this node's transmit power","text":"<p>Usage: - <code>get tx</code> - <code>set tx &lt;dbm&gt;</code></p> <p>Parameters: - <code>dbm</code>: Requested radio-chip power in dBm. The valid range depends on the   radio family, selected PA path, and any board-specific external-PA limit.</p> <p>Set by build flag: <code>LORA_TX_POWER</code></p> <p>Default: Varies by board</p> <p>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.</p> <p>The command strictly rejects malformed values and saves the new preference only after the active radio driver accepts it. On LR2021, the chip range is <code>-9</code> to <code>22</code> dBm below 1500 MHz and <code>-19</code> to <code>12</code> dBm above 1500 MHz. A lower board-specific external-PA limit still takes precedence. A saved profile is clamped to the applicable limit when its frequency changes; temporary radio settings use a safe effective power without replacing the saved preference.</p>"},{"location":"cli_commands/#change-the-radio-parameters-for-a-set-duration","title":"Change the radio parameters for a set duration","text":"<p>Usage:  - <code>tempradio &lt;freq&gt;,&lt;bw&gt;,&lt;sf&gt;,&lt;cr&gt;,&lt;timeout_mins&gt;</code> - <code>normalradio</code></p> <p>Parameters: - <code>freq</code>: Frequency in MHz (150-2500) - <code>bw</code>: Bandwidth in kHz (same allowed values as <code>set radio</code>) - <code>sf</code>: Spreading factor (5-12) - <code>cr</code>: Coding rate (5-8) - <code>timeout_mins</code>: Duration in minutes (must be &gt; 0)</p> <p>Notes: - <code>tempradio</code> is not saved to preferences and clears on reboot. - <code>normalradio</code> cancels pending and active temporary-radio windows, then   restores the saved radio tuple after its CLI reply has drained on the   current channel. Permanent <code>radioat</code> entries are not removed.</p>"},{"location":"cli_commands/#schedule-radio-parameter-changes","title":"Schedule radio parameter changes","text":"<p>Usage: - <code>set radioat &lt;freq&gt;,&lt;bw&gt;,&lt;sf&gt;,&lt;cr&gt;,&lt;start_time&gt;</code> - <code>get radioat [n|all]</code> - <code>del radioat [n|all]</code> - <code>set tempradioat &lt;freq&gt;,&lt;bw&gt;,&lt;sf&gt;,&lt;cr&gt;,&lt;start_time&gt;,&lt;end_time&gt;</code> - <code>get tempradioat [n|all]</code> - <code>del tempradioat [n|all]</code></p> <p>Parameters: - <code>freq</code>: Frequency in MHz (150-2500) - <code>bw</code>: Bandwidth in kHz (same allowed values as <code>set radio</code>) - <code>sf</code>: Spreading factor (5-12) - <code>cr</code>: Coding rate (5-8) - <code>start_time</code>: Unix epoch time when the setting starts - <code>end_time</code>: Unix epoch time when a temporary setting reverts - <code>n</code>: Scheduled entry number from <code>get radioat</code> or <code>get tempradioat</code></p> <p>Notes: - <code>get radioat</code> and <code>get tempradioat</code> list all entries when <code>n</code> is omitted. - <code>del radioat</code> and <code>del tempradioat</code> delete all entries when <code>n</code> is omitted. - Each queue supports 3 entries. Scheduled entries are not saved across reboot. - <code>radioat</code> saves the new radio preferences when it fires. <code>tempradioat</code> applies temporarily, then reverts to the saved radio preferences. - A successful scheduling reply notes any RXPS effective-level/preamble change   required by the scheduled tuple. <code>RXPS continuous-fast</code> means the tuple is   accepted but will use continuous receive because no safe duty-cycle level is   available. Returning to slower settings recalculates from the saved RXPS   minimum.</p> <p>On SX1262+TCXO boards, the fast-setting boundaries are:</p> SF BW (kHz) Wire preamble Effective timing preamble Minimum effective RXPS level RX / sleep 7 500 32 32 7 2731 / 6101 us 6 250 32 32 7 2731 / 6101 us 5 125 32 32 7 2731 / 6101 us 5 250 64 64 8 1252 / 6424 us 6 500 64 64 8 1252 / 6424 us 5 500 128 128 8 626 / 6398 us 5 62.5 32 16 10 4096 / 6272 us <p>SF7/BW500, SF6/BW250, and SF5/BW125 are timing-equivalent because each has a 256 us LoRa symbol. SF5/BW250 and SF6/BW500 have 128 us symbols; both need 64 wire symbols to cover the 6 ms transition. SF5/BW500 has 64 us symbols and needs 128.</p> <p>The wire preamble is a firmware property, not a <code>radio.rxps</code> preference. The effective preamble is the conservative length RXPS uses for its timing window, which is why SF5/BW62.5 can retain a saved 16-symbol assumption while the radio transmits 32. Starting with v1.17.1.5, firmware tries 32 first at SF5-SF8, then 64 and 128 only when each shorter length cannot enable RXPS at any level. It uses 16 at SF9-SF12. Every packet on a tuple, including retries, uses that tuple's selected length.</p> <p>Cascade/USA builds on a Heltec V4 and WisMesh Tag (RAK4631 target) passed 16/16 packets in each direction at both SF5/BW250/64 and SF5/BW500/128, CR5, 909.950 MHz. A 64- or 128-symbol timing window is safe only when every possible sender to the RXPS receiver follows the v1.17.1.5-or-newer adaptive-preamble contract; a shorter legacy sender would create a receive gap. LoRa OTA automation treats that version as the wire-format capability boundary.</p>"},{"location":"cli_commands/#view-or-change-this-nodes-frequency","title":"View or change this node's frequency","text":"<p>Usage: - <code>get freq</code> - <code>set freq &lt;frequency&gt;</code></p> <p>Parameters: - <code>frequency</code>: Frequency in MHz</p> <p>Default: <code>869.525</code></p> <p>Note: Requires reboot to apply Serial Only: <code>set freq &lt;frequency&gt;</code></p>"},{"location":"cli_commands/#view-or-change-this-nodes-rx-boosted-gain-mode-sx12xx-and-lr1110-v1141","title":"View or change this node's rx boosted gain mode (SX12xx and LR1110, v1.14.1+)","text":"<p>Usage: - <code>get radio.rxgain</code> - <code>set radio.rxgain &lt;state&gt;</code></p> <p>Parameters:   - <code>state</code>: <code>on</code>|<code>off</code></p> <p>Default: Target-specific. Most SX1262 and LR1110 targets default to <code>on</code>; Station G2/G3 targets default to <code>off</code>.</p> <p>Notes: - The saved setting is applied immediately and persists across reboots. - Periodic AGC resets restore the saved runtime setting; they do not replace it   with the target's compile-time default. - Existing installations retain their previously saved value after an upgrade.</p>"},{"location":"cli_commands/#view-or-change-rx-duty-cycle-power-saving","title":"View or change RX duty-cycle power saving","text":"<p>Usage: - <code>get radio.rxps</code> - <code>get radio.rxps.config</code> - <code>get radio.rxps.rfrx_disabled</code> - <code>get rxps.wd</code> - <code>set radio.rxps.rfrx_disabled &lt;state&gt;</code> - <code>set radio.rxps off</code> - <code>set radio.rxps on</code> - <code>set radio.rxps conservative</code> - <code>set radio.rxps balanced</code> - <code>set radio.rxps &lt;1-10&gt;</code> - <code>set radio.rxps level &lt;1-10&gt;</code> - <code>set radio.rxps level &lt;1-10&gt; preamble &lt;16|32&gt;</code> - <code>set radio.rxps &lt;rx_us&gt; &lt;sleep_us&gt;</code></p> <p>Parameters: - <code>rx_us</code>, <code>sleep_us</code>: Receive and sleep durations in microseconds (<code>1000</code>-<code>30000000</code>). - <code>level</code>: A power-saving level from <code>1</code> (most conservative) to <code>10</code> (least power saving). - <code>preamble</code>: RXPS timing assumption in symbols; <code>16</code> or <code>32</code>. This does not   change the radio's actual transmitted preamble. - <code>state</code>: <code>on</code> or <code>off</code>.</p> <p>Notes: - <code>get rxps.wd</code> reports the RXPS watchdog's soft and hard recovery counts. - <code>get radio.rxps.config</code> adds the persisted level and preamble assumption to   the on/off and timing values. Deployment tools use it to restore a   level-based preference without converting it to fixed manual timings. - <code>radio.rxps.rfrx_disabled</code> is a runtime-only diagnostic setting and resets to <code>off</code> after reboot. - Its default <code>off</code> state keeps the host-controlled SX1262 receive path enabled during RX duty-cycle mode. Setting it to <code>on</code> reproduces the old missing-RF_RX behavior and can significantly reduce receive sensitivity, making remote commands harder to receive. - <code>radio.rxps.rfrx_disabled</code> is supported only on SX1262 targets with a host-controlled RX enable pin. - <code>on</code> and <code>conservative</code> select level <code>1</code> with a 16-symbol preamble; <code>balanced</code> selects level <code>5</code> with a 16-symbol preamble. - Fresh Cascade-profile builds start with RXPS on at level <code>8</code> and a 16-symbol preamble. Saved operator settings still take precedence after an upgrade. - Level-based settings automatically recalculate their timings when the spreading factor or bandwidth changes. Custom <code>&lt;rx_us&gt; &lt;sleep_us&gt;</code> timings remain fixed. - <code>get radio.rxps</code> keeps the legacy on/off, RX, and sleep reply. The new   <code>get radio.rxps.config</code> reply adds the saved level and preamble assumption.   Radio-change replies and the Full Companion terminal status report any   effective level/preamble adjustment. Effective preamble 64 or 128 appears   only when the active tuple's physical wire preamble has that length. - The selected mode is applied immediately, persisted, and restored after reboot.</p>"},{"location":"cli_commands/#view-or-change-the-lora-fem-receive-path-gain-state-on-supported-boards","title":"View or change the LoRa FEM receive-path gain state on supported boards","text":"<p>Usage: - <code>get radio.fem.rxgain</code> - <code>set radio.fem.rxgain &lt;state&gt;</code></p> <p>Parameters: - <code>state</code>: <code>on</code>|<code>off</code></p> <p>Notes: - This controls the external LoRa FEM receive-path LNA where the board supports it. - This is separate from <code>radio.rxgain</code>, which controls the radio chip receive gain mode.</p>"},{"location":"cli_commands/#view-or-change-the-lora-fem-transmit-path-gain-state-on-supported-boards","title":"View or change the LoRa FEM transmit-path gain state on supported boards","text":"<p>Usage: - <code>get radio.fem.txgain</code> - <code>set radio.fem.txgain &lt;state&gt;</code></p> <p>Parameters: - <code>state</code>: <code>on</code>|<code>off</code></p> <p>Notes: - This controls a software-selectable external LoRa FEM transmit gain where the board supports it. - On Station G3, remove the PA PL1 jumper to allow software control. <code>on</code> selects PA PL1 high/short and <code>off</code> selects PA PL1 low/open. The PA PL2 hardware jumper determines whether this switches between power levels 1/3 or 2/4. - Select an operating level and SX1262 transmit power that comply with local RF limits and the Station G3 power-supply requirements. - The setting is saved immediately, but on Station G3 the level is applied to the hardware at the start of the next transmit, so that the PA supply rail is never re-targeted while the PA is being driven. <code>get</code> reports the configured state, which may lead the hardware until the node next transmits.</p>"},{"location":"cli_commands/#system","title":"System","text":""},{"location":"cli_commands/#view-or-change-this-nodes-name","title":"View or change this node's name","text":"<p>Usage: - <code>get name</code> - <code>set name &lt;name&gt;</code></p> <p>Parameters: - <code>name</code>: Node name</p> <p>Set by build flag: <code>ADVERT_NAME</code></p> <p>Default: Varies by board</p> <p>Note: Advertised names can use up to 23 bytes when location is included and 31 bytes otherwise. Emoji and Unicode characters may take more than one byte. Names that exceed the available advert space are truncated at a valid UTF-8 code point boundary.</p>"},{"location":"cli_commands/#view-or-change-the-independent-bluetooth-name-companion","title":"View or change the independent Bluetooth name (Companion)","text":"<p>Usage:</p> <ul> <li><code>get bluetooth.name</code></li> <li><code>set bluetooth.name &lt;name|default&gt;</code></li> </ul> <p><code>get ble.name</code> and <code>set ble.name ...</code> are accepted aliases. This command is specific to Companion firmware. The default is <code>MeshCore-&lt;advert name&gt;</code>; <code>default</code> (or <code>clear</code>) removes a custom override. Names are limited to 31 valid UTF-8 bytes without control characters and take effect after reboot.</p> <p>A binary Companion client should carry the same text in command <code>0x42</code> (<code>CMD_RUN_CLI_COMMAND</code>), which works over USB, BLE, or TCP without entering USB terminal mode. See Companion radio binary protocol for the frame and reply format.</p>"},{"location":"cli_commands/#view-or-change-this-nodes-latitude","title":"View or change this node's latitude","text":"<p>Usage: - <code>get lat</code> - <code>set lat &lt;degrees&gt;</code></p> <p>Set by build flag: <code>ADVERT_LAT</code></p> <p>Default: <code>0</code></p> <p>Parameters: - <code>degrees</code>: Latitude in degrees</p>"},{"location":"cli_commands/#view-or-change-this-nodes-longitude","title":"View or change this node's longitude","text":"<p>Usage: - <code>get lon</code> - <code>set lon &lt;degrees&gt;</code></p> <p>Set by build flag: <code>ADVERT_LON</code></p> <p>Default: <code>0</code></p> <p>Parameters: - <code>degrees</code>: Longitude in degrees</p>"},{"location":"cli_commands/#view-or-change-this-nodes-identity-private-key","title":"View or change this node's identity (Private Key)","text":"<p>Usage: - <code>get prv.key</code> - <code>set prv.key &lt;private_key&gt;</code></p> <p>Parameters: - <code>private_key</code>: Private key in hex format (64 hex characters)</p> <p>Serial Only: - <code>get prv.key</code>: Yes - <code>set prv.key</code>: No</p> <p>Note: Requires reboot to take effect after setting</p>"},{"location":"cli_commands/#change-this-nodes-admin-password","title":"Change this node's admin password","text":"<p>Usage: - <code>password &lt;new_password&gt;</code></p> <p>Parameters: - <code>new_password</code>: New admin password</p> <p>Set by build flag: <code>ADMIN_PASSWORD</code></p> <p>Default: <code>password</code></p> <p>Note: Command reply echoes the updated password for confirmation.</p> <p>Note: Any node using this password will be added to the admin ACL list.</p>"},{"location":"cli_commands/#view-or-change-this-nodes-guest-password","title":"View or change this node's guest password","text":"<p>Usage: - <code>get guest.password</code> - <code>set guest.password &lt;password&gt;</code></p> <p>Parameters: - <code>password</code>: Guest password</p> <p>Set by build flag: <code>ROOM_PASSWORD</code> (Room Server only)</p> <p>Default: <code>&lt;blank&gt;</code></p>"},{"location":"cli_commands/#view-or-change-this-nodes-owner-info","title":"View or change this node's owner info","text":"<p>Usage: - <code>get owner.info</code> - <code>set owner.info &lt;text&gt;</code></p> <p>Parameters: - <code>text</code>: Owner information text</p> <p>Default: <code>&lt;blank&gt;</code></p> <p>Note: <code>|</code> characters are translated to newlines</p> <p>Note: Requires firmware 1.12+</p>"},{"location":"cli_commands/#fine-tune-the-battery-reading","title":"Fine-tune the battery reading","text":"<p>Usage: - <code>get adc.multiplier</code> - <code>set adc.multiplier &lt;value&gt;</code></p> <p>Parameters: - <code>value</code>: ADC multiplier (0.0-10.0)</p> <p>Default: <code>0.0</code> (value defined by board)</p> <p>Note: Returns \"Error: unsupported by this board\" if hardware doesn't support it</p>"},{"location":"cli_commands/#send-a-repeater-flood-text","title":"Send a repeater flood text","text":"<p>Usage: - <code>send text.flood &lt;message&gt;</code></p> <p>Parameters: - <code>message</code>: Text to send to the shared <code>#repeaters</code> flood channel, prefixed with this node's name. Any <code>:</code> in the node name is sent as <code>;</code> so the prefix delimiter stays unambiguous.</p> <p>Example:</p> <pre><code>send text.flood checking ridge link\n</code></pre>"},{"location":"cli_commands/#view-or-change-battery-alert-state","title":"View or change battery alert state","text":"<p>Usage: - <code>get battery.alert</code> - <code>get battery.alert.region</code> - <code>set battery.alert on [region]</code> - <code>set battery.alert off</code></p> <p>Parameters: - <code>region</code>: Optional named region scope. When omitted, the repeater selects the single deepest (most narrow) named region in the configured hierarchy. If multiple regions tie for deepest, specify one explicitly.</p> <p>Defaults: - <code>battery.alert</code>: <code>off</code> - <code>battery.alert.region</code>: <code>&lt;unset&gt;</code></p> <p>Notes: - Enabling fails until at least one usable named region is defined. Alerts are never sent as unscoped floods. If the selected region is later removed, alerts stop until battery alerts are enabled again with a valid region. - Region hierarchy edits are not persistent until <code>region save</code> is run. After <code>region def west pnw wa w-wa sea</code>, run <code>region save</code> before enabling the alert if the hierarchy must survive a reboot. - A region must have a usable transport key. Public named regions derive one automatically; a private region without an available key is rejected. - The first alert is suppressed until the repeater has been up for at least 30 minutes. After that, the repeater checks every 30 minutes and sends low-battery warnings to the <code>#repeaters</code> channel in the selected region. - Once an alert finishes transmitting, another battery alert is suppressed for at least 12 hours. A queue rejection, stale-queue drop, or radio send failure does not start the cooldown. Battery recovery or toggling alerts off and back on does not bypass a completed alert's cooldown during the same boot. - With <code>region def west pnw wa w-wa sea</code>, <code>set battery.alert on</code> selects <code>sea</code>; <code>set battery.alert on w-wa</code> overrides that default. - <code>get battery.alert.region</code> returns the selected scope, for example <code>&gt; sea</code>. - The battery check never requests a wake earlier than its 30-minute deadline. If the normal loop is already awake when that deadline has elapsed, the check is effectively free of an additional wake. Time in light/event sleep counts toward the startup delay, and a pending alert keeps the repeater awake until the packet is handled.</p>"},{"location":"cli_commands/#view-or-change-battery-alert-thresholds","title":"View or change battery alert thresholds","text":"<p>Usage: - <code>get battery.alert.low</code> - <code>set battery.alert.low &lt;1-100&gt;</code> - <code>get battery.alert.critical</code> - <code>set battery.alert.critical &lt;0-99&gt;</code></p> <p>Defaults: - <code>battery.alert.low</code>: <code>20</code> - <code>battery.alert.critical</code>: <code>10</code></p> <p>Note: The low threshold must be greater than the critical threshold. Alerts at or below the critical threshold use <code>CRITICAL BATTERY</code> in the message; both severities use the same 12-hour resend cooldown.</p>"},{"location":"cli_commands/#enable-or-disable-the-rx-inactivity-watchdog-repeater-only","title":"Enable or disable the RX inactivity watchdog (Repeater Only)","text":"<p>Usage: - <code>get rx.watchdog</code> - <code>set rx.watchdog on</code> - <code>set rx.watchdog off</code></p> <p>Default: <code>off</code></p> <p>Notes: - When enabled, the first check is due after a full 12-hour observation window. The repeater then checks roughly every 12 hours and reboots if it has not successfully received a radio packet during the preceding 12 hours. - Enabling the watchdog starts a new 12-hour observation window. Rebooting also starts a new window, so a quiet mesh can reboot no more often than once every 12 hours. - The check reuses the radio driver's existing last-receive timestamp. It does not poll, sample, or wake the radio or CPU. A due check waits for the next normal loop/wake, so its actual cadence can drift around the 12-hour target. With RX power saving enabled, packets received during normal listening windows count as activity; the watchdog does not alter the RX/sleep timing.</p>"},{"location":"cli_commands/#enable-or-disable-the-nrf52-system-watchdog","title":"Enable or disable the nRF52 system watchdog","text":"<p>Usage: - <code>get system.watchdog</code> - <code>set system.watchdog on</code> - <code>set system.watchdog off</code></p> <p>Default: <code>on</code></p> <p>Notes: - This nRF52-only hardware watchdog resets the device if the application loop stops for 60 seconds, including an indefinite SoftDevice flash-write wait. - Enabling takes effect without a reboot. - The nRF52 hardware cannot stop a watchdog after it has started. Disabling is persisted immediately, then the current firmware stops feeding it so the board performs one watchdog restart within 60 seconds. It remains off after that restart. - This setting is nRF52-only. The SoftDevice flash deadlock does not apply to ESP32, whose existing watchdog behavior is unchanged.</p>"},{"location":"cli_commands/#estimate-and-correct-infrastructure-node-time-after-startup","title":"Estimate and correct infrastructure-node time after startup","text":"<p>Usage: - <code>get clock.sync</code> - <code>get clock.sync.status</code> - <code>get clock.sync.status.table</code> - <code>get clock.sync.status.&lt;1-16&gt;</code> - <code>get clock.sync.mesh</code> - <code>set clock.sync.mesh &lt;on|off&gt;</code> - <code>get clock.sync.mesh.edge</code> - <code>set clock.sync.mesh.edge &lt;on|off&gt;</code> - <code>clock.sync.mesh now</code> - <code>get clock.sync.internet</code> - <code>set clock.sync.internet &lt;on|off&gt;</code> - <code>get clock.sync.drift</code> - <code>set clock.sync.drift &lt;30-86400&gt;</code> - <code>get clock.sync.samples</code> - <code>set clock.sync.samples &lt;3-16&gt;</code></p> <p>Defaults: - <code>clock.sync.mesh</code>: <code>on</code> for all repeater, sensor, and room-server builds - <code>clock.sync.mesh.edge</code>: <code>on</code> - <code>clock.sync.internet</code>: <code>off</code> - <code>clock.sync.drift</code>: <code>600</code> seconds (10 minutes) - <code>clock.sync.samples</code>: <code>9</code></p> <p>When either source is enabled, the node makes its first clock-bootstrap attempt after 30 minutes of uptime, or immediately when the configured number of fresh evidence sources has been collected, whichever comes first. A successful estimate changes the RTC only when the absolute difference is greater than <code>clock.sync.drift</code>; correction can move the clock forward or backward. A valid estimate within the threshold counts as a successful sync without changing the clock. Seven days after each successful estimate, the node evaluates time again; the seven-day deadline therefore starts from the last successful estimate rather than from boot. This is a lazy uptime deadline: the check runs on the first normal loop/wake after it becomes due and does not wake the device by itself. If no source or consensus is available, the node retries every 30 minutes, and newly collected evidence triggers another immediate evaluation once the configured source count is present. Every reboot starts with the initial bootstrap attempt. An existing saved setting always overrides the platform default.</p> <p><code>clock.sync.mesh now</code> bypasses the startup/seven-day deadline and queues a LoRa-only consensus evaluation on the next normal loop, even when the internet source is also enabled. It uses any currently fresh samples without clearing the 16-slot table. If there is not yet enough evidence, mesh collection remains open and the next attempt follows the normal 30-minute retry. The command requires <code>clock.sync.mesh</code> to be on and does not bypass CLI, GPS, or NTP suppression; it also retains the normal quorum, timestamp-validity, and drift checks. The separate <code>clock</code> command only displays the current RTC and does not request a synchronization attempt.</p> <p><code>clock.sync.mesh</code> collects signature-verified advert timestamps and MAC-valid, decrypted Public-channel plain-text timestamps. In normal path mode, collection occurs only after the packet passes every forwarding filter. Sources are deduplicated by advert public key or case-insensitive Public-channel display name. Every fresh sample must also have a different full received path; all direct, zero-hop receptions count as the same empty path. This prevents repeated packets or multiple names arriving over one route from increasing the vote count.</p> <p>For a node at the edge of the network where every packet arrives through one relay path, <code>set clock.sync.mesh.edge on</code> changes the evidence requirement from distinct receive paths to distinct sources. Signature-verified adverts are deduplicated by public key, and Public-channel timestamps are deduplicated by case-insensitive display name. Repeated packets from one source still count once. Edge mode observes this verified evidence on the receive path, independently of the forwarding decision, so <code>repeat off</code> and forwarding filters do not prevent clock collection. Other packet types are observed normally but cannot be clock evidence because they do not provide a suitable authenticated Unix timestamp. Changing edge mode clears the in-memory sample table so evidence collected under the other policy is not reused. The setting is persistent and defaults on.</p> <p>At least the configured number of distinct fresh evidence sources (nine by default) and a strict majority of all fresh samples must fall within ten minutes of the median. In normal mode each source must use a distinct receive path. In edge mode signed adverts are distinct by public key and Public-channel messages are distinct by display name, but all may use the same receive path. The effective quorum is therefore the larger of <code>clock.sync.samples</code> and half the fresh sample count plus one. For example, a 9-vs-7 split can succeed but an 8-vs-8 split cannot. The median is used. <code>clock.sync.samples</code> accepts <code>3</code> through <code>16</code>; samples older than two hours are ignored. Status reports <code>mode=paths</code> or <code>mode=edge</code> and labels the collected evidence as <code>paths</code> or <code>sources</code>. It reports <code>reason=need-more-paths</code> or <code>reason=need-more-sources</code> when fewer than the configured number exist, and <code>reason=no-consensus</code> when enough evidence exists but the effective quorum does not agree. Mesh collection begins immediately after boot. Following a successful estimate, it resumes two hours before the next seven-day deadline so only evidence that can still be fresh at evaluation time is processed.</p> <p><code>get clock.sync.status</code> reports whether the clock was set and a <code>reason</code> when it was not. Common reasons include <code>waiting-deadline</code>, <code>need-more-sources</code>, <code>need-more-paths</code>, <code>no-consensus</code>, <code>within-drift</code>, <code>mesh-off</code>, and suppression by CLI, GPS, or internet time. It also reports whether collection is active, the fresh evidence count, the number of occupied table slots, and the next evaluation deadline.</p> <p><code>get clock.sync.status.table</code> shows the active sample table in compact form. Each item is <code>slot:type:id-prefix:age</code>, where type <code>A</code> is a signed advert and type <code>P</code> is a Public-channel message. A trailing <code>!</code> marks a stale sample. If the compact reply is truncated, query any slot with <code>get clock.sync.status.&lt;1-16&gt;</code>. The detail view reports the full source and path hashes, age-adjusted epoch, difference from the local clock, and freshness.</p> <p>A timestamp is eligible for a clock-sync sample only when it falls between the UTC build epoch embedded by <code>build.sh</code> and that time plus ten calendar years. Direct developer builds that bypass <code>build.sh</code> fall back to the compiler timestamp. Validation happens before a slot is selected or written, so an advert or Public-channel timestamp outside that window is not recorded as a clock sample.</p> <p>Before voting, the node advances each packet timestamp by an estimated transit time. The estimate sums the radio airtime at the original packet length and at each progressively longer relay length, plus the expected midpoint of the random flood-forward delay at every prior hop. The normal elapsed time since the radio recorded local receipt is then added when consensus is evaluated, so local signature/decryption/filter processing time is included too. This is better than using hop count alone because LoRa airtime changes with packet length and radio settings. Transit compensation is capped at the ten-minute consensus window. It cannot know sender queueing, channel contention, or a remote relay's non-matching <code>txdelay</code>, so the consensus window and median still absorb residual error.</p> <p>If a <code>clock sync</code> or <code>time &lt;epoch&gt;</code> CLI command successfully sets the clock, or a GPS provider writes a valid GPS time, LoRa-derived clock collection and correction are suppressed for the rest of that boot. Turning <code>clock.sync.mesh</code> off and back on does not clear this safety latch; only a reboot does. <code>get clock.sync.mesh</code> and <code>get clock.sync.status</code> report whether CLI or GPS time caused the suppression. On a WiFi MQTT build, a successful NTP sync is authoritative and also suppresses LoRa correction for the rest of that boot. Source selection starts fresh after a reboot, so LoRa remains the fallback when NTP cannot obtain internet time during that boot.</p> <p>Public-channel display names are not authenticated and can be spoofed. Received path hashes are also truncated, unauthenticated routing hints; requiring unique paths prevents ordinary duplicate-route inflation but is not a cryptographic identity check. Signed adverts authenticate the advert contents but do not prove that the advertising node's own clock is correct. Mesh time is therefore a consensus estimate, not an authoritative time service. Edge mode intentionally gives up receive-path diversity. Public-channel display names can be spoofed, so one sender can claim multiple names and inflate the edge-mode vote count.</p> <p><code>clock.sync.internet</code> is available on WiFi MQTT repeater-observer builds. Its initial and seven-day queries run on the MQTT/WiFi task and are read-only until the repeater applies the configured drift test. Failed queries retry after 30 minutes. On other infrastructure-node builds, the preference can be stored but status reports that internet time is unavailable. MQTT builds retain their existing startup NTP behavior required for MQTT/TLS/JWT operation; this setting controls the additional delayed drift checks. Startup NTP is always preferred when it succeeds, regardless of this setting.</p> <p>Sensor and room-server builds support mesh clock consensus and report <code>clock.sync.internet</code> as unavailable. Changing any <code>clock.sync.*</code> setting starts a new attempt for the current boot. Settings are persistent in <code>/clock_sync</code>; samples and schedule state are not.</p> <p>A backward correction is intentionally allowed, but peers that already recorded a later timestamp from this node may temporarily reject its lower timestamps as replays until corrected time passes the previously observed value.</p> <p>Example:</p> <pre><code>set clock.sync.drift 600\nset clock.sync.samples 3\nset clock.sync.mesh on\nset clock.sync.mesh.edge on\nclock.sync.mesh now\nget clock.sync.status\n</code></pre>"},{"location":"cli_commands/#view-this-nodes-public-key","title":"View this node's public key","text":"<p>Usage: <code>get public.key</code></p>"},{"location":"cli_commands/#view-this-nodes-firmware-version","title":"View this node's firmware version","text":"<p>Usage: <code>ver</code></p>"},{"location":"cli_commands/#view-this-nodes-configured-role","title":"View this node's configured role","text":"<p>Usage: <code>get role</code></p>"},{"location":"cli_commands/#view-or-change-this-nodes-power-saving-flag","title":"View or change this node's power saving flag","text":"<p>Usage: - <code>powersaving</code> - <code>powersaving on</code> - <code>powersaving off</code> - <code>set powersaving on</code> - <code>set powersaving off</code></p> <p>Parameters:  - <code>on</code>: enable power saving - <code>off</code>: disable power saving</p> <p>Default: <code>on</code> for fresh Cascade-profile builds and Companion firmware; <code>off</code> for other infrastructure profiles</p> <p>Note: Infrastructure firmware enters sleep between radio transmissions. It refuses to enable power saving from the local serial console or while an active USB serial data connection is detected; USB power alone does not block power saving.</p> <p>Companion firmware defaults this setting to <code>on</code>. Full Companion accepts the command from its local USB terminal and exposes the same setting in WebConfig. On ESP32, it lowers the CPU clock to 80 MHz, enables idle yielding, and enables the configured GPS duty cycle. USB and each active wireless transport remain available; SenseCAP Indicator Full keeps only its selected BLE or infrastructure-WiFi secondary transport active. <code>powersaving off</code> restores the board's normal CPU clock and disables the GPS duty cycle. This device setting is separate from LoRa RXPS (<code>radio.rxps</code>) and WiFi modem power save (<code>wifi.powersave</code>). Infrastructure WebConfig uses the <code>set powersaving</code> form; enabling it can put the node to sleep and make WiFi temporarily unavailable.</p>"},{"location":"cli_commands/#view-or-set-the-reboot-interval-repeater-and-room-server","title":"View or set the reboot interval (Repeater and room server)","text":"<p>Usage: - <code>get reboot.interval</code> - <code>set reboot.interval &lt;hours&gt;</code></p> <p>Parameters: - <code>hours</code>: <code>0-255</code>; <code>0</code> disables scheduled reboots.</p> <p>Default: <code>0</code> (disabled)</p>"},{"location":"cli_commands/#control-an-exposed-gpio","title":"Control an exposed GPIO","text":"<p>Availability: ESP32 Repeater, Room Server, Bridge, and Sensor firmware. Companion firmware does not expose these commands. On nRF52, the commands are enabled only for Sensor builds on the Heltec T096, ProMicro, RAK3401, and RAK4631. GPIO expanders are not supported.</p> <p>Usage:</p> <ul> <li><code>get gpio</code> - list the Arduino pin numbers this firmware build permits</li> <li><code>get gpio state</code>, <code>get gpio states</code>, or <code>get gpio status</code> - list every available pin currently controlled by the user (anything not in <code>reset</code>)</li> <li><code>get gpio state &lt;pin&gt;</code> - show one pin's state; <code>states</code> and <code>status</code> are accepted here too</li> <li><code>get gpio &lt;pin&gt;</code> - show <code>on</code>, <code>off</code>, or <code>reset</code>, plus any pending timed transition</li> <li><code>set gpio &lt;pin&gt; on</code></li> <li><code>set gpio &lt;pin&gt; off</code></li> <li><code>set gpio &lt;pin&gt; reset</code></li> <li><code>set gpio &lt;pin&gt; &lt;on|off&gt; &lt;duration&gt; &lt;on|off|reset&gt;</code></li> </ul> <p>Examples:</p> <ul> <li><code>set gpio 16 on 30 off</code> - drive GPIO16 high for 30 seconds, then drive it low</li> <li><code>set gpio 16 on 5ms off</code> - drive GPIO16 high for 5 milliseconds, then drive it low</li> <li><code>set gpio 16 off 5 reset</code> - drive GPIO16 low for 5 seconds, then return it to high impedance</li> </ul> <p>An integer duration has seconds as its default unit, so <code>5</code> means 5 seconds. Add <code>ms</code> for milliseconds (<code>5ms</code>); an explicit <code>s</code> suffix is also accepted (<code>5s</code>). The maximum duration is 24 hours (86,400 seconds or 86,400,000 milliseconds). <code>on</code> or <code>off</code> without a duration remains in that state until another command, reset, or reboot.</p> <p><code>reset</code> changes the pin to an input with no pull resistor (high impedance). It does not reboot the node. It also cancels any pending timer for that pin. A new timed command for the same pin cancels and replaces the previous timer. GPIOs begin in <code>reset</code>; states and timers are not saved and are lost on reboot.</p> <p>The immediate reply confirms the applied state and any pending transition. When a timed transition finishes, a command issued over the authenticated remote CLI receives a second report such as <code>&gt; GPIO 16 timer complete: off</code>. Retries of the same authenticated timed command are recognized and do not restart its countdown.</p> <p>The pin number is the Arduino pin number used by that target (the normal GPIO number on ESP32 and the board's <code>D</code>/pin index on nRF52). The available-pin list is build-specific. Radio, flash/PSRAM, USB, serial console, display, GPS, I2C, buttons, LEDs, battery measurement, power control, bridge, Ethernet, watchdog, and other pins claimed by the firmware are rejected. A pin must also be physically broken out on your board; <code>get gpio</code> cannot detect wiring or an attached peripheral that is not represented by the firmware configuration.</p> <p>Electrical warning: GPIOs use 3.3 V logic and have limited drive current. Do not power a relay, motor, solenoid, or other load directly from a GPIO. Use a suitable transistor, MOSFET, optocoupler, or driver with the required protection components.</p>"},{"location":"cli_commands/#routing","title":"Routing","text":""},{"location":"cli_commands/#view-or-set-the-direct-path-override-for-the-current-remote-client","title":"View or set the direct path override for the current remote client","text":"<p>Usage: - <code>get outpath</code> - <code>get outpath path</code> - <code>set outpath &lt;hop1_hex,hop2_hex,...&gt;</code> - <code>set outpath path</code> - <code>set outpath direct</code> - <code>set outpath clear</code> - <code>set outpath flood</code></p> <p>Parameters: - <code>hopN_hex</code>: Hop hash with <code>2</code>, <code>4</code>, or <code>6</code> hexadecimal characters. Every hop must use the same width.</p> <p>Notes: - These commands require remote client context and update the caller's ACL entry. - <code>get outpath path</code> reports the reciprocal <code>PAYLOAD_TYPE_PATH</code> received after   the caller's latest flood login without changing the selected output route.   Because that packet is asynchronous, an immediate query can report   <code>&gt; path pending</code>; retry shortly. The observation window expires after one   minute, and the captured login path is not automatically selected. - <code>set outpath path</code> copies that observed route to <code>outpath</code> and saves it. It   returns an error without changing <code>outpath</code> if no route was received. - <code>direct</code> selects a zero-hop route for a directly reachable caller. - <code>clear</code> forgets the override, replies <code>&gt; outpath cleared</code>, and allows normal   path discovery to repopulate it. - <code>flood</code> forces replies to use flood packets until the client logs in again.</p>"},{"location":"cli_commands/#view-or-change-this-nodes-repeat-flag","title":"View or change this node's repeat flag","text":"<p>Usage: - <code>get repeat</code> - <code>set repeat &lt;state&gt;</code></p> <p>Parameters:   - <code>state</code>: <code>on</code>|<code>off</code></p> <p>Default: <code>flood.channel.data on</code>; <code>flood.channel.data.hops h=all</code></p>"},{"location":"cli_commands/#view-or-change-this-nodes-advert-path-hash-size","title":"View or change this node's advert path hash size","text":"<p>Usage: - <code>get path.hash.mode</code> - <code>set path.hash.mode &lt;value&gt;</code></p> <p>Parameters: - <code>value</code>: Path hash size (0-2)   - <code>0</code>: 1 Byte hash size (256 unique ids)[64 max flood]   - <code>1</code>: 2 Byte hash size (65,536 unique ids)[32 max flood]   - <code>2</code>: 3 Byte hash size (16,777,216 unique ids)[21 max flood]   - <code>3</code>: DO NOT USE (Reserved) </p> <p>Default: <code>0</code></p> <p>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 &gt;= 1.14. This feature was added in firmware 1.14</p> <p>Temporary Note: adverts with ID/hash sizes of 2 or 3 bytes may have limited flood propagation 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 supported. Consider your install base of firmware &gt;=1.14 has reached a criticality for effective network flooding before implementing higher ID/hash sizes. </p>"},{"location":"cli_commands/#view-or-change-this-nodes-loop-detection","title":"View or change this node's loop detection","text":"<p>Usage: - <code>get loop.detect</code> - <code>set loop.detect &lt;state&gt;</code></p> <p>Parameters: - <code>state</code>:    - <code>off</code>: no loop detection is performed   - <code>minimal</code>: 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)   - <code>moderate</code>: 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)   - <code>strict</code>: 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)</p> <p>Default: <code>off</code></p> <p>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 (probably 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</p> <p>Example: If preference is <code>loop.detect minimal</code>, 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. </p>"},{"location":"cli_commands/#view-or-change-the-retransmit-delay-factor-for-flood-traffic","title":"View or change the retransmit delay factor for flood traffic","text":"<p>Usage: - <code>get txdelay</code> - <code>set txdelay &lt;value&gt;</code></p> <p>Parameters: - <code>value</code>: Transmit delay factor (0-2)</p> <p>Default: <code>0.5</code></p> <p>Note: When multiple nearby repeaters all hear the same flood packet, each waits a random amount of time before retransmitting to avoid simultaneous collisions. This factor scales the size of that random window. Higher values reduce collision risk at the cost of added latency. <code>0</code> disables the window entirely.</p>"},{"location":"cli_commands/#view-or-change-the-retransmit-delay-factor-for-direct-traffic","title":"View or change the retransmit delay factor for direct traffic","text":"<p>Usage: - <code>get direct.txdelay</code> - <code>set direct.txdelay &lt;value&gt;</code></p> <p>Parameters: - <code>value</code>: Direct transmit delay factor (0-2)</p> <p>Default: <code>0.2</code></p> <p>Note: Same collision-avoidance random window as <code>txdelay</code>, 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.</p>"},{"location":"cli_commands/#experimental-view-or-change-the-processing-delay-for-received-traffic","title":"[Experimental] View or change the processing delay for received traffic","text":"<p>Usage: - <code>get rxdelay</code> - <code>set rxdelay &lt;value&gt;</code></p> <p>Parameters: - <code>value</code>: Receive delay base (0-20)</p> <p>Default: <code>0.0</code></p> <p>Note: When enabled, repeaters that received a flood packet with a weak signal are held in a delay queue before processing, while those that received it with a strong signal process it immediately. This gives strong-signal paths forwarding priority. By the time weak-signal nodes process their copy, the packet may have already propagated and will be suppressed as a duplicate, reducing redundant retransmissions.</p>"},{"location":"cli_commands/#view-or-change-the-duty-cycle-limit","title":"View or change the duty cycle limit","text":"<p>Usage: - <code>get dutycycle</code> - <code>set dutycycle &lt;value&gt;</code></p> <p>Parameters: - <code>value</code>: Duty cycle percentage (1-100)</p> <p>Default: <code>50%</code> (equivalent to airtime factor 1.0)</p> <p>Examples: - <code>set dutycycle 100</code> - no duty cycle limit - <code>set dutycycle 50</code> - 50% duty cycle (default) - <code>set dutycycle 10</code> - 10% duty cycle - <code>set dutycycle 1</code> - 1% duty cycle (strictest EU requirement)</p> <p>Note: Added in firmware v1.15.0</p>"},{"location":"cli_commands/#view-or-change-the-airtime-factor-duty-cycle-limit","title":"View or change the airtime factor (duty cycle limit)","text":"<p>Deprecated as of firmware v1.15.0. Use <code>get/set dutycycle</code> instead.</p> <p>Usage: - <code>get af</code> - <code>set af &lt;value&gt;</code></p> <p>Parameters: - <code>value</code>: 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:   - <code>af = 1</code> -&gt; ~50% duty   - <code>af = 2</code> -&gt; ~33% duty   - <code>af = 3</code> -&gt; ~25% duty   - <code>af = 9</code> -&gt; ~10% duty   You are responsible for choosing a value that is appropriate for your jurisdiction and channel plan (for example EU 868 Mhz 10% duty cycle regulation).</p> <p>Default: <code>1.0</code></p>"},{"location":"cli_commands/#view-or-change-the-local-interference-threshold","title":"View or change the local interference threshold","text":"<p>Usage: - <code>get int.thresh</code> - <code>set int.thresh &lt;value&gt;</code></p> <p>Parameters: - <code>value</code>: Interference threshold value</p> <p>Default: <code>0.0</code></p>"},{"location":"cli_commands/#enable-or-disable-hardware-channel-activity-detection-cad","title":"Enable or disable hardware Channel Activity Detection (CAD)","text":"<p>Usage: - <code>get cad</code> - <code>set cad &lt;on|off&gt;</code></p> <p>Description: When enabled, the radio performs a hardware Channel Activity Detection scan before transmitting and defers if the channel is busy. Runs independently of <code>int.thresh</code> - either, both, or none may be active.</p> <p>The Cascade firmware profile defaults CAD to <code>on</code>; target-default builds continue to default it to <code>off</code>. The repeater applies the saved toggle to the radio during its periodic noise-floor service. With one runnable packet, a busy result uses the normal CAD retry delay and allows roughly four seconds of continuous busy results. As the runnable transmit queue grows, both delays are divided by its depth: retry spacing will not fall below 50 ms and the busy ceiling will not fall below 500 ms. Reaching the busy ceiling records a CAD-timeout error and attempts the next queued transmission rather than waiting indefinitely. Future-scheduled packets do not accelerate CAD. <code>get cad</code> includes the hardware busy-result count.</p> <p>Parameters: - <code>on|off</code>: Enable or disable hardware CAD</p> <p>Default: <code>off</code></p>"},{"location":"cli_commands/#view-or-change-the-agc-reset-interval","title":"View or change the AGC Reset Interval","text":"<p>Usage: - <code>get agc.reset.interval</code> - <code>set agc.reset.interval &lt;value&gt;</code></p> <p>Parameters: - <code>value</code>: Interval in seconds rounded down to a multiple of 4 (17 becomes 16). 0 to disable.</p> <p>Default: <code>0.0</code></p>"},{"location":"cli_commands/#view-or-change-the-radio-watchdog-interval-mqtt-observer-only","title":"View or change the radio watchdog interval (MQTT observer only)","text":"<p>Usage: - <code>get radio.watchdog</code> - <code>set radio.watchdog &lt;minutes&gt;</code></p> <p>Parameters: - <code>minutes</code>: <code>0</code> to disable, or <code>1-120</code> minutes</p> <p>Default: <code>5</code></p> <p>Note: This watchdog belongs to the MQTT observer runtime and is not available on a standalone FULL repeater. On quiet meshes, increasing it can reduce false recoveries when no traffic is expected.</p>"},{"location":"cli_commands/#enable-or-disable-multi-acks-support","title":"Enable or disable Multi-Acks support","text":"<p>Usage: - <code>get multi.acks</code> - <code>set multi.acks &lt;state&gt;</code></p> <p>Parameters: - <code>state</code>: <code>0</code> (disable) or <code>1</code> (enable)</p> <p>Default: <code>0</code></p>"},{"location":"cli_commands/#view-or-change-the-flood-advert-interval","title":"View or change the flood advert interval","text":"<p>Usage: - <code>get flood.advert.interval</code> - <code>set flood.advert.interval &lt;hours&gt;</code></p> <p>Parameters: - <code>hours</code>: Interval in hours (3-168)</p> <p>Default: <code>12</code> (Repeater) - <code>0</code> (Sensor)</p>"},{"location":"cli_commands/#view-or-change-the-zero-hop-advert-interval","title":"View or change the zero-hop advert interval","text":"<p>Usage: - <code>get advert.interval</code> - <code>set advert.interval &lt;minutes&gt;</code></p> <p>Parameters: - <code>minutes</code>: Interval in minutes rounded down to the nearest multiple of 2 (61 becomes 60) (60-240)</p> <p>Default: <code>0</code></p>"},{"location":"cli_commands/#limit-the-number-of-hops-for-a-flood-message","title":"Limit the number of hops for a flood message","text":"<p>Usage: - <code>get flood.max</code> - <code>set flood.max &lt;value&gt;</code></p> <p>Parameters: - <code>value</code>: Maximum flood hop count (0-64)</p> <p>Default: <code>64</code></p>"},{"location":"cli_commands/#limit-the-number-of-hops-for-an-unscoped-flood-message","title":"Limit the number of hops for an unscoped flood message","text":"<p>Usage: - <code>get flood.max.unscoped</code> - <code>set flood.max.unscoped &lt;value&gt;</code></p> <p>Parameters: - <code>value</code>: Maximum flood hop count (0-64) for a packet without a scope (no region set)</p> <p>Default: <code>0xFF</code> - indicates it hasn't been set, will track flood.max until it is.</p> <p>Note: An alternative to <code>region denyf *</code>, setting <code>flood.max.unscoped</code> to a lower value such as <code>3</code> would allow for local unscoped messages to propagate, while preventing noisy neighbors from flooding a local region.</p>"},{"location":"cli_commands/#limit-the-number-of-hops-for-an-advert-flood-message","title":"Limit the number of hops for an advert flood message","text":"<p>Usage: - <code>get flood.max.advert</code> - <code>set flood.max.advert &lt;value&gt;</code></p> <p>Parameters: - <code>value</code>: Maximum flood hop count (0-64) for an advert packet</p> <p>Default: <code>8</code></p>"},{"location":"cli_commands/#forward-flood-group-data-packets-on-repeaters","title":"Forward flood group data packets on repeaters","text":"<p>Usage: - <code>get flood.channel.data</code> - <code>get flood.channel.data.hops</code> - <code>set flood.channel.data &lt;on|off&gt;</code> - <code>set flood.channel.data.hops &lt;all|1-7&gt;</code></p> <p>Parameters: - <code>on</code>: Retransmit received flood <code>GRP_DATA</code> channel packets. - <code>off</code>: Do not retransmit received flood <code>GRP_DATA</code> channel packets. - <code>all</code>: When <code>flood.channel.data</code> is <code>off</code>, block <code>GRP_DATA</code> at any received flood hop count. - <code>1-7</code>: When <code>flood.channel.data</code> is <code>off</code>, repeat <code>GRP_DATA</code> at this hop count or lower and block longer paths.</p> <p>Default: <code>flood.channel.data on</code>; <code>flood.channel.data.hops h=all</code></p> <p>Forwarding behavior: Repeater firmware only. The repeater still receives and logs the packet when logging is enabled; this only blocks retransmission. On generalized repeaters these commands manage an ordinary visible FPF7 <code>type=grp_data</code> drop row. <code>off</code> with <code>all</code> maps to <code>hops=all</code>; <code>off</code> with <code>N</code> maps to <code>hops=N+1+</code>. The 240 KB compact FPF6 profiles retain the legacy hard gate. Because it is an ordinary FPF7 row, a matching higher-priority <code>stop</code> rule can exempt traffic from it. The compact <code>get flood.filter</code> list marks the managed row with <code>~data</code>. Flood group text (<code>GRP_TXT</code>) is unaffected by this setting.</p> <p><code>get flood.channel.data</code> includes the active hop gate as <code>h=all</code> or <code>h&gt;N</code>.</p>"},{"location":"cli_commands/#block-selected-flood-channels-with-fpf7","title":"Block selected flood channels with FPF7","text":"<p>The separate <code>flood.channel.block</code> command and 15-row table have been retired. Generalized repeaters use the 63-row FPF7 forward phase for authenticated channel blocks:</p> <pre><code>set flood.rule type=any channel=#test hops=all drop\nset flood.rule.2 type=any channel=#wardriving hops=5+ drop\nset flood.rule type=any channel=9cd8fcf22a47333b591d96a2b848b73f hops=4+ drop\nget flood.rule\ndel flood.rule.2\n</code></pre> <p><code>type=any</code> with a channel condition can authenticate only <code>GRP_TXT</code> and <code>GRP_DATA</code>, so it does not match other payload types. Use <code>hops=all</code> to block at every received hop count. To preserve the old <code>h=N</code> meaning of repeating through <code>N</code> hops and blocking longer paths, use <code>hops=N+1+</code>; old <code>h=4</code> is therefore <code>hops=5+</code>.</p> <p>New generalized repeater tables seed slot 2 with the second example. Existing FCB2 rows are imported once into free FPF7 slots and the retired file is then removed. The fixed-size STM32WL FPF6 build cannot match authenticated channels.</p>"},{"location":"cli_commands/#force-a-transport-scope-onto-floods","title":"Force a transport scope onto floods","text":"<p>Usage: - <code>get flood.channel.scope</code> - <code>get flood.channel.scope.&lt;n&gt;</code> - <code>set flood.channel.scope &lt;channel|txt:*|login:*|other:*&gt; &lt;region|scope=name&gt; [path=blacklist|path=bucket:1-6] [tx=slow]</code> - <code>set flood.channel.scope.&lt;n&gt; &lt;channel|txt:*|login:*|other:*&gt; &lt;region|scope=name&gt; [path=blacklist|path=bucket:1-6] [tx=slow]</code> - <code>del flood.channel.scope.&lt;n&gt;</code> - <code>del flood.channel.scope all</code></p> <p>Parameters: - <code>n</code>: Slot number within the table compiled for the target. Roomy ESP32 builds   provide <code>1-255</code>; DRAM-tight classic ESP32 LoRa-OTA repeaters and nRF52/other   normal constrained builds provide <code>1-31</code>; very-tight STM32WL repeaters provide   <code>1-15</code>; the no-PSRAM LilyGo T-LoRa V2.1 repeater/observer provides <code>1-4</code>. - <code>channel</code>: <code>public</code>, a public <code>#channel</code>, or a 128/256-bit channel key in hex. - <code>txt:*</code>: Unauthenticated fallback for otherwise-unmatched <code>GRP_TXT</code> and   <code>GRP_DATA</code>. Plain <code>*</code> is an alias for <code>txt:*</code>. - <code>login:*</code>: Type-based wildcard for the remote-login/admin family: <code>REQ</code>,   <code>RESPONSE</code>, <code>TXT_MSG</code>, <code>ANON_REQ</code>, and <code>PATH</code> (<code>0x00</code>, <code>0x01</code>, <code>0x02</code>,   <code>0x07</code>, and <code>0x08</code>). It classifies the outer type; a transit repeater cannot   authenticate whether a packet is actually part of a login session. - <code>other:*</code>: Type-based wildcard for every remaining flood payload type,   including flood-form TRACE, ACK, advert, multipart, control, OTA, reserved   types, and raw custom. - <code>region</code>: Existing named region with a usable transport key. A unique region   name prefix is accepted; wildcard region <code>*</code> is not a scope target. - <code>scope=&lt;name&gt;</code>: Regionless alternative to <code>region</code>. The public name is   normalized with a leading <code>#</code>, and its 128-bit transport key is derived   directly from that hashtag exactly as for <code>flood.filter scope=&lt;name&gt;</code>. It   does not need to exist in the region list. Public names up to 30 characters   are accepted; private <code>$</code> scopes are not. - <code>path=blacklist</code>: Optional. Require the received path to match the passive   <code>flood.filter.blacklist</code> ID table. No <code>flood.filter</code> drop row needs to be   enabled. One exact listed ID qualifies a 3-byte path. A 2-byte path requires   two matching received path entries, while a 1-byte path never qualifies. - <code>path=bucket:&lt;1-6&gt;</code>: Optional alternative to <code>path=blacklist</code>. Match IDs in   the selected persistent <code>flood.retry.bucket</code>. Each bucket holds up to 17   three-byte IDs and remains usable when <code>flood.retry.bridge</code> is off. It uses   the same 3-byte, 2-byte, and 1-byte thresholds as <code>path=blacklist</code>.   <code>recent.repeater</code> freshness and <code>flood.retry.ignore</code> do not affect this   passive match. - <code>tx=slow</code>: Optional. Use an effective inbound <code>rxdelay</code> base of   <code>max(2, configured rxdelay * 2)</code>, keep normal outbound queue priority, and   schedule retransmission with the maximum supported <code>txdelay</code> factor of   <code>2.0</code> after changing the scope. The default is fast; <code>tx=fast</code> may be   supplied explicitly when replacing a slow row.</p> <p>Default: No forced scopes.</p> <p>Remote ACL permission <code>4</code> (region/scope manager) can use all <code>get</code>, <code>set</code>, and <code>del flood.channel.scope</code> forms. Filter managers and other non-admin roles cannot change this table.</p> <p>Without <code>.n</code>, <code>set</code> updates the row for the same exact channel key or wildcard class with the same path selector, otherwise it uses the first empty slot. This permits an ordinary fallback and separate blacklist or bridge-bucket rows for the same channel. With <code>.n</code>, it replaces that slot. The three wildcard classes are independent and consume one slot each. <code>get flood.channel.scope</code> reports active/total slot counts; use the numbered form for row detail. Keyed rows are displayed by the first four bytes of their derived channel hash because channel secrets are never returned. Regionless targets are displayed with their normalized leading <code>#</code>.</p> <p>This acts on received <code>ROUTE_TYPE_FLOOD</code> and <code>ROUTE_TYPE_TRANSPORT_FLOOD</code> packets. An unscoped packet gains the configured scope; an already-scoped packet has its existing transport codes replaced. For <code>GRP_TXT</code> and <code>GRP_DATA</code>, all exact channel-key rows are tried first and must validate the packet MAC/decryption. Matching path-qualified exact rows are   tried before ordinary exact fallback rows. A region-backed row whose target   is missing or unusable is skipped; later exact rows and then <code>txt:*</code> are tried. Exact keyed rows with a usable target therefore beat <code>txt:*</code> regardless of slot number. Within each wildcard class, path-qualified rows similarly precede ordinary fallback rows. <code>login:*</code> and <code>other:*</code> select their non-overlapping outer-type families without decrypting the payload. The lowest usable slot wins within each priority tier.</p> <p>Standard traceroute is direct-routed and is therefore outside this flood-only table. A custom flood-form <code>TRACE</code> is treated like every other flood: an applicable wildcard may rewrite it and region/unknown-code gates still apply.</p> <p>On a match, the repeater sets the route to <code>ROUTE_TYPE_TRANSPORT_FLOOD</code>, computes transport code 0 from the selected region or direct hashtag key and packet payload, and sets transport code 1 to zero. This occurs before region enforcement, forwarding filters, and the seen-packet lookup. For an already-scoped packet, the selected code replaces both incoming transport-code fields. Direct routes are never rewritten. A packet converted from unscoped is no longer subject to <code>flood.max.unscoped</code>; all rewritten packets remain subject to normal payload handling, <code>flood.max</code>, <code>flood.filter</code>, loop detection, and moderation. Assigning a scope does not make a packet type forwardable if the core would otherwise reject it. By default, if the selected scope differs and the rewritten packet is accepted for forwarding, its initial retransmission uses zero <code>txdelay</code> and the highest outbound queue priority so the newly scoped copy can win at the next hop. Adding <code>tx=slow</code> uses an effective inbound <code>rxdelay</code> base of <code>max(2, configured rxdelay * 2)</code>, keeps the ordinary queue priority, and uses the maximum <code>txdelay</code> factor of <code>2.0</code> for the retransmission. As with ordinary <code>txdelay</code>, the actual transmit delay is randomized from zero through the resulting window; factor <code>2.0</code> gives a maximum of ten packet airtimes. Neither mode preempts an active radio transmission or bypasses CAD and airtime-budget limits. Selecting the scope already carried by the packet is a no-op and does not grant special transmit treatment.</p> <p>A region-backed target must be locally flood-allowed and remains subject to the normal region gate. A <code>scope=&lt;name&gt;</code> target is trusted for this matched receive pass even though it has no region-list entry, matching the behavior of <code>flood.filter scope=&lt;name&gt;</code>. It does not create a region, consume a region slot, or change the allow/deny state for unrelated packets carrying the same transport code.</p> <p>If a region-backed row's target has been removed or has no usable key, the repeater tries the next applicable row. For group packets this means later authenticated exact rows followed by <code>txt:*</code>; wildcard duplicates likewise fall through to the next usable slot. When no usable mapping exists, the packet retains its original unscoped or scoped route.</p> <p>LoRa OTA remains functional when <code>other:*</code> is configured. OTA packets are given that target's transport code, replacing an existing code when necessary, but the OTA handler still accepts and re-floods them during the temporary-radio window. A region target must allow flooding; a direct target follows the regionless trust behavior above. The OTA core itself is dormant outside that window; no default flood filter row is needed for that behavior. Forced scope does not make OTA operate outside the window.</p> <p>Capacity cost: Each rule slot retains its 36-byte runtime and persistent record. A separate 32-byte-name table holds up to the smaller of the rule count or 32 distinct regionless targets; very-tight STM32WL builds hold one reusable direct target. Region-backed targets do not consume this table. The four-slot minimum uses 272 bytes RAM and a 278-byte file; it has room for the three wildcard classes plus one exact channel mapping. Very-tight 15-slot builds use 572 bytes RAM and a 578-byte file. The 31-slot table uses 2,108 bytes RAM and a 2,114-byte file. Roomy ESP32 builds use 255 rule slots and 32 direct-target slots: 10,204 bytes RAM and a 10,210-byte file. Classic ESP32 LoRa-OTA builds that cannot afford the 255-rule table use 31 slots instead. Both configured regions and regionless targets can be reused by any number of rules.</p> <p>Duplicate behavior: Mesh dedup hashes payload type and payload bytes; it does not hash route type, transport codes, or the ordinary flood path. Adding a transport scope therefore does not create a new duplicate identity. If the same payload later arrives scoped, unscoped, or through a different region, it is still the same seen packet. <code>TRACE</code> is the exception only in that its encoded <code>path_len</code> byte is also hashed.</p> <p>While equivalent non-TRACE flood copies are waiting in <code>rxdelay</code>, the normal receive-quality timing still selects the packet to process, but that winner receives a scope from the queued scoped copies with the same dedupe identity. If the copies carry different locally allowed scopes, the scope from the shortest received path wins. Unknown and denied transport codes are not candidates and therefore cannot overwrite an unscoped winner. With equal path lengths, the deeper child region wins because it is narrower. A remaining tie keeps queue order. The winner's own path, SNR reading, and scheduled time are not changed, and an already-scoped winner may have its code replaced by the better queued scope.</p> <p>The comparison is deferred until dequeue so each copy retains its original scope and path for arbitration. It can only use copies still present in <code>rxdelay</code>; it cannot replace a packet that already won the dedupe race. Flood-form TRACE participates in this arbitration; direct traceroute does not enter the flood queue.</p> <p>A packet that matches a fast <code>flood.channel.scope</code> or <code>flood.filter scope=</code> action and needs its scope changed bypasses the inbound <code>rxdelay</code> queue. A <code>tx=slow</code> row remains in that queue with twice the configured base, floored at <code>2.0</code>, and participates in normal queued-copy scope arbitration.</p> <p>Examples:</p> <pre><code>region put west\nregion save\nset flood.channel.scope #local west\nset flood.channel.scope.2 txt:* west tx=slow\nset flood.channel.scope.3 login:* west\nset flood.channel.scope.4 other:* west\nget flood.channel.scope\nget flood.channel.scope.1\ndel flood.channel.scope.2\n</code></pre> <p>A regionless exact mapping needs no <code>region</code> command:</p> <pre><code>set flood.channel.scope #rgdata scope=BlackHole86\nget flood.channel.scope\nget flood.channel.scope.1\n</code></pre> <p>For example, if an authenticated <code>#rgdata</code> packet arrives carrying scope <code>#usa</code>, that rule replaces <code>#usa</code> with <code>#BlackHole86</code> before forwarding. The rule also assigns <code>#BlackHole86</code> when the packet is unscoped or carries any other scope; it is a channel-to-target mapping, not an incoming-scope filter.</p> <p>To use bridge bucket 1 to assign <code>east</code> to <code>public</code> packets whose received 3-byte path contains <code>7576FB</code>, while assigning <code>west</code> to every other authenticated <code>public</code> packet:</p> <pre><code>set flood.retry.bucket 1 7576FB\nset flood.channel.scope public west\nset flood.channel.scope public east path=bucket:1\n</code></pre> <p>Additional 3-byte IDs may be added to bucket 1 later; any one exact hit qualifies the <code>east</code> row. This use is passive and does not require <code>flood.retry.bridge</code> to be enabled. The separate blacklist selector remains available for tables shared with <code>flood.filter path=blacklist</code> rules.</p>"},{"location":"cli_commands/#require-valid-incoming-scopes-only-on-selected-channels","title":"Require valid incoming scopes only on selected channels","text":"<p>Usage: - <code>get flood.channel.scope.require</code> - <code>get flood.channel.scope.require.&lt;n&gt;</code> - <code>set flood.channel.scope.require &lt;public|#channel|128/256-bit-key&gt;</code> - <code>set flood.channel.scope.require.&lt;n&gt; &lt;public|#channel|128/256-bit-key&gt;</code> - <code>del flood.channel.scope.require.&lt;n&gt;</code> - <code>del flood.channel.scope.require all</code></p> <p>Default: Empty; normal global region enforcement remains active.</p> <p>Once this table contains a row, received flood <code>GRP_TXT</code> and <code>GRP_DATA</code> packets use selective region enforcement. A packet authenticating against a listed channel key must already carry a transport scope matching a locally flood-allowed region. Listed channels arriving unscoped, with an unknown code, or with a denied region are not retransmitted. This tests the original incoming scope before any <code>flood.channel.scope</code> or <code>flood.filter scope=</code> rewrite. Those rewrite actions are skipped for a rejected listed channel, so they cannot rescue it or grant special receive/transmit timing.</p> <p>Other group channels bypass the region/unknown-code gate while the table is active. They remain subject to every other forwarding control, including <code>repeat</code>, <code>flood.max*</code>, packet filters, loop detection, payload validation, and moderation. Non-channel flood payload types retain normal global region enforcement.</p> <p>Channel matching validates the packet MAC/decryption with the configured key; the visible one-byte channel hash is only a prefilter. Public hashtag channels use their derived public key. Without <code>.n</code>, setting an existing key updates it and a new key uses the first empty slot. Numbered <code>set</code> replaces that slot. <code>get ...&lt;n&gt;</code> reports a four-byte derived prefix and key size without exposing the key. The table uses the same build-dependent slot count as <code>flood.channel.scope</code>.</p> <p>Remote ACL permission <code>4</code> can manage this table. Deleting its final row restores normal global region enforcement for group channels.</p> <p>Example:</p> <pre><code>set flood.channel.scope.require #bot\nget flood.channel.scope.require\nget flood.channel.scope.require.1\n</code></pre>"},{"location":"cli_commands/#change-persistent-flood-rules-in-the-field","title":"Change persistent flood rules in the field","text":"<p>For setup guidance, interactions with the existing forwarding controls, and worked moderation examples, see Flood Filtering and Moderation.</p> <p>Usage: - <code>get flood.rule</code> - <code>get flood.rule.&lt;n&gt;</code> - <code>set flood.rule[.&lt;n&gt;] type=&lt;type&gt; [hops=&lt;range&gt;] [channel=&lt;channel&gt;] [prefix=&lt;path-prefix&gt;] [in=&lt;input-scope&gt;] &lt;drop|scope=&lt;name&gt;|region=&lt;name&gt;|rate=&lt;N&gt;/min|retry|stop&gt; [priority=&lt;0-255&gt;] [tx=slow] [suspend=tempradio]</code> - <code>del flood.rule.&lt;n&gt;</code> - <code>del flood.rule all</code> - <code>get flood.filter</code> - <code>get flood.filter.&lt;n&gt;</code> - <code>get flood.filter.blacklist</code> - <code>get flood.filter.blacklist.&lt;n&gt;</code> - <code>set flood.filter.blacklist &lt;ID[,ID...]&gt;</code> - <code>set flood.filter.blacklist.&lt;n&gt; &lt;ID[,ID...]&gt;</code> - <code>del flood.filter.blacklist</code> - <code>del flood.filter.blacklist.&lt;n&gt;</code> - <code>set flood.filter &lt;type&gt; [hops] [path=blacklist] [scope=&lt;name&gt;] [require=region] [tx=slow] [suspend=tempradio]</code> - <code>set flood.filter.&lt;n&gt; &lt;type&gt; [hops] [path=blacklist] [scope=&lt;name&gt;] [require=region] [tx=slow] [suspend=tempradio]</code> - <code>del flood.filter.&lt;n&gt;</code> - <code>del flood.filter all</code></p> <p>The extended table is available on repeaters with the rule engine enabled and on FULL-profile ESP32 room servers. A FULL room server exposes both <code>flood.rule</code> and <code>flood.filter</code>, has 31 slots, and requires an administrator for remote changes. It does not have the repeater's passive path blacklist, so <code>flood.filter.blacklist*</code> and <code>path=blacklist</code> are repeater-only; use the ordered <code>prefix=</code> match on a room server. Standard room-server profiles do not compile this table.</p> <p>Parameters: - <code>n</code>: Forward-rule slot in the build's compiled table (<code>1-63</code> on generalized   repeaters and <code>1-31</code> on FULL room servers; compact profiles may use fewer). - <code>type</code>: Payload type name, full <code>PAYLOAD_TYPE_*</code> name, decimal value <code>0-15</code>,   hexadecimal value <code>0x00-0x0F</code>, or <code>any</code>. - <code>hops</code>: Optional; omitted means <code>all</code>.   - <code>N</code>: Match only at received hop count <code>N</code>.   - <code>N+</code>: Match at received hop count <code>N</code> and higher.   - <code>N-M</code>: Match the inclusive received-hop range.   - <code>all</code>: Match every received hop count (<code>0-63</code>).   - <code>0+</code>, <code>all</code>, and an omitted hop expression are equivalent. The CLI displays     the saved range as <code>all</code>. - <code>channel=*|public|#name|hash:XX|128-bit-key|256-bit-key</code>: Optional channel match.   <code>channel=*</code> means no channel condition at all, so the row matches everything   selected by <code>type=</code> (including all flood payload types with <code>type=any</code>). It   does not authenticate a packet. <code>public</code>, <code>#name</code>, and raw keys authenticate   one channel and therefore narrow the row to <code>GRP_TXT</code>/<code>GRP_DATA</code>.   <code>hash:XX</code> matches only the visible one-byte group-channel hash; <code>short:XX</code>   and a bare two-digit byte are accepted aliases and are displayed as   <code>hash:XX</code>. This form is deliberately unauthenticated. It can collide with   another channel once in 256 hash values, and a sender can choose the byte,   so use an exact channel name or key whenever it is available. In particular,   <code>channel=hash:11</code> does not mean Public: it matches Public plus every collision   or deliberately selected <code>0x11</code> value. <code>channel=public</code> performs the deeper   MAC/decrypt check with the Public channel key. That distinguishes an ordinary   <code>0x11</code> collision, but it is channel authentication rather than sender   authentication: the group MAC is two bytes and the Public key is shared. - <code>prefix=&lt;ID[,ID...]&gt;</code>: Optional ordered source-path prefix of one to three   pbyte IDs. IDs must all be 2, 4, or 6 hex characters, matching a packet's   1-, 2-, or 3-byte pbyte width. <code>path=&lt;prefix&gt;</code> is an alias. - <code>in=any|none|scoped|allowed|unknown|scope:&lt;name&gt;|region:&lt;name&gt;</code>: Optional   condition on the original incoming scope, before any rule rewrites it.   <code>none</code> is an unscoped flood. <code>scope:name</code> is the exact public   hashtag-derived scope. <code>region:name</code> is an exact allowed region match. - <code>drop</code>: Explicit drop action. The <code>flood.rule</code> form requires an explicit   action. For compatibility, a legacy <code>flood.filter</code> row with no rewrite,   rate, or stop action is treated as drop. - <code>scope=&lt;name&gt;</code>: Direct public-name scope rewrite. It derives a transport key   from the name and does not require a configured region. For example,   <code>scope=BlackHole86</code> is a regionless sink scope; <code>region=BlackHole86</code> would   instead require a real configured, flood-allowed region with that name. - <code>region=&lt;name&gt;</code>: Rewrite using an existing locally allowed region and one of   that region's transport keys. - <code>rate=N/min</code>: Per-node, per-row fixed one-minute forwarding limit. It can be   the only action or accompany <code>scope=</code>/<code>region=</code>. Counters are charged only   for packets that pass all forwarding gates. - <code>retry</code>, <code>retry=on</code>, <code>retry=allow</code>, or <code>action=retry</code>: Allow a matching   received flood packet to enter the configured flood-retry sequence. With no   active <code>retry</code> rows, retry eligibility remains backward compatible and is   controlled by the global retry settings. Once any active <code>retry</code> row exists,   the matching rows become a retry allow-list: a received flood must match at   least one surviving <code>retry</code> row. <code>flood.retry.bridge</code> still selects ordinary   or bridge-bucket completion for the allowed packet. This action can accompany   rewrite, rate, or stop, but not <code>drop</code>; compact syntax uses <code>f=r</code>. - <code>priority=0-255</code>: Optional primary processing order. Higher values run first.   At the same numeric priority, authenticated channel matches run before raw   <code>hash:XX</code> matches, which run before <code>channel=*</code>; lower slot number breaks the   remaining tie. The default is <code>0</code>; <code>pri=</code> is an alias. An explicitly higher   numeric priority still overrides this automatic specificity ordering. - <code>stop</code> or <code>action=stop</code>: Apply this matching row, then stop lower-order FPF7   rows from processing. It can stand alone or accompany drop, rewrite, or   rate. A stop-only row acts as an exception to lower-priority FPF7 rules.   If the same row uses <code>region=</code> and that configured region is missing, denied,   wildcard, or has no usable transport key, both the rewrite and its <code>stop</code>   are inert so lower-order safety rows still run. A direct <code>scope=</code> target does   not depend on region configuration. - <code>suspend=tempradio</code>: Optional. Skip this row only while the temporary radio   is actually active. - <code>require=region</code>: Legacy alias for <code>in=allowed</code>. Apply the row only if the   original incoming packet already passes this repeater's   region gate. An incoming transport scope must resolve to a locally allowed   region; an unscoped flood must be allowed by the wildcard region. The check   occurs before any scope rewrite during this receive pass. - <code>tx=slow</code>: Optional and valid with <code>scope=</code> or <code>region=</code>. Use an effective inbound   <code>rxdelay</code> base of <code>max(2, configured rxdelay * 2)</code>, keep normal outbound   queue priority, and retransmit with the maximum supported <code>txdelay</code> factor   of <code>2.0</code>. Scope rows default to fast; <code>tx=fast</code> explicitly restores that   default when replacing a slow row. - <code>path=blacklist</code>: Optional unordered path condition. The persistent blacklist   is repeater-only. It contains up to 255 unique 3-byte repeater IDs on ESP32   builds and 18 on other builds, each written as six hexadecimal digits. A   packet with 3-byte path hashes matches after one exact ID hit. A packet with   2-byte path hashes matches after two path entries match the first two bytes   of listed IDs. Packets with 1-byte path hashes never match this condition.   Each received path entry is counted at most once.</p> <p>The payload names follow the MeshCore packet-format allocation:</p> Value Short name Full name <code>0x00</code> <code>req</code> <code>PAYLOAD_TYPE_REQ</code> <code>0x01</code> <code>response</code> <code>PAYLOAD_TYPE_RESPONSE</code> <code>0x02</code> <code>txt_msg</code> <code>PAYLOAD_TYPE_TXT_MSG</code> <code>0x03</code> <code>ack</code> <code>PAYLOAD_TYPE_ACK</code> <code>0x04</code> <code>advert</code> <code>PAYLOAD_TYPE_ADVERT</code> <code>0x05</code> <code>grp_txt</code> <code>PAYLOAD_TYPE_GRP_TXT</code> <code>0x06</code> <code>grp_data</code> <code>PAYLOAD_TYPE_GRP_DATA</code> <code>0x07</code> <code>anon_req</code> <code>PAYLOAD_TYPE_ANON_REQ</code> <code>0x08</code> <code>path</code> <code>PAYLOAD_TYPE_PATH</code> <code>0x09</code> <code>trace</code> <code>PAYLOAD_TYPE_TRACE</code> <code>0x0A</code> <code>multipart</code> <code>PAYLOAD_TYPE_MULTIPART</code> <code>0x0B</code> <code>control</code> <code>PAYLOAD_TYPE_CONTROL</code> <code>0x0C</code> <code>ota</code> <code>PAYLOAD_TYPE_OTA</code> (this fork's LoRa OTA extension; reserved upstream) <code>0x0D</code> <code>13</code> reserved <code>0x0E</code> <code>14</code> reserved <code>0x0F</code> <code>raw_custom</code> <code>PAYLOAD_TYPE_RAW_CUSTOM</code> <p>Route scope: Rules are evaluated only for the two flood route values: <code>ROUTE_TYPE_TRANSPORT_FLOOD</code> (<code>0x00</code>, flood plus transport codes) and <code>ROUTE_TYPE_FLOOD</code> (<code>0x01</code>, unscoped flood). Direct routes <code>0x02</code> and <code>0x03</code> are never affected.</p> <p>Behavior: Match fields within one row are ANDed. Every FPF7 row is matched against the same immutable receive-time packet, before any rule changes its scope. Matching rows are processed in descending <code>priority</code>. At equal numeric priority, authenticated channel matches precede raw hashes, which precede an unrestricted channel matcher; lower slot wins after that. The first matching <code>stop</code> row is included and all lower-order FPF7 matches are discarded. A stop cannot undo an earlier drop or bypass hard forwarding gates or the other policy phases. A row with <code>path=blacklist</code> must meet the path condition as well as its other conditions; blacklist IDs can occur anywhere in the received path and their configured order is irrelevant. In contrast, <code>prefix=</code> begins at the first received path entry and preserves order. A matching drop row prevents retransmission. The highest-order remaining matching scope/region row wins; matching drop and rate rows remain independent and can still block the rewritten packet. Scope rewriting happens before region enforcement and is trusted even when its name is absent from the local region list. It does not bypass <code>repeat</code>, <code>flood.max</code>, other drop rows, loop detection, or moderation.</p> <p>Retry selection uses that same ordered, stop-truncated match set. With at least one active <code>retry</code> row, a received flood starts a retry sequence only when one of those matching rows includes <code>retry</code>. This selector cannot override <code>flood.retry.count</code>, path/type attempt caps, <code>flood.retry.advert</code>, disabled forwarding, a drop decision, or any other hard forwarding gate. Locally originated floods retain the normal global retry behavior.</p> <p>With <code>require=region</code>, a failed check makes that scope row ineligible. It leaves the packet unchanged and does not set the filter-scope trust bypass, so an unknown or denied incoming region is rejected normally unless another independent scope rule rewrites it. Later eligible filter scope rows may still match.</p> <p>By default, when a scope row will change the packet's transport codes, the packet bypasses inbound <code>rxdelay</code>; its retransmission then uses zero <code>txdelay</code> and the highest outbound queue priority. With <code>tx=slow</code>, the rewrite instead uses an effective inbound <code>rxdelay</code> base of <code>max(2, configured rxdelay * 2)</code>, normal queue priority, and the maximum <code>txdelay</code> factor of <code>2.0</code>. The actual randomized transmit wait ranges from zero to ten packet airtimes. Selecting the scope already carried is a no-op and does not grant special treatment. An active radio transmission is not preempted, and CAD and airtime-budget limits still apply.</p> <p>The packet is still received and can still be logged. Rules are persistent data and can be changed over serial or authenticated remote CLI without an OTA or reboot. <code>flood.rule</code> and <code>flood.filter</code> address the same table on extended builds; FPF6 files are migrated in memory and the next save writes FPF7. FPF1-FPF5 files are rejected and filtering fails open. FPF7 stores canonical region names rather than transient numeric region IDs. Removing, reordering, or reusing a region ID therefore cannot silently retarget a rule. If a saved input or target region name is absent, that input match or rewrite is inert; restoring the same region name reactivates it. While the temporary radio is active, only rows explicitly marked <code>suspend=tempradio</code> are skipped. <code>tempradio</code> is a radio state, not an OTA mode; normal payload types can also use the temporary channel. Other rows remain in force. A malformed persisted table fails open (no general rules are applied).</p> <p>Within one receive evaluation, rows that use the same channel key share one authentication result. The cache is discarded after that packet and stores neither plaintext nor passwords; different keys are authenticated separately. Raw <code>hash:XX</code> rows skip this authentication and compare only the one visible byte.</p> <p>Per-channel retry examples:</p> <pre><code># Use bridge-bucket retry only for authenticated Public and #hamradio traffic.\nset flood.retry.bridge on\nset flood.rule.2 type=any channel=public retry\nset flood.rule.3 type=any channel=#hamradio retry\n\n# If the channel key/name is unavailable, select visible channel hash A7.\n# This is an unauthenticated 1-byte hint, not a channel identity.\nset flood.rule.4 type=any channel=hash:A7 retry\n</code></pre> <p>Because Public's visible hash is <code>0x11</code>, a bare <code>hash:11 drop</code> row also matches Public. To exempt authenticated Public while dropping other packets that carry the same visible byte, put the exact Public rule first and stop lower-priority rules after it:</p> <pre><code># Retry and preserve authenticated Public; drop other channel-hash 11 packets.\nset flood.rule.2 type=any channel=public retry stop\nset flood.rule.3 type=any channel=hash:11 drop\n</code></pre> <p>The Public row matches only after its MAC/decrypt check succeeds. A colliding channel therefore misses that <code>stop</code> and reaches the raw-hash drop row. Both rows use the default numeric priority, but authenticated-channel specificity automatically orders Public first even if its slot number is higher. Without <code>stop</code>, both rows match Public and the sticky <code>drop</code> action wins. Omit <code>retry</code> from the Public row when only the forwarding exemption is wanted. An operator can deliberately reverse this order by assigning the hash row a higher numeric <code>priority</code>.</p> <p>Deleting or replacing the last active <code>retry</code> row restores the legacy global retry eligibility. Firmware that predates the <code>retry</code>/<code>hash:XX</code> FPF7 extension cannot preserve tables containing those rows; remove them before downgrading.</p> <p>Default row: Repeater firmware and FULL ESP32 room-server firmware seed a new flood-filter table with <code>ota all suspend=tempradio</code> in slot 1. This blocks repeated LoRa OTA (<code>0x0C</code>) floods at every received hop unless temporary radio is actually active. The OTA core independently refuses OTA receive, relay, and transmit outside temporary radio. The row is editable and deletable; once the table is saved, deletion is persistent. Restore the exact seeded row with:</p> <pre><code>set flood.filter.1 0x0C all suspend=tempradio\n</code></pre> <p>Omitting <code>all</code> is equivalent. Omit <code>.1</code> as well to reuse an identical rule or the first empty slot instead of replacing slot 1.</p> <p>Remote-admin lockout warning: There are no hidden payload-type or short-hop exceptions. FPF7 drop and rate rows may block <code>req</code>, <code>response</code>, <code>txt_msg</code>, <code>anon_req</code>, <code>path</code>, ACK, and multipart traffic beginning at hop <code>0</code> when their match fields say so. Transit repeaters cannot decrypt these outer types to distinguish an admin exchange from ordinary peer traffic. Keep a serial or other recovery path and stage broad deny/rate rules carefully.</p> <p>Without <code>.n</code>, <code>set</code> reuses an identical rule or uses the first empty slot. With <code>.n</code>, it replaces that slot, which is the intended way to change a row's match or action. <code>get flood.filter</code> or <code>get flood.rule</code> gives a compact list. Use the numbered form for full details, including channel, prefix, original-scope condition, action, timing, rate, and temporary-radio suspension.</p> <p>If all of those fields plus long names would exceed one CLI reply, the numbered form automatically switches to a non-truncating compact spelling. The compact aliases are also accepted by <code>set</code>: <code>c=</code> means <code>channel=</code>, <code>p=</code> means <code>prefix=</code>, <code>i=*|n|s|a|u|s:&lt;scope&gt;|r:&lt;region&gt;</code> means the corresponding <code>in=</code> condition, <code>q=N</code> means <code>rate=N/min</code>, <code>pri=N</code> means priority, and <code>f=str</code> combines slow timing (<code>s</code>), temporary-radio suspension (<code>t</code>), and retry allowance (<code>r</code>). Packet type is shown numerically in that fallback. Normal-sized rows keep the descriptive spelling above.</p> <p>On generalized repeaters, filter rows, scope-rewrite rows, the shared blacklist, and <code>flood.channel.data</code> compatibility state are committed in one atomic FPF7 image. Compact FPF6 profiles retain separate files. Replacing or deleting the blacklist does not delete rows containing <code>path=blacklist</code>; such rows remain dormant while the list is empty. Path hashes are truncated routing identifiers, not authenticated identities, so this is a forwarding signal rather than proof that a particular repeater handled a packet.</p> <p>A common use is containment of bulk internet-to-mesh dumping: list the path IDs associated with the offending gateways, then add a broad <code>type=any hops=all path=blacklist drop</code> row. This prevents this repeater from retransmitting matching floods; it does not delete them from local logs or prove who originated them.</p> <p>The unnumbered blacklist <code>set</code> replaces the whole list and accepts up to 18 IDs so it fits every CLI transport. Numbered <code>set</code> writes up to 18 consecutive entries beginning at an existing slot or exactly the next slot, allowing an ESP32 list to grow to 255 entries in batches. Numbered deletion compacts subsequent slots. The unnumbered <code>get</code> reports the total and as many leading IDs as fit in one reply; use numbered <code>get</code> to inspect entries beyond that reply.</p> <p>Standard traceroute is direct-routed and therefore outside <code>flood.filter</code> entirely. A custom flood-form trace participates normally: <code>type=any</code>, explicit <code>trace</code>, rewrite, rate, drop, and stop rows can all apply.</p> <p>Examples:</p> <pre><code>set flood.rule.2 type=grp_data hops=4+ channel=#rgdata in=none scope=BlackHole86\nset flood.rule.3 type=grp_data channel=#rgdata in=scope:usa scope=BlackHole86\nset flood.rule.4 type=any prefix=860C rate=10/min\nset flood.rule.5 type=grp_data hops=0-2 channel=#rgdata priority=200 stop\nget flood.rule.2\nset flood.filter grp_data 4+\nset flood.filter.2 PAYLOAD_TYPE_ADVERT 6+\nset flood.filter ota 2-4\nset flood.filter.1 0x0C all suspend=tempradio\nset flood.filter grp_data all suspend=tempradio\nset flood.filter grp_txt all scope=local\nset flood.filter grp_data all scope=local require=region\nset flood.filter grp_data all path=blacklist scope=local tx=slow\nset flood.filter.blacklist A1B2C3,D4E5F6,112233\nset flood.filter.blacklist.4 445566\nset flood.filter.blacklist.19 778899,AABBCC,DDEEFF\nset flood.filter any all path=blacklist\nget flood.filter.blacklist\nget flood.filter.blacklist.4\nset flood.filter any 12+\nget flood.filter\nget flood.filter.2\ndel flood.filter.2\n</code></pre> <p>The first rule authenticates <code>#rgdata</code>, requires more than three received hops, and adds <code>#BlackHole86</code> only when no scope was present. The second rewrites the exact incoming <code>#usa</code> scope. The third demonstrates a two-byte pbyte source prefix and a global per-row rate cap. The fourth authenticates <code>#rgdata</code> at zero through two hops, applies no FPF7 action of its own, and stops lower-order FPF7 forward rows; hard gates and the rewrite/moderation phases still apply.</p> <p>The fixed 240 KB STM32WL profiles leave <code>MESH_ENABLE_FLOOD_RULE_ENGINE=0</code> and retain the compact, persistent FPF6 <code>flood.filter</code> and blacklist commands. They still filter floods, but do not expose the <code>flood.rule</code> alias or its extended channel, prefix, input-scope, region-action, or rate fields. No partition size changes are required.</p>"},{"location":"cli_commands/#moderate-flood-group-text-by-channel-sender-and-source-path","title":"Moderate flood group text by channel, sender, and source path","text":"<p>Usage: - <code>get flood.moderation</code> - <code>get flood.moderation.&lt;n&gt;</code> - <code>set flood.moderation &lt;channel&gt; &lt;sender&gt; &lt;action&gt; [action...]</code> - <code>set flood.moderation.&lt;n&gt; &lt;channel&gt; &lt;sender&gt; &lt;action&gt; [action...]</code> - <code>del flood.moderation.&lt;n&gt;</code> - <code>del flood.moderation all</code></p> <p>Parameters: - <code>n</code>: Moderation slot from <code>1</code> to <code>16</code>. - <code>channel</code>:   - <code>public</code>: Built-in Public channel.   - <code>#channel</code>: Derive the well-known hashtag-channel key.   - A 128-bit or 256-bit channel key in hex, for any other/private channel. - <code>sender</code>: Exact group-text display name. Matching is ASCII case-insensitive.   Quote names containing spaces, for example <code>\"Field User\"</code>. - <code>drop</code>: Do not forward matching messages. Equivalent to <code>rate=0/min</code>. - <code>rate=X/min</code>: Forward at most <code>X</code> matching messages per 60-second local   window. This option requires an exact sender rather than <code>*</code>. - <code>hops=N</code>: Do not forward a matching message whose received flood path count   is <code>N</code> or higher. <code>hops=all</code> removes this constraint. - <code>path=H1[,H2,H3]</code>: Match the start of the flood path. One to three hashes are   accepted; every hash must have the same 1-, 2-, or 3-byte width. - <code>path=*</code>: Match any source path (the default).</p> <p>At least one of <code>drop</code>, <code>rate=X/min</code>, or <code>hops=N</code> is required. Rate and hop limits can be combined. Rate counters are local to this repeater and rule, use a 60-second window beginning with the first matching message, and reset on reboot.</p> <p>Decode and identity behavior: Moderation applies only to flood <code>PAYLOAD_TYPE_GRP_TXT</code>. The repeater first checks the packet's channel-hash byte, then validates and decrypts with the configured key. It extracts the text before the first <code>:</code> from the standard <code>&lt;sender&gt;: &lt;message&gt;</code> plaintext. The channel key is stored locally but is never printed by <code>get</code>.</p> <p>The group-text sender is an unverified display name, not a public key. It can be spoofed. Combining it with the first one to three path hashes makes a more useful moderation signal, but path hashes are truncated and are not proof of the originating user. A path-qualified rule begins matching only after the packet contains all configured starting hops; it cannot identify a first hop on a zero-hop packet.</p> <p>As with general filtering, matching messages are still received/logged; only retransmission is denied. There are no moderation rules by default.</p> <p>Examples:</p> <pre><code>set flood.moderation public \"Noisy User\" rate=5/min\nset flood.moderation #local bot drop path=A1B2C3,D4E5F6\nset flood.moderation.3 00112233445566778899AABBCCDDEEFF alice rate=10/min hops=4 path=71CE82\nget flood.moderation\nget flood.moderation.3\ndel flood.moderation.3\n</code></pre>"},{"location":"cli_commands/#acl","title":"ACL","text":""},{"location":"cli_commands/#add-update-or-remove-permissions-for-a-companion","title":"Add, update or remove permissions for a companion","text":"<p>Usage:  - <code>setperm &lt;pubkey&gt; &lt;permissions&gt;</code></p> <p>Parameters: - <code>pubkey</code>: Companion public key - <code>permissions</code>:    - <code>0</code>: Guest   - <code>1</code>: Read-only   - <code>2</code>: Read-write   - <code>3</code>: Admin   - <code>4</code>: Region/scope manager (repeater delegated region and forced-scope management)   - <code>5</code>: Filter manager (repeater delegated forwarding-filter management)</p> <p>Filter manager scope: Permission <code>5</code> can use an explicit allowlist of non-secret operational/filter status commands and can change the forwarding controls <code>repeat</code>, <code>loop.detect</code>, <code>flood.max*</code>, <code>flood.channel.data*</code>, <code>flood.filter*</code>, <code>flood.rule*</code>, and <code>flood.moderation*</code>. It cannot read guest, WiFi, MQTT, bridge, or other credentials, and it cannot change regions, ACL entries, radio settings, or other admin configuration. Permission <code>4</code> is limited to region commands, <code>flood.channel.scope*</code>, and the same non-secret status allowlist. Both delegated manager roles are protected from least-recently-active ACL eviction like administrators.</p> <p>Note: Removes the entry when <code>permissions</code> is omitted</p>"},{"location":"cli_commands/#view-the-current-acl","title":"View the current ACL","text":"<p>Usage:  - <code>get acl</code></p> <p>Serial Only: Yes</p>"},{"location":"cli_commands/#recover-a-repeaters-future-dated-replay-timestamp","title":"Recover a repeater's future-dated replay timestamp","text":"<p>This is an explicit recovery operation after correcting a bad clock, not a contact deletion. It lowers selected replay timestamps to the repeater's current UTC epoch only when they are later than that epoch. Earlier values, public keys, permissions, stored paths, and historical identity records remain. The replay file is committed before the live table changes. No extra 60-second login reservation is added by this command.</p> <p>First set/synchronize and verify the repeater's clock (<code>clock</code>); a build-default clock without a manual or observed synchronization is not accepted. Also fix the companion's clock before its next login.</p> <p>USB console:</p> <pre><code>replay reset &lt;full-64-hex-public-key&gt;\nreplay reset all CONFIRM\n</code></pre> <p>Authenticated LoRa admin, including a resumed admin session:</p> <pre><code>replay reset &lt;full-64-hex-public-key&gt;\n</code></pre> <p>The reply shows <code>now=&lt;epoch&gt;</code>, <code>ttl=&lt;remaining-seconds&gt;s</code>, and a confirmation command containing the same full key and a one-use 32-hex-character token. Verify the displayed time and send that command before the original 300-second deadline. During the first 120 seconds, repeated requests for the same key by the same admin return the same token without restarting either timer. From 120 through 300 seconds, the token is retained for confirmation only: requests do not resend or replace it. This leaves at least 180 seconds to deliver a confirmation after the last permitted token response is generated (radio transit time still counts toward expiry). At 300 seconds it expires and a new request can receive a new token. Confirmation can succeed immediately; there is no requirement to wait for the resend window to close. The displayed TTL decreases on retries and is measured when the reply is generated, not when it reaches the companion.</p> <p>It can target the caller's own key or another exact key; prefixes, <code>self</code>, wildcards, and <code>all</code> are not allowed over LoRa. Tokens are bound to both the requesting admin and target, expire on reboot, and are invalid after use or a clock correction outside the five-second confirmation tolerance. A failed write requires a new confirmation. Challenge requests consult live token state instead of replaying cached challenge text; completed confirmation results remain cacheable without executing the reset again. Normal packet freshness checks still apply to retries.</p> <p>Only the physical serial console grants <code>all</code> access. Ethernet, browser and internal command callbacks do not count as USB. Guest, read-only, region-manager and filter-manager roles cannot reset replay state. This command is implemented in repeater firmware; room-server and sensor CLI are unchanged.</p> <p>Normal login and command admission checks remain in force: a fully locked-out caller that cannot send an accepted admin command needs another working admin or USB access. A corrupt/unreadable replay file fails closed and is not erased or formatted by this operation. Unknown keys do not create records.</p> <p>Security trade-off: lowering a replay boundary can admit previously captured future-dated login/command packets above the new boundary, including packets that could raise it again. The one-use token prevents the recovery command itself from being repeatedly executed; it does not replace the protocol's timestamp-based replay protection. Use recovery only after verifying clocks. Setting a clock alone never automatically resets this table.</p>"},{"location":"cli_commands/#view-or-change-this-room-servers-read-only-flag","title":"View or change this room server's 'read-only' flag","text":"<p>Usage: - <code>get allow.read.only</code> - <code>set allow.read.only &lt;state&gt;</code></p> <p>Parameters: - <code>state</code>: <code>on</code> (enable) or <code>off</code> (disable)</p> <p>Default: <code>off</code></p>"},{"location":"cli_commands/#region-management-v110","title":"Region Management (v1.10.+)","text":""},{"location":"cli_commands/#bulk-load-region-lists","title":"Bulk-load region lists","text":"<p>Usage:  - <code>region load</code> - <code>region load &lt;name&gt; [flood_flag]</code></p> <p>Parameters: - <code>name</code>: A name of a region. <code>*</code> represents the wildcard region</p> <p>Note: <code>flood_flag</code>: Optional <code>F</code> to allow flooding</p> <p>Note: Indentation creates parent-child relationships (max 8 levels)</p> <p>Note: <code>region load</code> with an empty name will not work remotely (it's interactive)</p>"},{"location":"cli_commands/#save-any-changes-to-regions-made-since-reboot","title":"Save any changes to regions made since reboot","text":"<p>Usage:  - <code>region save</code></p>"},{"location":"cli_commands/#allow-a-region","title":"Allow a region","text":"<p>Usage:  - <code>region allowf &lt;name&gt;</code></p> <p>Parameters:  - <code>name</code>: Region name (or <code>*</code> for wildcard)</p> <p>Note: Setting on wildcard <code>*</code> allows packets without region transport codes</p>"},{"location":"cli_commands/#block-a-region","title":"Block a region","text":"<p>Usage:  - <code>region denyf &lt;name&gt;</code></p> <p>Parameters:  - <code>name</code>: Region name (or <code>*</code> for wildcard)</p> <p>Note: Setting on wildcard <code>*</code> drops packets without region transport codes</p>"},{"location":"cli_commands/#show-information-for-a-region","title":"Show information for a region","text":"<p>Usage:  - <code>region get &lt;name&gt;</code></p> <p>Parameters: - <code>name</code>: Region name (or <code>*</code> for wildcard)</p>"},{"location":"cli_commands/#view-or-change-the-home-region-for-this-node","title":"View or change the home region for this node","text":"<p>Usage:  - <code>region home</code> - <code>region home &lt;name&gt;</code></p> <p>Parameters: - <code>name</code>: Region name</p>"},{"location":"cli_commands/#view-or-change-the-default-scope-region-for-this-node","title":"View or change the default scope region for this node","text":"<p>Usage:  - <code>region default</code> - <code>region default {name|&lt;null&gt;}</code></p> <p>Parameters: - <code>name</code>: Region name,  or  to reset/clear"},{"location":"cli_commands/#create-a-new-region","title":"Create a new region","text":"<p>Usage:  - <code>region put &lt;name&gt; [parent_name]</code></p> <p>Parameters: - <code>name</code>: Region name - <code>parent_name</code>: Parent region name (optional, defaults to wildcard)</p> <p>Note: In firmware v1.15.0 and later, <code>region put</code> enables flooding for that region by default (you do not need a separate <code>region allowf &lt;name&gt;</code> after each <code>put</code>). On v1.14.0 and earlier, new regions may still require <code>region allowf</code> for flooding-see <code>region allowf</code>.</p>"},{"location":"cli_commands/#define-region-hierarchy-single-line","title":"Define region hierarchy (single line)","text":"<p>Usage: - <code>region def &lt;token&gt; [&lt;token&gt; ...]</code></p> <p>Parameters (tokens): Space-separated. A logical cursor starts at the wildcard <code>*</code>.</p> <ul> <li><code>name</code> - Create <code>name</code> as a child of the current cursor (equivalent to <code>region put name</code> with the cursor as parent). Cursor moves to <code>name</code>.</li> <li><code>name|jump</code> (or <code>name,jump</code>) - Create <code>name</code> as a child of the current cursor, then move the cursor to <code>jump</code> (must already exist on the node, or have been created earlier in this command). <code>jump</code> is not the parent of <code>name</code>; use this form to pop back up and start another branch.</li> </ul> <p>Behavior: Each created region defaults to flood-allowed (same as <code>region put</code>). The reply is the resulting region tree (same format as bare <code>region</code>); review it before running <code>region save</code> to persist. The command is transactional: invalid names, unknown or ambiguous jumps, table overflow, and hierarchy cycles return <code>Err - ...</code> without changing the existing tree.</p> <p>Existing regions: <code>region def</code> does not clear the existing tree - if a name already exists, its parent is updated to the current cursor; otherwise a new region is created. To start from scratch, <code>region remove</code> the unwanted regions first.</p> <p>Limits: Repeater serial accepts one line up to 160 characters. For larger trees, split across multiple <code>region def</code> commands; the cursor resets to <code>*</code> between commands, so lead the next command with <code>child|ancestor</code> to reposition. Each token splits at most once on <code>|</code> - <code>region def a|b|c|d</code> is not a flat-list shorthand; see the flat-list example below.</p> <p>Example - linear chain (each token becomes a child of the previous):</p> <pre><code>region def a b c d e\nregion save\n</code></pre> <p>Example - branched tree (equivalent to <code>region put a</code>, <code>region put b a</code>, <code>region put c b</code>, <code>region put d c</code>, <code>region put e b</code>, <code>region put f e</code>):</p> <pre><code>region def a b c d|b e f\nregion save\n</code></pre> <p>Example - transactional error:</p> <pre><code>region def a b c|nope d\n</code></pre> <p>The reply is <code>Err - unknown or ambiguous jump: nope</code>. The existing tree is unchanged; re-run with a corrected jump.</p> <p>Example - flat list (each region a child of <code>*</code>). Use <code>|*</code> after each token to pop the cursor back to the root before the next token:</p> <pre><code>region def a|* b|* c|* d|* e|* f\nregion save\n</code></pre>"},{"location":"cli_commands/#remove-a-region","title":"Remove a region","text":"<p>Usage:  - <code>region remove &lt;name&gt;</code></p> <p>Parameters: - <code>name</code>: Region name</p> <p>Note: Must remove all child regions before the region can be removed </p>"},{"location":"cli_commands/#view-all-regions","title":"View all regions","text":"<p>Usage:  - <code>region list &lt;filter&gt;</code></p> <p>Serial Only: Yes</p> <p>Parameters: - <code>filter</code>: <code>allowed</code>|<code>denied</code></p> <p>Note: Requires firmware 1.12+</p>"},{"location":"cli_commands/#dump-all-defined-regions-and-flood-permissions","title":"Dump all defined regions and flood permissions","text":"<p>Usage:  - <code>region</code></p> <p>Serial Only: For firmware older than 1.12.0</p>"},{"location":"cli_commands/#region-examples","title":"Region Examples","text":"<p>Example 1: Using F Flag with Named Public Region</p> <pre><code>region load\n#Europe F\n&lt;blank line to end region load&gt;\nregion save\n</code></pre> <p>Explanation: - Creates a region named <code>#Europe</code> with flooding enabled - Packets from this region will be flooded to other nodes</p> <p>Example 2: Using Wildcard with F Flag</p> <pre><code>region load \n* F\n&lt;blank line to end region load&gt;\nregion save\n</code></pre> <p>Explanation: - Creates a wildcard region <code>*</code> with flooding enabled - Enables flooding for all regions automatically - Applies only to packets without transport codes</p> <p>Example 3: Using Wildcard Without F Flag</p> <pre><code>region load \n*\n&lt;blank line to end region load&gt;\nregion save\n</code></pre> <p>Explanation: - Creates a wildcard region <code>*</code> without flooding - This region exists but doesn't affect packet distribution - Used as a default/empty region</p> <p>Example 4: Nested Public Region with F Flag</p> <pre><code>region load \n#Europe F\n  #UK\n    #London\n    #Manchester\n  #France\n    #Paris\n    #Lyon\n&lt;blank line to end region load&gt;\nregion save\n</code></pre> <p>Explanation: - Creates <code>#Europe</code> region with flooding enabled - Adds nested child regions (<code>#UK</code>, <code>#France</code>) - All nested regions inherit the flooding flag from parent</p> <p>Example 5: Wildcard with Nested Public Regions</p> <pre><code>region load \n* F\n  #NorthAmerica\n    #USA\n      #NewYork\n      #California\n    #Canada\n      #Ontario\n      #Quebec\n&lt;blank line to end region load&gt;\nregion save\n</code></pre> <p>Explanation: - Creates wildcard region <code>*</code> with flooding enabled - Adds nested <code>#NorthAmerica</code> hierarchy - Enables flooding for all child regions automatically - Useful for global networks with specific regional rules</p>"},{"location":"cli_commands/#direct-retry","title":"Direct Retry","text":"<p>Direct retry resends direct-routed packets when the downstream echo is not heard. It applies to direct messages, ACK packets, multipart packets carrying ACK payloads, and TRACE packets.</p> <p>The shared state, count, base, and step controls work on repeater, room-server, and sensor firmware. Recent-repeater/SNR controls are repeater-only because the other roles do not keep the repeater reachability table they require.</p>"},{"location":"cli_commands/#view-or-change-direct-retry-state","title":"View or change direct retry state","text":"<p>Usage: - <code>get direct.retry</code> - <code>set direct.retry &lt;state&gt;</code></p> <p>Parameters: - <code>state</code>: <code>on</code>|<code>off</code></p> <p>Default: <code>on</code></p> <p>Notes: - New installs and older preference files without direct retry settings default to <code>on</code> with the <code>rooftop</code> preset.</p> <p>Examples:</p> <pre><code>get direct.retry\nset direct.retry on\nset direct.retry off\n</code></pre>"},{"location":"cli_commands/#view-or-change-direct-retry-heard-table-gate","title":"View or change direct retry heard-table gate","text":"<p>Usage: - <code>get direct.retry.heard</code> - <code>set direct.retry.heard &lt;state&gt;</code></p> <p>Parameters: - <code>state</code>: <code>on</code>|<code>off</code></p> <p>Default: <code>on</code></p> <p>Note: This command is repeater-only. When enabled, the recent repeater table is the direct retry eligibility gate. Prefixes missing from the table are assumed reachable; prefixes in the table below the active SNR gate are blocked.</p> <p>Examples:</p> <pre><code>get direct.retry.heard\nset direct.retry.heard on\nset direct.retry.heard off\n</code></pre>"},{"location":"cli_commands/#view-or-apply-a-retry-preset","title":"View or apply a retry preset","text":"<p>Usage: - <code>get retry.preset</code> - <code>set retry.preset &lt;preset&gt;</code></p> <p>Parameters: - <code>preset</code>: <code>infra</code>|<code>rooftop</code>|<code>mobile</code></p> <p>Notes: - Applies shared direct retry and flood retry defaults. - <code>infra</code>: fewer, slower retries for stable fixed infrastructure. - <code>rooftop</code>: default long retry window for weak rooftop links. - <code>mobile</code>: long retry count with shorter spacing for moving or changing links; flood retry count is <code>15</code>. - Changing <code>direct.retry.count</code>, <code>direct.retry.base</code>, <code>direct.retry.step</code>, <code>direct.retry.margin</code>, <code>flood.retry.count</code>, <code>flood.retry.path</code>, or <code>flood.retry.group.path</code> makes the preset report as <code>custom</code>.</p> <p>Examples:</p> <pre><code>get retry.preset\nset retry.preset infra\nset retry.preset rooftop\nset retry.preset mobile\n</code></pre>"},{"location":"cli_commands/#flood-retry","title":"Flood Retry","text":"<p>Flood retry resends flood-routed packets when the same packet is not heard from another qualifying repeater.</p> <p>The count, path, group-data path, and advert controls work on repeater, room-server, and sensor firmware. Flood forwarding must also be enabled for retries to run. Prefix, ignore, bridge, and bucket controls are repeater-only.</p>"},{"location":"cli_commands/#view-or-change-flood-retry-count","title":"View or change flood retry count","text":"<p>Usage: - <code>get flood.retry.count</code> - <code>set flood.retry.count &lt;count&gt;</code></p> <p>Parameters: - <code>count</code>: Base retry attempts after the original send, from <code>0</code> to <code>15</code>. <code>0</code> disables flood retry.</p> <p>Note: The role first calculates its retry count: path count 0 uses <code>count * 2</code>, path count 1 uses <code>count * 1.5</code> rounded up, and path count 2 and higher uses the configured base count, with a hard cap of <code>15</code>. A shared payload policy then applies to every build: <code>REQ</code> never retries; <code>GRP_TXT</code> keeps the role-calculated count; remote-login-critical <code>RESPONSE</code>, <code>TXT_MSG</code>, <code>ANON_REQ</code>, and <code>PATH</code> packets keep up to <code>15</code> at the originating node (path count 0) and cap at <code>2</code> after entering the path; all other flood payload types cap at <code>1</code>. These caps never raise a lower role-calculated count. Setting <code>count</code> to <code>0</code> immediately removes queued and future flood retries; a packet already transmitting is allowed to finish.</p> <p>Forwarded neighbor adverts have an additional loop guard independent of the advert retry setting. After this node completes an advert transmission and hears a downstream copy with a longer path, it does not forward that same advert again while the advert's signed timestamp is less than six hours old. Self-originated adverts, adverts without a heard echo, and adverts six hours old or older are unaffected.</p> <p>An enabled self-originated advert retry waits at least one additional minute beyond the normal airtime-aware retry delay. Once a newer self advert has successfully entered the outbound queue, its retry sequence replaces queued or future retries for older self adverts; an older advert already transmitting is allowed to finish. Companion firmware permits this single slow retry for its own adverts while continuing to block retry attempts for neighbor adverts it forwards.</p> <p>Defaults: - <code>infra</code>: <code>1</code> - <code>rooftop</code>: <code>3</code> - <code>mobile</code>: <code>15</code></p> <p>Examples:</p> <pre><code>get flood.retry.count\nset flood.retry.count 0\nset flood.retry.count 15\n</code></pre>"},{"location":"cli_commands/#view-or-change-flood-retry-path-gate","title":"View or change flood retry path gate","text":"<p>Usage: - <code>get flood.retry.path</code> - <code>set flood.retry.path &lt;count|off&gt;</code></p> <p>Parameters: - <code>count</code>: Maximum flood path hash count eligible for retry, from <code>0</code> to <code>63</code>. - <code>off</code>: Disable the path-length gate.</p> <p>Defaults: - <code>infra</code>: <code>1</code> - <code>rooftop</code>: <code>2</code> - <code>mobile</code>: <code>1</code></p> <p>Examples:</p> <pre><code>get flood.retry.path\nset flood.retry.path 1\nset flood.retry.path off\n</code></pre>"},{"location":"cli_commands/#view-or-change-the-group-data-flood-retry-path-gate","title":"View or change the group-data flood retry path gate","text":"<p>Usage: - <code>get flood.retry.group.path</code> - <code>set flood.retry.group.path &lt;count|off&gt;</code></p> <p>Parameters: - <code>count</code>: Maximum flood path hash count eligible for retry for group data packets (<code>PAYLOAD_TYPE_GRP_DATA</code>/type 6), from <code>0</code> to <code>63</code>. - <code>off</code>: Disable only the group-data-specific gate. The general <code>flood.retry.path</code> gate still applies.</p> <p>Default: <code>1</code> for <code>infra</code>, <code>rooftop</code>, and <code>mobile</code> presets.</p> <p>Note: The stricter of <code>flood.retry.path</code> and <code>flood.retry.group.path</code> is used. A value of <code>1</code> allows retry sequences at path counts <code>0</code> and <code>1</code>; group data at path count <code>2</code> or higher is still forwarded normally but does not start a flood retry sequence. A value of <code>0</code> allows retries only at the originating sender.</p> <p>Setting <code>flood.retry.path</code> to <code>0</code> also sets <code>flood.retry.group.path</code> to <code>off</code> because the general zero-hop gate is already stricter. While the general gate remains <code>0</code>, attempts to set the group-data gate keep it <code>off</code>. Applying a named retry preset restores the group-data default of <code>1</code>.</p> <p>Examples:</p> <pre><code>get flood.retry.group.path\nset flood.retry.group.path 1\nset flood.retry.group.path off\n</code></pre>"},{"location":"cli_commands/#view-or-change-flood-retry-advert-handling","title":"View or change flood retry advert handling","text":"<p>Usage: - <code>get flood.retry.advert</code> - <code>set flood.retry.advert &lt;on|off&gt;</code></p> <p>Parameters: - <code>on</code>: Retry node advert floods. - <code>off</code>: Do not retry node advert floods.</p> <p>Default: <code>off</code></p> <p>Examples:</p> <pre><code>get flood.retry.advert\nset flood.retry.advert off\n</code></pre>"},{"location":"cli_commands/#view-or-change-flood-retry-target-prefixes","title":"View or change flood retry target prefixes","text":"<p>Usage: - <code>get flood.retry.prefixes</code> - <code>set flood.retry.prefixes &lt;prefixes|none|off&gt;</code></p> <p>Parameters: - <code>prefixes</code>: Comma-separated 3-byte path hash prefixes, up to 8 entries. - <code>none</code> or <code>off</code>: Clear the list.</p> <p>Note: When set, non-bridge flood retry only accepts same-packet echoes whose last hop matches one of these prefixes. When unset, any non-ignored last hop can cancel the retry.</p> <p>Examples:</p> <pre><code>get flood.retry.prefixes\nset flood.retry.prefixes A58296,860CCA,425E5C\nset flood.retry.prefixes none\n</code></pre>"},{"location":"cli_commands/#view-or-change-flood-retry-ignored-prefixes","title":"View or change flood retry ignored prefixes","text":"<p>Usage: - <code>get flood.retry.ignore</code> - <code>set flood.retry.ignore &lt;prefixes|none|off&gt;</code></p> <p>Parameters: - <code>prefixes</code>: Comma-separated 3-byte path hash prefixes, up to 8 entries. - <code>none</code> or <code>off</code>: Clear the list.</p> <p>Note: Non-bridge flood retry does not cancel on same-packet echoes whose last hop matches this list. Bridge mode also excludes these prefixes from bucket and <code>other</code> hits.</p> <p>Examples:</p> <pre><code>get flood.retry.ignore\nset flood.retry.ignore 71CE82,C7618C\nset flood.retry.ignore none\n</code></pre>"},{"location":"cli_commands/#view-or-change-flood-retry-bridge-mode","title":"View or change flood retry bridge mode","text":"<p>Usage: - <code>get flood.retry.bridge</code> - <code>set flood.retry.bridge &lt;on|off&gt;</code></p> <p>Note: Bridge mode retries until each configured fresh bucket, plus the non-source <code>other</code> bucket, has been heard or the retry count is exhausted. If prefixes in different buckets share their first byte, configuration commands return a warning because a 1-byte path cannot distinguish those buckets. The configuration remains valid: an ambiguous source is treated as belonging to every matching source bucket, and an ambiguous echo credits every matching target bucket so it cannot force retry exhaustion.</p> <p>Flood retry timing retains its fixed maximum-frame plus 20 packet-airtime wait, then adds a random <code>0-200%</code> of one additional packet airtime on every attempt. This de-synchronizes repeaters that may have missed the same echo while capping the added wait at two frames.</p> <p>Only one active retry sequence is kept for a given logical flood packet. An identical flood can still transmit normally, but it does not create a second sequence of extra attempts. Retry state is released if a queued packet is evicted, and the final echo window retains metadata without reserving a packet-pool entry.</p> <p>Bridge reachability learned from earlier hops in a successful echo is cached separately from <code>recent.repeater</code>. Only the final RF hop updates <code>recent.repeater</code> and its SNR, so indirect path entries cannot affect direct-retry SNR gating or coding-rate selection.</p> <p>Examples:</p> <pre><code>get flood.retry.bridge\nset flood.retry.bridge on\n</code></pre>"},{"location":"cli_commands/#view-or-change-flood-retry-bridge-buckets","title":"View or change flood retry bridge buckets","text":"<p>Usage: - <code>get flood.retry.bucket.&lt;n&gt;</code> - <code>set flood.retry.bucket &lt;n&gt; &lt;prefixes|none|off&gt;</code></p> <p>Parameters: - <code>n</code>: Bucket number from <code>1</code> to <code>6</code>. - <code>prefixes</code>: Comma-separated 3-byte path hash prefixes, up to 17 entries per bucket. - <code>none</code> or <code>off</code>: Clear the bucket.</p> <p>Examples:</p> <pre><code>get flood.retry.bucket.1\nset flood.retry.bucket 1 71CE82,C7618C\nset flood.retry.bucket 2 none\n</code></pre>"},{"location":"cli_commands/#view-or-change-direct-retry-count","title":"View or change direct retry count","text":"<p>Usage: - <code>get direct.retry.count</code> - <code>set direct.retry.count &lt;count&gt;</code></p> <p>Parameters: - <code>count</code>: Maximum retry attempts after the original send, from <code>1</code> to <code>15</code>.</p> <p>Default: <code>15</code> with the <code>rooftop</code> preset</p> <p>Note: Direct-routed type 2 text packets always use 21 retry attempts in the shared retry logic, regardless of this setting or the repeater short-path cap.</p> <p>Examples:</p> <pre><code>get direct.retry.count\nset direct.retry.count 1\nset direct.retry.count 4\nset direct.retry.count 15\n</code></pre>"},{"location":"cli_commands/#view-or-change-direct-retry-base-delay","title":"View or change direct retry base delay","text":"<p>Usage: - <code>get direct.retry.base</code> - <code>set direct.retry.base &lt;ms&gt;</code></p> <p>Parameters: - <code>ms</code>: First retry wait in milliseconds, from <code>10</code> to <code>5000</code>.</p> <p>Default: <code>175</code> with the <code>rooftop</code> preset</p> <p>Explanation: - The first retry waits for <code>base + packet-length add-on + random forwarding jitter</code>   after the preceding transmission completes. - TRACE and   ANON_REQ/type 7 packets use a 3x line-time add-on. TXT_MSG/type 2   packets use 7x. Other direct retry packets use 6x. - Room-server and sensor firmware use this configured base with the same   packet-type add-ons. - Larger values reduce channel pressure and give slow repeaters more time. - Smaller values recover faster but create tighter retry bursts.</p> <p>Examples:</p> <pre><code>get direct.retry.base\nset direct.retry.base 175\nset direct.retry.base 275\nset direct.retry.base 500\n</code></pre>"},{"location":"cli_commands/#view-or-change-direct-retry-step-delay","title":"View or change direct retry step delay","text":"<p>Usage: - <code>get direct.retry.step</code> - <code>set direct.retry.step &lt;ms&gt;</code></p> <p>Parameters: - <code>ms</code>: Extra milliseconds added for each subsequent retry, from <code>0</code> to <code>5000</code>.</p> <p>Default: <code>100</code> with the <code>rooftop</code> preset</p> <p>Explanation: - Retry delay is <code>base + packet-length add-on + random forwarding jitter + attempt_index * step</code>. - TRACE and ANON_REQ/type 7 packets   use a 3x packet-length add-on. TXT_MSG/type 2 packets use 7x.   Other direct retry packets use 6x. - Room-server and sensor firmware use this configured step with the same   packet-type add-ons. - With <code>base=175</code> and <code>step=100</code>, the fixed portion is <code>175</code>, <code>275</code>, <code>375</code>,   <code>475</code> ms, and so on, before the packet-length add-on and random jitter. - <code>step=0</code> keeps every retry at the same delay. - Larger steps spread retries over time and are safer on busy channels.</p> <p>Examples:</p> <pre><code>get direct.retry.step\nset direct.retry.step 0\nset direct.retry.step 50\nset direct.retry.step 100\nset direct.retry.step 250\n</code></pre>"},{"location":"cli_commands/#view-or-change-direct-retry-snr-margin","title":"View or change direct retry SNR margin","text":"<p>Usage: - <code>get direct.retry.margin</code> - <code>set direct.retry.margin &lt;snr_db&gt;</code></p> <p>Parameters: - <code>snr_db</code>: Extra SNR margin above the SF receive floor, from <code>0</code> to <code>40</code>.</p> <p>Default: <code>5.00</code> with the <code>rooftop</code> preset</p> <p>Notes: - This command is repeater-only. - Unknown repeaters are still retried. - Known repeaters below the receive floor plus this margin are skipped. - Failed attempts lower the recent repeater SNR estimate by <code>0.25 dB</code>.</p> <p>Examples:</p> <pre><code>get direct.retry.margin\nset direct.retry.margin 0\nset direct.retry.margin 2.5\nset direct.retry.margin 5\nset direct.retry.margin 10\n</code></pre>"},{"location":"cli_commands/#view-or-change-adaptive-direct-retry-coding-rate","title":"View or change adaptive direct retry coding rate","text":"<p>Usage: - <code>get direct.retry.cr</code> - <code>set direct.retry.cr off</code> - <code>set direct.retry.cr on</code> (room-server and sensor) - <code>set direct.retry.cr &lt;cr4_min&gt;,&lt;cr5_min&gt;,&lt;cr7_min&gt;,&lt;cr8_max&gt;</code></p> <p>Parameters: - <code>cr4_min</code>: Minimum SNR in dB to retry at CR4. - <code>cr5_min</code>: Minimum SNR in dB to retry at CR5. - <code>cr7_min</code>: Minimum SNR in dB to retry at CR7. - <code>cr8_max</code>: Maximum SNR in dB that forces CR8.</p> <p>Default: <code>10.00,7.50,2.50,2.50</code></p> <p>Explanation: - Higher SNR uses faster coding rates. - Lower SNR uses more robust coding rates. - Repeater retry attempts escalate from the adaptive starting CR. CR4 starts as CR4, CR5, CR7, CR7, then CR8. CR5 starts as CR5, CR7, CR7, then CR8. CR7 gets two attempts, then CR8. - Repeater adaptive CR selection intentionally skips CR6. - Non-repeater retry packets start at the current radio CR and follow the same escalation pattern, clamped at CR8. With the normal CR5 radio setting this is CR5, CR7, CR7, then CR8. - Room-server and sensor firmware accept <code>on</code> or <code>off</code>; numeric SNR thresholds   are repeater-only because those roles do not keep recent-repeater SNR data. - <code>off</code> disables per-packet retry CR overrides and uses the current radio CR. - Retry packets may use a different coding rate, but they keep the radio's normal physical preamble. - Unknown repeaters start at <code>+3.00 dB</code> for adaptive CR selection. - A failed unknown repeater is seeded at <code>+2.75 dB</code>. - Each later failure lowers the SNR estimate by <code>0.25 dB</code>.</p> <p>Examples:</p> <pre><code>get direct.retry.cr\nset direct.retry.cr off\nset direct.retry.cr on\nset direct.retry.cr 10.0,7.5,2.5,2.5\nset direct.retry.cr 12.0,8.0,4.0,1.0\nset direct.retry.cr 8.0,5.0,1.5,0\nset direct.retry.cr 6.0,3.0,0,-2.0\nset direct.retry.cr 20.0,12.0,6.0,2.0\nset direct.retry.cr 4.0,2.0,0,-4.0\n</code></pre> <p>Example profiles: - Conservative weak-link profile:</p> <pre><code>set direct.retry.cr 12.0,8.0,4.0,1.0\n</code></pre> <ul> <li>Balanced rooftop profile:</li> </ul> <pre><code>set direct.retry.cr 10.0,7.5,2.5,2.5\n</code></pre> <ul> <li>Faster strong-link profile:</li> </ul> <pre><code>set direct.retry.cr 6.0,3.0,0,-2.0\n</code></pre> <ul> <li>Very cautious noisy-link profile:</li> </ul> <pre><code>set direct.retry.cr 20.0,12.0,6.0,2.0\n</code></pre>"},{"location":"cli_commands/#view-seed-or-clear-the-recent-repeater-table","title":"View, seed, or clear the recent repeater table","text":"<p>Usage: - <code>get recent.repeater</code> - <code>get recent.repeater &lt;page&gt;</code> - <code>get recent.repeaters &lt;page&gt;</code> - <code>get recent.repeaters search &lt;prefix&gt; [page]</code> - <code>set recent.repeater &lt;prefix&gt; [snr_db]</code> - <code>clear recent.repeater</code></p> <p>Parameters: - <code>prefix</code>: Repeater path-hash prefix as 2, 4, or 6 hex characters. - <code>snr_db</code>: Optional SNR in dB. If omitted or invalid, defaults to <code>3.0</code>. - <code>page</code>: 1-based result page.</p> <p>Note: These commands are repeater-only.</p> <p>Output order: - <code>get recent.repeater</code> lists 3-byte prefixes first, then 2-byte prefixes, then 1-byte prefixes. - Within each prefix length, entries are sorted from highest SNR to lowest SNR. - <code>search</code> returns every overlapping path-hash entry. For example, searching   <code>860C</code> can return <code>86</code>, <code>860C</code>, and <code>860CCA</code>; it does not return a different   branch such as <code>86D0</code>. - Search rows include the monotonic age of the entry's most recent recording,   compacted to a whole <code>s</code>, <code>m</code>, or <code>h</code> field. Search pages contain up to six   rows so the result remains within the remote CLI reply limit.</p> <p>SNR details: - Recent repeater SNR is stored internally in quarter-dB units. - Heard repeater samples update an existing table entry with a weighted blend: <code>75%</code> existing SNR and <code>25%</code> new heard SNR, rounded up. - Direct retry success also feeds the heard echo SNR back into the same weighted table. - Direct retry failure is not weighted: each final echo-timeout failure lowers that repeater's SNR by <code>0.25 dB</code>. - Unknown repeaters start at <code>+3.00 dB</code> for adaptive CR selection. - If an unknown repeater fails, it is seeded into the table at <code>+2.75 dB</code>. - <code>set recent.repeater &lt;prefix&gt; [snr_db]</code> seeds a missing prefix or adds another weighted sample for an existing prefix. - Successful <code>set recent.repeater</code> replies include the stored prefix and SNR, for example <code>OK - set A1B2C3 at 3.0 SNR</code>. - Entries strictly older than 24 hours are removed during a sweep every three hours, so an entry can remain for at most approximately 27 hours.</p> <p>Examples:</p> <pre><code>get recent.repeater\nget recent.repeater 2\nget recent.repeaters search 86\nget recent.repeaters search 860C page 2\nset recent.repeater A1B2C3 8.5\nset recent.repeater 71CE82 -3.25\nset recent.repeater A1B2C3\nclear recent.repeater\n</code></pre>"},{"location":"cli_commands/#gps-when-gps-support-is-compiled-in","title":"GPS (When GPS support is compiled in)","text":""},{"location":"cli_commands/#view-or-change-gps-state","title":"View or change GPS state","text":"<p>Usage: - <code>gps</code> - <code>gps &lt;state&gt;</code></p> <p>Parameters: - <code>state</code>: <code>on</code>|<code>off</code></p> <p>Default: <code>off</code></p> <p>Note: Output format: - <code>off</code> when the GPS hardware is disabled - <code>on, {active|deactivated}, {fix|no fix}, {sat count} sats</code> when the GPS hardware is enabled</p>"},{"location":"cli_commands/#sync-this-nodes-clock-with-gps-time","title":"Sync this node's clock with GPS time","text":"<p>Usage:  - <code>gps sync</code></p> <p>The GPS must be enabled. When GPS power saving has put an enabled receiver to sleep, this command schedules a sync and wakes it; after <code>gps off</code>, it reports <code>gps is off</code> without scheduling work.</p>"},{"location":"cli_commands/#set-this-nodes-location-based-on-the-gps-coordinates","title":"Set this node's location based on the GPS coordinates","text":"<p>Usage:  - <code>gps setloc</code></p>"},{"location":"cli_commands/#view-or-change-the-gps-advert-policy","title":"View or change the GPS advert policy","text":"<p>Usage: - <code>gps advert</code> - <code>gps advert &lt;policy&gt;</code></p> <p>Parameters:  - <code>policy</code>: <code>none</code>|<code>share</code>|<code>prefs</code>    - <code>none</code>: don't include location in adverts   - <code>share</code>: share gps location (from SensorManager)   - <code>prefs</code>: location stored in node's lat and lon settings</p> <p>Default: <code>prefs</code> on every repeater, room-server, and sensor build that uses the common advert policy. A previously saved <code>none</code>, <code>share</code>, or <code>prefs</code> choice still overrides the first-boot default after an update.</p>"},{"location":"cli_commands/#sensors-when-sensor-support-is-compiled-in","title":"Sensors (When sensor support is compiled in)","text":""},{"location":"cli_commands/#view-or-change-telemetry-access-mode","title":"View or change telemetry access mode","text":"<p>Usage: - <code>get telemetry.access</code> - <code>set telemetry.access &lt;mode&gt;</code></p> <p>Parameters: - <code>mode</code>: <code>all</code>|<code>acl</code>   - <code>all</code>: allow telemetry requests using the requester-provided telemetry mask   - <code>acl</code>: require ACL read-only or higher for telemetry, including GPS</p> <p>Default: <code>all</code></p> <p>Note: <code>all</code> matches the previous sensor telemetry behavior.</p>"},{"location":"cli_commands/#view-the-list-of-sensors-on-this-node","title":"View the list of sensors on this node","text":"<p>Usage: <code>sensor list [start]</code></p> <p>Parameters: - <code>start</code>: Optional starting index (defaults to 0)</p> <p>Note: Output format: <code>&lt;var_name&gt;=&lt;value&gt;\\n</code></p>"},{"location":"cli_commands/#view-or-change-the-value-of-a-sensor","title":"View or change the value of a sensor","text":"<p>Usage:  - <code>sensor get &lt;key&gt;</code> - <code>sensor set &lt;key&gt; &lt;value&gt;</code></p> <p>Parameters: - <code>key</code>: Sensor setting name - <code>value</code>: The value to set the sensor to</p>"},{"location":"cli_commands/#bridge-when-bridge-support-is-compiled-in","title":"Bridge (When bridge support is compiled in)","text":""},{"location":"cli_commands/#view-the-compiled-bridge-type","title":"View the compiled bridge type","text":"<p>Usage: <code>get bridge.type</code></p>"},{"location":"cli_commands/#view-or-change-the-bridge-enabled-flag","title":"View or change the bridge enabled flag","text":"<p>Usage: - <code>get bridge.enabled</code> - <code>get bridge.running</code> - <code>set bridge.enabled &lt;state&gt;</code></p> <p>Parameters: - <code>state</code>: <code>on</code>|<code>off</code></p> <p><code>bridge.enabled</code> is the saved intent. <code>bridge.running</code> reports whether the bridge actually started in this boot; they can differ after a hardware conflict, missing credentials, or a transient initialization failure. Normal merged repeater images default to <code>off</code>; dedicated bridge images may default to <code>on</code>.</p>"},{"location":"cli_commands/#add-a-delay-to-packets-routed-through-this-bridge","title":"Add a delay to packets routed through this bridge","text":"<p>Usage: - <code>get bridge.delay</code> - <code>set bridge.delay &lt;ms&gt;</code></p> <p>Parameters: - <code>ms</code>: Delay in milliseconds (0-10000)</p> <p>Default: <code>500</code></p>"},{"location":"cli_commands/#view-or-change-the-source-of-packets-bridged-to-the-external-interface","title":"View or change the source of packets bridged to the external interface","text":"<p>Usage: - <code>get bridge.source</code> - <code>set bridge.source &lt;source&gt;</code></p> <p>Parameters: - <code>source</code>:   - <code>rx</code>: bridges received packets   - <code>tx</code>: bridges transmitted packets</p> <p>Default: <code>tx</code></p> <p>Note: For MQTT bridges, use <code>mqtt.rx</code> and <code>mqtt.tx</code> instead of <code>bridge.source</code>. These provide independent per-direction control and support both RX and TX simultaneously. <code>bridge.source</code> still works as a convenience alias for MQTT (setting <code>bridge.source rx</code> sets <code>mqtt.rx on</code> + <code>mqtt.tx off</code>, and vice versa), but <code>mqtt.rx</code>/<code>mqtt.tx</code> are preferred.</p>"},{"location":"cli_commands/#view-or-change-mqtt-rx-packet-uplinking","title":"View or change MQTT RX packet uplinking","text":"<p>Usage: - <code>get mqtt.rx</code> - <code>set mqtt.rx &lt;on|off&gt;</code></p> <p>Parameters: - <code>on</code>: uplink received (RX) packets to MQTT brokers - <code>off</code>: disable RX packet uplinking</p> <p>Default: <code>on</code></p>"},{"location":"cli_commands/#view-or-change-mqtt-tx-packet-uplinking","title":"View or change MQTT TX packet uplinking","text":"<p>Usage: - <code>get mqtt.tx</code> - <code>set mqtt.tx &lt;on|off|advert&gt;</code></p> <p>Parameters: - <code>on</code>: uplink all transmitted (TX) packets to MQTT brokers - <code>advert</code>: uplink only this node's own advert packets (self-originated advertisements only - forwarded adverts from other nodes are filtered out) - <code>off</code>: disable TX packet uplinking</p> <p>Default: <code>advert</code></p> <p>Note: <code>mqtt.rx</code> and <code>mqtt.tx</code> take effect immediately - no restart required. Both can be enabled simultaneously.</p>"},{"location":"cli_commands/#view-or-change-periodic-neighbors-publishing-mqtt-observer-neighbors-feature","title":"View or change periodic neighbors publishing (MQTT observer, neighbors feature)","text":"<p>Usage: - <code>get mqtt.neighbors</code> - <code>set mqtt.neighbors &lt;on|off&gt;</code></p> <p>Parameters: - <code>on</code>: periodically discover neighbor scopes and publish the neighbor table to the <code>neighbors</code> topic - <code>off</code>: disable periodic neighbors publishing</p> <p>Default: <code>off</code></p> <p>Note: Requires a build with the neighbors feature compiled in (all PSRAM boards, plus non-PSRAM boards built with <code>MQTT_NEIGHBORS_WITHOUT_PSRAM</code>); elsewhere this replies <code>Err - neighbors not enabled in this build</code>. Non-PSRAM builds publish at most 20 neighbours per pass to bound internal-DRAM use, and set <code>truncated</code> with the true <code>total_neighbors</code> when the table is larger. The setting is read live by the mesh loop - no restart required; enabling it triggers a discovery on the next pass. While enabled, <code>get mqtt.status</code> gains a trailing <code>nbr: &lt;next&gt;/&lt;last&gt;</code> field (time to next publish, and how the last publish went).</p>"},{"location":"cli_commands/#view-or-change-the-neighbors-publish-interval-mqtt-observer-neighbors-feature","title":"View or change the neighbors publish interval (MQTT observer, neighbors feature)","text":"<p>Usage: - <code>get mqtt.neighbors.interval</code> - <code>set mqtt.neighbors.interval &lt;hours&gt;</code></p> <p>Parameters: - <code>hours</code>: how often to publish the neighbor table (12-336, default 24)</p> <p>Default: <code>24</code> (hours)</p> <p>Note: Out-of-range values are rejected (not clamped). Requires a build with <code>WITH_MQTT_NEIGHBORS</code>; PSRAM boards enable it automatically and selected non-PSRAM variants opt in with <code>MQTT_NEIGHBORS_WITHOUT_PSRAM</code>.</p>"},{"location":"cli_commands/#view-or-change-the-ntp-server-mqtt-observer-only","title":"View or change the NTP server (MQTT observer only)","text":"<p>Usage: - <code>get mqtt.ntp</code> - <code>set mqtt.ntp &lt;hostname&gt;</code> - <code>set mqtt.ntp none</code></p> <p>Description: Sets the primary NTP server used for clock sync (required for JWT MQTT auth). On <code>set</code>, the device attempts an immediate sync of the just-configured server (primary only, so a typo fails fast) when WiFi is connected and the MQTT bridge is running.</p> <p>Fallbacks: If the primary fails, the firmware tries <code>pool.ntp.org</code>, <code>time.google.com</code>, <code>time.cloudflare.com</code>, <code>time.aws.com</code>, and <code>time.nist.gov</code> in order (skipping duplicates).</p> <p>Default: <code>pool.ntp.org</code> (when unset or <code>none</code>)</p>"},{"location":"cli_commands/#diagnose-ntp-server-connectivity-mqtt-observer-only","title":"Diagnose NTP server connectivity (MQTT observer only)","text":"<p>Usage: - <code>get mqtt.ntp.diag</code></p> <p>Description: Probes every configured NTP server (the custom primary, if set, plus the built-in fallbacks) and reports whether each responds. This is a pure connectivity diagnostic - it does not change the system clock.</p> <ul> <li>Serial console: prints a detailed table with each server's reported UTC time (or <code>FAIL</code>).</li> <li>Over LoRa: returns a compact <code>&lt;server&gt; ok|fail</code> list, one per line.</li> </ul> <p>Requires WiFi connected and the MQTT bridge running.</p>"},{"location":"cli_commands/#view-or-change-the-speed-of-the-bridge-rs-232-only","title":"View or change the speed of the bridge (RS-232 only)","text":"<p>Usage: - <code>get bridge.baud</code> - <code>set bridge.baud &lt;rate&gt;</code></p> <p>Parameters: - <code>rate</code>: Baud rate (<code>9600</code>, <code>19200</code>, <code>38400</code>, <code>57600</code>, or <code>115200</code>)</p> <p>Default: <code>115200</code></p>"},{"location":"cli_commands/#view-or-change-the-uart-used-by-the-bridge-rs-232-only","title":"View or change the UART used by the bridge (RS-232 only)","text":"<p>Usage: - <code>get bridge.uart</code> - <code>set bridge.uart &lt;port&gt;</code></p> <p>Parameters: - <code>port</code>: Hardware UART number compiled for the board. Most boards expose one   fixed UART. RAK4631 accepts <code>1</code> or <code>2</code>; UART 2 is the default so UART 1 can   remain available to the RAK12501/L76K GPS. RAK12500 GPS uses I2C rather than   this UART, but the explicit legacy Serial1 bridge omits the combined GPS   provider and therefore does not expose either GPS path.</p> <p>The setting is persistent and restarts an enabled bridge immediately. Normal repeater artifacts start with <code>bridge.enabled off</code>; configure the UART and baud rate before running <code>set bridge.enabled on</code>. On the canonical RAK4631 runtime image, UART 1 is reserved even if the bounded boot probe hears no RAK12501. Silence cannot prove that a cold L76K is physically absent, and that module remains powered by the shared WB_IO2/3V3_S rail. Use UART 2. UART 1 requires an explicit no-GPS/dedicated Serial1 bridge image. This fail-closed reservation also applies when the detected GPS is an I2C RAK12500; that receiver does not electrically use UART 1, but its presence cannot rule out another silent UART module.</p>"},{"location":"cli_commands/#view-or-change-the-channel-used-for-bridging-espnow-only","title":"View or change the channel used for bridging (ESPNow only)","text":"<p>Usage: - <code>get bridge.channel</code> - <code>set bridge.channel &lt;channel&gt;</code></p> <p>Parameters: - <code>channel</code>: Channel number from 1 through 13 in either format. This matches   the primary-ESP-NOW policy and the default regulatory range used by the   supported ESP32 targets.</p> <p>This controls the optional ESP-NOW bridge transport; it does not change a node's primary ESP-NOW mesh channel. Primary-ESP-NOW firmware uses <code>get espnow.channel</code> and <code>set espnow.channel &lt;1-13&gt;</code> instead.</p>"},{"location":"cli_commands/#view-or-change-the-esp-now-bridge-wire-format","title":"View or change the ESP-NOW bridge wire format","text":"<p>Usage: - <code>get bridge.format</code> - <code>set bridge.format &lt;format&gt;</code></p> <p>Parameters: - <code>format</code>:   - <code>wrapped</code>: the original ESP-NOW bridge framing (magic, checksum, and XOR     using <code>bridge.secret</code>)   - <code>raw</code>: the exact serialized MeshCore packet used by primary     <code>ESPNOWRadio</code> firmware</p> <p>Default: <code>wrapped</code></p> <p>The setting is persistent and restarts an enabled bridge immediately. Receive parsing is strict: <code>wrapped</code> accepts only wrapped frames and <code>raw</code> accepts only raw MeshCore frames. Coordinate the format and channel on every ESP-NOW peer; there is no automatic dual-format receive mode because it would permit ambiguous, asymmetric bridge deployments.</p> <p>Use <code>raw</code> to connect a LoRa-primary <code>*_repeater_bridge_espnow</code> node to <code>Generic_ESPNOW</code>, <code>SenseCapIndicator-ESPNow</code>, or another primary-ESP-NOW node. Raw mode enables the ESP-NOW LR PHY and sends at the same LR rate used by those targets. All nodes must use the same 1-13 channel. On a primary-ESP-NOW node, change that side with <code>set espnow.channel &lt;1-13&gt;</code> and reboot; on the bridge, use <code>set bridge.channel &lt;1-13&gt;</code>.</p> <p>Raw mode ignores <code>bridge.secret</code> and removes the bridge wrapper's lightweight network isolation. MeshCore's own packet authentication/encryption still applies where the packet type provides it, but public frames and routing metadata remain visible. The wrapped format's XOR is isolation, not strong cryptography. Bridge duplicate tracking remains active in both formats, but deploying multiple gateways between the same LoRa and ESP-NOW coverage areas can still increase duplicate traffic while their seen-packet tables converge.</p> <p>One ESP-NOW frame carries at most 250 payload bytes. In raw mode, serialized MeshCore packets up to that size remain byte-for-byte compatible with existing raw endpoints. Updated raw endpoints split 251-255-byte transport units into two versioned fragments and reassemble them by source MAC, length, and CRC; both endpoints must include this support for those sizes. Current valid MeshCore packet geometry reaches 254 bytes, while 255 is retained as transport headroom. Wrapped mode retains its legacy 246-byte maximum after the four-byte magic and checksum overhead, and drops larger packets instead of truncating them.</p>"},{"location":"cli_commands/#set-the-esp-now-secret","title":"Set the ESP-Now secret","text":"<p>Usage:  - <code>get bridge.secret</code> - <code>set bridge.secret &lt;secret&gt;</code></p> <p>Parameters: - <code>secret</code>: ESP-NOW bridge secret, 1-15 characters</p> <p>Default: Varies by board</p> <p>This setting is used only by <code>bridge.format wrapped</code>; raw mode ignores it.</p>"},{"location":"cli_commands/#view-the-bootloader-version-nrf52-only","title":"View the bootloader version (nRF52 only)","text":"<p>Usage: <code>get bootloader.ver</code></p>"},{"location":"cli_commands/#view-power-management-support","title":"View power management support","text":"<p>Usage: <code>get pwrmgt.support</code></p>"},{"location":"cli_commands/#view-the-current-power-source","title":"View the current power source","text":"<p>Usage: <code>get pwrmgt.source</code></p> <p>Note: Returns an error on boards without power management support.</p>"},{"location":"cli_commands/#view-the-boot-reset-and-shutdown-reasons","title":"View the boot reset and shutdown reasons","text":"<p>Usage: <code>get pwrmgt.bootreason</code></p> <p>Note: Returns an error on boards without power management support.</p>"},{"location":"cli_commands/#view-the-boot-voltage","title":"View the boot voltage","text":"<p>Usage: <code>get pwrmgt.bootmv</code></p> <p>Note: Returns an error on boards without power management support.</p>"},{"location":"cli_commands/#ethernet-when-ethernet-support-is-compiled-in","title":"Ethernet (when Ethernet support is compiled in)","text":"<p>Ethernet support is available on RAK4631 boards with a RAK13800 (W5100S) Ethernet module. Use the <code>_ethernet</code> firmware variants (e.g. <code>RAK_4631_repeater_ethernet</code>) to enable this feature.</p>"},{"location":"cli_commands/#view-ethernet-connection-status","title":"View Ethernet connection status","text":"<p>Usage: - <code>eth.status</code></p> <p>Output: - <code>ETH: &lt;ip&gt;:&lt;port&gt;</code> when connected (e.g. <code>ETH: 192.168.1.50:23</code>) - <code>ETH: not connected</code> when Ethernet is not active</p> <p>Notes: - Available on repeater and room server firmware only. Companion radio ethernet firmware does not expose a CLI. - The Ethernet interface obtains an IP address via DHCP automatically on boot. - A TCP server listens on port 23 (default) for CLI connections. - Connect with any TCP client (e.g. <code>nc</code>, PuTTY) to access the same CLI available over serial.</p>"},{"location":"companion_offline_queue/","title":"Companion Offline Message Queue","text":"<p>Companion firmware keeps received channel data, channel messages, and direct messages in one pending queue until a Companion client requests them with the sync-next-message command. This is volatile RAM, not message history in flash. A reboot clears it.</p>"},{"location":"companion_offline_queue/#default-capacities","title":"Default capacities","text":"Platform or memory profile Pending frames ESP32 with configured PSRAM 512 ESP32 without PSRAM 256 nRF52840 256 RP2040 256 STM32 16 Known constrained classic ESP32 target override 128 Meshadventurer Full Companion 64 Constrained Full ESP32 fallback 16 <p>An explicit target <code>OFFLINE_QUEUE_SIZE</code> overrides the platform default. The Heltec V2 and TLora V2 Full Companion profiles, for example, use 16 frames so their combined WiFi, BLE, and LoRa mOTA image retains enough internal DRAM. Meshadventurer SX1262 and SX1268 Full Companion use 64 frames together with 160 contacts and 30 group channels; their ordinary transport-specific images keep 128 frames and 40 channels.</p> <p>Standard, logging, MQTT, and Cascade build overlays retain the selected target capacity; they do not silently shrink the queue.</p> <p>Each queue slot currently costs 177 bytes. A 256-frame queue reserves 45,312 bytes, while a 512-frame queue reserves 90,624 bytes. There is no 256-frame protocol limit: the queue length and indexes can represent 512 or more. The practical limit is available RAM and the heap and stack headroom required by the transports and display.</p> <p>On ESP32 boards marked with <code>BOARD_HAS_PSRAM</code>, the queue is allocated from PSRAM before WiFi and BLE start. A failed 512-frame allocation retries at 256, then 128, and finally uses a 16-frame internal fallback. Full Companion prints the capacity actually allocated in its startup memory line as <code>offline_queue=&lt;frames&gt;</code>.</p>"},{"location":"companion_offline_queue/#full-queue-behavior","title":"Full queue behavior","text":"<p>The capacity is shared across Public, other channels, channel data, and direct messages. It is not a per-channel count. When the queue is full, firmware replaces the oldest queued channel frame so newer traffic can still arrive. If the full queue contains only direct messages, a new frame is dropped rather than deleting a direct message.</p> <p>Queue order is preserved. Removal uses a ring index, so delivering one pending message no longer copies every remaining frame; only the less-common removal of an old channel frame from a full queue may shift entries.</p> <p>Capacity is selected when firmware is compiled. There is no CLI or Companion protocol setting to resize it at runtime.</p>"},{"location":"companion_protocol/","title":"Companion Protocol","text":"<ul> <li>Last Updated: 2026-08-26</li> <li>Protocol Version: 14 (<code>FIRMWARE_VER_CODE</code>)</li> </ul> <p>The command and response catalogs track <code>examples/companion_radio/MyMesh.cpp</code>. Applications should negotiate the protocol and validate lengths because older firmware exposes a subset.</p> <p>This document is a practical guide to MeshCore's binary companion protocol. The same protocol frames can be carried by the enabled BLE, USB serial, Wi-Fi, or Ethernet companion interface; connection details differ by build.</p> <p>On builds exposing more than one transport, delivery-required replies follow the interface which supplied the command. The multi-frame contact-list response holds that route until <code>END_OF_CONTACTS</code>; best-effort asynchronous observations may still be broadcast to enabled clients. Treat the device as one Companion session rather than as independent per-transport sessions.</p> <p>The examples focus on BLE, but the packet formats are transport-independent.</p>"},{"location":"companion_protocol/#official-libraries","title":"Official Libraries","text":"<p>Please see the following repos for existing MeshCore Companion Protocol libraries.</p> <ul> <li>JavaScript: https://github.com/meshcore-dev/meshcore.js</li> <li>Python: https://github.com/meshcore-dev/meshcore_py</li> </ul>"},{"location":"companion_protocol/#important-security-note","title":"Important Security Note","text":"<p>All secrets, hashes, and cryptographic values shown in this guide are example values only.</p> <ul> <li>All hex values, public keys and hashes are for demonstration purposes only</li> <li>Never use example secrets in production</li> <li>Always generate new cryptographically secure random secrets</li> <li>Please implement proper security practices in your implementation</li> <li>This guide is for protocol documentation only</li> </ul>"},{"location":"companion_protocol/#table-of-contents","title":"Table of Contents","text":"<ol> <li>BLE Connection</li> <li>Packet Structure</li> <li>Commands</li> <li>Channel Management</li> <li>Message Handling</li> <li>Response Parsing</li> <li>Example Implementation Flow</li> <li>Best Practices</li> <li>Troubleshooting</li> </ol>"},{"location":"companion_protocol/#ble-connection","title":"BLE Connection","text":""},{"location":"companion_protocol/#service-and-characteristics","title":"Service and Characteristics","text":"<p>MeshCore Companion devices expose a BLE service with the following UUIDs:</p> <ul> <li>Service UUID: <code>6E400001-B5A3-F393-E0A9-E50E24DCCA9E</code></li> <li>RX Characteristic (App -&gt; Firmware): <code>6E400002-B5A3-F393-E0A9-E50E24DCCA9E</code></li> <li>TX Characteristic (Firmware -&gt; App): <code>6E400003-B5A3-F393-E0A9-E50E24DCCA9E</code></li> </ul> <p>An nRF52 Full Companion also exposes a separate LoRa mOTA source service. It does not replace or multiplex the normal Companion UART service:</p> <ul> <li>mOTA Service: <code>14518FC2-7E7A-4D84-8CAE-6664B0234CF2</code></li> <li>Device Request (notify): <code>2BFAA1EE-7030-459A-B65A-E7CFD5B09735</code></li> <li>Host Response (write with response): <code>ACF38A51-DD58-4DCE-917F-0B1135E41B1A</code></li> </ul> <p>All three mOTA attributes require an encrypted, MITM-authenticated connection using the Companion's six-digit PIN. The source remains inactive until the client subscribes to Device Request and explicitly starts it with command <code>0x4B</code>. See Bluetooth LoRa mOTA source.</p> <p>ESP32 and nRF52 Companion UART characteristics require the same PIN-protected, MITM-authenticated link. ESP32 advertises DisplayOnly capability so a central must enter the PIN shown by the Companion; a Just Works bond is insufficient.</p>"},{"location":"companion_protocol/#connection-steps","title":"Connection Steps","text":"<ol> <li> <p>Scan for Devices</p> <ul> <li>Scan for BLE devices advertising the MeshCore Service UUID</li> <li>Optionally filter by device name (typically contains \"MeshCore\" prefix)</li> <li>Note the device MAC address for reconnection</li> </ul> </li> <li> <p>Connect to GATT</p> <ul> <li>Connect to the device using the discovered MAC address</li> <li>Wait for connection to be established</li> </ul> </li> <li> <p>Discover Services and Characteristics</p> <ul> <li>Discover the service with UUID <code>6E400001-B5A3-F393-E0A9-E50E24DCCA9E</code></li> <li>Discover the RX characteristic <code>6E400002-B5A3-F393-E0A9-E50E24DCCA9E</code><ul> <li>Your app writes to this, the firmware reads from this</li> </ul> </li> <li>Discover the TX characteristic <code>6E400003-B5A3-F393-E0A9-E50E24DCCA9E</code><ul> <li>The firmware writes to this, your app reads from this</li> </ul> </li> </ul> </li> <li> <p>Enable Notifications</p> <ul> <li>Subscribe to notifications on the TX characteristic to receive data from the firmware</li> </ul> </li> <li> <p>Send Initial Commands</p> <ul> <li>Send <code>CMD_APP_START</code> to identify your app to firmware and get radio settings</li> <li>Send <code>CMD_DEVICE_QUERY</code> to fetch device info and negotiate supported protocol versions</li> <li>Send <code>CMD_SET_DEVICE_TIME</code> to set the firmware clock</li> <li>Send <code>CMD_GET_CONTACTS</code> to fetch all contacts</li> <li>Send <code>CMD_GET_CHANNEL</code> multiple times to fetch all channel slots</li> <li>Send <code>CMD_SYNC_NEXT_MESSAGE</code> to fetch the next message stored in firmware</li> <li>Setup listeners for push codes, such as <code>PUSH_CODE_MSG_WAITING</code> or <code>PUSH_CODE_ADVERT</code></li> <li>See Commands section for information on other commands</li> </ul> </li> </ol> <p>Note: MeshCore devices may disconnect after periods of inactivity. Implement auto-reconnect logic with exponential backoff.</p>"},{"location":"companion_protocol/#ble-write-type","title":"BLE Write Type","text":"<p>When writing commands to the RX characteristic, specify the write type:</p> <ul> <li>Write with Response (default): Waits for acknowledgment from device</li> <li>Write without Response: Faster but no acknowledgment</li> </ul> <p>Platform-specific:</p> <ul> <li>Android: Use <code>BluetoothGattCharacteristic.WRITE_TYPE_DEFAULT</code> or <code>WRITE_TYPE_NO_RESPONSE</code></li> <li>iOS: Use <code>CBCharacteristicWriteType.withResponse</code> or <code>.withoutResponse</code></li> <li>Python (bleak): Use <code>write_gatt_char()</code> with <code>response=True</code> or <code>False</code></li> </ul> <p>Recommendation: Use write with response for reliability.</p>"},{"location":"companion_protocol/#mtu-maximum-transmission-unit","title":"MTU (Maximum Transmission Unit)","text":"<p>The default BLE MTU is 23 bytes (20 bytes payload). For larger commands like <code>SET_CHANNEL</code> (50 bytes), you may need to:</p> <ol> <li>Request Larger MTU: Request MTU of 512 bytes if supported<ul> <li>Android: <code>gatt.requestMtu(512)</code></li> <li>iOS: <code>peripheral.maximumWriteValueLength(for:)</code></li> <li>Python (bleak): MTU is negotiated automatically</li> </ul> </li> </ol>"},{"location":"companion_protocol/#command-sequencing","title":"Command Sequencing","text":"<p>Critical: Commands must be sent in the correct sequence:</p> <ol> <li> <p>After Connection:</p> <ul> <li>Wait for BLE connection to be established</li> <li>Wait for services/characteristics to be discovered</li> <li>Wait for notifications to be enabled</li> <li>Now you can safely send commands to the firmware</li> </ul> </li> <li> <p>Command-Response Matching:</p> <ul> <li>Send one command at a time</li> <li>Wait for a response before sending another command</li> <li>Use a timeout (typically 5 seconds)</li> <li>Match response to command by type (e.g: <code>CMD_GET_CHANNEL</code> -&gt; <code>RESP_CODE_CHANNEL_INFO</code>)</li> </ul> </li> </ol>"},{"location":"companion_protocol/#command-queue-management","title":"Command Queue Management","text":"<p>For reliable operation, implement a command queue.</p> <p>Queue Structure:</p> <ul> <li>Maintain a queue of pending commands</li> <li>Track which command is currently waiting for a response</li> <li>Only send next command after receiving response or timeout</li> </ul> <p>Error Handling:</p> <ul> <li>On timeout, clear current command, process next in queue</li> <li>On error, log error, clear current command, process next</li> </ul>"},{"location":"companion_protocol/#packet-structure","title":"Packet Structure","text":"<p>The MeshCore protocol uses a binary format with the following structure:</p> <ul> <li>Commands: Sent from app to firmware via RX characteristic</li> <li>Responses: Received from firmware via TX characteristic notifications</li> <li>All multi-byte integers: Little-endian byte order (except CayenneLPP which is Big-endian)</li> <li>All strings: UTF-8 encoding</li> </ul> <p>Most packets follow this format:</p> <pre><code>[Packet Type (1 byte)] [Data (variable length)]\n</code></pre> <p>The first byte indicates the packet type (see Response Parsing).</p>"},{"location":"companion_protocol/#commands","title":"Commands","text":"<p>The first byte selects the command. This is the current protocol-v14 command catalog; bytes <code>0x2C</code>-<code>0x31</code> are parked and <code>0x35</code> is unused.</p> Byte Firmware name Purpose <code>0x01</code> <code>CMD_APP_START</code> Start an app session and request self information. <code>0x02</code> <code>CMD_SEND_TXT_MSG</code> Send text to a contact. <code>0x03</code> <code>CMD_SEND_CHANNEL_TXT_MSG</code> Send channel text. <code>0x04</code> <code>CMD_GET_CONTACTS</code> Enumerate contacts, optionally modified since a timestamp. <code>0x05</code> / <code>0x06</code> <code>CMD_GET_DEVICE_TIME</code> / <code>CMD_SET_DEVICE_TIME</code> Read or set the device clock. <code>0x07</code> / <code>0x08</code> <code>CMD_SEND_SELF_ADVERT</code> / <code>CMD_SET_ADVERT_NAME</code> Advertise self or change the advertised name. <code>0x09</code> <code>CMD_ADD_UPDATE_CONTACT</code> Add or update a contact. <code>0x0A</code> <code>CMD_SYNC_NEXT_MESSAGE</code> Dequeue the next pending message. <code>0x0B</code> / <code>0x0C</code> <code>CMD_SET_RADIO_PARAMS</code> / <code>CMD_SET_RADIO_TX_POWER</code> Set radio parameters or transmit power. <code>0x0D</code> <code>CMD_RESET_PATH</code> Reset a contact's learned path. <code>0x0E</code> <code>CMD_SET_ADVERT_LATLON</code> Set advertised coordinates. <code>0x0F</code> <code>CMD_REMOVE_CONTACT</code> Remove a contact. <code>0x10</code> / <code>0x11</code> / <code>0x12</code> <code>CMD_SHARE_CONTACT</code> / <code>CMD_EXPORT_CONTACT</code> / <code>CMD_IMPORT_CONTACT</code> Share, export, or import contact data. <code>0x13</code> <code>CMD_REBOOT</code> Reboot after the required confirmation body. <code>0x14</code> <code>CMD_GET_BATT_AND_STORAGE</code> Read battery and storage usage. <code>0x15</code> <code>CMD_SET_TUNING_PARAMS</code> Set tuning parameters. <code>0x16</code> <code>CMD_DEVICE_QUERY</code> Negotiate protocol support and read device information. <code>0x17</code> / <code>0x18</code> <code>CMD_EXPORT_PRIVATE_KEY</code> / <code>CMD_IMPORT_PRIVATE_KEY</code> Export or import identity key material when enabled. <code>0x19</code> <code>CMD_SEND_RAW_DATA</code> Send an application raw-data packet. <code>0x1A</code>-<code>0x1D</code> <code>CMD_SEND_LOGIN</code> through <code>CMD_LOGOUT</code> Manage a server connection. <code>0x1E</code> <code>CMD_GET_CONTACT_BY_KEY</code> Look up a contact by public-key prefix. <code>0x1F</code> / <code>0x20</code> <code>CMD_GET_CHANNEL</code> / <code>CMD_SET_CHANNEL</code> Read or write a channel slot. <code>0x21</code>-<code>0x23</code> <code>CMD_SIGN_START</code> through <code>CMD_SIGN_FINISH</code> Stream data for identity signing. <code>0x24</code> <code>CMD_SEND_TRACE_PATH</code> Trace a direct route. <code>0x25</code> <code>CMD_SET_DEVICE_PIN</code> Set or clear the device PIN. <code>0x26</code> <code>CMD_SET_OTHER_PARAMS</code> Set telemetry, location, ACK, and related preferences. <code>0x27</code> <code>CMD_SEND_TELEMETRY_REQ</code> Send the legacy telemetry request. <code>0x28</code> / <code>0x29</code> <code>CMD_GET_CUSTOM_VARS</code> / <code>CMD_SET_CUSTOM_VAR</code> Read or set custom variables. <code>0x2A</code> <code>CMD_GET_ADVERT_PATH</code> Read a cached advertisement path. <code>0x2B</code> <code>CMD_GET_TUNING_PARAMS</code> Read tuning parameters. <code>0x32</code> <code>CMD_SEND_BINARY_REQ</code> Send an application binary request. <code>0x33</code> <code>CMD_FACTORY_RESET</code> Factory-reset after the required confirmation body. <code>0x34</code> <code>CMD_SEND_PATH_DISCOVERY_REQ</code> Request path discovery. <code>0x36</code> <code>CMD_SET_FLOOD_SCOPE_KEY</code> Select scoped or unscoped flood behavior. <code>0x37</code> <code>CMD_SEND_CONTROL_DATA</code> Send zero-hop control data. <code>0x38</code> <code>CMD_GET_STATS</code> Read core, radio, or packet statistics. <code>0x39</code> <code>CMD_SEND_ANON_REQ</code> Send an anonymous request. <code>0x3A</code> / <code>0x3B</code> <code>CMD_SET_AUTOADD_CONFIG</code> / <code>CMD_GET_AUTOADD_CONFIG</code> Write or read automatic-contact policy. <code>0x3C</code> <code>CMD_GET_ALLOWED_REPEAT_FREQ</code> Read allowed client-repeat frequency ranges. <code>0x3D</code> <code>CMD_SET_PATH_HASH_MODE</code> Set path-hash width mode. <code>0x3E</code> <code>CMD_SEND_CHANNEL_DATA</code> Send a channel binary datagram. <code>0x3F</code> / <code>0x40</code> <code>CMD_SET_DEFAULT_FLOOD_SCOPE</code> / <code>CMD_GET_DEFAULT_FLOOD_SCOPE</code> Write or read the default flood scope. <code>0x41</code> <code>CMD_SEND_RAW_PACKET</code> Queue a fully encoded raw mesh packet. <code>0x42</code> <code>CMD_RUN_CLI_COMMAND</code> Run a local CLI command (protocol v14+). <code>0x4A</code> <code>CMD_EXEC_LOCAL_OTA_CONTROL</code> Run one bounded local TempRadio or OTA command when the Companion includes the OTA CLI. <code>0x4B</code> <code>CMD_BLE_MOTA_SOURCE</code> Query, start, or stop an nRF52 Full Companion's Bluetooth-backed LoRa mOTA source. <code>0x78</code>-<code>0x7F</code> Deprecated hardware-setting aliases Receive-only compatibility for clients shipped before command <code>0x42</code> became the canonical settings path. <p>The sections below detail the most common frames. Refer to the source named above for command bodies that are not expanded here.</p> <p><code>CMD_RUN_CLI_COMMAND</code> is followed by the local CLI text without a terminating NUL. The device returns <code>RESP_CODE_CLI_REPLY</code> (<code>0x1D</code>) followed by the reply text. This is separate from sending a remote on-air CLI command with <code>CMD_SEND_TXT_MSG</code> and <code>TXT_TYPE_CLI_COMMAND</code>. The body must contain at least one byte and must not contain an embedded NUL. An unknown command is returned as the normal CLI reply text <code>Unknown command</code>, not as an error frame. Clients may prefix the CLI text with any two-character correlation tag and <code>|</code> (for example, <code>A7|get radio.rxgain</code>); the reply preserves that prefix.</p> <p>Full Companion clients can send <code>version</code> through this command to receive the untruncated build identity, for example <code>Companion 1.17.1.5-... (protocol 14, build 31-Aug-2026)</code>. This deliberately supplements rather than changes the 20-byte legacy version field in <code>RESP_CODE_DEVICE_INFO</code>, so existing clients keep the same frame layout.</p> <p>Firmware from this fork predating the upstream <code>0x42</code> allocation used <code>0x42</code>-<code>0x49</code> for these eight settings. This firmware accepts those values as deprecated inbound aliases so existing clients continue to work. A one-byte <code>0x42</code> frame is the legacy FEM-gain GET; <code>0x42</code> followed by text is the official <code>CMD_RUN_CLI_COMMAND</code>. New clients should use <code>CMD_RUN_CLI_COMMAND</code> for all of these settings, rather than allocating additional command bytes. For example, send <code>0x42</code> followed by <code>get radio.rxgain</code> or <code>set radio.rxgain on</code>. The reply is <code>RESP_CODE_CLI_REPLY</code> followed by the normal CLI reply text.</p> <p>Two deprecated binary alias blocks remain receive-only for compatibility:</p> Setting Original alias Later fork alias GET body/reply SET body/reply FEM receive gain <code>0x42</code> / <code>0x43</code> <code>0x78</code> / <code>0x79</code> No body; <code>OK, state</code> One byte <code>0</code>/<code>1</code>; <code>OK</code> Radio receive gain <code>0x44</code> / <code>0x45</code> <code>0x7A</code> / <code>0x7B</code> No body; <code>OK, state</code> One byte <code>0</code>/<code>1</code>; <code>OK</code> WiFi power save <code>0x46</code> / <code>0x47</code> <code>0x7C</code> / <code>0x7D</code> No body; <code>OK, mode</code> One mode byte <code>0</code>-<code>2</code>; <code>OK</code> Bluetooth name <code>0x48</code> / <code>0x49</code> <code>0x7E</code> / <code>0x7F</code> No body; <code>OK, custom, name</code> Zero to 31 UTF-8 bytes; <code>OK</code> <p>Each pair lists GET then SET. Here <code>OK</code> is <code>RESP_CODE_OK</code>; the remaining reply bytes have the same meanings as the CLI settings below. A bare <code>0x42</code> is the old FEM GET, while <code>0x42</code> plus at least one text byte is <code>CMD_RUN_CLI_COMMAND</code>. New clients must use the framed CLI form; these aliases exist only so deployed clients do not break after a firmware update.</p> <p>The equivalent framed CLI commands are:</p> Setting Commands Radio receive gain <code>get radio.rxgain</code>; <code>set radio.rxgain on|off</code> FEM receive gain <code>get radio.fem.rxgain</code>; <code>set radio.fem.rxgain on|off</code> WiFi power save <code>get wifi.powersave</code>; <code>set wifi.powersave none|min|max</code> Bluetooth name <code>get bluetooth.name</code>; <code>set bluetooth.name &lt;name|default&gt;</code> <p>The framed form works over the normal binary USB, BLE, or TCP transport and does not need the USB terminal-start token. Unsupported settings return the same explanatory text as the local CLI.</p> <p>WiFi power-save modes are:</p> Value Mode <code>0</code> <code>min</code> - minimum modem sleep <code>1</code> <code>none</code> - no modem sleep <code>2</code> <code>max</code> - maximum modem sleep <p>A Full Companion that runs BLE and infrastructure WiFi simultaneously rejects WiFi mode <code>none</code> because coexistence requires modem sleep. A Full Companion using ESP-NOW as its primary mesh radio also rejects <code>max</code>, because maximum modem sleep can miss broadcasts that the access point cannot buffer. If an older image saved a conflicting value, the effective mode is capped to and reported as <code>min</code>. Device <code>powersaving</code> remains independent.</p> <p>The SenseCAP Indicator Full profiles run exactly one secondary wireless Companion transport per boot. Their active-mode constraints are:</p> Indicator mode Accepted <code>wifi.powersave</code> values LoRa + infrastructure WiFi <code>none</code>, <code>min</code>, <code>max</code> LoRa + BLE <code>min</code>, <code>max</code>; infrastructure WiFi is not started ESP-NOW + infrastructure WiFi <code>none</code>, <code>min</code>; <code>max</code> conflicts with primary ESP-NOW ESP-NOW + BLE <code>min</code>; infrastructure WiFi is not started and primary ESP-NOW remains active <p>The Bluetooth name can be configured over USB, BLE, or TCP. Use <code>set bluetooth.name default</code> to restore <code>MeshCore-&lt;advert name&gt;</code>; an empty CLI value is rejected. (<code>clear</code> is also accepted as an alias for <code>default</code>.) A custom name is limited to 31 valid UTF-8 bytes and takes effect after reboot.</p>"},{"location":"companion_protocol/#bluetooth-lora-mota-source","title":"Bluetooth LoRa mOTA source","text":"<p>Protocol v14 lets a phone control an install-capable Companion's own LoRa OTA session. An nRF52 Full Companion can additionally act as the source for a remote repeater update without a USB computer. The normal Companion service still carries contacts, repeater login, CLI messages, and these two control commands. The separate mOTA service carries only host-folder request/response frames.</p> <p><code>CMD_EXEC_LOCAL_OTA_CONTROL</code> (<code>0x4A</code>) is followed by 1-174 printable ASCII bytes. A Companion built with the OTA CLI accepts only these local command families:</p> <pre><code>tempradio &lt;freq_kHz&gt;,&lt;bw_kHz&gt;,&lt;sf&gt;,&lt;cr&gt;,&lt;minutes&gt;\nnormalradio\nota ...\n</code></pre> <p><code>ota folder ...</code> is deliberately rejected because USB and Bluetooth source ownership must not be changed through the wrong transport. Embedded NUL, CR, LF, other control bytes, non-ASCII bytes, empty commands, and oversized frames return <code>ERR_CODE_ILLEGAL_ARG</code>. A recognized command replies with <code>RESP_CODE_OK</code>, one unsigned reply-length byte, and exactly that many printable result bytes. Shell metacharacters are rejected as well; the text is dispatched only to the in-firmware parser and is never passed to a host shell. Firmware without the OTA CLI feature returns <code>ERR_CODE_UNSUPPORTED_CMD</code>.</p> <p><code>CMD_BLE_MOTA_SOURCE</code> (<code>0x4B</code>) has one action byte:</p> Action Meaning <code>0</code> Read status without changing it. <code>1</code> Attach and enumerate the subscribed Bluetooth host's <code>.mota</code> catalog. <code>2</code> Detach the Bluetooth source. <p>Current firmware returns eleven bytes (legacy protocol-v14 previews returned the seven-byte prefix only):</p> <pre><code>00 action flags offered_le16 advertised_le16 source_packets_sent_le32\n</code></pre> <p>Flag bit <code>0x01</code> means the encrypted GATT channel is connected and Device Request notifications are enabled. Bit <code>0x02</code> means the Bluetooth catalog is attached. Bit <code>0x04</code> means USB or another folder transport currently owns the source slot. Start without a ready subscription, or while another source link owns the slot, returns <code>ERR_CODE_BAD_STATE</code>. A non-nRF52 Full Companion returns <code>ERR_CODE_UNSUPPORTED_CMD</code>. <code>source_packets_sent</code> is a per-attachment count of OTA packets accepted by the Companion's LoRa transmit adapter, including catalog/manifest traffic, data, proofs, and retries. It wraps as an unsigned 32-bit value. Clients should accept the legacy seven-byte response and display the packet counter as unavailable.</p> <p>After a successful start, the device sends the same bounded seeder frames used by <code>motatool serve</code> on Device Request:</p> <pre><code>device -&gt; host: 'M' 'S' op args... xor(op || args)\nhost -&gt; device: 'm' 's' op status payload... xor(all prior bytes)\n</code></pre> <p>Device requests are at most 11 bytes. A source response is at most 197 bytes. The host may split one response across multiple write-with-response operations when the negotiated ATT payload is smaller; it must preserve byte order and must not interleave another response. Bad checksums, partial frames, overflow, unsubscribe, loss of encryption, or disconnect fail closed. The firmware then detaches the catalog and stops advertising its entries. USB and Bluetooth folder sources are mutually exclusive.</p> <p>A Linux reference controller and seeder is provided at <code>tools/ble_mota/ble_mota_seeder.py</code>. It verifies every input with <code>motatool</code> before offering it. A mobile implementation should apply the same complete container verification before serving files.</p>"},{"location":"companion_protocol/#1-app-start","title":"1. App Start","text":"<p>Purpose: Initialize communication with the device. Must be sent first after connection.</p> <p>Command Format:</p> <pre><code>Byte 0: 0x01\nBytes 1-7: Reserved (currently ignored by firmware)\nBytes 8+: Application name (UTF-8, optional)\n</code></pre> <p>Example (hex):</p> <pre><code>01 00 00 00 00 00 00 00 6d 63 63 6c 69\n</code></pre> <p>Response: <code>PACKET_SELF_INFO</code> (0x05)</p>"},{"location":"companion_protocol/#2-device-query","title":"2. Device Query","text":"<p>Purpose: Query device information.</p> <p>Command Format:</p> <pre><code>Byte 0: 0x16\nByte 1: Highest companion protocol version understood by the app\n</code></pre> <p>Example (hex):</p> <pre><code>16 0E\n</code></pre> <p>Response: <code>PACKET_DEVICE_INFO</code> (0x0D) with device information</p>"},{"location":"companion_protocol/#3-get-channel-info","title":"3. Get Channel Info","text":"<p>Purpose: Retrieve information about a specific channel.</p> <p>Command Format:</p> <pre><code>Byte 0: 0x1F\nByte 1: Channel index (0 through max_channels - 1)\n</code></pre> <p>Example (get channel 1):</p> <pre><code>1F 01\n</code></pre> <p>Response: <code>PACKET_CHANNEL_INFO</code> (0x12) with channel details</p>"},{"location":"companion_protocol/#4-set-channel","title":"4. Set Channel","text":"<p>Purpose: Create or update a channel on the device.</p> <p>Command Format:</p> <pre><code>Byte 0: 0x20\nByte 1: Channel index (0 through max_channels - 1)\nBytes 2-33: Channel Name (32 bytes, UTF-8, null-padded)\nBytes 34-49: Secret (16 bytes)\n</code></pre> <p>Total Length: 50 bytes</p> <p>Channel index: - Slot count is build-specific. Read <code>max_channels</code> from byte 3 of   <code>PACKET_DEVICE_INFO</code>; current profiles commonly expose 1, 8, or 40 slots. - No slot number has an intrinsic public/private meaning.</p> <p>Channel Name: - UTF-8 encoded - Maximum 32 bytes - Padded with null bytes (0x00) if shorter</p> <p>Secret Field (16 bytes): - Supply the exact 16-byte channel key. A private channel normally uses a   cryptographically random key; known public and hashtag channels use their   defined or derived key. - An all-zero key is not the public-channel key.</p> <p>Example (create channel \"SMS\" at index 1 with secret):</p> <pre><code>20 01 53 4D 53 00 00 ... (name padded to 32 bytes)\n    [16 bytes of secret]\n</code></pre> <p>Note: The 32-byte secret variant is unsupported and returns <code>PACKET_ERROR</code>.</p> <p>Response: <code>PACKET_OK</code> (0x00) on success, <code>PACKET_ERROR</code> (0x01) on failure</p>"},{"location":"companion_protocol/#5-send-channel-message","title":"5. Send Channel Message","text":"<p>Purpose: Send a text message to a channel.</p> <p>Command Format:</p> <pre><code>Byte 0: 0x03\nByte 1: 0x00\nByte 2: Channel index (0 through max_channels - 1)\nBytes 3-6: Timestamp (32-bit little-endian Unix timestamp, seconds)\nBytes 7+: Message Text (UTF-8, variable length)\n</code></pre> <p>Timestamp: Unix timestamp in seconds (32-bit unsigned integer, little-endian)</p> <p>Example (send \"Hello\" to channel 1 at timestamp 1234567890):</p> <pre><code>03 00 01 D2 02 96 49 48 65 6C 6C 6F\n</code></pre> <p>Response: <code>PACKET_MSG_SENT</code> (0x06) on success</p>"},{"location":"companion_protocol/#6-send-channel-data-datagram","title":"6. Send Channel Data Datagram","text":"<p>Purpose: Send a binary datagram to a channel. Unlike channel text messages, datagrams carry no built-in sender identity and no timestamp - applications needing either must encode them inside the binary payload.</p> <p>Command Format:</p> <pre><code>Byte 0:                         0x3E\nByte 1:                         Channel index (0 through max_channels - 1)\nByte 2:                         Encoded path descriptor (0xFF = flood)\nBytes 3+:                       Encoded path bytes (omitted for 0xFF)\nNext 2 bytes (little-endian):   Data Type (`data_type`, uint16)\nRemaining bytes:                Binary payload (variable length)\n</code></pre> <p>For a direct send, the descriptor's low six bits are the hash count and its high two bits are the hash size minus one. Current mesh packets accept one-, two-, or three-byte hashes; the four-byte code is reserved. The following path therefore occupies <code>hash_count * hash_size</code> bytes; the descriptor itself is not a raw byte count.</p> <p>Example (flood, <code>DATA_TYPE_DEV</code>, payload <code>A1 B2 C3</code>, channel 1):</p> <pre><code>3E 01 FF FF FF A1 B2 C3\n</code></pre> <p>Data Type / Transport Mapping: - <code>0x0000</code> (<code>DATA_TYPE_RESERVED</code>) is invalid and rejected with <code>PACKET_ERROR</code>. - <code>0xFFFF</code> (<code>DATA_TYPE_DEV</code>) is the developer namespace for experimenting and developing apps. - Registered application/community namespaces occupy <code>0x0100</code>-<code>0xFEFF</code>; the remaining nonzero ranges are reserved for internal or development use. See the Registered data_type values table below.</p> <p>Limits: - Maximum payload length is <code>MAX_CHANNEL_DATA_LENGTH = MAX_FRAME_SIZE - 9 = 167</code> bytes. - Larger payloads are rejected with <code>PACKET_ERROR</code> (<code>ERR_CODE_ILLEGAL_ARG</code>).</p> <p>Response: <code>PACKET_OK</code> (0x00) on success, or <code>PACKET_ERROR</code> (0x01) with one of: - <code>ERR_CODE_NOT_FOUND</code> (2) - unknown <code>channel_idx</code> - <code>ERR_CODE_ILLEGAL_ARG</code> (6) - invalid <code>path_len</code>, reserved <code>data_type</code> (<code>0x0000</code>), or payload larger than <code>MAX_CHANNEL_DATA_LENGTH</code> - <code>ERR_CODE_TABLE_FULL</code> (3) - outbound send queue is full; retry later</p> <p>Inbound datagrams are delivered to the host via <code>RESP_CODE_CHANNEL_DATA_RECV</code> (0x1B); see Receive Channel Data Datagram.</p>"},{"location":"companion_protocol/#registered-data_type-values","title":"Registered <code>data_type</code> values","text":"<p><code>data_type</code> is an application identifier, not a payload-format identifier. Each registered value identifies an application that owns its own internal payload schemas. The firmware does not inspect payload contents - <code>data_type</code> is transported opaquely.</p> Value Constant Purpose 0x0000 <code>DATA_TYPE_RESERVED</code> Reserved; invalid on send 0x0001 - 0x00FF - Reserved for internal use 0x0100 - 0xFEFF - Registered application namespaces (see number_allocations.md) 0xFF00 - 0xFFFE - Testing/development; no registration required 0xFFFF <code>DATA_TYPE_DEV</code> Developer/experimental namespace <p>To register a new application, submit a PR adding a row to the table in docs/number_allocations.md. Internal sub-formats within an allocated application ID are owned by that application and are not tracked in MeshCore firmware or this document.</p>"},{"location":"companion_protocol/#receive-channel-data-datagram","title":"Receive Channel Data Datagram","text":"<p>Inbound group datagrams (radio-level <code>PAYLOAD_TYPE_GRP_DATA</code>, 0x06) are forwarded to the host as <code>RESP_CODE_CHANNEL_DATA_RECV</code> notifications.</p> <p>Frame Format (<code>RESP_CODE_CHANNEL_DATA_RECV</code>, 0x1B):</p> <pre><code>Byte 0:                 0x1B (packet type)\nByte 1:                 SNR (signed int8, scaled x4 - divide by 4.0 to recover dB)\nBytes 2-3:              Reserved (clients MUST ignore)\nByte 4:                 Channel index (0 through max_channels - 1)\nByte 5:                 Path Length (actual path length when flooded, otherwise 0xFF for direct)\nBytes 6-7:              Data Type (uint16 little-endian)\nByte 8:                 Data Length\nBytes 9 .. 8+data_len:  Payload\n</code></pre> <p>Path bytes are not forwarded: Only <code>path_len</code> is reported in the receive frame - the path itself is not copied to the host. There are no path bytes between byte 5 and the data_type field at bytes 6-7, regardless of <code>path_len</code>.</p> <p>Path Length semantics differ between send and receive:</p> Direction <code>path_len = 0xFF</code> <code>path_len != 0xFF</code> Send Flood the network Direct route; the encoded path follows (low 6 bits = hash count, top 2 bits + 1 = hash size; on-wire byte count = <code>hash_count x hash_size</code>) Receive Packet arrived via direct route Packet was flooded; this is the encoded <code>pkt-&gt;path_len</code> field as observed (no path bytes follow) <p>In other words, the meaning of <code>0xFF</code> is inverted between the two directions, and on receive the field carries metadata only - never a routable path. <code>path_len</code> is an encoded byte (see <code>Packet::isValidPathLen</code> / <code>Packet::writePath</code> in <code>src/Packet.cpp</code>), not a raw byte count.</p> <p>Note: The device may also emit <code>PACKET_MESSAGES_WAITING</code> (0x83) to notify the host that datagrams are queued; poll with <code>CMD_SYNC_NEXT_MESSAGE</code> (0x0A) to retrieve them.</p> <p>Parsing Pseudocode:</p> <pre><code>def parse_channel_data_recv(data):\n    if len(data) &lt; 9:\n        return None\n    snr_byte = data[1]\n    snr = (snr_byte if snr_byte &lt; 128 else snr_byte - 256) / 4.0\n    channel_idx = data[4]\n    path_len = data[5]\n    data_type = int.from_bytes(data[6:8], 'little')\n    data_len = data[8]\n    if 9 + data_len &gt; len(data):\n        return None\n    payload = data[9:9 + data_len]\n    return {\n        'snr': snr,\n        'channel_idx': channel_idx,\n        'path_len': path_len,\n        'data_type': data_type,\n        'payload': bytes(payload),\n    }\n</code></pre>"},{"location":"companion_protocol/#7-get-message","title":"7. Get Message","text":"<p>Purpose: Request the next queued message from the device.</p> <p>Command Format:</p> <pre><code>Byte 0: 0x0A\n</code></pre> <p>Example (hex):</p> <pre><code>0A\n</code></pre> <p>Response:  - <code>PACKET_CHANNEL_MSG_RECV</code> (0x08) or <code>PACKET_CHANNEL_MSG_RECV_V3</code> (0x11) for channel messages - <code>PACKET_CONTACT_MSG_RECV</code> (0x07) or <code>PACKET_CONTACT_MSG_RECV_V3</code> (0x10) for contact messages - <code>PACKET_CHANNEL_DATA_RECV</code> (0x1B) for channel data datagrams - <code>PACKET_NO_MORE_MSGS</code> (0x0A) if no messages available</p> <p>Note: Poll this command periodically to retrieve queued messages. The device may also send <code>PACKET_MESSAGES_WAITING</code> (0x83) as a notification when messages are available.</p>"},{"location":"companion_protocol/#8-get-battery-and-storage","title":"8. Get Battery and Storage","text":"<p>Purpose: Query device battery voltage and storage usage.</p> <p>Command Format:</p> <pre><code>Byte 0: 0x14\n</code></pre> <p>Example (hex):</p> <pre><code>14\n</code></pre> <p>Response: <code>PACKET_BATTERY</code> (0x0C) with battery millivolts and storage information</p>"},{"location":"companion_protocol/#channel-management","title":"Channel Management","text":""},{"location":"companion_protocol/#channel-types","title":"Channel Types","text":"<ol> <li>Public Channel<ul> <li>Uses a publicly known 16-byte key: <code>8b3387e9c5cdea6ac9e5edbaa115cd72</code></li> <li>Anyone can join this channel, messages should be considered public</li> <li>Used as the default public group chat</li> </ul> </li> <li>Hashtag Channels<ul> <li>Uses a secret key derived from the channel name</li> <li>It is the first 16 bytes of <code>sha256(\"#test\")</code></li> <li>For example hashtag channel <code>#test</code> has the key: <code>9cd8fcf22a47333b591d96a2b848b73f</code></li> <li>Traffic is encrypted on air, but anyone who knows or guesses the channel   name can derive the key. Hashtag channels should not be treated as private.</li> <li>Used as a topic based public group chat, separate from the default public channel</li> </ul> </li> <li>Private Channels<ul> <li>Uses a randomly generated 16-byte secret key</li> <li>Messages should be considered private between those that know the secret</li> <li>Users should keep the key secret, and only share with those you want to communicate with</li> <li>Used as a secure private group chat</li> </ul> </li> </ol>"},{"location":"companion_protocol/#channel-lifecycle","title":"Channel Lifecycle","text":"<ol> <li>Set Channel:<ul> <li>Read <code>max_channels</code> from device info, fetch those slots, and choose an   unused slot (normally an empty name and zeroed key)</li> <li>Generate or provide a 16-byte secret</li> <li>Send <code>CMD_SET_CHANNEL</code> with name and a 16-byte secret</li> </ul> </li> <li>Get Channel:<ul> <li>Send <code>CMD_GET_CHANNEL</code> with channel index</li> <li>Parse <code>RESP_CODE_CHANNEL_INFO</code> response</li> </ul> </li> <li>Delete Channel:<ul> <li>Send <code>CMD_SET_CHANNEL</code> with empty name and all-zero secret</li> <li>Or overwrite with a new channel</li> </ul> </li> </ol>"},{"location":"companion_protocol/#message-handling","title":"Message Handling","text":""},{"location":"companion_protocol/#receiving-messages","title":"Receiving Messages","text":"<p>Messages are received via the TX characteristic (notifications). The device sends:</p> <ol> <li>Channel Messages:</li> <li><code>PACKET_CHANNEL_MSG_RECV</code> (0x08) - Standard format</li> <li> <p><code>PACKET_CHANNEL_MSG_RECV_V3</code> (0x11) - Version 3 with SNR</p> </li> <li> <p>Contact Messages:</p> </li> <li><code>PACKET_CONTACT_MSG_RECV</code> (0x07) - Standard format</li> <li> <p><code>PACKET_CONTACT_MSG_RECV_V3</code> (0x10) - Version 3 with SNR</p> </li> <li> <p>Notifications:</p> </li> <li><code>PACKET_MESSAGES_WAITING</code> (0x83) - Indicates messages are queued</li> </ol>"},{"location":"companion_protocol/#contact-message-format","title":"Contact Message Format","text":"<p>Standard Format (<code>PACKET_CONTACT_MSG_RECV</code>, 0x07):</p> <pre><code>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</code></pre> <p>V3 Format (<code>PACKET_CONTACT_MSG_RECV_V3</code>, 0x10):</p> <pre><code>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</code></pre> <p>Parsing Pseudocode:</p> <pre><code>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 &lt; 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</code></pre>"},{"location":"companion_protocol/#channel-message-format","title":"Channel Message Format","text":"<p>Standard Format (<code>PACKET_CHANNEL_MSG_RECV</code>, 0x08):</p> <pre><code>Byte 0: 0x08 (packet type)\nByte 1: Channel index (0 through max_channels - 1)\nByte 2: Path Length\nByte 3: Text Type\nBytes 4-7: Timestamp (32-bit little-endian)\nBytes 8+: Message Text (UTF-8)\n</code></pre> <p>V3 Format (<code>PACKET_CHANNEL_MSG_RECV_V3</code>, 0x11):</p> <pre><code>Byte 0: 0x11 (packet type)\nByte 1: SNR (signed byte, multiplied by 4)\nBytes 2-3: Reserved\nByte 4: Channel index (0 through max_channels - 1)\nByte 5: Path Length\nByte 6: Text Type\nBytes 7-10: Timestamp (32-bit little-endian)\nBytes 11+: Message Text (UTF-8)\n</code></pre> <p>Parsing Pseudocode:</p> <pre><code>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 &lt; 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</code></pre>"},{"location":"companion_protocol/#sending-messages","title":"Sending Messages","text":"<p>Use the <code>SEND_CHANNEL_MESSAGE</code> command (see Commands).</p> <p>Important:  - The shared text envelope permits up to 160 UTF-8 bytes. For channel text,   firmware prepends <code>&lt;sender name&gt;:</code> inside that envelope, so the available   message body is <code>160 - prefix_bytes</code> and varies with the configured name. - Count encoded UTF-8 bytes, not Unicode characters. Split a longer message at   valid UTF-8 boundaries. - Include a chunk indicator (e.g., \"[1/3] message text\")</p>"},{"location":"companion_protocol/#response-parsing","title":"Response Parsing","text":""},{"location":"companion_protocol/#terminology","title":"Terminology","text":"<p>This document uses a spec-level naming convention (<code>PACKET_*</code>) for bytes the firmware sends back to the host. In the firmware source these same values are split across two <code>#define</code> families by purpose:</p> <ul> <li><code>RESP_CODE_*</code> - direct replies to a command (e.g. <code>RESP_CODE_CHANNEL_DATA_RECV</code> = <code>PACKET_CHANNEL_DATA_RECV</code> = 0x1B).</li> <li><code>PUSH_CODE_*</code> - asynchronous notifications not tied to a specific command (e.g. <code>PUSH_CODE_MSG_WAITING</code> = <code>PACKET_MESSAGES_WAITING</code> = 0x83).</li> </ul> <p>Byte values are authoritative; names are aliases. When reading firmware source, <code>RESP_CODE_X</code> / <code>PUSH_CODE_X</code> correspond to this doc's <code>PACKET_X</code> of the same numeric value.</p>"},{"location":"companion_protocol/#response-types","title":"Response types","text":"Value Firmware name Description <code>0x00</code> <code>RESP_CODE_OK</code> Command succeeded. <code>0x01</code> <code>RESP_CODE_ERR</code> Command failed; byte 1 is the error code. <code>0x02</code> <code>RESP_CODE_CONTACTS_START</code> Contact enumeration started. <code>0x03</code> <code>RESP_CODE_CONTACT</code> One contact record. <code>0x04</code> <code>RESP_CODE_END_OF_CONTACTS</code> Contact enumeration ended. <code>0x05</code> <code>RESP_CODE_SELF_INFO</code> Device self-information. <code>0x06</code> <code>RESP_CODE_SENT</code> Send accepted, with route/tag/timeout data. <code>0x07</code> / <code>0x08</code> <code>RESP_CODE_CONTACT_MSG_RECV</code> / <code>RESP_CODE_CHANNEL_MSG_RECV</code> Queued legacy-format message. <code>0x09</code> <code>RESP_CODE_CURR_TIME</code> Current device time. <code>0x0A</code> <code>RESP_CODE_NO_MORE_MESSAGES</code> Offline queue is empty. <code>0x0B</code> <code>RESP_CODE_EXPORT_CONTACT</code> Exported contact bytes. <code>0x0C</code> <code>RESP_CODE_BATT_AND_STORAGE</code> Battery and storage values. <code>0x0D</code> <code>RESP_CODE_DEVICE_INFO</code> Protocol and build information. <code>0x0E</code> <code>RESP_CODE_PRIVATE_KEY</code> Exported identity key, when enabled. <code>0x0F</code> <code>RESP_CODE_DISABLED</code> Requested sensitive feature is disabled. <code>0x10</code> / <code>0x11</code> <code>RESP_CODE_CONTACT_MSG_RECV_V3</code> / <code>RESP_CODE_CHANNEL_MSG_RECV_V3</code> Queued message with SNR fields. <code>0x12</code> <code>RESP_CODE_CHANNEL_INFO</code> Channel slot information. <code>0x13</code> / <code>0x14</code> <code>RESP_CODE_SIGN_START</code> / <code>RESP_CODE_SIGNATURE</code> Signing capacity or completed signature. <code>0x15</code> <code>RESP_CODE_CUSTOM_VARS</code> Custom-variable data. <code>0x16</code> <code>RESP_CODE_ADVERT_PATH</code> Cached advertisement path. <code>0x17</code> <code>RESP_CODE_TUNING_PARAMS</code> Tuning parameters. <code>0x18</code> <code>RESP_CODE_STATS</code> Requested statistics subtype. <code>0x19</code> <code>RESP_CODE_AUTOADD_CONFIG</code> Automatic-contact policy. <code>0x1A</code> <code>RESP_ALLOWED_REPEAT_FREQ</code> Allowed repeat-frequency ranges. <code>0x1B</code> <code>RESP_CODE_CHANNEL_DATA_RECV</code> Queued channel datagram. <code>0x1C</code> <code>RESP_CODE_DEFAULT_FLOOD_SCOPE</code> Default flood-scope data. <code>0x1D</code> <code>RESP_CODE_CLI_REPLY</code> Text returned by <code>CMD_RUN_CLI_COMMAND</code>."},{"location":"companion_protocol/#asynchronous-push-types","title":"Asynchronous push types","text":"Value Firmware name Description <code>0x80</code> <code>PUSH_CODE_ADVERT</code> Advertisement received. <code>0x81</code> <code>PUSH_CODE_PATH_UPDATED</code> A contact path changed. <code>0x82</code> <code>PUSH_CODE_SEND_CONFIRMED</code> A sent message was acknowledged. <code>0x83</code> <code>PUSH_CODE_MSG_WAITING</code> One or more offline frames are waiting. <code>0x84</code> <code>PUSH_CODE_RAW_DATA</code> Raw application data received. <code>0x85</code> / <code>0x86</code> <code>PUSH_CODE_LOGIN_SUCCESS</code> / <code>PUSH_CODE_LOGIN_FAIL</code> Server login result. <code>0x87</code> <code>PUSH_CODE_STATUS_RESPONSE</code> Server status response. <code>0x88</code> <code>PUSH_CODE_LOG_RX_DATA</code> Radio receive log data. <code>0x89</code> <code>PUSH_CODE_TRACE_DATA</code> Completed trace data. <code>0x8A</code> <code>PUSH_CODE_NEW_ADVERT</code> Newly stored contact advertisement. <code>0x8B</code> <code>PUSH_CODE_TELEMETRY_RESPONSE</code> Telemetry response. <code>0x8C</code> <code>PUSH_CODE_BINARY_RESPONSE</code> Binary request response. <code>0x8D</code> <code>PUSH_CODE_PATH_DISCOVERY_RESPONSE</code> Path-discovery response. <code>0x8E</code> <code>PUSH_CODE_CONTROL_DATA</code> Control/discovery data. <code>0x8F</code> <code>PUSH_CODE_CONTACT_DELETED</code> Oldest contact was deleted while making room. <code>0x90</code> <code>PUSH_CODE_CONTACTS_FULL</code> Contact storage is full."},{"location":"companion_protocol/#parsing-responses","title":"Parsing Responses","text":"<p>PACKET_OK (0x00):</p> <pre><code>Byte 0: 0x00\nBytes 1-4: Optional value (32-bit little-endian integer)\n</code></pre> <p>PACKET_ERROR (0x01):</p> <pre><code>Byte 0: 0x01\nByte 1: Error code (optional)\n</code></pre> <p>PACKET_CHANNEL_INFO (0x12):</p> <pre><code>Byte 0: 0x12\nByte 1: Channel Index\nBytes 2-33: Channel Name (32 bytes, null-terminated)\nBytes 34-49: Secret (16 bytes)\n</code></pre> <p>Note: The device returns the 16-byte channel secret in this response.</p> <p>PACKET_DEVICE_INFO (0x0D):</p> <pre><code>Byte 0: 0x0D\nByte 1: Firmware Version (uint8)\nBytes 2+: Variable length based on firmware version\n\nFor firmware version &gt;= 3:\nByte 2: Max Contacts Raw (uint8, actual = value * 2)\nByte 3: Max Channels (uint8)\nBytes 4-7: Active BLE PIN (32-bit little-endian; includes a generated session PIN)\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</code></pre> <p>Parsing Pseudocode:</p> <pre><code>def parse_device_info(data):\n    if len(data) &lt; 2:\n        return None\n\n    fw_ver = data[1]\n    info = {'fw_ver': fw_ver}\n\n    if fw_ver &gt;= 3 and len(data) &gt;= 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    if fw_ver &gt;= 9 and len(data) &gt;= 81:\n        info['client_repeat'] = data[80] != 0\n    if fw_ver &gt;= 10 and len(data) &gt;= 82:\n        info['path_hash_mode'] = data[81]\n\n    return info\n</code></pre> <p>PACKET_BATTERY (0x0C):</p> <pre><code>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</code></pre> <p>Parsing Pseudocode:</p> <pre><code>def parse_battery(data):\n    if len(data) &lt; 3:\n        return None\n\n    mv = int.from_bytes(data[1:3], 'little')\n    info = {'battery_mv': mv}\n\n    if len(data) &gt;= 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</code></pre> <p>PACKET_SELF_INFO (0x05):</p> <pre><code>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</code></pre> <p>Parsing Pseudocode:</p> <pre><code>def parse_self_info(data):\n    if len(data) &lt; 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 &gt;&gt; 4) &amp; 0b11\n    info['telemetry_mode_loc'] = (telemetry_mode &gt;&gt; 2) &amp; 0b11\n    info['telemetry_mode_base'] = telemetry_mode &amp; 0b11\n    info['manual_add_contacts'] = data[offset + 3] &gt; 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 &lt; len(data):\n        name_bytes = data[offset:]\n        info['name'] = name_bytes.decode('utf-8').rstrip('\\x00').strip()\n\n    return info\n</code></pre> <p>PACKET_MSG_SENT (0x06):</p> <pre><code>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</code></pre> <p>PACKET_SEND_CONFIRMED (0x82):</p> <pre><code>Byte 0: 0x82\nBytes 1-4: ACK code (32-bit little-endian)\nBytes 5-8: Round-trip time (32-bit little-endian, milliseconds)\n</code></pre>"},{"location":"companion_protocol/#error-codes","title":"Error Codes","text":"<p><code>PACKET_ERROR</code> (0x01) carries a single-byte error code in byte 1. Values match the <code>ERR_CODE_*</code> constants defined in <code>examples/companion_radio/MyMesh.cpp</code>:</p> Code Constant (firmware) Description 1 <code>ERR_CODE_UNSUPPORTED_CMD</code> Unknown or unsupported command byte / sub-command 2 <code>ERR_CODE_NOT_FOUND</code> Target not found (channel, contact, message, etc.) 3 <code>ERR_CODE_TABLE_FULL</code> Internal queue or table is full - retry later 4 <code>ERR_CODE_BAD_STATE</code> Operation not valid in current device state (e.g. iterator already running) 5 <code>ERR_CODE_FILE_IO_ERROR</code> Filesystem or storage I/O failure 6 <code>ERR_CODE_ILLEGAL_ARG</code> Invalid argument (bad length, out-of-range value, reserved field, etc.) <p>Note: Error codes may vary by firmware version. Always check byte 1 of <code>PACKET_ERROR</code> response, and treat unknown codes as generic errors.</p>"},{"location":"companion_protocol/#frame-handling","title":"Frame Handling","text":"<p>BLE implementations enqueue and deliver one protocol frame per BLE write/notification at the firmware layer.</p> <ul> <li>Apps should treat each characteristic write/notification as exactly one companion protocol frame</li> <li>Apps should still validate frame lengths before parsing</li> <li>Future transports or firmware revisions may differ, so avoid assuming fixed payload sizes for variable-length responses</li> </ul>"},{"location":"companion_protocol/#response-handling","title":"Response Handling","text":"<ol> <li>Command-Response Pattern:</li> <li>Send command via RX characteristic</li> <li>Wait for response via TX characteristic (notification)</li> <li>Match the response by the expected response type; frames do not carry a      general command sequence number</li> <li>Handle timeout (typically 5 seconds)</li> <li> <p>Use command queue to prevent concurrent commands</p> </li> <li> <p>Asynchronous Messages:</p> </li> <li>Device may send messages at any time via TX characteristic</li> <li>Handle <code>PACKET_MESSAGES_WAITING</code> (0x83) by polling <code>GET_MESSAGE</code> command</li> <li>Parse incoming messages and route to appropriate handlers</li> <li> <p>Validate frame length before decoding</p> </li> <li> <p>Response Matching:</p> </li> <li> <p>Match responses to commands by expected packet type:</p> <ul> <li><code>APP_START</code> -&gt; <code>PACKET_SELF_INFO</code></li> <li><code>DEVICE_QUERY</code> -&gt; <code>PACKET_DEVICE_INFO</code></li> <li><code>GET_CHANNEL</code> -&gt; <code>PACKET_CHANNEL_INFO</code></li> <li><code>SET_CHANNEL</code> -&gt; <code>PACKET_OK</code> or <code>PACKET_ERROR</code></li> <li><code>SEND_CHANNEL_MESSAGE</code> -&gt; <code>PACKET_MSG_SENT</code></li> <li><code>GET_MESSAGE</code> -&gt; <code>PACKET_CHANNEL_MSG_RECV</code>, <code>PACKET_CONTACT_MSG_RECV</code>, <code>PACKET_CHANNEL_DATA_RECV</code>, or <code>PACKET_NO_MORE_MSGS</code></li> <li><code>SEND_CHANNEL_DATA</code> -&gt; <code>PACKET_OK</code> or <code>PACKET_ERROR</code></li> <li><code>GET_BATTERY</code> -&gt; <code>PACKET_BATTERY</code></li> </ul> </li> <li> <p>Timeout Handling:</p> </li> <li>Default timeout: 5 seconds per command</li> <li>On timeout: Log error, clear current command, proceed to next in queue</li> <li>Some commands may take longer (e.g., <code>SET_CHANNEL</code> may need 1-2 seconds)</li> <li> <p>Consider longer timeout for channel operations</p> </li> <li> <p>Error Recovery:</p> </li> <li>On <code>PACKET_ERROR</code>: Log error code, clear current command</li> <li>On connection loss: Clear command queue, attempt reconnection</li> <li>On invalid response: Log warning, clear current command, proceed</li> </ol>"},{"location":"companion_protocol/#example-implementation-flow","title":"Example Implementation Flow","text":""},{"location":"companion_protocol/#initialization","title":"Initialization","text":"<pre><code># 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</code></pre>"},{"location":"companion_protocol/#creating-a-private-channel","title":"Creating a Private Channel","text":"<pre><code># 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 = choose_unused_slot(max_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</code></pre>"},{"location":"companion_protocol/#sending-a-message","title":"Sending a Message","text":"<pre><code># 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</code></pre>"},{"location":"companion_protocol/#receiving-messages_1","title":"Receiving Messages","text":"<pre><code>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</code></pre>"},{"location":"companion_protocol/#best-practices","title":"Best Practices","text":"<ol> <li>Connection Management:</li> <li>Implement auto-reconnect with exponential backoff</li> <li>Handle disconnections gracefully</li> <li> <p>Store last connected device address for quick reconnection</p> </li> <li> <p>Secret Management:</p> </li> <li>Always use cryptographically secure random number generators</li> <li>Store secrets securely (encrypted storage)</li> <li> <p>Never log or transmit secrets in plain text</p> </li> <li> <p>Message Handling:</p> </li> <li>Send <code>CMD_SYNC_NEXT_MESSAGE</code> when <code>PUSH_CODE_MSG_WAITING</code> is received</li> <li> <p>Implement message deduplication to avoid displaying the same message twice</p> </li> <li> <p>Channel Management:</p> <ul> <li>Fetch all channel slots even if you encounter an empty slot</li> <li>Ideally save new channels into the first empty slot</li> </ul> </li> <li> <p>Error Handling:</p> </li> <li>Implement timeouts for all commands (typically 5 seconds)</li> <li>Handle <code>RESP_CODE_ERR</code> responses appropriately</li> </ol>"},{"location":"companion_protocol/#troubleshooting","title":"Troubleshooting","text":""},{"location":"companion_protocol/#connection-issues","title":"Connection Issues","text":"<ul> <li>Device not found: Ensure device is powered on and advertising</li> <li>Connection timeout: Check Bluetooth permissions and device proximity</li> <li>GATT errors: Ensure proper service/characteristic discovery</li> </ul>"},{"location":"companion_protocol/#command-issues","title":"Command Issues","text":"<ul> <li>No response: Verify notifications are enabled, check connection state</li> <li>Error responses: Verify command format and check error code</li> <li>Timeout: Increase timeout value or try again</li> </ul>"},{"location":"companion_protocol/#message-issues","title":"Message Issues","text":"<ul> <li>Messages not received: Poll <code>GET_MESSAGE</code> command periodically</li> <li>Duplicate messages: Implement message deduplication using timestamp/content as a unique id</li> <li>Message truncation: Send long messages as separate shorter messages</li> </ul>"},{"location":"companion_radio_full/","title":"Full Companion","text":"<p><code>companion_radio_full</code> combines every qualified Companion transport for its platform into one artifact and acts as a host-backed LoRa mOTA source for updating other nodes. Most targets can run those transports simultaneously; the SenseCAP Indicator exception selects one secondary wireless transport per boot as described below.</p> <p>The full Companion is deliberately not a LoRa OTA destination: it has no firmware staging store, refuses <code>ota install</code>, and never advertises its own firmware as an mOTA image.</p> Capability ESP32 full nRF52 full USB Binary Companion Yes Yes BLE Binary Companion Yes Yes USB ASCII terminal Yes Yes Dedicated USB plaintext logging No - shares the one USB TTY Yes Host-backed LoRa mOTA source WiFi TCP 5001 Exclusive USB mode or encrypted BLE WiFi Companion/WebConfig Yes No - nRF52840 has no WiFi Hardware serial Companion On targets with assigned serial pins On targets with assigned serial pins Ethernet Companion On targets with an Ethernet module On RAK4631 with RAK13800 LoRa self-update No No"},{"location":"companion_radio_full/#sensecap-indicator-transport-and-rendering-exception","title":"SenseCAP Indicator transport and rendering exception","text":"<p>Both SenseCAP Indicator Full layouts keep USB available and start exactly one secondary wireless Companion transport per boot: BLE or infrastructure WiFi. The saved <code>companion.transport</code> selection takes effect after reboot. BLE mode does not start infrastructure WiFi, WebConfig, MQTT, TCP Companion, or network OTA services. WiFi mode never initializes BLE and releases its controller and host memory. LoRa remains the primary radio on the LoRa layout. ESP-NOW remains the primary mesh radio in both ESP-NOW modes, including BLE mode; only the infrastructure-WiFi services are omitted.</p> <p>The requested 4-bit internal render profiles are:</p> Primary radio Secondary Companion transport Canvas LoRa Infrastructure WiFi Native 480x480 LoRa BLE Native 480x480 ESP-NOW Infrastructure WiFi Native 480x480 ESP-NOW BLE 320x320, scaled 1.5x to the 480x480 panel <p>All four modes retain the same 160x160 logical UI. If a contiguous native DMA-capable block is unavailable, startup keeps the device usable with the 320x320 emergency fallback and reports the canvas actually retained. Such a fallback is not a successful native-480 validation result.</p>"},{"location":"companion_radio_full/#build-and-install","title":"Build and install","text":"<p>The target is synthesized by <code>build.sh</code> only for an exact board recipe that has passed the combined-transport size check:</p> <ul> <li>The normal automatic path requires matching WiFi, USB, and BLE recipes on   ESP32, or matching USB and BLE recipes on nRF52.</li> <li>A measured qualification list also promotes an exact BLE recipe when the   same board can safely add its platform's remaining transports. It never   substitutes the pin map or peripherals from another board.</li> </ul> <p>The measured ESP32 additions are M5Stack Unit C6L; XIAO C6/S3, Meshimi, WHY2025 Badge, LilyGo T-LoRa C6, T3S3 SX1262/SX1276, T-Deck, TETH Elite, classic T-Beam SX1262/SX1276, and T-Beam S3 Supreme; Heltec Wireless Tracker, Wireless Paper, E213, E290, T190, CT62, and V4 expansion-kit TFT; Generic ESP-NOW; SenseCAP Indicator ESP-NOW/LoRa; Ebyte EoRa-S3; and Meshadventurer SX1262/SX1268. The measured nRF52 additions are GAT562 Mesh Watch13, LilyGo T-Echo Lite, LilyGo T-Impulse Plus, and Wio Tracker L1 E-Ink. Their old transport-specific names remain available for explicit compatibility builds, but the Full image is the canonical release artifact.</p> <p>Every ESP32 Full image includes ordinary WiFi Companion, WebConfig, and the TCP mOTA services, even when its historical build base was USB- or BLE-only. On <code>Generic_ESPNOW</code> and <code>SenseCapIndicator-ESPNow</code>, ESP-NOW is also the primary mesh radio and shares the same 2.4 GHz hardware. Those two Full images retain B/G/N for ordinary clients alongside ESP-NOW LR. Their ESP-NOW mesh, setup AP, and infrastructure connection all use one persisted channel, which defaults to 1. Configure the router's 2.4 GHz radio and every other primary ESP-NOW node for that same fixed channel. Turning Companion WiFi off stops its TCP/AP services but deliberately leaves the ESP-NOW mesh radio running on the selected channel.</p> <p>Every ESP32 Full Companion with a station connection synchronizes its UTC clock from NTP after boot and explicitly refreshes it every 24 hours. The common WiFi path owns this for non-MQTT and runtime-unconfigured nodes; a configured MQTT bridge owns the same boot-and-daily schedule. Successful sync updates an attached hardware RTC as well as the ESP32 clock and suppresses LoRa clock fallback for that boot. Reconnecting WiFi preserves the existing daily deadline. A timeout leaves the existing clock and fallback intact and retries without blocking radio work.</p> <p>Inspect or change the shared channel from the Full Companion text terminal:</p> <pre><code>get espnow.channel\nset espnow.channel 6\nreboot\n</code></pre> <p>The accepted range is 1 through 13; use only a channel permitted in your region and supported by the router. The setter persists the selection, but the running radio stays on its current channel until reboot. Coordinate the change across every primary ESP-NOW node and the router before rebooting, or the node will lose one or both links. This primary-radio setting is not <code>bridge.channel</code>; that command belongs to the separate ESP-NOW bridge feature. To attach a LoRa-primary <code>*_repeater_bridge_espnow</code> gateway to these nodes, match its <code>bridge.channel</code> and select <code>set bridge.format raw</code>; the bridge's backward-compatible default is the distinct wrapped format. WiFi power saving cannot put infrastructure WiFi and ESP-NOW on different channels. On these two primary-ESP-NOW Full targets, <code>max</code> is unavailable because maximum modem sleep can make the station miss ESP-NOW broadcasts; use <code>min</code> for WiFi/BLE/ESP-NOW coexistence. The firmware also holds the ESP-IDF RF wake reference for the primary mesh radio, so the ESP-NOW receiver remains continuous even though the reported coexistence setting is <code>min</code>.</p> <p>List the available targets:</p> <pre><code>bash build.sh list | grep companion_radio_full\n</code></pre> <p>Build by using one exact listed name:</p> <pre><code>bash build.sh build-firmware heltec_v4_r8_companion_radio_full \\\n  --firmware-version v1.17.0\n\nbash build.sh build-firmware RAK_4631_companion_radio_full \\\n  --firmware-version v1.17.0\n</code></pre> <p>To build every canonical full Companion target, select the corresponding interactive menu item or run:</p> <pre><code>bash build.sh build-full-companion-firmwares \\\n  --firmware-version v1.17.0\n</code></pre> <p>Canonical Companion bulk builds also omit legacy <code>_ps</code> and <code>_femoff</code> aliases. Power saving and controllable FEM receive gain are persisted runtime settings; the old names remain available through an explicit <code>build-firmware</code> command for compatibility. Full Companion replaces separate USB, BLE, ordinary WiFi, hardware-serial, Ethernet Companion, Terminal Chat, and USB-only packet-logging release artifacts whenever the exact board supports those combined transports. Direct builds of the legacy targets remain available. RAK4631 repeater and room server Ethernet builds remain separate because they are different standalone roles, not Companion transports. nRF52 separates framed traffic and logs; ESP32 makes those modes mutually exclusive on its one USB TTY. In WebConfig, use the FEM RX boost switch. From the text terminal (USB, or TCP 5002 on ESP32), use:</p> <pre><code>get radio.rxgain\nset radio.rxgain off\nset radio.rxgain on\nget radio.fem.rxgain\nset radio.fem.rxgain off\nset radio.fem.rxgain on\nget radio.fem.txgain\nset radio.fem.txgain off\nset radio.fem.txgain on\n</code></pre> <p><code>radio.rxgain</code> controls the radio chip's boosted receive-gain mode; the FEM commands control the external receive and transmit paths. The selected states are applied immediately and retained after reboot. FEM TX gain is reported as unsupported on boards without software-selectable PA gain.</p> <p>SSD1306 display builds also persist a runtime orientation. This replaces the separate rotated Full Companion release image:</p> <pre><code>get display.rotation\nset display.rotation 90\nset display.rotation 180\nset display.rotation 270\nset display.rotation 0\n</code></pre> <p><code>0</code> resets the screen to that board's compiled default orientation.</p> <p>Heltec E290 and T190 now use their Full Companion artifacts for simultaneous USB, BLE, and WiFi. Their older <code>usb_ble</code>, USB-only, and BLE-only names remain available only as explicit compatibility builds.</p> <p>Heltec V3 and base OLED V4 Full Companion also include the former direct WiFi MQTT Companion capability. Configure and enable MQTT at runtime through WebConfig; the canonical release therefore publishes the Full image instead of a second <code>companion_radio_wifi_mqtt</code> image. V4 TFT and expansion-kit layouts remain separate hardware images because their display and I2C wiring differs.</p> <p>Device power saving is separate from LoRa RXPS. It can be changed in WebConfig with the Device power saving switch or from the text terminal:</p> <pre><code>powersaving\npowersaving on\npowersaving off\n</code></pre> <p>On ESP32, WiFi modem power saving is a third independent setting. Select it in the WebConfig WiFi card, or use the Full Companion text terminal:</p> <pre><code>get wifi.ssid\nget wifi.status\nget wifi.powersave\nget webui\nset wifi.ssid MyNetwork\nset wifi.pwd my-password\nset wifi.powersave min\nset wifi.powersave max\nstart webconfig\nstop webconfig\n</code></pre> <p>Full Companion does not expose the repeater/room-server browser CLI tab, so <code>get/set wifi.cli</code> explicitly report that the browser terminal is unavailable. Its complete Companion text terminal remains available over USB and TCP port 5002; this does not reduce that command surface.</p> <p>On the two primary-ESP-NOW Full targets, the same terminal also provides <code>get espnow.channel</code> and <code>set espnow.channel &lt;1-13&gt;</code>. A channel change is persisted and requires a reboot, unlike a WiFi power-save change.</p> <p>SSID and password writes return their reply first, then restart the Companion WiFi station with the saved credentials. A TCP terminal therefore disconnects shortly after either write; reconnect to the IP reported by the new network. The password is write-only and is masked while it is entered over USB. It may be empty for an open network, an ordinary passphrase of up to 63 characters, or an exact 64-character hexadecimal WPA/WPA2 PSK. Other 64-character values and all longer values are rejected.</p> <p>The normal binary Companion connection can also read or write this setting over USB, BLE, or TCP port 5000 without entering terminal mode. The mode values are <code>0</code> for <code>min</code>, <code>1</code> for <code>none</code>, and <code>2</code> for <code>max</code>; see the Companion protocol. A Full Companion that runs WiFi and BLE simultaneously rejects <code>none</code> because coexistence requires modem sleep. A primary-ESP-NOW Full target also rejects <code>max</code>; unlike infrastructure traffic, peer ESP-NOW broadcasts cannot be buffered by the access point while the station sleeps. If an older image saved a conflicting value, firmware applies and reports <code>min</code> instead. The SenseCAP Indicator uses the active-mode constraints in the exception above: LoRa + WiFi accepts all three values, ESP-NOW + WiFi accepts <code>none|min</code>, LoRa + BLE accepts <code>min|max</code> for the inactive WiFi setting, and ESP-NOW + BLE requires <code>min</code>. Fresh Cascade builds select <code>min</code>, and an existing valid saved selection takes precedence.</p> <p>On radios with RX duty-cycle support, WebConfig and the text terminal also expose the persisted RXPS setting:</p> <pre><code>get radio.rxps\nset radio.rxps off\nset radio.rxps on\nset radio.rxps level 8 preamble 16\nset radio.rxps 65625 60000\n</code></pre> <p>Fresh Cascade-profile Full Companion builds start with RXPS on at level 8 and a 16-symbol preamble. Changing it takes effect immediately and remains selected after reboot.</p> <p>Companion firmware defaults device power saving to on. Version 1.17.1.2 also turns it on once when upgrading an older Companion preference file, including one written by the short-lived default-off regression. After that one-time migration, an explicit <code>powersaving off</code> selection remains persistent.</p> <p>On ESP32, enabling it lowers the CPU clock to 80 MHz, enables idle yielding, and enables the configured GPS duty cycle. Disabling it restores the normal CPU clock and keeps GPS awake. Active Full Companion transports remain available in both states; on the SenseCAP Indicator this means USB plus the selected BLE or infrastructure-WiFi secondary transport. WiFi modem sleep stays enabled when BLE and the ESP32 WiFi radio are active together because coexistence requires it. Changing device power saving does not overwrite the saved WiFi power-save mode. While a native-USB host is enumerated, the platform sleep attempt is held off so USB CDC remains responsive; detaching the host releases that guard. CPU, radio-modem, and GPS power-saving settings remain active, and USB power from a charger alone does not create a Companion session. The selected state is retained after reboot.</p> <p>On the LilyGo T-Beam 1W Full Companion, press the physical <code>BOOT</code> button once to turn the ESP32 WiFi radio and all WiFi services off or on. The screen confirms <code>WiFi: OFF</code> or <code>WiFi: ON</code>, and the selected state is retained after reboot. When WiFi is off, TCP ports 5000-5002, WebConfig, and MQTT are stopped; USB, BLE, the display, GPS, and LoRa continue to operate. Press BOOT again to restore WiFi, including the saved station or setup-AP mode. On boot, BLE starts two seconds after WiFi/WebConfig so their peak startup allocations do not overlap.</p> <p>Artifacts are written to <code>out/</code> by default.</p> <p>Full Companion behavior is selected with independent capability macros for TempRadio, the OTA CLI, the TCP terminal, USB folder seeding, and memory diagnostics. The legacy <code>COMPANION_RADIO_FULL</code> flag remains an input for older target recipes, but application behavior no longer uses that umbrella as an unrelated compile guard. In particular, ESP32 WiFi/WebConfig terminal controls are compiled from their actual WiFi/WebConfig capability. On targets that run ESP32 WiFi and BLE simultaneously, BLE is started first to avoid heap fragmentation. The SenseCAP Indicator starts only its selected secondary transport. Compile-time prerequisite checks reject inconsistent feature flags. After linking, the capability sidecar verifies USB, BLE, the OTA CLI, TempRadio, and each platform's host-folder transport; it also verifies the TCP terminal, WebConfig, and WiFi seeder on ESP32, plus dedicated logging on nRF52.</p> <p>On 4 MB ESP32 boards, the full target uses a single 3 MB application partition so WiFi, BLE, WebConfig, and source-only mOTA fit in one artifact. The T-Beam 1W Full Companion uses that same LilyGo factory-compatible boot layout on its 16 MB flash because this source-only role does not install updates into a second app slot. Flash the generated <code>-merged.bin</code> when first installing this partition layout. Other boards with 8 MB or more retain dual application partitions. Heltec V2 and TLora V2 use 100 contacts, 8 group channels, and a 16-frame offline queue in this combined profile because of internal DRAM limits. Meshadventurer SX1262 and SX1268 retain 160 contacts, use 30 group channels, and use a 64-frame queue. That is the smallest measured reduction which cleared their classic ESP32 internal-DRAM link limit; their ordinary transport-specific images retain 160 contacts, 40 channels, and 128 queued frames.</p> <p>Full Companions normally retain 256 pending Companion message frames. ESP32 boards with configured PSRAM retain 512 and allocate that queue from PSRAM before WiFi and BLE start. If PSRAM is unavailable at runtime, allocation falls back through 256 and 128 frames, then to a 16-frame internal buffer. The Full Companion startup memory line reports the capacity actually allocated as <code>offline_queue=&lt;frames&gt;</code>. The queue is volatile and shared by all channels and direct messages; it is not flash-backed history. See Companion offline message queue for all platform defaults and full-queue behavior.</p> <p>The nRF52 target inherits the board's ordinary USB Companion installation format and adds BLE plus the serial mOTA source. It does not enable an SD cache or any other board-specific storage behavior; host files are streamed as they are requested. Its image is bounded by the board's normal application region, not the smaller OTAFIX in-place workspace reserved for firmware that can update itself.</p>"},{"location":"companion_radio_full/#interfaces","title":"Interfaces","text":"Platform Interface Purpose Both USB, 115200 baud ASCII after boot; automatically switches on the first complete Binary Companion frame Both BLE Binary Companion; display builds show a random session PIN, while headless builds default to <code>123456</code> ESP32 TCP 5000 Binary Companion over WiFi ESP32 HTTP 80 Companion WebConfig and first-boot WiFi setup ESP32 TCP 5001 Host <code>.mota</code> folder from <code>motatool serve --tcp</code> ESP32 TCP 5002 Full Companion text terminal; same role commands as the USB terminal nRF52 USB mOTA mode Host <code>.mota</code> folder from <code>motatool serve --serial</code> nRF52 Encrypted BLE mOTA service Paired phone/tablet/Linux host <code>.mota</code> catalog <p>Delivery-required replies are returned only to the interface which supplied the latest command. A contact-list stream keeps that route locked from <code>CONTACTS_START</code> through <code>END_OF_CONTACTS</code>; commands waiting on another interface are read after the stream finishes. Best-effort asynchronous observations such as adverts remain broadcast so passive clients can refresh their views. Companion session state is device-wide, so use one active Companion application at a time. On nRF52, BLE remains available while USB is in terminal or mOTA mode.</p> <p>USB Binary output is queued as complete length-prefixed frames. Temporary CDC or UART backpressure pauses the contact stream; a frame may drain through a smaller hardware FIFO in ordered chunks, but its remainder is retained and no later frame can interleave with it or cause it to be discarded.</p> <p>When a BLE client requests pairing, a display-equipped build wakes the screen, switches to the first home page, and keeps the active six-digit PIN visible until Bluetooth connects or the two-minute pairing window expires. USB, WiFi, Ethernet, and hardware-serial connections do not suppress this screen. With no saved BLE PIN, display builds generate a new PIN at boot; builds without a physical display use <code>123456</code>. A PIN saved through the Companion protocol takes effect after reboot.</p> <p>The Bluetooth device name is independently configurable. In the text terminal, use <code>get bluetooth.name</code> and <code>set bluetooth.name &lt;name&gt;</code>; use <code>set bluetooth.name default</code> to restore <code>MeshCore-&lt;node name&gt;</code>. The WebConfig Node card exposes the same optional field on Bluetooth-capable ESP32 builds. Custom names replace the complete Bluetooth label rather than inheriting the prefix, accept up to 31 valid UTF-8 bytes, and take effect after reboot. This does not change the node's mesh advertisement name.</p> <p>ESP32 ports 5000, 5001, 5002, and WebConfig have no independent login layer. Expose them only on a trusted LAN or temporary setup network. See WiFi setup for credential setup and reconnect behavior.</p>"},{"location":"companion_radio_full/#usb-binary-and-text-terminal-modes","title":"USB Binary and text terminal modes","text":"<p>Full Companion USB starts in the ASCII terminal after boot. MeshCore apps and <code>meshcli</code> send a <code>&lt;</code>-prefixed framed command, which automatically hands the untouched frame to the Binary Companion parser:</p> <pre><code>meshcli -s /dev/ttyACM0 -b 115200 ver\n</code></pre> <p>The automatic probe runs only at an empty prompt. A complete frame confirms binary mode; an incomplete probe returns to ASCII after one second. Binary mode then remains selected until reboot or the explicit terminal start token. See Full Companion USB CLI and binary switcher for the byte-level state machine, logging and mOTA ownership, recovery paths, and known limitations.</p> <p>Immediately after boot, an ordinary terminal can issue ASCII commands without a start token. If the device is already in Binary Companion mode, open the port with the terminal start token sent automatically:</p> <pre><code>picocom -b 115200 \\\n  --imap spchex \\\n  --initstring $'+++MESHCORE-TERM-START\\r' \\\n  /dev/ttyACM0\n</code></pre> <p>The input map prevents any Binary Companion control bytes received during the mode transition from changing the local terminal's character set or display state while leaving UTF-8 emoji intact. The banner confirms that terminal mode is active; do not enter the start token again after it appears.</p> <p>The terminal supports Companion chat commands, including <code>channels</code>, <code>channel &lt;name-or-slot&gt; &lt;message&gt;</code>, remote administration with <code>login &lt;admin-password&gt;</code> and <code>cmd &lt;remote-command&gt;</code>, and routed <code>trace [recipient-name-or-prefix]</code>, plus local <code>ota</code>, <code>tempradio</code>, and <code>normalradio</code> controls. <code>board</code> reports the exact hardware target. ESP32 Full Companion also provides <code>memory</code>, which reports heap, internal allocation, PSRAM, and offline-queue usage; it is omitted from non-ESP32 help. ESP32 builds also provide local WiFi credential, status, WebConfig, and power-save controls. Every Full Companion provides persistent <code>get/set usb.logging</code> and starts with logging off on a fresh installation.</p>"},{"location":"companion_radio_full/#esp32-single-usb-serial-port","title":"ESP32 single USB serial port","text":"<p>Every ESP32 Full Companion exposes one USB TTY with two exclusive modes. It starts as the ASCII terminal unless a saved logging-on preference boots directly into the logging terminal. If it is already binary, enter its text terminal with <code>+++MESHCORE-TERM-START</code>, then run <code>set usb.logging on</code>; the same TTY emits plaintext packet/debug logs and continues accepting CLI commands, including <code>set usb.logging off</code>. Framed Binary Companion is unavailable on USB while logging owns the TTY. Turning logging off sends the command reply, stops the logs, and leaves that TTY in the normal ASCII terminal, matching a fresh Full installation. Send <code>+++MESHCORE-TERM-STOP</code>, or let a Companion app send a valid framed probe, to switch it to Binary Companion afterward. A saved logging-on preference boots directly into this input-capable logging terminal. BLE and Wi-Fi Companion remain available while USB is logging on simultaneous targets. On the SenseCAP Indicator, only the selected BLE or Wi-Fi Companion transport remains available alongside the logging terminal.</p> <p>ESP32 Full Companion uses the repository's Arduino-ESP32 2.x platform base where the board supports it. RC32 and ESP32-C6 retain their board-required Arduino 3.x platform, but follow the same one-TTY policy. No ESP32 Full image creates an optional second CDC interface. The single-TTY behavior applies to native-USB ESP32-S3 boards and boards using a USB-UART bridge.</p>"},{"location":"companion_radio_full/#nrf52-dual-usb-serial-ports","title":"nRF52 dual USB serial ports","text":"<p>Current nRF52 Full Companion firmware can expose two CDC ACM serial interfaces on one physical USB cable:</p> <ul> <li>USB interface <code>00</code> is the primary Companion, text-terminal, and serial-mOTA   source port. It is always present, starts in ASCII after boot, and   automatically hands a complete <code>&lt;</code> frame to Binary Companion.</li> <li>USB interface <code>02</code> is the optional write-only plaintext packet/debug logging   port. Host input on this interface is ignored and cannot invoke firmware   commands.</li> </ul> <p>A fresh Full Companion starts with USB logging off and therefore enumerates only interface <code>00</code>. Use <code>set usb.logging on</code> to save logging on; the reply says that a reboot is required. Use <code>set usb.logging on reboot</code> to save it and have the node reboot automatically after the reply. The second interface appears after that reboot. Likewise, <code>set usb.logging off reboot</code> removes interface <code>02</code>. The optional <code>reboot</code> word is accepted only in these exact command forms and triggers a reboot only when the descriptor actually needs to change.</p> <p>These are Full Companion text-terminal commands. The superficially similar <code>meshcli ... get usb.logging</code> command uses the Binary Companion parameter registry and can report <code>Unknown var usb.logging</code>; it does not forward that line to the text terminal. Enter terminal mode on interface <code>00</code> with the <code>+++MESHCORE-TERM-START</code> token as described above, then issue the command.</p> <p>When logging is on, Linux normally shows two <code>/dev/ttyACM*</code> devices. Match the stable <code>/dev/serial/by-id/*-if00</code> and <code>*-if02</code> links, or use a udev rule matching <code>ID_USB_INTERFACE_NUM</code>, rather than assuming which tty number is assigned. On Windows they appear as two COM ports; identify them by USB interface instead of depending on a particular COM number. The nRF52 bootloader temporarily exposes its normal DFU serial interface during an update.</p> <p>Opening the nRF52 logging port prints <code>MeshCore USB logging port</code> followed by its portable identity, <code>USB CDC 1; interface 02; Linux stable suffix: -if02</code>. <code>get usb.logging</code> reports the same endpoint. Firmware cannot print the exact <code>/dev/ttyACM*</code> or <code>COM*</code> name because Linux, macOS, or Windows assigns that name after USB enumeration; use the <code>*-if02</code> link on Linux to obtain the exact path. For example, <code>readlink -f /dev/serial/by-id/*-if02</code> prints the host-assigned <code>/dev/ttyACM*</code> name.</p> <p>Every ESP32-S3 Full Companion image uses DIO flash mode, including the RAK3112 and RC32 profiles. The S3 ROM supports DIO while loading the software bootloader, and some flash configurations fail before the application starts when a merged image inherits QIO. DIO trades some maximum flash-read throughput for compatibility; it does not change a board's PSRAM type or any ordinary non-Full firmware profile.</p> <p>On nRF52, point MeshCore Companion software, <code>meshcli</code>, and <code>motatool</code> at interface <code>00</code>. When enabled and rebooted, point a plaintext reader or USB-connected MQTT service at interface <code>02</code>. On ESP32, use its only USB TTY for Binary Companion while logging is off, or for the plaintext CLI/logger while logging is on; close one consumer before switching modes. Turning logging off returns to ASCII, so the normal stop token or a valid framed probe is still required before Binary Companion owns the port.</p> <p>ESP32 Full Companion exposes this same text terminal on TCP port 5002. Connect with <code>nc DEVICE_IP 5002</code>; no USB control token is needed. USB terminal mode and the TCP terminal share recipient, login, command, trace, and display state, so only one may own the terminal at a time. The idle startup USB prompt yields to a TCP connection when no USB data client or partial command is present, and is restored when TCP disconnects. An active USB session rejects TCP; entering USB terminal mode later closes an active TCP session. On USB-Serial-JTAG and USB-to-UART hardware, the firmware cannot observe an idle host open, so actual buffered USB activity\u2014not the physical cable alone\u2014claims ownership. Disconnecting TCP clears pending terminal-only state without cancelling Binary Companion delivery or radio retries.</p> <p>Both terminal transports accept <code>reboot</code>. The reply is sent first and the device reboots one second later, so a script can distinguish an accepted reboot from an abruptly lost connection.</p> <p>Port 5002 is plaintext and has no device-local login gate. A remote-admin password entered with <code>login</code> is sent across the LAN connection as typed even though the terminal does not echo it. Use port 5002 only on a trusted LAN or a temporary setup network.</p> <p>For example:</p> <pre><code>channels\nchannel #rgdata Hello from Eugene \ud83d\udc4b\nshow\nshow channels on\nto Hilltop Repeater\npath A1B2C3,D4E5F6\npath 7773D0 7E7662\nlogin my-admin-password\ncmd ver\ntrace\n</code></pre> <p>The terminal <code>list [n]</code> command displays favorite contacts first and orders each favorite/non-favorite group by its most recent advertisement. This does not alter the binary Companion contact-list protocol.</p> <p>Unsolicited terminal output starts in a quiet mode: advertisements and ordinary channel messages are hidden, while <code>#emergency</code> messages remain visible. Use <code>show adverts on|off</code>, <code>show channels on|off</code>, and <code>show emergency on|off</code> to control each category independently; plain <code>show</code> reports their state. These runtime filters affect terminal printing only and reset to their defaults after reboot.</p> <p>The <code>to</code> command selects the remote-administration target. <code>path</code> shows its saved outgoing route; <code>path direct</code>, <code>path clear</code>, or a list separated by spaces, commas, or both changes the route used by subsequent <code>login</code>, <code>send</code>, and <code>cmd</code> commands. Every hop must use the same 2-, 4-, or 6-digit hexadecimal width. Login passwords are masked during entry and limited by the radio protocol to 15 UTF-8 bytes. Wait for the asynchronous login result before using <code>cmd</code>; command replies appear as <code>CLI -&gt; from &lt;name&gt;</code> and use a response window of 300% of the route estimate. <code>DIRECT via path &lt;hop,...&gt;</code> displays the exact saved prefixes copied into the packet. Remote ACL permissions determine which commands the target accepts. The matching reply reports its round-trip time from local queueing through result reception, including radio transit and remote execution. Only one terminal <code>cmd</code> can be pending at a time.</p> <p>Incoming unicast replies are labeled <code>ROUTED</code>. Their exact return prefixes are not available at the destination because each forwarder consumes its prefix; use <code>trace</code> to verify the return route.</p> <p>With no argument, <code>trace</code> uses the current <code>to</code> recipient. A name-prefix argument traces that contact directly without changing the current recipient. The contact must already have a known direct path; results show the SNR at each hop, or a timeout if the round trip does not return.</p> <p>An explicit route can use 1-, 2-, or 4-byte hexadecimal prefixes. Spaces, commas, and mixed separators are accepted:</p> <pre><code>trace path 1 12 34 56 34 12\ntrace path 2 1234,ABCD,5678,ABCD,1234\ntrace path 4 12345678, ABCDEF01 89ABCDEF, ABCDEF01,12345678\n</code></pre> <p>The entered route must include both the outward and return prefixes. Exact three-byte traces are not supported.</p> <p>Return to Binary mode with:</p> <pre><code>+++MESHCORE-TERM-STOP\n</code></pre> <p>Closing an armed ASCII USB data connection also changes the port to Binary mode when the hardware can report disconnect. A USB-to-UART bridge may not be able to report this event. A different baud rate, including 57600, does not select ASCII mode.</p> <p>On an ESP32 Full Companion built with <code>OTA_FOLDER_SERIAL</code>, <code>motatool</code> can keep the USB serial port open as an mOTA folder source when WiFi is unavailable:</p> <pre><code>motatool serve --serial /dev/ttyACM0 --dir ./motas -v\n</code></pre> <p>The tool sends the exact completed <code>ota folder on</code> line when it opens the port. Firmware recognizes it in startup ASCII or idle Binary Companion mode, then transfers the port to exclusive USB mOTA ownership before binary request/reply frames begin. The text terminal and Binary Companion are unavailable on that TTY until <code>motatool</code> detaches the folder. This matches the nRF52 ownership behavior described below. TCP port 5001 remains the preferred unattended source transport.</p>"},{"location":"companion_radio_full/#nrf52-usb-mota-mode","title":"nRF52 USB mOTA mode","text":"<p>The nRF52 full target has a third, exclusive USB mode for the host folder. Unmodified <code>motatool serve --serial</code> sends <code>ota folder on</code> when it opens the port. The startup ASCII terminal recognizes that exact completed line, leaves terminal mode, and gives the stream directly to exclusive mOTA handling. If the port is already in Binary Companion mode, the idle binary parser recognizes the same control sequence. The sequence is not examined inside a framed Binary Companion packet. See the switcher guide for the ownership transitions.</p> <p>While mOTA mode owns USB:</p> <ul> <li>mOTA manifests and blocks stream from the computer on demand.</li> <li>USB Binary and the USB text terminal are unavailable.</li> <li>BLE Binary Companion remains available.</li> <li><code>motatool</code> sending <code>ota folder off</code>, or disconnecting the USB data session,   detaches the folder and restores Binary mode.</li> </ul> <p>No modified <code>motatool</code> build, terminal token, or preliminary mode change is required.</p>"},{"location":"companion_radio_full/#nrf52-bluetooth-mota-source","title":"nRF52 Bluetooth mOTA source","text":"<p>Protocol v14 also lets a phone, tablet, or Bluetooth-capable Linux host feed the <code>.mota</code> catalog to an nRF52 Full Companion. Normal Companion commands stay on the Nordic UART service. Firmware data uses a separate GATT service, so binary app traffic cannot be mistaken for a firmware block.</p> <p>The client must pair with the Companion PIN, subscribe to the mOTA Device Request characteristic, and send <code>CMD_BLE_MOTA_SOURCE</code> action <code>start</code> over the normal Binary Companion connection. The source is available only while that encrypted MITM-authenticated connection remains active. Disconnecting, unsubscribing, overflowing a frame, or receiving malformed data automatically detaches the catalog. USB and BLE source modes are mutually exclusive.</p> <p>The included Raspberry Pi reference client validates each <code>.mota</code> with <code>motatool</code>, schedules the local TempRadio window, serves until interrupted, then detaches and restores the normal radio tuple:</p> <pre><code>python3 tools/ble_mota/ble_mota_seeder.py \\\n  --device MeshCore-MyCompanion \\\n  --dir ./motas \\\n  --local 'tempradio 909.950,250,5,5,120'\n</code></pre> <p>Prefer this relative <code>tempradio</code> form when the phone/Pi and radio clocks may disagree. It starts a duration on the Companion and does not compare their wall clocks. Use the absolute <code>tempradioat</code> scheduler only after synchronizing the participating nodes.</p> <p>Use <code>--pair</code> when the Linux host has not already bonded. BlueZ must have an agent capable of entering or confirming the six-digit PIN. Use <code>--source status</code> without <code>--dir</code> for a read-only channel/status check. The complete UUID, frame, action, and status definitions are in the Companion protocol.</p> <p>This reference process stands in for the phone application. A mobile app can use the same sequence while retaining its normal contact and Repeater Admin UI: log in to the destination, put each required node on the same bounded TempRadio tuple, start the local Bluetooth catalog, then send the normal remote <code>ota ls</code>, <code>ota pull</code>, and <code>ota install</code> commands. The destination still checks container geometry, hardware identity, hashes, signature policy, and the OTAFIX bootloader before installation.</p>"},{"location":"companion_radio_full/#serve-mota-images-manually","title":"Serve mOTA images manually","text":"<p>First put the destination, required relays, controller, and source on the same bounded TempRadio tuple. The example frequency below is not legal everywhere; choose a legal tuple supported by every participating radio.</p>"},{"location":"companion_radio_full/#esp32-source","title":"ESP32 source","text":"<p>Use the local console to start TempRadio:</p> <pre><code>nc 192.168.1.50 5002\n</code></pre> <pre><code>tempradio 909.950,250,5,5,120\nota status\n</code></pre> <p>Then start the dedicated TCP seeder:</p> <pre><code>motatool serve --dir ./motas --tcp 192.168.1.50:5001 -v\n</code></pre>"},{"location":"companion_radio_full/#nrf52-source","title":"nRF52 source","text":"<p>Use the USB terminal briefly to schedule TempRadio, then return to Binary mode and close the terminal:</p> <pre><code>picocom -b 115200 \\\n  --imap spchex \\\n  --initstring $'+++MESHCORE-TERM-START\\r' \\\n  /dev/ttyACM1\n</code></pre> <pre><code>tempradio 909.950,250,5,5,120\n+++MESHCORE-TERM-STOP\n</code></pre> <p>After sending the stop token, exit <code>picocom</code> with Ctrl-A, Ctrl-X.</p> <p>Start the serial seeder on that same port:</p> <pre><code>motatool serve --dir ./motas --serial /dev/ttyACM1 --baud 115200 -v\n</code></pre> <p><code>motatool</code> switches the port into mOTA mode automatically. Stop it with Ctrl-C to detach the folder. Reopen the terminal and use <code>normalradio</code> if the source should return early; otherwise the saved radio settings return when the bounded window expires.</p> <p>As a cable-free alternative, keep the normal Companion BLE session open and run the Bluetooth reference client shown in the nRF52 Bluetooth section. Do not run the USB seeder at the same time.</p> <p>Both platforms intentionally refuse firmware installation commands such as:</p> <pre><code>ota pull &lt;id&gt; flash\nota install\nota dev ...\n</code></pre>"},{"location":"companion_radio_full/#script-a-complete-update","title":"Script a complete update","text":"<p>The Bash and PowerShell wrappers accept a release ZIP or ready <code>.mota</code>, set up TempRadio, run <code>motatool</code>, monitor the exact image, install it on the destination, and restore the radio path. Use a separate Companion as the controller.</p> <p>For an ESP32 full source:</p> <pre><code>export MESHCORE_ADMIN_PASSWORD='target-admin-password'\n\n./tools/lora_ota/lora_ota.sh ./release.zip \"Roof Node\" \\\n  --controller-serial /dev/ttyACM0 \\\n  --source-tcp 192.168.1.50:5001 \\\n  --source-cli-tcp 192.168.1.50:5002\n</code></pre> <p>For an nRF52 full source, the script automatically detects the token-switched terminal and uses the same source port sequentially for control and seeding:</p> <pre><code>export MESHCORE_ADMIN_PASSWORD='target-admin-password'\n\n./tools/lora_ota/lora_ota.sh ./release.zip \"Roof Node\" \\\n  --controller-serial /dev/ttyACM0 \\\n  --source-serial /dev/ttyACM1\n</code></pre> <pre><code>$env:MESHCORE_ADMIN_PASSWORD = 'target-admin-password'\n\n&amp; .\\tools\\lora_ota\\lora_ota.ps1 '.\\release.zip' 'Roof Node' `\n  --controller-serial COM7 `\n  --source-serial COM8\n</code></pre> <p>See the start-to-finish LoRa OTA guide for package selection, nRF52 in-place deltas, relays, trust checks, and recovery behavior.</p>"},{"location":"docs/","title":"Local Documentation","text":"<p>This document explains how to build and view the MeshCore documentation locally.</p>"},{"location":"docs/#building-and-viewing-docs","title":"Building and viewing Docs","text":"<pre><code>pip install mkdocs\npip install mkdocs-material\n</code></pre> <ul> <li><code>mkdocs serve</code> - Start the live-reloading docs server.</li> <li><code>mkdocs build</code> - Build the documentation site.</li> </ul>"},{"location":"faq/","title":"Frequently Asked Questions","text":"<p>A list of frequently-asked questions and answers for MeshCore</p> <ul> <li>Frequently Asked Questions</li> <li>1. Introduction<ul> <li>1.1. Q: What is MeshCore?</li> <li>1.2. Q: What do you need to start using MeshCore?<ul> <li>1.2.1. Hardware</li> <li>1.2.2. Firmware</li> <li>1.2.3. Companion Radio Firmware</li> <li>1.2.4. Repeater</li> <li>1.2.5. Room Server</li> </ul> </li> </ul> </li> <li>2. Initial Setup<ul> <li>2.1. Q: How many devices do I need to start using MeshCore?</li> <li>2.2. Q: Does MeshCore cost any money?</li> <li>2.3. Q: What frequencies are supported by MeshCore?</li> <li>2.4. Q: What is an \"advert\" in MeshCore?</li> <li>2.5. Q: Is there a hop limit?</li> </ul> </li> <li>3. Server Administration<ul> <li>3.1. Q: How do you configure a repeater or a room server?</li> <li>3.2. Q: Do I need to set the location for a repeater?</li> <li>3.3. Q: What is the password to administer a repeater or a room server?</li> <li>3.4. Q: What is the password to join a room server?</li> <li>3.5. Q: Can I retrieve a repeater's private key or set a repeater's private key?</li> <li>3.6. Q: The first byte of my repeater's public key collides with an existing repeater on the mesh. How do I get a new private key with a matching public key that has its first byte of my choosing?</li> <li>3.7. Q: My repeater may be suffering from deafness due to high power interference near my mesh's frequency, it is not hearing other in-range MeshCore radios. What can I do?</li> <li>3.8. Q: How do I make my repeater an observer on the mesh?</li> <li>3.9. Q: What is multibyte support? What do 1-byte, 2-byte, 3-byte adverts and messages mean?</li> <li>3.9.1. Q: What path hash sizes will my repeater forward?</li> <li>3.9.2. Q: What determines a packet's path hash size?</li> <li>3.9.3. Q: How do I change my companion's path hash size?</li> <li>3.9.4. Q: What does the CLI command <code>path.hash.mode</code> do on a repeater?</li> <li>3.9.5. Q: Why use 2- or 3-byte path hash for adverts?</li> <li>3.9.6. Q: When can we move away from 1-byte path hash for channel and direct messages?</li> </ul> </li> <li>4. T-Deck Related<ul> <li>4.1. Q: Is there a user guide for T-Deck, T-Pager, T-Watch, or T-Display Pro?</li> <li>4.2. Q: What are the steps to get a T-Deck into DFU (Device Firmware Update) mode?</li> <li>4.3. Q: Why is my T-Deck Plus not getting any satellite lock?</li> <li>4.4. Q: Why is my OG (non-Plus) T-Deck not getting any satellite lock?</li> <li>4.5. Q: What size of SD card does the T-Deck support?</li> <li>4.6. Q: What is the public key for the default public channel?</li> <li>4.7. Q: How do I get maps on T-Deck?</li> <li>4.8. Q: Where do the map tiles go?</li> <li>4.9. Q: How to unlock deeper map zoom and server management features on T-Deck?</li> <li>4.10. Q: How to decipher the diagnostics screen on T-Deck?</li> <li>4.11. Q: The T-Deck sound is too loud?</li> <li>4.12. Q: Can you customize the sound?</li> <li>4.13. Q: What is the 'Import from Clipboard' feature on the t-deck and is there a way to manually add nodes without having to receive adverts?</li> <li>4.14. Q: How to capture a screenshot on T-Deck?</li> </ul> </li> <li>5. General<ul> <li>5.1. Q: What are BW, SF, and CR?</li> <li>5.2. Q: Do MeshCore clients repeat?</li> <li>5.3. Q: What happens when a node learns a route via a mobile repeater, and that repeater is gone?</li> <li>5.4. Q: How does a node discover a path to its destination and then use it to send messages in the future, instead of flooding every message it sends like Meshtastic?</li> <li>5.5. Q: Do public channels always flood? Do private channels always flood?</li> <li>5.6. Q: What is the public key for the default public channel?</li> <li>5.7. Q: Is MeshCore open source?</li> <li>5.8. Q: How can I support MeshCore?</li> <li>5.9. Q: How do I build MeshCore firmware from source?</li> <li>5.10. Q: Are there other MeshCore related open source projects?</li> <li>5.11. Q: Does MeshCore support ATAK?</li> <li>5.12. Q: How do I add a node to the MeshCore Map?</li> <li>5.13. Q: Can I use a Raspberry Pi to update a MeshCore radio?</li> <li>5.14. Q: Are there projects built around MeshCore?</li> <li>5.15. Q: Are there client applications for Windows or Mac?</li> <li>5.16. Q: Are there any resources that compare MeshCore to other LoRa systems?</li> </ul> </li> <li>6. Troubleshooting<ul> <li>6.1. Q: My client says another client or a repeater or a room server was last seen many, many days ago.</li> <li>6.2. Q: A repeater or a client or a room server I expect to see on my discover list (on T-Deck) or contact list (on a smart device client) are not listed.</li> <li>6.3. Q: How to connect to a repeater via BLE (Bluetooth)?</li> <li>6.4. Q: My companion isn't showing up over Bluetooth?</li> <li>6.5. Q: I can't connect via Bluetooth, what is the Bluetooth pairing code?</li> <li>6.6. Q: My Heltec V3 keeps disconnecting from my smartphone. It can't hold a solid Bluetooth connection.</li> <li>6.7. Q: My RAK/T1000-E/xiao_nRF52 device seems to be corrupted, how do I wipe it clean to start fresh?</li> <li>6.8. Q: WebFlasher fails on Linux with failed to open</li> </ul> </li> <li>7. Other Questions:<ul> <li>7.1. Q: How to update nRF (RAK, T114, Seeed XIAO) companion, repeater and room server firmware over the air using the new simpler DFU app?<ul> <li>7.1.1 Q: Can I update Seeed Studio Wio Tracker L1 Pro using OTA?</li> </ul> </li> <li>7.2. Q: How to update ESP32-based devices over the air?</li> <li>7.3. Q: Is there a way to lower the chance of a failed OTA device firmware update (DFU)?</li> <li>7.4. Q: are the MeshCore logo and font available?</li> <li>7.5. Q: What is the format of a contact or channel QR code?</li> <li>7.6. Q: How do I connect to the companion via Wi-Fi, e.g. using a Heltec V3?</li> <li>7.7. Q: I have a Station G2, or a Heltec V4, or an Ikoka Stick, or a radio with an EByte E22-900M30S or an EByte E22-900M33S module, what should their transmit power be set to?</li> <li>7.8. Q: How do I use Ethernet with a RAK4631?</li> </ul> </li> </ul>"},{"location":"faq/#1-introduction","title":"1. Introduction","text":""},{"location":"faq/#11-q-what-is-meshcore","title":"1.1. Q: What is MeshCore?","text":"<p>A: MeshCore is a multi-platform system for enabling secure text-based communications utilizing LoRa radio hardware. It can be used for Off-Grid Communication, Emergency Response &amp; Disaster Recovery, Outdoor Activities, Tactical Security including law enforcement and private security and also IoT sensor networks. (source)</p> <p>MeshCore is free and open source:</p> <ul> <li>MeshCore is the routing and firmware etc., available on GitHub under MIT license</li> <li>There are clients made by the community, such as the web clients, these are free to use, and some are open source too</li> <li>The cross-platform mobile app developed by Liam Cottle for Android/iOS/PC etc. is free to download and use</li> <li>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</li> </ul> <p>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.</p> <p>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 utilize the advanced features.</p> <p>Anyone is able to build anything they like on top of MeshCore without paying anything.</p>"},{"location":"faq/#12-q-what-do-you-need-to-start-using-meshcore","title":"1.2. Q: What do you need to start using MeshCore?","text":"<p>A: Everything you need for MeshCore is available at:</p> <ul> <li>Main Website: https://meshcore.io</li> <li>Firmware Flasher: https://flasher.meshcore.io</li> <li>MeshCore Firmware on GitHub: https://github.com/meshcore-dev/MeshCore</li> <li>MeshCore Companion Web App: https://app.meshcore.nz</li> <li>MeshCore Map: https://map.meshcore.io</li> <li>Liam Cottle's MeshCore Technical Presentation</li> </ul> <p>You need LoRa hardware devices to run MeshCore firmware as clients or server (repeater and room server).</p>"},{"location":"faq/#121-hardware","title":"1.2.1. Hardware","text":"<p>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.</p> <p>For an up-to-date list of supported devices, please go to https://flasher.meshcore.io</p> <p>To use MeshCore without using a phone as the client interface, you can run MeshCore on a LilyGo T-Deck, T-Deck Plus, T-Pager, T-Watch, or T-Display Pro. MeshCore Ultra firmware running on these devices is a complete off-grid secure communication solution.</p>"},{"location":"faq/#122-firmware","title":"1.2.2. Firmware","text":"<p>MeshCore firmware is organized by role and, for companions, by host transport. The main roles are Companion, Repeater, Room Server, and Sensor. The tree also contains specialized terminal-chat and KISS-modem builds. Availability depends on the board; use the flasher or that board's PlatformIO environments as the current source of truth.</p>"},{"location":"faq/#123-companion-radio-firmware","title":"1.2.3. Companion Radio Firmware","text":"<p>Companion radios connect MeshCore client software to LoRa. Depending on the board and build profile, the companion protocol can be exposed over BLE, USB serial, Wi-Fi, or Ethernet. Some boards also provide a Full Companion profile with additional local administration features. Check the exact build name and transport before flashing. Pending messages are held in a volatile shared queue; capacity depends on the platform and memory profile. See the Companion offline message queue for the exact defaults and limitations. See https://meshcore.io and the web client at https://app.meshcore.nz.</p>"},{"location":"faq/#124-repeater","title":"1.2.4. Repeater","text":"<p>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.</p> <p>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.</p>"},{"location":"faq/#125-room-server","title":"1.2.5. Room Server","text":"<p>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.</p> <p>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.</p> <p>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.</p> <p>When a client logs into a room server, the client will receive the previously 32 unseen messages.</p> <p>Although room server can also repeat with the command line command <code>set repeat on</code>, it is not recommended nor encouraged. A room server with repeat set to <code>on</code> lacks the full set of repeater and remote administration features that are only available in the repeater firmware.</p> <p>The recommendation is to run repeater and room server on separate devices for the best experience.</p>"},{"location":"faq/#2-initial-setup","title":"2. Initial Setup","text":""},{"location":"faq/#21-q-how-many-devices-do-i-need-to-start-using-meshcore","title":"2.1. Q: How many devices do I need to start using MeshCore?","text":"<p>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.</p> <p>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 nearby friends and family.</p> <p>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.</p> <p>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:</p> <p><code>set freq {frequency}</code></p> <p>The repeater and room server CLI reference is here: https://docs.meshcore.io/cli_commands</p> <p>If you have more supported devices, you can use your additional devices with the room server firmware.</p>"},{"location":"faq/#22-q-does-meshcore-cost-any-money","title":"2.2. Q: Does MeshCore cost any money?","text":"<p>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.</p> <p>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.</p> <p>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.</p>"},{"location":"faq/#23-q-what-frequencies-are-supported-by-meshcore","title":"2.3. Q: What frequencies are supported by MeshCore?","text":"<p>A: Supported frequencies depend on the radio hardware and the rules for the country in which it operates. Common MeshCore hardware covers portions of the 433, 868, and 915 MHz ISM bands.</p> <p>Use the current regional preset offered by the client or flasher, confirm it with the local MeshCore community, and comply with local frequency, bandwidth, duty-cycle, and power limits. Do not copy an old frequency from this FAQ. Narrow presets commonly use BW62.5 with a lower spreading factor; their exact frequency and SF are region-specific and can change as deployments coordinate.</p> <p>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.</p>"},{"location":"faq/#24-q-what-is-an-advert-in-meshcore","title":"2.4. Q: What is an \"advert\" in MeshCore?","text":"<p>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.</p> <p>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\".</p> <ul> <li>Zero hop means your advert is broadcast to anyone that can hear it, and that's it.</li> <li>Flooded means it's broadcast and then repeated by all the repeaters that hear it.</li> </ul> <p>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:</p> <p><code>set flood.advert.interval {hours}</code></p> <p>The separate <code>set advert.interval {minutes}</code> command controls the local zero-hop advert timer.</p>"},{"location":"faq/#25-q-is-there-a-hop-limit","title":"2.5. Q: Is there a hop limit?","text":"<p>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.</p>"},{"location":"faq/#3-server-administration","title":"3. Server Administration","text":""},{"location":"faq/#31-q-how-do-you-configure-a-repeater-or-a-room-server","title":"3.1. Q: How do you configure a repeater or a room server?","text":"<p>A: When MeshCore is flashed onto a LoRa device 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.</p> <p>Repeater or room server can be administered with one of the options below:</p> <ul> <li>After a repeater or room server firmware is flashed onto a LoRa device, go to https://config.meshcore.io and use the web user interface to connect to the LoRa device via USB serial. From there you can set the name of the server, its frequency and other related settings, location, passwords etc.</li> </ul> <p></p> <ul> <li> <p>Connect the server device using a USB cable to a computer running Chrome on https://flasher.meshcore.io, then use the <code>console</code> feature to connect to the device</p> </li> <li> <p>Use a MeshCore smartphone client to remotely administer servers via LoRa.</p> </li> <li> <p>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:</p> </li> </ul> <p>https://buymeacoffee.com/ripplebiz/e/249834</p>"},{"location":"faq/#32-q-do-i-need-to-set-the-location-for-a-repeater","title":"3.2. Q: Do I need to set the location for a repeater?","text":"<p>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:</p> <p><code>set lat &lt;GPS Lat&gt;</code></p> <p><code>set lon &lt;GPS Lon&gt;</code></p> <p>You can get the latitude and longitude from Google Maps by right-clicking the location you are at on the map.</p>"},{"location":"faq/#33-q-what-is-the-password-to-administer-a-repeater-or-a-room-server","title":"3.3. Q: What is the password to administer a repeater or a room server?","text":"<p>A: The default admin password to a repeater and room server is <code>password</code>. Use the following command to change the admin password:</p> <p><code>password {new-password}</code></p>"},{"location":"faq/#34-q-what-is-the-password-to-join-a-room-server","title":"3.4. Q: What is the password to join a room server?","text":"<p>A: The default guest password to a room server is <code>hello</code>. Use the following command to change the guest password:</p> <p><code>set guest.password {guest-password}</code></p>"},{"location":"faq/#35-q-can-i-retrieve-a-repeaters-private-key-or-set-a-repeaters-private-key","title":"3.5. Q: Can I retrieve a repeater's private key or set a repeater's private key?","text":"<p>A: You can issue these commands to get or set a repeater's private key using a USB serial connection.</p> <p><code>get prv.key</code> to print a repeater's private key on the serial console <code>set prv.key &lt;hex&gt;</code> to set a repeater's private key on the serial console</p> <p>Reboot the repeater after <code>set prv.key &lt;hex&gt;</code> command for the new private key to take effect.</p>"},{"location":"faq/#36-q-the-first-byte-of-my-repeaters-public-key-collides-with-an-existing-repeater-on-the-mesh-how-do-i-get-a-new-private-key-with-a-matching-public-key-that-has-its-first-byte-of-my-choosing","title":"3.6. Q: The first byte of my repeater's public key collides with an existing repeater on the mesh. How do I get a new private key with a matching public key that has its first byte of my choosing?","text":"<p>A: You can generate a new private key and specify the first byte of its public key here: https://gessaman.com/mc-keygen</p> <p>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.</p> <p>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.</p>"},{"location":"faq/#37-q-my-repeater-may-be-suffering-from-deafness-due-to-high-power-interference-near-my-meshs-frequency-it-is-not-hearing-other-in-range-meshcore-radios-what-can-i-do","title":"3.7. Q: My repeater may be suffering from deafness due to high power interference near my mesh's frequency, it is not hearing other in-range MeshCore radios. What can I do?","text":"<p>A: This may be due to the SX1262 radio's auto gain control feature. You can use this command to periodically reset its AGC.</p> <p><code>set agc.reset.interval &lt;number&gt;</code></p> <p>The <code>&lt;number&gt;</code> unit is in seconds and is incremented by 4. <code>set agc.reset.interval 4</code> works well to cure deafness.</p> <p>The reset is skipped while a packet is pending, being received, or being transmitted. When safe, <code>RadioLibWrapper::resetAGC()</code> warm-sleeps the radio, returns the wrapper to idle so receive mode is re-armed, reapplies the cached RX boost setting, and starts a fresh noise-floor calibration.</p>"},{"location":"faq/#371-q-can-firmware-recover-an-external-radio-whose-busy-pin-is-stuck-high","title":"3.7.1. Q: Can firmware recover an external radio whose BUSY pin is stuck high?","text":"<p>A: Current firmware first attempts a non-destructive RX/AGC re-arm and then uses a physical radio reset when the board exposes one. A normal RadioLib reinitialization is not reported as a hard reset unless firmware can actually pulse NRST or cycle the radio's power rail.</p> <p>Most supported external-radio boards expose NRST directly. RAK3401 pulses its dedicated NRST while leaving the shared peripheral rail and SPI controller intact, and LilyGo T-Beam 1W can cycle the radio regulator. The generic Tenstar C3 target describes a user-wired radio and has no reset connection by default. For unattended recovery on that target, wire NRST to a free GPIO and override <code>P_LORA_RESET</code> with that GPIO in the build configuration.</p> <p>The SenseCAP T1000-E LR1110 path was hardware-qualified with 50 successful radio-only resets: 25 in continuous receive and 25 with RX power saving active. The saved radio tuple, TX power, RX gain, and RX power-saving configuration were restored after every reset, bidirectional LoRa status traffic still passed, and the nRF52840 uptime remained continuous.</p> <p>An integrated STM32WL radio has no independently resettable RF peripheral, so it intentionally remains on the bounded soft-recovery path. If its radio core cannot recover, resetting only the radio is electrically impossible; the MCU must be restarted.</p>"},{"location":"faq/#372-q-does-firmware-automatically-update-lr1110-transceiver-firmware","title":"3.7.2. Q: Does firmware automatically update LR1110 transceiver firmware?","text":"<p>A: No. A transceiver update erases and rewrites the LR1110 itself, so it is not performed as a side effect of installing ordinary device firmware. Use the hardware vendor's physical-access maintenance procedure and verify the exact LR1110 and bootloader versions before changing them.</p> <p>Full remediation of Semtech SEM-PSA-2026-001 requires LR1110 BL2 0x1001 as well as the applicable transceiver firmware. It is a separate two-stage maintenance procedure and is not performed automatically by MeshCore.</p>"},{"location":"faq/#373-q-how-does-firmware-handle-lr2021-lowhigh-band-changes","title":"3.7.3. Q: How does firmware handle LR2021 low/high-band changes?","text":"<p>A: Firmware first selects the board's matching RF path, retunes the radio, and then reapplies output power so the LR2021 selects the correct low- or high-frequency PA. It also uses the matching RF-switch mode when RX or TX is launched. LR2021 high-band output power is limited to 12 dBm; a lower board-specific limit still takes precedence.</p> <p>On Meshnology W12, the two external FEM supplies are mutually exclusive: GPIO4 powers the sub-GHz GC1109 path and GPIO3 powers the 2.4 GHz RFX2402E path. Both supplies are disabled before the selected one is enabled. Temporary radio settings preserve the saved TX power and safely clamp only the active band; returning to the saved settings restores its applicable power. A permanent frequency change clamps the saved TX power to the new band's limit.</p> <p>The external SX1262, SX1268, LLCC68, LR1110, and LR2021 drivers also bound the post-SetTx BUSY wait. A failed PA ramp therefore returns an error and can enter the physical-reset recovery path instead of hanging the node indefinitely.</p>"},{"location":"faq/#38-q-how-do-i-make-my-repeater-an-observer-on-the-mesh","title":"3.8. Q: How do I make my repeater an observer on the mesh?","text":"<p>A: The observer instruction is available here: https://analyzer.letsmesh.net/observer/onboard</p>"},{"location":"faq/#39-q-what-is-multibyte-support-what-do-1-byte-2-byte-3-byte-adverts-and-messages-mean","title":"3.9. Q: What is multibyte support? What do 1-byte, 2-byte, 3-byte adverts and messages mean?","text":"<p>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.</p> <p>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 any way. It does make it harder for tools to analyze paths with duplicated repeater IDs.</p> <p>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.</p>"},{"location":"faq/#391-q-what-path-hash-sizes-will-my-repeater-forward","title":"3.9.1. Q: What path hash sizes will my repeater forward?","text":"<p>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.</p>"},{"location":"faq/#392-q-what-determines-a-packets-path-hash-size","title":"3.9.2. Q: What determines a packet's path hash size?","text":"<p>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.</p>"},{"location":"faq/#393-q-how-do-i-change-my-companions-path-hash-size","title":"3.9.3. Q: How do I change my companion's path hash size?","text":"<p>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 <code>Settings (gear icon)</code>, <code>Experimental Settings</code>.</p> <p>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.</p>"},{"location":"faq/#394-q-what-does-the-cli-command-pathhashmode-do-on-a-repeater","title":"3.9.4. Q: What does the CLI command <code>path.hash.mode</code> do on a repeater?","text":"<p>This CLI command <code>path.hash.mode</code> 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.</p> <p>Usage: <code>set path.hash.mode {0|1|2}</code>:</p> <pre><code>+----------------+-----------------------+\n| path.hash.mode | Advert path hash size |\n+----------------+-----------------------+\n| 0              | 1 byte (default)      |\n+----------------+-----------------------+\n| 1              | 2 bytes               |\n+----------------+-----------------------+\n| 2              | 3 bytes               |\n+----------------+-----------------------+\n</code></pre> <p>It is safe to set your 1.14+ repeaters to mode 1 or 2.</p> <p></p>"},{"location":"faq/#395-q-why-use-2-or-3-byte-path-hash-for-adverts","title":"3.9.5. Q: Why use 2- or 3-byte path hash for adverts?","text":"<p>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 is 21 or 32 hops away.</p>"},{"location":"faq/#396-q-when-can-we-move-away-from-1-byte-path-hash-for-channel-and-direct-messages","title":"3.9.6. Q: When can we move away from 1-byte path hash for channel and direct messages?","text":"<p>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 <code>path.hash.mode</code> 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.</p>"},{"location":"faq/#4-t-deck-related","title":"4. T-Deck Related","text":""},{"location":"faq/#41-q-is-there-a-user-guide-for-t-deck-t-pager-t-watch-or-t-display-pro","title":"4.1. Q: Is there a user guide for T-Deck, T-Pager, T-Watch, or T-Display Pro?","text":"<p>A: Yes, it is available on https://buymeacoffee.com/ripplebiz/ultra-v7-7-guide-meshcore-users</p>"},{"location":"faq/#42-q-what-are-the-steps-to-get-a-t-deck-into-dfu-device-firmware-update-mode","title":"4.2. Q: What are the steps to get a T-Deck into DFU (Device Firmware Update) mode?","text":"<p>A:</p> <ol> <li>Device off</li> <li>Connect USB cable to device</li> <li>Hold down trackball (keep holding)</li> <li>Turn on device</li> <li>Hear USB connection sound</li> <li>Release trackball</li> <li>T-Deck in DFU mode now</li> <li>At this point you can begin flashing using https://flasher.meshcore.io</li> </ol>"},{"location":"faq/#43-q-why-is-my-t-deck-plus-not-getting-any-satellite-lock","title":"4.3. Q: Why is my T-Deck Plus not getting any satellite lock?","text":"<p>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.</p> <p>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 <code>GPS Info</code> screen; you should see the <code>Sentences:</code> counter increasing if the baud rate is correct.</p> <p>Source</p>"},{"location":"faq/#44-q-why-is-my-og-non-plus-t-deck-not-getting-any-satellite-lock","title":"4.4. Q: Why is my OG (non-Plus) T-Deck not getting any satellite lock?","text":"<p>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.</p>"},{"location":"faq/#45-q-what-size-of-sd-card-does-the-t-deck-support","title":"4.5. Q: What size of SD card does the T-Deck support?","text":"<p>A: Users have had no issues using 16GB or 32GB SD cards. Format the SD card to FAT32.</p>"},{"location":"faq/#46-q-what-is-the-public-key-for-the-default-public-channel","title":"4.6. Q: What is the public key for the default public channel?","text":"<p>A: T-Deck uses the same key the smartphone apps use but in base64 <code>izOH6cXN6mrJ5e26oRXNcg==</code></p> <p>There is no <code>=</code> key on the T-Deck's hardware keyboard. You can use the on-screen software keyboard to enter <code>=</code>. Tap the text box to enable the on-screen software keyboard. The third character is the capital letter <code>O</code> (Oh), not zero <code>0</code></p> <p>The smartphone app key is in hex: <code>8b3387e9c5cdea6ac9e5edbaa115cd72</code></p> <p>Source</p>"},{"location":"faq/#47-q-how-do-i-get-maps-on-t-deck","title":"4.7. Q: How do I get maps on T-Deck?","text":"<p>A: You need map tiles. You can get pre-downloaded map tiles here (a good way to support development):</p> <ul> <li>https://buymeacoffee.com/ripplebiz/e/342543 (Europe)</li> <li>https://buymeacoffee.com/ripplebiz/e/342542 (US)</li> </ul> <p>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</p> <p>There is also a modified script that adds additional error handling and parallel downloads: https://github.com/TheBestJohn/MTD-Script</p>"},{"location":"faq/#48-q-where-do-the-map-tiles-go","title":"4.8. Q: Where do the map tiles go?","text":"<p>Once you have the tiles downloaded, copy the <code>\\tiles</code> folder to the root of your T-Deck's SD card.</p>"},{"location":"faq/#49-q-how-to-unlock-deeper-map-zoom-and-server-management-features-on-t-deck","title":"4.9. Q: How to unlock deeper map zoom and server management features on T-Deck?","text":"<p>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</p>"},{"location":"faq/#410-q-how-to-decipher-the-diagnostics-screen-on-t-deck","title":"4.10. Q: How to decipher the diagnostics screen on T-Deck?","text":"<p>A: Space is tight on T-Deck's screen, so the information is a bit cryptic. The format is : <code>{hops} l:{packet-length}({payload-len}) t:{packet-type} snr:{n} rssi:{n}</code></p> <p>See here for packet-type: https://github.com/meshcore-dev/MeshCore/blob/main/src/Packet.h#L19</p> Value Payload <code>0x00</code> Request <code>0x01</code> Response <code>0x02</code> Plain text message <code>0x03</code> Acknowledgment <code>0x04</code> Node advertisement <code>0x05</code> Group text <code>0x06</code> Group datagram <code>0x07</code> Anonymous request <code>0x08</code> Returned path <code>0x09</code> Trace <code>0x0A</code> Multipart <code>0x0B</code> Control/discovery data <code>0x0C</code> OTA-over-LoRa data <code>0x0D</code>-<code>0x0E</code> Reserved <code>0x0F</code> Raw custom data <p>See Packet Format and Payload Format for the maintained descriptions.</p> <p>Source</p>"},{"location":"faq/#411-q-the-t-deck-sound-is-too-loud","title":"4.11. Q: The T-Deck sound is too loud?","text":""},{"location":"faq/#412-q-can-you-customize-the-sound","title":"4.12. Q: Can you customize the sound?","text":"<p>A: You can customize the sounds on the T-Deck, by placing <code>.mp3</code> files onto the <code>root</code> dir of the SD card. The files are:</p> <ul> <li><code>startup.mp3</code></li> <li><code>error.mp3</code></li> <li><code>alert.mp3</code></li> <li><code>new-advert.mp3</code></li> <li><code>existing-advert.mp3</code></li> </ul>"},{"location":"faq/#413-q-what-is-the-import-from-clipboard-feature-on-the-t-deck-and-is-there-a-way-to-manually-add-nodes-without-having-to-receive-adverts","title":"4.13. Q: What is the 'Import from Clipboard' feature on the t-deck and is there a way to manually add nodes without having to receive adverts?","text":"<p>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://...\")</p>"},{"location":"faq/#414-q-how-to-capture-a-screenshot-on-t-deck","title":"4.14. Q: How to capture a screenshot on T-Deck?","text":"<p>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.</p>"},{"location":"faq/#5-general","title":"5. General","text":""},{"location":"faq/#51-q-what-are-bw-sf-and-cr","title":"5.1. Q: What are BW, SF, and CR?","text":"<p>A:</p> <p>BW is bandwidth - width of frequency spectrum that is used for transmission</p> <p>SF is spreading factor - how much should the communication spread in time</p> <p>CR is coding rate - from: https://www.thethingsnetwork.org/docs/lorawan/fec-and-code-rate</p> <p>TL;DR: default CR to 5 for good stable links. If it is not a solid link and is intermittent, change CR to 7 or 8.</p> <p>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.</p> <p>The Code Rate of a forward error correction expresses the proportion of bits in a data stream that actually carry useful information.</p> <p>There are 4 code rates used in LoRaWAN:</p> <p>4/5 4/6 5/7 4/8</p> <p>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.</p> <p>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.</p> <p>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 talking in a noisy place (a bar for example). If you're far from each other, you have to talk slow (SF10), but if you're close, you can talk faster (SF7)</p> <p>So, it's a balancing act between speed of the transmission and resistance to noise. The Things Network is mainly focused on LoRaWAN, but the LoRa low-level stuff still checks out for any LoRa project</p>"},{"location":"faq/#52-q-do-meshcore-clients-repeat","title":"5.2. Q: Do MeshCore clients repeat?","text":"<p>A: Companion clients do not repeat by default. Supported builds can opt into bounded client repeating on permitted frequencies, and the emergency-channel path has a bounded delayed relay behavior. Dedicated repeaters remain the normal and recommended way to extend network coverage. Room servers can repeat when explicitly configured, but separating the roles is generally preferable.</p>"},{"location":"faq/#53-q-what-happens-when-a-node-learns-a-route-via-a-mobile-repeater-and-that-repeater-is-gone","title":"5.3. Q: What happens when a node learns a route via a mobile repeater, and that repeater is gone?","text":"<p>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.</p> <p>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.</p>"},{"location":"faq/#54-q-how-does-a-node-discover-a-path-to-its-destination-and-then-use-it-to-send-messages-in-the-future-instead-of-flooding-every-message-it-sends-like-meshtastic","title":"5.4. Q: How does a node discover a path to its destination and then use it to send messages in the future, instead of flooding every message it sends like Meshtastic?","text":"<p>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.</p> <p>Source</p>"},{"location":"faq/#55-q-do-public-channels-always-flood-do-private-channels-always-flood","title":"5.5. Q: Do public channels always flood? Do private channels always flood?","text":"<p>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 <code>set flood.max</code> CLI command. Administrators of repeaters get to set the rules of their repeaters.</p> <p>Source</p>"},{"location":"faq/#56-q-what-is-the-public-key-for-the-default-public-channel","title":"5.6. Q: What is the public key for the default public channel?","text":"<p>A: The smartphone app key is in hex:</p> <p><code>8b3387e9c5cdea6ac9e5edbaa115cd72</code></p> <p>T-Deck uses the same key but in base64:</p> <p><code>izOH6cXN6mrJ5e26oRXNcg==</code></p> <p>The third character is the capital letter <code>O</code>, not zero <code>0</code>.</p> <p>Source</p>"},{"location":"faq/#57-q-is-meshcore-open-source","title":"5.7. Q: Is MeshCore open source?","text":"<p>A: Most of the firmware is freely available. Everything is open source except the T-Deck firmware and Liam's native mobile apps.</p> <p>Firmware repo: https://github.com/meshcore-dev/MeshCore</p>"},{"location":"faq/#58-q-how-can-i-support-meshcore","title":"5.8. Q: How can I support MeshCore?","text":"<p>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.</p> <p>Support Liam Cottle's smartphone client development by unlocking the server administration wait gate with in-app purchase</p> <p>Support Rastislav Vysoky (recrof)'s flasher website and the map website development through PayPal or Revolut</p>"},{"location":"faq/#59-q-how-do-i-build-meshcore-firmware-from-source","title":"5.9. Q: How do I build MeshCore firmware from source?","text":"<p>A: See instructions here: https://discord.com/channels/826570251612323860/1330643963501351004/1341826372120608769</p> <p>Build instructions for MeshCore:</p> <p>For Windows, first install WSL and Python+pip via: https://plainenglish.io/python/setting-up-python-on-windows-subsystem-for-linux-wsl-26510f1b2d80</p> <p>(Linux, Windows+WSL) In the terminal/shell:</p> <pre><code>sudo apt update\nsudo apt install libpython3-dev\nsudo apt install python3-venv\n</code></pre> <p>Mac: python3 should be already installed.</p> <p>Then it should be the same for all platforms:</p> <pre><code>python3 -m venv meshcore\ncd meshcore &amp;&amp; source bin/activate\npip install -U platformio\ngit clone https://github.com/meshcore-dev/MeshCore.git\ncd MeshCore\n</code></pre> <p>Choose an exact environment listed by <code>pio project config</code> or in the target board's <code>variants/*/platformio.ini</code>. For example:</p> <pre><code>pio run -e RAK_4631_repeater\n</code></pre> <p>The output is under <code>.pio/build/RAK_4631_repeater/</code>. Set the radio parameters to your current regional preset after flashing; if changing build defaults, keep that local change out of commits unless it is intended for every user.</p>"},{"location":"faq/#510-q-are-there-other-meshcore-related-open-source-projects","title":"5.10. Q: Are there other MeshCore related open source projects?","text":"<p>A: Liam Cottle's MeshCore web client and MeshCore JavaScript library are open source under MIT license.</p> <p>Web client: https://github.com/liamcottle/meshcore-web JavaScript: https://github.com/meshcore-dev/meshcore.js</p>"},{"location":"faq/#511-q-does-meshcore-support-atak","title":"5.11. Q: Does MeshCore support ATAK?","text":"<p>A: This repository does not ship or document an official ATAK integration. An external integration must account for LoRa airtime, moving endpoints, stale direct paths, and the collision cost of frequent flood fallback. Optional, bounded Companion repeating does not turn every mobile client into a dedicated repeater and does not remove those capacity constraints. Check current community projects before designing a deployment.</p> <p>Source</p>"},{"location":"faq/#512-q-how-do-i-add-a-node-to-the-meshcore-map","title":"5.12. Q: How do I add a node to the MeshCore Map?","text":"<p>A:</p> <p>To add a BLE Companion radio, connect to the BLE Companion radio from the MeshCore smartphone app. In the app, tap the <code>3 dot</code> menu icon at the top right corner, then tap <code>Internet Map</code>. Tap the <code>3 dot</code> menu icon again and choose <code>Add me to the Map</code></p> <p>To add a Repeater or Room Server to the map, go to the Contact List, tap the <code>3 dot</code> next to the Repeater or Room Server you want to add to the Internet Map, tap <code>Share</code>, then tap <code>Upload to Internet Map</code>.</p> <p>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.</p>"},{"location":"faq/#513-q-can-i-use-a-raspberry-pi-to-update-a-meshcore-radio","title":"5.13. Q: Can I use a Raspberry Pi to update a MeshCore radio?","text":"<p>A: Yes. Below are the instructions to flash firmware onto a supported LoRa device using a Raspberry Pi over USB serial.</p> <p>Instructions for nRF devices like RAK, T1000-E, T114 are immediately after the ESP instructions</p> <p>For ESP-based devices (e.g. Heltec V3) you need:</p> <ol> <li>Download the firmware file from https://flasher.meshcore.io.<ul> <li>Select the exact board and role. Artifact names and release URLs include a   changing version and commit, so copy the current download URL instead of   using an example URL from a guide.</li> <li>A non-merged application image is for an already compatible bootloader   and partition table. A merged image also contains low-level flash data.   Back up settings before either operation; do not assume a merged flash   preserves configuration, pairing data, or a previous partition layout.</li> <li>To download a copied URL from the shell, use   <code>curl -L '&lt;copied-url&gt;' -o &lt;firmware&gt;.bin</code>.</li> </ul> </li> <li>Confirm the <code>ttyXXXX</code> device path on your Raspberry Pi.<ul> <li>Run <code>ls /dev/ttyACM* /dev/ttyUSB* 2&gt;/dev/null</code> before and after connecting   the board. ESP devices can appear under either name.</li> </ul> </li> <li>Install esptool in a virtual environment.<ul> <li><code>python3 -m venv .venv &amp;&amp; . .venv/bin/activate</code></li> <li><code>python -m pip install --upgrade esptool</code></li> </ul> </li> <li>Flash the firmware.<ul> <li>For non-merged bin:<ul> <li><code>python -m esptool --port /dev/ttyUSB0 --chip auto write-flash 0x10000 &lt;non-merged-firmware&gt;.bin</code></li> </ul> </li> <li>For merged bin:<ul> <li><code>python -m esptool --port /dev/ttyUSB0 --chip auto write-flash 0x00000 &lt;merged-firmware&gt;.bin</code></li> </ul> </li> </ul> </li> </ol> <p>Instructions for nRF devices:</p> <p>For nRF devices (e.g. RAK, Heltec T114) you need the following:</p> <ol> <li>Download the firmware file from https://flasher.meshcore.io.<ul> <li>Select the exact board and role, and download its current ZIP package.   Do not rename a package from another board or reuse a static versioned URL.</li> </ul> </li> <li>Confirm the <code>ttyXXXX</code> device path on your Raspberry Pi.<ul> <li>Run <code>ls /dev/ttyACM* /dev/ttyUSB* 2&gt;/dev/null</code>; nRF bootloaders commonly   appear as <code>/dev/ttyACM0</code>, but the number can change.</li> </ul> </li> <li>In a virtual environment, install adafruit-nrfutil:<ul> <li><code>python3 -m venv .venv &amp;&amp; . .venv/bin/activate</code></li> <li><code>python -m pip install --upgrade adafruit-nrfutil</code></li> </ul> </li> <li>Flash the nRF device.<ul> <li><code>adafruit-nrfutil --verbose dfu serial --package &lt;firmware-package&gt;.zip -p /dev/ttyACM0 -b 115200 --singlebank --touch 1200</code></li> </ul> </li> </ol> <p>To manage a repeater or room server connected to a Pi over USB serial using shell commands, you need to install <code>picocom</code>. To install <code>picocom</code>, run the following command:</p> <ul> <li><code>sudo apt install picocom</code></li> </ul> <p>To start managing your USB serial-connected device using picocom, use the following command:</p> <ul> <li><code>picocom -b 115200 /dev/ttyUSB0 --imap lfcrlf</code></li> </ul> <p>From here, reference repeater and room server command line commands in the MeshCore docs here:</p> <ul> <li>https://docs.meshcore.io/cli_commands</li> </ul>"},{"location":"faq/#514-q-are-there-projects-built-around-meshcore","title":"5.14. Q: Are there projects built around MeshCore?","text":"<p>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 Assistant.</p> <p>As new MeshCore community projects become available on a weekly basis, we have stopped tracking them here in this FAQ. samuk maintains a very exhaustive list of MeshCore community project at https://github.com/samuk/awesome-meshcore/blob/main/README.md. samuk accepts PRs and merges them regularly.</p>"},{"location":"faq/#515-q-are-there-client-applications-for-windows-or-mac","title":"5.15. Q: Are there client applications for Windows or Mac?","text":"<p>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</p> <p>Both the Windows and Mac versions of the client app are fully unlocked and are free to use.</p>"},{"location":"faq/#516-q-are-there-any-resources-that-compare-meshcore-to-other-lora-systems","title":"5.16. Q: Are there any resources that compare MeshCore to other LoRa systems?","text":"<p>A: Here is a list of MeshCore comparison resources:</p> <ul> <li>The Comms Channel on YouTube: https://www.youtube.com/watch?v=guDoKGs02Us</li> <li>MeshCore Advantages by MCarper: https://github.com/mikecarper/meshfirmware/blob/main/MeshCoreAdvantages.md</li> <li>MeshCore vs Meshtastic by austinmesh.org: https://www.austinmesh.org/about/meshcore-vs-meshtastic/</li> </ul>"},{"location":"faq/#6-troubleshooting","title":"6. Troubleshooting","text":""},{"location":"faq/#61-q-my-client-says-another-client-or-a-repeater-or-a-room-server-was-last-seen-many-many-days-ago","title":"6.1. Q: My client says another client or a repeater or a room server was last seen many, many days ago.","text":""},{"location":"faq/#62-q-a-repeater-or-a-client-or-a-room-server-i-expect-to-see-on-my-discover-list-on-t-deck-or-contact-list-on-a-smart-device-client-are-not-listed","title":"6.2. Q: A repeater or a client or a room server I expect to see on my discover list (on T-Deck) or contact list (on a smart device client) are not listed.","text":"<p>A:</p> <ul> <li>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).</li> <li>If you are using the Android or iOS client, the other client, repeater, or room server may have the wrong time.</li> </ul> <p>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 <code>time</code> command in the USB serial console with the server device connected.</p>"},{"location":"faq/#63-q-how-to-connect-to-a-repeater-via-ble-bluetooth","title":"6.3. Q: How to connect to a repeater via BLE (Bluetooth)?","text":"<p>A: You can't connect to a device running repeater firmware via Bluetooth. You can connect to devices running the BLE companion firmware via Bluetooth using the Android app.</p>"},{"location":"faq/#64-q-my-companion-isnt-showing-up-over-bluetooth","title":"6.4. Q: My companion isn't showing up over Bluetooth?","text":"<p>A: Make sure that you flashed the Bluetooth companion firmware and not the USB-only companion firmware.</p>"},{"location":"faq/#65-q-i-cant-connect-via-bluetooth-what-is-the-bluetooth-pairing-code","title":"6.5. Q: I can't connect via Bluetooth, what is the Bluetooth pairing code?","text":"<p>A: The default Bluetooth pairing code is <code>123456</code> on builds without a physical display. Display-equipped Companion builds generate a six-digit PIN at boot and show it when a client requests pairing. The display stays awake on the PIN page until Bluetooth connects or the two-minute pairing window expires.</p>"},{"location":"faq/#66-q-my-heltec-v3-keeps-disconnecting-from-my-smartphone-it-cant-hold-a-solid-bluetooth-connection","title":"6.6. Q: My Heltec V3 keeps disconnecting from my smartphone. It can't hold a solid Bluetooth connection.","text":"<p>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.</p>"},{"location":"faq/#67-q-my-rakt1000-exiao_nrf52-device-seems-to-be-corrupted-how-do-i-wipe-it-clean-to-start-fresh","title":"6.7. Q: My RAK/T1000-E/xiao_nRF52/... device seems to be corrupted, how do I wipe it clean to start fresh?","text":"<p>A: If you're able to connect to the device from your MeshCore app 1. Navigate to Gear icon(Settings) on the upper right corner 2. Click on <code>Export Settings</code> button, choose <code>Select All</code> and Confirm. This will save your Node configuration 3. Now choose <code>Factory Reset</code> option 4. Confirm that you want to reset your device 5. Go to Bluetooth System settings and remove pairing of the device, so you can connect again 6. Connect your device in the app and enter the PIN 7. Navigate to Gear icon(Settings) on the upper right corner 8. Click on <code>Import Settings</code> and choose the file from 2., click on <code>Select All</code> and Confirm 9. Find <code>Reboot</code> button on of the Settings list</p> <p>B: You're not able to connect to the App 1. Connect USB cable to your device 2. Go to https://flasher.meshcore.io 3. Search for your device in the list 4. Choose <code>Companion Bluetooth</code> 5. Press <code>Enter DFU mode</code> button, choose your USB device 6. Press <code>Erase Flash</code> button, choose the device again and wait until it completes 7. Press <code>Flash!</code> button and choose the USB device last time 8. The device is erased and newest firmware is installed 9. You might need to remove the pairing in Bluetooth System Settings in order to re-pair the app again.</p> <p>An erase application or ordinary application ZIP/UF2 does not repair a damaged or partially overwritten SoftDevice. This can happen after flashing an nRF52 image for a different board or SoftDevice layout. A characteristic failure is that the application can boot and read its filesystem, but reboots or hangs when it writes or formats internal flash. Repeating <code>Erase Flash</code> is not a recovery for that condition.</p> <p>Recover it with a combined bootloader + SoftDevice package for the exact board (including XIAO Sense versus non-Sense), installed through serial/BLE DFU or SWD. With <code>adafruit-nrfutil</code>, the serial form is:</p> <pre><code>adafruit-nrfutil dfu serial -p &lt;port&gt; \\\n  -pkg &lt;exact-board-bootloader-with-softdevice&gt;.zip -sb -t 1200\n</code></pre> <p>Then install the exact-board MeshCore application. Do not use an application- only UF2, filesystem formatter, or a similarly named package from another nRF52 board as a substitute. See the confirmed XIAO recovery in issue #3284 and obtain the matching package from the OTAFIX releases.</p> <p>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 holding down the user button of the device within 8 seconds of boot. Then you can use the 'Console' on https://flasher.meshcore.io</p>"},{"location":"faq/#68-q-webflasher-fails-on-linux-with-failed-to-open","title":"6.8. Q: WebFlasher fails on Linux with failed to open","text":"<p>A: If the usb port doesn't have the right ownership for this task, the process fails with the following error:</p> <p><code>NetworkError: Failed to execute 'open' on 'SerialPort': Failed to open serial port.</code></p> <p>Allow user access on your USB port:</p> <p><code>sudo setfacl -m u:$USER:rw /dev/ttyUSB0</code></p>"},{"location":"faq/#7-other-questions","title":"7. Other Questions:","text":""},{"location":"faq/#71-q-how-to-update-nrf-rak-t114-seeed-xiao-companion-repeater-and-room-server-firmware-over-the-air-using-the-new-simpler-dfu-app","title":"7.1. Q: How to update nRF (RAK, T114, Seeed XIAO) companion, repeater and room server firmware over the air using the new simpler DFU app?","text":"<p>A: The steps below work on both Android and iOS as nRF has made both apps' user interface the same on both platforms:</p> <ol> <li>Download nRF's DFU app from iOS App Store or Android's Play Store, you can find the app by searching for <code>nrf dfu</code>, the app's full name is <code>nRF Device Firmware Update</code></li> <li>On https://flasher.meshcore.io, download the ZIP version of the firmware for your nRF device (e.g. RAK or Heltec T114 or Seeed Studio's Xiao)</li> <li>From the MeshCore app, log in remotely to the repeater you want to update with admin privileges</li> <li>Go to the Command Line tab, type <code>start ota</code> and hit enter.</li> <li>You should see <code>OK</code> to confirm the repeater device is now in OTA mode</li> <li>Run the DFU app, then tap <code>Settings</code> in the top-right corner</li> <li>Enable <code>Packet receipt notifications</code>, and change <code>Number of Packets</code> to 10 for RAK, 8 for T114. 8 also works for RAK.</li> <li>Select the firmware zip file you downloaded</li> <li>Select the device you want to update. If the device you want to update is not on the list, try enabling <code>OTA</code> on the device again</li> <li>If the device is not found, enable <code>Force Scanning</code> in the DFU app</li> <li>Tap <code>Upload</code> to begin OTA update</li> <li>If it fails, try toggling Bluetooth on your phone. If that doesn't work, try rebooting your phone. If you keep getting failures at the \"Enabling Bootloader\" step, try forgetting the nRF board in your iOS or Android device's Bluetooth settings and re-pair it through the DFU app.</li> <li>Wait for the update to complete. It can take a few minutes.</li> <li>It is strongly recommended that you install and use the OTAFIX bootloader at https://github.com/oltaco/Adafruit_nRF52_Bootloader_OTAFIX.</li> <li>A companion must be running a build that exposes <code>start ota</code>; consult the     current flasher release notes rather than relying on a version threshold in     this FAQ.</li> <li>Please see the MeshCore Blog for additional information on OTA firmware flashing:<ul> <li>https://blog.meshcore.io/2026/04/06/otafix-bootloader</li> <li>https://blog.meshcore.io/2026/04/02/nrf-ota-update</li> </ul> </li> </ol>"},{"location":"faq/#711-q-can-i-update-seeed-studio-wio-tracker-l1-pro-using-ota","title":"7.1.1 Q: Can I update Seeed Studio Wio Tracker L1 Pro using OTA?","text":"<p>A:  You can flash this safer bootloader to the Wio Tracker L1 Pro https://github.com/oltaco/Adafruit_nRF52_Bootloader_OTAFIX</p> <p>After this bootloader is flashed onto the device, you can trigger an over-the-air update using Bluetooth by holding the button next to the D-Pad and then clicking the reset button. Then follow the same OTA update instructions above. You can skip the <code>start ota</code> instruction and start the update using the DFU app.</p>"},{"location":"faq/#72-q-how-to-update-esp32-based-devices-over-the-air","title":"7.2. Q: How to update ESP32-based devices over the air?","text":"<p>A: For ESP32-based devices (e.g. Heltec V3):</p> <ol> <li>On https://flasher.meshcore.io, download the current non-merged    application image for the exact ESP32 board and role (no <code>merged</code> in the    filename).</li> <li>From the MeshCore app, log in remotely to the repeater you want to update with admin privileges.</li> <li>Go to the Command Line tab, type <code>start ota</code> and hit enter.</li> <li>You should see <code>OK</code> to confirm the repeater device is now in OTA mode.</li> <li>If the ESP32 is not already joined to Wi-Fi, <code>start ota</code> starts an open hotspot named <code>MeshCore-OTA</code> at <code>192.168.4.1</code>. If it is already joined, the command reports and uses its router-assigned address instead.</li> <li>From your phone or computer, connect to the <code>MeshCore-OTA</code> hotspot when one was started.</li> <li>Open the URL reported by <code>start ota</code> and upload the non-merged bin from the flasher. When the device started <code>MeshCore-OTA</code>, the URL is http://192.168.4.1/update.</li> </ol> <p>On an MQTT observer, stop WebConfig before running <code>start ota</code>; both servers use HTTP port 80. Likewise, stop the OTA uploader before running <code>start webconfig</code>.</p>"},{"location":"faq/#73-q-is-there-a-way-to-lower-the-chance-of-a-failed-ota-device-firmware-update-dfu","title":"7.3. Q: Is there a way to lower the chance of a failed OTA device firmware update (DFU)?","text":"<p>A: Yes, developer <code>che aporeps</code> 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.</p> <p>Refer to https://github.com/oltaco/Adafruit_nRF52_Bootloader_OTAFIX for the latest information.</p> <p>Currently, the following boards are supported:</p> <ul> <li>Elecrow ThinkNode M1, M3, and M6</li> <li>Heltec Automation Mesh Node T114 / HT-nRF5262</li> <li>LilyGO T-Echo</li> <li>Minewsemi MX25LE01</li> <li>Nologo ProMicro NRF52840 (aka SuperMini NRF52840)</li> <li>RAK4631</li> <li>RAK WisMesh Tag</li> <li>Seeed Studio SenseCAP Card Tracker T1000-E</li> <li>Seeed Studio SenseCAP Solar Node P1</li> <li>Seeed Studio Wio Tracker L1</li> <li>Seeed Studio XIAO nRF52840 BLE</li> <li>Seeed Studio XIAO nRF52840 BLE SENSE</li> </ul>"},{"location":"faq/#74-q-are-the-meshcore-logo-and-font-available","title":"7.4. Q: Are the MeshCore logo and font available?","text":"<p>A: Yes, it is on the MeshCore GitHub repo here: https://github.com/meshcore-dev/MeshCore/tree/main/logo</p>"},{"location":"faq/#75-q-what-is-the-format-of-a-contact-or-channel-qr-code","title":"7.5. Q: What is the format of a contact or channel QR code?","text":"<p>A:</p> <p>Channel: <code>meshcore://channel/add?name=&lt;name&gt;&amp;secret=&lt;secret&gt;</code></p> <p>Contact: <code>meshcore://contact/add?name=&lt;name&gt;&amp;public_key=&lt;secret&gt;&amp;type=&lt;type&gt;</code></p> <p>Where <code>&amp;type</code> is:</p> <ul> <li><code>chat = 1</code></li> <li><code>repeater = 2</code></li> <li><code>room = 3</code></li> <li><code>sensor = 4</code></li> </ul>"},{"location":"faq/#76-q-how-do-i-connect-to-the-companion-via-wi-fi-eg-using-a-heltec-v3","title":"7.6. Q: How do I connect to the companion via Wi-Fi, e.g. using a Heltec V3?","text":"<p>A: Flash an ESP32 companion Wi-Fi build. Its shared WebUI is enabled by default. If it has no saved Wi-Fi configuration, it starts an open <code>MeshCore-Setup-XXXX</code> access point. Join it and browse to http://192.168.4.1/. The wizard configures WiFi, node identity, and radio settings; MQTT companion builds add an MQTT step and MQTT tab, while non-MQTT companions remove those controls. After saving, the page and device screen show the station IP assigned by your router.</p> <p>If a saved network remains unreachable for two minutes, the setup AP starts as a fallback. If the original network returns, the companion closes that recovery portal and resumes normal LAN operation.</p> <p>The setup AP always uses <code>192.168.4.1</code>; the companion's station IP is assigned by DHCP and can be different. A real <code>WIFI_SSID</code> and <code>WIFI_PWD</code> can still be supplied at compile time as initial defaults, but they are no longer required.</p> <p>On the LAN, the WebUI remains available at the companion's station IP and the companion protocol remains available on TCP port <code>5000</code>. Companion builds do not have an admin CLI password, so this configuration page trusts the local LAN; do not put the companion on an untrusted WiFi network.</p> <p>ESP32 repeater and room-server builds use the same page, but keep it off by default. Run <code>set webui on</code> from the admin CLI, open the reported LAN URL, and sign in with the admin password; <code>get webui</code> reports its current address. Their MQTT observer variants expose the MQTT controls, while ordinary builds do not. The two 4 MB <code>LilyGo_TLora_V2_1_1_6_*_observer_mqtt</code> builds retain CLI-only configuration so their flash can keep two app slots for LoRa OTA.</p>"},{"location":"faq/#77-q-i-have-a-station-g2-or-a-heltec-v4-or-an-ikoka-stick-or-a-radio-with-an-ebyte-e22-900m30s-or-an-ebyte-e22-900m33s-module-what-should-their-transmit-power-be-set-to","title":"7.7. Q: I have a Station G2, or a Heltec V4, or an Ikoka Stick, or a radio with an EByte E22-900M30S or an EByte E22-900M33S module, what should their transmit power be set to?","text":"<p>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 <code>set tx</code>. You can get their current value using command line command <code>get tx</code></p> <p>[WARN] WARNING: Set these values at your own risk. Incorrect power settings can permanently damage your radio hardware.</p> Device / Model Region / Description In-App Setting (dBm) Target Radio Output Notes Station G2 Reference US915 Max Output 19 dBm 36.5 dBm (4.46W) US915 Max at 1dB compression point 16 dBm 35 dBm (3.16W) 1dB compression point EU868  Max at 1dB compression point 15 dBm 34.5 dBm (2.82W) 1dB compression point US915 1W Output 10 dBm 1W Refer to your local government's requirements EU868 1W Output 9 dBm 1W Refer to your local government's requirements Ikoka Stick E22-900M30S 1W Model 19 dBm 1W DO NOT EXCEED (Risk of burn out) data sheet Ikoka Stick E22-900M33S 2W Model 9 dBm 2W DO NOT EXCEED (Risk of burn out) data sheet Refer to your local government's requirements Heltec V4 Standard Output 10 dBm 22 dBm (~0.15W) High Output 22 dBm 28 dBm (~0.5W to 0.6W)"},{"location":"faq/#78-q-how-do-i-use-ethernet-with-a-rak4631","title":"7.8. Q: How do I use Ethernet with a RAK4631?","text":"<p>A: MeshCore supports Ethernet on RAK4631 boards using the RAK13800 WisBlock Ethernet module (based on the W5100S chip).</p> <p>Hardware required: - RAK4631 WisBlock Core - RAK19007 or RAK19018 WisBlock Base Board (with an available IO slot) - RAK13800 WisBlock Ethernet module - Ethernet cable connected to a network with a DHCP server</p> <p>Firmware: Flash one of the Ethernet-enabled firmware variants: - <code>RAK_4631_repeater_ethernet</code> - Repeater with Ethernet CLI access - <code>RAK_4631_room_server_ethernet</code> - Room server with Ethernet CLI access - <code>RAK_4631_companion_radio_ethernet</code> - Companion radio over Ethernet (replaces BLE)</p> <p>Connecting: - The device obtains an IP address via DHCP automatically on boot. - For repeaters and room servers, connect to the device on TCP port 23 using any TCP client (e.g. <code>nc &lt;ip&gt; 23</code> or PuTTY in raw mode). This gives you the same CLI available over serial/USB. - For companion radio firmware, the Ethernet interface replaces BLE as the transport to companion apps. Connect on TCP port 5000 (same as the WiFi companion radio). - Use the <code>eth.status</code> CLI command to check connection status and see the assigned IP address.</p>"},{"location":"filter_tool/","title":"Filter policy playground","text":"<p>Build a forwarding policy, see its readable definition, and simulate how a repeater handles a packet. Rules match received packet facts, then apply actions such as dropping, scoping, rate-limiting, or retrying a flood.</p> <p>Everything runs locally in this browser. Channel keys, packet facts, and policy drafts are not uploaded anywhere.</p> Policy design preview <p>     The phases and core conditions model current FPF7 behavior, including its     forward rows, scope rewrites, and shared blacklist. The readable policy     language, JSON, and Base64 bundle are still a prototype: current firmware     is configured with <code>set flood.*</code> commands and cannot install a     bundle from this page.   </p>"},{"location":"filter_tool/#build-a-policy","title":"Build a policy","text":"<p>Start with an example or build a rule, then test the draft against packet facts in the simulator below. The examples draw from Flood Filtering and Moderation.</p> Remote login and direct routes <p>       This policy only decides whether a relay retransmits a flood. Direct       packets and local delivery are unaffected. Rules matching the login/admin       family can still reduce multi-hop remote-login reach, so the analyzer       flags them.     </p> Example policies Choose one to load its full rules into the builder and draft. <p>         Read each summary as <code>when</code> all conditions match,         <code>do</code> the actions. A match alone does not stop forwarding.       </p> Payload selectors <code>type=</code> valueMatches <code>grp_data</code>Only the named payload type; see every exact type below <code>any</code>Every payload type <code>class:group</code>GRP_TXT and GRP_DATA <code>class:login</code>REQ, RESPONSE, TXT_MSG, ANON_REQ, and PATH <code>class:other</code>Every remaining payload type that is not group or login Other conditions and actions FieldMeaning <code>hops=</code>Received hop count: <code>all</code>, <code>3+</code>, <code>2-6</code>, or <code>3</code> <code>channel=</code><code>*</code> means no channel condition; a name or key authenticates one group channel; <code>hash:XX</code> is an unauthenticated one-byte fallback <code>rx.scope=</code>Original incoming transport scope <code>path=</code>Path prefix, blacklist, bucket, or loop match <code>tempradio=</code>Temporary-radio state <code>do drop</code>Do not retransmit <code>do scope=</code>Set the outgoing transport scope <code>do rate=</code>Apply a per-minute rate and burst <code>do timing=</code>Select fast, normal, or slow scheduling <p>         There is no <code>class:txt</code>. Use <code>type=grp_txt</code> for         channel text or <code>type=txt_msg</code> for peer text.       </p> Set #BlackHole86 scope on all #rgdata group traffic <code>when type=class:group hops=all channel=#rgdata do scope=#BlackHole86 timing=fast</code> Add #BlackHole86 scope to unscoped #rgdata data <code>when type=grp_data hops=all channel=#rgdata rx.scope=none do scope=#BlackHole86 timing=fast</code> Replace #usa with #BlackHole86 on #rgdata data <code>when type=grp_data hops=all channel=#rgdata rx.scope=scope:usa do scope=#BlackHole86 timing=fast</code> Rate-limit packets whose path starts with 860C <code>when type=any hops=all path=prefix:860C do rate=10/min burst=10</code> Drop selected flood types at their hop limits <code>when type=control hops=1+ do dropwhen type=req hops=3+ do drop; same for type=grp_datawhen type=response hops=9+ do drop; same for type=anon_req and type=path</code> Rate-limit Public messages from \u201cNoisy User\u201d <code>when type=grp_txt hops=all channel=public sender=\"Noisy User\" do rate=5/min burst=5</code> Stop forwarding traffic from blacklisted internet gateways <code>when type=any hops=all path=blacklist do drop</code> Drop OTA outside temporary-radio mode and distant #wardriving <code>when type=ota hops=all tempradio=inactive do dropwhen type=any channel=#wardriving hops=5+ do drop</code> Set #BlackHole86 scope on login and bucket-matched other traffic <code>when type=class:login hops=all do scope=#BlackHole86 timing=fastwhen type=class:other hops=all path=bucket:2 do scope=#BlackHole86 timing=slow</code> <p>Rule builder</p> Reset form Common match settings            Payload type or class            Any payload type Class: group text and data Class: login/admin family Class: every other payload REQ RESPONSE TXT_MSG ACK ADVERT GRP_TXT GRP_DATA ANON_REQ PATH TRACE MULTIPART CONTROL OTA Reserved type 13 Reserved type 14 RAW_CUSTOM            Received hops                       Channel (optional)                       Original incoming scope                       Path matcher            No path condition Ordered 1/2/3-byte pbyte prefix Passive blacklist Path bucket 1 Path bucket 2 Path bucket 3 Path bucket 4 Path bucket 5 Path bucket 6 Own-ID loop: strict Own-ID loop: moderate Own-ID loop: minimal            Ordered pbyte prefix                       Decrypted sender (optional)                       Temporary-radio state            Either state Inactive Active Common actions <p>         Choosing a phase-specific action automatically selects a compatible         phase and ACL owner. Open the advanced section to inspect or override         those choices.       </p>            Forwarding verdict            No verdict change Drop / do not retransmit            Region-gate decision            Leave global gate unchanged Require original allowed region Bypass global gate for this packet            Scope rewrite target            Do not rewrite scope Regionless public scope Configured region            Target name                       Token rate per minute (optional)                       Burst tokens                       Rewrite timing            Inherit normal behavior Fast-track rewrite Normal queue timing Slow receive/transmit timing            Queue priority            Inherit High Normal Low            Retry path bucket            No retry action Bucket 1 Bucket 2 Bucket 3 Bucket 4 Bucket 5 Bucket 6            Retry attempts                       Decision tag (optional)            Advanced execution, ownership, and flood route <p>           Direct packets already carry a supplied path and are intentionally           outside this engine. The route condition below only distinguishes           unscoped floods from transport-scoped floods.         </p>              Stable rule ID                           Processing phase              1 - Incoming scope gate 2 - Scope rewrite 3 - Forwarding decision 4 - Decrypted content 5 - Scheduling and retry              Rule owner / capability              ACL 4 - Region/scope manager ACL 5 - Filter manager Administrator Firmware-managed system rule              Priority                           Mode              Active Shadow - observe only Disabled              Rule processing after a match              Continue to later rules Skip later rules in this phase Skip all later policy rules              Flood route              Either flood route Unscoped flood only Transport-scoped flood only Readable policy definition <code></code> <p></p> Add rule to policy Copy definition <p>Policy draft</p> Clear policy            Approximate target budget            Compact STM32 - 2 KB nRF52 - 8 KB Classic ESP32 - 16 KB Roomy ESP32 - 64 KB <p>         Rules match the same immutable packet facts. Ordering is phase, then         descending priority, then authenticated channel, raw hash, or wildcard         specificity, then stable rule ID. Drop decisions are sticky.       </p>          Add a rule or load an example to start exploring.        <p>Immutable packet simulator</p> Reset packet Read a raw MeshCore packet <p>             Paste an on-air packet as hexadecimal. The decoder follows the             MeshCore wire format, displays its             header, route, pbyte path, and clear payload envelope, then loads             only facts actually present on the wire into the simulator.           </p> Runs locally          Raw packet hex         014e912ceebb98918b86772df5dacf1bcba9e4127ffffaa8665596aa3e2903a3b1901fdc53497dfca6b5d7df2d771bea68de Decode and load packet          Received route          Unscoped flood Transport-scoped flood          Payload type          REQ RESPONSE TXT_MSG ACK ADVERT GRP_TXT GRP_DATA ANON_REQ PATH TRACE MULTIPART CONTROL OTA Reserved type 13 Reserved type 14 RAW_CUSTOM          Received hops                   Channel                   Received pbyte path                   Original scope status          Unscoped Allowed region Unknown or denied scope          Original scope name                   Resolved region name                   Decrypted sender                   Passive blacklist result          No match Matched          Matching path buckets                   Own-ID loop result          No loop match Strict only Moderate and strict Minimal, moderate, and strict          Temporary radio is active        Run policy simulation <p>Import and explain</p> <p>       Accepts one-line <code>policy set ... when ... do ...</code> definitions,       playground JSON, or a playground Base64 bundle.     </p> Explain input Load into builder <p>Export</p> Readable policy Policy JSON Playground Base64 <p>Proposed human-readable definition. Current firmware does not accept it yet.</p> <p>Structured draft used by this page.</p> <p>Browser-playground interchange only. It is not the final packed firmware codec.</p> Copy visible export Download JSON"},{"location":"filter_tool/#filter-builder-title","title":"Create a policy rule","text":""},{"location":"filter_tool/#filter-policy-title","title":"Rules in execution order","text":""},{"location":"filter_tool/#filter-simulator-title","title":"Explain an evaluation","text":""},{"location":"filter_tool/#filter-import-title","title":"Paste readable policy or a saved draft","text":""},{"location":"filter_tool/#filter-export-title","title":"Move or save this design","text":""},{"location":"filter_tool/#payload-type-reference","title":"Payload type reference","text":"<p>Use an exact <code>type=</code> value when a rule should match only one payload type. The class column shows which broader selector also matches it.</p> <code>type=</code> value Payload Class <code>req</code> Request <code>class:login</code> <code>response</code> Response <code>class:login</code> <code>txt_msg</code> Peer text message <code>class:login</code> <code>ack</code> Acknowledgment <code>class:other</code> <code>advert</code> Node advertisement <code>class:other</code> <code>grp_txt</code> Group-channel text <code>class:group</code> <code>grp_data</code> Group-channel datagram <code>class:group</code> <code>anon_req</code> Anonymous request <code>class:login</code> <code>path</code> Returned path <code>class:login</code> <code>trace</code> Path trace <code>class:other</code> <code>multipart</code> One frame in a multipart sequence <code>class:other</code> <code>control</code> Control or discovery data <code>class:other</code> <code>ota</code> OTA-over-LoRa data <code>class:other</code> <code>13</code> Reserved payload type 13 <code>class:other</code> <code>14</code> Reserved payload type 14 <code>class:other</code> <code>raw_custom</code> Application-defined raw data <code>class:other</code>"},{"location":"filter_tool/#current-fpf7-command-mapping","title":"Current FPF7 command mapping","text":"Firmware command FPF7 role <code>flood.rule</code> / <code>flood.filter</code> Forward-phase match and action rows <code>flood.channel.data</code> Compatibility view over one visible <code>type=grp_data</code> forward drop row <code>flood.channel.scope</code> Scope-rewrite phase rows <code>flood.filter.blacklist</code> One shared unordered path-ID set referenced by <code>path=blacklist</code> rows <p>Generalized repeaters expose 63 forward rows and commit those sections together. The blacklist is useful for refusing to retransmit floods associated with internet gateways dumping bulk traffic, but a path ID is truncated and unauthenticated; it identifies a routing pattern, not a person.</p>"},{"location":"filter_tool/#proposed-evaluation-contract","title":"Proposed evaluation contract","text":"<p>The simulator uses these rules:</p> <ol> <li>Only flood retransmission enters the policy. Direct routing and local packet    delivery remain outside it.</li> <li>Every matcher reads the same immutable receive-time packet facts.</li> <li>Rules run by phase and descending numeric priority. At an equal priority,    authenticated channel matches run before raw one-byte hash matches, which    run before wildcard channel matches; stable rule ID breaks the remaining    tie. An explicitly higher numeric priority overrides channel specificity.</li> <li>A drop decision is sticky and cannot be undone by a later rule.</li> <li>The first matching scope, timing, queue, and retry action in execution order    wins.</li> <li>All matching token-bucket rate constraints remain attached to the decision.</li> <li><code>stop=phase</code> skips later rules in that phase. <code>stop=policy</code> skips later    configurable rules, but never mandatory packet validation or radio safety.</li> <li>Shadow rules report what they would do without changing the decision or    stopping other rules.</li> <li>Expensive facts such as channel-key matching, decryption, and path-table    lookup are resolved once per packet and reused by every matching rule.</li> </ol> <p>The byte-budget display is deliberately approximate until the packed firmware codec exists. It demonstrates why simple mappings should not reserve a maximum- sized structure for every possible condition and action.</p>"},{"location":"firmware_picker/","title":"Firmware picker","text":"<p>Pick the choices in any order. Every selection narrows all the other controls to firmware combinations that were actually built in the current release set.</p> <p>The picker reads public release metadata from GitHub. It does not upload device information. Hardware names, target names, and download links come directly from the published firmware assets.</p> Current release set <p>Loading release information...</p> <p>       For a new installation, choose the exact board and role, prefer a       FULL / complete profile when it is available, and select       Erase &amp; fresh install (merged .bin). Narrower profiles       remain available when their reduced transport or feature set is intentional.     </p> <p>     Pick in any order. Use Any to clear one choice, or clear     everything with the button below.   </p> Hardware Loading hardware... Hardware variant Choose hardware first Install operation          Loading install choices...        Firmware role          Loading roles...        Logging / MQTT          Loading logging choices...        OTA capability          Loading OTA choices...        Connection / bridge mode Loading modes... Feature profile          Loading profiles...        Firmware variant Loading variants... Clear all choices      Loading the current firmware catalog...    <p>Exact firmware match</p> Recommended download <p></p> No exact firmware matched <p></p> Browse all firmware releases Advanced: search current release filenames <p>       Use this for uncommon board suffixes or expert recovery. A filename match       is not a board-identity check.     </p>        Filename contains"},{"location":"firmware_picker/#what-the-choices-mean","title":"What the choices mean","text":"Choice Use Companion A phone, computer, or host application controls the radio Repeater Standalone mesh relay Room Server Hosts room conversations and history Sensor / telemetry Publishes supported sensor data Terminal Chat Standalone serial-terminal interface USB logging / USB-connected MQTT Node remains attached to a computer over a data-capable USB cable Wi-Fi MQTT observer Firmware connects directly to MQTT over Wi-Fi; this is not USB logging USB logging + Wi-Fi MQTT Unified FULL image sends to both paths; avoid two publishers aimed at the same broker unless messages are deduplicated No logging Normal standalone operation without the dedicated logging/MQTT profile LoRa OTA repeater Repeater profile that can stage an exact matching update received over LoRa LoRa OTA source only Full Companion serving a host-supplied update to another node without self-installing it <p>Connection and bridge choices depend on the selected role. Companion firmware may offer Full, combined USB + Bluetooth, Bluetooth, USB, Wi-Fi, serial, or Ethernet transports. Normal repeater firmware includes runtime-controlled RS-232 support where the board has room; use <code>set bridge.enabled on</code> after configuring <code>bridge.uart</code> and <code>bridge.baud</code>. The Wio-E5 remains the capacity exception and offers a separate RS-232 image. Choose Wi-Fi MQTT under Logging / MQTT; it is an output mode, not a second connection choice. Repeaters may still offer separate ESP-NOW or Ethernet bridge firmware because those paths use different compiled drivers.</p> <p>An ESP-NOW bridge target keeps LoRa as its primary mesh radio. Its runtime <code>bridge.format</code> setting chooses the peer protocol: <code>wrapped</code> (the backward-compatible bridge-to-bridge default using <code>bridge.secret</code>) or <code>raw</code> (direct MeshCore ESP-NOW LR frames for <code>Generic_ESPNOW</code>, <code>SenseCapIndicator-ESPNow</code>, and other primary-ESP-NOW nodes). This is one firmware choice, not two board images. Match <code>bridge.channel</code> to the primary nodes' <code>espnow.channel</code> before selecting <code>set bridge.format raw</code>. For Heltec V4 specifically, <code>companion_radio_full</code> is still a LoRa-primary Companion; choose the existing <code>heltec_v4_repeater_bridge_espnow</code> firmware to make that board the LoRa/ESP-NOW gateway. Use its exact merged artifact when changing roles or partition layouts.</p>"},{"location":"firmware_picker/#full-versus-standard","title":"FULL versus standard","text":"<p>For a new installation, use the FULL / complete profile when it exists and the board has enough flash. FULL profiles keep the complete supported feature set and CLI. Standard profiles remain useful for boards without a FULL build, for an intentionally narrower transport, or when retaining an existing compatible partition layout.</p> <p>Changing between standard and FULL ESP32 layouts requires the exact-board merged image over USB. A running application cannot safely move its own active and inactive partitions.</p> <p>Current <code>full-usb-wifi</code> profiles use one binary for no external output, USB packet logging/USB-connected MQTT, direct WiFi MQTT, or both. The picker shows that same exact binary for each compatible logging choice; select the saved runtime mode with <code>set logging.output off|usb|wifi|both</code>. A FULL logging-fallback profile is listed only when no WiFi MQTT sibling exists; it appears for both the no-output and USB choices because <code>set usb.logging off|on</code> is persistent. On a fresh unified FULL install with no saved SSID, the setup AP and WiFi radio remain available for 30 minutes per boot, then turn off automatically until the next reboot or power cycle. An explicit administrator <code>start webconfig</code> remains available as an override. A saved SSID switches to the normal indefinite reconnect behavior instead.</p> <p>Full Companion profiles use one binary for USB, BLE, ordinary Wi-Fi on ESP32, source-only LoRa OTA, Terminal Chat, optional USB packet logging, and any board-qualified serial or Ethernet Companion transport. Bulk builds therefore omit separate attached-transport, Terminal Chat, and USB-logging artifacts whenever the exact Full recipe exists. RAK4631 repeater and room-server Ethernet images remain separate roles. Fresh installs default to logging off. Heltec V3 and base OLED V4 Full images also contain the former direct Wi-Fi MQTT Companion capability, configured at runtime through WebConfig, so their separate <code>companion_radio_wifi_mqtt</code> artifacts are omitted from canonical builds as well.</p> <p>When Full Companion does not fit but a matching USB Companion does, that USB artifact also supplies Terminal Chat and replaces its standalone release image. Heltec E290 and T190 now publish one Full USB + BLE + WiFi Companion; their old combined and single-transport names are explicit-build compatibility aliases. SSD1306 Full Companion builds use <code>set display.rotation 90|180|270</code>; <code>0</code> restores the board default, so a separate rotated release image is not recommended.</p> <p>Ordinary non-OTA roles also use one artifact for normal operation and USB logging. Select the saved mode with <code>set usb.logging off|on</code>; no <code>-logging-</code> artifact is emitted. KISS, BLE-only Companion, and constrained LoRa OTA repeater images retain their protocol/partition contracts and do not inherit plaintext USB logging.</p> <p>nRF52 Full Companion keeps the multi-role primary interface on <code>00</code>; it starts as an ASCII terminal and automatically hands a complete <code>&lt;</code> frame to Binary Companion. <code>set usb.logging on reboot</code> adds its plaintext interface <code>02</code>.</p> <p>Every ESP32 Full Companion instead exposes one USB TTY. Logging is off by default, so the TTY serves the ASCII/Binary Companion switcher. Use <code>set usb.logging on</code> to turn that same TTY into an input-capable plaintext CLI/logging stream; framed Binary Companion is unavailable on USB while logging owns it. <code>set usb.logging off</code> stops the logs and leaves the TTY in the normal ASCII terminal, matching a fresh Full installation. Send <code>+++MESHCORE-TERM-STOP</code>, or let a Companion app send a valid framed probe, to switch from there to Binary Companion. BLE and Wi-Fi Companion remain usable while the USB TTY is logging. ESP32 Full builds use the repository's Arduino-ESP32 2.x base where the board supports it; RC32 and ESP32-C6 retain their board-required Arduino 3.x platform but still expose only one USB TTY. A second ESP32 CDC interface is not part of the release profile.</p>"},{"location":"firmware_picker/#installation-methods","title":"Installation methods","text":"File Use <code>-merged.bin</code> Erase/fresh install, recovery, role migration, or partition-profile change on ESP32 over USB Non-merged <code>.bin</code> Update an existing same-board, same-role, same-partition installation <code>.zip</code> Native nRF52 Serial DFU update package; it is not an extra archive <code>.uf2</code> UF2 bootloader drag-and-drop install or update <code>.hex</code> Erase/recovery flash with a supported wired programmer <p>Never send a merged ESP32 image through browser OTA or LoRa OTA. Back up the node configuration and verify every filename suffix before flashing.</p>"},{"location":"firmware_picker/#lora-ota-and-otafix","title":"LoRa OTA and OTAFIX","text":"<p>A LoRa OTA repeater build installs repeater firmware that can receive and stage updates. A later LoRa update still needs an exact target identity, compatible partition signature, matching radio settings, and the correct update package.</p> <p>nRF52 LoRa OTA requires an OTAFIX bootloader built for the exact board. There is no universal bootloader file. Use the latest stable OTAFIX release and select the hardware-matched HEX, Serial DFU ZIP, or bootloader-update UF2.</p>"},{"location":"firmware_picker/#hardware-and-variant-names","title":"Hardware and variant names","text":"<p>Hardware families with multiple released targets get a second hardware-variant menu. It separates revisions, display type, expansion kit, radio/PA layout, pin map, and other physical differences without crowding the first menu. The firmware-variant menu separately exposes choices that still require different code or wiring, such as serial port or the legacy <code>no_external_sensors</code> target suffix. The picker labels that suffix Reduced optional environmental/ranging drivers: it does not disable generic I2C or unrelated board-integrated peripherals. Reduced RAK3401 and RAK4631 targets retain INA219/INA226/INA260/INA3221 as voltage/current entries in the optional sensor table. They are not the only I2C users: the SSD1306 OLED, supported autodiscovered RTCs, and RAK12500 GPS remain separate I2C peripherals in compatible recipes. RAK12501/L76K GPS uses Serial1 instead. The explicit RAK4631 Serial1 bridge omits the combined GPS provider because its bridge owns the RAK12501 UART, so that legacy image does not expose RAK12500 either. The firmware-configured INA3221 and RAK12500 addresses are both <code>0x42</code>; to install both, keep RAK12500 at <code>0x42</code>, strap INA3221 A0 to SCL for <code>0x43</code>, and use a build with <code>-DTELEM_INA3221_ADDRESS=0x43</code>. Companion power saving, controllable FEM receive gain, and radio-chip receive gain are saved settings rather than separate recommended firmware files. Do not substitute a similarly named physical target.</p> <p>The header-wired RAK19007 W25Q16 LoRa-OTA recipes are also exact hardware variants. Choose the W25Q16 variant for RAK4631 or for RAK3401 + RAK13302 only when that core/radio combination, the <code>EF4015</code> flash wiring, and its matching OTAFIX bootloader are all present. The common base-board wiring does not make the two firmware or bootloader identities interchangeable.</p> <p>The picker recommends one Full Companion image instead of separate USB, BLE, ordinary WiFi, and USB-logging images. On ESP32, logging is off by default so the one USB TTY starts in ASCII and automatically changes to framed Companion when a complete <code>&lt;</code> frame arrives. Enabling logging gives that TTY to the plaintext CLI/logger and disables framed USB Companion until logging is turned off and the normal ASCII-to-binary mode switch occurs. nRF52 Full Companion retains its optional dedicated interface <code>02</code>. Exact filename search still finds old aliases from earlier releases.</p>"},{"location":"flood_filtering/","title":"Flood Filtering and Moderation","text":"<p>This guide explains the Keymind forwarding filters. Repeaters expose the full set of channel, rule, blacklist, and moderation controls described here. FULL-profile ESP32 room servers expose the generalized <code>flood.rule</code> table (and its <code>flood.filter</code> alias) with 31 forward-rule slots, but not the repeater's scope-rewrite, passive-blacklist, or text-moderation phases. Standard room-server profiles do not compile the rule table. Filters decide whether the node retransmits a packet and can assign a transport scope before that decision. They do not stop local reception, packet logging, or MQTT observation.</p> <p>Only flood routes are filtered:</p> <ul> <li><code>0x00</code> / <code>ROUTE_TYPE_TRANSPORT_FLOOD</code> - flood routing with transport codes</li> <li><code>0x01</code> / <code>ROUTE_TYPE_FLOOD</code> - unscoped flood routing</li> </ul> <p>Direct routes <code>0x02</code> and <code>0x03</code> are never affected by these rules. The route and payload values follow the upstream packet-format reference and payload layouts, with this fork's LoRa OTA assignment noted below.</p>"},{"location":"flood_filtering/#before-making-changes","title":"Before making changes","text":"<p>On a repeater, show the current forwarding controls:</p> <pre><code>get repeat\nget flood.max\nget flood.max.unscoped\nget flood.max.advert\nget flood.channel.data\nget flood.channel.data.hops\nget flood.channel.scope\nget flood.channel.scope.require\nget flood.filter\nget flood.rule\nget flood.filter.blacklist\nget flood.moderation\n</code></pre> <p><code>flood.rule</code> is an alias for <code>flood.filter</code>, not another table. Generalized repeater FPF7 has 63 forward-rule slots plus scope-rewrite and shared-blacklist sections in the same atomic policy file. FULL room servers have 31 forward slots and empty repeater-only sections. Compact target profiles retain their separate FPF6-era controls. <code>flood.moderation</code> has 16 slots. A new repeater FPF7 table starts with <code>ota all suspend=tempradio</code> in slot 1 and an authenticated <code>#wardriving hops=5+</code> drop in slot 2; FULL room servers seed only the OTA row. <code>flood.moderation</code> starts empty. A row can opt into <code>suspend=tempradio</code>; temporary radio is not synonymous with OTA and can carry normal packet types too. A corrupt or truncated table fails open, so corrupt storage does not silently enable blocking.</p> <p>On a FULL ESP32 room server, use <code>get flood.rule</code> (or <code>get flood.filter</code>) for the available table. Remote rule changes require room-server administrator access. <code>flood.filter.blacklist*</code> and <code>path=blacklist</code> are repeater-only; use the ordered <code>prefix=</code> condition on a room server.</p>"},{"location":"flood_filtering/#force-floods-into-a-transport-scope","title":"Force floods into a transport scope","text":"<p><code>flood.channel.scope</code> can add a scope to a received unscoped flood or replace the scope of a transport-scoped flood before this repeater forwards it:</p> <pre><code>set flood.channel.scope &lt;channel|txt:*|login:*|other:*&gt; &lt;region|scope=name&gt; [path=blacklist|path=bucket:1-6] [tx=slow]\nset flood.channel.scope.&lt;slot&gt; &lt;channel|txt:*|login:*|other:*&gt; &lt;region|scope=name&gt; [path=blacklist|path=bucket:1-6] [tx=slow]\nget flood.channel.scope\nget flood.channel.scope.&lt;slot&gt;\ndel flood.channel.scope.&lt;slot&gt;\ndel flood.channel.scope all\n</code></pre> <p>The channel may be <code>public</code>, <code>#channel</code>, or a 128/256-bit hex key. A bare target names an existing region with a usable transport key. Use <code>scope=&lt;name&gt;</code> instead to derive a regionless public hashtag scope exactly as <code>flood.filter scope=&lt;name&gt;</code> does. The direct name is normalized with a leading <code>#</code>, may contain up to 30 characters, and does not need a region-list entry. Keyed rules first check the one-byte channel hash carried in the packet, then validate the MAC by decrypting with the configured channel key. A hash collision alone cannot force a scope.</p> <p>For example, this authenticates only <code>#rgdata</code> and rewrites it to <code>#BlackHole86</code> without creating a region:</p> <pre><code>set flood.channel.scope #rgdata scope=BlackHole86\nget flood.channel.scope.1\n</code></pre> <p>If that channel arrives scoped to <code>#usa</code>, the rule replaces <code>#usa</code> with <code>#BlackHole86</code>. It also handles unscoped packets and replaces any other incoming scope; the source scope is not a condition on the rule.</p> <p>Add <code>path=blacklist</code> to make a channel-scope row eligible only when the received path matches the passive <code>flood.filter.blacklist</code> ID table. It does not require an enabled <code>flood.filter</code> drop row. With 3-byte paths, one exact listed ID qualifies. With 2-byte paths, two received path entries must match the first two bytes of listed IDs. A 1-byte path never qualifies.</p> <p>Use <code>path=bucket:&lt;1-6&gt;</code> to match one of the existing <code>flood.retry.bucket</code> tables instead. Each bridge bucket holds up to 17 three-byte IDs and remains usable by channel scoping while <code>flood.retry.bridge</code> is off. Bucket matching uses the same thresholds as the blacklist: one exact hit for 3-byte paths, two qualifying entries for 2-byte paths, and no matches for 1-byte paths. Channel scoping reads the configured IDs directly; <code>recent.repeater</code> freshness and <code>flood.retry.ignore</code> do not change this match.</p> <p>There are three independent wildcard classes:</p> <ul> <li><code>txt:*</code> handles otherwise-unmatched <code>GRP_TXT</code> and <code>GRP_DATA</code>; plain <code>*</code> is   its alias.</li> <li><code>login:*</code> handles <code>REQ</code>, <code>RESPONSE</code>, <code>TXT_MSG</code>, <code>ANON_REQ</code>, and <code>PATH</code>.</li> <li><code>other:*</code> handles every remaining flood payload type, including flood-form   TRACE and OTA.</li> </ul> <p><code>login:*</code> and <code>other:*</code> classify only the visible outer payload type; they do not authenticate its contents. Exact channel rows with usable targets always take precedence over <code>txt:*</code>, even if that wildcard has a lower slot number. Within the exact class, matching path-qualified rows are tried before ordinary fallback rows. The same qualified-then-fallback order applies within each wildcard class. A missing or unusable target is skipped, so later rows remain eligible. The lowest usable slot wins within each priority tier.</p> <p>For example, this uses bridge bucket 1 to assign <code>east</code> to <code>public</code> packets whose received 3-byte path contains <code>7576FB</code>, and assigns <code>west</code> to all other authenticated <code>public</code> packets:</p> <pre><code>set flood.retry.bucket 1 7576FB\nset flood.channel.scope public west\nset flood.channel.scope public east path=bucket:1\n</code></pre> <p>More 3-byte IDs can be added to bucket 1 later. Any one of them qualifies the <code>east</code> row. Replacing or clearing that bucket changes which paths qualify but leaves both channel-scope rows intact. Bridge retry does not need to be enabled.</p> <p>On a successful match, an unscoped route changes from <code>ROUTE_TYPE_FLOOD</code> to <code>ROUTE_TYPE_TRANSPORT_FLOOD</code>; an already-scoped route remains transport-flood but receives replacement codes. Transport code 0 is calculated with the target region or direct hashtag key over the payload type and payload, and code 1 becomes zero. The change happens before region enforcement, forwarding filters, and deduplication. Consequently <code>flood.max.unscoped</code> no longer applies to a packet converted from unscoped, while <code>flood.max</code>, <code>flood.filter</code>, loop detection, and moderation still apply to every rewritten packet. A region target must be flood-allowed. A regionless target is trusted for this matched receive pass, but it neither creates a region nor changes how unrelated packets with the same transport code pass the region gate. By default, if the selected scope differs and the rewritten packet passes those checks, its initial retransmission uses zero <code>txdelay</code> and the highest outbound queue priority so the newly scoped copy can win at the next hop. Add <code>tx=slow</code> to use an effective inbound <code>rxdelay</code> base of <code>max(2, configured rxdelay * 2)</code>, retain normal outbound queue priority, and force the maximum <code>txdelay</code> factor of <code>2.0</code>. The actual transmit delay is still randomized, from zero through ten packet airtimes. It does not preempt an active radio transmission or bypass CAD and airtime-budget limits. Selecting the scope already present is a no-op and does not grant special treatment.</p> <p>Direct routes are never rewritten. Standard traceroute is direct-routed and therefore remains outside this flood-only table. A custom flood-form TRACE is treated like every other flood: an applicable wildcard may rewrite it and the normal region/unknown-code gates still apply. Scope assignment does not override normal payload validation or make an otherwise non-forwardable packet type forwardable.</p> <p>LoRa OTA (<code>0x0C</code>) falls under <code>other:*</code>. A matching row adds the selected transport code or replaces the existing one, but OTA still operates normally during the temporary-radio window because the OTA handler accepts both unscoped and transport-scoped flood routes. A region target must allow flooding; a direct target uses the regionless trust behavior above. A new repeater also seeds <code>ota all suspend=tempradio</code> in flood-filter slot 1. That visible rule blocks OTA forwarding at every received hop outside temporary-radio operation and is skipped while temporary radio is active. Independently, the OTA core refuses OTA receive, relay, and transmit outside an actually active temporary-radio window, even if the seeded row is deleted or replaced.</p> <p>Capacity is selected at build time:</p> <ul> <li>Roomy ESP32 builds: 255 rewrite slots and 32 regionless-target slots, 10,204   bytes RAM.</li> <li>DRAM-tight classic ESP32 LoRa-OTA repeaters, nRF52, and other normal   constrained builds: 31 rewrite and regionless-target slots, 2,108 bytes RAM.</li> <li>Very-tight STM32WL builds: 15 rewrite slots and one reusable regionless-target   slot, 572 bytes RAM.</li> <li>The no-PSRAM LilyGo T-LoRa V2.1 repeater/observer: 4 rewrite and   regionless-target slots, 272 bytes RAM. This minimum holds the   three wildcard classes and one exact channel mapping.</li> </ul> <p>Each rule retains its 36-byte record. A separate table holds 32-byte normalized names for up to the smaller of the rule count or 32 distinct regionless targets, except that very-tight STM32WL builds retain one reusable direct target. Both configured regions and regionless targets can be reused by any number of rules.</p> <p>On generalized builds these records are the FPF7 rewrite phase, and the file stores only through the highest occupied slot. Compact FPF6 builds retain the standalone FCS5 file and the file sizes described by their build profile.</p>"},{"location":"flood_filtering/#require-valid-incoming-scopes-only-on-selected-channels","title":"Require valid incoming scopes only on selected channels","text":"<p><code>flood.channel.scope.require</code> changes region enforcement for received flood <code>GRP_TXT</code> and <code>GRP_DATA</code> packets from a global policy to a channel opt-in policy:</p> <pre><code>set flood.channel.scope.require &lt;public|#channel|128/256-bit-key&gt;\nset flood.channel.scope.require.&lt;slot&gt; &lt;public|#channel|128/256-bit-key&gt;\nget flood.channel.scope.require\nget flood.channel.scope.require.&lt;slot&gt;\ndel flood.channel.scope.require.&lt;slot&gt;\ndel flood.channel.scope.require all\n</code></pre> <p>An empty table preserves the normal global region behavior. Once at least one row exists, a group-channel packet that authenticates against a listed key must arrive as <code>ROUTE_TYPE_TRANSPORT_FLOOD</code> with a transport code matching a locally flood-allowed region. An unscoped packet, an unknown transport code, or a code for a denied region is not retransmitted. The check uses the original incoming scope before <code>flood.channel.scope</code> or <code>flood.filter scope=</code> can rewrite it. Those rewrite actions are skipped for a rejected listed channel, so they cannot rescue it or grant special receive/transmit timing.</p> <p>Group-channel packets that do not authenticate against any listed key bypass the region/unknown-code forwarding gate. They still pass through <code>repeat</code>, <code>flood.max*</code>, <code>flood.filter</code>, loop detection, payload validation, and moderation. Non-channel flood payload types retain the normal global region behavior. A one-byte channel-hash collision is only a prefilter; the packet must also pass MAC validation/decryption with the configured key.</p> <p>Without <code>.slot</code>, setting an existing key updates its row and a new key uses the first empty row. Numbered <code>set</code> replaces that slot. Detail output displays only the first four derived hash bytes and key size, never the secret. The table has the same build-dependent slot count as <code>flood.channel.scope</code>; each row consumes 34 bytes of RAM and storage, plus a five-byte file header. ACL permission <code>4</code> can manage it.</p> <p>For example, this requires an allowed incoming scope on <code>#bot</code>, while every other group channel bypasses region enforcement:</p> <pre><code>set flood.channel.scope.require #bot\nget flood.channel.scope.require\n</code></pre>"},{"location":"flood_filtering/#interaction-with-duplicate-detection","title":"Interaction with duplicate detection","text":"<p>The seen-packet hash contains the payload type and exact payload bytes. It does not contain the route type, either transport code, or the ordinary flood path. For <code>TRACE</code> only, the encoded <code>path_len</code> byte is also included. Therefore an unscoped packet and the same packet after this repeater adds a transport code are the same duplicate. A later copy with a different scope is also the same duplicate; changing or adding scope cannot evade the seen table.</p> <p>When equivalent non-TRACE flood copies overlap in <code>rxdelay</code>, the normal receive-quality timing still chooses the packet to process, but that winner takes a scope from the queued copies whose transport code matches an allowed region in this repeater. Unknown and denied scopes are ignored. If eligible copies have different scopes, the shortest received path supplies the scope. Equal path lengths prefer the deepest matching child region (the narrowest configured scope). A remaining tie keeps queue order. The winner keeps its own path, SNR, and delay schedule; only its route and transport codes can change, including replacement of a less-preferred scope it already carried.</p> <p>Scope selection happens at dequeue so the original scopes remain available for comparison. It applies only while copies are queued and cannot alter a copy already processed into the seen table. Flood-form TRACE participates in the same arbitration. Direct traceroute never enters this flood queue.</p> <p>A packet that already matches a configured fast <code>flood.channel.scope</code> or <code>flood.filter scope=</code> action and needs its scope changed bypasses this inbound <code>rxdelay</code> queue entirely. A <code>tx=slow</code> row remains in the queue with twice the configured base, floored at <code>2.0</code>, and participates in normal queued-copy scope arbitration.</p>"},{"location":"flood_filtering/#runtime-flood-rules","title":"Runtime flood rules","text":"<p>On repeaters with the rule engine enabled and on FULL-profile ESP32 room servers, <code>flood.rule</code> and <code>flood.filter</code> are two names for the same persistent table. The evaluator is fixed firmware, but every row is data, so an authenticated operator can add, replace, inspect, or delete a row without an OTA or reboot. Existing <code>flood.filter</code> commands remain compatible. Only FPF6 and FPF7 files are accepted; FPF1-FPF5 files are rejected and filtering fails open. A row saved by the extended engine uses FPF7. Older firmware cannot preserve an FPF7 table containing the packed <code>retry</code> action or one-byte <code>hash:XX</code> matcher; remove those rows before downgrading.</p> <p>The former <code>flood.channel.block</code> table is now represented by ordinary FPF7 rows. On a generalized repeater, an existing FCB2 file is imported once into free FPF7 slots and then removed. For example, an old <code>#wardriving h=4</code> row becomes <code>type=any channel=#wardriving hops=5+ drop</code>. The 63-row table can hold all 31 former general filter rows, all 15 legacy channel-block rows, and the migrated global <code>flood.channel.data</code> gate. Compact STM32WL FPF6 builds cannot match authenticated channels and retain the older separate gate.</p> <p>On generalized repeaters, <code>flood.channel.data*</code> is a compatibility view over one ordinary visible FPF7 <code>type=grp_data ... drop</code> row. Turning it off creates or updates that row; turning it on removes the row. Its hop setting maps to <code>hops=all</code> or <code>hops=N+1+</code>. There is no hidden GRP_DATA forwarding check ahead of FPF7. Normal ordering applies, so a matching higher-priority <code>stop</code> row can exempt selected traffic. The compact rule list marks the managed row with <code>~data</code>.</p> <p>FPF7 binds <code>in=region:&lt;name&gt;</code> and <code>region=&lt;name&gt;</code> to canonical region names, not numeric region IDs. Removing, reordering, or reusing a region ID cannot silently redirect a rule. If the saved name is missing, an input-region match does not match and a target-region rewrite is skipped. Re-adding the same name reactivates the rule.</p> <p>The extended form is:</p> <pre><code>set flood.rule[.&lt;slot&gt;] type=&lt;type&gt; [hops=&lt;range&gt;] [channel=&lt;channel&gt;]\n    [prefix=&lt;ID[,ID...]&gt;] [in=&lt;input-scope&gt;] &lt;action&gt; [rate=&lt;N&gt;/min]\n    [priority=&lt;0-255&gt;] [stop] [tx=fast|slow] [suspend=tempradio]\nget flood.rule\nget flood.rule.&lt;slot&gt;\ndel flood.rule.&lt;slot&gt;\ndel flood.rule all\n</code></pre> <p>The command must be entered on one line. Match fields in one row are ANDed. Every row is matched against the same immutable packet state captured on receive, before any rule rewrites its scope. Matching rows are then processed by descending numeric <code>priority</code>. At an equal numeric priority, authenticated channel matches run before raw <code>hash:XX</code> matches, raw hashes run before <code>channel=*</code>, and lower slot number breaks the remaining tie. Priority defaults to <code>0</code>; an explicitly higher numeric priority overrides specificity.</p> <p>The first matching <code>stop</code> row ends the FPF7 forward phase after that row. Higher-order matches and the stop row still apply; lower-order matches do not. A stop-only row is therefore an exception to lower-priority FPF7 rows. It cannot undo a higher-priority drop and it does not bypass hard forwarding gates or the scope-rewrite and moderation phases. Without a stop row, matching drop and rate rows remain independent and the highest-order matching scope or region rewrite wins.</p> <p>Match fields:</p> <ul> <li><code>type=</code> accepts the same packet names and numeric values as legacy   <code>flood.filter</code>. The positional form remains accepted.</li> <li><code>hops=</code> accepts <code>all</code>, <code>N</code>, <code>N+</code>, or <code>N-M</code>. The positional form remains   accepted. Received hops over 3 are written as <code>hops=4+</code>.</li> <li><code>channel=*|public|#name|hash:XX|128-bit-key|256-bit-key</code> optionally narrows by   channel. <code>channel=*</code> is an unconstrained wildcard: it performs no channel   authentication and matches every payload selected by <code>type=</code>. Thus   <code>type=any channel=*</code> means every flood payload type. <code>public</code>, <code>#name</code>, and   raw keys authenticate one channel and narrow the row to <code>GRP_TXT</code> or   <code>GRP_DATA</code>. <code>hash:XX</code> compares only the visible one-byte group-channel hash.   <code>short:XX</code> and a bare two-digit byte are aliases; saved output uses   <code>hash:XX</code>. This matcher is unauthenticated, has a 1-in-256 collision space,   and can be selected by a sender, so prefer an exact name or key when known.   <code>hash:11</code> is not an alias for Public: it includes Public and every <code>0x11</code>   collision, while <code>public</code> verifies and decrypts with the Public key. This is   channel authentication, not sender authentication: the group MAC is two   bytes and the Public key is shared.</li> <li><code>prefix=</code> is a source-path prefix containing one to three comma-separated   pbyte IDs. Every ID must use the packet's pbyte width: 2, 4, or 6 hex   characters for 1-, 2-, or 3-byte paths. Order matters and matching begins at   the first received path entry. <code>path=&lt;prefix&gt;</code> is an alias;   <code>path=blacklist</code> retains its separate unordered-list behavior.</li> <li><code>in=any|none|scoped|allowed|unknown|scope:&lt;name&gt;|region:&lt;name&gt;</code> tests the   original incoming route before any rewrite. <code>none</code> means an unscoped flood;   <code>scoped</code> means any transport flood; <code>scope:name</code> compares the exact public   hashtag-derived scope; and <code>region:name</code> compares an allowed configured   region. <code>allowed</code> is the legacy <code>require=region</code> test and includes an   unscoped packet when the wildcard region allows it. <code>unknown</code> means a scoped   packet that does not resolve to an allowed local region.</li> </ul> <p>Actions:</p> <ul> <li><code>drop</code> prevents retransmission when the row matches. The strict   <code>flood.rule</code> form requires an explicit action. For backward compatibility,   only a legacy <code>flood.filter</code> row with no rewrite, rate, or stop action means   drop implicitly.</li> <li><code>scope=&lt;name&gt;</code> derives a public transport scope directly from the name; no   region entry is consulted. <code>scope=BlackHole86</code> is therefore a valid   regionless sink. <code>region=&lt;name&gt;</code> is different: it resolves a configured,   flood-allowed region and one of that region's transport keys.</li> <li>A <code>stop</code> on a row whose <code>region=</code> target is currently unusable is also inert,   allowing lower-priority safety rules to run. Direct <code>scope=</code> targets do not   have this configuration dependency.</li> <li><code>rate=N/min</code> is a per-node, per-row fixed one-minute forwarding limit. It can   stand alone or accompany a scope/region rewrite. Quota is charged only after   every other forwarding gate, including moderation, accepts the packet. It is   not keyed per sender; use <code>flood.moderation</code> when a group-text rate must be   tied to an exact display name.</li> <li><code>retry</code> allows a matching received flood to start the configured retry   sequence. <code>retry=on</code>, <code>retry=allow</code>, and <code>action=retry</code> are aliases. If the   table has no active <code>retry</code> rows, global retry behavior is unchanged. If it   has one or more, those rows are a retry allow-list: at least one must remain   in the ordered, stop-truncated match set. The action may accompany rewrite,   rate, or stop, but not <code>drop</code>; its compact flag is <code>f=r</code>.</li> <li><code>priority=0-255</code> controls the primary processing order. Higher values run   first. Equal values use automatic channel specificity (authenticated, then   raw hash, then wildcard) before slot order. <code>pri=</code> is the compact alias.</li> <li><code>stop</code> (or <code>action=stop</code>) applies this row and prevents lower-order FPF7 rows   from acting. It can stand alone or accompany drop, rewrite, or rate.</li> </ul> <p>When several rows use the same channel key, authentication is performed once for that packet and reused by those rows. This cache lives only for the current receive evaluation; it is not persisted and never stores plaintext or a password. A <code>hash:XX</code> row deliberately skips authentication and uses only the one visible byte.</p> <p>The global retry controls remain hard gates. A <code>retry</code> row does not override a zero <code>flood.retry.count</code>, path/type attempt caps, disabled forwarding, <code>flood.retry.advert</code>, a drop verdict, or any other forwarding rejection. <code>flood.retry.bridge</code> independently chooses ordinary retry or bridge-bucket completion for an allowed packet. The selector applies to received floods; locally originated floods retain the normal global behavior.</p> <p>The exact requested examples are:</p> <pre><code># If #rgdata arrives unscoped with more than 3 received hops, add\n# the regionless #BlackHole86 scope.\nset flood.rule.2 type=grp_data hops=4+ channel=#rgdata in=none scope=BlackHole86\n\n# Rewrite the exact incoming #usa scope to #BlackHole86 for #rgdata.\nset flood.rule.3 type=grp_data channel=#rgdata in=scope:usa scope=BlackHole86\n\n# Match a two-byte source-path prefix and cap forwarding at 10 per minute.\nset flood.rule.4 type=any prefix=860C rate=10/min\n\n# Keep authenticated #rgdata at two hops or less out of lower-priority FPF7\n# rules. Hard gates and separate tables still apply.\nset flood.rule.5 type=grp_data hops=0-2 channel=#rgdata priority=200 stop\n\n# Retry received Public and #hamradio floods, using bridge completion.\n# Once these rows exist, other received floods are not retried.\nset flood.retry.bridge on\nset flood.rule.6 type=any channel=public retry\nset flood.rule.7 type=any channel=#hamradio retry\n\n# Fall back to an unauthenticated one-byte match if only the visible hash is known.\nset flood.rule.8 type=any channel=hash:A7 retry\n\nget flood.rule.2\nget flood.rule.3\nget flood.rule.4\n</code></pre> <p>Public's visible channel hash is <code>0x11</code>, so a <code>hash:11 drop</code> row also matches Public unless an earlier exact-channel rule stops it. This standalone example preserves authenticated Public while dropping other packets that use the same visible byte:</p> <pre><code>set flood.rule.2 type=any channel=public retry stop\nset flood.rule.3 type=any channel=hash:11 drop\n</code></pre> <p>The Public rule's MAC/decrypt check must succeed before its <code>stop</code> applies. A colliding channel misses that rule and reaches the hash drop. With equal numeric priorities, authenticated-channel specificity automatically puts the Public rule first regardless of slot order. Without <code>stop</code>, both rows match Public and the sticky drop wins. Remove <code>retry</code> from the Public row if the exemption should not also opt Public into flood retry. An explicitly higher numeric priority on the hash rule remains an operator override.</p> <p>The 240 KB STM32WL profiles keep <code>MESH_ENABLE_FLOOD_RULE_ENGINE=0</code> and retain the persistent compact FPF6 <code>flood.filter</code> and blacklist syntax below. They still perform filtering, but omit the generalized <code>flood.rule</code> parser and extended fields. No partition size is changed by this feature.</p> <p>The compatible filter and blacklist commands are:</p> <pre><code>set flood.filter.blacklist &lt;ID[,ID...]&gt;\nset flood.filter.blacklist.&lt;slot&gt; &lt;ID[,ID...]&gt;\nget flood.filter.blacklist\nget flood.filter.blacklist.&lt;slot&gt;\ndel flood.filter.blacklist\ndel flood.filter.blacklist.&lt;slot&gt;\nset flood.filter &lt;type&gt; [hops] [path=blacklist] [scope=&lt;name&gt;] [require=region] [tx=slow] [suspend=tempradio]\nset flood.filter.&lt;slot&gt; &lt;type&gt; [hops] [path=blacklist] [scope=&lt;name&gt;] [require=region] [tx=slow] [suspend=tempradio]\nget flood.filter\nget flood.filter.&lt;slot&gt;\ndel flood.filter.&lt;slot&gt;\ndel flood.filter all\n</code></pre> <p>The blacklist holds up to 255 unique 3-byte repeater IDs on ESP32 builds and 18 on other builds. Each is written as six hexadecimal digits. For example:</p> <pre><code>set flood.filter.blacklist A1B2C3,D4E5F6,112233\nset flood.filter.blacklist.4 445566\nset flood.filter any all path=blacklist\n</code></pre> <p>This is intended for abuse containment, such as refusing to retransmit floods that repeatedly enter the mesh through known internet gateways dumping bulk traffic. The list is shared by every FPF7 row and scope-rewrite row that uses <code>path=blacklist</code>; it is not copied into each rule.</p> <p>An unnumbered <code>set</code> replaces the list with up to 18 IDs, the largest command that fits every CLI transport. A numbered <code>set</code> writes a batch of up to 18 IDs beginning at an existing slot or the next consecutive slot. This is how an ESP32 list grows beyond 18. Deleting a numbered entry compacts the entries after it. Unnumbered <code>get</code> reports the total and prints the leading IDs that fit; numbered <code>get</code> retrieves one specific entry.</p> <p><code>path=blacklist</code> is an unordered precondition on that row. With 3-byte path hashes, one or more exact blacklist hits qualifies the packet. With 2-byte path hashes, two or more received path entries must match the first two bytes of listed IDs. Each received entry is counted at most once. A 1-byte path never qualifies. The IDs may occur anywhere in the received path; neither their list order nor their path order matters.</p> <p>Without a slot number, <code>set</code> reuses an identical row or selects the first empty slot. Use a slot number to replace a row whose match or action is changing. Omitting the hop expression means <code>all</code> (<code>0-63</code>).</p> <p>Numbered <code>get</code> normally uses the long field names. If a rule containing several maximum-length names would exceed one CLI reply, it switches to a non-truncating compact spelling that <code>set</code> also accepts: <code>c=</code> is <code>channel=</code>, <code>p=</code> is <code>prefix=</code>, <code>i=*|n|s|a|u|s:&lt;scope&gt;|r:&lt;region&gt;</code> represents <code>in=</code>, <code>q=N</code> is <code>rate=N/min</code>, and <code>f=str</code> combines slow timing (<code>s</code>), temporary-radio suspension (<code>t</code>), and retry allowance (<code>r</code>). The fallback prints packet type numerically.</p> <p>A legacy row without <code>scope=</code> is the existing drop action. On extended builds, an explicit <code>drop</code> has the same result, while <code>rate=</code> by itself creates a rate-only row. A row with <code>scope=</code> adds transport scope to an unscoped packet or replaces the codes on an already-scoped packet. The scope name is normalized with a leading <code>#</code>, and the 128-bit transport key is derived directly from that hashtag. The name does not need to exist in the region list and is not added to it. Public names up to 30 characters are accepted; private <code>$</code> scopes are not.</p> <p><code>require=region</code> is the legacy spelling of <code>in=allowed</code>. The repeater evaluates the packet's original route before any rewrite in that receive pass. An incoming transport scope must match a locally allowed region; an unscoped flood must be allowed by the wildcard region. If the check fails, that row is skipped, the filter does not grant a region bypass, and the unchanged packet is allowed to fail normal region enforcement. Other independently configured scope rows still apply in their normal order.</p> <p>When multiple scope or region rows match, the highest numeric-priority row wins. Equal priorities use authenticated channel, raw hash, then wildcard specificity before the slot-number tie-break. Rewrite rows do not approve a packet: any matching drop row and every remaining forwarding gate can still reject it. A filter-assigned scope is trusted without local region-list validation, but <code>repeat</code>, <code>flood.max</code>, loop detection, and moderation still apply. By default, a changed scope bypasses inbound <code>rxdelay</code>, then is retransmitted with zero <code>txdelay</code> and the highest outbound queue priority. Add <code>tx=slow</code> to use an effective inbound <code>rxdelay</code> base of <code>max(2, configured rxdelay * 2)</code>, retain normal queue priority, and force the maximum <code>txdelay</code> factor of <code>2.0</code>; the randomized transmit delay ranges from zero through ten packet airtimes. <code>tx=fast</code> explicitly restores the default. Selecting the scope already present does not grant special treatment. Active radio transmission, CAD, and airtime-budget limits are unchanged.</p> <p>On generalized repeaters, forward rules, <code>flood.channel.scope</code> rewrite rows, the shared blacklist, and the <code>flood.channel.data</code> compatibility state are one atomic FPF7 policy image. Existing <code>/flood_ch_scope</code>, <code>/flood_filter_bl</code>, FPF6, and FCB2 data is imported once; the old files are removed only after the new image verifies and commits. Compact FPF6 repeaters retain separate files. Deleting the blacklist leaves <code>path=blacklist</code> rows in place but dormant until IDs are configured again. Path hashes are truncated routing identifiers and are not authenticated proof that a particular repeater\u2014or a particular person\u2014handled a packet. FULL room servers reject blacklist commands.</p> <p>On first initialization, flood-filter slot 1 is seeded with:</p> <pre><code>set flood.filter.1 0x0C all suspend=tempradio\n</code></pre> <p>This is a normal editable row. After the table has been saved, deleting it remains persistent across reboot; the firmware does not recreate it. Run the same command to restore the exact seeded row, or omit <code>.1</code> to preserve existing slot assignments and use the first empty slot. Operators may add <code>suspend=tempradio</code> to any other row that should be skipped while the radio is on a temporary channel.</p> <p>Suspension does not approve a packet or bypass the rest of the filter table. It skips that row, then evaluation continues with the next row and the remaining forwarding gates. An ordinary drop <code>any</code> row therefore still applies during the temporary-radio window unless an earlier matching stop row ends FPF7 processing. <code>repeat</code>, <code>flood.max*</code>, region handling, loop detection, and the OTA subsystem's own hop limit also remain in force.</p> <p>Standard traceroute uses direct routing and never enters <code>flood.filter</code>. For a custom flood-form trace, <code>type=any</code>, explicit <code>trace</code>, scope, region, rate, and drop rows all behave normally. The stock core does not normally flood-forward TRACE packets.</p>"},{"location":"flood_filtering/#remote-administration-lockout-warning","title":"Remote-administration lockout warning","text":"<p>There are no hidden payload-type or short-hop exemptions in FPF7. Drop and rate rules can block <code>req</code>, <code>response</code>, <code>txt_msg</code>, <code>anon_req</code>, <code>path</code>, ACK, and multipart traffic beginning at hop <code>0</code> when their match fields say so.</p> <p>A flooded login starts as <code>ANON_REQ</code>; its reply is commonly a <code>PATH</code> packet carrying an encrypted <code>RESPONSE</code>. Before a direct return path is established, administrative replies and CLI text can also be flooded. Transit repeaters do not have the session key and cannot distinguish those encrypted admin exchanges from ordinary peer packets with the same outer type. A rule therefore affects the complete outer packet class, not only packets that ultimately authenticate as administrators. Keep a serial or other recovery path and stage broad deny/rate rules carefully.</p> <p>Hop expressions are based on the path count when this repeater receives the packet:</p> <ul> <li><code>N</code> matches exactly <code>N</code> received hops.</li> <li><code>N+</code> matches <code>N</code> or more received hops.</li> <li><code>N-M</code> matches the inclusive range.</li> <li><code>all</code> matches <code>0</code> through <code>63</code> hops.</li> <li><code>0+</code>, <code>all</code>, and omitting the hop expression are equivalent. <code>get</code> reports   the stored range using the canonical spelling <code>all</code>.</li> </ul> <p>Examples:</p> <pre><code># Stop forwarding group data once it arrives with four or more path entries.\nset flood.filter grp_data 4+\n\n# Stop long adverts, while still allowing shorter adverts.\nset flood.filter.2 advert 6+\n\n# Keep LoRa OTA floods from crossing this repeater at path counts 2 through 4.\nset flood.filter.3 ota 2-4\n\n# Assign #local scope to group text without requiring #local in the region map.\nset flood.filter grp_txt all scope=local\n\n# Rewrite only packets whose incoming region was already acceptable.\nset flood.filter grp_data all scope=local require=region\n\n# Rewrite matching blacklisted paths without fast-tracking their retransmission.\nset flood.filter grp_data all path=blacklist scope=local tx=slow\n\n# Drop matching flood types after the unordered path blacklist qualifies.\nset flood.filter.blacklist A1B2C3,D4E5F6,112233\nset flood.filter any all path=blacklist\n\n# Apply a hard ceiling to flood payload types at 12 or more received hops.\nset flood.filter any 12+\n</code></pre>"},{"location":"flood_filtering/#high-traffic-mesh-example","title":"High-traffic mesh example","text":"<p>This preset limits request and group-data propagation early while allowing the login-capable response, anonymous-request, and path types to travel farther:</p> <pre><code>set flood.filter req 3+\nset flood.filter response 9+\nset flood.filter 0x06 3+\nset flood.filter 0x07 9+\nset flood.filter path 9+\nset flood.filter control 1+\nget flood.filter\n</code></pre> Rule Stops retransmission when received with <code>req 3+</code> 3 or more path entries <code>response 9+</code> 9 or more path entries <code>0x06 3+</code> (<code>grp_data</code>) 3 or more path entries <code>0x07 9+</code> (<code>anon_req</code>) 9 or more path entries <code>path 9+</code> 9 or more path entries <code>control 1+</code> 1 or more path entries <p>On a new table, the factory OTA rule occupies slot 1, so these unnumbered commands normally fill slots 2 through 7. Existing tables may choose different free slots. All six rules take effect at the thresholds shown; there are no hidden short-hop exceptions. The Control rule allows a flood received with path count <code>0</code> to be forwarded once, then stops it at the next repeater. Normal node-discovery Control packets are direct zero-hop packets and never enter <code>flood.filter</code>. These rules affect only retransmission by the repeater; local reception and logging remain unchanged.</p> <p>Accepted payload names are:</p> Value Short name Full name <code>0x00</code> <code>req</code> <code>PAYLOAD_TYPE_REQ</code> <code>0x01</code> <code>response</code> <code>PAYLOAD_TYPE_RESPONSE</code> <code>0x02</code> <code>txt_msg</code> <code>PAYLOAD_TYPE_TXT_MSG</code> <code>0x03</code> <code>ack</code> <code>PAYLOAD_TYPE_ACK</code> <code>0x04</code> <code>advert</code> <code>PAYLOAD_TYPE_ADVERT</code> <code>0x05</code> <code>grp_txt</code> <code>PAYLOAD_TYPE_GRP_TXT</code> <code>0x06</code> <code>grp_data</code> <code>PAYLOAD_TYPE_GRP_DATA</code> <code>0x07</code> <code>anon_req</code> <code>PAYLOAD_TYPE_ANON_REQ</code> <code>0x08</code> <code>path</code> <code>PAYLOAD_TYPE_PATH</code> <code>0x09</code> <code>trace</code> <code>PAYLOAD_TYPE_TRACE</code> <code>0x0A</code> <code>multipart</code> <code>PAYLOAD_TYPE_MULTIPART</code> <code>0x0B</code> <code>control</code> <code>PAYLOAD_TYPE_CONTROL</code> <code>0x0C</code> <code>ota</code> <code>PAYLOAD_TYPE_OTA</code> in this fork <code>0x0D</code> <code>13</code> reserved <code>0x0E</code> <code>14</code> reserved <code>0x0F</code> <code>raw_custom</code> <code>PAYLOAD_TYPE_RAW_CUSTOM</code> <p>Decimal values <code>0</code> through <code>15</code>, hexadecimal values <code>0x00</code> through <code>0x0F</code>, the full <code>PAYLOAD_TYPE_*</code> names, and <code>any</code> are also accepted. Upstream currently reserves <code>0x0C</code>; this fork assigns it to LoRa OTA. Rows are suspended during temporary-radio operation only when explicitly configured that way.</p>"},{"location":"flood_filtering/#moderate-group-text-by-channel-and-username","title":"Moderate group text by channel and username","text":"<p>Use <code>flood.moderation</code> for flood <code>GRP_TXT</code> messages. The repeater validates and decrypts the selected channel, extracts the display name before the first <code>:</code>, then applies the rule:</p> <pre><code>set flood.moderation &lt;channel&gt; &lt;sender&gt; &lt;action&gt; [action...]\nset flood.moderation.&lt;slot&gt; &lt;channel&gt; &lt;sender&gt; &lt;action&gt; [action...]\nget flood.moderation\nget flood.moderation.&lt;slot&gt;\ndel flood.moderation.&lt;slot&gt;\ndel flood.moderation all\n</code></pre> <p>Channels can be specified as:</p> <ul> <li><code>public</code> for the built-in Public channel</li> <li><code>#name</code> for a well-known hashtag channel</li> <li>a 128-bit or 256-bit channel key in hexadecimal</li> </ul> <p>The key is stored locally so packets can be authenticated and decrypted. It is not included in <code>get flood.moderation</code> output.</p> <p>Available actions are:</p> <ul> <li><code>drop</code> - do not retransmit any matching message</li> <li><code>rate=X/min</code> - retransmit at most <code>X</code> messages per local 60-second window</li> <li><code>hops=N</code> - do not retransmit when the received path count is <code>N</code> or higher</li> <li><code>path=H1[,H2,H3]</code> - require the first one to three path hashes to match</li> <li><code>path=*</code> - match every path; this is the default</li> </ul> <p>At least one of <code>drop</code>, <code>rate=X/min</code>, or <code>hops=N</code> is required. Rate and hop limits can be combined. <code>rate=0/min</code> is equivalent to <code>drop</code>.</p>"},{"location":"flood_filtering/#per-user-per-channel-rate-limits","title":"Per-user, per-channel rate limits","text":"<p>Rate limits require an exact username; <code>*</code> is not accepted for a rate rule. Username comparison is ASCII case-insensitive, and names containing spaces must be quoted. A rule's counter is independent from rules for the same name on other channels, so this directly supports \"X messages per minute from user X on channel Y.\" Counters are local to this repeater and reset on reboot.</p> <pre><code># At most five Public-channel messages per minute from this display name.\nset flood.moderation public \"Noisy User\" rate=5/min\n\n# A separate limit for the same name on #local.\nset flood.moderation #local \"Noisy User\" rate=10/min\n\n# Combine a rate limit with a maximum forwarding distance.\nset flood.moderation public alice rate=4/min hops=5\n</code></pre>"},{"location":"flood_filtering/#match-the-start-of-a-path","title":"Match the start of a path","text":"<p>Path matching accepts one-, two-, or three-byte hashes. Every hash in one rule must use the same width, and matching always starts at the beginning of the received path:</p> <pre><code>set flood.moderation #local bot drop path=A1B2C3,D4E5F6\nset flood.moderation public alice rate=3/min path=71\n</code></pre> <p>A path-qualified rule cannot match a zero-hop packet and does not match until the packet contains all path entries listed by the rule.</p>"},{"location":"flood_filtering/#how-the-forwarding-controls-combine","title":"How the forwarding controls combine","text":"<p>A flood packet is retransmitted only if it passes every applicable control. In other words, the controls combine as deny rules:</p> <ol> <li><code>flood.channel.scope.require</code> evaluates a listed group channel against the    original incoming scope; unlisted group channels bypass the later region    gate while the table is active.</li> <li><code>flood.channel.scope</code> tries a path-qualified channel row before that    channel's ordinary fallback, then adds or replaces the scope from either a    configured region or a direct <code>scope=&lt;name&gt;</code> target.</li> <li>All extended <code>flood.rule</code> match fields are evaluated against the same    original incoming packet. Matches are ordered by descending numeric    priority, then authenticated/raw-hash/wildcard channel specificity, then    ascending slot. The first matching <code>stop</code> row removes every later FPF7    match. The highest-order remaining <code>scope=</code> or <code>region=</code> row may replace the    channel-scope result; a direct scope does not require a region-list entry.</li> <li><code>repeat</code> and <code>flood.max*</code> are checked.</li> <li>The FPF7 forward phase, including any row managed through    <code>flood.channel.data*</code>, applies drop and rate decisions using that saved    match result. No packet type or short-hop range is silently exempted.</li> <li>Region and loop-detection rules are checked; a regionless scope assigned by    either table is already trusted when it has no region-list match, except    that it cannot rescue a channel rejected by    <code>flood.channel.scope.require</code>.</li> <li><code>flood.moderation</code> checks decrypted group text, username, rate, hops, and    path. If it accepts the packet, matching general-rule rate counters are    charged immediately before retransmission is approved.</li> </ol> <p>The first denial is enough to prevent retransmission. A packet that is denied can still appear in local logs or MQTT output. Moderation runs last because its rate counters are charged only for packets that pass every other forwarding control and will actually be retransmitted.</p>"},{"location":"flood_filtering/#delegate-filter-management","title":"Delegate filter management","text":"<p>On repeaters, ACL permission <code>5</code> is the filter-manager role:</p> <pre><code>setperm &lt;companion-public-key-hex&gt; 5\n</code></pre> <p>A filter manager can read non-secret operational status and manage <code>repeat</code>, <code>loop.detect</code>, <code>flood.max*</code>, <code>flood.channel.data*</code>, <code>flood.filter*</code>, <code>flood.rule*</code>, and <code>flood.moderation*</code>. Delegated <code>get</code> access uses an explicit allowlist: it cannot retrieve guest, WiFi, MQTT, bridge, or other credentials, and it cannot change regions, ACL entries, radio settings, or unrelated administrator settings. Because <code>flood.filter scope=</code> derives a public hashtag key directly, a filter manager can configure that action without region-manager permission; it still cannot edit the region hierarchy.</p> <p>FULL ESP32 room servers use their existing administrator check for remote <code>flood.rule</code> and <code>flood.filter</code> commands; they do not grant this table through permission <code>5</code>.</p> <p>ACL permission <code>4</code>, the region/scope-manager role, can read, add, replace, and delete <code>flood.channel.scope</code> and <code>flood.channel.scope.require</code> rows and manage regions. This lets the same delegate create target regions, assign forced scopes from regions or direct hashtag names, and select the channels that require valid incoming scopes.</p>"},{"location":"flood_filtering/#security-limitations","title":"Security limitations","text":"<p>Public and hashtag channels use shared, well-known keys. A valid channel MAC proves that the sender knew the channel key; it does not identify a person. The <code>&lt;sender&gt;</code> value is an unverified display name and can be spoofed. Path hashes are truncated routing hints and can collide or be manipulated; they are not authenticated user identities.</p> <p>Use username and path rules as traffic moderation, not as an authorization boundary. For a strict network boundary, combine these tools with region ACLs, private transport/channel keys, and controlled device access.</p>"},{"location":"flood_filtering/#restore-the-factory-seeded-rows","title":"Restore the factory-seeded rows","text":"<p>The repeater's factory-seeded forwarding rows can be restored through the CLI:</p> <pre><code>set flood.rule.1 type=ota hops=all drop suspend=tempradio\nset flood.rule.2 type=any channel=#wardriving hops=5+ drop\n</code></pre> <p>These commands explicitly replace the two seeded generalized-repeater slots. Inspect them first if they may now contain other rules. Compact FPF6 builds use only the first command's <code>flood.filter.1 0x0C all suspend=tempradio</code> form.</p>"},{"location":"flood_filtering/#remove-the-custom-rules","title":"Remove the custom rules","text":"<p>To save both tables in an empty state:</p> <pre><code>del flood.filter all\ndel flood.moderation all\nget flood.filter\nget flood.moderation\n</code></pre> <p>This does not change the older <code>flood.max*</code>, loop-detection, or region settings; inspect or reset those separately when troubleshooting.</p>"},{"location":"full_companion_usb_switcher/","title":"Full Companion USB CLI and binary switcher","text":"<p>Full Companion uses one primary USB serial interface for two incompatible wire formats:</p> <ul> <li>a human-readable ASCII command line;</li> <li>the framed Binary Companion protocol used by MeshCore apps and <code>meshcli</code>.</li> </ul> <p>The primary interface starts in the ASCII terminal after each boot. A Binary Companion client does not need to send a special mode command: its first valid frame automatically hands the interface to the binary parser.</p> <p>This automatic behavior is compiled only into <code>companion_radio_full</code> targets. Ordinary USB Companion builds continue to use the explicit <code>+++MESHCORE-TERM-START</code> and <code>+++MESHCORE-TERM-STOP</code> controls described in the Terminal Chat CLI guide.</p>"},{"location":"full_companion_usb_switcher/#wire-formats","title":"Wire formats","text":"<p>Host-to-device Binary Companion frames use this layout:</p> <pre><code>'&lt;'  length-low  length-high  payload[length]\n</code></pre> <p>Device-to-host frames use the same little-endian length with a different marker:</p> <pre><code>'&gt;'  length-low  length-high  payload[length]\n</code></pre> <p>For example, a representative two-byte device query is:</p> <pre><code>3C 02 00 16 03\n</code></pre> <p>The ASCII terminal is line-oriented and accepts commands such as:</p> <pre><code>get radio.cad\nset display.rotation 90\nreboot\n</code></pre> <p>Changing the configured baud rate does not select a mode. Use 115200 for compatibility even though native USB CDC hardware does not use UART timing.</p>"},{"location":"full_companion_usb_switcher/#state-transitions","title":"State transitions","text":"<pre><code>                         complete '&lt;' frame\n                 +--------------------------------+\n                 |                                v\nboot ------&gt; ASCII terminal                  Binary Companion\n                 ^                                |\n                 |                                | +++MESHCORE-TERM-START\n                 | incomplete '&lt;' probe           |\n                 | (one-second timeout)            |\n                 +--------------------------------+\n\nASCII terminal -- +++MESHCORE-TERM-STOP ------&gt; Binary Companion\nASCII terminal -- observable USB disconnect ---&gt; Binary Companion\nESP32 logging terminal -- usb.logging off -----&gt; ASCII terminal\nany mode ------- reboot ------------------------&gt; ASCII terminal\n</code></pre> <p>Serial mOTA and single-TTY logging add exclusive ownership states described below. BLE, WiFi, Ethernet, and hardware-serial Companion transports are not switched; they remain binary.</p>"},{"location":"full_companion_usb_switcher/#how-automatic-detection-works","title":"How automatic detection works","text":"<ol> <li>Full Companion initializes the normal USB Binary Companion interface, then    gives its primary stream to the ASCII terminal before normal loop service    begins.</li> <li>While the prompt has no buffered input, the terminal peeks at the next byte.    It does not remove that byte.</li> <li>If the byte is <code>&lt;</code>, the terminal temporarily releases the stream and enables    the existing <code>ArduinoSerialInterface</code> frame parser.</li> <li>The parser consumes the original <code>&lt;</code>, the two-byte length, and the payload.    There is no second parser and no copied or synthetic frame.</li> <li>A monotonically increasing completed-frame counter confirms that the parser    received a complete frame. The interface then remains in Binary Companion    mode.</li> <li>If no complete frame arrives within one second, the parser state is reset    and the ASCII terminal prints a new banner and prompt.</li> </ol> <p>The switcher checks framing, not client identity. Any syntactically complete Binary Companion frame confirms binary mode; it does not require the first command to be <code>CMD_APP_START</code> or <code>CMD_DEVICE_QUERY</code>. Normal command validation still occurs after the frame parser returns the payload.</p> <p>The empty-prompt requirement prevents a literal <code>&lt;</code> in the middle of a command from silently changing modes. A literal <code>&lt;</code> typed as the first character does start a probe, but the terminal returns after the one-second timeout if no binary header and payload follow.</p>"},{"location":"full_companion_usb_switcher/#manual-controls","title":"Manual controls","text":"<p>The original controls remain available.</p> <p>From Binary Companion, send this exact unframed line while the parser is idle:</p> <pre><code>+++MESHCORE-TERM-START\n</code></pre> <p>Terminate it with CR or LF. The binary parser accepts control tokens only as complete delimiter-bounded lines; prefixes, suffixes, and partial tokens are ignored.</p> <p>From the ASCII terminal, send this exact sequence to return to binary mode:</p> <pre><code>+++MESHCORE-TERM-STOP\n</code></pre> <p>The stop sequence takes effect as soon as its last byte arrives in ASCII mode. The start sequence is recognized only as a completed line while the binary parser is idle and is not examined inside a length-prefixed frame.</p> <p><code>meshcli</code> can normally connect directly after boot:</p> <pre><code>meshcli -s /dev/ttyACM0 -b 115200 ver\n</code></pre> <p>An explicit terminal start token is still useful when the device is already in binary mode:</p> <pre><code>picocom -b 115200 \\\n  --imap spchex \\\n  --initstring $'+++MESHCORE-TERM-START\\r' \\\n  /dev/ttyACM0\n</code></pre>"},{"location":"full_companion_usb_switcher/#logging-and-mota-ownership","title":"Logging and mOTA ownership","text":"<p>The switcher never attempts to mix ASCII, framed Companion traffic, or binary mOTA traffic on the same stream.</p> Situation Primary USB behavior Full Companion after boot ASCII; a complete <code>&lt;</code> frame switches to Binary Companion nRF52 logging enabled Primary interface still follows the switcher; logs use the optional second interface ESP32 logging enabled at boot Logging terminal owns the only USB TTY; automatic <code>&lt;</code> detection is disabled nRF52 USB serial mOTA active mOTA owns primary USB; ASCII and Binary Companion are unavailable there BLE/WiFi/Ethernet/hardware serial Always Binary Companion and unaffected by the USB mode <p>On every ESP32 Full Companion, use <code>set usb.logging off</code> in its logging terminal before trying to use USB with an app. That command stops logging and returns to the ordinary ASCII terminal; it does not select Binary Companion. The app's first valid framed probe can perform the normal automatic switch, or a human can send <code>+++MESHCORE-TERM-STOP</code> first. The framed/binary Companion parser is disabled while logging owns that TTY. BLE and WiFi Companion transports remain available while USB is logging. ESP32 Full builds use the Arduino-ESP32 2.x base where supported; RC32 and ESP32-C6 keep their board-required Arduino 3.x platform but follow the same one-TTY policy. No ESP32 Full build enumerates a second CDC interface.</p> <p>On nRF52, serial <code>motatool</code> is also text-first. Its exact initial <code>ota folder on</code> line is recognized in either startup ASCII or Binary Companion mode. From ASCII, the firmware leaves terminal mode and directly enters exclusive mOTA ownership; from binary, the idle frame parser recognizes the same control sequence. The following mOTA request/reply frames therefore cannot be consumed by the ASCII line editor. <code>motatool serve --serial</code> can be the first client after boot and does not require a terminal token or disconnect workaround.</p> <p>Only the exact completed line selects mOTA from ASCII. Extra arguments, leading/trailing whitespace, or a partial line remain ordinary terminal input.</p>"},{"location":"full_companion_usb_switcher/#shortcomings-and-edge-cases","title":"Shortcomings and edge cases","text":"<p>This mechanism is deliberately small and deterministic, but it is not a full protocol negotiation layer.</p>"},{"location":"full_companion_usb_switcher/#it-is-startup-selection-not-per-connection-negotiation","title":"It is startup selection, not per-connection negotiation","text":"<p>After the first complete binary frame, the device stays in Binary Companion mode. Closing <code>meshcli</code> does not automatically restore ASCII. Use the terminal start token or reboot when an ASCII prompt is needed again.</p> <p>Conversely, closing an ASCII terminal on native USB normally changes the port to binary mode because the firmware can observe USB DTR/data disconnect. The next client therefore sees binary mode, not a new ASCII session. A USB-to-UART bridge often cannot report disconnect, so it can remain in ASCII until the stop token or a reboot.</p>"},{"location":"full_companion_usb_switcher/#detection-works-only-at-an-empty-prompt","title":"Detection works only at an empty prompt","text":"<p>If part of an ASCII command is already buffered, an incoming <code>&lt;</code> is treated as ordinary terminal input. Clear or submit the line before starting a Binary Companion client. Only one process should have the serial port open.</p>"},{"location":"full_companion_usb_switcher/#the-first-frame-has-a-one-second-deadline","title":"The first frame has a one-second deadline","text":"<p>The complete marker, length, and payload must arrive within the probe window. This is generous for local USB but may reject a heavily buffered serial proxy, a debugger that pauses the MCU, or a tool that writes the header and body with a long delay. A timed-out client can retry after the ASCII banner appears.</p>"},{"location":"full_companion_usb_switcher/#framing-confirmation-is-not-authentication","title":"Framing confirmation is not authentication","text":"<p>Any complete length-prefixed frame selects binary mode, even if its command is unknown or malformed at the application layer. This is safe for stream separation but means a random complete frame can leave the device in binary mode until manually switched back.</p>"},{"location":"full_companion_usb_switcher/#the-terminal-banner-is-best-effort","title":"The terminal banner is best effort","text":"<p>The firmware enters ASCII mode during boot, often before a host opens the CDC device. The banner may therefore be absent even though the terminal is ready; send a newline or a harmless <code>get</code> command rather than treating a missing banner as proof of binary mode.</p> <p>A host that remains connected across a reboot may receive ASCII banner and prompt bytes before the first binary response. Binary clients should discard leading bytes until a plausible <code>&gt;</code> frame marker and length are found, reject implausible lengths, and resynchronize. The ordinary open-after-boot path has been tested with <code>meshcli</code>, but third-party clients that assume byte zero is always <code>&gt;</code> may fail.</p>"},{"location":"full_companion_usb_switcher/#text-and-binary-output-cannot-be-interleaved","title":"Text and binary output cannot be interleaved","text":"<p>Primary USB suppresses Binary Companion output while the terminal owns the stream. Packet/debug logging must use its dedicated CDC interface or the exclusive single-TTY logging mode. Writing diagnostic text directly to the primary binary stream will corrupt clients regardless of the switcher.</p>"},{"location":"full_companion_usb_switcher/#a-literal-leading-briefly-hides-the-prompt","title":"A literal leading <code>&lt;</code> briefly hides the prompt","text":"<p>Typing <code>&lt;</code> as the first terminal character begins a binary probe. With no complete frame, the prompt returns after one second and the banner is printed again. There is currently no escape syntax for entering a literal leading <code>&lt;</code>; prefix it with another character if it is needed as command text.</p>"},{"location":"full_companion_usb_switcher/#troubleshooting","title":"Troubleshooting","text":"<p>If <code>meshcli</code> cannot connect:</p> <ol> <li>close every terminal or logging reader using the primary interface;</li> <li>on ESP32, confirm that saved USB logging is off;</li> <li>reboot and let <code>meshcli</code> be the first process to open the data interface;</li> <li>use the stable <code>/dev/serial/by-id/*-if00</code> path on Linux when available;</li> <li>if a prompt appears after one second, the client's first frame was not    completed inside the probe window.</li> </ol> <p>If an ASCII terminal shows no banner, press Enter and issue a harmless query such as <code>get radio.cad</code>. If binary bytes appear, send the exact terminal start token or reboot.</p> <p>The switch policy is implemented in <code>UsbAsciiBinarySwitch.h</code>, with stream ownership in <code>main.cpp</code> and framing in <code>ArduinoSerialInterface.cpp</code>.</p>"},{"location":"gps_tracking/","title":"GPS Tracking","text":"<p>This document describes how GPS telemetry works for companion/client nodes and sensor nodes.</p>"},{"location":"gps_tracking/#scope","title":"Scope","text":"<p>GPS tracking uses the existing CayenneLPP GPS telemetry field. It does not add a new phone app protocol field.</p> <p>The GPS telemetry value contains latitude, longitude, and altitude. Speed, heading, and freshness are not sent as separate telemetry fields.</p> <p>If the firmware does not have a valid fresh GPS cache, it omits the GPS field from telemetry. This is intentional: stale or missing fixes are not reported as zero coordinates.</p>"},{"location":"gps_tracking/#freshness","title":"Freshness","text":"<p>GPS telemetry is cached separately from advert location.</p> <p>The cache behavior is:</p> <ul> <li>Refresh the cached GPS value every 2 hours only when at least one contact or   ACL client can receive location telemetry.</li> <li>Try for up to 15 minutes during a refresh.</li> <li>If the position stays within about 100 meters for 30 seconds, cache a weighted   average of the stable fixes, with newer fixes weighted more heavily.</li> <li>If the position moves outside that 100 meter circle during acquisition, cache   the latest valid fix.</li> <li>Omit GPS from telemetry if there is no fix or if the cached fix is more than   12 hours old.</li> </ul> <p>When a telemetry request asks for location, GPS is kept on for 2 hours after the latest location request. During that hold window, later location telemetry requests can use fresh GPS data as soon as valid fixes are available.</p> <p>If GPS is manually enabled, it stays on and valid fixes continue to update the cache.</p> <p>If no contact or ACL client can receive location telemetry, the scheduled 2-hour refresh does not run. A real location telemetry request still turns GPS on for the 2-hour hold window, and manual GPS-on still keeps the cache updated.</p>"},{"location":"gps_tracking/#companionclient-nodes","title":"Companion/Client Nodes","text":"<p>Companion/client telemetry uses the existing companion telemetry permission system:</p> <ul> <li>base telemetry</li> <li>location telemetry</li> <li>environment telemetry</li> </ul> <p>Location telemetry is sent only when the requester's effective telemetry permissions include location. Those permissions are derived from the companion telemetry mode settings and contact flags.</p> <p>The scheduled GPS cache refresh runs only when at least one stored contact has effective location telemetry access:</p> <ul> <li><code>location: allow all</code> with at least one stored contact</li> <li><code>location: allow flags</code> with at least one stored contact whose flags include   location</li> </ul> <p>No new phone app behavior is required. Existing clients see the existing GPS telemetry field when it is present.</p>"},{"location":"gps_tracking/#sensor-nodes","title":"Sensor Nodes","text":"<p>Sensor telemetry access is controlled by:</p> <pre><code>get telemetry.access\nset telemetry.access all\nset telemetry.access acl\n</code></pre> <p><code>all</code> is the default and matches the previous sensor telemetry behavior. A request that reaches the normal sensor telemetry request path can receive the requested telemetry fields, including GPS, subject to the request mask and GPS freshness rules.</p> <p><code>acl</code> gates telemetry through the sensor ACL. A requester with read-only or higher permissions receives the existing telemetry set, including GPS. Guest or unknown requesters receive no telemetry fields.</p> <p>The scheduled GPS cache refresh follows the same access setting:</p> <ul> <li><code>all</code>: runs only when at least one ACL client exists</li> <li><code>acl</code>: runs only when at least one ACL client is read-only or higher</li> </ul> <p>Use the existing ACL command to grant access:</p> <pre><code>setperm &lt;pubkey&gt; 1\n</code></pre> <p>Permission values:</p> <ul> <li><code>1</code>: read-only, suitable for telemetry access</li> <li><code>2</code>: read-write</li> <li><code>3</code>: admin</li> </ul>"},{"location":"gps_tracking/#advert-location","title":"Advert Location","text":"<p>Advert location is separate from telemetry GPS. The advert policy is controlled with:</p> <pre><code>gps advert\ngps advert none\ngps advert share\ngps advert prefs\n</code></pre> <p>Policies:</p> <ul> <li><code>none</code>: do not include location in adverts</li> <li><code>share</code>: use the live/shared sensor manager location</li> <li><code>prefs</code>: use the stored node latitude and longitude preferences</li> </ul> <p><code>prefs</code> is the first-boot default for every repeater, room-server, and sensor build. Firmware updates retain an explicitly saved policy from the existing preferences filesystem.</p> <p>Telemetry GPS can be fresh while advert location is fixed or disabled, depending on this policy.</p>"},{"location":"gps_tracking/#recommended-setup","title":"Recommended Setup","text":"<p>For private sensor tracking:</p> <pre><code>set telemetry.access acl\nsetperm &lt;owner_pubkey&gt; 3\nsetperm &lt;trusted_pubkey&gt; 1\n</code></pre> <p>For compatibility with the older sensor behavior:</p> <pre><code>set telemetry.access all\n</code></pre> <p>For GPS telemetry behavior, leave the phone app unchanged. The firmware omits GPS when it is stale or missing and sends the existing GPS telemetry field when fresh data is available.</p>"},{"location":"halo_keymind_settings/","title":"Halo and Keymind Branch Settings","text":"<p>This file covers only CLI settings and helper commands added by the Halo or Keymind branches. Use <code>docs/cli_commands.md</code> for the general MeshCore CLI. See Repeater Flood Filtering and Moderation for a focused filter setup and troubleshooting guide.</p>"},{"location":"halo_keymind_settings/#quick-start","title":"Quick Start","text":"<pre><code>set retry.preset rooftop\nset direct.retry.heard on\nset flood.retry.advert off\nset flood.retry.bridge off\nset flood.retry.prefixes none\nset flood.retry.ignore none\n</code></pre> <p>Then verify:</p> <pre><code>get retry.preset\nget direct.retry.heard\nget flood.retry.advert\nget flood.retry.prefixes\nget flood.retry.ignore\n</code></pre> <p>Use prefixes from the analyzer or neighbors list or <code>get recent.repeater</code> after the repeater has been online for a few hours.</p>"},{"location":"halo_keymind_settings/#common-examples","title":"Common Examples","text":"<p>Disable retrying advert packets:</p> <pre><code>set flood.retry.advert off\nget flood.retry.advert\n</code></pre> <p>Ignore a repeater as a successful flood retry echo: Use this if you have a car repeater and a house repeater; have the house ignore the car.</p> <pre><code>set flood.retry.ignore 71CE82,C7618C\nget flood.retry.ignore\n</code></pre> <p>Only accept specific downstream relays as flood retry success: You're in a hole and need to hit a mountain top repeater to get out; keep trying till one you see one of these send out your packet.</p> <pre><code>set flood.retry.prefixes A58296,860CCA,425E5C\nget flood.retry.prefixes\n</code></pre> <p>Bridge two groups of repeaters:</p> <pre><code>set flood.retry.bridge on\nset flood.retry.bucket 1 71CE82,C7618C\nset flood.retry.bucket 2 BEEBB0,425E5C\nget flood.retry.bucket.1\nget flood.retry.bucket.2\n</code></pre> <p>Return to simple non-bridge flood retry:</p> <pre><code>set flood.retry.bridge off\nset flood.retry.prefixes none\nset flood.retry.ignore none\n</code></pre>"},{"location":"halo_keymind_settings/#added-settings","title":"Added Settings","text":"Setting What it does How to use Example <code>telemetry.temp</code>, <code>telemetry.volt</code>, <code>telemetry.volt.i2c</code>, <code>telemetry.gps</code> Repeater and room builds record 30-minute MCU temperature and battery samples for seven days. Detected INA voltage channels retain four days at 0.02 V resolution through 655.34 V; all-zero channels are omitted as disconnected. GPS-capable builds retain GPS separately. Repeater <code>telemetry.tx</code> sends temperature, battery, and per-channel I2C RAW_CUSTOM packets over a configured direct path on a persistent 1-30 day schedule (default two days) or immediately for testing; GPS is never included. History resets on reboot. <code>get telemetry.temp [page]</code>, <code>get telemetry.volt [page]</code>, <code>get telemetry.volt.i2c [channel [page]]</code>, <code>get telemetry.gps [page]</code>, <code>set telemetry.gps &lt;1-30&gt;</code>, <code>get telemetry.tx</code>, <code>set telemetry.tx &lt;off|direct|path&gt;</code>, <code>set telemetry.tx schedule &lt;off|1-30d&gt;</code>, <code>send telemetry.tx now</code> <code>get telemetry.volt.i2c 2 1</code> <code>battery.alert</code> Sends opt-in, region-scoped low-battery warnings to <code>#repeaters</code> after 30 minutes of uptime. <code>get battery.alert</code>, <code>get battery.alert.region</code>, <code>set battery.alert on [region]</code>, <code>set battery.alert off</code> <code>set battery.alert on sea</code> <code>battery.alert.low</code> Warning threshold percentage. Must be greater than <code>battery.alert.critical</code>. <code>get battery.alert.low</code>, <code>set battery.alert.low &lt;1-100&gt;</code> <code>set battery.alert.low 20</code> <code>battery.alert.critical</code> Critical threshold percentage. Critical and warning alerts use the same 12-hour resend cooldown. <code>get battery.alert.critical</code>, <code>set battery.alert.critical &lt;0-99&gt;</code> <code>set battery.alert.critical 10</code> <code>recent.repeater</code> Shows, searches, seeds, or clears the recent repeater prefix/SNR table used by direct retry and bridge freshness checks. Search results include the last-recorded age. Entries older than 24 hours are removed by a three-hour sweep. <code>get recent.repeater [page]</code>, <code>get recent.repeaters search &lt;2|4|6 hex&gt; [page]</code>, <code>set recent.repeater &lt;prefix&gt; &lt;snr_db&gt;</code>, <code>clear recent.repeater</code> <code>get recent.repeaters search A1B2</code> <code>flood.channel.data</code> Compatibility view for a visible FPF7 <code>type=grp_data</code> drop row on generalized repeaters. <code>off</code> creates the row and <code>on</code> removes it; compact FPF6 builds retain the legacy gate. Use an authenticated <code>channel=</code> row when only selected channels should be blocked. <code>get flood.channel.data</code>, <code>set flood.channel.data on/off</code> <code>set flood.channel.data off</code> <code>flood.channel.data.hops</code> Sets the compatibility row's hop range: <code>all</code> maps to <code>hops=all</code>; <code>1</code>-<code>7</code> repeats through that hop count and maps to <code>hops=N+1+</code>. <code>get flood.channel.data.hops</code>, <code>set flood.channel.data.hops &lt;all|1-7&gt;</code> <code>set flood.channel.data.hops 7</code> <code>flood.channel.scope</code> FPF7 rewrite-phase rows that add a transport scope to received unscoped floods or replace the scope of already-scoped floods. A bare target uses an existing flood-allowed region; <code>scope=&lt;name&gt;</code> derives a public hashtag target directly without creating a region, exactly like <code>flood.filter scope=</code>. By default, a changed packet bypasses inbound <code>rxdelay</code> and is forwarded at the highest outbound queue priority with zero initial <code>txdelay</code>, so the selected scope can win at the next hop. <code>tx=slow</code> uses an effective inbound <code>rxdelay</code> base of <code>max(2, configured rxdelay * 2)</code>, retains normal queue priority, and forces the maximum <code>txdelay</code> factor of <code>2.0</code>; its actual randomized transmit delay ranges from zero through ten packet airtimes. <code>path=blacklist</code> and <code>path=bucket:&lt;1-6&gt;</code> make a row path-qualified; bridge buckets remain usable while bridge retry is off. An already-matching scope is a no-op. Exact channel keys beat <code>txt:*</code>; path-qualified rows beat the ordinary channel fallback. <code>login:*</code> covers the remote-login family, and <code>other:*</code> covers every remaining flood type, including flood-form TRACE and OTA. Direct traceroute remains outside the flood table. Generalized builds commit these rows with the forward phase and blacklist; compact FPF6 builds retain separate storage. ACL permission <code>4</code> can manage the table. <code>get flood.channel.scope[.n]</code>, <code>set flood.channel.scope[.n] &lt;channel|txt:*|login:*|other:*&gt; &lt;region|scope=name&gt; [path=blacklist|path=bucket:1-6] [tx=slow]</code>, <code>del flood.channel.scope.&lt;n&gt;|all</code> <code>set flood.channel.scope #rgdata scope=BlackHole86</code> <code>flood.channel.scope.require</code> Switches group-channel region enforcement to opt-in when the table has entries. Listed authenticated <code>GRP_TXT</code>/<code>GRP_DATA</code> channels must arrive already scoped to a locally allowed region; unscoped, unknown, or denied incoming scopes are dropped before any rewrite can rescue them. Unlisted group channels bypass only the region gate and retain all other forwarding controls. An empty table preserves global region behavior; non-channel payloads are unchanged. ACL permission <code>4</code> can manage the table. <code>get flood.channel.scope.require[.n]</code>, <code>set flood.channel.scope.require[.n] &lt;public|#channel|key&gt;</code>, <code>del flood.channel.scope.require.&lt;n&gt;|all</code> <code>set flood.channel.scope.require #bot</code> <code>flood.filter</code> Persistent flood-route rules selected by payload type and optional hop range. Generalized repeaters have 63 FPF7 forward slots; FULL ESP32 room servers have 31. Repeaters store their scope-rewrite phase, shared unordered blacklist, and channel-data compatibility state in the same atomic FPF7 image. <code>path=blacklist</code> is intended for forwarding abuse containment, including bulk internet-to-mesh dumping, but truncated path IDs are not authenticated identities. Fixed 240 KB STM32WL repeaters retain compact FPF6 filtering and separate blacklist storage. New generalized repeater tables seed slot 1 with <code>ota all suspend=tempradio</code> and slot 2 with an authenticated <code>#wardriving hops=5+</code> drop. Direct routes and local receive/logging are unchanged. <code>get flood.filter[.n]</code>, <code>set flood.filter[.n] &lt;type&gt; [N|N+|N-M|all] [scope=&lt;name&gt;] [require=region] [tx=slow] [suspend=tempradio]</code>, <code>del flood.filter.&lt;n&gt;|all</code>; repeater only: <code>get/set/del flood.filter.blacklist[.n]</code> <code>set flood.filter grp_txt all scope=local tx=slow</code> <code>flood.rule</code> Live alias for extended <code>flood.filter</code> on rule-engine repeaters and FULL ESP32 room servers. A row can AND packet type, hop range, optional channel match, ordered 1/2/3-byte pbyte source prefix, and original scope/region conditions, then drop, rewrite to a direct scope or configured region, enforce a per-row rate, allow flood retry, and/or stop lower-priority FPF7 rules. <code>channel=*</code> means no channel condition; <code>public</code>, <code>#name</code>, and keys authenticate; <code>hash:XX</code> is an unauthenticated one-byte fallback with collision/spoof risk. With no <code>retry</code> rows, global retry behavior is unchanged; once any exists, matching <code>retry</code> rows allow-list received floods while the global retry gates and <code>flood.retry.bridge</code> algorithm still apply. <code>scope=BlackHole86</code> directly derives a regionless sink scope; <code>region=BlackHole86</code> would require a configured flood-allowed region. All rows match the original receive-time packet. Higher numeric <code>priority</code> runs first; equal values automatically order authenticated channels before raw hashes before <code>channel=*</code>, then use lower slot as the final tie-break. Repeated rows with one channel key share a per-packet authentication result. Persistent FPF7 stores canonical region names, so region ID reorder or reuse cannot retarget a rule. A missing saved region makes its <code>region=</code> rewrite and paired <code>stop</code> inert until the name returns, allowing lower safety rows to run. Fixed 240 KB STM32WL profiles keep FPF6 and do not expose this alias; partition sizes are unchanged. <code>get flood.rule[.n]</code>, <code>set flood.rule[.n] type=&lt;type&gt; [hops=...] [channel=...] [prefix=...] [in=...] &lt;drop|scope=...|region=...|rate=N/min|retry|stop&gt; [priority=0-255]</code>, <code>del flood.rule.&lt;n&gt;|all</code> <code>set flood.rule.2 type=any channel=#hamradio retry</code> <code>flood.moderation</code> Decrypts keyed <code>GRP_TXT</code> channels and applies drop, per-username messages/minute, and maximum-hop controls, optionally matched against the first 1-3 path hashes. Supports <code>public</code>, <code>#channel</code>, and 128/256-bit channel keys. Sender names and truncated path hashes are moderation hints, not authenticated identities. <code>get flood.moderation[.n]</code>, <code>set flood.moderation[.n] &lt;channel&gt; &lt;sender&gt; &lt;drop|rate=X/min|hops=N&gt; [path=...]</code>, <code>del flood.moderation.&lt;n&gt;|all</code> <code>set flood.moderation public \"Noisy User\" rate=5/min hops=4</code> <code>clock.sync.mesh</code> Defaults on for all repeater, sensor, and room-server builds; a saved setting overrides that default. It estimates UTC as soon as the configured number of fresh signed-advert or valid Public-channel sources is collected, with a 30-minute bootstrap/retry timer when evidence is still insufficient, then repeats lazily seven days after each successful estimate. New evidence retriggers evaluation after a no-consensus result. <code>clock.sync.mesh now</code> queues an immediate LoRa-only attempt without bypassing quorum or source suppression. Only timestamps from firmware build time through build time plus ten years are recorded. Successful CLI, GPS, or WiFi/NTP clock updates suppress LoRa time collection until reboot; after reboot LoRa is the fallback if NTP cannot sync. Status reports the reason a clock was not set; its <code>.table</code> and <code>.1</code> through <code>.16</code> forms inspect collected samples. <code>get clock.sync.mesh</code>, <code>set clock.sync.mesh &lt;on|off&gt;</code>, <code>clock.sync.mesh now</code>, <code>get clock.sync.status[.table|.1-.16]</code> <code>set clock.sync.mesh on</code> <code>clock.sync.mesh.edge</code> Defaults on so edge infrastructure nodes can collect clock evidence when all packets arrive through one relay path. Verified evidence is observed before the forwarding decision, so disabled forwarding and forwarding filters do not prevent collection. Signed adverts are deduplicated by public key and Public-channel timestamps by case-insensitive display name; all may share one receive path. Public display names are unauthenticated and can be spoofed. Changing this setting clears current clock samples. <code>get clock.sync.mesh.edge</code>, <code>set clock.sync.mesh.edge &lt;on|off&gt;</code> <code>set clock.sync.mesh.edge on</code> <code>clock.sync.internet</code> Adds a read-only internet/NTP estimate at the same initial and seven-day checks on WiFi MQTT repeater-observer builds. Other builds retain the setting but report internet unavailable. <code>get clock.sync.internet</code>, <code>set clock.sync.internet &lt;on|off&gt;</code> <code>set clock.sync.internet on</code> <code>clock.sync.drift</code> Absolute correction threshold in seconds; the default is 600 seconds (10 minutes). The clock is moved forward or backward only when the estimate differs by more than this value. <code>get clock.sync.drift</code>, <code>set clock.sync.drift &lt;30-86400&gt;</code> <code>set clock.sync.drift 600</code> <code>clock.sync.samples</code> Minimum fresh evidence count before mesh time can be used: distinct receive paths in normal mode or distinct advert keys/Public-channel display names in edge mode. A strict majority of all fresh samples is also required. Range <code>3-16</code>; default <code>9</code>. <code>get clock.sync.samples</code>, <code>set clock.sync.samples &lt;3-16&gt;</code> <code>set clock.sync.samples 9</code> <code>outpath</code> Overrides the primary direct route used for replies to the current remote client. <code>get outpath</code>, <code>set outpath &lt;hops&gt;</code>, <code>set outpath direct</code>, <code>set outpath clear</code>, <code>set outpath flood</code> <code>set outpath A1B2C3,D4E5F6</code> <code>altpath</code> Adds a secondary direct route for repeater replies to the current remote client. <code>get altpath</code>, <code>set altpath &lt;hops&gt;</code>, <code>set altpath direct</code>, <code>set altpath clear</code>, <code>set altpath flood</code> <code>set altpath 71CE82,BA09F0</code>"},{"location":"halo_keymind_settings/#other-keymind-commands","title":"Other Keymind Commands","text":"Command What it does How to use Example <code>send text.flood</code> Sends a <code>#repeaters</code> flood text message formatted as <code>&lt;node_name&gt;: &lt;message&gt;</code>, with <code>:</code> in the node name sent as <code>;</code>. <code>send text.flood &lt;message&gt;</code> <code>send text.flood checking ridge link</code>"},{"location":"halo_keymind_settings/#battery-alerts","title":"Battery Alerts","text":"<p>Battery alerts are off by default. Enabling requires a named region. With no region argument, the repeater selects the single deepest (most narrow) region in the hierarchy; if multiple regions tie, the command asks for an explicit region. For example, after <code>region def west pnw wa w-wa sea</code>, <code>set battery.alert on</code> selects <code>sea</code>, while <code>set battery.alert on w-wa</code> overrides the default. Alerts are never sent as unscoped floods, and removing the selected region stops alerts until a valid scope is selected again.</p> <p>The repeater suppresses alerts for its first 30 minutes of uptime. It then checks every 30 minutes and sends a flood text warning to <code>#repeaters</code> when voltage is above <code>1 V</code> and the estimated battery percent is below <code>battery.alert.low</code>.</p> <p>Warnings and critical alerts both use a <code>12</code>-hour resend cooldown, beginning only after the radio reports that the alert transmission completed.</p> <p>Defaults:</p> Setting Default <code>battery.alert</code> <code>off</code> <code>battery.alert.region</code> <code>&lt;unset&gt;</code> <code>battery.alert.low</code> <code>20</code> <code>battery.alert.critical</code> <code>10</code> <p>Example:</p> <pre><code>set battery.alert.low 20\nset battery.alert.critical 10\nset battery.alert on\nget battery.alert\nget battery.alert.region\n</code></pre> <p>CPU power saving remains compatible with the check. The battery timer never requests a wake earlier than its 30-minute deadline; when the normal loop is already awake after that deadline, no additional wake is needed. Sleeping time counts toward the startup delay, and an outbound warning prevents another sleep until the queued packet has been handled. This is separate from RX duty-cycle power saving, which only cycles the LoRa receiver and does not stop the main loop's battery timer.</p>"},{"location":"halo_keymind_settings/#recent-repeater-table","title":"Recent Repeater Table","text":"<p>Direct retry uses the recent repeater table when <code>direct.retry.heard</code> is <code>on</code>. Bridge buckets also use this table: a configured bucket prefix is active only when it was heard within the last hour.</p> <p>Show learned rows:</p> <pre><code>get recent.repeater\nget recent.repeater 2\nget recent.repeaters 2\nget recent.repeater page 3\nget recent.repeaters search A1\nget recent.repeaters search A1B2 page 2\n</code></pre> <p>Search matches overlapping 1-, 2-, and 3-byte path hashes. Each matching row shows its stored SNR and a whole <code>s</code>, <code>m</code>, or <code>h</code> age measured from the most recent recording. Search pages contain up to six rows.</p> <p>Seed or correct a prefix:</p> <pre><code>set recent.repeater A1B2C3 8.5\n</code></pre> <p>Clear learned and manually seeded rows:</p> <pre><code>clear recent.repeater\n</code></pre> <p>Rows are sorted by prefix width, then SNR. A full direct retry failure lowers the matching row by <code>0.25 dB</code>. Unfiltered paged replies contain up to <code>10</code> rows; an unpaged local serial query prints the full table.</p>"},{"location":"halo_keymind_settings/#direct-path-overrides","title":"Direct Path Overrides","text":"<p><code>outpath</code> and <code>altpath</code> apply to the current remote client ACL entry. They need remote client context, so they are not useful from the local serial CLI.</p> <p>Set paths with comma-separated hop hashes. Each hop must be <code>2</code>, <code>4</code>, or <code>6</code> hex characters, and all hops in one path must use the same width. Hex input is case-insensitive. Replies use uppercase hex and retain the commas, so the value can be copied directly into another <code>set outpath</code> or <code>set altpath</code> command.</p> <pre><code>get outpath\nget outpath path\nset outpath A1B2C3,D4E5F6\nset outpath path\nset outpath direct\nset outpath clear\nset outpath flood\nget altpath\nset altpath 71CE82,BA09F0\nset altpath clear\n</code></pre> <p>For example, both <code>set altpath 600000,0d2784,f8dada</code> and <code>Set altpath 600000,0d2784,f8dada</code> store the same path and reply with:</p> <pre><code>&gt; 600000,0D2784,F8DADA\n</code></pre> <p>The first CLI word is case-insensitive (<code>set</code>, <code>Set</code>, and <code>SET</code> are the same, as are <code>get</code>, <code>Get</code>, and the other command verbs). Argument case is preserved.</p> <p><code>get outpath path</code> reports the reciprocal path received after the latest flood login without changing <code>outpath</code>. That packet arrives asynchronously, so retry shortly if the first query reports <code>&gt; path pending</code>; the observation window expires after one minute. The login path is not automatically selected. <code>set outpath path</code> copies the observed route into <code>outpath</code> and saves it; it leaves the current route unchanged when no observed route is available.</p> <p><code>set outpath direct</code> sets a zero-hop direct route for a client reachable without repeaters. <code>set outpath clear</code> forgets the override, replies <code>&gt; outpath cleared</code>, and lets normal path discovery fill it again. <code>set outpath flood</code> forces replies to use flood packets until the client logs in again.</p> <p>When <code>outpath</code> is a valid direct path and <code>altpath</code> is also a valid, different direct path, repeater DM replies send two packets: one on <code>outpath</code> and one on <code>altpath</code>. The secondary <code>altpath</code> copy does not create its own direct-retry state, so retry tracking stays attached to the primary <code>outpath</code> packet. <code>altpath clear</code> disables the secondary direct reply. <code>altpath flood</code> is accepted for command symmetry, but it does not create a second flood reply; only a valid direct <code>altpath</code> sends the second packet.</p>"},{"location":"halo_keymind_settings/#direct-retry-settings","title":"Direct Retry Settings","text":"<p>Direct retry applies to direct-routed packets. A queued resend is canceled when the next-hop echo is heard. Repeaters expose the settings below; non-repeater firmware uses the same packet-type timing rules with fixed shared base/step timing.</p> Setting What it does How to use Example <code>retry.preset</code> Applies shared direct and flood retry defaults. Values: <code>infra</code>, <code>rooftop</code>, <code>mobile</code> or <code>0</code>, <code>1</code>, <code>2</code>. <code>get retry.preset</code>, <code>set retry.preset &lt;value&gt;</code> <code>set retry.preset rooftop</code> <code>direct.retry.heard</code> Uses the recent repeater table as the direct retry eligibility gate. <code>get direct.retry.heard</code>, <code>set direct.retry.heard on/off</code> <code>set direct.retry.heard on</code> <code>direct.retry.margin</code> SNR margin in dB above the SF-specific receive floor. <code>get direct.retry.margin</code>, <code>set direct.retry.margin &lt;0-40&gt;</code> <code>set direct.retry.margin 5</code> <code>direct.retry.count</code> Maximum direct retry attempts after initial TX. Direct-routed type 2 text packets always use 21 attempts regardless of this setting or the short-path cap. <code>get direct.retry.count</code>, <code>set direct.retry.count &lt;1-15&gt;</code> <code>set direct.retry.count 15</code> <code>direct.retry.base</code> Base wait in milliseconds before retry; packet-length add-on is 3x for TRACE and ANON_REQ/type 7, 7x for TXT_MSG/type 2, and 6x for other direct retry packets. <code>get direct.retry.base</code>, <code>set direct.retry.base &lt;10-5000&gt;</code> <code>set direct.retry.base 175</code> <code>direct.retry.step</code> Milliseconds added per retry attempt after the base, packet-length add-on, and random forwarding jitter. <code>get direct.retry.step</code>, <code>set direct.retry.step &lt;0-5000&gt;</code> <code>set direct.retry.step 100</code> <code>direct.retry.cr</code> Adaptive coding-rate thresholds for repeater direct retry packets. Repeaters use <code>CR4</code>, <code>CR5</code>, <code>CR7</code>, or <code>CR8</code>, then escalate by attempt: CR4, CR5, CR7, CR7, then CR8 from a CR4 start; CR5, CR7, CR7, then CR8 from a CR5 start. Non-repeaters start at the current radio CR and follow the same escalation pattern, clamped at CR8. <code>get direct.retry.cr</code>, <code>set direct.retry.cr &lt;cr4_min&gt;,&lt;cr5_min&gt;,&lt;cr7_min&gt;,&lt;cr8_max&gt;</code>, <code>set direct.retry.cr off</code> <code>set direct.retry.cr 10.0,7.5,2.5,0</code> <p>The default adaptive coding-rate profile is <code>10.0,7.5,2.5,2.5</code>. SNR <code>10.0 dB</code> and up uses <code>CR4</code>, <code>7.5 dB</code> and up uses <code>CR5</code>, <code>2.5 dB</code> and down uses <code>CR8</code>, and the middle band uses <code>CR7</code>. If no recent repeater table entry is available, retry packets use <code>CR5</code>. Use <code>set direct.retry.cr off</code> to disable adaptive coding-rate overrides. Repeater attempts escalate from the adaptive starting CR: <code>CR4</code>, <code>CR5</code>, <code>CR7</code>, <code>CR7</code>, then <code>CR8</code> from a <code>CR4</code> start; <code>CR5</code>, <code>CR7</code>, <code>CR7</code>, then <code>CR8</code> from a <code>CR5</code> start. Non-repeaters use the current radio CR as the first retry CR and follow the same pattern up to <code>CR8</code>.</p> <p>Preset details:</p> Preset Base Count Step SNR gate <code>infra</code> <code>275 ms</code> <code>4</code> <code>150 ms</code> SF floor + <code>15 dB</code> <code>rooftop</code> <code>175 ms</code> <code>15</code> <code>100 ms</code> SF floor + <code>5 dB</code> <code>mobile</code> <code>175 ms</code> <code>15</code> <code>50 ms</code> SF floor <p>Example for a quiet fixed repeater:</p> <pre><code>set retry.preset rooftop\nset direct.retry.heard on\nset direct.retry.margin 5\n</code></pre> <p>Example for a moving or weak-link node:</p> <pre><code>set retry.preset mobile\nset direct.retry.margin 0\n</code></pre>"},{"location":"halo_keymind_settings/#flood-and-advert-settings","title":"Flood And Advert Settings","text":"<p>Flood retry applies to flood-routed packets. A queued retry is canceled when the same packet is heard from a qualifying, non-ignored repeater. Bridge mode uses the bucket rules below instead.</p> Setting What it does How to use Example <code>flood.retry.count</code> Base flood retry attempts after initial TX. Role path scaling happens first, then all builds apply payload caps: <code>REQ</code> is <code>0</code>; <code>GRP_TXT</code> keeps up to <code>15</code>; remote-login <code>RESPONSE</code>, <code>TXT_MSG</code>, <code>ANON_REQ</code>, and <code>PATH</code> keep up to <code>15</code> at path count 0 and cap at <code>2</code> in transit; every other flood type caps at <code>1</code>. A lower calculated value is preserved, and <code>0</code> disables flood retry. <code>get flood.retry.count</code>, <code>set flood.retry.count &lt;0-15&gt;</code> <code>set flood.retry.count 7</code> <code>flood.retry.path</code> Maximum path hash count eligible for flood retry, or <code>off</code> to disable the gate. <code>get flood.retry.path</code>, <code>set flood.retry.path &lt;0-63/off&gt;</code> <code>set flood.retry.path 1</code> <code>flood.retry.group.path</code> Additional path gate for group data (<code>type=6</code>) flood retries. The stricter of this and <code>flood.retry.path</code> applies; <code>off</code> disables only this additional gate. Setting the general path gate to <code>0</code> forces this setting to <code>off</code>; a named preset restores the default of <code>1</code>. <code>get flood.retry.group.path</code>, <code>set flood.retry.group.path &lt;0-63/off&gt;</code> <code>set flood.retry.group.path 1</code> <code>flood.retry.advert</code> Allows or blocks retry for node advert packets (<code>type=4</code>). Default is <code>off</code>. <code>get flood.retry.advert</code>, <code>set flood.retry.advert on/off</code> <code>set flood.retry.advert off</code> <code>flood.retry.prefixes</code> Target prefixes. If set, only same-packet echoes from matching last-hop prefixes cancel a retry. <code>get flood.retry.prefixes</code>, <code>set flood.retry.prefixes &lt;prefixes/none/off&gt;</code> <code>set flood.retry.prefixes BEEBB0,425E5C</code> <code>flood.retry.ignore</code> Ignored prefixes. In non-bridge retry, ignored last-hop echoes do not cancel retry. <code>get flood.retry.ignore</code>, <code>set flood.retry.ignore &lt;prefixes/none/off&gt;</code> <code>set flood.retry.ignore 71CE82,C7618C</code> <code>flood.retry.bridge</code> Enables bucket-based bridge retry logic. <code>get flood.retry.bridge</code>, <code>set flood.retry.bridge on/off</code> <code>set flood.retry.bridge on</code> <code>flood.retry.bucket.&lt;n&gt;</code> Shows one bridge bucket. Buckets are numbered <code>1</code>-<code>6</code>. <code>get flood.retry.bucket.&lt;n&gt;</code> <code>get flood.retry.bucket.1</code> <code>flood.retry.bucket</code> Sets bridge bucket prefixes. <code>set flood.retry.bucket &lt;1-6&gt; &lt;prefixes/none/off&gt;</code> <code>set flood.retry.bucket 1 71CE82,C7618C</code> <p>Extended <code>flood.rule</code> rows can select which received floods may use these settings. For example, enable bridge completion only for Public and <code>#hamradio</code> with <code>set flood.rule type=any channel=public retry</code> and a second row using <code>channel=#hamradio</code>. Adding the first active <code>retry</code> row changes received retry selection into an allow-list; deleting the last restores the legacy global selection. <code>channel=hash:XX</code> is available when only the visible one-byte hash is known, but it is not authenticated and is collision-prone. For example, <code>hash:11</code> includes Public and any other packet using <code>0x11</code>; <code>channel=public</code> alone performs the Public-key MAC/decrypt check.</p> <p>Bridge buckets may also be reused as passive <code>flood.channel.scope</code> path selectors with <code>path=bucket:&lt;1-6&gt;</code>. This does not require <code>flood.retry.bridge</code> to be enabled and does not depend on recent-repeater freshness or the retry ignore list.</p> <p>Forwarded neighbor adverts also use an automatic echo guard in every build. If this node hears a downstream, longer-path echo after transmitting an advert whose signed timestamp is less than six hours old, it will not forward that exact advert again during the six-hour age window. This guard works even when <code>flood.retry.advert</code> is off and does not affect self-originated adverts.</p> <p>Self-originated advert retries are deliberately slow: the first retry waits at least one extra minute beyond the normal airtime-aware delay. Queueing a newer self advert retires queued and future retry attempts for older self adverts without disturbing other flood retry sequences. Companion firmware allows the one slow retry for its own adverts but not for neighbor adverts it relays.</p> <p>The shared retry preset sets these flood defaults:</p> Preset Retry count Path gate Group-data path gate <code>infra</code> <code>1</code> <code>1</code> <code>1</code> <code>rooftop</code> <code>3</code> <code>2</code> <code>1</code> <code>mobile</code> <code>15</code> <code>1</code> <code>1</code> <p>Example for path-gated retry:</p> <pre><code>set retry.preset rooftop\nset flood.retry.path 1\nset flood.retry.group.path 1\nset flood.retry.advert off\nset flood.retry.ignore 71CE82,C7618C\n</code></pre>"},{"location":"halo_keymind_settings/#north-south-buckets","title":"North South Buckets","text":"<p>Buckets describe groups of repeaters on different sides of this relay. Bucket numbers do not have built-in meanings; this example uses bucket <code>1</code> for North and bucket <code>2</code> for South.</p> <pre><code>              North bucket 1\n        +-----------------------+\n        | A1B2C3       D4E5F6   |\n        | North A      North B  |\n        +-----------+-----------+\n                    |\n                    v\n              +-----------+\n              | This node |\n              +-----------+\n                    ^\n                    |\n        +-----------+-----------+\n        | 71CE82       C7618C   |\n        | South A      South B  |\n        +-----------------------+\n              South bucket 2\n</code></pre> <p>Configure the buckets:</p> <pre><code>set flood.retry.bridge on\nset flood.retry.bucket 1 A1B2C3,D4E5F6\nset flood.retry.bucket 2 71CE82,C7618C\nset flood.retry.ignore none\n</code></pre> <p>Packet heard from the North:</p> <pre><code>     heard source\n         |\n         v\n  +--------------+        retry targets\n  | North bucket | -----&gt; South bucket\n  | bucket 1     | -----&gt; Other fresh/unbucketed relays\n  +--------------+\n</code></pre> <p>Packet heard from the South:</p> <pre><code>     heard source\n         |\n         v\n  +--------------+        retry targets\n  | South bucket | -----&gt; North bucket\n  | bucket 2     | -----&gt; Other fresh/unbucketed relays\n  +--------------+\n</code></pre> <p>Packet heard from an unbucketed or pathless source:</p> <pre><code>     heard source\n         |\n         v\n  +--------------+        retry targets\n  | Other bucket | -----&gt; North bucket\n  | implicit     | -----&gt; South bucket\n  +--------------+\n</code></pre> <p>Bridge retry stays eligible until every target bucket has been heard or <code>flood.retry.count</code> is exhausted. A configured bucket is a target only when at least one of its prefixes is fresh in <code>recent.repeater</code>. Prefixes in <code>flood.retry.ignore</code> never count as bucket hits.</p> <p>Configuration reports a warning when prefixes in different buckets, including bucket 7 (<code>flood.retry.prefixes</code>), share the same first byte. A 1-byte path cannot distinguish those buckets. Bridge mode therefore excludes every matching bucket when that short prefix is the source, and credits every matching target bucket when it is heard as an echo. This prevents an ambiguous short prefix from keeping an impossible target outstanding through every retry.</p> <p>Each flood retry wait retains the fixed maximum-frame plus 20 packet-airtime delay, then adds random jitter from zero to 200 percent of one additional packet airtime. This keeps nearby repeaters from repeating a collision on fixed timing while capping the added wait at two frames.</p> <p>Only one enhanced retry sequence can be active for the same logical flood packet. Identical floods still receive their normal transmission, but do not multiply the extra attempts. Evicted queued retries release their bridge state, and the final echo wait does not reserve a packet-pool entry.</p> <p>Earlier path hops from a successful bridge echo refresh a separate per-bucket reachability cache without an SNR value. Only the final hop, which actually sent the received RF frame, updates <code>recent.repeater</code> and its SNR. Indirect path hops therefore cannot change direct-retry SNR gating or coding-rate selection.</p>"},{"location":"halo_keymind_settings/#troubleshooting","title":"Troubleshooting","text":"<p>If advert packets are still retrying:</p> <pre><code>get flood.retry.advert\nset flood.retry.advert off\n</code></pre> <p>If ignored prefixes still appear in <code>flood retry good</code> logs:</p> <pre><code>get flood.retry.ignore\nset flood.retry.ignore &lt;prefix&gt;\n</code></pre> <p>The ignored prefix must match the last hop shown as <code>heard=&lt;prefix&gt;</code>. For example, this log needs <code>C7618C</code> in the ignore list:</p> <pre><code>flood retry good (... path=7773D0&gt;C7618C, heard=C7618C ...)\n</code></pre> <p>If retries are too aggressive:</p> <pre><code>set flood.retry.count 1\nset flood.retry.path 1\nset direct.retry.count 4\n</code></pre> <p>If retries are too sparse:</p> <pre><code>set flood.retry.count 7\nset flood.retry.path 2\n</code></pre>"},{"location":"hardware_validation_checklist/","title":"Hardware validation checklist","text":"<p>Use this checklist for release-candidate hardware runs. A check is complete only when its log identifies the physical device, firmware artifact, artifact hash, command result, and cold/warm boot outcome. Do not infer success from a tool's exit code when the tool has a documented false-success mode.</p>"},{"location":"hardware_validation_checklist/#current-marathon-ledger-through-2026-09-01","title":"Current marathon ledger (through 2026-09-01)","text":"Hardware Stable identity Current state Next blocking check Seeed XIAO nRF52840 <code>B35E71C1C3726CE7</code> A stalled Companion transport survived the stop token and exact USB reset, then recovered after a 36-second exact application DFU. Current Full Companion USB, bonded BLE, clock sync, terminal/Binary switching, serial-mOTA folder attach, and reversible dual-CDC logging all pass Prove current-build cold persistence; separately reproduce the stall before using a power cut to test whether power alone clears it; then transfer an actual image through BLE-controlled LoRa OTA Seeed Tracker T1000-E <code>34A9141999729D5D</code> A temporary Full Companion and one of two same-visible-version OTAFIX candidates are running; the exact candidate bytes are not yet proven. The bonded warm baseline passed at 3.34 kB/s. Two lab-only pre-START 15 ms/latency-0 DFUs with <code>0/0</code> no-preference event-length hints passed at 6.23 and 6.52 kB/s; a 10 ms event-length control timed out before START Prove installed bootloader bytes by readback, exercise a physical cold 20-to-244-byte readiness transition, restore the protected Repeater identity, cold boot, then force LR1110 reset RAK3401 <code>0B81C9C68D8D01B4</code>; FICR <code>8D8D01B4 0B81C9C6</code> OTAFIX test version <code>0x02040403</code> passes bidirectional application UF2, exact SWD application/bootloader readback, unchanged UICR, and a 74-block direct V4 LoRa apply from exact <code>3caf9dcf</code> to current HEAD <code>9fd580c8</code>. Post-apply USB and LoRa identity/hash checks pass and the temporary 0 dBm bench setting is restored to 22 dBm Add exact RF packet counters, then repeat the supported-bandwidth and controlled/passive/mixed routed-hop matrix Heltec T096 <code>651F8E496197F882</code> OTAFIX HIL candidate <code>0x02040401</code>, serial DFU, signed LoRa bootloader OTA, warm-watchdog recovery, physical power-removal cold persistence, bonded Legacy BLE application DFU, serial mOTA ownership, button/display wake, and Full Companion dual-CDC reconnect checks pass on <code>keymindCascade</code> <code>fcd1f8cc</code>. The final T096-only no-footer Full Companion image is installed Perform a privileged or physical host-driven USB bus reset without resetting the MCU; complete the deferred multi-click/long-press physical matrix Heltec MeshTower V2 with SD <code>9352162A72082314</code> Exact SD LoRa-OTA Repeater <code>e26d48e4</code> is running after identity-gated BLE recovery. Card format/cooldown/forced-format/raw-erase/remount pass; live bootloader contract reports ABI 3, FULL+INPLACE, and SD apply Signed interrupted-download resume, corruption/signature rejection, then full/delta apply Heltec V4 USB MAC <code>44:1B:F6:6A:E8:44</code>; BLE <code>44:1B:F6:6A:E8:45</code> USB/BLE/Wi-Fi and all three TCP services pass on hardware. The final fresh-NTP-gated Full Companion image builds with 4.31 MB app space free Flash the exact final NTP build, prove NTP-before-TLS success/failure ordering, then OTA seeding SenseCAP Indicator LoRa CH340 plus USB MAC <code>D8:3B:DA:75:23:AC</code>; BLE <code>D8:3B:DA:75:23:AD</code> The current dark-layout application is SHA-256 <code>81bebdc07b6a8349c1c975cb5a0e30c5f6019d35bcac641e5f3d4df951f7406b</code>; identity-gated flash, USB ASCII/Binary switching, runtime logging, and separate configured-Wi-Fi, BLE, and TCP checks pass. Fresh-NTP HTTPS recovery, strict Range resume, STAGEV2 install, and RP USB readback passed on earlier exact artifacts; the final coordinator source still needs its blocked-UDP/123 hardware gate Physical display-wrap and four-mode render/heap checks, exact-final blocked-NTP recovery gate, LoRa/TempRadio, and non-empty OTA seeding <p>The current source checkpoint passes 1,132/1,132 native cases, 68/68 host broker/endpoint cases, all 318 LoRa-OTA chain/route/bundle cases, and 41/41 MOTA format/signature/delta cases under the documented pipx <code>detools</code> interpreter. Indicator geometry, dark-theme, and font-recovery contracts pass 4/4, 6/6, and 25/25. A serialized real Indicator ESP32-S3 Wi-Fi/USB profile also compiles at 95,944 bytes RAM and 1,589,433 bytes flash. The direct system-Python MOTA invocation predictably lacks <code>detools</code>; that environment boundary is not a firmware failure and must not be worked around by installing the package globally.</p> <p>The RAK failure log is <code>/home/mikec/hwtest/runs/rak3401-syncidle-clean-tSp7PLgA/result.txt</code> on the Mercerwood Pi. The tested UF2 SHA-256 was <code>650c9fda456685cdf99c1f2996c60f1f551cc9216d2b746a22c8cb78464b0ff7</code>. <code>cp</code> returned success in 95 ms, but <code>sync -f</code> failed with <code>EIO</code> after 157,188 ms. Post-failure SWD readback proved that all seven ordinary sectors whose bytes differed between the old and intended builds still contained the old values, and the settings page was still erased. The only available pre-copy SWD dump was taken several hours earlier, however, so it cannot prove that zero unchanged blocks were written during this attempt or establish when the stale S140-v7 tail in the first application page appeared. The next run must capture an immediate pre-copy dump as well as the post-copy dump. Serial DFU recovery then completed in 35,698 ms with the exact <code>Device programmed.</code> marker. All 1,830 UF2 payload blocks matched SWD readback after recovery, and the application passed a subsequent real power-removal boot.</p> <p>The corrected 2.4.4-preview.2 candidate was installed through identity-gated SWD from combined-image SHA-256 <code>9b1654baccd2a920f68651893e31d79170400d1a7982a3f854ae640f1d3513a8</code>. An immediate pre-copy dump closed the earlier evidence gap. A deliberately old UF2 then copied and flushed successfully in 16,568 ms, and the exact formerly failing UF2 above copied and flushed successfully in 16,601 ms. After each direction, all 1,830 payload blocks matched a full SWD readback with zero header or payload mismatches. The return update changed 123 bytes across five expected application pages, UICR remained byte-identical, and a subsequent downstream USB power removal plus Pi reboot returned the RAK as the same stable identity. It reported the intended <code>3caf9dcf</code> application, board, node name, USA radio tuple, and 22 dBm setting after that cold boot. The new bootloader's CLI source string is truncated before the injected preview number, so the independently hashed SWD artifact is the authoritative candidate identity for this run.</p> <p>The later TinyUSB lifecycle/generation candidate identifies itself as test version <code>0x02040403</code>. Its exact 40,960-byte bootloader readback SHA-256 is <code>f609eb18754070c54f127325b1cb48547baf5c6b1c695d36fd0c8e0874713c13</code>. With that candidate installed, a full <code>CURRENT.UF2</code> read completed before each write. The 936,960-byte <code>bf092b24</code> application UF2 (SHA-256 <code>12477a9734cf12eb920361bd21024e39bf303953fcf79d0bf720e00847e2ae92</code>) copied and flushed in 28,203 ms and returned to application mode four seconds later. The exact <code>3caf9dcf</code> application UF2 (SHA-256 <code>650c9fda456685cdf99c1f2996c60f1f551cc9216d2b746a22c8cb78464b0ff7</code>) then copied and flushed in 26,479 ms and also returned in four seconds. Both boots retained <code>RAK3401-OTA-BENCH</code> and <code>910.525/62.5/SF7/CR5</code>.</p> <p>Identity-gated SWD then read the entire 468,480-byte padded UF2 application range. Its SHA-256 exactly matched the converted source on both sides at <code>b2e37a7681027ca91d1b2bd8e39b55395d9e91d4863aed17131e50c1ba1d2227</code>. The bootloader still matched the installed <code>0x02040403</code> image byte-for-byte, and UICR still matched the pre-test image at <code>d029ea630c2f632a1b690cb52b2a96a28b6f870c656c3e1bd74ba3a571c53b9c</code>. The authoritative logs are under <code>/home/mikec/hwtest/runs/rak3401-uf2-02040403-20260830-170829</code> and <code>/home/mikec/hwtest/runs/rak3401-uf2-return-02040403-sfHiGEqA</code> on Mercerwood.</p> <p>The subsequent direct LoRa qualification used the V4 as controller/seeder and the RAK's exact <code>bf092b24</code> body <code>91CF4EC2882F23D6</code> as the base. Its mandatory fixed three-minute rehearsal passed on <code>909.95/250/SF5/CR5</code>, including natural expiry and exact normal-radio recovery. The 2,132-byte, two-block in-place delta reached <code>2/2</code> and ready in six seconds; install was accepted, and the new body appeared at the 60-second reboot probe. The automation took 514 seconds including rehearsal, clock/radio safety checks, and post-install verification. The final body was <code>27A223DDFC3A8F47</code>, version <code>1.17.1.5</code> at <code>3caf9dcf</code>, and the bootloader reported <code>blrc:B8</code>, which is OTAFIX's successful application apply result rather than an error. Exact target TX power was wrapped from 22 dBm to 0 dBm for the co-located transfer and restored to 22 dBm afterward; the source RXPS configuration and both normal radio tuples were also restored.</p> <p>Identity-gated SWD then read the live application at <code>0x26000</code>. All 468,384 bytes matched the intended release image exactly (SHA-256 <code>b496e3f4419c9f771564ed3c74b3407822f45acdf60cbd6c4625a54b181ca084</code>), and the independently recomputed EndF hash was <code>27A223DDFC3A8F47</code>. The target ID was <code>2FA509C1</code>, hardware ID was <code>RAK_3401</code>, and version word decoded to <code>1.17.1.5</code>. The 40,024-byte bootloader readback also matched the exact installed <code>ffb1580</code>/test-version-<code>0x02040402</code> artifact byte-for-byte; UICR was unchanged. After SWD reset-halt/resume, USB again reported the expected application, identity, name, radio, 22 dBm, no TempRadio lease, and <code>blrc:00</code> (the retained success diagnostic is intentionally cleared by the next normal boot).</p> <p>The current <code>0x02040403</code> bootloader candidate then passed a second direct V4 LoRa qualification using a materially larger application change. The unsigned in-place package was 75,614 bytes with 75,108 payload bytes and 74 transfer blocks. Its mandatory fixed three-minute rehearsal passed, including natural TempRadio expiry and exact normal-channel recovery; one lost read-only <code>ota status</code> reply was reconciled by its bounded exact retry. The transfer reached 74/74 and READY in 122 seconds, the explicit unsigned install was accepted, and reboot produced exact HEAD <code>9fd580c8</code> with body <code>744BC4443891ED10</code>. The complete safety-wrapped run took 589.487 seconds, including rehearsal, recovery, and final verification. The first postboot <code>ver</code> reply was lost and its exact read-only retry passed. Independent USB checks then confirmed target <code>2FA509C1</code>, hardware <code>RAK_3401</code>, unchanged identity/name/radio/RXPS/watchdog state, bootloader CRC <code>6683C066</code>, ABI 3, apply result <code>blrc:B8</code>, and no active TempRadio/download/seeder/key state. After the separate host-recovery exercise, the near-field TX setting was restored from 0 dBm to its exact original 22 dBm and read back over an authenticated LoRa session. The sanitized authoritative log is <code>/home/mikec/hwtest/runs/rak3401-02040403-head-vzWOXVxT/qualification-redacted.log</code> with SHA-256 <code>3e53dcaa5922c7c18a7890963b8fc092311d2db01caa5603640f43f1482802f6</code>.</p> <p>A serialized VM build of the six connected-board qualification profiles then completed 6/6 in 136.122 seconds: XIAO nRF52 BLE Companion, T1000-E BLE Companion, RAK3401 LoRa-OTA Repeater, SenseCAP Indicator LoRa USB/Wi-Fi Companion, MeshTower V2 SD LoRa-OTA Repeater, and the consolidated Heltec V4 V4.2/V4.3 Full Companion. The earlier V4 selector typo was rejected before any compile began and is not a firmware build failure.</p> <p>After the fresh-NTP download gate, shared SNTP coordinator, MQTT-to-MeshCore RTC handoff, and daily refresh policy were added, the complete native matrix passed 1,102/1,102 cases in 93.953 seconds. The scheduler is host-tested at 24-hours-minus-one-millisecond, the exact 24-hour boundary, normal and wrapped <code>millis()</code> values, a short retry that overrides the daily cadence, the zero deadline sentinel, and a Wi-Fi event latch. A reconnect after a successful sample preserves the existing deadline, so successful samples are requested after boot and then only once per day. All current Python and shell contract suites passed, and the expanded LoRa-OTA automation suite passed 317/317 cases.</p> <p>Serialized real builds also passed after that change. The final event-safe implementation uses an atomic <code>GOT_IP</code> latch so even a short initial connection before the 10-second MQTT status sample cannot skip the required boot NTP request. The final Heltec V4 MQTT Observer application is 1,853,304 bytes with SHA-256 <code>1938ae88fcdbe601cf8698df44b548656079562d899801886b808af913e5f9ac</code>. The consolidated Full V4 image used 2,250,801/6,553,600 flash bytes and left 4,302,799 bytes of app-image space. Its 2,251,272-byte application image has SHA-256 <code>05131eac29164be46d1bcceeb4f03455f5ea8d61c8d4f529b77d8adfe25fdb6a</code>; the 2,316,808-byte merged image has SHA-256 <code>c4c1fc639b6d0087c795a81aca79c07eba56dc4e071eb374dc70da0bec81815e</code>. The focused daily-NTP policy suites passed all 42 cases after the latch was added, and the Full capability manifest verified all ten expected features. The reduced RAK3401 LoRa-OTA Repeater also compiled with the verified WisBlock I2C aliases. At that source state its link used 471,344/815,104 flash bytes; the reduced external-sensor contract retains INA219/INA226/INA260/INA3221 as the voltage/current entries in the optional environmental-telemetry table. These are not the image's only I2C consumers. The image separately retains its SSD1306 display, auto-discovered I2C RTCs, RAK12500 I2C GPS, and RAK12501/L76K UART GPS paths. The configured INA3221 and RAK12500 both default to I2C address <code>0x42</code>; those two devices cannot coexist at those addresses. The supported combined arrangement leaves RAK12500 at <code>0x42</code>, straps INA3221 A0 to SCL for <code>0x43</code>, and uses a build with <code>-DTELEM_INA3221_ADDRESS=0x43</code>. The nRF52840 die-temperature and ADC battery-voltage paths are also retained. The 472,227-byte DFU ZIP SHA-256 is <code>fdd369005a61635756efa9e38b217376a952f334b0864f927a46799b65264fa9</code>, and the matching 943,104-byte UF2 SHA-256 is <code>2155632fde730e0ae2e4a72ce64f89910861f6c5105a4bd7ac96aaa538a33dca</code>. These VM results do not replace the remaining exact-final hardware test with UDP/123 blocked.</p> <p>The later serialized RAK3401 contract build, after the non-blocking nRF52 USB logging change, used 471,576 bytes before its 56-byte EndF trailer. Its EndF body hash is <code>026749684bf6ee8f</code>, target ID is <code>2FA509C1</code>, hardware ID is <code>RAK_3401</code>, and version word is <code>0x01110105</code>. The 472,435-byte DFU ZIP has SHA-256 <code>cf0880b26f2d6bd8157f8af76a6718fe1f998de8ea7df8cd952e734448201fb9</code>; the 943,616-byte UF2 has SHA-256 <code>f893a8cebf309af12a4a6f5483acb28f94158e18632f660e011658c846e8ca7f</code>. The linked ELF contains GPS, SSD1306, RTC, and the four INA families, while an exact symbol audit finds none of AHT10/20, BME280, BMP280, SHTC3, SHT4X, LPS22HB, MLX90614, VL53L0X, BME680/BSEC, BMP085, or RAK12035. The complete native matrix passed 1,112/1,112 cases at that intermediate source state. These are VM gates only; flash the exact artifacts and repeat the physical peripheral and blocked-clock checks before marking any later source state hardware-qualified.</p> <p>Subsequent source hardening changed RAK peripheral discovery: the shared 3V3_S rail remains enabled, UART GPS requires a complete checksum-valid NMEA sentence, an exact INA3221 identity blocks a conflicting u-blox probe, and a successful I2C GPS claim suppresses a sensor only on the same bus and address. The hashes and sizes above describe their recorded intermediate artifacts; they are not current-HEAD evidence and must not be reused for the hardened source.</p> <p>The immutable font endpoint was re-probed only after the VM reported <code>NTPSynchronized=yes</code>. GitHub returned HTTP 206 for bytes <code>0-65535</code>, an exact 65,536-byte match to the checked-in font (range SHA-256 <code>8b0dd308eb01469d1f9e732fba260720a80cc86f6cb5385c28e8a16c76dcfbf3</code>), with total length 1,302,608 and strong ETag <code>\"39ff0cfbe37e36905507697d042869c05374c3202dd96d5a9f98812153f324c1\"</code>. This validates the current strict Range assumptions against the live service; the exact-final Indicator still needs the negative hardware run proving that blocked UDP/123 prevents every TLS request and RP2040 staging write.</p> <p>Mercerwood subsequently recovered without a target write. Both its Tailscale and LAN addresses again accepted SSH, Bluetooth was idle, and the exact T1000-E stable serial <code>34A9141999729D5D</code> was present as application USB <code>239a:8029</code>. The RAK3401 simultaneously uses the same VID/PID, which confirms that every continuation must resolve the stable serial/by-id identity rather than VID/PID. The T1000-E remained in the exact bonded Full Companion application; no stale DFU, scanner, <code>meshcli</code>, or HCI-capture process was running.</p> <p>The post-reboot seven-TTY inventory was also resolved without assuming that one board owned adjacent device names. <code>ttyUSB0</code> is the SenseCAP Indicator's ESP32-S3 CH340 UART and <code>ttyACM5</code> is its RP2040; their sibling physical USB paths and the Indicator's live TCP board reply agree. The separately attached <code>ttyACM4</code> is the MeshTower V2 native <code>HT-n5262</code> endpoint and returned the qualified MeshTower build over its own console. The remaining ACM endpoints independently identify the RAK3401, XIAO nRF52840, Heltec V4, and T1000-E.</p> <p>ModemManager had restarted after the Pi reboot and could probe otherwise idle radio consoles. Six serial-bearing boards now use stable-serial-only <code>ID_MM_DEVICE_IGNORE</code> rules. Because the Indicator CH340 has no stable serial, its separate rule requires the exact current physical port chain and exact <code>1a86:7523</code> identity; there is no broad CH340, product, or VID/PID-only rule. A controlled ModemManager restart reported zero modems, displaced no TTY owner, caused no USB disconnect/re-enumeration, and left all seven endpoints ignored. The same mctomqtt process retained sole ownership of the RAK, while a subsequent Indicator TCP query still returned the expected board and build. Reversible root-only backups were retained on the Pi before each rule update.</p>"},{"location":"hardware_validation_checklist/#run-wide-gates","title":"Run-wide gates","text":"<ul> <li>[ ] Record commit, version string, role/profile, artifact filename, size, and       SHA-256 before flashing.</li> <li>[ ] Archive the exact ELF and symbol/objdump map beside each qualification       firmware. A rebuilt ELF is acceptable for diagnosis only after its       firmware binary matches byte-for-byte; compiler <code>__DATE__</code>/<code>__TIME__</code>       strings can otherwise change both bytes and the EndF body hash.</li> <li>[ ] Bind every operation to a stable USB serial number or physical USB path;       never rely on a changing <code>ttyACM</code>/<code>ttyUSB</code> number.</li> <li>[ ] After erasing/reflashing a BLE board that reuses its Bluetooth address,       remove any stale host bond and pair again with the board's current PIN       before diagnosing service-discovery disconnects. On Linux, verify the       BlueZ agent actually accepted the passkey; a scanner seeing the device is       not proof that Companion GATT is usable.</li> <li>[ ] Do not use BlueZ's advertisement <code>service_uuids</code> as a same-address warm       handoff identity gate. After application/bootloader transitions BlueZ can       merge the bootloader's cached GATT UUIDs into the live application's       advertisement. Gate the application advertisement by exact address and       name, then require the live connected BLEDfu service, control/revision       characteristics, retained bond/encryption, notification subscription,       and observed target disconnect before accepting the handoff.</li> <li>[ ] Do not treat <code>meshcli -P</code> as an infallible pairing probe. Immediately       after one successful post-DFU session, a second invocation with the exact       paired XIAO address hit the meshcore-cli <code>NoneType ... pair/disconnect</code>       path before it created a Bleak client. BlueZ still reported the exact       bond and the same command without <code>-P</code> connected and synchronized the       clock successfully. Capture this as a host-tool failure, then verify the       device independently before blaming firmware.</li> <li>[ ] After a successful <code>BleakClient.connect()</code>, start a fresh disconnect       generation before beginning DFU. BlueZ can fail one internal LE attempt,       retry successfully, and still deliver the failed attempt's callback. A       stale event caused the host to stop notifications and issue a local HCI       disconnect after a valid image CRC but before ACTIVATE; the target and       bootloader had not dropped the link. Preserve an HCI trace through       activation so local-host and remote-target disconnects remain       distinguishable.</li> <li>[ ] Before a BLE pairing/throughput test on a Wi-Fi-managed Pi, record both       management addresses and a same-LAN recovery vantage point. The XIAO       pairing run completed, but Mercerwood then stopped answering on both its       Wi-Fi and Tailscale addresses; BellevueBBS confirmed the old LAN address       was absent at ARP and no replacement LAN host exposed SSH. This is an       infrastructure outage until Pi logs prove a cause, not a firmware or BLE       failure. The T1000-E pairing run reproduced the management outage: its       exact application paired successfully and exposed the complete DFU       service, then Mercerwood stopped accepting SSH and ultimately stopped       answering Tailscale pings. No buttonless DFU write had been sent, and the       T1000 remained in its valid application. Capture Pi Wi-Fi/firmware logs       after recovery and avoid leaving discovery enabled between operations.</li> <li>[ ] Confirm the selected board and role before every erase or flash.</li> <li>[ ] Before every SWD write, read the target FICR device ID and match it to the       intended board's stable USB serial (and physical wiring record). A USB       product name or remembered cable position is not sufficient.</li> <li>[ ] Confirm no other PlatformIO process is active; run only one PlatformIO       build, test, clean, or upload at a time.</li> <li>[ ] Record the installed bootloader, SoftDevice, partition table, or flash       layout independently of the application banner where applicable.</li> <li>[ ] Test both a software reboot and a real power removal/cold boot.</li> <li>[ ] After an update, read back identity, version, radio tuple, node name, and       persistent settings instead of assuming they survived.</li> <li>[ ] Save command output and elapsed milliseconds. Mark a test <code>FAIL</code>, not       <code>PASS</code>, if the transport reports an I/O error even when firmware later       boots.</li> <li>[ ] Before calling a node hung, validate that the probe uses that profile's       command terminator, check a second transport, and capture PC/LR/watchdog       state over identity-gated SWD before reset. Resume once and retest before       using reset as recovery so the diagnostic state is not destroyed first.</li> <li>[ ] Treat a remote login acknowledgement and the following command reply as       separate LoRa packets. A lost login acknowledgement is not proof of       failed authentication when a command-matched private reply from the       selected contact key is present; an explicit negative login result still       fails closed.</li> <li>[ ] Restore the intended USA radio preset and normal-radio mode after tests.</li> <li>[ ] Compare both semantic version and exact EndF/body hash. A transition       between two commits carrying the same version string must stop at the       normal reinstall guard unless the run plan explicitly records and passes       <code>--allow-non-upgrade</code>; a different commit name alone is not authorization.</li> <li>[ ] Do not allow a non-interactive transmission-failure prompt to continue       retry cycles forever. Optional capability probes must fail/fall back after       a bounded interval, while mutations and cleanup retain their stronger       bounded-lease recovery rules.</li> <li>[ ] Before the first remote command after any controller/source reboot, read       its RTC and compare it with a trusted host clock. Advance a clock which is       behind and prove readback; never move a radio clock backward. Fail closed       when it is more than 10 minutes ahead. During the RAK rehearsal the V4       rebooted to <code>2026-03-01</code> while the RAK remained at <code>2026-08-30</code>; the RAK       received the direct packets but correctly rejected their old timestamps       as replays. Setting the V4 to host epoch immediately restored login and       the exact public-key reply at SNR -1.5 dB.</li> <li>[ ] Before every external HTTPS download, require a fresh SNTP response for       that bounded operation, a plausible signed wall clock, connected Wi-Fi,       and a non-expired proof immediately before opening TLS. Re-check the proof       before every resumed/Range TLS connection. A retained plausible RTC or       mesh time is not a substitute for observing NTP, and failure must occur       before any HTTP request body or flash writer begins.</li> <li>[ ] Treat an unacknowledged immediate <code>tempradio</code> mutation as potentially       active, not merely lost. On the tested repeater, scheduled-radio expiry       deliberately waits for <code>hasOutbound()</code> to clear; a CLI reply stranded on       the temporary tuple can therefore hold the node there beyond its nominal       lease. Prefer one fixed absolute <code>tempradioat</code> window per node, so duplicate       delivery cannot extend it, and prove the return on both tuples before a       transfer. If recovering an older immediate handoff, join the exact       temporary tuple to drain the reply before issuing <code>normalradio</code>.</li> <li>[ ] Do not diagnose a co-located high-power LoRa bench failure as weak RF       without an overdrive check. On the RAK3401/V4 bench, the RAK at 22 dBm       produced only 3/6 status replies around -1.5 dB SNR, while a reversible       0 dBm setting produced 6/6 replies in 5--8 seconds at +12 to +12.5 dB       SNR. Read the original power, lower it only for the near-field test, and       require exact restoration afterward.</li> </ul>"},{"location":"hardware_validation_checklist/#compute-placement-gate","title":"Compute-placement gate","text":"<ul> <li>[ ] Run firmware builds, PlatformIO, mOTA/delta generation, compression,       full-image hashing sweeps, symbol generation, and other sustained CPU or       memory work on the VM. Do not offload these jobs to a Pi merely because       the hardware and source artifacts are attached there.</li> <li>[ ] Use the Mercerwood Pi as the identity-gated hardware gateway, SWD/USB/BLE       test host, and LoRa/Wi-Fi seeder. Copy only the completed artifact plus       its manifest/hash to the Pi, then verify the copied SHA-256 before use.</li> <li>[ ] Run CPU work on a Pi only when Pi performance or deployment behavior is       itself the test subject, and label that exception in the run log.</li> <li>[ ] Do not assume a non-interactive SSH session has the same <code>PATH</code> as an       interactive shell. Resolve pipx-installed tools such as esptool and       detools to their explicit venv path, record the version, and fail before       erase if the pinned executable is unavailable.</li> <li>[ ] Treat short serial/BLE/SWD control scripts on the Pi as hardware I/O, not       as permission to generate artifacts there. Use the explicit Python from       the relevant pipx environment when a probe needs one of its dependencies;       the Pi system Python did not contain <code>pyserial</code> during the RAK run.</li> </ul>"},{"location":"hardware_validation_checklist/#lora-controlled-host-recovery-gate","title":"LoRa-controlled host recovery gate","text":"<ul> <li>[x] The privileged recovery boundary is a root-owned, group-restricted       AF_UNIX broker with a fixed command grammar and fixed <code>systemctl</code> argv.       The unprivileged MQTT endpoint cannot gain privileges under       <code>NoNewPrivileges</code>, cannot select an executable or unit, and commits an       action only after its signed challenge/reply has been published and       confirmed. The installed broker passed its cold activation, peer       credential, socket owner/mode, injection, duplicate, timeout, durable       reservation, and ambiguous-outcome checks.</li> <li>[x] A signed <code>host network restart</code> was accepted exactly once in 4.088       seconds. The broker retained one <code>network-restart</code> record at sequence 1,       and the fixed unit journal had exactly one start/finish pair. Independent       management probing measured 7.184 seconds from last successful probe to       first recovered success and 6.314 seconds from first failure to recovery.       Pi-local loopback MQTT delivered 107/107 samples; mosquitto, mctomqtt,       and the endpoint retained their exact PIDs, and mctomqtt remained the sole       owner of the RAK USB port. One read-only LoRa status reply was lost at the       temporary 0 dBm bench setting, then authenticated status returned       <code>scheduled</code>; no mutation was replayed. One monitor parsed two       <code>systemctl --value</code> columns in reverse order, so its boolean labels are       discarded; its PID/MQTT trace and the independent postchecks remain       valid.</li> <li>[x] A signed <code>host reboot</code> was accepted exactly once in 3.312 seconds and       armed the fixed 10-second timer. A changed boot ID and one observed       outage prove one reboot; management recovery took 35.763 seconds from       the last pre-outage success and 31.276 seconds from the first failed       probe. Postboot signed LoRa uptime replied in 3.651 seconds. All seven       exact USB identities returned, only the RAK port was owned, the deployed       configuration hashes were unchanged, and NetworkManager, Tailscale,       mosquitto, mctomqtt, the endpoint, and both privileged sockets were       active. Broker action state is intentionally under <code>/run</code> and persistent       journaling was unavailable, so exactly-once evidence is the accepted       reply, one boot-ID transition, one outage, an inactive timer, and no       second outage; do not claim a durable postboot operation record.</li> <li>[x] Reboot auto-started the still-enabled ModemManager service, but all seven       exact devices retained <code>ID_MM_DEVICE_IGNORE=1</code>, zero modems appeared,       and no TTY was probed or claimed. The service was returned to its       pretest inactive state without disabling or masking it. The RAK then       passed exact identity/body/radio gates; an explicit radio-busy rejection       left TX at 0 dBm, one bounded idempotent retry after idle returned OK,       and authenticated readback proved exact restoration to 22 dBm. V4       identity, power-saving, RXPS, TempRadio, and seeder state also matched       their pretest values.</li> </ul> <p>The sanitized host-recovery evidence bundle is under <code>out/host-actions-live-20260831/</code>. Its <code>SHA256SUMS</code> manifest has SHA-256 <code>5acff71ed98f483bb769e8c99c577bf358d0491355ac72855ee7093cd658bf21</code>, and <code>sha256sum -c</code> verifies every deployed-hash, pre/post-state, radio, OTA, network, and reboot record in that manifest.</p>"},{"location":"hardware_validation_checklist/#mercerwood-pi-usb-power-cycle-gate","title":"Mercerwood Pi USB power-cycle gate","text":"<ul> <li>[ ] Confirm the Pi is reachable through Wi-Fi/Tailscale and that <code>eth0</code> is not       the active management path before cycling its downstream USB tree.</li> <li>[ ] Stop all flashes/transfers, run <code>sync</code>, and release SWD GPIO 8 and GPIO 11       to inputs with no pulls before removing USB power. This prevents an SWD       signal from partially back-powering an otherwise unpowered nRF52.</li> <li>[ ] Never issue a standalone <code>uhubctl ... -a off</code> to Pi root hub location <code>1</code>.       Once its only port is off, the hub disappears from <code>uhubctl</code> discovery and       a separate <code>-a on</code> command fails with <code>No compatible devices detected at       location 1!</code>. This has interrupted two hardware runs.</li> <li>[ ] A downstream hub may be cycled only after resolving the board's stable       USB serial to an exact sysfs path and proving that hub advertises       per-port power switching. Record the hub location and port, cycle only       that port, and gate the re-enumerated VID/PID/serial before continuing.       The T1000-E qualification safely used child hub <code>1-1.2</code>, port 3; this is       not permission to cycle the ganged root hub at location <code>1</code>.</li> <li>[ ] Do not use <code>uhubctl</code> <code>off</code>, <code>on</code>, or atomic <code>cycle</code> on Mercerwood root       hub location <code>1</code>. Physical testing showed that even one atomic <code>cycle</code>       powers the ganged root hub down and then cannot rediscover it to restore       power. Use a planned Wi-Fi-issued <code>sudo reboot</code>, which is the verified       recovery, or arrange a true upstream VBUS removal when that distinction       is part of the test.</li> <li>[ ] Treat root hub <code>1</code> as a ganged operation: every attached test board and USB       Ethernet adapter loses power. After recovery, enumerate every stable       <code>/dev/serial/by-id</code> identity again before resuming any board-specific test.</li> <li>[ ] On this heavily populated root hub, inspect kernel logs for real transfer       faults before and after a flash, and stop ModemManager while it could open       a test TTY. A CH340/ESP32-S3 write which lost the chip at 460800 baud       completed and verified at 115200 after a planned Pi reboot; start at the       board-qualified conservative rate rather than treating a fast partial       transfer as firmware failure.</li> <li>[ ] Under non-interactive SSH, do not let <code>udisksctl</code> fall through to an       interactive polkit password prompt. After resolving the exact UF2 block       device by board serial, either use an already-mounted volume or an       explicit <code>sudo -n mount</code> at a board-specific mount point; re-check       <code>INFO_UF2.TXT</code> model/version before copying.</li> </ul>"},{"location":"hardware_validation_checklist/#seeed-xiao-nrf52840","title":"Seeed XIAO nRF52840","text":"<ul> <li>[ ] Stable USB identity distinguishes application (<code>2886:8044</code>) from UF2       bootloader (<code>2886:0044</code>).</li> <li>[ ] Do not repeat the known-failing full-application UF2 copy under the       installed initial 2.4.4 candidate. The identity-gated 897,024-byte copy       returned exit 0, then <code>sync -f</code> failed with <code>EIO</code> in 850 ms; the kernel       logged an offline device, lost queued writes, and FAT errors before USB       disappeared. Recover through a separately hash-gated BLE/serial path and       qualify a corrected bootloader candidate before retrying UF2.</li> <li>[ ] SWD readback exactly matches the intended bootloader-region SHA-256.</li> <li>[ ] Actual SoftDevice FWID and runtime application base match the artifact       (<code>S140 7.3.0</code>: FWID <code>0x0123</code>, application base <code>0x27000</code>).</li> <li>[ ] Exercise and independently verify the exact-board combined       bootloader+SoftDevice recovery path before relying on it in the field.       A wrong-layout nRF52840 application can overwrite part of S140 while the       UF2 bootloader still accepts files and the application still reads flash;       internal writes or <code>InternalFS.format()</code> may then hang or reboot. An       application-only UF2 and a filesystem erase cannot repair that state.       The known XIAO incident in upstream issue #3284 recovered only after the       matching Sense/non-Sense OTAFIX bootloader+S140 ZIP was installed. Keep       board identity, SoftDevice FWID, application base, and package contents       as four separate pre-write gates.</li> <li>[ ] Invalid settings enter persistent UF2 recovery after a cold boot.</li> <li>[ ] UF2 application copy returns success; <code>sync -f</code> returns success; the host       has no offline-sector, lost-write, or FAT I/O errors.</li> <li>[ ] Application enumerates after update and reports the expected board,       version, role, and radio tuple.</li> <li>[ ] Legacy serial DFU crosses all application pages, emits the exact       <code>Device programmed.</code> success marker, and rejects false-success output.       Two application serial-DFU attempts on this board timed out waiting for       the start ACK while <code>adafruit-nrfutil</code> still returned exit 0, so exit       status alone is explicitly insufficient.</li> <li>[ ] Legacy BLE DFU verifies each cumulative PRN receipt exactly and fails on       a missing, short, regressive, or overreported offset; it may adapt       only among the packet-size-specific safe receipt windows after timely       exact receipts and must step back down on slow exact receipts. Final       application/SoftDevice/bootloader CRC and a peer disconnect are mandatory       before declaring success.</li> <li>[ ] Every upward PRN move is a bounded adjacent-level probe. A failed probe       or a later real demotion blocks further increases for that transfer, while       additional slow exact receipts may still negotiate down one level at a       time. This prevents <code>4 -&gt; 8 -&gt; 4 -&gt; 8</code> churn without disabling a safe       initial probe or a <code>32 -&gt; 16 -&gt; 8</code> fallback.</li> <li>[x] The exact Full Companion ZIP       <code>Xiao_nrf52_companion_radio_full-v1.17.1.5-halo-keymind-cascade-3caf9dcf.zip</code>       (SHA-256 <code>9a916c1a3ea83d8f6dd704465fe9c044a363478f852a4369cf6b13424a7a9430</code>)       installed over BLE in 237,297 ms at about 2,110 B/s using ATT MTU 247,       244-byte writes, PRN 4, and exact cumulative receipts. Validate and the       target-initiated disconnect passed. USB then reported the exact expected       version/hash, USA radio tuple, key, RXPS policy, and reversible       Terminal/Binary mode; the new application advertised NUS as       <code>MeshCore-4610BBD2</code>.</li> <li>[x] The post-update application was paired through BlueZ with the expected       PIN. Companion GATT then returned the same public key, USA radio tuple,       22 dBm limit, non-repeater role, board, and build over BLE. Its RTC was       18,038 seconds behind the trusted host; <code>clock sync</code> advanced it and the       immediate readback was within one second of the host interval. No       backward clock write was performed.</li> <li>[x] A second exact same-image update exercised application buttonless DFU and       retained-peer bootloader entry. The bootloader deliberately reused the       bonded application address <code>E5:C3:A8:B0:60:66</code> rather than the cold-entry       address ending in <code>:67</code>; exact name, Legacy DFU service, and DIS model       gates still passed. The first adaptive threshold remained at PRN 4 and       completed all 448,416 bytes at about 877 B/s in 527,832 ms; validate,       target disconnect, USB identity, application key, role, and USA radio       readback all passed. The application clock was then about 10 minutes       behind because its RTC did not advance during the bootloader transfer;       it was advanced to the host clock and proved by immediate readback.</li> <li>[x] A third same-image A/B run used bounded neutral-window exploration. At       244-byte writes, two exact neutral PRN-4 receipts triggered one adjacent       PRN-8 probe. PRN 8 measured about 845 B/s against an approximately       879 B/s PRN-4 baseline, so the helper rolled back to PRN 4 after two       receipts and never re-probed. All 448,416 bytes completed at about       870 B/s in 531,804 ms; CRC validation, target disconnect, USB return,       exact Companion key/role/radio readback, and post-DFU forward clock sync       passed. This proves up/down sender-window adaptation and no churn, while also showing       that PRN receipt overhead is not the bonded-path bottleneck on this run.</li> <li>[x] A bootloader candidate built from exact ZIP SHA-256       <code>9c70200fc15a315a50ec68d2a905b5bcf2fc07a796a21fbd439535ec19a608be</code>       disabled inherited slave latency locally during DFU DATA. The controller       trace still reported the peer-negotiated 30 ms interval and latency 4,       with no connection-parameter update after START; the change is therefore       a local event-attendance override, not a GAP speed renegotiation. A cold       address-generation control completed 448,416 bytes at 2,231 B/s and       passed validation/activation in 226,103 ms.</li> <li>[x] Two subsequent bonded application-to-bootloader runs completed the exact       same 448,416-byte image at 3,524 and 3,534 B/s. Their complete elapsed       times, including exact application advertisement proof, buttonless       handoff, bootloader scan, erase, DATA, CRC validation, activation, and       reboot, were 169,414 and 169,221 ms. Both targets initiated the final       disconnect; USB returned as stable serial <code>B35E71C1C3726CE7</code>; the public       key, 22 dBm setting, USA <code>910.525/62.5/SF7/CR5</code> tuple, board, and build       read back exactly. Compared with the prior roughly 877 B/s bonded run,       the DATA rate improved by about 4.0x without increasing the PRN window       beyond 8.</li> <li>[x] An exact bonded B-A-B link-profile sequence used the same Full Companion       ZIP SHA-256 <code>9a916c1a3ea83d8f6dd704465fe9c044a363478f852a4369cf6b13424a7a9430</code>,       lab helper SHA-256 <code>4909c617de37b5666cc622b7190568f002280f55bf26a05843ea283f2be8f566</code>,       handoff helper SHA-256       <code>1bad570173079b623bbe2bbb9e5ba7c4f8ac379bf966bfd4382c5266fb9fd214</code>,       stable USB serial, bonded address, and 448,416-byte application throughout.       First B, <code>xiao-ble-event-length-prestart-20260830-072641-W7COxm</code>, used one       exact pre-START 15 ms/latency-0 update with <code>0/0</code> no-preference event-length       hints and completed DATA in 72.030 seconds at 6,225 B/s; DFU through target       disconnect was 102.792 seconds and the full workflow was 117,064 ms.       Control A, <code>xiao-ble-control-prestart-20260830-073149-yKf0lO</code>, requested no       update, retained the bootloader connection's 30 ms/latency-4 link, and       completed DATA in 134.131 seconds at 3,343 B/s; DFU was 165.137 seconds and       the full workflow was 182,624 ms. Final B,       <code>xiao-ble-exact15-prestart-20260830-073554-FuGPfH</code>, repeated exact 15 ms and       completed DATA in 71.970 seconds at 6,231 B/s; DFU was 102.799 seconds and       the full workflow was 117,179 ms. Both B rates were about 1.86x control and       differed by only 0.096%.</li> <li>[x] The B-A-B protocol and link gates passed independently. Both B runs probed       PRN 4 -&gt; 8 after an exact 0.135-second four-packet receipt, rolled back       once to PRN 4 after the exact 0.345-second eight-packet receipt, and never       re-probed. Control A likewise probed after 0.269 seconds and rolled back       after 0.600 seconds. Each B bootloader connection had exactly one matching       HCI Update Complete before START; control A had no bootloader-connection       update. All three captures contained zero connection updates from START       through DATA, CRC validation, activation, and the target-initiated       disconnect. Each run ended <code>RESULT=PASS</code>, <code>RC=0</code>, <code>STAGE=complete</code>; final B       returned the exact Full Companion application as USB <code>2886:8044</code>, stable       serial <code>B35E71C1C3726CE7</code>, with current application name       <code>MeshCore-4610BBD2</code>. A fresh post-B binary Companion query independently       re-gated the unchanged public identity, name, Full Companion role, 22 dBm       power, and USA <code>910.525/62.5/SF7/CR5</code> radio tuple. A separate bonded BLE       application query then returned the same board, build, and Full Companion       role, so the USB return did not mask a broken Companion BLE path or stale       bootloader alias.</li> <li>[x] The current host-controller ceiling is independently characterized. The       Pi Zero 2 W Broadcom UART controller reports HCI/LMP 4.2 but supports only       LE 1M; LE Read Maximum Data Length and Read Suggested Default Data Length       both return Unknown HCI Command. The final B capture contains 1,837 full       244-byte firmware writes,       each split into ten 27-byte HCI ACL fragments; all 18,425 transmitted ACL       fragments received completed-packet accounting. The median full-write gap       was 29.947 ms at 15 ms versus 59.936 ms in control A. A BLE 5 controller       with working Data Length Extension is therefore the next host-side speed       experiment; this built-in controller cannot exercise DLE or LE 2M.</li> <li>[x] The host helper now clears a disconnect callback left by an unsuccessful       internal BlueZ connection attempt only after <code>connect()</code> has returned a       live link, and labels PRN changes as adaptation rather than link       negotiation. All 81 strict host tests pass. The first physical run before       this fix still proved the 3,520 B/s DATA rate and returned a successful       validation response, but is correctly recorded as FAIL because the stale       host event prevented ACTIVATE.</li> <li>[ ] Warm app-to-bootloader handoff is tested with the application watchdog       active; cold recovery is tested separately.</li> <li>[ ] BLE Companion/recovery behavior and radio-reset recovery are exercised.</li> <li>[x] The post-Pi-recovery application still enumerated as exact       <code>2886:8044</code> / <code>B35E71C1C3726CE7</code>, but one identity-gated, bounded USB       Binary Companion attempt received no protocol response. <code>meshcore-cli</code>       1.6.0 printed both of its no-response error lines and nevertheless exited       zero; the supervisor treated the attempt as a failure and independently       proved that no process retained the serial port. The exact terminal-stop       token and an identity/path-gated USB bus reset also failed, which excludes       an ordinary startup Terminal-mode hold and host USB endpoint state. The       external tool defect remains in upstream <code>meshcore-cli</code> 1.6.3: its serial       creation failure returns normally, so callers must validate command output       instead of trusting exit zero. The LoRa-OTA controller has an exact       three-diagnostic regression and continues to fail closed.</li> <li>[x] An exact hash-recorded Full Companion application DFU erased/replaced only       the application and completed in 36 seconds. The transferred ZIP was       440,083 bytes with SHA-256       <code>9946b8417c389784ac92c20e4ce5cf0b6a0123a58136627c0689815637f96992</code>.       The same stable USB serial returned as interface <code>00</code>; USB and the existing       bonded BLE identity both reported <code>Seeed Xiao-nrf52</code>, the 31-Aug-2026       build, and Companion role. Preserved settings included a roughly six-month       stale clock, which Binary Companion <code>clock sync</code> advanced to one second of       the Pi without changing the role.</li> <li>[x] The recovered application passed explicit Terminal start/stop, exact board       query, saved <code>usb.logging off</code>, source-only OTA status, and a real serial       <code>motatool serve</code> attach/detach with an empty folder (<code>COUNT -&gt; 0</code>). Binary       Companion returned after both terminal and mOTA ownership. Enabling USB       logging and rebooting produced exact interfaces <code>00</code> and <code>02</code>; interface       <code>02</code> emitted 123 bytes of entirely printable log data while Binary       Companion stayed usable on <code>00</code>. Disabling and rebooting removed <code>02</code>,       restored the single-interface descriptor, and read back logging off.</li> <li>[ ] A physical power-removal cold test is still needed to prove persistence of       the current application. It cannot retrospectively determine whether a       power cycle alone would have cleared the original stall. Answer that only       after reproducing the stall under a bounded stress loop, capturing state,       and power-cycling before any DFU. The application DFU proves recovery but       intentionally does not claim the underlying stall trigger is fixed.</li> </ul>"},{"location":"hardware_validation_checklist/#seeed-tracker-t1000-e","title":"Seeed Tracker T1000-E","text":"<ul> <li>[x] Stable application identity <code>34A9141999729D5D</code> is recorded and is not       confused with the RAK3401 even though both currently enumerate with USB       product ID <code>239a:8029</code>. Application is <code>239a:8029</code>; the exercised       bootloader is <code>2886:0057</code>, with the same stable serial and exact       <code>T1000-E</code>/<code>T1KE_DFU</code> model/name gates.</li> <li>[x] A post-Pi-recovery, identity-gated, read-only USB Companion query returned       the exact T1000-E model, non-repeater Full Companion role, 22 dBm maximum,       and <code>910.525/62.5/SF7/CR5</code>. Its clock readback was within the query's       few-second host interval. No clock, radio, role, key, or settings write       was issued.</li> <li>[ ] Board, version, repeater role, bootloader status, and USA radio tuple are       correct after erase/install and after reboot. The live baseline and a       2,184 ms software reboot passed: <code>3caf9dcf</code>, <code>Seeed Tracker T1000-E</code>, 22 dBm,       <code>910.525/62.5/SF7/CR5</code>, OTA target <code>7B071FA0</code>, bootloader       <code>0.11.0-OTAFIX2.4.3</code>, and full OTA base hash       <code>3E92B157128B6963</code>. A real power-removal boot is still required.</li> <li>[ ] UF2 and serial DFU installation paths complete without host I/O errors.       On OTAFIX 2.4.3, an identity-gated root copy of the exact old UF2 returned       success in 112 ms, but the device disconnected before host writeback was       durable: <code>sync -f</code> failed with <code>EIO</code> after 17,695 ms and the kernel logged       lost asynchronous writes/FAT read errors. The old application happened to       boot and retained its settings, but this transport is a FAIL. Retest       with the corrected 2.4.4 candidate before qualifying T1000-E UF2.</li> <li>[x] The installed <code>t1000e_repeater_lora_ota_no_external_sensors</code> profile does       not compile the Companion BLE transport and did not advertise during a       post-reboot BlueZ scan; that is expected for this repeater image. BLE       Companion qualification belongs to the separate T1000-E Companion build.</li> <li>[x] The exact latency-disable bootloader candidate ZIP (SHA-256       <code>ebe9739ce40c2c7cc1f52076f9614194959fcf6df93d37666b69b7bd415fab68</code>)       installed through identity-gated serial DFU. The final output contained       exactly one terminal <code>Device programmed.</code> success line, the bootloader       returned as <code>2886:0057</code>, and its embedded manifest identifies       <code>T1KE_DFU</code>, S140 7.3/FWID <code>0x0123</code>, application base <code>0x27000</code>, and test       version <code>0x02040403</code>.</li> <li>[ ] The later connection-policy-reapply combined ZIP (SHA-256       <code>c2de1fb2704154b4abc371b6b4827c32ad09c4d15f3f6d97d0f4182bb51fff58</code>)       was identity-gated, transferred, validated, activated, and returned as       exact <code>2886:0057</code> recovery USB. <code>INFO_UF2.TXT</code> reported       <code>0.11.0-OTAFIX2.4.3-3-gffb1580-dirty-test-version-0x02040403</code>, S140       7.3.0, and the T1000-E board. The earlier and later candidates share the       same visible version string, however, so package sequencing and INFO_UF2       do not independently prove the installed bootloader bytes. Require an       identity-gated live bootloader-region readback or a uniquely versioned       rebuild before checking this item.</li> <li>[x] The combined-image BLE transport itself passed: 193,688 bytes at       3,331 B/s, target CRC validation, and target-initiated activation. The       package contains SoftDevice plus bootloader and <code>APP=0</code>, so remaining in       recovery USB was the correct postcondition. Its first supervisor record       is not accepted as run-level evidence: TERM inherited status zero and       wrote a false <code>PASS</code> at <code>STAGE=post_copy_usb</code>. A separate audit records       the transport result, and all later wrappers map INT/TERM to nonzero and       refuse <code>PASS</code> unless <code>STAGE=complete</code>.</li> <li>[x] A separate exact application recovery after that combined transfer       completed 404,468 bytes at 2,095 B/s, validated, activated, and returned       stable application USB in 225,899 ms. The lower rate is the expected       cold/unbonded class, not the bonded warm baseline.</li> <li>[x] A cold exact Full Companion application ZIP (SHA-256       <code>b3be000ab2391527a325cc868e2706dec291c167b6e6cd3495908addb8af6c65</code>)       completed all 404,468 DATA bytes over BLE at 1,572 B/s. The complete       workflow took 281,236 ms (about 1,438 B/s end to end, including setup,       validation, activation, and reboot). ATT MTU reached 247, but BlueZ's       independently cached maximum write size was still 20, so the       identity-gated helper correctly used 20-byte packets, adapted PRN       8 -&gt; 16 -&gt; 32, validated CRC, activated, observed the target-initiated       disconnect, and gated the exact USB application return.</li> <li>[x] The Full Companion application advertised as <code>MeshCore-F9AD7082</code> at the       expected address generation, paired with the qualification PIN, and       exposed its bonded, MITM-protected Legacy DFU service after connection.       That DFU service is intentionally absent from the advertisement, so an       advertisement-only check is insufficient. A 1200-baud USB touch instead       selects serial-only DFU and correctly produces no BLE advertisement;       use the bonded application control characteristic for a warm BLE handoff.</li> <li>[x] Exact same-address bonded warm buttonless DFU passed. The application       advertisement, Paired/Bonded state, connected BLEDfu service/control/       revision layout, encrypted notification/write gate, observed target       disconnect, <code>T1KE_DFU</code> advertisement, DIS model <code>T1000-E</code>, ATT MTU 247,       and 244-byte write capability were all checked. All 404,468 bytes were       confirmed in 121.081 seconds at 3,340 B/s; DFU through target disconnect       took 144.076 seconds and the full supervisor took 176.958 seconds. CRC,       activation, and exact <code>239a:8029</code>/<code>34A9141999729D5D</code> USB return passed.</li> <li>[x] Two accepted in-DATA 30 ms -&gt; 15 ms -&gt; 30 ms controller experiments       completed without corrupting either image, but were decisive negative       performance results. The first finished DATA in 425.398 seconds at       951 B/s; the later candidate finished DATA in 449.063 seconds at 901 B/s.       HCI capture found the cause: <code>hcitool lecup</code> silently encoded both       connection-event-length hints as <code>0x0001</code> (0.625 ms). The Pi's Broadcom       4.2 controller consequently scheduled about one ACL fragment per event:       roughly 64 fragments/s at 15 ms and 32 fragments/s after the 30 ms       \"rollback\", versus roughly 120--144 fragments/s on the untouched link.       The later pre-START controls prove that 15 ms itself is not slow; the       restrictive event-length hint and in-DATA update/rollback were unsafe.</li> <li>[x] Two exact 15 ms/latency-0, zero-event-length lab controls passed:       <code>t1000-ble-event-length-prestart-20260830-071549-QOeVuw</code> completed all       404,468 DATA bytes in 64.905 seconds at 6,232 B/s (95.635 seconds through       target disconnect; 112,639 ms full workflow), and       <code>t1000-ble-event-length-prestart-20260830-071825-VE9Re3</code> completed DATA in       62.070 seconds at 6,516 B/s (92.794 seconds through target disconnect;       106,807 ms full workflow). Both used exact <code>0/0</code> no-preference minimum and       maximum connection-event lengths. On each bootloader connection the HCI       trace contains exactly one successful update before START and none from       START through DATA, validation, activation, and the target disconnect;       Update Complete preceded START by 7.535 and 7.536 seconds. Completed-packet       clusters followed the 15 ms connection anchors, while the median full-size       DFU write gap was 29.997 ms in both traces. Exact package hash, CRC,       activation, and stable application USB return passed twice.</li> <li>[x] <code>t1000-ble-event-length-prestart-20260830-071358-ogzmRy</code> is the bounded       negative control. HCI accepted exact 15 ms/latency 0 with both event-length       hints set to 10 ms, then reported <code>Connection Timeout (0x08)</code> 6.810 seconds       after Update Complete during the 20-second pre-START pause. The run failed       closed at <code>STAGE=pre_start_update</code> in 44,227 ms; START and application DATA       were never sent. A 10 ms event-length hint is therefore rejected for this       adapter/target pair.</li> <li>[ ] Production BLE DFU keeps the controller-negotiated link and issues no raw       host connection update unless that exact adapter/target profile has been       separately graduated. The opt-in lab path may issue exactly one request on       the bootloader connection before START while sent/confirmed are zero: exact       interval and latency, <code>0/0</code> no-preference event-length hints, bounded pause,       and a matching HCI Update Complete are mandatory. Failure or mismatch       disconnects before START. Never update or roll back the link during DATA;       only the protocol PRN/window may adapt there. Compare complete repeated       control/candidate DFUs offline before graduating a production profile.</li> <li>[ ] Repeat the cold transfer with the host's bounded BlueZ readiness wait.       When ATT MTU is greater than 23 while the cached write capability remains       20, it polls the same connected DFU characteristic for at most three       seconds, aborts on disconnect, disappearance, or characteristic-handle       change, and otherwise falls back safely to 20. The four readiness unit       cases and all 81 strict helper tests pass; a physical 20 -&gt; 244-byte       promotion is still required.</li> <li>[ ] Restore the protected       <code>t1000e_repeater_lora_ota_no_external_sensors</code> application (target       <code>0x7B071FA0</code>, exact ZIP SHA-256       <code>9b9be2bee9ebb6644d22806d404fe02c415d037707713d206fa43a8c689cf632</code>)       through identity-gated application DFU while retaining the candidate       bootloader. Do not use the generic repeater image or the unqualified UF2       path. Verify the protected private/public identity without printing the       private key, plus exact name, latitude/longitude, build/body/OTA target,       USA radio, 22 dBm, GPS off, power saving on, RX gain on, RXPS on,       watchdog on, telemetry access <code>all</code>, no TempRadio/download, and a valid       admin login.</li> <li>[ ] LoRa radio reset/recovery is forced and normal receive/transmit resumes.       Normal post-reboot bidirectional LoRa is already proven: the V4 learned a       zero-hop path, received the exact message-specific ACK in 558 ms, and       received the T1000-E's exact <code>3caf9dcf</code> version reply. A deliberately       forced LR1110 recovery event is still required.</li> <li>[x] Direct V4 LoRa OTA receive, apply, reboot, and post-update verification       passed from exact <code>bf092b24</code> body <code>9443FB5E6F23FC1B</code> to exact <code>3caf9dcf</code>       body <code>3E92B157128B6963</code> on OTAFIX 2.4.3. The mandatory fixed three-minute       rehearsal passed at <code>909.950/250/SF5/CR5</code>, including natural expiry and       return to <code>910.525/62.5/SF7/CR5</code>. The 2,036-byte/two-block delta reached       ready in six seconds, the new body replied at the 50-second probe, and the       complete safety-wrapped runner took 519 seconds. V4 source RXPS and both       normal radio tuples were restored. The co-located T1000 was temporarily       reduced to 0 dBm and restored to 22 dBm using bounded retries across its       RXPS busy windows.</li> <li>[x] Independent post-LoRa-OTA USB verification matched the protected pre-run       private key, public key, name, latitude, and longitude without printing       private material. GPS remained off; device power saving, system watchdog,       RX gain, and RXPS remained on; telemetry access remained <code>all</code>; no       TempRadio lease or download remained. <code>blrc:B8</code> is the expected OTAFIX       application-apply success diagnostic. A subsequent software reboot reset       uptime and preserved the exact build/body, name, radio, 22 dBm, GPS,       power-saving, RXPS, watchdog, and no-TempRadio state. The CDC symlink did       not disappear during this warm reset, so uptime/readback\u2014not USB removal\u2014       is the required reboot proof on this board.</li> <li>[x] GPS was initially off, enabled successfully under device power saving,       reported active/no-fix/zero-satellites with its duty-cycle deadline, and       was restored to off. Device power saving reported on, RXPS reported       <code>on,18205,20423</code>, GPS advert policy <code>prefs</code>, and telemetry access <code>all</code>.</li> </ul>"},{"location":"hardware_validation_checklist/#rak3401","title":"RAK3401","text":"<ul> <li>[x] Stable USB identity and SWD FICR identity are independently matched.</li> <li>[x] Source-level WisBlock peripheral pins are complete and non-conflicting:       I2C SDA/SCL are P0.13/P0.14 through both <code>PIN_WIRE_*</code> and       <code>PIN_BOARD_*</code>; GPS-module RX crosses to MCU UART TX P0.16, GPS-module TX       crosses to MCU UART RX P0.15, and PPS is P0.17. A static contract test       prevents these aliases from silently disappearing or being uncrossed.</li> <li>[x] Ordinary/full-sensor RAK3401 profiles use the source-built Adafruit BME680       provider, not Bosch's precompiled BSEC archive, so upstream issue #3292's       soft-float/hard-float link mismatch is not reachable there. The reduced       LoRa-OTA profile deliberately omits BME680/BSEC and the other declared       optional environmental/ranging drivers. A static contract test requires       the hard-float path fix and BSEC dependency if BSEC is enabled in this       board or an inherited full-sensor recipe later.</li> <li>[ ] With the RAK13302 radio installed, detect a RAK12501/L76K UART GPS from a       complete checksum-valid NMEA sentence in sensor slot A. Confirm random       UART bytes, an incomplete sentence, and a bad checksum do not claim GPS.</li> <li>[ ] Detect RAK12500 I2C GPS alone at <code>0x42</code>; exercise GPS power saving and       confirm the shared 3V3_S rail, OLED, RTC, and other slots remain powered.</li> <li>[ ] Detect INA3221 alone at the firmware-configured <code>0x42</code> and prove the       discovery path does not send u-blox configuration traffic to it.</li> <li>[ ] Exercise RAK12500 at <code>0x42</code> and INA3221 at <code>0x43</code> together after strapping       INA3221 A0 to SCL and building with       <code>-DTELEM_INA3221_ADDRESS=0x43</code>; verify both retain independent telemetry.</li> <li>[ ] With a representative omitted environmental sensor attached, confirm the       reduced image leaves the generic I2C bus healthy but does not advertise a       driver that was intentionally removed.</li> <li>[x] Local USB terminal probes are terminated with carriage return (<code>\\r</code>).       This CLI echoes an LF-only command without executing it; an echoed       <code>ver</code> with no reply is therefore a bad probe, not evidence of a hung       application. Confirm any suspected hang with a CR-terminated command,       LoRa status, and SWD state before resetting the board.</li> <li>[x] Assert CDC DTR when probing the RAK terminal. With DTR deasserted, writes       reached the port but no CLI replies were returned; the same exact       stable-identity port returned the expected version immediately after DTR       was asserted. Keep 1200-baud bootloader touch separate from 115200-baud       application probes, and allow a full reply window so delayed responses       are not attributed to the following command.</li> <li>[x] Installed S140 6.1.1 FWID (<code>0x00B6</code>) and runtime application base       (<code>0x26000</code>) are independently verified.</li> <li>[x] Bootloader version and apply capabilities are independently reported.</li> <li>[x] UF2 application copy returns success; <code>sync -f</code> returns success; no USB       reset/timeout or offline-sector errors occur; SWD readback matches every       UF2 payload byte. Current 2.4.4-preview.2 result is PASS in both       current\u2192old and old\u2192current directions.</li> <li>[x] Board, repeater role, version, name, and USA radio tuple are verified       after serial recovery and again after a real cold boot.</li> <li>[x] Six consecutive authenticated <code>ota self</code> attempts leave the application       healthy. In the qualification run, two login/reply pairs were lost, one       login succeeded while its command reply was lost, and the next three       commands replied in about 2.5 seconds each. A CR-terminated local <code>ver</code>       probe passed after every attempt; packet loss did not become a node hang.</li> <li>[ ] An unchanged admin login does not rewrite the ACL flash file, while an       actually changed/newly learned persistent route schedules exactly one       delayed save and survives reboot. Cover delayed flood-path replies,       already-unknown paths, changed permissions/secrets, new/evicted clients,       and the intentionally non-persistent guest case. Do not rely on an       unrelated login write to capture a later PATH response.</li> <li>[ ] Location and private-key persistence are verified without exposing the       private key in logs.</li> <li>[x] Serial recovery rejects nrfutil's false exit-0 failure, requires the exact       success marker, and produces a byte-exact SWD application readback.</li> <li>[ ] UF2/serial recovery works with both the deployed older bootloader family       and the current backward-compatible application.</li> <li>[ ] Bluetooth advertisement and connection work when enabled. The tested       repeater profile does not advertise BLE during normal operation.</li> <li>[x] Direct LoRa OTA from the V4 passes with elapsed time, bounded retry       behavior, final hash/version verification, exact radio restoration, and       independent SWD readback. The qualified <code>bf092b24</code> base       <code>91CF4EC2882F23D6</code> reached <code>3caf9dcf</code>/<code>27A223DDFC3A8F47</code> using a       two-block, 2,132-byte delta: ready in six seconds, new body at the       60-second reboot probe, and 514 seconds for the complete safety-wrapped       run. Log:       <code>/home/mikec/hwtest/runs/rak3401-0dbm-final-9KWjey61/run.log</code>.</li> <li>[x] The current OTAFIX test version <code>0x02040403</code> independently passes a       74-block direct LoRa update from exact <code>3caf9dcf</code> body       <code>27A223DDFC3A8F47</code> to HEAD <code>9fd580c8</code> body <code>744BC4443891ED10</code>.       READY took 122 seconds and the complete three-minute-rehearsal,       transfer, install, reboot, recovery, and restore wrapper took 589.487       seconds. Lost read-only preflight and postboot replies were reconciled by       bounded exact retries. USB confirmed the target/hardware/body and       bootloader success result, and authenticated LoRa readback confirmed the       final 22 dBm restoration. Sanitized log:       <code>/home/mikec/hwtest/runs/rak3401-02040403-head-vzWOXVxT/qualification-redacted.log</code>.</li> <li>[ ] Add exact RF packet sent/confirmed counters to the device/host telemetry.       The qualified run records two payload blocks, all seeder reads, command       retries, and final success, but those are not equivalent to LoRa packet       counts and must not be presented as such.</li> <li>[ ] Repeat at each supported bandwidth and record 0-hop, 1-hop, and 2-hop       estimates from measured airtime rather than extrapolating only by file size.</li> </ul>"},{"location":"hardware_validation_checklist/#rak4631-reduced-profiles","title":"RAK4631 reduced profiles","text":"<ul> <li>[x] Serialized VM contracts distinguish the three application identities:       the plain and Serial2 reduced profiles retain the combined WisBlock GPS       provider and all four INA voltage/current drivers; the explicit legacy       Serial1 profile retains the INA drivers and omits GPS. This is build       evidence only, not physical peripheral qualification.</li> <li>[ ] On the plain reduced profile, detect and read RAK12500 I2C GPS, a       RAK12501/L76K UART GPS in a separate run, the SSD1306 OLED, a supported       autodiscovered RTC, and representative INA telemetry. Verify GPS sleep and       repeated discovery never lower the shared WB_IO2/3V3_S rail.</li> <li>[ ] With a UART RAK12501 installed and detected, confirm the Serial2 bridge       and GPS remain usable together. Select Serial1 and try to enable the       bridge with the GPS preference both on and off; verify each attempt is       refused before the bridge starts and does not change GPS transport,       acquisition, hold, or cached-fix state. The shared WB_IO2/3V3_S rail must       remain high and GPS must remain usable after each refusal.</li> <li>[ ] With only an I2C RAK12500 installed, and again with neither GPS installed,       select Serial1 on the merged image and confirm bridge enable is refused       without changing saved UART/runtime state. Silence or an I2C-only detection       must not defeat the fail-closed RAK12501 reservation. Confirm Serial2 starts       and I2C GPS telemetry remains usable.</li> <li>[ ] Exercise RAK12500 at <code>0x42</code> and INA3221 at <code>0x43</code> together with the       address-matched build. Separately place INA3221 alone at the configured       <code>0x42</code> and prove the identity guard prevents u-blox configuration writes.</li> <li>[ ] With a logic analyzer, hold SDA low and then SCL low before sensor       discovery. Confirm the validated board pins receive at most nine       open-drain recovery clocks and a STOP only after SCL rises; the firmware       must skip discovery if either line remains low. Repeat on ProMicro's       remapped SDA 8/SCL 7 and verify the user-button pin is never driven.</li> <li>[ ] Record the remaining core limitation: the pinned Adafruit nRF52 Wire       implementation has no transaction timeout. This preflight cannot protect       display/RTC calls made earlier in boot or interrupt a peripheral that       wedges after a transaction begins. Qualify those cases with a hard power       cut/watchdog fixture before claiming bus-hang recovery.</li> <li>[ ] Confirm the explicit legacy Serial1 image exposes neither UART RAK12501       nor I2C RAK12500. Record this as a combined-provider build limitation, not       an assertion that RAK12500 electrically conflicts with the UART.</li> </ul>"},{"location":"hardware_validation_checklist/#heltec-t096","title":"Heltec T096","text":"<ul> <li>[x] Stable USB serial <code>651F8E496197F882</code> distinguishes the application       (<code>239A:8029</code>) from the OTAFIX serial-DFU interface. Every flash followed       that identity across the host-assigned <code>COM9 -&gt; COM6 -&gt; COM9</code> transition;       the simultaneously connected MeshPocket on <code>COM20</code> was never selected.</li> <li>[x] Baseline bootloader <code>0.11.0-OTAFIX2.4.3</code> was installed at this checkpoint. The restored Repeater       reports application body hash <code>3B6D1A729C087243</code>, target <code>98411AC6</code>, apply       ABI 3, codec mask <code>0x5</code>, and stage address <code>0xED000</code>. The application ZIP       is 708,216 bytes with SHA-256       <code>abb00560cc5618ae155bf10252e9261127416a7a91b5f6565837384f0dec2390</code>.</li> <li>[x] A 48,229-byte in-place delta with SHA-256       <code>988bd2385e9c995d0ae04effb6bb5cd614227c7c764590d82bd1943da2f18e4d</code>       transferred over LoRa in 47/47 blocks from the MeshPocket seeder and       applied successfully. The first application boot reported bootloader       result <code>B8</code>; the running body hash matched the candidate exactly. No chat       message was sent for this transfer.</li> <li>[x] The generic delayed AGC/watchdog arming fix passes warm-reboot hardware       checks on both the T096 and MeshPocket. The restored T096 retained AGC       interval 8 and, after 215 seconds, was in RX with 100 packets received,       28 sent, zero core errors, and <code>err_flags=0</code>. The Pocket's quiet-channel       liveness recovery set only the expected radio-watchdog bit; temporarily       matching the USA channel then received 14 packets with zero receive       errors before its saved <code>869.618/62.5/SF8/CR5</code> profile was restored. At       498 seconds the T096 had one CAD-busy timeout after 37 busy-channel       samples, then returned to RX with no queue, watchdog, or start-RX fault.</li> <li>[x] Exact Full Companion ZIP SHA-256       <code>ee92856e5bfb7877b0d8bff6d6a5873d8037fc178ddb151202a9e6a6d9d59e73</code>       installed by serial DFU and passed the reversible dual-CDC test. Logging       off exposed only interface <code>00</code>; <code>set usb.logging on reboot</code> added       interface <code>02</code> as <code>COM21</code>. Opening <code>02</code> emitted both portable identity       lines, 980 captured bytes were entirely printable, and host input produced       no echo or command reply while Binary Companion on <code>00</code> returned the exact       model, key, and radio tuple.</li> <li>[x] With interface <code>02</code> deliberately unread, 11/11 text-terminal probes stayed       between 212 and 231 ms for 44.4 seconds. A longer 100-second hold buffered       8,636 entirely printable bytes while 60/60 hard-bounded Binary Companion       reconnects passed with no timeout; the final full identity query completed       in 739 ms. Neither USB interface disconnected. Logging off plus reboot       removed <code>02</code>, read back off on <code>00</code>, and the qualified Repeater was then       restored with its original name, public key, and USA radio tuple.</li> <li>[x] The descriptor/reconnect follow-up built a 482,271-byte Full Companion DFU       ZIP with SHA-256       <code>2a5a6bd0fd26031a2c2e047af6ead8f85f0d617da238d0cd6d816f7d5c41ec6f</code>.       On the physical T096, Windows read interface <code>02</code>'s bus-reported       description as <code>MeshCore Logging</code>. Two immediate open/close cycles each       delivered the complete 80-byte two-line identity marker with no NUL or       other invalid control byte, while Binary Companion on interface <code>00</code>       retained the exact key, model, and <code>910.525/62.5/SF7/CR5</code> tuple.</li> <li>[x] The final short-write/reconnect guard built a 482,271-byte Full Companion       DFU ZIP with SHA-256       <code>bbbc3459b2c032af23c6da05e41984cb0250398b57ba56ea99166456700ace6f</code>       and EndF body hash <code>41365E4DB0FF4AE5</code>. On the physical T096, interface       <code>02</code> again reported <code>MeshCore Logging</code>; 3/3 explicit DTR sessions each       delivered one complete 80-byte marker with no NUL or invalid control byte.       With that logging endpoint held open and unread, interface <code>00</code> completed       60/60 Binary Companion reconnect queries and retained public key       <code>8e229d0a9ace9bd6f768fc1237d9e3ebca340d1ff1c6087349983a07f305903a</code>       plus the exact <code>910.525/62.5/SF7/CR5</code> tuple.</li> <li>[x] The corrected Windows flasher identifies Binary-mode Full Companion and       links the same-radio <code>MI_02</code> inventory row to <code>MI_00</code>. An intentional       selection of <code>COM21/MI_02</code> was canonicalized to <code>COM9/MI_00</code> before any       1200-baud action; the exact USB serial then followed       <code>COM9 -&gt; COM6 -&gt; COM9</code>, never touched the logging endpoint or MeshPocket,       and produced both <code>Device programmed.</code> and <code>Flash completed.</code>. The VM was       suspended only across each touch/transfer and resumed immediately. After       restoring the qualified Repeater and performing a final warm reboot, the       58-second snapshot was in RX with 28 packets received, 9 sent, zero core       errors, an empty queue, and <code>err_flags=0</code>.</li> <li>[x] Final flasher review now revalidates the selected USB identity and exact       interface immediately before both the direct 1200-baud open and its Python       fallback, and balances every successfully written terminal START with a       STOP even when the banner is lost. Windows PowerShell 5.1 and PowerShell 7       regression suites pass. A second physical restore deliberately selected       <code>COM21/MI_02</code>; it was canonicalized to <code>COM9/MI_00</code>, followed the same       <code>COM9 -&gt; COM6 -&gt; COM9</code> transition, and completed without touching the       MeshPocket. At 112 seconds the restored Repeater retained its name, OTA       body hash <code>3B6D1A729C087243</code>, USA radio tuple, and AGC interval 8; it was in       RX with 20 packets received, 6 sent, zero core errors, an empty queue, and       <code>err_flags=0</code>. The VM was running again immediately after the flash.</li> <li>[x] The T096-only message profile defines <code>UI_MESSAGE_CHANNEL_FOOTER=0</code>;       every other profile retains the default footer. The exact incoming       <code>#testing</code> message <code>T096 footer test: wrapped text should reach the screen       bottom.</code> traversed the live channel receive/display path, and the temporary       empty <code>#testing</code> channel slots on both endpoints were restored byte-for-byte.       Static profile coverage passes 2/2. No framebuffer or camera capture was       available, so the evidence is the exact live UI path plus the compiled       board-specific flag rather than a pixel photograph.</li> <li>[x] The then-final Full Companion artifact at this checkpoint,       <code>v1.17.1-t096-head-fcd1f8cc-usbtask8-fcd1f8cc</code>, was installed. Its DFU ZIP       is 487,231 bytes with SHA-256       <code>CD267952F420294DF21CA96E3AA6D924C6EF7467C31C8D69B46F31E6719A1D67</code>;       the application is 486,428 bytes with a 486,372-byte EndF body and hash       <code>2E03B1C1166D4CC0</code>. The ELF exposes strong <code>T</code> definitions for both CDC       callbacks, mount/unmount, SOF, and the CDC0-only framework flush override.</li> <li>[x] Identity-gated BLE application DFU passed through the bonded address       <code>CF:A8:18:36:DE:8B</code>: encrypted application handoff from       <code>MeshCore-8E229D0A</code>, same-address <code>T096_DFU</code> Legacy service, and DIS model       <code>HT-n5262G</code> all matched. The target confirmed 486,428/486,428 bytes in       565.986 seconds at 859 payload B/s, validated, activated, and initiated       the expected disconnect; end-to-end time was 603.967 seconds. USB serial,       version, board, public key, radio tuple, EndF hash, and bootloader apply       ABI 3/codecs <code>0x5</code> returned exactly, and a fresh active scan observed the       application name again at the same address.</li> <li>[x] The real host <code>motatool</code> opened <code>COM9</code>, survived the intentional CDC       session-settle purge, attached an empty folder with <code>COUNT -&gt; 0</code> and       <code>OK folder attached</code>, then detached it and restored Binary mode. This       test sent no mesh messages. Three primary-port close/reopen cycles after       deliberately abandoned terminal output exposed zero stale bytes and each       returned a clean banner. Five logging-port reopen sessions each began       with the exact 80-byte identity marker and contained no NUL or invalid       control byte.</li> <li>[x] With both USB outputs deliberately unread for 65 seconds after a 10,000-byte       terminal input burst, the primary accumulated 16,886 printable bytes and       CDC1 accumulated 3,735 printable bytes beginning with its exact marker.       <code>ver</code> and Binary Companion remained responsive. A subsequent warm reboot       removed USB for 2.209 seconds, returned both interfaces in 2.409 seconds,       and CDC1 again emitted the exact marker. At 65 seconds the fresh boot had       <code>err_flags=0</code>, an empty outbound queue, 9 received floods, and zero CRC       errors. A Windows host-side composite       restart was attempted but denied by the non-elevated PnP API, so the       distinct host-driven BUS_RESET case remains a physical/privileged check;       it is not inferred from the warm-reboot result.</li> <li>[x] After the operator physically removed and restored T096 power (the off       interval was not measured), stable serial <code>651F8E496197F882</code> returned as       primary <code>MI_00</code>/<code>COM9</code> and logging <code>MI_02</code>/<code>COM21</code>. The cold terminal       reported exact version       <code>v1.17.1-t096-head-fcd1f8cc-usbtask8-fcd1f8cc</code>, Heltec T096 identity,       public key, USA radio tuple, BLE name, dedicated-CDC logging state, EndF       body hash <code>2E03B1C1166D4CC0</code>, and bootloader apply ABI 3/codecs <code>0x5</code> with       stage ceiling <code>0xD4000</code>; mOTA remained source-only with no folder attached,       and STOP restored Binary mode. CDC1's first read was the exact 80-byte       identity marker with no NUL. At 150 seconds, Binary stats reported 4,224       mV, <code>err_flags=0</code>, an empty outbound queue, 47 packets received, zero       packets sent, and zero TX airtime. A second core checkpoint advanced       monotonically to 315 seconds with 4,220 mV, <code>err_flags=0</code>, and an empty       queue, providing no evidence of a watchdog reboot. A fresh active BLE       scan observed <code>MeshCore-8E229D0A</code> at the same <code>CF:A8:18:36:DE:8B</code>       address; BlueZ still       reported paired, bonded, and trusted. No mesh message was sent. This proves       cold persistence, but not the distinct host-only USB <code>BUS_RESET</code> path.</li> <li>[x] The display auto-off wake failure was traced to the shared ST7735 power       lifecycle: <code>turnOff()</code> released SCK/MOSI as inputs, but the nRF52       <code>SPIClass::begin()</code> wake path was a no-op while the SPI object still       considered itself initialized. The shared driver now restores the bus-pin       directions and nRF52 high-drive configuration explicitly, waits through       reset release, and primes the retained frame after <code>DISPON</code>. Static wake       ordering and the T096 footer profile pass, and the exact Full Companion artifact       <code>v1.17.1-t096-head-fcd1f8cc-wake1-fcd1f8cc</code> compiled at 486,348 bytes.       Its 487,231-byte serial-DFU ZIP has SHA-256       <code>A091F6DC458177BB26B8384B2AAAC0A9FD550322179F96062CCD3F0F5BB0E585</code>;       the 486,428-byte OTA image reports a 486,372-byte EndF body with hash       <code>E9AB2A36E9F7091F</code>. Identity-gated <code>meshfirmware</code> selected <code>COM21/MI_02</code>,       canonicalized it to <code>COM9/MI_00</code>, followed <code>COM9 -&gt; COM6 -&gt; COM9</code>, and       emitted both <code>Device programmed.</code> and <code>Flash completed.</code> without touching       the MeshPocket. The VM was suspended only across touch/transfer and was       running again as soon as exact serial <code>651F8E496197F882</code> returned. Live       readback then matched the public key, Heltec T096 board, USA       <code>910.525/62.5/SF7/CR5</code> tuple, ABI 3/codecs <code>0x5</code>/stage <code>0xD4000</code>, and exact       80-byte CDC1 marker; core checkpoints advanced through 369 seconds with       <code>err_flags=0</code>, an empty queue, and zero TX. Follow-up physical testing       confirmed auto-off wake and single-click page navigation. Double-click,       triple-click, long-press, and simultaneous-button gestures remain deferred.</li> <li>[x] A signed bootloader mOTA package for OTAFIX HIL candidate <code>0x02040401</code>       transferred over LoRa in 40/40 blocks, passed the privileged-install gate,       installed with the watchdog enabled, and rebooted with unchanged node and       radio settings. The installed bootloader CRC changed to the package's       expected <code>381BAE6E</code>; the temporary HIL signer was removed afterwards.</li> <li>[x] A 486,796-byte Full Companion application completed bonded Legacy BLE DFU       at approximately 5.7-6.2 kbit/s payload throughput, then returned with the       same identity and USA radio tuple. The later CDC0 first-open fix preserved       immediate <code>APP_START</code> input across the eight-millisecond session gate:       first client after reboot passed with CDC1 logging active, followed by       10/10 immediate COM9 close/reopen queries. CDC1 continued to emit its exact       identity marker and printable packet/debug logs.</li> </ul>"},{"location":"hardware_validation_checklist/#heltec-meshtower-v2-with-sd","title":"Heltec MeshTower V2 with SD","text":"<ul> <li>[x] Stable serial <code>9352162A72082314</code> and physical downstream-hub path       <code>1-1.2</code> port 4 identify this board across application and bootloader       descriptors; no other attached nRF52 endpoint was selected. The older       2.4.3 bootloader's UF2/serial failure was rejected rather than treated as       a successful flash.</li> <li>[x] Exact <code>1.17.1.5-halo-keymind-cascade-marathon-hwtest-e26d48e4</code> SD       Repeater boots with hardware ID <code>Heltec_tower_v2</code>, target <code>0A9DBBF0</code>,       body hash <code>E9282D470AAC348B</code>, and USA radio       <code>910.525/62.5/SF7/CR5</code>. <code>ota self</code> reports SD apply ABI 3 with codec mask       <code>0x5</code>; <code>ota bootloader</code> reports board <code>239A0071</code>, target <code>1150F50E</code>, name       <code>TOWER_V2_OTA</code>, and capability byte <code>09</code>.</li> <li>[x] A post-Pi-recovery identity-gated serial audit reconfirmed the exact       Tower V2 model, Repeater role, build, <code>910.525/62.5/SF7/CR5</code>, target       <code>0A9DBBF0</code>, body <code>E9282D47</code>, SD ABI 3/codecs <code>0x5</code>, and installed       bootloader identity/capability <code>239A0071</code>/<code>09</code>. The card reported       959.6 MiB free and no active download. This profile exposes the local       text console but deliberately has no runtime <code>usb.logging</code> setting; the       unknown-setting reply is a capability result, not a transport failure.</li> <li>[x] Card detection and destructive maintenance pass. Normal format took       3,927 ms; an immediate repeat was rejected by the five-minute cooldown;       forced format took 3,933 ms; and raw erase plus format took 3,947 ms.       The card remounted empty with 16.0 KiB used and 959.6 MiB free, and both       completion ages were recorded. Automatic archive capture was then       disabled deterministically, leaving only <code>/mota/cache.off</code>.</li> <li>[ ] SD card detection, staging, hash validation, apply, cleanup, and recovery       from missing/corrupt media pass.</li> <li>[ ] Multi-page application and bootloader update paths pass across a cold boot.</li> <li>[ ] LoRa OTA receive/apply reports the expected target ID and installed version.</li> </ul>"},{"location":"hardware_validation_checklist/#heltec-v4","title":"Heltec V4","text":"<ul> <li>[x] Exact V4 hardware variant is reported (<code>Heltec V4.3 OLED</code>); OLED/TFT       variants are not merged.</li> <li>[x] Full Companion boots with USB logging off and Binary Companion selected.       The text terminal independently reports the complete build string;       protocol <code>ver</code> has a shorter fixed-width version field.</li> <li>[ ] USB logging changes take effect immediately on this single-TTY ESP32       profile, require no reboot, and return to Binary Companion only through       the explicit terminal-stop mode change.</li> <li>[x] Bluetooth pairing and Companion protocol operations pass. Qualification       required removing the Pi's stale pre-flash bond, pairing through a BlueZ       <code>KeyboardOnly</code> agent with the current displayed/reported PIN, then       reconnecting; BLE <code>infos</code> and <code>ver</code> returned the exact V4.3 OLED identity.</li> <li>[x] Saved Wi-Fi connects to <code>SlowFi</code>, returns at <code>192.168.1.51</code> after the test       host reboot, reports Wi-Fi power save <code>min</code>, and remains governed by the       configured-network behavior rather than the unconfigured 30-minute       shutdown policy.</li> <li>[x] TCP Binary Companion (<code>5000</code>), Wi-Fi OTA (<code>5001</code>), and text CLI (<code>5002</code>)       are each tested and cannot be confused with one another. Port 5000       returned the exact Companion identity; 5002 returned the full terminal,       version, Wi-Fi, logging, RXPS, and memory state; and a real <code>motatool       serve --tcp 192.168.1.51:5001 -v</code> session received <code>COUNT -&gt; 0</code> from an       intentionally empty folder. Disconnect then restored <code>folder:not       connected</code> while the 5001 listener stayed active.</li> <li>[ ] For a shared Full-Companion controller/seeder, bind the source identity       to the exact public key already read from Binary Companion port 5000.       Do not require <code>get public.key</code> from text port 5002: the hardware-tested       V4 Full CLI rejects that command. Port 5002 must still prove the local       TempRadio state/tuple, while keyed on-air destination replies prove the       physical LoRa handoff.</li> <li>[ ] V4 seeds direct and routed LoRa OTA; TempRadio preflight, apply, and       automatic normal-radio restoration all pass.</li> </ul>"},{"location":"hardware_validation_checklist/#seeed-sensecap-indicator-lora","title":"Seeed SenseCAP Indicator LoRa","text":"<ul> <li>[x] Flashing selects the ESP32-S3 CH340 endpoint, never the Indicator RP2040       ACM endpoint; esptool MAC probing succeeds before erase. The qualifying       merged write used 115200 baud and completed with flash hash verification.</li> <li>[x] A fresh merged install completes SPIFFS initialization and reports the       intended Full Companion version/role and <code>Seeed SenseCAP Indicator</code>       hardware identity. The exact qualifying artifact was       <code>SenseCapIndicator-LoRa_companion_radio_full-1.17.1.5-halo-keymind-cascade-marathon-e26d48e4-merged.bin</code>,       2,070,152 bytes, SHA-256       <code>df08b770313ca8776436456525681cf286cd9b5b40e05e7cf55f21ef097f338a</code>;       its ELF, map, manifest, and partition signature are archived beside it on       the Mercerwood Pi.</li> <li>[x] The current dark-layout Full Companion application was flashed app-only       with exact CH340/MAC/partition gates, preserving identity, Wi-Fi, and       settings. The 2,147,800-byte application has SHA-256       <code>81bebdc07b6a8349c1c975cb5a0e30c5f6019d35bcac641e5f3d4df951f7406b</code>;       esptool verified its flash hash in 134.2 seconds. USB Binary/terminal,       saved logging-off state, configured Wi-Fi, BLE, TCP ports 5000/5001/5002,       and an empty-folder Wi-Fi mOTA <code>COUNT -&gt; 0</code> exchange all pass afterward.</li> <li>[x] Keep one identity-gated CH340 descriptor open with DTR/RTS deasserted       through startup. On the valid-current-font path, the Indicator streams a       1,302,608-byte font from its RP2040 at 1 Mbps before registering the USB       terminal, so allow at least 30 seconds before the first command. A       missing/corrupt-font recovery instead runs in the background after the       interfaces start. Reopening short probes can reset the ESP32 repeatedly       and create a false UART-hang diagnosis; the controlled run returned       <code>ver</code> and <code>board</code> after the same apparent-silence condition.</li> <li>[x] Automatic font recovery starts from a physically corrupt RP asset. The       setup deliberately installed 64 all-zero bytes, CRC32 <code>758d6336</code>, in       place of <code>/meshcore/ui-font.vlw</code>; the ESP32 rejected that asset and kept       its built-in fallback font while recovery ran.</li> <li>[x] Every new HTTPS recovery attempt waits for a fresh SNTP callback and a       signed epoch at or after the compiled asset publication time before it       opens TLS. The forced-resume run observed fresh syncs in 3,700, 400, and       699 ms across three outer attempts, including two failed TLS handshakes;       the final normal run synced in 1,999 ms and only then logged the first       <code>api.github.com</code> connection. A retained merely plausible clock is not       accepted. CA validation and the compiled asset SHA-256 remain mandatory.</li> <li>[x] The release-source normal path downloaded all 1,302,608 bytes into PSRAM       in 13,205 ms, closed TLS, verified SHA-256       <code>61bce9662db314054e7bcfaa26147a28ad7b500b51baac4cae1caacce90b7421</code>,       staged receiver-paced 512-byte <code>MCFONT STAGEV2</code> chunks in 36,676 ms,       committed, and verified RP CRC32 <code>19f80d64</code> at 76.7 seconds from reset.       An independent <code>MCFONT GET</code> over RP USB then returned exactly 1,302,608       bytes with the same CRC and SHA in 15.273 seconds. The exact installed       application is       <code>SenseCapIndicator-LoRa_companion_radio_full-1.17.1.5-halo-keymind-cascade-marathon-font-recovery-e26d48e4.bin</code>;       its log is       <code>/home/mikec/hwtest/runs/indicator-release-recovery-lUZEmBHL/esp-serial.log</code>       on Mercerwood. The current RP service reports protocol 2 and completed       STAGEV2 accounting; its installed flash was not independently read back,       so no RP artifact hash is inferred from the archived candidates.</li> <li>[x] Strict Range recovery passed a forced hardware interruption. Exact test       application SHA-256       <code>cfd5aec497cb9919f87c0f82f5deaf8614d411582a709cea1c36275529c0bb68</code>       closed the initial response at verified offset 1,048,576. Its first       same-offset resume handshake failed; bounded retry 2/2 then accepted only       the remaining 254,032-byte <code>206</code> response under the original strong       ETag/<code>If-Range</code>, retained the same PSRAM buffer and SHA stream, completed       the download in 49,422 ms, staged in 36,702 ms, committed, and passed an       independent exact USB readback. The full log is       <code>/home/mikec/hwtest/runs/indicator-range-v2-xbKr09wI/esp-serial.log</code>.       An earlier forced 512 KiB run proved one correct resume at 524,288 but       later exhausted its second reconnect on a TLS failure; it is retained as       regression-trigger evidence rather than an end-to-end pass.</li> <li>[x] Rebooting the exact release-source application with the current valid       font performed no NTP query, TLS connection, or GitHub request. The       valid-font boot log is       <code>/home/mikec/hwtest/runs/indicator-release-valid-a84vd7Du/esp-serial.log</code>.</li> <li>[x] The post-qualification shared SNTP-coordinator source compiles in the       real Arduino-ESP32 2.x LoRa USB/WiFi profile (1,587,965 bytes, 60.6% of       its OTA slot), the dynamically generated ESP-NOW Full profile (2,093,465       bytes, 79.9%), and the matching RP2040 transactional service. After the       VM independently reported <code>NTPSynchronized=yes</code>, an       end-to-end request to the immutable GitHub asset returned HTTP 200,       exactly 1,302,608 bytes, and SHA-256       <code>61bce9662db314054e7bcfaa26147a28ad7b500b51baac4cae1caacce90b7421</code>.       A live <code>524288-1302607</code> continuation then returned HTTP 206, the same       strong ETag, an exact 778,320-byte <code>Content-Length</code>, and a byte-for-byte       hash match against the checked-in font tail; the pinned Sectigo E46 root       independently verified the current <code>api.github.com</code> chain.       The same coordinator also compiles in the real       <code>heltec_v4_repeater_observer_mqtt</code> profile: its 1,852,392-byte EndF image       has SHA-256       <code>fe8352654437f67488b412e1c1a690f2874e836abb5a5d209654bd030c713d7e</code>.       MQTT's three process-global <code>configTime()</code> paths are lease-protected,       and a busy asynchronous refresh uses a wrap-safe five-second retry       deadline instead of overwriting another service's SNTP callback or       recording a false successful refresh.       The exact final LoRa Full artifact gate then passed 11/11 linked-image       markers, including both <code>requesting fresh NTP time before download</code> and       the subsequent TLS-open marker. Its 2,146,312-byte application has       SHA-256       <code>f557088a5ef3f49f74ab01ca95fefc76911cca4073f01b77cee4882284fc5110</code>       and 475,128 bytes remain in its app slot; the matching 2,211,848-byte DIO       merged image has SHA-256       <code>52a4559774384b54dd7fb81da82c791e2c9564991fcf016bcad3b6ad756c1fb2</code>.       The exact ELF, map, capability manifest, and partition signature are       archived together under <code>/tmp/indicator-full-daily-ntp.WQ6ozM</code> on       the VM pending transfer to the hardware-run archive.       The ESP-NOW Full sibling passed the same 11/11 gate with a 2,093,928-byte       application (527,512 bytes free), SHA-256       <code>fcd9e0e8a37551a845a234fc10eaa4a9f420d54172039b9241f4696a12d4c65f</code>,       and matching DIO merged-image SHA-256       <code>f3637c23f58204f5b752b68a1bd494601cb68bee9c27b664832d40abd03cc186</code>;       its complete archive is <code>/tmp/indicator-espnow-full-ntp-gate.YN9T8l</code>.       Repeat the negative UDP/123-blocked hardware gate on this exact final       source before treating the coordinator refinement as hardware-qualified.</li> <li>[ ] Full Wi-Fi SSID, setup address, and related status text wrap without       clipping on the physical display. The new dark palette and exclusive       lower pairing block are installed; a fresh bond removal held the random       PIN request on-screen for 30 seconds and then an immediate second attempt       paired, trusted, and returned the exact Indicator identity over BLE. A       human physical-readability confirmation is still required; the automated       geometry tests prove the PIN block is centered at four-fifths height and       cannot overlap IP, inbox, or status text.</li> <li>[ ] Boot the exact current LoRa and ESP-NOW Full artifacts in both saved       secondary-transport modes and capture the <code>Indicator render</code> line. Require       LoRa + WiFi, LoRa + BLE, and ESP-NOW + infrastructure WiFi to retain       480x480, and ESP-NOW + BLE to select 320x320 scaled to the panel. A logged       emergency 320x320 fallback keeps the unit recoverable but does not pass a       native-480 gate.</li> <li>[ ] For all four boots, record free heap and largest internal block before       interfaces and after the selected interface is usable. In WiFi mode prove       BLE never starts; in BLE mode prove infrastructure WiFi, WebConfig, MQTT,       and TCP never start. Keep the primary LoRa or ESP-NOW radio exchanging       traffic throughout. For both BLE modes pair/encrypt, negotiate MTU,       subscribe, exchange repeated Companion requests, disconnect/reconnect,       and repeat after bond removal; exercise network/TCP traffic in both WiFi       modes and record the lowest heap/largest-block values.</li> <li>[x] With no saved SSID, setup Wi-Fi powers down after the absolute 30-minute       window even if queried or used.</li> <li>[x] A software reboot starts a fresh unconfigured setup window.</li> <li>[x] With a saved SSID, Wi-Fi reconnects to <code>SlowFi</code>, reports minimum modem       power save, and remains governed by normal configured-network behavior.</li> <li>[x] Bluetooth Companion pairing and protocol operations pass after saving a       deterministic qualification PIN, removing any stale host bond, pairing,       disconnecting the <code>bluetoothctl</code> client, and reconnecting with meshcli.       Binary <code>infos</code>/<code>ver</code> returned the exact Indicator identity and USA tuple.       A second connection after the USB-open reboot and logging-mode exercise       also returned the exact build; one initial scanner miss was resolved by       an explicit BlueZ discovery pass and was not a firmware advertisement       failure.</li> <li>[x] Wi-Fi/TCP Companion, CLI, and OTA endpoints pass at <code>192.168.1.54</code>:       port 5000 returned Binary Companion identity, port 5002 returned the full       text version/status, and motatool completed a port-5001 <code>COUNT -&gt; 0</code>       protocol exchange against an empty served folder.</li> <li>[x] Fresh Full starts with USB logging off. On this single-TTY ESP32 profile,       logging on/off applies and persists without a descriptor-changing reboot;       the same held-open ASCII terminal reported off -&gt; on -&gt; off correctly,       emitted live Wi-Fi/radio diagnostics while on, then accepted the explicit       terminal-stop token and returned a valid 85-byte Binary Companion device       info frame for <code>Seeed SenseCAP Indicator</code> without rebooting. Companion       remained independently usable over Bluetooth and Wi-Fi.</li> <li>[x] Normal-radio LoRa transmit and receive pass. At the installed 22 dBm,       a co-located discovery request overloaded the nearby receivers and found       zero nodes; temporarily reducing only the Indicator to 0 dBm produced       three repeater replies at RSSI -29 to -59 dBm, proving both directions.       The saved 22 dBm value was restored and independently read back after the       test; this near-field result is a lab-power gate, not a firmware failure.</li> <li>[ ] TempRadio sanity check, OTA seeding, and normal-radio restoration pass.</li> </ul>"},{"location":"hardware_validation_checklist/#cross-radio-lora-ota-acceptance","title":"Cross-radio LoRa OTA acceptance","text":"<ul> <li>[ ] Run a three-minute reachability preflight before staging or changing any       repeater radio settings.</li> <li>[ ] Test direct, fully controlled multi-hop, passive TempRadio hop, and mixed       controlled/passive paths independently.</li> <li>[ ] Record bytes, LoRa packets sent, packets confirmed, retries, useful       throughput, total elapsed time, and per-phase elapsed time.</li> <li>[ ] Confirm every controlled intermediate returns to its saved radio tuple.</li> <li>[ ] Verify target application and bootloader hashes after apply, not merely the       OTA tool's final status line.</li> <li>[ ] Exercise interruption/retry and confirm incomplete data cannot be approved       or booted.</li> </ul>"},{"location":"host_cli_service/","title":"LoRa CLI Host Service","text":"<p>The repeater <code>host &lt;text&gt;</code> command lets an authenticated LoRa administrator request a small, explicitly allowed operation from a USB-connected computer. The included Raspberry Pi endpoint supports these exact requests:</p> <pre><code>cmd host help\ncmd host cpu-temp\ncmd host hostname\ncmd host uptime\ncmd host load\ncmd host memory\ncmd host disk-free\ncmd host clock status\ncmd host clock sync\ncmd host clock set &lt;unix_epoch&gt;\ncmd host network restart\ncmd host reboot\ncmd host action status &lt;operation_id&gt;\ncmd host run &lt;alias&gt; [arguments]\n</code></pre> <p>The first seven actions after <code>help</code> are read-only. Clock changes, network restart, and reboot are opt-in actions and are disabled unless explicitly enabled. Text such as <code>reboot now</code>, <code>cpu-temp; reboot</code>, and embedded newlines is not a command: the endpoint accepts only an exact allowlist match.</p> <p>The bridge is included in normal repeater firmware except on Wio-E5. Its specialized RS232 bridge image omits the host service because the combined application exceeds the fixed 240 KiB partition; use the normal Wio-E5 repeater image when the USB/MQTT host service is needed.</p>"},{"location":"host_cli_service/#run-alongside-meshcoretomqtt","title":"Run alongside meshcoretomqtt","text":"<p><code>meshcoretomqtt</code> must remain the only process that opens the repeater USB serial port. The endpoint communicates with it through the same MQTT broker, which can be local to the Raspberry Pi:</p> <pre><code>LoRa -&gt; repeater -&gt; USB -&gt; meshcoretomqtt -&gt; MQTT -&gt; host endpoint\nLoRa &lt;- repeater &lt;- USB &lt;- meshcoretomqtt &lt;- MQTT &lt;- host endpoint\n</code></pre> <p>Clock-recovery deployments must run the loopback broker, <code>meshcoretomqtt</code>, and endpoint on the same Pi. A wrong Pi clock can prevent TLS validation against a remote broker, while split host clocks can reject the signed live claim before the correction arrives. Remote brokers remain suitable for ordinary commands when the connection and both clocks are already healthy.</p> <p>Launch <code>meshcoretomqtt</code> with its existing arguments plus <code>--debug</code>; its current debug-topic parser needs that flag to publish the repeater request record. Do not open the serial TTY from the host endpoint too.</p> <p>This feature does not compare the repeater wall clock with the Pi clock. Minutes of drift, an unset repeater clock, and later clock corrections are safe: request freshness comes from a live one-time challenge. The normal <code>meshcoretomqtt</code> <code>sync_time</code> setting may remain enabled for its other uses, but host-command authorization does not depend on it.</p> <p>Generate a dedicated service key using the Python environment installed by <code>meshcoretomqtt</code>:</p> <pre><code>sudo /opt/mctomqtt/venv/bin/python3 host_cli_service.py \\\n  --generate-key /etc/mctomqtt/host-cli-key.json\nsudo chown mctomqtt:mctomqtt /etc/mctomqtt/host-cli-key.json\nsudo chmod 600 /etc/mctomqtt/host-cli-key.json\n</code></pre> <p>Add the printed public key to the existing <code>meshcoretomqtt</code> configuration:</p> <pre><code>[remote_serial]\nenabled = true\nallowed_companions = [\n  \"SERVICE_PUBLIC_KEY_PRINTED_ABOVE\"\n]\nnonce_ttl = 120\ncommand_timeout = 10\n</code></pre> <p>Restart <code>meshcoretomqtt</code>, then run the endpoint. Replace <code>USA</code> with the exact three-character IATA namespace configured in the broker and supply the repeater's complete 64-character public key:</p> <pre><code>sudo -u mctomqtt /opt/mctomqtt/venv/bin/python3 host_cli_service.py \\\n  --broker 127.0.0.1 \\\n  --iata USA \\\n  --repeater-key REPEATER_PUBLIC_KEY \\\n  --service-key /etc/mctomqtt/host-cli-key.json\n</code></pre> <p>Add <code>--username NAME --password-file FILE</code> for broker authentication. Add <code>--tls</code>, and optionally <code>--ca-cert FILE</code>, for TLS. Custom installations can use <code>--request-topic</code> and <code>--command-topic</code> to match their broker namespace. The endpoint source and its systemd/configuration details are in <code>examples/host_cli_service</code>.</p>"},{"location":"host_cli_service/#allowlisted-programs-and-arguments","title":"Allowlisted programs and arguments","text":"<p>Add <code>--programs-file FILE</code> to expose locally selected programs as <code>host run &lt;alias&gt; [arguments]</code>. The example JSON file fixes each executable, fixed leading arguments, maximum 1-5 second runtime, and the exact remote argument schema. For example:</p> <pre><code>cmd host run fan on 15\n</code></pre> <p>The example maps that request to the fixed process argument vector:</p> <pre><code>/usr/local/bin/mesh-fan-control --source lora on 15\n</code></pre> <p>The supported argument rules are an explicit non-option <code>choice</code>, a bounded nonnegative <code>integer</code>, or a short <code>token</code> using a restricted ASCII character set. Alias lookup and every argument validation happen before process creation. Execution uses an absolute configured path, no stdin, <code>shell=False</code>, a minimal environment, and <code>/</code> as its working directory. Extra arguments, leading-option injection, shell syntax, control characters, and invalid quoting are rejected. The allowlist file and executable must not be group- or world-writable.</p> <p>Copy and edit <code>programs.example.json</code>, then give the service account only the operating-system permissions needed by those trusted programs.</p>"},{"location":"host_cli_service/#opt-in-network-and-reboot-recovery","title":"Opt-in network and reboot recovery","text":"<p>These actions use their own socket-activated root broker, independently of the clock-control broker. Installing or enabling clock control does not grant host recovery actions. Install the following as root-owned files:</p> <pre><code>sudo install -o root -g root -m 0755 meshcore_host_actions.py \\\n  /usr/local/sbin/meshcore-host-actions\nsudo install -o root -g root -m 0644 meshcore-host-actions.socket \\\n  /etc/systemd/system/meshcore-host-actions.socket\nsudo install -o root -g root -m 0644 meshcore-host-actions.service \\\n  /etc/systemd/system/meshcore-host-actions.service\nsudo install -o root -g root -m 0644 meshcore-networkmanager-restart.service \\\n  /etc/systemd/system/meshcore-networkmanager-restart.service\nsudo install -o root -g root -m 0644 meshcore-host-reboot.timer \\\n  /etc/systemd/system/meshcore-host-reboot.timer\nsudo install -o root -g root -m 0644 meshcore-host-reboot.service \\\n  /etc/systemd/system/meshcore-host-reboot.service\n</code></pre> <p>The root-owned broker policy enables nothing by default. Create a systemd drop-in and select <code>network-restart</code>, <code>reboot</code>, or both as an exact comma-separated list:</p> <pre><code>sudo systemctl edit meshcore-host-actions.service\n</code></pre> <pre><code>[Service]\nEnvironment=MESHCORE_HOST_ACTIONS=network-restart,reboot\n</code></pre> <p>Reload systemd and enable only the broker socket:</p> <pre><code>sudo systemctl daemon-reload\nsudo systemctl enable --now meshcore-host-actions.socket\n</code></pre> <p>After changing the policy on an already active installation, restart <code>meshcore-host-actions.service</code> so the broker reads the new value.</p> <p>Finally add <code>--allow-network-restart</code>, <code>--allow-reboot</code>, or both to the unprivileged endpoint. An action must pass both gates: the endpoint flag and the root-owned broker policy. The endpoint never invokes <code>sudo</code>; remove legacy <code>wifi-restart</code> program aliases and host-action sudoers entries because sudo aliases are not a fallback for this hardened service. Use the exact <code>host network restart</code> action instead.</p> <p>Systemd creates <code>/run/meshcore-host-actions.sock</code> as <code>root:mctomqtt</code> mode <code>0660</code>. The root broker authenticates both the endpoint UID and primary GID with <code>SO_PEERCRED</code>, while the endpoint authenticates the root-created listener. The protocol is one bounded ASCII line. Neither the caller nor request text can choose an executable, unit, path, or argument. The broker can start only the fixed static NetworkManager restart service or the fixed reboot timer; the broker and action units have empty capability sets and systemd sandboxing. The configured <code>mctomqtt</code> UID and its effective primary GID are the delegated local trust boundary; supplementary group membership alone is rejected.</p> <p>Side effects follow a fail-closed two-phase sequence. The endpoint reserves a canonical 128-bit operation ID with <code>PREPARE</code>, publishes its reply with MQTT QoS 1, and requires <code>wait_for_publish</code> plus <code>is_published</code> confirmation before sending one <code>COMMIT</code>. It does not block the Paho network callback while waiting. No confirmation means no commit. Reboot uses a fixed approximately 10-second timer that starts only after commit. The MQTT confirmation proves acceptance by the local broker, not delivery over USB and LoRa; there is no correlated serial delivery acknowledgement, so the physical reply is best effort.</p> <p><code>network restart</code> deliberately drops Wi-Fi and Tailscale management while NetworkManager restarts. Use a loopback MQTT broker and keep the broker, <code>meshcoretomqtt</code>, host endpoint, and USB device services independent of NetworkManager: they must not have <code>Requires=</code>, <code>BindsTo=</code>, or ordering dependencies on it. This preserves the local reply/commit path while remote management temporarily disappears.</p> <p>The operation ID is derived from the authenticated repeater key, request ID, and nonce. The reply displays it, and its state can be queried later:</p> <pre><code>cmd host action status 0123456789ABCDEF0123456789ABCDEF\n</code></pre> <p>The root broker retains at most 64 records for the current boot. It persists <code>prepared</code> before replying and <code>in-progress</code> before scheduling, schedules a committed operation at most once, and never automatically retries an ambiguous outcome. A broker restart converts recovered <code>in-progress</code> to <code>ambiguous</code>. Only an old uncommitted <code>prepared</code> record may be evicted; otherwise a full store rejects new work. Reusing an operation ID for a different action is rejected. <code>scheduled</code> means PID 1 accepted the fixed unit job; it does not claim that the subsequent network restart or reboot completed successfully.</p> <p>A distinct reboot is rejected while another reboot is committed or ambiguous, so a second request cannot falsely promise a fresh 10-second timer while the first timer is already running. A new reboot reservation may supersede only an older, uncommitted reboot reservation; the superseded operation can no longer be committed.</p>"},{"location":"host_cli_service/#opt-in-clock-recovery","title":"Opt-in clock recovery","text":"<p><code>clock status</code> reports the Pi epoch and NTP synchronization state without root access. To enable the exact <code>clock sync</code> and <code>clock set &lt;unix_epoch&gt;</code> actions, install <code>meshcore_clock_control.py</code> as <code>/usr/local/sbin/meshcore-clock-control</code>, owned by root and mode <code>0755</code>, then install the accompanying <code>meshcore-clock-control.socket</code> and <code>meshcore-clock-control.service</code> and static <code>meshcore-chrony-step.service</code> files in <code>/etc/systemd/system</code> as root-owned mode-<code>0644</code> files:</p> <pre><code>sudo install -o root -g root -m 0755 meshcore_clock_control.py \\\n  /usr/local/sbin/meshcore-clock-control\nsudo install -o root -g root -m 0644 meshcore-clock-control.socket \\\n  /etc/systemd/system/meshcore-clock-control.socket\nsudo install -o root -g root -m 0644 meshcore-clock-control.service \\\n  /etc/systemd/system/meshcore-clock-control.service\nsudo install -o root -g root -m 0644 meshcore-chrony-step.service \\\n  /etc/systemd/system/meshcore-chrony-step.service\nsudo systemctl daemon-reload\nsudo systemctl enable --now meshcore-clock-control.socket\n</code></pre> <p>The socket is fixed at <code>/run/meshcore-clock-control.sock</code>; systemd creates it as <code>root:mctomqtt</code> with mode <code>0660</code>. Run the endpoint as user and primary group <code>mctomqtt</code>, then add <code>--allow-clock-control</code>. The endpoint validates the socket metadata and authenticates the connected server as root with Linux <code>SO_PEERCRED</code>. The root service independently requires the peer's UID and primary GID to match <code>mctomqtt:mctomqtt</code> before it reads or executes a request. No clock-control sudo rule is used; remove old clock-helper sudoers lines when upgrading.</p> <p>Both layers require one canonical unsigned decimal argument with no sign, leading zero, whitespace, or trailing text. The accepted epoch range is 2020 through 2099. The private protocol accepts only the complete bounded ASCII lines <code>sync</code> and <code>set &lt;epoch&gt;</code>. Every child process uses a fixed absolute argv, <code>shell=False</code>, and a timeout no longer than 1.5 seconds.</p> <p><code>clock set</code> changes <code>CLOCK_REALTIME</code> without disabling NTP, then requests an NTP step. If the NTP request fails, the response honestly reports that the clock changed and which synchronization step remains incomplete. If <code>clock sync</code> enables NTP but the explicit step/restart fails, that partial outcome is also reported. When chrony is available, the root broker starts only the fixed static <code>meshcore-chrony-step.service</code>. That hardened one-shot runs <code>/usr/bin/chronyc -a makestep</code> as <code>_chrony:_chrony</code>, with no capabilities, <code>AF_UNIX</code> only, and a one-second start timeout; it can therefore reach chrony's private runtime socket without broadening the root broker. The <code>_chrony</code> account comes from the Debian/Raspberry Pi chrony package. Without chrony, the broker restarts systemd-timesyncd. Clock drift cannot authorize a captured command: the signed request still needs the repeater's live one-time claim, whose deadline is monotonic rather than wall-clock based.</p>"},{"location":"host_cli_service/#trust-and-injection-controls","title":"Trust and injection controls","text":"<p>The MQTT broker transports records but does not establish their authenticity. The endpoint checks the configured repeater identity and verifies its Ed25519 signature over the complete request ID, random nonce, and Base64URL request. It also validates framing, UTF-8, and byte limits. It does not execute that first record.</p> <p>Instead, the endpoint stores the request in memory, creates a random 64-bit challenge, and sends <code>@claim=&lt;random&gt;</code> through <code>meshcoretomqtt</code>'s signed serial channel. The repeater accepts it only from physical USB while the exact ID and nonce are pending, then signs a <code>CLAIMED</code> proof containing the challenge. Only a matching live proof lets the endpoint perform allowlist matching and execute the action. It consumes the proof before execution, so MQTT redelivery cannot execute an action twice.</p> <p>A captured request only causes a new challenge that an idle repeater refuses. A captured proof does not match a new challenge, and restarting the endpoint forgets pending challenges. Repeater/Pi clock drift therefore cannot turn an old <code>reboot</code> or <code>run</code> record into a valid action. The reply and claim commands still use short-lived JWTs; <code>meshcoretomqtt</code> checks their signer allowlist, target, expiration, signature, and separate replay nonce. Wall-clock expiry and its in-memory nonce cache are not sufficient across a backward clock jump plus restart; the firmware's live one-time claim is what protects these host actions. Keep recovery-mode <code>allowed_companions</code> limited to the dedicated service key, with the endpoint and <code>meshcoretomqtt</code> on the same Pi.</p> <p>Newlines and other reply control characters are converted to spaces and are also independently rejected by the firmware parser.</p> <p>Protect the service private key and use broker ACLs that allow it to subscribe only to the selected repeater debug topic and publish only to that repeater serial-command topic. A private key listed in <code>allowed_companions</code> is trusted to sign serial requests.</p>"},{"location":"host_cli_service/#limits","title":"Limits","text":"<ul> <li>The request is at most 155 UTF-8 bytes after <code>host</code>, or 152 bytes with the   legacy three-byte companion correlation prefix.</li> <li>The complete LoRa reply is at most 162 UTF-8 bytes.</li> <li>Only one host request can be pending per repeater.</li> <li>Only one privileged action or action-status query can be active; overlapping   work is rejected before reservation.</li> <li>The live claim must complete within 4 seconds. Allowlisted programs have a   configured 1-5 second child-process timeout. Privileged actions and status   queries share one 5-second broker/reply-confirmation deadline.</li> <li><code>host.reply</code> is accepted only through physical USB, not LoRa or Ethernet.</li> </ul> <p>Use <code>cmd get host</code> to report the bridge state and limits.</p>"},{"location":"kiss_modem_protocol/","title":"MeshCore KISS Modem Protocol","text":"<p>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.</p>"},{"location":"kiss_modem_protocol/#serial-configuration","title":"Serial Configuration","text":"<p>115200 baud, 8N1, no flow control.</p>"},{"location":"kiss_modem_protocol/#frame-format","title":"Frame Format","text":"<p>Standard KISS framing per the KA9Q/K3MC specification.</p> Byte Name Description <code>0xC0</code> FEND Frame delimiter <code>0xDB</code> FESC Escape character <code>0xDC</code> TFEND Escaped FEND (FESC + TFEND = 0xC0) <code>0xDD</code> TFESC Escaped FESC (FESC + TFESC = 0xDB) <pre><code>+------+-----------+--------------+------+\n| FEND | Type Byte | Data (escaped)| FEND |\n| 0xC0 |  1 byte   | 0-510 bytes  | 0xC0 |\n+------+-----------+--------------+------+\n</code></pre>"},{"location":"kiss_modem_protocol/#type-byte","title":"Type Byte","text":"<p>The type byte is split into two nibbles:</p> Bits Field Description 7-4 Port Port number (0 for single-port TNC) 3-0 Command Command number <p>Maximum unescaped frame size: 512 bytes.</p>"},{"location":"kiss_modem_protocol/#standard-kiss-commands","title":"Standard KISS Commands","text":""},{"location":"kiss_modem_protocol/#host-to-tnc","title":"Host to TNC","text":"Command Value Data Description Data <code>0x00</code> Raw packet Queue packet for transmission (one pending at a time) TXDELAY <code>0x01</code> Delay (1 byte) Transmitter keyup delay in 10ms units (default: 50 = 500ms) Persistence <code>0x02</code> P (1 byte) CSMA persistence parameter 0-255 (default: 63) SlotTime <code>0x03</code> Interval (1 byte) CSMA slot interval in 10ms units (default: 10 = 100ms) TXtail <code>0x04</code> Delay (1 byte) Post-TX hold time in 10ms units (default: 0) FullDuplex <code>0x05</code> Mode (1 byte) 0 = half duplex, nonzero = full duplex (default: 0) SetHardware <code>0x06</code> Sub-command + data MeshCore extensions (see below) Return <code>0xFF</code> - Exit KISS mode (no-op)"},{"location":"kiss_modem_protocol/#tnc-to-host","title":"TNC to Host","text":"Type Value Data Description Data <code>0x00</code> Raw packet Received packet from radio <p>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.</p> <p>Only one packet may be pending for radio transmission at a time. If the host sends a second Data frame before the first has completed, the modem responds with Error (0xF1) and TxBusy (0x07).</p>"},{"location":"kiss_modem_protocol/#host-output-backpressure","title":"Host Output Backpressure","text":"<p>Outbound frames are encoded into a 2-slot queue and flushed when serial output space is available; <code>loop()</code> never blocks on writes. Radio TX state advances independently of host read speed. TxDone is retained until it can be queued. If the outbound queue is full, the modem responds with Error (0xF1) and TxBusy (0x07). Hosts should read serial promptly to avoid delayed responses.</p>"},{"location":"kiss_modem_protocol/#csma-behavior","title":"CSMA Behavior","text":"<p>The TNC implements p-persistent CSMA for half-duplex operation:</p> <ol> <li>When a packet is queued, monitor carrier detect</li> <li>When the channel clears, generate a random value 0-255</li> <li>If the value is less than or equal to P (Persistence), wait TXDELAY then transmit</li> <li>Otherwise, wait SlotTime and repeat from step 1</li> </ol> <p>In full-duplex mode, CSMA is bypassed and packets transmit after TXDELAY.</p>"},{"location":"kiss_modem_protocol/#sethardware-extensions-0x06","title":"SetHardware Extensions (0x06)","text":"<p>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.</p>"},{"location":"kiss_modem_protocol/#frame-format_1","title":"Frame Format","text":"<pre><code>+------+------+-------------+--------------+------+\n| FEND | 0x06 | Sub-command | Data (escaped)| FEND |\n| 0xC0 |      |   1 byte    |   variable   | 0xC0 |\n+------+------+-------------+--------------+------+\n</code></pre>"},{"location":"kiss_modem_protocol/#request-sub-commands-host-to-tnc","title":"Request Sub-commands (Host to TNC)","text":"Sub-command Value Data GetIdentity <code>0x01</code> - GetRandom <code>0x02</code> Length (1 byte, 1-64) VerifySignature <code>0x03</code> PubKey (32) + Signature (64) + Data SignData <code>0x04</code> Data to sign EncryptData <code>0x05</code> Key (32) + Plaintext DecryptData <code>0x06</code> Key (32) + MAC (2) + Ciphertext KeyExchange <code>0x07</code> Remote PubKey (32) Hash <code>0x08</code> Data to hash SetRadio <code>0x09</code> Freq (4) + BW (4) + SF (1) + CR (1) SetTxPower <code>0x0A</code> Power dBm (1) GetRadio <code>0x0B</code> - GetTxPower <code>0x0C</code> - GetCurrentRssi <code>0x0D</code> - IsChannelBusy <code>0x0E</code> - GetAirtime <code>0x0F</code> Packet length (1) GetNoiseFloor <code>0x10</code> - GetVersion <code>0x11</code> - GetStats <code>0x12</code> - GetBattery <code>0x13</code> - GetMCUTemp <code>0x14</code> - GetSensors <code>0x15</code> Permissions (1) GetDeviceName <code>0x16</code> - Ping <code>0x17</code> - Reboot <code>0x18</code> - SetSignalReport <code>0x19</code> Enable (1): 0x00=disable, nonzero=enable GetSignalReport <code>0x1A</code> -"},{"location":"kiss_modem_protocol/#response-sub-commands-tnc-to-host","title":"Response Sub-commands (TNC to Host)","text":"<p>Response codes use the high-bit convention: <code>response = command | 0x80</code>. Generic and unsolicited responses use the <code>0xF0</code>+ range.</p> Sub-command Value Data Identity <code>0x81</code> PubKey (32) Random <code>0x82</code> Random bytes (1-64) Verify <code>0x83</code> Result (1): 0x00=invalid, 0x01=valid Signature <code>0x84</code> Signature (64) Encrypted <code>0x85</code> MAC (2) + Ciphertext Decrypted <code>0x86</code> Plaintext SharedSecret <code>0x87</code> Shared secret (32) Hash <code>0x88</code> SHA-256 hash (32) Radio <code>0x8B</code> Freq (4) + BW (4) + SF (1) + CR (1) TxPower <code>0x8C</code> Power dBm (1) CurrentRssi <code>0x8D</code> RSSI dBm (1, signed) ChannelBusy <code>0x8E</code> Result (1): 0x00=clear, 0x01=busy Airtime <code>0x8F</code> Milliseconds (4) NoiseFloor <code>0x90</code> dBm (2, signed) Version <code>0x91</code> Version (1) + Reserved (1) Stats <code>0x92</code> RX (4) + TX (4) + Errors (4) Battery <code>0x93</code> Millivolts (2) MCUTemp <code>0x94</code> Temperature (2, signed) Sensors <code>0x95</code> CayenneLPP payload DeviceName <code>0x96</code> Name (variable, UTF-8) Pong <code>0x97</code> - SignalReport <code>0x9A</code> Status (1): 0x00=disabled, 0x01=enabled OK <code>0xF0</code> - Error <code>0xF1</code> Error code (1) TxDone <code>0xF8</code> Result (1): 0x00=failed, 0x01=success RxMeta <code>0xF9</code> SNR (1) + RSSI (1)"},{"location":"kiss_modem_protocol/#error-codes","title":"Error Codes","text":"Code Value Description InvalidLength <code>0x01</code> Request data too short InvalidParam <code>0x02</code> Invalid parameter value NoCallback <code>0x03</code> Feature not available MacFailed <code>0x04</code> MAC verification failed UnknownCmd <code>0x05</code> Unknown sub-command EncryptFailed <code>0x06</code> Encryption failed TxBusy <code>0x07</code> Radio TX busy, or host output queue full"},{"location":"kiss_modem_protocol/#unsolicited-events","title":"Unsolicited Events","text":"<p>The TNC sends these SetHardware frames without a preceding request:</p> <p>TxDone (0xF8): Sent after radio transmission completes. Contains a single byte: 0x01 for success, 0x00 for failure. Delivery to the host may be delayed under serial backpressure but is not dropped.</p> <p>RxMeta (0xF9): Sent after each standard data frame (type 0x00) with SNR (1 byte, signed, value x4) and RSSI (1 byte, signed, dBm). Queued with the data frame; omitted if the data frame cannot be queued. Enabled by default; toggle with SetSignalReport. Standard KISS clients ignore this frame.</p>"},{"location":"kiss_modem_protocol/#data-formats","title":"Data Formats","text":""},{"location":"kiss_modem_protocol/#radio-parameters-setradio-radio-response","title":"Radio Parameters (SetRadio / Radio response)","text":"<p>All values little-endian.</p> Field Size Description Frequency 4 bytes Hz (e.g., 869618000) Bandwidth 4 bytes Hz (e.g., 62500) SF 1 byte Spreading factor (5-12) CR 1 byte Coding rate (5-8)"},{"location":"kiss_modem_protocol/#version-version-response","title":"Version (Version response)","text":"Field Size Description Version 1 byte Firmware version Reserved 1 byte Always 0"},{"location":"kiss_modem_protocol/#encrypted-encrypted-response","title":"Encrypted (Encrypted response)","text":"Field Size Description MAC 2 bytes HMAC-SHA256 truncated to 2 bytes Ciphertext variable AES-128 block-encrypted data with zero padding"},{"location":"kiss_modem_protocol/#airtime-airtime-response","title":"Airtime (Airtime response)","text":"<p>All values little-endian.</p> Field Size Description Airtime 4 bytes uint32_t, estimated air time in milliseconds"},{"location":"kiss_modem_protocol/#noise-floor-noisefloor-response","title":"Noise Floor (NoiseFloor response)","text":"<p>All values little-endian.</p> Field Size Description Noise floor 2 bytes int16_t, dBm (signed) <p>The modem recalibrates the noise floor every 2 seconds with an AGC reset every 30 seconds.</p>"},{"location":"kiss_modem_protocol/#stats-stats-response","title":"Stats (Stats response)","text":"<p>All values little-endian.</p> Field Size Description RX 4 bytes Packets received TX 4 bytes Packets transmitted Errors 4 bytes Receive errors"},{"location":"kiss_modem_protocol/#battery-battery-response","title":"Battery (Battery response)","text":"<p>All values little-endian.</p> Field Size Description Millivolts 2 bytes uint16_t, battery voltage in mV"},{"location":"kiss_modem_protocol/#mcu-temperature-mcutemp-response","title":"MCU Temperature (MCUTemp response)","text":"<p>All values little-endian.</p> Field Size Description Temperature 2 bytes int16_t, tenths of degC (e.g., 253 = 25.3degC) <p>Returns <code>NoCallback</code> error if the board does not support temperature readings.</p>"},{"location":"kiss_modem_protocol/#device-name-devicename-response","title":"Device Name (DeviceName response)","text":"Field Size Description Name variable UTF-8 string, no null terminator"},{"location":"kiss_modem_protocol/#reboot","title":"Reboot","text":"<p>Sends an <code>OK</code> response, flushes serial, then reboots the device. The host should expect the connection to drop.</p>"},{"location":"kiss_modem_protocol/#sensor-permissions-getsensors","title":"Sensor Permissions (GetSensors)","text":"Bit Value Description 0 <code>0x01</code> Base (battery) 1 <code>0x02</code> Location (GPS) 2 <code>0x04</code> Environment (temp, humidity, pressure) <p>Use <code>0x07</code> for all permissions.</p>"},{"location":"kiss_modem_protocol/#sensor-data-sensors-response","title":"Sensor Data (Sensors response)","text":"<p>Data returned in CayenneLPP format. See CayenneLPP documentation for parsing.</p>"},{"location":"kiss_modem_protocol/#cryptographic-algorithms","title":"Cryptographic Algorithms","text":"Operation Algorithm Identity / Signing / Verification Ed25519 Key Exchange X25519 (ECDH) Encryption AES-128 block encryption with zero padding + HMAC-SHA256 (MAC truncated to 2 bytes) Hashing SHA-256"},{"location":"kiss_modem_protocol/#notes","title":"Notes","text":"<ul> <li>Data payload limit (255 bytes) matches MeshCore MAX_TRANS_UNIT; no change needed for KISS \"1024+ recommended\" (that applies to general TNCs, not MeshCore)</li> <li>Modem generates identity on first boot (stored in flash)</li> <li>All multi-byte values are little-endian unless stated otherwise</li> <li>SNR values in RxMeta are multiplied by 4 for 0.25 dB precision</li> <li>TxDone is sent as a SetHardware event after each transmission</li> <li>Standard KISS clients receive only type 0x00 data frames and can safely ignore all SetHardware (0x06) frames</li> <li>See packet_format.md for packet format</li> </ul>"},{"location":"lora_ota_automation/","title":"Scripted LoRa OTA from start to finish","text":"<p>The dedicated RAK3401 chain report records the physical failures of withdrawn migrations and the physically qualified compact nine-step replacement. Its runner blocks the withdrawn chains and pins every accepted bridge image by SHA-256.</p> <p><code>tools/lora_ota/lora_ota.sh</code> and <code>tools/lora_ota/lora_ota.ps1</code> automate a MeshCore LoRa firmware update from a release <code>.zip</code> or ready <code>.mota</code>. They identify the destination, validate the hardware and running firmware, prepare the right container, move the participating nodes to a temporary radio channel, serve and monitor the download, request installation, restore the controller, and check the rebooted node.</p> <p>The script cannot install the destination's first OTA-capable firmware. It is also deliberately application-only: it rejects both v3 bootloader containers and a v2 container carrying the bootloader flag, and it never sends the privileged install command. Do the first nRF52 bootloader installation over USB. An already-capable, explicitly supported internal-flash, XIAO QSPI, or exact MeshTower V2 microSD repeater may later use the separate manual <code>ota bootloader install</code> workflow.</p>"},{"location":"lora_ota_automation/#required-topology","title":"Required topology","text":"<p>The reliable serial topology uses two local radios:</p> <pre><code>                                      authenticated admin commands\ncomputer -- MeshCore binary API --&gt; controller Companion -------------------+\n   |                                                                         |\n   +-- raw text CLI + mOTA seeder --&gt; OTA source ---- LoRa OTA blocks ----&gt; target\n                                                        |                    ^\n                                                        +-- relay(s) --------+\n</code></pre> <ul> <li>Controller: a Companion connected through serial, TCP, or BLE. The   script uses <code>meshcli</code> to send remote admin commands to the target and changes   the controller's live radio parameters during the transfer. A serial   Companion stays in its normal Binary USB mode at 115200 baud.</li> <li>OTA source: an OTA-enabled repeater/FULL node whose USB port is a raw   text CLI, an ESP32 <code>companion_radio_full</code> using WiFi ports 5001 and 5002, or   an nRF52 <code>companion_radio_full</code> whose USB port switches between Binary,   terminal control, and exclusive mOTA seeding.</li> <li>Target: an OTA-enabled ESP32 or nRF52 node present in the controller's   contact list. Its admin password is required.</li> <li>Relays: optional. They do not need to install OTA themselves, but every   relay on the path must be running current firmware and have an overlapping   TempRadio window.</li> </ul> <p>One serial port cannot serve both controller roles: <code>meshcli</code> must keep reopening the controller while <code>motatool</code> owns the source port. The script rejects an attempt to use the same port for both.</p> <p>The USB ASCII switch (<code>+++MESHCORE-TERM-START</code>) is the local control path, not the mOTA data framing. On an nRF52 dual-CDC Full Companion, the script uses that mode briefly for <code>ota status</code> and TempRadio commands. It then closes the CLI and starts <code>motatool</code>; the exact <code>ota folder on</code> preamble switches the same USB interface <code>00</code> into exclusive mOTA mode from either startup ASCII or Binary Companion mode. If USB logging was enabled and the Full Companion rebooted, its separate interface <code>02</code> continues to provide plaintext logging and is not a controller or source port. With default logging off, interface <code>02</code> is not enumerated. BLE remains available.</p> <p>ESP32 Full Companion normally uses its dedicated TCP seeder on port 5001. ESP32 builds that also retain serial folder support use the same exclusive USB mOTA ownership state as nRF52. The exact <code>ota folder on</code> line transfers the USB port from startup ASCII or idle Binary Companion mode before binary mOTA frames begin; neither console mode shares that port until the folder detaches.</p>"},{"location":"lora_ota_automation/#destination-requirements","title":"Destination requirements","text":"Destination Package installed One-time prerequisite Raw ZIP handling ESP32 Full application image OTA-enabled image with an A/B partition table Builds a full mOTA from the matching non-merged application <code>.bin</code> nRF52, internal flash In-place delta Exact-board OTAFIX bootloader with mOTA apply support Requires <code>--base</code> with the exact image currently running nRF52 repeater, external QSPI Full image or in-place delta QSPI-aware exact-board OTAFIX bootloader and matched repeater build Builds a full mOTA; adding <code>--base</code> requests a delta MeshTower V2 nRF52, microSD Full image or in-place delta SD-aware exact-board OTAFIX bootloader and compatible card Builds a full mOTA; adding <code>--base</code> requests a delta <p>MeshTower V2 microSD application and bootloader containers require an Ed25519 signature from a key in the device allowlist. Supply <code>--sign-key</code> when the runner must build a container, and install the BLM2-capable SD-aware bootloader locally before attempting application or bootloader OTA. Preview.12 requires USB/BLE DFU or SWD; see MeshTower V2 microSD LoRa OTA.</p> <p>The firmware inside a raw ZIP must have a valid MeshCore <code>EndF</code> trailer. An ESP32 merged/factory image is not an application image and is rejected. A generic vendor DFU ZIP may also be unusable if it does not contain the raw EndF-bearing <code>.hex</code> or <code>.bin</code>.</p> <p>For an internal-staging nRF52, the exact base image is irreducible information. The node reports its eight-byte body hash, but that hash cannot reconstruct the firmware bytes needed to create a delta. Keep the <code>.pio/build/ENV/firmware.hex</code> that was actually flashed. A matching filename or version alone is not enough.</p>"},{"location":"lora_ota_automation/#1-install-the-host-tools","title":"1. Install the host tools","text":"<p>Install Python 3.10 or newer, Rust, Git, the official <code>meshcore-cli</code>, and the official <code>motatool</code>.</p> <p>On Bash:</p> <pre><code>python3 -m pip install --user pipx\npython3 -m pipx ensurepath\npipx install meshcore-cli\n\ngit clone https://github.com/vk496/motatool.git\ncargo install --path ./motatool\n\nmeshcli -v\nmotatool --version\n</code></pre> <p>On PowerShell:</p> <pre><code>py -m pip install --user pipx\npy -m pipx ensurepath\npipx install meshcore-cli\n\ngit clone https://github.com/vk496/motatool.git\ncargo install --path .\\motatool\n\nmeshcli -v\nmotatool --version\n</code></pre> <p>Restart the shell if <code>pipx</code> or Cargo reports that it changed <code>PATH</code>.</p>"},{"location":"lora_ota_automation/#2-identify-and-test-both-local-links","title":"2. Identify and test both local links","text":"<p>List serial devices:</p> <pre><code>meshcli -l\n</code></pre> <p>The examples below assume <code>/dev/ttyACM0</code> is the controller and <code>/dev/ttyACM1</code> is the OTA source. On Windows they might be <code>COM7</code> and <code>COM8</code>. Close picocom, a serial monitor, the phone app, and any other program holding either link.</p> <p>Test the controller's binary API:</p> <pre><code>meshcli -s /dev/ttyACM0 -b 115200 ver\n</code></pre> <p>For an ordinary raw-text source, test its OTA support:</p> <pre><code>meshcli -r -s /dev/ttyACM1 -b 115200 \"ota status\"\n</code></pre> <p>The command must print an <code>OTA | ... target:XXXXXXXX</code> status.</p> <p>For an nRF52 full Companion, open the source port with terminal mode selected automatically:</p> <pre><code>picocom -b 115200 \\\n  --imap spchex \\\n  --initstring $'+++MESHCORE-TERM-START\\r' \\\n  /dev/ttyACM1\n</code></pre> <p>Run <code>ota status</code>. It must report <code>OTA seeder</code>, <code>install:disabled</code>, and target <code>00000000</code>; send <code>+++MESHCORE-TERM-STOP</code> before closing the terminal. The automation detects and performs this token-wrapped preflight itself, so no extra command-line option is needed.</p> <p>For an ESP32 full Companion, test its separate WiFi control console instead:</p> <pre><code>printf 'ota status\\r\\n' | nc 192.168.1.50 5002\n</code></pre> <p>It must report <code>OTA seeder</code>, <code>install:disabled</code>, and target <code>00000000</code>.</p> <p>Changing a terminal to 57600 baud does not select ASCII mode. USB Companion builds and the normal raw management CLI use 115200 unless a particular build was explicitly configured otherwise.</p>"},{"location":"lora_ota_automation/#3-check-the-destination-once","title":"3. Check the destination once","text":"<p>The destination must be in the controller's contacts and remotely reachable on the normal channel. The script runs these authenticated checks itself:</p> <pre><code>ota status\nget bootloader.ver\nota self\nota stats\n</code></pre> <p>The script uses <code>get bootloader.ver</code> to distinguish ESP32 from nRF52 and, for nRF52, report the installed bootloader version. It then requires <code>ota self</code> to report <code>bootloader: apply OK</code>, <code>bootloader: QSPI apply OK</code>, or <code>bootloader: SD apply OK</code> and checks the reported bootloader ABI and codec mask against the selected package. If the version command is unavailable on older firmware, the script warns and falls back to the legacy <code>ota self</code> platform marker. If an nRF52 bootloader lacks the required capabilities, install the exact-board OTAFIX bootloader first. Current firmware also reports <code>maxblk:2048</code> near the front of both OTA replies. The runner treats a missing marker as the deployed 1 KiB receive limit, rejects a ready 2 KiB package for such a target before transfer, and passes the live limit to <code>motatool --block-size</code> when it builds from raw firmware. Thus updating an older target from a release ZIP produces a compatible 1 KiB package while a current target retains the 2 KiB application default. <code>ota stats</code> is only an optional EndF version probe. It uses one bounded retry cycle; unsupported firmware or a lost reply falls back directly to the required <code>ver</code> command instead of entering an operator continuation loop.</p> <p>The default TempRadio tuple is:</p> <pre><code>909.950,250,5,5,120\n</code></pre> <p>The test default is 250 kHz bandwidth, SF5, and CR5. The frequency is only a North American example: choose a legal frequency supported by every participating radio and appropriate to your location. Older radios that do not support SF5 require a complete replacement tuple passed with <code>--temp-radio</code>.</p> <p>Before that long window is allowed, the live runner performs a mandatory independent three-minute rehearsal. Its exact normal-channel <code>ota status</code> and <code>ota self</code> identity proof gets one shared four-minute, read-only budget before any schedule, radio override, seeder, or transfer is armed; this tolerates a marginal link without consuming or extending a live lease. It advances a stale managed controller with exact readback and treats a source terminal's whole-minute display as an uncertainty window, never as an exact epoch. A source minute overlapping the host is preserved; a completely stale minute is pinned to a guarded future value and read back once. Neither clock is moved backward, and the runner stops if a managed clock cannot be proven within the ten-minute limit. Each remote participant must expose an empty <code>tempradioat</code> schedule. The runner projects one fixed start/end interval into each participant's independently sampled RTC, sends each mutation once, proves every exact identity on the temporary tuple, waits for natural expiry, and proves the complete normal path again. A lost schedule reply is resolved by those on-air proofs; it is never blindly replayed with a fresh duration.</p> <p>The published RAK3401 <code>v1.16.7-c1caa5ad</code> LoRa-OTA image includes <code>get/set/del tempradioat</code> and can take this safe first step. A truly older or reduced build without fixed TempRadio scheduling is rejected before mutation; bootstrap it locally or with another explicitly controlled maintenance path. The automation does not substitute an immediate <code>tempradio</code> command whose first delivery could remain queued after cleanup.</p>"},{"location":"lora_ota_automation/#rxps-handling-during-tempradio","title":"RXPS handling during TempRadio","text":"<p>RXPS improves receive performance per unit of radio-on time, so the runner keeps the destination's saved RXPS preference enabled whenever the selected fast tuple has a qualified timing window. Before changing any radio, it reads <code>ver</code> from the destination, controller, source, and every named relay. It treats v1.17.1.5 as the first forward contract in which every SF5-SF8 transmission, including a retry, uses the same tuple-selected physical preamble: normally 32 symbols, 64 only when 32 cannot enable RXPS, and 128 only when neither 32 nor 64 can. A saved RXPS level is also safely retuned after a radio change. An older or unparseable destination version fails closed: the runner temporarily sends <code>set radio.rxps off</code> instead of assuming an ad-hoc build contains the timing fixes. Automation deliberately treats the version as a wire-format contract.</p> <p>For the default SF5/BW250 tuple, the runner keeps destination RXPS on only when the destination and every possible sender are v1.17.1.5 or newer. It does not overwrite an existing level-based preference. Current firmware retunes that preference against the tuple-selected 64-symbol wire preamble; the qualified boundary is effective level 8, preamble 64 (<code>1252 / 6424 us</code>). A manually configured node may save <code>set radio.rxps level 8 preamble 32</code> before entering TempRadio: when 32 symbols cannot cover the TCXO transition, firmware safely selects the real 64-symbol preamble. If the saved setting uses fixed manual timings, or even one participant is older or unknown, RXPS is temporarily off. This avoids the receive gap that a 32-symbol sender or an unretuned manual window would create.</p> <p>The complete qualified SX1262+TCXO policy is:</p> TempRadio SF/BW Saved reference setting Qualified boundary Automation SF7/BW500 <code>level 7 preamble 32</code> 7 / 32 RXPS on for a current destination SF6/BW250 <code>level 7 preamble 32</code> 7 / 32 RXPS on for a current destination SF5/BW125 <code>level 7 preamble 32</code> 7 / 32 RXPS on for a current destination SF5/BW250 <code>level 8 preamble 32</code> 8 / 64 RXPS on only when every participant follows the 64-symbol contract SF6/BW500 <code>level 8 preamble 32</code> 8 / 64 RXPS on only when every participant follows the adaptive-preamble contract SF5/BW500 <code>level 8 preamble 32</code> 8 / 128 RXPS on only when every participant follows the adaptive-preamble contract SF5/BW62.5 <code>level 10 preamble 16</code> 10 / 16 RXPS on for a current destination Unqualified tuple none continuous RX RXPS temporarily off <p>If RXPS was already off, the runner leaves it off. Otherwise it writes the original level, preamble assumption, receive/sleep periods, and temporary decision to protected <code>target-rxps-settings.json</code> in the run's working directory, verifies the temporary state, and restores the exact original setting after the target is back on its normal radio. Current firmware exposes this complete state through <code>get radio.rxps.config</code>; a legacy reply has only on/off and periods, so the runner can restore those periods but cannot reconstruct an unreported saved level. A radio change later recalculates from a preserved saved minimum, so moving back to a slower tuple returns to the operator's saved level.</p> <p>The OTA source has a stricter policy than the destination. For every source with a managed serial or TCP CLI, the runner reads and retains its exact RXPS preference, using the legacy fixed-period query only when the detailed query is unavailable. It builds and verifies the package, completes the read-only target checks, and obtains confirmation while that preference remains unchanged. Immediately before the first radio mutation, it reads the source RXPS state again, disables RXPS, and verifies the readback. Source RXPS stays off through catalog serving, download, installation, and post-install identity verification. Cleanup first proves that the source has returned to its normal radio, then restores and verifies the exact saved level/preamble or fixed-period state once. A source whose RXPS state cannot be read, disabled, or restored safely fails closed. If current firmware explicitly rejects an RXPS disable or restore with <code>radio busy; retry</code>, the runner retries that idempotent mutation at staggered 210\u2013378 ms intervals. All 32 delays are distinct and contribute about 9.4 seconds of waits; source-CLI command round-trip time is additional. This avoids repeatedly sampling one radio phase while retaining a strict attempt cap. Other rejections are not replayed.</p>"},{"location":"lora_ota_automation/#4-run-an-esp32-update","title":"4. Run an ESP32 update","text":"<p>The ZIP can contain a compatible ready <code>.mota</code> or the exact board-and-role non-merged application <code>.bin</code>:</p> <pre><code>export MESHCORE_ADMIN_PASSWORD='target-admin-password'\n\n./tools/lora_ota/lora_ota.sh ./release.zip \"Roof ESP32\" \\\n  --controller-serial /dev/ttyACM0 \\\n  --source-serial /dev/ttyACM1\n</code></pre> <p>The script shows the detected target, hardware, running hash, chosen package, version, manifest ID, and action before asking for confirmation. For an unattended job, add <code>--yes</code>:</p> <pre><code>./tools/lora_ota/lora_ota.sh ./release.mota \"Roof ESP32\" \\\n  --controller-serial /dev/ttyACM0 \\\n  --source-serial /dev/ttyACM1 \\\n  --yes\n</code></pre> <p>PowerShell equivalents:</p> <pre><code>$env:MESHCORE_ADMIN_PASSWORD = 'target-admin-password'\n\n&amp; .\\tools\\lora_ota\\lora_ota.ps1 '.\\release.zip' 'Roof ESP32' `\n  --controller-serial COM7 `\n  --source-serial COM8\n\n&amp; .\\tools\\lora_ota\\lora_ota.ps1 '.\\release.mota' 'Roof ESP32' `\n  --controller-serial COM7 `\n  --source-serial COM8 `\n  --yes\n</code></pre> <p>Prefer the environment variable or the interactive password prompt. Passing <code>--password</code> works, but the wrapper's own command line may be visible to other local processes. The runner keeps the password out of child <code>meshcli</code> command lines and removes its protected temporary command file after each call.</p>"},{"location":"lora_ota_automation/#5-run-an-nrf52-update","title":"5. Run an nRF52 update","text":"<p>If the input ZIP already contains a compatible in-place delta <code>.mota</code>, no base argument is needed: its embedded base hash is compared with the live node. If the ZIP contains raw new firmware, supply the exact running image:</p> <pre><code>./tools/lora_ota/lora_ota.sh ./nrf52-new-release.zip \"Hill nRF52\" \\\n  --base ./firmware-that-is-running.hex \\\n  --controller-serial /dev/ttyACM0 \\\n  --source-serial /dev/ttyACM1\n</code></pre> <pre><code>&amp; .\\tools\\lora_ota\\lora_ota.ps1 '.\\nrf52-new-release.zip' 'Hill nRF52' `\n  --base '.\\firmware-that-is-running.hex' `\n  --controller-serial COM7 `\n  --source-serial COM8\n</code></pre> <p>Before building a delta, the runner proves that the base's target ID, hardware identity, firmware version when available, and <code>EndF</code> body hash match the live destination. It then asks <code>motatool</code> for codec 2, the nRF52 in-place format. The normal workspace is <code>0x98000</code>.</p> <p>For a QSPI-backed repeater or the SD-backed MeshTower V2 target, a raw ZIP becomes a full image without <code>--base</code>. Supplying an exact base requests a smaller in-place delta and automatically selects the conservative external workspace <code>0xC6000</code>, which is safe for S140 v6 and v7 application layouts. An explicit <code>--inplace-memory</code> overrides the automatic value.</p> <p>The live runner detects QSPI from <code>ota self</code> (<code>QSPI apply OK</code>) or <code>ota status</code> (<code>bl:QSPI</code>) and refuses an explicit <code>QSPI store:ERR 0K</code> report even when the bootloader itself advertises QSPI apply support. Offline <code>--prepare-only</code> runs must supply <code>--nrf-qspi</code>; do not use that switch for a board that only exposes QSPI pins or uses the chip as a Companion filesystem. The application and bootloader must both be from the matched repeater list in the nRF52 QSPI guide.</p>"},{"location":"lora_ota_automation/#6-add-intermediate-relays","title":"6. Add intermediate relays","text":"<p>List relays from farthest to nearest so each command is sent before its route moves to TempRadio. A bare relay name uses the destination password; use <code>NAME=PASSWORD</code> when it differs:</p> <pre><code>./tools/lora_ota/lora_ota.sh ./release.mota \"Remote Target\" \\\n  --controller-serial /dev/ttyACM0 \\\n  --source-serial /dev/ttyACM1 \\\n  --relay \"Far Relay=far-password\" \\\n  --relay \"Near Relay=near-password\"\n</code></pre> <p>PowerShell uses the same arguments:</p> <pre><code>&amp; .\\tools\\lora_ota\\lora_ota.ps1 '.\\release.mota' 'Remote Target' `\n  --controller-serial COM7 `\n  --source-serial COM8 `\n  --relay 'Far Relay=far-password' `\n  --relay 'Near Relay=near-password'\n</code></pre>"},{"location":"lora_ota_automation/#other-connection-choices","title":"Other connection choices","text":"<p>The controller can use any one of:</p> <pre><code>--controller-serial PORT\n--controller-tcp HOST[:PORT]       # default port 5000\n--controller-ble ADDRESS_OR_NAME\n</code></pre> <p>An ESP32 FULL/repeater source can serve over its dedicated WiFi seeder port while its raw USB CLI is used to start TempRadio:</p> <pre><code>./tools/lora_ota/lora_ota.sh ./release.mota \"Remote Target\" \\\n  --controller-serial /dev/ttyACM0 \\\n  --source-tcp 192.168.1.50:5001 \\\n  --source-cli-serial /dev/ttyACM1\n</code></pre> <p>An ESP32 <code>companion_radio_full</code> uses WiFi for both dedicated source links:</p> <pre><code>./tools/lora_ota/lora_ota.sh ./release.mota \"Remote Target\" \\\n  --controller-serial /dev/ttyACM0 \\\n  --source-tcp 192.168.1.50:5001 \\\n  --source-cli-tcp 192.168.1.50:5002\n</code></pre> <p>Port 5002 defaults automatically when it is omitted from <code>--source-cli-tcp</code>. Current Full Companion firmware exposes its complete role-specific text terminal there; the runner uses only <code>ota</code>, <code>tempradio</code>, and <code>normalradio</code>, and remains compatible with older bounded port-5002 consoles. The source-only Companion never stages or installs the image itself; it streams the host folder to other nodes over LoRa. See the full Companion guide for manual operation and interface details.</p> <p>An nRF52 <code>companion_radio_full</code> uses one USB source port sequentially. The runner automatically wraps local control commands in the terminal tokens, and unmodified <code>motatool</code> switches that port into mOTA mode when seeding starts:</p> <p>The wrapper sends STOP, then START, before each command. This makes fallback independent of whether a prior raw probe left an unobservable USB-UART connection in ASCII or Binary mode. Seeder startup is reported only after the verbose device log contains its <code>COUNT</code> acknowledgement; an immediate device <code>ERR</code> or a missing acknowledgement fails during startup instead of surfacing later as a catalog timeout.</p> <pre><code>./tools/lora_ota/lora_ota.sh ./release.mota \"Remote Target\" \\\n  --controller-serial /dev/ttyACM0 \\\n  --source-serial /dev/ttyACM1\n</code></pre> <p>If the source is already on the exact TempRadio tuple through a scheduled or manual operation, <code>--source-already-temp</code> lets a TCP source run without a raw CLI link. The script cannot verify, extend, or shorten that source window, so leave a comfortable time margin. It also cannot inspect or change that unmanaged source's RXPS state; disable source RXPS yourself before starting the run and restore it only after returning the source to its normal radio.</p> <p>Use <code>--controller-baud</code> or <code>--source-baud</code> only for a build whose corresponding interface is genuinely configured to another speed.</p>"},{"location":"lora_ota_automation/#package-selection-and-safety-gates","title":"Package selection and safety gates","text":"<p>For a ZIP, the runner first examines every <code>.mota</code> without extracting paths. It keeps only packages matching the live target, hardware, base, platform, codec, and bootloader capabilities. It chooses the newest compatible version and prefers a delta over a full image at the same version. If equally suitable files differ, select one explicitly:</p> <pre><code>--zip-member path/inside/archive/update.mota\n</code></pre> <p>If no ready mOTA is usable, it searches <code>.bin</code> and <code>.hex</code> members for a valid, matching <code>EndF</code>, then builds the platform-appropriate container. Every result is structurally checked by the runner and independently passed through <code>motatool verify</code> before any radio changes. Direct firmware and mOTA inputs, as well as individual ZIP members, are rejected above 64 MiB before being loaded.</p> <p>Useful controls:</p> <ul> <li><code>--public-key signer.key.pub</code> requires a particular Ed25519 signer during   verification.</li> <li><code>--sign-key signer.key</code> signs a newly built container.</li> <li><code>--no-install</code> downloads and verifies the image but leaves it staged. By   default the runner then schedules the target, relays, and a script-configured   source back to their normal radios. Combining it with   <code>--leave-controller-radio</code> deliberately preserves the destination, relays,   and separate controller on the TempRadio topology; a managed source is still   returned to normal so its exact RXPS setting can be restored.   If the version gate required RXPS off, it stays off while that topology is   preserved; use <code>target-rxps-settings.json</code> to restore it only after sending   <code>normalradio</code>.</li> <li><code>--allow-non-upgrade</code> deliberately permits the same or an older version.</li> <li><code>--replace-active-download</code> deliberately discards a different update already   downloading or staged on the target. Without it, that update is preserved.</li> <li><code>--source-shares-controller</code> is for a Full Companion whose USB Binary API is   the controller while its TCP port <code>5001</code> is the source. It verifies that the   source's port-<code>5000</code> public key equals the controller key, then binds the   fresh port-<code>5002</code> Full Terminal banner's complete public key to that Binary   identity and challenges it with the supported <code>ver</code> command. It does not   assume the Full Terminal implements repeater-only <code>get public.key</code>. Port   <code>5002</code> uses a bounded local <code>tempradio</code> override to move the shared physical   radio without overwriting its saved normal tuple; the Binary API remains the   authenticated transport. Cleanup sends local <code>normalradio</code>, proves that   override inactive, and then reasserts the saved Binary tuple. It cannot be   combined with   <code>--leave-controller-radio</code>,   because exact source RXPS restoration requires that shared physical radio to   be back on its verified normal tuple.</li> <li><code>--require-system-watchdog-off</code> checks <code>get system.watchdog</code> immediately   before every <code>ota install</code> transmission and refuses installation unless the   destination reports <code>&gt; off</code>. Use it for nRF52 chains whose bootloader cannot   service an application watchdog inherited across reset.</li> <li>Managed <code>--relay</code> nodes have their original <code>rxdelay</code> and <code>txdelay</code> captured   in the work directory. During transfer the runner verifies <code>rxdelay 0</code> and   an airtime-scaled <code>txdelay 0.3</code> (override with <code>--relay-txdelay</code>), then   restores both values before the relay leaves TempRadio.</li> <li><code>--work-dir PATH</code> chooses a new, non-existent work directory.</li> <li><code>--meshcli PATH</code> and <code>--motatool PATH</code> select binaries not on <code>PATH</code>.</li> <li><code>--package-build-timeout SECONDS</code> bounds local mOTA generation. It defaults   to 3600 seconds. Run detools, delta/compression, and raw-firmware package   generation on a workstation or build VM, then transfer the completed,   hash-verified <code>.mota</code> to a Pi-class radio host. The Pi should perform only   lightweight identity-gated hardware I/O and serve that finished artifact;   preparation still occurs before any radio state changes.</li> <li><code>--debug</code> prints redacted child commands, timeouts, process status, stdout,   and stderr. Admin passwords are never printed, but node names, addresses,   paths, and command replies can still be sensitive; share the log carefully.</li> </ul> <p>For offline package preparation only:</p> <pre><code>./tools/lora_ota/lora_ota.sh ./release.zip offline \\\n  --prepare-only \\\n  --platform nrf52 \\\n  --target-id 1234ABCD \\\n  --target-base-hash 0011223344556677 \\\n  --target-hw Heltec_T114 \\\n  --base ./firmware-that-is-running.hex\n</code></pre> <p>Live operation is safer because the script obtains these values directly from the destination.</p>"},{"location":"lora_ota_automation/#what-happens-during-a-run","title":"What happens during a run","text":"<ol> <li>Validate the input paths and host tools, then prove the source is either an    OTA-enabled raw CLI or a source-only full Companion control interface. Read    and durably save a managed source's exact RXPS preference without changing    it.</li> <li>Before sending any remote packet, prove the managed source has no active,    pending, or fixed TempRadio work, then gate the source and controller    clocks. Advance a stale exact clock to host time; for a minute-resolution    source, preserve an overlapping minute or use one guarded forward value    with readback. Preserve a small future lead and fail closed above the    ten-minute drift limit. Then    authenticate to the target, query its target ID, hardware, running body    hash, firmware version, bootloader version, and nRF52 bootloader    capabilities, and save the controller's normal radio tuple.</li> <li>Select or build one compatible v2 application mOTA and verify all block    hashes, Merkle root, full-image hash where applicable, identity fields,    signature, codec, base, and the live firmware's reported maximum block size    (1 KiB for legacy replies without <code>maxblk</code>, currently 2 KiB otherwise).    Version-3 bootloader packages are refused before any target state changes.</li> <li>Read every participant's version, save the destination's RXPS state,    select the qualified destination policy, and show the confirmation prompt.</li> <li>Run the fixed-window three-minute rehearsal described above. This phase    does not disable RXPS, start a seeder, request a pull, or install anything;    the long transfer remains completely unarmed until temporary and normal    reachability both pass.</li> <li>Fresh-read, disable, and verify source RXPS; apply and verify the    destination RXPS policy; then start TempRadio on the    target, far-to-near relays, and source. A separate controller is moved and    read back through Binary; a shared Full Companion instead schedules its    bounded local override while Binary remains the transport. The runner    rejects a TempRadio window that cannot cover setup, seeder startup,    discovery, the transfer timeout, final polling, and install checks.</li> <li>Start <code>motatool serve</code>, discover the exact eight-hex manifest ID, request    <code>ota pull &lt;id&gt; flash</code>, and poll until that same ID reports ready. A seeder    process exit stops the run immediately. For <code>--no-install</code>, schedule all    script-controlled nodes back to their normal radios before restoring the    controller, unless <code>--leave-controller-radio</code> was requested.</li> <li>Recheck that exact ID, give the target a short final TempRadio safety window,    and request <code>ota install</code>. Then shorten each relay's TempRadio window so the    normal multi-hop route returns, stop the seeder, shorten the source window,    restore the controller, and probe <code>ota self</code> every 10 seconds through the    configured readiness window (five minutes by default). The exact new body    hash is the readiness signal;    only then does the runner require the exact package version. A relayed run    continues the 10-second probes through the mandatory relay-return window. A    source supplied with <code>--source-already-temp</code> is never modified.    <code>--leave-controller-radio</code> moves the controller back to TempRadio only after    this normal-channel verification. Restore the destination's exact original    RXPS setting after normal-channel identity is proven. A managed source stays    RXPS-off through that verification and its exact setting is restored only    after its own TempRadio state is proven inactive.</li> </ol> <p>Remote replies are matched only after queued messages have been drained and only when they come from the intended contact and fit the command. A ready status for another manifest ID is an error, never permission to install it.</p>"},{"location":"lora_ota_automation/#transmission-loss-and-retries","title":"Transmission loss and retries","text":"<p>Read-only and replay-safe transmissions retry up to three times. Three retries or 90 seconds, whichever comes first, opens a 10-second stop-or-continue prompt when stdin is an interactive terminal. Continue remains the default on timeout or Enter, so an operator can persist through a temporary outage; enter <code>s</code> or <code>stop</code> to end the run, and Ctrl-C remains immediate. With non-interactive stdin, the runner stops after that finite automatic retry cycle instead of silently starting another cycle forever. Optional participant-version probes always use a bounded cycle and degrade to <code>unknown</code>; optional destination <code>ota stats</code> falls back directly to <code>ver</code>. The mandatory normal-channel destination baseline is the narrow exception: it may make nine total read-only attempts but is stopped by one hard four-minute deadline before any TempRadio lease or OTA mutation exists. Proofs inside the live rehearsal retain the smaller four-attempt limit.</p> <p>Commands that change OTA state are reconciled before replay:</p> <ul> <li>After a lost <code>ota pull</code> reply, <code>ota status</code> must show the requested manifest   ID before the runner treats the pull as started. Otherwise the safe retry   policy applies.</li> <li>A lost <code>ota install</code> reply is not blindly resent. After a short wait, it is   sent again only if the target replies that the same manifest is still ready.   If the target has stopped replying because it may be rebooting, the runner   restores the normal path and lets post-reboot identity resolve the outcome.   The target's final three-minute safety window also returns a non-rebooting   target to the normal channel promptly.</li> </ul> <p>Retries and operator-selected continuation can outlast the original TempRadio budget. If a bounded window expires, rerun the same package after the nodes return to their normal channel; the manifest-ID check resumes its partial download without replacing it.</p> <p>The working directory is created before a managed source can be changed, then retained and printed at exit. It contains the exact served mOTA, <code>motatool-serve.log</code>, extracted build inputs when needed, and <code>controller-radio.txt</code>. A managed source also gets a protected <code>source-rxps-settings.json</code> containing its exact original preference and idempotent restore command. Its contents and directory entry are flushed before RXPS is disabled. When the destination started with RXPS enabled, protected <code>target-rxps-settings.json</code> records its manual recovery state. The RAK3401 chain points every nested step at one chain-root source record, so a rerun after host power loss does not adopt the temporary RXPS-off state as the original. A retained record is accepted only for the same managed CLI endpoint. These files contain no saved admin password. After exact source restoration, a standalone run atomically retires its record; the chain retains its shared record between steps and retires it only after the verified endpoint restoration completes.</p>"},{"location":"lora_ota_automation/#interruption-and-recovery","title":"Interruption and recovery","text":"<p>Ctrl-C stops the seeder, detaches its serial folder, makes a bounded attempt to shorten a source TempRadio window started by the script, and attempts to restore the controller. For a managed source it leaves RXPS off until the source is proven back on its normal radio, then restores and verifies the saved source preference. A transient success-path restore failure remains armed for one more idempotent cleanup attempt. The target and relays remain on TempRadio only until their bounded windows end; rebooting also restores their saved radio settings. A normal cleanup restores the destination's exact RXPS periods. If that remote restore cannot be confirmed, use <code>target-rxps-settings.json</code> after the target returns to its normal channel. A partial download remains safe. Once the target is reachable again (after its TempRadio window ends, or after putting the controller back on that tuple), rerunning the same package recognizes its manifest ID and resumes the existing session instead of clearing it.</p> <p>When a chained run has already proved the newly running body hash, its retained previous package can briefly report <code>verifying staged blocks</code> after TempRadio reactivates the OTA manager. The runner waits only through the configured discovery timeout, keeps checking source liveness, and accepts only the same manifest becoming <code>ready to install</code> or the manager becoming idle. A changed ID, failed or incomplete state, or timeout stops the chain. It then proves the exact installed body again. If that same session is still attached and ready, the runner detaches it with <code>ota cancel</code>; if the manager has become idle, it sends no cancel. An ordinary-channel <code>no download</code> status proves only that the manager is idle, not that persistent staging was erased. The runner therefore does not issue or describe an IDLE cancel as durable cleanup. The next chain transition explicitly re-adopts and proves the expected previous MID before detaching it; after the final install OTAFIX has consumed the approval word, so any retained container is inert and is replaced by the next valid pull.</p> <p>A hard process kill or host power loss cannot run cleanup. Recover a serial controller using the tuple saved in the printed work directory:</p> <pre><code>radio=$(tr -d '\\r\\n' &lt; ./meshcore-lora-ota-20260807-123456-1234/controller-radio.txt)\nmeshcli -s /dev/ttyACM0 set radio \"$radio\"\n</code></pre> <pre><code>$radio = (Get-Content '.\\meshcore-lora-ota-...\\controller-radio.txt' -Raw).Trim()\nmeshcli -s COM7 set radio $radio\n</code></pre> <p>For a managed source, first return it to its ordinary radio, then inspect <code>source-rxps-settings.json</code> and issue its exact <code>restore_command</code> through the same serial or TCP-console endpoint recorded in that file. The command is idempotent; confirm the full setting with <code>get radio.rxps.config</code> before resuming an update.</p> <p>If you stop during final confirmation, reconnect on the node's normal channel and run <code>ota self</code> and <code>ver</code>. A completed run returns success only when <code>ota self</code> reports a valid new body hash and <code>ver</code> exactly matches the package; an unverified install returns status 2. Do not immediately replace a staged image: the default active-download guard preserves it until you explicitly use <code>--replace-active-download</code> or run <code>ota cancel</code>.</p> <p>Exit status is <code>0</code> for success, <code>2</code> for a validation or operational error, and <code>130</code> for Ctrl-C.</p>"},{"location":"mbedtls-tls-footprint/","title":"Shrinking the per-connection TLS footprint on non-PSRAM observers","text":""},{"location":"mbedtls-tls-footprint/#why","title":"Why","text":"<p>On a non-PSRAM Heltec V3 running two WSS/JWT broker slots, the largest allocatable block in internal DRAM walks down in ~16 KiB steps at every TLS reconnect while total free heap stays flat. Measured on hardware over 50 reconnect cycles: 62,452 -&gt; 16,372 bytes, permanently.</p> <p>The step size is not a coincidence. <code>framework-arduinoespressif32 3.20017</code> (Arduino 2.0.17, IDF 4.4) builds mbedTLS with the symmetric buffer configuration:</p> <pre><code>CONFIG_MBEDTLS_SSL_MAX_CONTENT_LEN 16384      # sizes BOTH the in and out record buffers\nCONFIG_MBEDTLS_SSL_KEEP_PEER_CERTIFICATE 1\n# CONFIG_MBEDTLS_ASYMMETRIC_CONTENT_LEN       -- not defined\n# CONFIG_MBEDTLS_DYNAMIC_BUFFER               -- not defined\n# CONFIG_MBEDTLS_SSL_VARIABLE_BUFFER_LENGTH   -- not defined\n</code></pre> <p>Read from <code>packages/framework-arduinoespressif32/tools/sdk/esp32s3/qio_qspi/include/sdkconfig.h</code>. Note the separate <code>framework-arduinoespressif32-libs</code> package in <code>~/.platformio</code> belongs to the esp32c6 env (pioarduino, IDF 5.3) and is not what this env links against -- though it happens to carry identical mbedTLS values.</p> <p>So each broker slot costs 2 x 16 KiB = 32 KiB of contiguous internal DRAM in record buffers alone, and two slots cost 64 KiB on a board with roughly 80 KiB free. Every reconnect frees and re-allocates those buffers, and anything that lands in the vacated hole in between prevents them from going back, which is the ratchet.</p> <p>Confirmed by two independent observations: losing a whole TLS session returned exactly 16,384 bytes of contiguity on one device and exactly 32,768 on another, and per-connection teardown frees ~41.6-44.7 KB total.</p>"},{"location":"mbedtls-tls-footprint/#what-the-firmware-could-already-do-and-its-limit","title":"What the firmware could already do, and its limit","text":"<p><code>softDisconnect()</code> (branch <code>perf/mqtt-renewal-no-stop</code>, commit <code>6c51e468</code>) stops the JWT renewal bounce from destroying and recreating the esp-mqtt task, keeping its 6 KiB stack out of the hole. Measured: the staircase arrests after 2 steps at 36,852 through cycle 16, where the baseline took 4 steps and settled at 16,372 by cycle 11 -- about 20 KB better.</p> <p>That is as far as the application layer reaches. MQTT 3.1.1 has no re-authentication packet, so presenting a fresh JWT requires a transport reconnect; mbedTLS's internal allocation order during the handshake is not controllable from the application. The remaining cost is the record buffers themselves.</p>"},{"location":"mbedtls-tls-footprint/#the-changes","title":"The changes","text":"<p>All three are compile-time in mbedTLS, and the Arduino framework ships precompiled <code>.a</code> archives (<code>tools/sdk/esp32s3/lib/libmbedtls.a</code>), so a project-level <code>-D</code> cannot change them. A custom framework build is required.</p> Setting From To Saving per connection <code>CONFIG_MBEDTLS_ASYMMETRIC_CONTENT_LEN</code> unset <code>y</code> enables the two below <code>CONFIG_MBEDTLS_SSL_IN_CONTENT_LEN</code> 16384 (implied) 16384 none -- keep it <code>CONFIG_MBEDTLS_SSL_OUT_CONTENT_LEN</code> 16384 (implied) 4096 ~12 KiB <code>CONFIG_MBEDTLS_SSL_KEEP_PEER_CERTIFICATE</code> <code>1</code> <code>n</code> ~4 KiB <p>Roughly 16 KiB per connection, 32 KiB across two slots.</p>"},{"location":"mbedtls-tls-footprint/#why-inbound-stays-at-16-kib","title":"Why inbound stays at 16 KiB","text":"<p>A peer may legitimately send a 16 KiB TLS record. Lowering the inbound limit only works if both brokers negotiate the max-fragment-length extension or provably never send larger, and getting it wrong produces invalid-record and handshake failures rather than a clean error. Outbound is ours to choose: this firmware's MQTT and WebSocket frames are far below 4 KiB (<code>MAX_TRANS_UNIT</code>-bounded packets plus small JSON), so 4 KiB is comfortable.</p>"},{"location":"mbedtls-tls-footprint/#risk-on-the-peer-certificate","title":"Risk on the peer certificate","text":"<p>Dropping <code>KEEP_PEER_CERTIFICATE</code> means <code>mbedtls_ssl_get_peer_cert()</code> returns NULL after the handshake. Chain validation still happens -- only retention of the parsed leaf changes. This firmware verifies against a CA (<code>GTS_ROOT_R4</code> / the bundle) and never inspects the peer certificate or a fingerprint, so it should be safe. It does change <code>mbedtls_ssl_session</code> layout, which is exactly why the whole framework must be rebuilt together rather than swapping a single archive in.</p>"},{"location":"mbedtls-tls-footprint/#build-procedure","title":"Build procedure","text":""},{"location":"mbedtls-tls-footprint/#do-not-use-esp32-arduino-lib-builder-for-this","title":"Do not use esp32-arduino-lib-builder for this","text":"<p><code>release/v4.4</code> is the branch matching Arduino 2.0.x, but its <code>update-components.sh</code> clones every dependency at master, so it no longer resolves. Five successive failures, each a different repo: the arduino branch name it passes to <code>-A</code> does not exist; <code>jq</code> is absent from the IDF image and its absence makes <code>build.sh</code>'s target loop a silent no-op that still exits 0; <code>esp_littlefs</code> and <code>esp32-camera</code> master require IDF &gt;=5.0/&gt;=5.1; <code>esp32-camera</code> later needs an <code>esp_jpeg</code> version the 4.4 registry cannot satisfy; and tinyusb's source layout no longer matches <code>arduino_tinyusb/CMakeLists.txt</code>. Pinning each one in turn just surfaces the next.</p>"},{"location":"mbedtls-tls-footprint/#rebuild-only-the-mbedtls-archives","title":"Rebuild only the mbedTLS archives","text":"<p>More rigorous anyway, because it reuses the shipped <code>sdkconfig</code> verbatim -- so the archives differ from stock only by the intended change, with no arduino-version or <code>DYNAMIC_BUFFER</code> drift.</p> <p>This is ABI-safe for the content-length change specifically: <code>ssl.h</code> declares <code>in_buf</code> and <code>out_buf</code> as <code>unsigned char *</code>, allocated in <code>ssl_setup()</code>, and no public struct embeds a CONTENT_LEN-sized array. The other precompiled archives (esp-tls, esp_http_client, esp-mqtt) therefore remain compatible. It is not safe for <code>CONFIG_MBEDTLS_SSL_KEEP_PEER_CERTIFICATE</code>, which changes <code>mbedtls_ssl_session</code> layout -- that one needs everything rebuilt together, so it is excluded here.</p> <ol> <li>Minimal IDF project whose only component requirement is <code>mbedtls</code>.</li> <li><code>sdkconfig.defaults</code> = the shipped    <code>packages/framework-arduinoespressif32/tools/sdk/esp32s3/sdkconfig</code>, with    <code>CONFIG_MBEDTLS_SSL_MAX_CONTENT_LEN=16384</code> replaced by the three asymmetric lines.    Verify the diff is exactly 5 lines before building.</li> <li><code>docker run --rm -v $PWD:/project -w /project espressif/idf:v4.4.7 idf.py -DIDF_TARGET=esp32s3 build</code></li> <li>Confirm <code>build/config/sdkconfig.h</code> carries <code>OUT_CONTENT_LEN 4096</code>.</li> <li>Stage the four archives under the framework's names -- note the rename:</li> </ol> built framework name stock size rebuilt <code>esp-idf/mbedtls/libmbedtls.a</code> <code>libmbedtls.a</code> 113,914 113,338 <code>esp-idf/mbedtls/mbedtls/library/libmbedtls.a</code> <code>libmbedtls_2.a</code> 1,252,150 1,245,718 <code>.../libmbedcrypto.a</code> <code>libmbedcrypto.a</code> 4,302,698 4,259,458 <code>.../libmbedx509.a</code> <code>libmbedx509.a</code> 676,590 673,318 <p>All within ~1% of stock, which is a good check that only the config differs.</p>"},{"location":"mbedtls-tls-footprint/#wire-it-in-with-l-never-platform_packages","title":"Wire it in with -L, never platform_packages","text":"<pre><code>PLATFORMIO_BUILD_FLAGS=\"-L/path/to/staged/archives\" pio run -e Heltec_v3_repeater_observer_mqtt\n</code></pre> <p>Verify with <code>grep -oE \"[^ ]*libmbed[a-z0-9_]*\\.a\" .pio/build/&lt;env&gt;/firmware.map | sort -u</code> -- every path must be the staged directory.</p> <p>Do not point <code>platform_packages</code> at a <code>file://</code> copy of the framework. PlatformIO installs it over the shared <code>~/.platformio/packages/framework-arduinoespressif32</code>, silently changing mbedTLS for every other ESP32 env and project on the machine. It does this even when the copy's <code>package.json</code> version differs -- verified twice here, and both times the fix was <code>rm -rf</code> the package and <code>pio pkg install</code> to re-download stock. A prepended library search path keeps the change scoped to one env, because the linker takes each archive member from the first archive that satisfies an undefined symbol.</p>"},{"location":"mbedtls-tls-footprint/#how-to-verify-it-worked","title":"How to verify it worked","text":"<ol> <li><code>strings</code>/<code>grep</code> the new <code>sdkconfig.h</code> for the four settings.</li> <li>Build and check the RAM figure; static usage should be unchanged (these are heap buffers).</li> <li>On hardware, <code>get mqtt.stats</code> at boot with two slots connected: the largest free block    should start roughly 24-32 KiB higher than the current 62-67 KiB.</li> <li>Soak across reconnect cycles and compare the floor against the two recorded runs:    baseline settled 16,372 (cycle 11); <code>softDisconnect</code> holds 36,852 (cycle 16).</li> </ol>"},{"location":"mbedtls-tls-footprint/#prior-art-in-this-investigation","title":"Prior art in this investigation","text":"<p><code>.scratch/mqtt-non-psram-heap-staircase-analysis-2026-08-05.md</code> (untracked -- <code>.scratch/</code> is globally gitignored) holds the full allocation inventory. <code>~/mqtt-soak/STATE.md</code> holds the soak evidence, including two retracted hypotheses worth not repeating: the perf commits were not the cause, and waev does not cap connections per IP.</p>"},{"location":"nrf52_companion_storage_recovery/","title":"nRF52 Companion automatic ExtraFS recovery","text":"<p>Companion builds using internal ExtraFS reserve 100 KiB at <code>0xD4000..0xED000</code>. Identity and preferences remain in the separate 28 KiB primary store at <code>0xED000..0xF4000</code>. This applies to internal-ExtraFS Companion builds, including Full, not repeaters or external QSPI storage.</p> <p>At startup the firmware:</p> <ol> <li>Mounts primary storage without erasing nonblank media. Only proven-blank    primary storage may be initialized automatically.</li> <li>Checks the exact ExtraFS address, size, block geometry, and application    linker reservation, then attempts a non-formatting secondary mount.</li> <li>Validates primary filesystem metadata before any destructive secondary    recovery. An unavailable primary store blocks recovery and identity replacement.</li> <li>Keeps an already mounted, metadata-valid ExtraFS unchanged. If its initial    mount or validation failed, unmounts and retries once without formatting.</li> <li>If the retry remains unusable, automatically formats only the reserved    100 KiB region, then remounts and validates it. There is one format attempt    per boot; failure keeps the contact/channel write quarantine active.</li> <li>Runs the existing verified migration from primary into ExtraFS. Primary    contact/channel sources are retired only after every destination is copied,    read back, and the migration transaction is committed. Identity and    preferences stay on primary.</li> </ol> <p>No terminal repair command, phone intervention, or bootloader update is needed for this recovery path when a compatible application/layout is already used. After successful recovery, the Companion storage API reports 100 KiB total rather than the 28 KiB primary fallback.</p>"},{"location":"nrf52_companion_storage_recovery/#data-loss-boundary","title":"Data-loss boundary","text":"<p>Automatic rebuilding prioritizes a usable contact/channel store over retaining an unreadable secondary filesystem. Data stored only in that damaged region can be lost. Surviving primary files are migrated, but may not contain the latest secondary-only changes. An API backup remains advisable before flashing. Primary storage is never formatted by this recovery path.</p> <p>This is mount/metadata recovery, not forensic file recovery. An invalid migration journal, unreadable individual contact page, primary-source error, full filesystem, or failed migration cleanup does not on its own trigger a format of a mountable, metadata-valid secondary store. Those cases retain the existing validation, retry, and incomplete-load protections.</p>"},{"location":"nrf52_companion_storage_recovery/#regression-coverage","title":"Regression coverage","text":"<p><code>test/test_internal_secondary_fs_repair</code> exercises healthy/no-format startup, successful remount, failed remount/traversal followed by one repair, and format/remount/validation failure. <code>test/test_nrf52_extrafs_contract.py</code> checks primary-first ordering, internal-only geometry guards, quarantine handling, and the separation between migration failures and destructive recovery.</p>"},{"location":"nrf52_companion_storage_recovery/#t1000-e-hardware-qualification-2026-09-03","title":"T1000-E hardware qualification (2026-09-03)","text":"<p>A device reporting 25/28 KiB primary fallback and contact enumeration error 5 was flashed with the recovery build. With no explicit repair command, startup activated 100 KiB ExtraFS and loaded all 125 contacts and 40 channel slots. Identity, preferences, radio settings, and channels matched the pre-update API snapshot. Add, edit, and delete of an owned temporary contact each survived a separate normal reboot; the device ended with the original 125 contacts and 27/100 KiB usage. The 161 offline/native regression tests and target build passed.</p> <p>This was not lossless recovery of every historical RAM value: 21 contacts had older advertisement/local-modification timestamps, including one older advertised location. No contact was missing, and no computer-backup restoration was used. A subsequent read-only scan found no readable cached advert for any of the 125 contacts. Without a surviving newer copy, firmware cannot infer those earlier values; receiving new verified advertisements can refresh them normally.</p>"},{"location":"nrf52_power_management/","title":"nRF52 Power Management","text":""},{"location":"nrf52_power_management/#overview","title":"Overview","text":"<p>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.</p>"},{"location":"nrf52_power_management/#features","title":"Features","text":""},{"location":"nrf52_power_management/#boot-voltage-protection","title":"Boot Voltage Protection","text":"<ul> <li>Checks battery voltage immediately after boot and before mesh operations commence</li> <li>If voltage is below a configurable threshold (e.g., 3300mV), the device configures voltage wake (LPCOMP + VBUS) and enters protective shutdown (SYSTEMOFF)</li> <li>Prevents boot loops when battery is critically low</li> <li>Skipped when external power (USB VBUS) is detected</li> </ul>"},{"location":"nrf52_power_management/#voltage-wake-lpcomp-vbus","title":"Voltage Wake (LPCOMP + VBUS)","text":"<ul> <li>Configures the nRF52's Low Power Comparator (LPCOMP) before entering SYSTEMOFF</li> <li>Enables USB VBUS detection so external power can wake the device</li> <li>Device automatically wakes when battery voltage rises above recovery threshold or when VBUS is detected</li> <li>Uses no LPCOMP hysteresis; on divided battery inputs the additional 50 mV   comparator hysteresis can move the effective battery wake point by several   hundred millivolts and strand an otherwise charged node</li> </ul>"},{"location":"nrf52_power_management/#early-boot-register-capture","title":"Early Boot Register Capture","text":"<ul> <li>Captures RESETREAS (reset reason) and GPREGRET2 (shutdown reason) before SystemInit() clears them</li> <li>Allows firmware to determine why it booted (cold boot, watchdog, LPCOMP wake, etc.)</li> <li>Allows firmware to determine why it last shut down (user request, low voltage, boot protection)</li> </ul>"},{"location":"nrf52_power_management/#shutdown-reason-tracking","title":"Shutdown Reason Tracking","text":"<p>Shutdown reason codes (stored in GPREGRET2):</p> 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"},{"location":"nrf52_power_management/#supported-boards","title":"Supported Boards","text":"Board family Implemented LPCOMP wake VBUS wake Seeed Studio XIAO nRF52840 (<code>xiao_nrf52</code>) Yes Yes Yes SenseCAP Solar Yes Yes Yes RAK4631 / RAK3401 Yes Yes Yes GAT562 30S / EVB Pro / Tracker Pro / Watch13 Yes Yes Yes Heltec T096 / T114 / T1 / Tower V2 Yes Yes Yes Muzi Works R1 Neo Partial Inactive Inactive Promicro nRF52840 No No No RAK WisMesh Tag No No No Heltec Mesh Solar No No No LilyGo T-Echo / T-Echo Lite / T-Impulse Plus No No No WIO Tracker L1 / L1 E-Ink / WM1110 No No No Mesh Pocket / Meshtiny / Nano G2 Ultra No No No ThinkNode M1 / M3 / M6 No No No T1000-E No No No Ikoka Nano / Stick / Handheld (nRF) No No No Keepteen LT1 / Minewsemi ME25LS01 No No No <p>Notes: - \"Implemented\" reflects Phase 1 (boot lockout + shutdown reason capture). - R1 Neo has the integration compiled, but its board configuration deliberately   sets <code>PWRMGT_VOLTAGE_BOOTLOCK</code> to <code>0</code>; automatic protective shutdown and its   voltage/VBUS recovery wake are therefore inactive. - User power-off does not enable LPCOMP wake; voltage recovery is armed only   for boot protection and automated low-voltage shutdown. - 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.</p>"},{"location":"nrf52_power_management/#technical-details","title":"Technical Details","text":""},{"location":"nrf52_power_management/#architecture","title":"Architecture","text":"<p>The power management functionality is integrated into the <code>NRF52Board</code> base class in <code>src/helpers/NRF52Board.cpp</code>. Board variants provide hardware-specific configuration via a <code>PowerMgtConfig</code> struct and override <code>initiateShutdown(uint8_t reason)</code> to perform board-specific power-down work and conditionally enable voltage wake (LPCOMP + VBUS).</p>"},{"location":"nrf52_power_management/#early-boot-capture","title":"Early Boot Capture","text":"<p>A static constructor with priority 101 in <code>NRF52Board.cpp</code> captures the RESETREAS and GPREGRET2 registers before: - SystemInit() (priority 102) - which clears RESETREAS - Static C++ constructors (default priority 65535)</p> <p>This ensures we capture the true reset reason before any initialisation code runs.</p>"},{"location":"nrf52_power_management/#board-implementation","title":"Board Implementation","text":"<p>To enable power management on a board variant:</p> <ol> <li> <p>Enable in platformio.ini:    <code>ini    -D NRF52_POWER_MANAGEMENT</code></p> </li> <li> <p>Define configuration in variant.h:    <code>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)</code></p> </li> <li> <p>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    };</p> </li> </ol> <p>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);</p> <pre><code> if (enable_lpcomp) {\n   configureVoltageWake(power_config.lpcomp_ain_channel, power_config.lpcomp_refsel);\n }\n\n enterSystemOff(reason);\n</code></pre> <p>}    #endif</p> <p>void MyBoard::begin() {      NRF52Board::begin();  // or NRF52BoardDCDC::begin()      // ... board setup ...</p> <p>#ifdef NRF52_POWER_MANAGEMENT      checkBootVoltage(&amp;power_config);    #endif    }    ```</p> <p>For user-initiated shutdowns, <code>powerOff()</code> remains board-specific. Power management only arms LPCOMP for automated shutdown reasons (boot protection/low voltage).</p> <ol> <li>Declare override in board .h file:    <code>cpp    #ifdef NRF52_POWER_MANAGEMENT      void initiateShutdown(uint8_t reason) override;    #endif</code></li> </ol>"},{"location":"nrf52_power_management/#voltage-wake-configuration","title":"Voltage Wake Configuration","text":"<p>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 no hysteresis so the configured recovery threshold is not widened by the battery divider - Wake the device from SYSTEMOFF when triggered</p> <p>VBUS wake is enabled via the POWER peripheral USBDETECTED event whenever <code>configureVoltageWake()</code> is used. This requires USB VBUS to be routed to the nRF52 (typical on nRF52840 boards with native USB).</p> <p>LPCOMP Reference Selection (PWRMGT_LPCOMP_REFSEL):</p> 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 <p>Important: For boards with a voltage divider on the battery sense pin, LPCOMP measures the divided voltage. Use: <code>VBAT_threshold ~ (VDD * fraction) * divider_scale</code>, where <code>divider_scale = (Rtop + Rbottom) / Rbottom</code> (e.g., 2.0 for 1M/1M, 2.5 for 1.5M/1M, 3.0 for XIAO).</p>"},{"location":"nrf52_power_management/#softdevice-compatibility","title":"SoftDevice Compatibility","text":"<p>The power management code checks whether SoftDevice is enabled and uses the appropriate API: - When SD enabled: <code>sd_power_*</code> functions - When SD disabled: Direct register access (NRF_POWER-&gt;*)</p> <p>This ensures compatibility regardless of BLE stack state.</p>"},{"location":"nrf52_power_management/#cli-commands","title":"CLI Commands","text":"<p>Power management status can be queried via the CLI:</p> Command Description <code>get pwrmgt.support</code> Returns \"supported\" or \"unsupported\" <code>get pwrmgt.source</code> Returns current power source - \"battery\" or \"external\" (5V/USB power) <code>get pwrmgt.bootreason</code> Returns reset and shutdown reason strings <code>get pwrmgt.bootmv</code> Returns boot voltage in millivolts <p>On boards without power management enabled, all commands except <code>get pwrmgt.support</code> return:</p> <pre><code>ERROR: Power management not supported\n</code></pre>"},{"location":"nrf52_power_management/#debug-output","title":"Debug Output","text":"<p>When <code>MESH_DEBUG=1</code> is enabled, the power management module outputs:</p> <pre><code>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</code></pre>"},{"location":"nrf52_power_management/#phase-2-planned","title":"Phase 2 (Planned)","text":"<ul> <li>Runtime voltage monitoring</li> <li>Voltage state machine (Normal -&gt; Warning -&gt; Critical -&gt; Shutdown)</li> <li>Configurable thresholds</li> <li>Load shedding callbacks for power reduction</li> <li>Deep sleep integration</li> <li>Scheduled wake-up</li> <li>Extended sleep with periodic monitoring</li> </ul>"},{"location":"nrf52_power_management/#references","title":"References","text":"<ul> <li>nRF52840 Product Specification - POWER</li> <li>nRF52840 Product Specification - LPCOMP</li> <li>SoftDevice S140 API - Power Management</li> </ul>"},{"location":"number_allocations/","title":"Number Allocations","text":"<p>This document lists unique numbers/identifiers used in various MeshCore protocol payloads.</p>"},{"location":"number_allocations/#group-data-types","title":"Group Data Types","text":"<p>The <code>PAYLOAD_TYPE_GRP_DATA</code> payloads have a 16-bit data-type field, which identifies which application the packet is for.</p> <p>To make sure multiple applications can function without interfering with each other, the table below is for reserving various ranges of data-type values. Just modify this table, adding a row, then submit a PR to have it authorised/merged.</p> <p>NOTE: the range FF00 - FFFF is for use while you're developing, doing POC, and for these you don't need to request to use/allocate.</p> <p>Once you have a working app/project, you need to be able to demonstrate it exists/works, and THEN request type IDs. So, just use the testing/dev range while developing, then request IDs before you transition to publishing your project.</p> Data-Type range App name Contact 0000 - 00FF -reserved for internal use- 0100 MeshCore Open zsylvester@monitormx.com - https://github.com/zjs81/meshcore-open 0110 - 011F Ripple ripple_biz@protonmail.com - https://buymeacoffee.com/ripplebiz 0120 MCO Advanced most.original.address@gmail.com - https://github.com/HDDen/meshcore-open/tree/rename-mco-advanced FF00 - FFFF -reserved for testing/dev- <p>(add rows, inside the range 0100 - FEFF for custom apps)</p>"},{"location":"ota_easy/","title":"Easy firmware updates over LoRa","text":"<p>This guide shows the shortest manual path for sending firmware from a computer to a MeshCore node over LoRa. Choose the package type for the destination node:</p> <p>For an end-to-end controller that accepts a release ZIP or ready mOTA, see Scripted LoRa OTA from start to finish.</p> Destination Update type Files needed to build the <code>.mota</code> Installer ESP32 Full firmware New non-merged application <code>.bin</code> ESP32 A/B firmware slots nRF52, internal staging In-place delta Exact running <code>firmware.hex</code> and new <code>firmware.hex</code> Exact-board OTAFIX bootloader Supported nRF52 QSPI repeater Full firmware or in-place delta New <code>firmware.hex</code>; a delta also needs the exact running <code>firmware.hex</code> Matching QSPI-aware OTAFIX bootloader MeshTower V2 SD target Full firmware or in-place delta New <code>firmware.hex</code>; a delta also needs the exact running <code>firmware.hex</code> Matching SD-aware OTAFIX bootloader <p>An internal-staging nRF52 target accepts only an in-place delta built against its exact running firmware. Matched QSPI repeater targets and the MeshTower V2 microSD target can also install a full image because the complete container stays off-chip. See nRF52 repeater OTA with external QSPI and MeshTower V2 microSD LoRa OTA.</p> <p>MeshTower V2 microSD application and bootloader containers must be Ed25519-signed by a key in the device allowlist; pass <code>--sign</code> to <code>motatool build</code> (or <code>--sign-key</code> to the end-to-end runner) when building one. Its BLM2-capable SD-aware bootloader is also required before ordinary application or bootloader OTA can use the reset-retained authorization record. Upgrade preview.12 locally over USB/BLE DFU or SWD first; there is no raw-card compatibility handoff.</p>"},{"location":"ota_easy/#temporary-ota-channel-used-in-this-guide","title":"Temporary OTA channel used in this guide","text":"Setting Value Center frequency 909.950 MHz Bandwidth 250 kHz Spreading factor SF5 Coding rate used in this guide CR5 Example window 120 minutes <p>The copy/paste command is:</p> <pre><code>tempradio 909.950,250,5,5,120\n</code></pre> <p>The fourth value is the transmit coding rate. This guide uses CR5, but the participating nodes' coding rates do not need to match.</p> <p><code>tempradio</code> is not saved and the node returns to its normal radio settings when the window ends or the node reboots. Current full-parser firmware also accepts <code>normalradio</code>, which cancels the temporary window and restores the saved tuple after replying on the current channel. This frequency is intended for North American configurations. Confirm that it is permitted in your location and change it when necessary.</p> <p>At SF5/BW250, an SX1262+TCXO destination can keep RXPS enabled only when it and every sender that can reach it (controller, source, and relays) follow the v1.17.1.5-or-newer adaptive-preamble contract. The qualified destination boundary is effective level 8, preamble 64 and <code>1252 / 6424 us</code>. For manual setup, save <code>set radio.rxps level 8 preamble 32</code> before entering TempRadio; the <code>32</code> is a conservative saved timing assumption and current firmware selects the real 64-symbol wire preamble when it retunes the temporary radio. For an older, unknown, or mixed-version path, use <code>set radio.rxps off</code> for the maintenance window. First record <code>get radio.rxps.config</code>; after <code>normalradio</code>, restore a reported level with <code>set radio.rxps level N preamble P</code> (omit <code>preamble P</code> when <code>P</code> is <code>0</code>). A legacy node returns only on/off and periods, which can be restored with <code>set radio.rxps RX_US SLEEP_US</code>. The scripted runner performs the version checks, temporary change, verification, and restoration automatically while preserving automatic retuning. SF5/BW500 is too fast for RXPS even with a 64-symbol preamble, so current firmware selects 128 and uses the qualified level-8 <code>626 / 6398 us</code> timing when every participant supports the adaptive contract.</p>"},{"location":"ota_easy/#before-you-start","title":"Before you start","text":"<p>Both paths require:</p> <ul> <li>A destination artifact explicitly identified by its release table as install-capable. Some lean internal   nRF52 builds carry <code>lora_ota_no_external_sensors</code> in the filename, while matched QSPI boards enable install   support in the normal full-sensor repeater artifact, so filename text alone is not authoritative. Confirm   support with <code>ota self</code> and <code>ota status</code>. Intermediate repeaters do not need an install-capable build:   current repeater firmware relays OTA packets opaquely without storing or installing them.</li> <li>An OTA-enabled MeshCore source connected to the computer by USB serial, or   an ESP32 WiFi companion/FULL source connected over WiFi as described below.</li> <li>Overlapping <code>tempradio</code> windows on the source, destination, and every repeater needed between them.</li> </ul> <p>LoRa OTA packets are generated, consumed, and relayed only while <code>tempradio</code> is active. Intermediate repeaters apply their normal forwarding filters, duplicate checks, and flood limits; they do not interpret the OTA payload. If any required window closes, the transfer stops making progress and can resume during a later overlapping window.</p> <p><code>build.sh</code> provides a <code>*_repeater_lora_ota_no_external_sensors</code> build for standalone ESP32 and nRF52 repeater targets that need a smaller internal update workspace. Those siblings omit selected optional environmental and ranging drivers while retaining board-native features such as displays, buttons, battery monitoring, and GPS where the target uses the GPS-preserving lean profile. RAK3401 and RAK4631 reduced builds also retain INA219, INA226, INA260, and INA3221 I2C voltage/current monitors; together these drivers cost less than 5 KiB in the measured profile. Those four monitor drivers are not the only retained I2C support: the board's SSD1306 OLED, supported autodiscovered RTCs, and the RAK12500 GPS remain separate I2C peripherals in GPS-compatible RAK recipes. RAK12501/L76K GPS instead uses UART Serial1. The RAK3401 OTA repeater supports either GPS module in sensor slot A; slot D conflicts with the RAK13302 radio's BUSY/DIO1 lines. The RAK4631 OTA repeater defaults its runtime RS-232 bridge to Serial2 so the UART RAK12501 can retain Serial1. The runtime guard always reserves Serial1 because a bounded silent probe cannot prove a cold RAK12501 is absent; the shared WB_IO2/3V3_S rail keeps a fitted module powered and driving the UART. Use Serial2. Serial1 requires an explicit no-GPS/dedicated image. The merged image remains fail-closed even when it detects an I2C RAK12500. The explicit legacy Serial1 bridge omits the combined GPS provider, including the otherwise non-UART RAK12500 path.</p> <p>The firmware-configured INA3221 address and the RAK12500 address are both <code>0x42</code>; they cannot coexist on one bus at those addresses. Keep RAK12500 at <code>0x42</code>, strap INA3221 A0 to SCL for <code>0x43</code>, and use a build with <code>-DTELEM_INA3221_ADDRESS=0x43</code> when both are installed.</p> <p>Selected nRF52 boards with matched external QSPI application and bootloader support can instead make the normal full-sensor repeater install-capable; those targets do not need to reserve internal flash for the downloaded container. SolarXiao 30S and 33S use this matched external-QSPI path and therefore do not emit redundant no-external-sensors siblings. A RAK19007 can use the same separately wired W25Q16 with either RAK4631 or RAK3401 + RAK13302: the flash consumes no WisBlock slot and GPS remains supported in slot A. This is not the RAK15001 arrangement; RAK15001 and RAK13302 share a chip-select and cannot be used together. Other normal repeaters can still serve as intermediate relays but cannot necessarily install an update themselves. ESP32 <code>-ota-</code> siblings also retain the lightweight browser WiFi uploader (<code>start ota</code>), the complete CLI, and a 254-entry neighbor table. RP2040 and STM32 repeaters do not currently have a safe self-apply path, but current repeater firmware can still relay OTA packets opaquely during TempRadio.</p> <p>For one explicitly selected internal-flash nRF52 repeater, the default <code>--build-profile auto</code> run emits two install-capable choices. The <code>*-full-ota-*</code> artifact retains external sensors, while the <code>*_lora_ota_no_external_sensors-reduced-ota-*</code> artifact trades only those optional drivers not explicitly retained by the board profile for more delta-staging space. They retain the same OTA target identity so update tooling does not confuse the optimization choice with a different board. QSPI- and SD-backed repeaters emit only the complete choice unless a measured size failure requires a fallback.</p> <p>nRF52 <code>-ota-</code> siblings are compiled with size optimization instead of the Adafruit platform's default speed optimization. This prevents the retained software Ed25519 fallback from expanding beyond the fixed in-place workspace; CC310 hardware crypto, hardware RNG mixing, telemetry history, and board-native features remain enabled.</p> <p>ESP32 <code>*-full-usb-wifi-ota-*</code> artifacts retain all compiled features and enable LoRa OTA for every FULL role, including room servers, sensors, observers, and bridges. A FULL image requires its expanded partition table: install the matching merged image over USB once before installing later non-merged FULL updates over LoRa. ESP32 MQTT observers and ESP-NOW bridges are always emitted as FULL artifacts; compact-CLI variants are no longer built. The <code>*-full-usb-wifi-ota-*</code> profile compiles USB packet logging and direct WiFi MQTT into one image. Use <code>set logging.output off|usb|wifi|both</code> to persist the desired path. A <code>*-full-logging-ota-*</code> artifact is now only a fallback for a hardware/role combination without a WiFi MQTT target and can produce substantial serial output.</p>"},{"location":"ota_easy/#choose-the-source-radio","title":"Choose the source radio","text":"<p>Use an OTA-enabled MeshCore node as the source. It receives the update folder from the computer, then advertises it over LoRa. ESP32 USB/WiFi companions and FULL ESP32 roles include the required transport. A <code>*_companion_radio_full</code> target keeps only the source half of LoRa OTA: it serves host images but cannot stage or install one for itself. ESP32 full combines USB, BLE, and WiFi; nRF52 full combines USB and BLE because nRF52840 has no WiFi. A small set of high-capacity, non-PSRAM classic ESP32 companions keep their normal image and provide a separate <code>-full-logging-ota-</code> fallback with 100 contacts, 8 group channels, a 16-frame offline queue, and persistent USB output selection. Install that variant's merged image over USB once before using it. Connect the source by USB serial or, when supported, by WiFi. For an ordinary raw-text USB source, confirm that its USB CLI accepts:</p> <pre><code>ota folder on\n</code></pre> <p>If an older build reports that <code>OTA_FOLDER_SERIAL</code> is not compiled in, install a current <code>-ota-</code>, <code>-full-usb-wifi-ota-</code>, or applicable <code>-full-logging-ota-</code> build first. Do not use a KISS modem: KISS firmware is a TNC/KISS frame interface and does not provide the MeshCore CLI or the OTA-folder transport that <code>motatool serve</code> requires.</p> <p>An nRF52 <code>companion_radio_full</code> starts in its USB ASCII terminal and automatically changes to Binary Companion when it receives a complete <code>&lt;</code> frame. It also recognizes <code>motatool</code>'s exact initial <code>ota folder on</code> line and enters exclusive mOTA mode directly, so <code>motatool serve --serial</code> can be the first client after boot. No terminal token or preliminary disconnect is required. Stopping the tool or disconnecting resets USB to Binary. BLE remains available throughout. See the Full Companion USB switcher guide for the complete ownership transitions. Protocol v14 can instead take the catalog from a paired phone or Linux host over a separate encrypted BLE mOTA service while Binary Companion remains active. USB and BLE catalog sources are mutually exclusive. See the Full Companion Bluetooth source guide.</p> <p>For an ESP32 WiFi companion or FULL ESP32 source with active WiFi, use its dedicated OTA seeder:</p> <pre><code>motatool serve --dir ./motas --tcp &lt;source-host&gt;:5001 -v\n</code></pre> <p>Port <code>5001</code> is separate from the companion application port (<code>5000</code>) and the HTTP configuration/browser-OTA port (<code>80</code>, depending on the role). An ESP32 <code>companion_radio_full</code> also has its complete role-specific text terminal on port <code>5002</code>; OTA automation uses its <code>ota</code> and TempRadio subset. See the full Companion guide. On a FULL repeater or room server, <code>start webconfig</code> can bring up the saved WiFi connection. Other FULL roles with browser OTA support can raise <code>MeshCore-OTA</code> with <code>start ota</code> and use <code>192.168.4.1:5001</code>. The TCP seeder auto-attaches; do not also run <code>ota folder on</code> for USB serial.</p>"},{"location":"ota_easy/#install-motatool","title":"Install <code>motatool</code>","text":"<p>Install Rust if necessary, then install the standalone packaging and serving tool:</p> <pre><code>git clone https://github.com/vk496/motatool\ncargo install --path ./motatool\n</code></pre>"},{"location":"ota_easy/#esp32-package-a-full-firmware-image","title":"ESP32: package a full firmware image","text":"<p>The destination must be an OTA-capable ESP32 with an A/B partition table. Download or build the new non-merged <code>.bin</code> application for the destination's exact board and role. Do not use an ESP32 <code>-merged.bin</code> factory image.</p> <p>Put the application firmware in a working directory, then build a full <code>.mota</code> container. For example:</p> <pre><code>mkdir -p ./motas\nmotatool build --fw ./Heltec_v3_repeater-ota-v1.16.05.bin --out-dir ./motas\nmotatool verify ./motas/*.mota\n</code></pre> <p>Replace the example filename with the firmware for the destination's exact target. With no <code>--base</code> argument, <code>motatool build</code> creates a full-image update. The firmware must contain its MeshCore <code>EndF</code> identity trailer so <code>motatool</code> and the destination can verify the target, hardware, and version.</p> <p>Do not continue if <code>motatool verify</code> reports a failure.</p>"},{"location":"ota_easy/#nrf52-package-a-full-image-or-in-place-delta","title":"nRF52: package a full image or in-place delta","text":""},{"location":"ota_easy/#1-install-and-check-the-otafix-bootloader","title":"1. Install and check the OTAFIX bootloader","text":"<p>This is a one-time prerequisite. Install the OTAFIX bootloader built for the destination's exact board from the OTAFIX nRF52 bootloader releases. Internal-staging delta updates require OTAFIX 2.4 or newer. External QSPI and SD staging require OTAFIX 2.4.1 or newer and release notes that explicitly list the exact board and storage mode. Follow the release's board-specific installation and erase instructions. If it does not contain the destination's exact board, this LoRa install path is not yet available for that board; never substitute a similar board's bootloader.</p> <p>Before preparing or downloading a LoRa update, run this on the destination:</p> <pre><code>get bootloader.ver\nota self\n</code></pre> <p>The first command identifies the installed nRF52 bootloader. Continue only if the <code>ota self</code> reply includes the apply mode required by this target:</p> <pre><code>bootloader: apply OK\nbootloader: QSPI apply OK\nbootloader: SD apply OK\n</code></pre> <p>The reply also contains the running firmware's <code>base_hash</code>. Save it for the package check below. A stock, legacy, or older OTAFIX bootloader without <code>.mota</code> in-place-apply support will report that apply support is missing, and <code>ota install</code> will refuse to reboot into it.</p>"},{"location":"ota_easy/#2-choose-full-or-delta-packaging","title":"2. Choose full or delta packaging","text":"<p>For a QSPI- or SD-backed target, a full update needs only the new raw <code>firmware.hex</code>:</p> <pre><code>mkdir -p ./motas\nmotatool build --fw ./LilyGo_T-Echo_repeater-new.hex --out-dir ./motas\nmotatool verify ./motas/*.mota\n</code></pre> <p>Use a full package when an exact base image is unavailable. Use the delta path below when reducing airtime is worth retaining the exact running image.</p>"},{"location":"ota_easy/#3-keep-the-exact-current-and-new-application-images-for-a-delta","title":"3. Keep the exact current and new application images for a delta","text":"<p>You need the raw <code>.pio/build/&lt;environment&gt;/firmware.hex</code> from the build that is actually running, plus the corresponding <code>firmware.hex</code> from the new build. Save the current file before building the new version, because PlatformIO reuses that path. For example:</p> <pre><code># Save this immediately after building/flashing the version now running on the node.\ncp .pio/build/Heltec_t114_repeater_lora_ota_no_external_sensors/firmware.hex \\\n  ./Heltec_t114_repeater_lora_ota_no_external_sensors-running.hex\n\n# After checking out and building the new version, save its image separately.\ncp .pio/build/Heltec_t114_repeater_lora_ota_no_external_sensors/firmware.hex \\\n  ./Heltec_t114_repeater_lora_ota_no_external_sensors-new.hex\n</code></pre> <p>Replace <code>Heltec_t114_repeater_lora_ota_no_external_sensors</code> with the destination's exact PlatformIO environment. The two images must be for the same board and role, and both must contain their <code>EndF</code> trailers. Do not pass a release <code>.uf2</code> or BLE-DFU <code>.zip</code> to <code>motatool</code>; those are installation containers rather than raw application images.</p> <p>Keeping a file with the same version label is not enough: the base must be byte-for-byte identical to the running application. The hash check in the next step proves that it is the right file.</p> <p>On RAK4631 repeaters, use the <code>RAK_4631_repeater_lora_ota_no_external_sensors</code> environment. It retains built-in battery monitoring but omits selected optional environmental/ranging drivers so the delta fits the safe in-place workspace. INA219, INA226, INA260, and INA3221 I2C voltage/current monitors remain supported despite the legacy target name. That trim does not remove the SSD1306 OLED, autodiscovered I2C RTCs, or GPS-compatible RAK12500 I2C path. The <code>0x42</code> RAK12500/INA3221 addressing rule above still applies. If the device has a RAK15001 installed in sensor slot C and the matching RAK15001 OTAFIX bootloader, use <code>RAK_4631_repeater_rak15001_slot_c_lora_ota</code> instead. That target retains the full sensor/GPS set and can install either a full image or a delta from the external 2 MiB store.</p> <p>With the separately wired Winbond breakout, use <code>RAK_4631_repeater_w25q16_lora_ota</code> for RAK4631 or <code>RAK_3401_repeater_rak13302_w25q16_lora_ota</code> for RAK3401 + RAK13302. Both require an <code>EF4015</code> 2 MiB device. As a one-time prerequisite, install <code>wiscore_rak4631_w25q16</code> for RAK4631 or <code>wiscore_rak3401_rak13302_w25q16</code> for RAK3401 + RAK13302. Wire CLK/MISO/MOSI to the RAK19007 IO connector pins 26/27/28, CS to J11 AIN1, and VCC/GND to J12 VDD/GND. Fit an approximately 10 kOhm CS-to-VDD pull-up; never use VBAT. The SPI pins require underside taps or an interposer, but no sensor slot is occupied. See the nRF52 QSPI guide before installing either image.</p>"},{"location":"ota_easy/#4-build-and-check-the-in-place-delta","title":"4. Build and check the in-place delta","text":"<pre><code>mkdir -p ./motas\nmotatool build \\\n  --base ./Heltec_t114_repeater_lora_ota_no_external_sensors-running.hex \\\n  --fw ./Heltec_t114_repeater_lora_ota_no_external_sensors-new.hex \\\n  --patch-type in-place \\\n  --out-dir ./motas\nmotatool verify ./motas/*.mota\n</code></pre> <p><code>motatool</code> prints the generated filename. Inspect that file:</p> <pre><code>motatool inspect ./motas/GENERATED_FILENAME.mota\n</code></pre> <p>Check all three of these before serving it:</p> <ul> <li><code>codec_id</code> is <code>2 (detools-in-place)</code>.</li> <li><code>base_hash</code> is the same 8-byte value reported by the destination's <code>ota self</code> command.</li> <li>The numeric <code>target_id</code> exactly matches <code>target:</code> in the destination's <code>ota status</code>, and the hardware and   firmware version identify the intended board and role. If <code>inspect</code> shows <code>N/A</code> for the human-readable   target name, the tool's name table is older than that environment; the numeric IDs still must match.</li> </ul> <p>Current layout-aware <code>motatool</code> derives the safe workspace from the new firmware's authenticated EndF layout record, so the normal recipe deliberately omits <code>--inplace-memory</code>. If older tooling requires an explicit override, use <code>0xC6000</code> only for matched external SD/QSPI staging and <code>0x98000</code> for an internal-staging nRF52 such as the RAK4631 lean OTA build. Do not substitute the external value on an internal target, and do not override either value unless you have verified the exact app base, bootloader, and package geometry. Do not continue if verification or any identity check fails.</p>"},{"location":"ota_easy/#transfer-and-install-either-package","title":"Transfer and install either package","text":""},{"location":"ota_easy/#1-start-the-temporary-ota-channel","title":"1. Start the temporary OTA channel","text":"<p>First save the current <code>ota config</code> output. For a direct source-to-destination link, set both OTA-enabled endpoints to direct-only mode before starting the transfer:</p> <pre><code>ota config hops 0\n</code></pre> <p>Do not use <code>hops 1</code> as extra margin on a direct link. It tells a receiving repeater to retransmit each direct DATA/PROOF packet; that unnecessary half-duplex transmission can make it miss the source's next fragment, especially with older single-block receivers. Use <code>hops 1</code> only when one real intermediate relay is required, <code>hops 2</code> for two, and so on. This setting is saved, so restore the original value after the maintenance window.</p> <p>On the source node, destination node, and every intermediate repeater, then run:</p> <pre><code>tempradio 909.950,250,5,5,120\n</code></pre> <p>All participating nodes must use the same frequency, bandwidth, and spreading factor. Their time windows must overlap. Start with the farthest hop (the destination) and work back toward the source when using <code>tempradio</code>.</p> <p>If you administer the destination over LoRa, the controller used to send later <code>ota</code> commands must also be able to communicate on this temporary channel. For unattended nodes, use synchronized <code>tempradioat</code> entries instead of manually starting the windows. Ensure the nodes' clocks are set before using <code>tempradioat</code>.</p>"},{"location":"ota_easy/#2-serve-the-update-from-the-computer","title":"2. Serve the update from the computer","text":"<p>Close any serial terminal using the source node's USB port, find its device name, and start the server:</p> <pre><code>motatool serve --dir ./motas --serial /dev/ttyACM0 -v\n</code></pre> <p>Replace <code>/dev/ttyACM0</code> with the USB serial device of the source companion selected above. <code>motatool</code> attaches the folder to the source, which advertises the update over LoRa while its temporary-radio window is active. KISS modem serial ports cannot be used here.</p> <p>For an nRF52 Full Companion and a Bluetooth-capable host, the equivalent cable-free source is:</p> <pre><code>python3 tools/ble_mota/ble_mota_seeder.py \\\n  --device MeshCore-MyCompanion \\\n  --dir ./motas \\\n  --local 'tempradio 909.950,250,5,5,120'\n</code></pre> <p>Leave this command running until the destination finishes downloading.</p>"},{"location":"ota_easy/#3-find-and-download-the-update","title":"3. Find and download the update","text":"<p>On the destination node, check its state and ask for nearby updates:</p> <pre><code>ota status\nota ls\n</code></pre> <p>Discovery is asynchronous. <code>ota ls</code> says <code>refreshing</code>; wait a few seconds and run it again even if it first shows an older row. Select <code>[same target]</code>: it can say <code>full</code> for ESP32 and external SD/QSPI nRF52 targets, or <code>delta</code> for any supported nRF52 target. Do not select <code>[unsupported]</code> (for example, a source's self-served full image on an internal-staging nRF52). Rows labelled <code>bootloader</code> are also outside this ordinary application flow: they are never automatic and <code>ota install</code> refuses them. Only an already-capable, allowlisted internal-flash, XIAO-QSPI, or exact MeshTower V2 microSD nRF52 target can use the separate explicit bootloader workflow. Use the row's stable eight-hex manifest ID rather than its changing list position:</p> <pre><code>ota pull 838B8169 flash\n</code></pre> <p>If a legacy internal-flash nRF52 reports <code>no EndF</code>, only a row marked <code>[rescue]</code> is eligible. Current rescue-capable firmware requires <code>ota pull &lt;mid8&gt; flash rescue</code>, followed after completion by <code>ota rescue install &lt;base_hash16&gt;</code>. Older running firmware without those commands must be recovered over USB. Shared-internal bootloader-update builds are stricter: without a valid live <code>EndF</code>, every internal pull is refused before erase because the normal application may extend through <code>0xED000</code>. Recover those builds over USB/BLE DFU or SWD instead of relying on the older 608 KiB rescue estimate.</p> <p>Monitor the transfer:</p> <pre><code>ota status\n</code></pre> <p>For a powered bench update where restart-resume is not needed, <code>ota config checkpoint 0</code> on the destination removes periodic progress writes. It is a smaller optimization than selecting the correct hop count and it trades away persisted mid-download resume; restore the previous checkpoint cadence afterward.</p> <p>Current repeater firmware automatically uses the full transmit budget during a bounded TempRadio window. Older receivers do not: if <code>get af</code> reports a nonzero value on such a node, record it, use <code>set af 0</code> for the maintenance window, and restore it afterward. This affects how promptly the legacy receiver can send its next block/proof request; it does not increase LoRa transmit power. Use a full duty budget only where the selected frequency and local rules permit it.</p> <p>The update is ready when the status says <code>ready to install</code>. Discovery is background traffic, while an active OTA download is primary mesh traffic. At the temporary-radio settings in this guide, allow roughly one hour for a typical ESP32 full image over a quiet, direct link. That is a planning estimate, not an upper bound: repeaters, retries, weak links, and normal mesh traffic can extend it well past an hour. The 120-minute example window is intentional. If necessary, start another overlapping <code>tempradio</code> window; the download resumes rather than starting over.</p>"},{"location":"ota_easy/#4-verify-and-install","title":"4. Verify and install","text":"<p>Once the destination reports <code>ready to install</code>, run:</p> <pre><code>ota install\n</code></pre> <p>The destination verifies the complete package again before approving it. ESP32 installs the full image into its inactive A/B slot. nRF52 checks the bootloader and storage capabilities and, for a delta, the base hash, then reboots into OTAFIX. The bootloader independently rechecks the package, installs the external full image or applies the delta in place, and verifies the resulting image. Pre-install failures leave the running firmware unchanged and report the reason. If power is lost after an nRF52 in-place apply has begun, OTAFIX will not boot a partial image; it enters recovery DFU so a known-good application can be restored.</p> <p>After the node returns, reconnect on its normal radio channel and confirm:</p> <pre><code>ota status\n</code></pre>"},{"location":"ota_easy/#quick-troubleshooting","title":"Quick troubleshooting","text":"<ul> <li>Nothing appears in <code>ota ls</code>: confirm that <code>motatool serve</code> is still running and every required node   has an active <code>tempradio 909.950,250,5,5,120</code> window.</li> <li>The CLI says LoRa OTA is not included: that firmware does not contain the LoRa OTA feature.   If it is the source or destination, install a supported <code>-ota-</code> build over WiFi or USB first. An intermediate   repeater does not need the OTA CLI and can relay opaquely while its matching <code>tempradio</code> window is active.</li> <li>The update shows another environment or a raw <code>[hw XXXXXXXX]</code>: it is for a different board or firmware   role. Do not install it.</li> <li>An internal-flash nRF52 marks a full update <code>[unsupported]</code>: it can install only an in-place delta.   A matched QSPI repeater or MeshTower V2 microSD target accepts full images with its corresponding bootloader.</li> <li>A QSPI nRF52 reports <code>QSPI store:ERR 0K</code> or <code>bl:NO-QSPI</code>: do not download an install package. Install   the exact QSPI-aware bootloader and check that the selected application matches the board's flash wiring.   A RAK W25Q16 target must identify exactly <code>EF4015</code> and 2048K; also check its physical CS pull-up.</li> <li>nRF52 reports no bootloader apply support: install the exact-board in-place-delta OTAFIX bootloader   before trying LoRa OTA.</li> <li>nRF52 reports a base mismatch: the file passed to <code>--base</code> is not the exact application running on   the destination. Rebuild the delta from the correct saved <code>firmware.hex</code>.</li> <li>The download stalls: check the source, destination, and intermediate repeaters. Restart matching,   overlapping temporary-radio windows if one expired. On a direct link, also require <code>ota config hops 0</code>;   a larger reach makes a repeater destination unnecessarily echo source packets.</li> <li>The serial port is busy: close the serial terminal before starting <code>motatool serve</code>.</li> <li>The destination rejects the package: verify the source files, their <code>EndF</code> trailers, the package's   target/hardware identity, and the result of <code>motatool verify</code>.</li> </ul> <p>For additional commands and safety details, see the full OTA user guide. For protocol and container internals, see the OTA protocol specification.</p>"},{"location":"ota_meshtower_v2_sdcard/","title":"MeshTower V2 microSD LoRa OTA","text":"<p>The <code>Heltec_tower_v2_sdcard_repeater_lora_ota_no_external_sensors</code> target uses the MeshTower V2 onboard microSD socket as persistent storage for its own LoRa OTA downloads. It accepts full application images, in-place application deltas, and explicitly selected signed v3 bootloader packages. After verification, the matching SD-aware OTAFIX bootloader reads the staged file from the card and programs the selected nRF52840 application or bootloader region.</p> <p>The pin assignment follows the Heltec MeshTower V2 partial reference circuit:</p> Signal nRF52840 pin Arduino pin number SD CS P1.00 32 SD MOSI P1.01 33 SD SCK P0.06 6 SD MISO P0.26 26 <p>The SD socket uses its own SPI peripheral, so card traffic does not change the LoRa radio pinout.</p>"},{"location":"ota_meshtower_v2_sdcard/#card-requirements","title":"Card requirements","text":"<p>Use a FAT16, FAT32, or exFAT card accepted by the bundled SdFat version. The normal update path imposes no additional MBR/sector-1 layout requirement; filesystem layouts SdFat cannot mount are still rejected. MeshCore creates <code>/meshcore-ota.mota</code> as a contiguous file and passes its exact sector range to OTAFIX in reset-retained MCU RAM.</p> <p>MeshCore never reads or writes raw sector 1 and does not infer ownership from blank card sectors. Both application and bootloader OTA require a locally provisioned BLM2-capable bootloader that understands the retained-RAM record. Preview.12 must first be upgraded over USB/BLE DFU or SWD.</p>"},{"location":"ota_meshtower_v2_sdcard/#capacity-and-update-types","title":"Capacity and update types","text":"<p>The card removes the internal-flash staging limit. The <code>.mota</code> container may be much larger than the old internal staging gap, and either a full image or an in-place delta may be downloaded. The installed firmware itself must still fit the nRF52840 application region below InternalFS (ending at <code>0xED000</code>); SD storage does not increase the MCU's executable flash.</p> <p>For this S140 v6 target, the maximum application image including its <code>EndF</code> trailer is <code>0xC7000</code> bytes (815,104 bytes). To package a full self-update:</p> <pre><code>motatool build --fw ./Heltec_tower_v2_sdcard-new.hex \\\n  --sign ./trusted-signer.key --out-dir ./motas\nmotatool verify ./motas/*.mota\n</code></pre> <p>A delta uses the exact installed image as its base. The normal <code>0x98000</code> workspace remains compatible. If either image is larger than that legacy limit, build the patch with the SD target's larger workspace:</p> <pre><code>motatool build \\\n  --base ./Heltec_tower_v2_sdcard-running.hex \\\n  --fw ./Heltec_tower_v2_sdcard-new.hex \\\n  --patch-type in-place \\\n  --inplace-memory 0xC7000 \\\n  --sign ./trusted-signer.key \\\n  --out-dir ./motas\nmotatool verify ./motas/*.mota\n</code></pre> <p>The download is resumable because the partial <code>.mota</code> stays on the card. Once it reaches <code>ready</code>, <code>ota install</code> performs the final verification, publishes a one-reset authorization record, and reboots. SD application installation requires a valid signature from a key in the node's allowlist. Keep the card inserted through the reboot and installation.</p> <p>The BLM2 retained-auth SD-aware bootloader is mandatory for application OTA. <code>ota install</code> refuses to reboot if its continuity metadata does not match the running S140 family/FWID/application layout or if its capability marker does not advertise SD staging and the selected codec. Existing <code>Heltec_tower_v2_repeater</code> firmware continues to use the internal-flash delta path and is unchanged.</p>"},{"location":"ota_meshtower_v2_sdcard/#signed-bootloader-update","title":"Signed bootloader update","text":"<p>Only this exact SD build exposes the privileged LoRa bootloader-update command. It requires an already installed exact-board ABI-3 OTAFIX bootloader whose one unambiguous capability marker is exactly <code>0x09</code> (<code>SD|BOOT_UPDATE</code>) and whose codec mask is <code>0x0005</code> (<code>FULL|INPLACE</code>). Requiring both application codecs prevents a bootloader self-update from disabling either normal SD application path. A stock bootloader still requires USB/BLE DFU or SWD. The sole remote bootstrap is intentionally absent: preview.12 and any other legacy-v1 image must be upgraded locally before either SD application or bootloader OTA.</p> <p>The signed v3 container is exactly 41,330 bytes and carries a 40 KiB candidate for the installed <code>239A0071 / TOWER_V2_OTA</code> identity (boot target <code>1150F50E</code>). It uses the same contiguous <code>/meshcore-ota.mota</code> file as an application update. GPREGRET <code>0x6B</code> plus the distinct SD source marker <code>0x53</code> selects the bootloader path; LoRa transport remains payload type <code>0x0C</code>.</p> <p>The application linker still ends at <code>0xED000</code>, but OTAFIX needs <code>0xE0000..0xEA000</code> as temporary scratch while replacing itself. Before a boot package can be downloaded or approved, MeshCore requires a hash-valid live <code>EndF</code> proving the complete running image ends by <code>0xE0000</code>; OTAFIX repeats that no-overlap check before its first erase. An application extending above that boundary can still receive normal FULL or delta application updates from SD, but its bootloader must be updated locally.</p> <p>MeshCore also checks the live boot settings before touching that scratch page. Erased settings and a valid-app record with CRC disabled are allowed. When a nonzero bank CRC is active, its recorded <code>bank_0_size</code> must cover the complete EndF-inclusive running image and must end by <code>0xE0000</code>; an undersized or oversized record refuses the operation and requires local DFU/SWD.</p> <p>Because the card is removable, approval is bound to the exact bytes that were authenticated. For both fmt2 application and fmt3 bootloader packages, MeshCore authenticates one exact signed manifest, requires every streamed manifest byte to match it, and verifies the leaves, payload, and image. During that same pass it hashes the entire container with only the mutable four-byte <code>APRV</code> field normalized to zero. After writing and syncing <code>APRV</code>, MeshCore publishes a 72-byte <code>MOTASDA2</code> record at reset-retained RAM address <code>0x20006008</code>. The record binds package purpose/format, exact LBA range, card size, container length, and that normalized SHA-256. OTAFIX consumes and clears the record before reading the card; changing the card or file can only fail. A power loss erases the authorization and also fails closed.</p> <p>For fmt3, MeshCore additionally writes and readback-verifies the temporary 64-byte <code>MOTASDBL</code> token at <code>0xE0000</code>, binding the exact total and signed manifest <code>image_hash</code>. OTAFIX requires the parsed manifest, streamed payload, and final scratch image to match it. The token page becomes scratch during a successful boot update and is not permanently reserved.</p> <p>Every new candidate also carries a backward-compatible <code>BLM2</code>/<code>SOFT</code> continuity extension next to its legacy embedded manifest. The complete 76-byte envelope is fixed at final raw-image offset <code>0x9FB4</code>; a relocated copy is not a valid candidate. Its embedded bootloader version must equal the outer package version, match the runtime SoftDevice family/FWID, application base, and layout ABI, and be strictly newer than an installed BLM2 version. Preview values use low bytes <code>1..254</code> and a stable release uses <code>0xFF</code>; zero-preview and all-ones versions are invalid. Remote bootloader rollback is not supported; use local DFU/SWD when rollback or migration is intentional.</p> <p>Bootloader packages are never autofetched or autoinstalled. Select and confirm one exact package manually:</p> <pre><code>ota ls\nota pull &lt;MID8&gt; flash\n# wait for ota status to report the bootloader download ready\nota bootloader\nota bootloader install &lt;MID8&gt; &lt;HASH16&gt;\n</code></pre> <p>Copy the MID and first 16 image-hash hex digits from <code>ota bootloader</code>. Ordinary <code>ota install</code> rejects this package, and the bootloader command rejects an application package. Keep the SD card inserted through the reboot. A later <code>ota status</code> value of <code>blup:C8</code> reports a successful bootloader replacement.</p>"},{"location":"ota_meshtower_v2_sdcard/#sd-card-cli","title":"SD card CLI","text":"<p>The SD-backed target provides these CLI commands:</p> <pre><code>set sdcard format [--force]\nset sdcard erase [--force]\nget sdcard\nget sdcard *\nget sdcard format\nget sdcard erase\nget sdcard free\nget sdcard ls\nget sdcard ls 2\nget sdcard dir 3\n</code></pre> <p><code>format</code> creates a new FAT16, FAT32, or exFAT filesystem according to card size. <code>erase</code> first uses the card's raw media erase command and then formats it, so a successful erase finishes with a usable filesystem. Both operations destroy all data on the card and cancel any staged OTA download.</p> <p>The firmware records successful format and erase completion times in RAM. Repeating the same operation within five minutes is rejected unless <code>--force</code> is present. Format and erase have independent cooldowns. Because erase also formats the card, a successful erase updates both timestamps. The timestamps reset when the device reboots. The <code>get sdcard</code> age queries report how long ago each operation completed. <code>get sdcard free</code> reports used and free filesystem space in human-readable binary units.</p> <p><code>get sdcard ls</code> and <code>get sdcard dir</code> recursively list files on the card, two files per page. A bare command shows page 1; append a positive page number to move through the remaining results. Each row includes the path and a compact file size. The header reports the selected page, total pages, and total files.</p>"},{"location":"ota_meshtower_v2_sdcard/#persistent-ota-archive-and-seeder","title":"Persistent OTA archive and seeder","text":"<p>On the SD-backed target, automatic OTA archiving is on by default. While the temporary OTA radio is active, the node requests full catalogs from seeders and saves every complete mOTA it discovers, including firmware for other hardware targets and codecs that this node cannot install. Archive downloads use the same per-block Merkle proof checks as an install download, but archived images are never selected for local installation.</p> <p>Completed containers are stored as <code>/mota/&lt;manifest-id&gt;.mota</code>. An interrupted download remains <code>/mota/&lt;manifest-id&gt;.part</code> and resumes when that mOTA is seen again. Completed files survive reboot, are enumerated on the first archive access or TempRadio window, and are advertised and served directly from SD. The SD target supports the protocol maximum served set: its own running firmware plus up to 254 archived mOTAs.</p> <p>Automatic capture preserves an 8 MiB free-space reserve for manual <code>/meshcore-ota.mota</code> installation staging. It stops starting new archive files when the next file would cross that reserve. Archive allocation first tries the fast contiguous path and then falls back to an ordinary fragmented FAT file; only the bootloader staging file requires contiguous sectors.</p>"},{"location":"ota_meshtower_v2_sdcard/#preload-many-motas-from-a-computer","title":"Preload many mOTAs from a computer","text":"<p>You can populate the archive much faster on a computer than over LoRa. Use only complete, verified <code>.mota</code> containers. Do not copy firmware <code>.bin</code>, <code>.hex</code>, <code>.zip</code>, or <code>.part</code> files into the archive.</p> <p>Install the standalone <code>motatool</code> first if it is not already available:</p> <pre><code>git clone https://github.com/vk496/motatool.git\ncargo install --path ./motatool\n</code></pre> <p>The on-card filename is part of the archive index and has a strict format:</p> <pre><code>/mota/&lt;merkle_root&gt;.mota\n</code></pre> <p><code>&lt;merkle_root&gt;</code> is the eight-hex-digit value printed by <code>motatool inspect</code>. It is also the mOTA's four-byte manifest ID. The extension must be lowercase, the file must be directly inside <code>/mota</code>, and descriptive release filenames are not indexed. For example, if inspection reports:</p> <pre><code>merkle_root    : ABCD1234\n</code></pre> <p>copy that container to:</p> <pre><code>/mota/abcd1234.mota\n</code></pre> <p>If two containers have the same Merkle root, they have the same protocol ID and cannot both be present. Keep only the intended one. The current SD seeder can index up to 254 archived files. A served file must use a logical block size of at most 1024 bytes and contain at most 2048 blocks; check <code>block_size</code> and <code>block_count</code> in <code>motatool inspect</code> when importing unusually large images. Files outside that serve geometry are not counted or advertised. If a malformed <code>/mota/&lt;id&gt;.mota</code> conflicts with a newly discovered valid image, the repeater preserves the malformed file as <code>&lt;id&gt;.bad</code> through <code>&lt;id&gt;.bad9</code> and downloads a clean replacement instead of treating path existence as a valid cache hit.</p> <p>To prepare and load the card:</p> <ol> <li>Format it as described under Card requirements. The    easiest route is to insert it in the repeater, run <code>set sdcard format</code>, power    the repeater off, and then move the card to the computer. Formatting destroys    the existing card contents.</li> <li>Mount the card on the computer and create a directory named <code>mota</code> at the    filesystem root. Do not use a nested directory such as <code>/firmware/mota</code>.</li> <li>Run <code>motatool verify FILE.mota</code> for every source file. Do not copy a file    that reports <code>FAIL</code>.</li> <li>Run <code>motatool inspect FILE.mota</code>, read its <code>merkle_root</code>, and copy the file    to <code>/mota/&lt;lowercase-merkle-root&gt;.mota</code> on the card.</li> <li>Flush pending writes, safely eject the card, power the repeater off, insert    the card, and boot    <code>Heltec_tower_v2_sdcard_repeater_lora_ota_no_external_sensors</code>.</li> </ol> <p>On Linux or macOS, this Bash example verifies and imports every <code>.mota</code> from <code>./motas</code>. Replace the example mount path before running it:</p> <pre><code>card_mount=/media/YOU/MESHCORE\nmkdir -p \"$card_mount/mota\"\n\nshopt -s nullglob\nfor image in ./motas/*.mota; do\n  motatool verify \"$image\" || exit 1\n  mid=$(motatool inspect \"$image\" |\n    awk '$1 == \"merkle_root\" { print tolower($3) }')\n  if [[ ! $mid =~ ^[0-9a-f]{8}$ ]]; then\n    echo \"Could not read the Merkle root from: $image\" &gt;&amp;2\n    exit 1\n  fi\n\n  destination=\"$card_mount/mota/$mid.mota\"\n  if [[ -e $destination ]]; then\n    cmp -s \"$image\" \"$destination\" || {\n      echo \"Different containers have the same ID: $mid\" &gt;&amp;2\n      exit 1\n    }\n  else\n    cp \"$image\" \"$destination\"\n  fi\ndone\nsync\n</code></pre> <p>On Windows, create <code>E:\\mota</code>, inspect each source with <code>motatool inspect</code>, and rename it to the reported lowercase root in the same way. Safely eject the drive after all copies finish.</p> <p>After boot, scan the archive and confirm the card contents from the repeater console:</p> <pre><code>get sdcard ls\nget sdcard ls 2\nota cache\nota folder\n</code></pre> <p><code>ota cache</code> should report the imported count. <code>ota folder</code> reports the current served count; once OTA serving starts in TempRadio, that set also includes the repeater's running firmware. If the files appear in <code>get sdcard ls</code> but not in the served count, check their exact names, run <code>motatool verify</code> again, and inspect their block geometry. It is fine to run <code>ota cache off</code> for a curated, read-mostly archive: that disables capture of new mOTAs but continues serving every valid file already on the card.</p>"},{"location":"ota_meshtower_v2_sdcard/#serve-the-preloaded-archive-over-tempradio","title":"Serve the preloaded archive over TempRadio","text":"<p>LoRa OTA traffic exists only during an active temporary-radio window. The SD repeater, each receiving node, and every intermediate repeater in the path need overlapping windows on the same temporary channel. Use a frequency permitted for the node's configured region. This North American example uses the recommended fast OTA settings and a 120-minute window:</p> <pre><code>tempradio 909.950,250,5,5,120\n</code></pre> <p>Start the farthest receiving node first, then intermediate repeaters, and the SD source last so their windows overlap for as long as possible. Before or during the source window, <code>ota cache</code> makes the source scan and attach the SD archive. Entry into TempRadio automatically triggers an OTA advertisement burst; <code>ota announce</code> can send another advertisement immediately.</p> <p>On a receiving OTA-capable node, allow a few seconds for catalog exchange, then run:</p> <pre><code>ota ls\nota ls 2\nota get &lt;mid8&gt; flash\nota status\n</code></pre> <p>Use <code>ota ls 2</code>, <code>ota ls 3</code>, and so on when the source advertises more than the two rows that fit in one remote CLI reply. Each row includes a stable eight-hex-digit manifest ID. Use that ID instead of a list number, because asynchronous catalog refreshes can reorder rows between the list and pull commands. A receiver retains the complete protocol catalog and verifies every transferred block. It still applies its normal target, hardware, codec, signature, and installation checks. The SD repeater may advertise images for many hardware families; it never installs those archive files merely because it serves them.</p> <p>When a temporary window expires or a node reboots, it returns to its saved radio settings and OTA transfer stops. The archive remains on the card. Start another set of overlapping <code>tempradio</code> windows to resume an interrupted download, or use synchronized <code>tempradioat</code> entries for a scheduled window.</p> <p>Archive capture is lower priority than operator work. An explicit <code>ota pull</code> to install storage or a host folder immediately takes the single receive slot; the archive partial is checkpointed and resumes later. Existing cached files can still answer peer requests while another archive file is downloading.</p> <p>Use these commands to inspect or control automatic capture:</p> <pre><code>ota cache\nota cache on\nota cache off\nota config cache on\nota config cache off\n</code></pre> <p>The on/off choice is saved on the SD card. Turning capture off stops new downloads but keeps serving files already cached. Formatting or erasing the card removes both the archive and its off marker, so a newly formatted card returns to the default-on setting. <code>ota config sdseed on|off</code> is also accepted as an alias.</p>"},{"location":"ota_nrf52_bootloader_update/","title":"nRF52 bootloader updates over LoRa","text":"<p>Selected nRF52840 repeater LoRa-OTA builds can replace their matching OTAFIX bootloader without replacing the running application. This is a privileged maintenance path, not a normal firmware update. A stock bootloader must first be replaced with the exact ABI-3 self-update-capable OTAFIX build over USB/BLE DFU or SWD. MeshTower SD also requires the BLM2 retained-auth version to be provisioned locally before either application or bootloader OTA.</p>"},{"location":"ota_nrf52_bootloader_update/#storage-layouts","title":"Storage layouts","text":"Layout Application limit Staged boot package Work area Handoff / capability XIAO-module raw QSPI below <code>0xE0000</code> external QSPI offset 0 dedicated internal <code>0xE0000..0xEA000</code> scratch source <code>0x51</code>, flags <code>0x0E</code> Qualified internal-flash target normal <code>0xED000</code> limit shared internal slot, exact start <code>0xE2000</code> the same eleven-page slot; no second reservation source <code>0xED</code>, flags <code>0x0A</code> MeshTower V2 microSD normal <code>0xED000</code> limit contiguous <code>/meshcore-ota.mota</code> dynamic internal <code>0xE0000..0xEA000</code> scratch; live image must end by <code>0xE0000</code> source <code>0x53</code>, flags <code>0x09</code> <p>The exact SD target is <code>Heltec_tower_v2_sdcard_repeater_lora_ota_no_external_sensors</code>. Its normal application FULL and delta updates continue to use the SD file without the bootloader-update scratch restriction. For a bootloader package only, both MeshCore and OTAFIX require a hash-valid live <code>EndF</code> proving the complete running image ends at or below <code>0xE0000</code>. If boot settings carry a nonzero app bank CRC, the recorded bank size must also cover that full EndF-inclusive image and stop by <code>0xE0000</code>; erased or explicitly CRC-disabled settings remain valid. OTAFIX then copies the verified 40 KiB payload from SD into <code>0xE0000..0xEA000</code> and uses the MBR copy operation to replace <code>0xF4000..0xFE000</code>. The application linker remains at <code>0xED000</code>; a future application extending above <code>0xE0000</code> can still use application mOTA but must update its bootloader through local DFU/SWD.</p> <p>The removable SD authorization is fail-closed for both application and bootloader packages. MeshCore directly authenticates one exact signed manifest, requires the streamed copy to remain byte-identical, verifies all leaves/payload/image bytes, and computes a normalized full-container SHA-256 in that same pass (<code>APRV</code> bytes are treated as zero). After syncing <code>APRV</code>, it publishes a 72-byte <code>MOTASDA2</code> record in reset-retained RAM at <code>0x20006008</code>. That record binds purpose/format, first LBA, sector count, total length, card sector count, and the normalized digest. OTAFIX copies, validates, and clears the record before SD access. A card swap/mutation or a power cycle therefore fails closed; there is no general sector-1 ownership inference.</p> <p>For fmt3, MeshCore also writes and readback-verifies a 64-byte <code>MOTASDBL</code> token at <code>0xE0000</code>. That token contains the exact container length and the exact authenticated signed manifest <code>image_hash</code>. OTAFIX requires the same hash in the parsed manifest, streamed payload, and final scratch image. The page is consumed as scratch during success and is not permanently reserved.</p> <p>The first BLM2-capable MeshTower bootloader cannot be delivered to preview.12 through the retained-RAM protocol that preview.12 predates. MeshCore does not write a raw-sector compatibility record because a blank sector is not proof of ownership. Upgrade preview.12 through USB/BLE DFU or SWD. Both fmt2 application and fmt3 bootloader OTA then require the installed BLM2 metadata to match the live SoftDevice/application layout; neither MeshCore nor OTAFIX uses sector 1.</p> <p>The internal path does not change the application linker or permanently set aside separate app-OTA, boot-package, and scratch regions. The ordinary bottom-aligned internal store holds one container at a time: either an application delta or a bootloader package.</p> <p>The exact bootloader container is 41,330 bytes: 365 bytes of signed mOTA metadata, a 40 KiB payload, and the five-byte trailer. Below the normal <code>0xED000</code> store ceiling it bottom-aligns at <code>0xE2000</code>. Admission requires a hash-valid live <code>EndF</code> proving the current application, including its trailer, ends at or before <code>0xE2000</code>. OTAFIX then reads each source window before erasing and compacts the payload forward in place to the page-aligned raw range <code>0xE2000..0xEC000</code>; it verifies every page and the whole image before asking the MBR to copy that image over <code>0xF4000..0xFE000</code>.</p> <p>An ordinary application delta can be smaller or larger than this eleven-page shape. It bottom-aligns dynamically below <code>0xED000</code> and may begin below <code>0xE2000</code>; its detools workspace must stop at its actual container start, while the reconstructed application must stop below <code>0xED000</code>. The two package kinds are mutually exclusive because they use the same store.</p> <p>For internal-self-update builds, an absent or corrupt live <code>EndF</code> disables all internal staging before the first erase. The older 608 KiB rescue estimate is unsafe when a normally linked application may extend to <code>0xED000</code>. Builds without this feature retain the legacy rescue behavior.</p>"},{"location":"ota_nrf52_bootloader_update/#internal-flash-target-inventory","title":"Internal-flash target inventory","text":"<p>The release builder consumes the allowlist in <code>tools/mota/nrf52_internal_bootloader_targets.txt</code>. Ten names are also literal PlatformIO environments and are enabled automatically when built directly. The other eleven are release aliases assembled from a base environment plus the lean OTA overlay; build them through <code>build.sh</code>, which passes the same allowlist decision to the common pre-build guard. These lean repeater/bridge targets have no OTA-owned SD/QSPI store and have an exact curated OTAFIX manifest identity:</p> Build target(s) Installed OTAFIX identity Boot target ID <code>Heltec_tower_v2_repeater_lora_ota_no_external_sensors</code> <code>239A0071 / TOWER_V2_OTA</code> <code>1150F50E</code> T096 lean repeater and RS232 bridge <code>239A0071 / T096_DFU</code> <code>42354C85</code> <code>Heltec_t1_repeater_lora_ota_no_external_sensors</code> <code>239A0071 / T1_DFU</code> <code>FC556FFC</code> T114 display and without-display lean repeaters <code>239A0071 / T114_DFU</code> <code>0C3F2902</code> <code>Mesh_pocket_repeater_lora_ota_no_external_sensors</code> <code>239A0071 / MESH_POCKET_OTA</code> <code>059277F4</code> <code>KeepteenLT1_repeater_lora_ota_no_external_sensors</code> <code>239A00B3 / KeepteenLT1_OTA</code> <code>DB2E7B51</code> <code>Minewsemi_me25ls01_repeater_lora_ota_no_external_sensors</code> <code>239A0029 / MX25_DFU</code> <code>026AA982</code> <code>ProMicro_repeater_lora_ota_no_external_sensors</code> <code>239A00B3 / PROM_DFU</code> <code>AF79E8CC</code> <code>t1000e_repeater_lora_ota_no_external_sensors</code> <code>28860057 / T1KE_DFU</code> <code>E6F5F03F</code> <code>ThinkNode_M3_repeater_lora_ota_no_external_sensors</code> <code>239A00DA / TNM3_DFU</code> <code>0CA41DB2</code> <code>RAK_3401_repeater_lora_ota_no_external_sensors</code> <code>239A0029 / 3401_DFU</code> <code>23818A80</code> RAK4631 lean repeater and both lean RS232 bridges <code>239A0029 / 4631_DFU</code> <code>2D0DF000</code> GAT562 30S/Tracker Pro/EVB Pro lean targets <code>239A0029 / GAT562_DFU</code> <code>D50D2D44</code> <code>R1Neo_repeater_lora_ota_no_external_sensors</code> <code>239A0029 / 4631_DFU</code> <code>2D0DF000</code> <code>RAK_WisMesh_Tag_repeater_lora_ota_no_external_sensors</code> <code>239A0029 / RTAG_DFU</code> <code>C72E9C9C</code> <p>Board IDs are not globally unique. For generic targets, the signed hardware ID is the exact NUL-padded 32-byte value <code>NRF_BL_&lt;BOARD_ID&gt;_&lt;DEVICE_NAME&gt;</code>. The wire target is the little-endian first four SHA-256 bytes of all 32 padded bytes. The installed and candidate embedded manifest pairs must match exactly. XIAO retains its deployed <code>XIAO_BL_28860044</code> / <code>XIAO_BL_28860045</code> identity and raw board-ID target.</p> <p>The Python reference builder and release tooling audit these boot targets for duplicates and collisions with application target IDs. Generic image parsing can inspect a future canonical identity, but signing/building a package fails until that exact identity is in the qualified inventory.</p> <p>Earlier GAT562 installations may report the RAK-compatible <code>4631_DFU</code> identity. The installed and candidate identity pair must match exactly, so a remote bootloader update cannot migrate one of those devices to <code>GAT562_DFU</code>. Provision the GAT562-specific OTAFIX bootloader once through USB/BLE DFU or SWD; subsequent signed bootloader mOTA updates use target <code>D50D2D44</code>.</p>"},{"location":"ota_nrf52_bootloader_update/#embedded-continuity-and-version-policy","title":"Embedded continuity and version policy","text":"<p>Every remotely supplied successor retains the legacy 44-byte CRC-valid <code>BLMF</code> v1 record for identity continuity and diagnostics. Immediately after that record is a 32-byte <code>BLM2</code>/<code>SOFT</code> extension. The complete 76-byte envelope is fixed at the final raw-image offset <code>0x9FB4</code>; relocated candidates are refused, while installed legacy-v1 discovery remains a generic diagnostic scan. The extension carries the actual packed bootloader version, SoftDevice family and FWID, application base, layout ABI, and zero compatibility/reserved fields; the legacy whole-image CRC covers the extension too. Scanners first count CRC-valid 44-byte base manifests, then interpret continuity only after one base identity remains. A malformed claimed extension therefore cannot make a duplicate identity disappear, and a sole half-present extension is rejected rather than treated as legacy.</p> <p>MeshCore requires the candidate extension, exact equality between its embedded version and the signed outer mOTA version, and exact agreement with the running SoftDevice family/FWID/application layout. Qualified internal/QSPI paths may bootstrap a CRC-valid installed legacy-v1 image once; the SD path never does and requires local BLM2 provisioning. Once the installed bootloader has BLM2 metadata, the candidate version must be strictly greater. Preview low bytes are <code>1..254</code>, a stable release uses <code>0xFF</code>, and low-byte zero or all-ones values are rejected. There is no remote rollback/migration override; intentional rollback uses USB/BLE DFU or SWD.</p> <p>The legacy <code>no_external_sensors</code> profiles trim selected optional environmental and ranging drivers to preserve flash headroom; they do not generally disable the I2C bus. Reduced RAK3401 and RAK4631 recipes retain INA219, INA226, INA260, and INA3221 voltage/current monitors. Those are entries in the optional sensor table, not the complete set of I2C consumers: the SSD1306 OLED, supported autodiscovered RTCs, and RAK12500 GPS remain separate I2C peripherals where the exact board recipe enables them. RAK3401 retains its compatible RAK12500 I2C and RAK12501/L76K UART GPS paths in sensor slot A. The plain RAK4631 repeater and Serial2 bridge retain GPS. Its RAK12501 path uses Serial1; the explicitly compiled Serial1 RS232 bridge therefore omits the combined GPS provider, including RAK12500, even though RAK12500 itself is I2C rather than UART.</p> <p>The firmware-configured INA3221 and RAK12500 addresses are both <code>0x42</code>. They cannot coexist on the same bus at those addresses. Leave RAK12500 at <code>0x42</code>, strap INA3221 A0 to SCL for <code>0x43</code>, and use firmware built with <code>-DTELEM_INA3221_ADDRESS=0x43</code> when both modules are installed.</p> <p>Boards with onboard external flash are not silently redirected to internal staging. Mesh Solar, Nano G2 Ultra, T-Impulse Plus, ThinkNode M8, T-Echo Lite/Card, MeshTracker X1, and Wio WM1110 have board-specific QSPI hardware and need a separately matched QSPI path where available. Full Companions, other SD/QSPI/ExtraFS roles, Ethernet roles, source-only roles, and unqualified full-sensor roles are excluded from the internal-flash inventory. The exact MeshTower V2 SD role above is separately qualified for its SD path.</p> <p>This internal layout is limited to nRF52840 devices with 1 MiB internal flash, the exact S140 v6/v7 map, and the 40 KiB boot region at <code>0xF4000..0xFE000</code>. nRF52833 and smaller nRF52 parts cannot provide that map plus a non-overlapping 41,330-byte live staging slot, so configuration fails closed instead of selecting smaller or overlapping geometry.</p>"},{"location":"ota_nrf52_bootloader_update/#explicit-install-workflow","title":"Explicit install workflow","text":"<p>Check the installed identity and capability marker:</p> <pre><code>ota bootloader\n</code></pre> <p>The response must show a CRC-valid exact identity, ABI 3 or newer, both FULL and INPLACE application codecs (<code>codecs=0x5</code>), and exact flags <code>0x09</code> for MeshTower V2 SD, <code>0x0A</code> for internal shared storage, or <code>0x0E</code> for XIAO QSPI. A bootloader row is visible in <code>ota ls</code>, but it is never autofetched or autoinstalled. Fetch its exact MID, then explicitly arm it:</p> <pre><code>ota pull &lt;MID8&gt; flash\n# wait for ota status to report the download ready\nota bootloader\nota bootloader install &lt;MID8&gt; &lt;HASH16&gt;\n</code></pre> <p>Copy both confirmation values from the second <code>ota bootloader</code> response. Ordinary <code>ota install</code> rejects a bootloader package; the bootloader command rejects an application package. The FULL-codec exception exists only for that manual bootloader MID. Ordinary application FULL remains disabled on an internal single-slot node, bootloader autofetch remains off, and a partial bootloader package is not automatically resumed after an application reboot.</p> <p>Before writing <code>APRV</code>, the application authenticates and authorizes the package: exact v3 geometry, trusted Ed25519 signer, signed/embedded identity, one unambiguous capability marker, embedded CRC, sane vectors, complete Merkle/payload/image hashes, storage-specific safe live placement, and the typed MID/hash confirmation. The manifest root and target inside the received manifest must also equal the MID/target that opened the fetch before any store is allocated. On SD, <code>APRV</code>, the retained geometry/container authorization, and the internal signed-image-hash token are published in that order before the reset trigger. OTAFIX consumes that application-written authorization and then independently rechecks the safety/integrity subset: strict v3 structure, canonical identity/capabilities, vectors, full payload SHA, embedded manifest CRC, the applicable live <code>EndF</code>/bank-settings no-overlap geometry, the SD token binding where applicable, scratch readback, and final copy hash. It does not re-run Ed25519, the signer allowlist, Merkle leaves/root, or the typed operator confirmation. Success is reported as <code>blup:C8</code>.</p>"},{"location":"ota_nrf52_bootloader_update/#failure-behavior","title":"Failure behavior","text":"<p>The feature fails closed when the MCU/map is wrong, required valid <code>EndF</code> headroom is insufficient, an unsupported external/ExtraFS role owns the target, the exact installed capability marker is absent or ambiguous, identity cannot be derived unambiguously, or any package check fails. Before the storage-specific scratch/copy step, the application and bootloader are unchanged. OTAFIX consumes the trigger and authorization before its first destructive action, so an interrupted operation cannot automatically retry a partly consumed package. On SD, the retained-RAM authorization is zero-consumed before media access; <code>APRV</code> and the fmt3 flash token may persist but are inert without a new explicit authenticated re-arm and reset trigger. No SD raw-sector handoff is created or consumed. Use USB/BLE DFU or SWD for initial provisioning and local recovery.</p> <p>For XIAO and ordinary external-QSPI details, see nRF52 repeater LoRa OTA with external QSPI.</p>"},{"location":"ota_nrf52_qspi/","title":"nRF52 repeater LoRa OTA with external QSPI","text":"<p>Selected nRF52840 repeater builds use their dedicated external QSPI NOR flash as a raw LoRa OTA staging device. This removes the internal-flash staging conflict: the complete <code>.mota</code> stays off-chip, and the bootloader can use the entire internal application region while it installs either a full image or an in-place delta.</p> <p>This is a matched application-and-bootloader feature. A board merely having an nRF52840, free RAM, or pins named QSPI is not enough. Both halves must use the exact flash wiring, and <code>ota self</code> must confirm the store and bootloader before an update is downloaded.</p>"},{"location":"ota_nrf52_qspi/#supported-repeater-families","title":"Supported repeater families","text":"<p>QSPI staging is enabled only for explicitly matched repeater-role environments (and RS232 bridge variants that directly inherit one of those repeater targets) on these currently matched families:</p> <ul> <li>Seeed XIAO nRF52840 and XIAO nRF52840 Sense modules, including the   <code>Xiao_nrf52</code>, SolarXiao 30S/33S, and XIAO-module Ikoka handheld, Nano, and   Stick repeaters</li> <li>original LilyGo T-Echo</li> <li>Elecrow ThinkNode M1 and M6</li> <li>Seeed Wio Tracker L1</li> <li>Seeed SenseCAP Solar Node P1</li> <li>RAK4631 with a RAK15001 in WisBlock sensor slot C, using the dedicated   <code>RAK_4631_repeater_rak15001_slot_c_lora_ota</code> application and matching   <code>wiscore_rak4631_board_rak15001_slot_c</code> OTAFIX bootloader</li> <li>RAK4631 with an externally wired Winbond W25Q16JV breakout on RAK19007,   using <code>RAK_4631_repeater_w25q16_lora_ota</code></li> <li>RAK3401 with its RAK13302 1 W radio and the same externally wired W25Q16JV   breakout on RAK19007, using   <code>RAK_3401_repeater_rak13302_w25q16_lora_ota</code></li> </ul> <p>Heltec T114 is intentionally not in this list. Its public V1, V2.0, and V2.1 schematics show U9 (MX25R1635F) as an optional QSPI footprint, so standard T114 application and bootloader targets do not assume that external NOR is populated.</p> <p>The XIAO-module derivatives use the matching XIAO or XIAO Sense OTAFIX bootloader shown by the module's <code>INFO_UF2.TXT</code>. Do not substitute a similar bootloader for a board with different QSPI pins. For example, the T-Echo Card and T-Echo Lite have different flash wiring and are not enabled by the original T-Echo target.</p> <p>Companion builds are intentionally excluded. Some companion targets use the same external QSPI as a LittleFS message/data store, where raw OTA staging would corrupt the filesystem; other companions simply do not assign that chip to OTA. Room-server, sensor, and KISS roles are unchanged. Raw QSPI OTA is scoped to the explicitly matched repeater-derived environments.</p>"},{"location":"ota_nrf52_qspi/#rak15001-placement-and-module-conflicts","title":"RAK15001 placement and module conflicts","text":"<p>RAK15001 is a 2 MiB GD25Q16C standard SPI module, not a quad-I/O flash. The dedicated RAK4631 target uses the nRF52840 QSPI peripheral in its single-data-line FAST_READ/page-program modes at 8 MHz and accepts only the module's exact <code>C8 40 15</code> JEDEC ID. <code>ota self</code> reports <code>QSPI store:2048K</code> only when the expected module responds. An empty slot or a different SPI device reports <code>QSPI store:ERR 0K</code>, and install is refused.</p> <p>The module is electrically usable in sensor slot A-D because those slots share the SPI signals and RAK15001 has onboard 10 kOhm pull-ups on WP# and HOLD#. The supported MeshCore/OTAFIX combination nevertheless requires slot C. It is the placement that remains safe when a RAK12501 GNSS is fitted in either of its supported slots, A or D: slot C avoids the GNSS PPS/reset nets on IO1/IO2 and IO5/IO6. In particular, GPS in A plus flash in B would share IO1/IO2 through the modules' auxiliary pins.</p> <p>Only one device that uses the shared WisBlock SPI chip-select may be fitted. Do not combine this target with RAK13800 Ethernet, RAK15002 SD, or another SPI module. RAK13800 and RAK15001 cannot coexist because they use the same SPI chip-select. Update a RAK13800 Ethernet build locally over USB using the release's Manual UF2 or Serial DFU (.zip) download; it cannot use this RAK15001 LoRa-OTA staging target.</p> <p>RAK3401 with RAK13302 remains incompatible with RAK15001. The 1 W radio uses the same WisBlock SPI clock/data pins and the same chip-select as RAK15001. Firmware cannot independently select or detect those two chips, so a stock RAK3401 + RAK15001 assembly cannot provide reliable OTA staging without a hardware chip-select rework. This restriction does not apply to the separate-CS W25Q16 wiring below.</p>"},{"location":"ota_nrf52_qspi/#one-w25q16-wiring-for-rak4631-or-rak3401-rak13302","title":"One W25Q16 wiring for RAK4631 or RAK3401 + RAK13302","text":"<p>An external Winbond W25Q16JV breakout can remain attached to a RAK19007 while the core is changed between RAK4631 and RAK3401 + RAK13302. It shares only the WisBlock SPI clock/data nets and has its own chip-select on AIN1:</p> W25Q16 breakout RAK19007 connection nRF52840 / Arduino pin <code>CLK</code> IO connector pin 26, <code>SPI_CLK</code> P0.03 / <code>3</code> <code>DO</code> / MISO IO connector pin 27, <code>SPI_MISO</code> P0.29 / <code>29</code> <code>DI</code> / MOSI IO connector pin 28, <code>SPI_MOSI</code> P0.30 / <code>30</code> <code>CS</code> J11 <code>AIN1</code> P0.31 / <code>31</code> <code>VCC</code> J12 <code>VDD</code> regulated 3.3 V <code>GND</code> J12 <code>GND</code> ground <p>Fit a physical approximately 10 kOhm pull-up from <code>CS</code> to J12 <code>VDD</code>. That keeps the flash deselected during reset, bootloader entry, and a core-module swap. Power the breakout only from J12 <code>VDD</code>; never use J11 <code>VBAT</code>, which can exceed the flash's supply rating. The six-pin breakout does not expose WP#/IO2 or HOLD#/IO3; do not add nRF IO2/IO3 wiring. A breakout with an onboard power LED works, but that LED draws continuously and is undesirable for low-power or solar operation.</p> <p>This arrangement consumes no WisBlock sensor slot. However, <code>SPI_CLK</code>, <code>SPI_MISO</code>, and <code>SPI_MOSI</code> are not available on the easy 2.54 mm J10/J11/J12 headers. Those three signals require a short underside-pad tap or a suitable IO-connector interposer at pins 26-28. J11 and J12 alone are not sufficient.</p> <p>GPS remains supported in sensor slot A. RAK12500 uses I2C, while RAK12501/L76K uses UART plus its auxiliary control signals; neither uses the shared SPI clock/data bus. On RAK4631 the built-in SX1262 has a separate private SPI bus. On RAK3401 the RAK13302 and flash share clock/data, but have independent chip-selects: RAK13302 NSS is P0.26 and flash CS is P0.31. The matched firmware holds the radio NSS high while it temporarily hands the bus to the flash, then restores the radio SPI interface.</p> <p>The breakout target accepts only a 2 MiB W25Q16 with JEDEC ID <code>EF 40 15</code> and runs it at 8 MHz in standard single-data-line SPI mode. A substituted W25Q32, W25Q64, or W25Q128 fails closed instead of being treated as the OTA store. Use the complete application/bootloader identity row that matches the fitted core:</p> Core and radio PlatformIO environment MOTA hardware identity OTAFIX board / DFU device name RAK4631 built-in SX1262 <code>RAK_4631_repeater_w25q16_lora_ota</code> <code>RAK4631_W25Q16</code> <code>wiscore_rak4631_w25q16</code> / <code>4631_W25Q16_DFU</code> RAK3401 + RAK13302 1 W <code>RAK_3401_repeater_rak13302_w25q16_lora_ota</code> <code>RAK3401_RAK13302_W25Q16</code> <code>wiscore_rak3401_rak13302_w25q16</code> / <code>3401_W25Q16_DFU</code> <p>The physical flash wiring is identical, but the two application and bootloader pairs are not interchangeable.</p>"},{"location":"ota_nrf52_qspi/#one-time-prerequisite","title":"One-time prerequisite","text":"<p>Install a QSPI-capable OTAFIX 2.4.1 preview.9 or newer bootloader for the exact board from the OTAFIX releases before using LoRa OTA. The release notes must explicitly list that board's QSPI mode. Also install the SoftDevice version expected by that target. The application refuses the install handoff when the bootloader does not advertise QSPI support.</p> <p>For the external W25Q16 option, install the corresponding bootloader once before installing its MeshCore application: <code>wiscore_rak4631_w25q16</code> (<code>DEVICE_NAME=4631_W25Q16_DFU</code>) for RAK4631, or <code>wiscore_rak3401_rak13302_w25q16</code> (<code>DEVICE_NAME=3401_W25Q16_DFU</code>) for RAK3401 plus RAK13302. Use only a release that explicitly names that exact pairing. Do not substitute the RAK15001 bootloader or swap the two W25Q16 bootloaders merely because the base-board wiring is the same.</p> <p>For the first migration from the ordinary <code>wiscore_rak4631_board</code> bootloader to <code>wiscore_rak4631_board_rak15001_slot_c</code>, use Nordic serial DFU or a compatible BLE DFU client with the exact slot-C OTAFIX combined bootloader + SoftDevice DFU package (or use SWD), then reinstall the slot-C MeshCore application. The release filename has this form:</p> <pre><code>wiscore_rak4631_board_rak15001_slot_c_bootloader-&lt;OTAFIX-version&gt;_s140_6.1.1.zip\n</code></pre> <p>Do not copy the slot-C bootloader-update UF2 onto the stock UF2 drive. The stock loader is bound to <code>DEVICE_NAME=4631_DFU</code>, while the slot-C image is bound to <code>4631_15001C_DFU</code>, so that UF2 is intentionally rejected. After the one-time DFU/SWD migration, later canonical slot-C bootloader UF2 files work normally. The combined OTAFIX package above is not the MeshCore application's Serial DFU <code>.zip</code>; an application package does not migrate the bootloader.</p> <p>After installing the repeater application, check:</p> <pre><code>get bootloader.ver\nota self\nota status\nota qspi\n</code></pre> <p>A ready RAK15001 target reports all of the following:</p> <pre><code>QSPI store:2048K\nbootloader: QSPI apply OK\nbl:QSPI\nQSPI jedec=C84015 size=2048K sr1=00 stage=jedec\n</code></pre> <p>A ready external W25Q16 target instead identifies the Winbond part:</p> <pre><code>QSPI store:2048K\nbootloader: QSPI apply OK\nbl:QSPI\nQSPI jedec=EF4015 size=2048K sr1=00 stage=jedec\n</code></pre> <p>Other supported boards can report a capacity different from 2048K; the RAK15001 and W25Q16 targets must report exactly 2048K and their respective exact JEDEC IDs. <code>QSPI store:ERR 0K</code>, <code>NO QSPI</code>, or <code>bl:NO-QSPI</code> means the flash wiring, flash power, chip-select pull-up, application, or bootloader does not match. Do not start an install in that state.</p> <p><code>ota qspi</code> is a read-only diagnostic probe available on QSPI OTA builds. It reports the exact JEDEC ID, status-register byte, last store stage, and the first latched storage error. Run it after an immediate <code>storage error</code> before starting another pull; later capacity probes preserve that failure detail.</p>"},{"location":"ota_nrf52_qspi/#capacity-and-package-types","title":"Capacity and package types","text":"<p>The store reads the JEDEC capacity at runtime and accepts supported 1 MiB through 16 MiB devices using 24-bit addressing. QSPI capacity is not the final firmware limit. The reconstructed application, including its 56-byte <code>EndF</code> trailer, must fit its build's linked application region:</p> SoftDevice layout Application region Maximum image S140 v7, boot-update-capable XIAO module <code>0x27000..0xE0000</code> <code>0xB9000</code> (757,760 bytes) S140 v7, app base <code>0x27000</code> <code>0x27000..0xED000</code> <code>0xC6000</code> (811,008 bytes) S140 v6, app base <code>0x26000</code> <code>0x26000..0xED000</code> <code>0xC7000</code> (815,104 bytes) <p>The XIAO limit is deliberately 52 KiB smaller. Its linker and post-link record cap every ordinary application at <code>0xE0000</code>; OTAFIX reserves <code>0xE0000..0xEA000</code> as a 40 KiB self-update scratch bank, with the remaining gap left unused before InternalFS. Full and delta application packages for these targets derive their effective application end from that <code>0xE0000</code> record and are rejected if their reconstructed image or detools geometry crosses it.</p> <p>A full package needs only the new raw <code>firmware.hex</code> or non-merged application image. An in-place delta still needs the exact image currently running. The automation uses a conservative <code>0xC6000</code> detools workspace for external nRF52 staging so one package setting is safe for both layouts.</p> <p>For online automation, QSPI is detected from <code>ota self</code> or <code>ota status</code>. For offline preparation, identify it explicitly:</p> <pre><code>./tools/lora_ota/lora_ota.sh ./release.zip target-name \\\n  --prepare-only \\\n  --platform nrf52 \\\n  --nrf-qspi \\\n  --target-id 12345678 \\\n  --target-hw Xiao_nrf52\n</code></pre> <p>Use the real target ID and hardware identity from the destination. A ready full <code>.mota</code> normally uses that target ID for discovery and routing. An operator can deliberately override the routing target for a role change, so <code>target_id</code> is not an apply-time safety assertion; the destination still enforces the package's hardware identity before approval.</p>"},{"location":"ota_nrf52_qspi/#explicit-xiao-bootloader-updates-over-lora","title":"Explicit XIAO bootloader updates over LoRa","text":"<p>This section documents the deployed XIAO raw-QSPI layout. Curated nRF52840 targets without external staging use a separate internal-flash layout with the same explicit operator safety model; see nRF52 bootloader updates over LoRa.</p> <p>Bootloader delivery is available only when all of these are already true:</p> <ul> <li>the application is an <code>OTA_QSPI_BOOTLOADER_UPDATE</code> XIAO-module repeater build   linked below <code>0xE0000</code>;</li> <li><code>ota bootloader</code> shows a CRC-valid installed <code>XIAO_DFU</code> embedded identity for   board ID <code>28860044</code> (base) or <code>28860045</code> (Sense);</li> <li>the installed OTAFIX marker reports ABI 3 or newer and both QSPI (<code>0x04</code>) and   boot-update (<code>0x08</code>) capability bits;</li> <li>the package is the exact signed v3/40-KiB/1-KiB-block profile for that board,   and its signer is already in <code>ota key</code>'s trusted allowlist.</li> </ul> <p>This is not part of normal automation. Bootloader catalog rows are labelled <code>bootloader</code>; even a capable node never autofetches or autoinstalls them, and ordinary <code>ota install</code> rejects them in every application backend. The <code>tools/lora_ota</code> deployment runner also refuses v3 packages. Fetch and arm one only with the explicit flow:</p> <pre><code>ota ls\nota pull &lt;MID8&gt; flash\n# wait for ota status to report the same bootloader download as ready\nota bootloader\n# copy the exact mid= and hash= values printed above\nota bootloader install &lt;MID8&gt; &lt;HASH16&gt;\n</code></pre> <p>The pull command is only transport intent; it does not authorize an install. The final command must reproduce both the complete staged manifest ID and the first eight bytes of its signed image hash. Before approval the application again checks package/root/payload/image hashes, Ed25519 signature and trusted allowlist, exact signed <code>XIAO_BL_...</code> ID, installed and incoming embedded   manifest/CRC/name/board identity, vector table, ABI-3 QSPI+boot-update marker,   and the adjacent CRC-covered <code>BLM2</code>/<code>SOFT</code> continuity extension at the exact   final-image offset <code>0x9FB4</code>. The embedded   boot version must equal the signed outer package version, the SoftDevice   family/FWID/application base/layout ABI must match the running platform, and   a successor to installed BLM2 must be strictly newer. Low-byte-zero and   all-ones versions are invalid. Remote rollback is refused; use local DFU/SWD.</p> <p>After the reply drains, GPREGRET <code>0x6B</code> and GPREGRET2 <code>0x51</code> enter the special OTAFIX path. <code>APRV</code> carries the app's signature/allowlist and explicit operator authorization decision. OTAFIX independently rechecks the strict structure, identity/capabilities, vectors, payload SHA, embedded CRC, and copy hashes before using the reserved scratch bank to replace its own <code>0xF4000..0xFE000</code> region. The running application remains preserved; a rejected candidate returns to it unchanged. Post-reboot <code>ota status</code> reports bootloader-update diagnostics as <code>blup:C0</code> to <code>blup:CF</code> (<code>blup:C8</code> is success), separately from ordinary application <code>blrc</code>.</p> <p>This feature cannot update a stock or old bootloader that lacks the capability marker: perform the first exact-board combined bootloader+SoftDevice migration over USB/BLE DFU or SWD. Do not attempt to bootstrap it with a v3 package.</p>"},{"location":"ota_nrf52_qspi/#storage-ownership-and-recovery","title":"Storage ownership and recovery","text":"<p>The QSPI store is raw, not a file inside LittleFS. It owns the flash from offset zero, erases 4 KiB sectors as blocks arrive, writes data before progress metadata, and verifies every programmed page. A previously interrupted download is reopened only when its header and trailer are valid; every claimed block is re-hashed before it is trusted. Between a probe, transfer operation, or checkpoint, firmware puts the NOR into deep power-down, deactivates the nRF QSPI peripheral, and turns off a board-provided flash power-enable pin. The next operation powers the chip, shifts the NOR's <code>0xAB</code> wake command over GPIO, then activates the nRF QSPI peripheral and identifies the flash. Waking it before peripheral activation is required because a flash in deep power-down ignores the activation traffic itself. Merely running <code>ota self</code> therefore does not leave QSPI drawing active-mode current or prevent the following operation from reactivating it.</p> <p>Installing a QSPI repeater build over a former companion build therefore repurposes the external flash and destroys companion filesystem data as OTA sectors are written. Back up anything important first. Returning to a companion build may require formatting its external data store.</p> <p>Before changing internal application flash, the application verifies package integrity, hardware identity, signature policy, and bootloader capabilities. The target ID selects discovery/fetch routing and can be deliberately overridden; it is not a second hardware gate. The bootloader then verifies a full payload before its first application erase. For a delta, the application rejects invalid detools geometry before approval and the bootloader independently repeats the base and geometry checks before applying it. It clears the one-shot approval marker before invalidating the running image. If power is lost after application writes begin, the bank remains invalid and OTAFIX enters USB/BLE recovery rather than booting a partial image.</p> <p>See Easy firmware updates over LoRa for the transfer commands and the OTA protocol for the container and handoff details.</p>"},{"location":"ota_protocol/","title":"MeshCore OTA - <code>.mota</code> container &amp; LoRa protocol","text":"<p>This is the single source of truth for MeshCore's over-the-air firmware update system (\"mOTA\"). It is written for developers who want to implement an interoperable peer (server, fetcher, relay, or host tool) in another codebase or project. Everything below is implemented in this repository and covered by host, simulation, build, or hardware tests as noted in the relevant section. Hardware qualification is target- and chain-specific; do not infer it from implementation alone. Where a section names a source file, that file is the authoritative reference for byte-level details.</p> <p>Just want to update your node? See the plain-language OTA user guide - this document is the technical/wire specification.</p> <p>Design goals</p> <ul> <li>Distribute firmware over LoRa as a self-verifying, resumable, single-source block transfer that   survives reboots and never auto-applies without explicit consent.</li> <li>Trustless mesh relay: repeaters may forward packets while the source alone serves firmware data;   integrity is content-addressed   against a signed merkle root, so a relay need not be trusted and never needs the signing keys.</li> <li>Primary while transferring: periodic discovery stays at background priority, but manifest, block,   data, and proof packets for an active fetch use primary queue priority at every relay hop.</li> <li>Portable: the engine (<code>src/helpers/ota/OtaManager</code>) is Arduino/radio/crypto-free and host-testable,   so the same logic drives a device, a simulation, or a third-party implementation.</li> </ul> <p>Source map (all under <code>src/helpers/ota/</code> unless noted)</p> Concern File Constants, enums, flags <code>OtaFormat.h</code> Container/manifest parse <code>MotaContainer.{h,cpp}</code> Merkle tree + proofs <code>MerkleTree.{h,cpp}</code> EndF self-identity <code>FirmwareInfo.{h,cpp}</code> Wire message codec <code>OtaProtocol.{h,cpp}</code> Session engine (serve+fetch+discovery) <code>OtaManager.{h,cpp}</code> Multi-mota / folder relay <code>OtaSource.h</code>, <code>MotaSourceSerial.{h,cpp}</code>, <code>MotaSeederProto.h</code> Staging stores <code>OtaStore.h</code>, <code>OtaStoreFlashNrf52.*</code>, <code>OtaStoreFlashEsp32.*</code> Apply <code>OtaApply.*</code>, bootloader <code>Adafruit_nRF52_Bootloader_OTAFIX</code> Device glue (CLI/context) <code>OtaCli.cpp</code>, <code>OtaContext.h</code> Host tooling <code>motatool</code> (standalone Rust CLI: build/verify/inspect/serve); <code>tools/mota/</code> (Python reference lib <code>motalib.py</code> + build/test glue)"},{"location":"ota_protocol/#1-conventions","title":"1. Conventions","text":"<ul> <li>Endianness: all multi-byte integers are little-endian unless stated.</li> <li>Hashes (multihash): the hash family is declared once per manifest via <code>hash_algo</code> =   <code>0x12</code> = SHA-256 (the multihash code for sha2-256).   Truncations used:</li> <li><code>sha2-256:4</code> - first 4 bytes of the SHA-256 digest. Merkle leaves, internal nodes, root, proofs,     <code>manifest_id</code>, and the discovery <code>set_digest</code>.</li> <li><code>sha2-256:8</code> - first 8 bytes. Base-firmware identity (<code>base_hash</code>, <code>EndF.body_hash</code>).</li> <li><code>sha2-256:32</code> - full digest. The image security anchor (<code>image_hash</code>).   Digests are stored bare (just the truncated bytes); the family is implied by <code>hash_algo</code>.</li> <li>Signatures: Ed25519 (RFC 8032), 64-byte detached signature, 32-byte public key.</li> </ul> <p>Reference constants (<code>OtaFormat.h</code>):</p> Name Value ASCII / note Container <code>MAGIC</code> <code>6D 4F 54 41</code> <code>mOTA</code> Container <code>TRAILER</code> <code>76 6B 34 39 36</code> <code>vk496</code> <code>EndF</code> marker <code>45 6E 64 46</code> <code>EndF</code> <code>hash_algo</code> (sha2-256) <code>0x12</code> multihash code application <code>format_ver</code> <code>0x02</code> ordinary full/delta application package bootloader <code>format_ver</code> <code>0x03</code> privileged exact-identity nRF52 bootloader package only <code>approval</code> = not approved <code>FF FF FF FF</code> erased NOR word <code>approval</code> = approved <code>41 50 52 56</code> <code>APRV</code> <code>MFLAG_FULL</code> <code>0x01</code> flags bit0 <code>MFLAG_SIGNED</code> <code>0x02</code> flags bit1 <code>MFLAG_BOOTLOADER</code> <code>0x04</code> flags bit2; valid only in the exact v3 bootloader profile <code>CODEC_FULL</code> / <code>_SEQUENTIAL</code> / <code>_INPLACE</code> <code>0</code> / <code>1</code> / <code>2</code> Section 5 <code>PAYLOAD_TYPE_OTA</code> <code>0x0C</code> MeshCore packet type (<code>src/Packet.h</code>) <code>MAX_PACKET_PAYLOAD</code> <code>184</code> usable bytes per packet (<code>src/MeshCore.h</code>) Default application block size <code>2048</code> <code>block_size_log2 = 0x0B</code>; deployed 1 KiB application packages remain accepted Bootloader-package block size <code>1024</code> fixed <code>block_size_log2 = 0x0A</code> for format 3 OTA discovery TX priority <code>250</code> background (<code>OTA_TX_PRIORITY</code>, <code>src/Mesh.h</code>) OTA active-transfer TX priority <code>0</code> primary (<code>OTA_TRANSFER_TX_PRIORITY</code>, <code>src/Mesh.h</code>) <p>Current application firmware publishes its receive/reassembly ceiling as the compact <code>maxblk:2048</code> field near the front of both <code>ota status</code> and <code>ota self</code>. Keeping the field ahead of variable diagnostics ensures it survives the 160-byte remote-admin reply limit. Host updaters must treat an absent field as the deployed legacy capability (<code>1024</code>), reject a ready package whose manifest block size exceeds that capability, and use the reported size when turning a raw firmware image into a new application package. This capability does not change the format-3 bootloader package's fixed 1 KiB geometry.</p>"},{"location":"ota_protocol/#2-firmware-image-the-endf-trailer","title":"2. Firmware image &amp; the <code>EndF</code> trailer","text":"<p>Every OTA-capable build appends a fixed 56-byte <code>EndF</code> trailer to its flashed image so a running node can discover its own size and self-describing identity on any MCU (no linker symbols needed). Every field is always present at a constant offset. Implemented by <code>FirmwareInfo.cpp</code>; appended at build time by <code>tools/mota/pio_endf.py</code> (post-build hook).</p> <pre><code>flashed image = BODY (image bytes) || EndF trailer\nEndF trailer (fixed 56 bytes):\n  off 0   4   \"EndF\"        45 6E 64 46\n  off 4   4   body_len      uint32 LE - length of BODY (excludes the whole trailer)\n  off 8   8   body_hash     sha2-256:8 of BODY\n  off 16  4   fw_version    uint32 LE, packed MAJOR&lt;&lt;24|MINOR&lt;&lt;16|PATCH&lt;&lt;8|pre  (0 = unknown)\n  off 20  4   target_id     uint32 LE - sha2-256:4(pio_env): hardware + role + partition (fetch routing)\n  off 24  32  hw_id         NUL-padded ASCII hardware tag (brick-safety), e.g. \"RAK4631\" (\"\" = unknown)\n</code></pre> <ul> <li>Self-describing identity. <code>pio_endf.py</code> uses <code>build.sh</code>'s <code>MOTA_TARGET_ID</code> when present (required for   virtual LoRa-OTA build names), otherwise it computes <code>target_id</code> from the PlatformIO env name. It reads   <code>hw_id</code> from <code>MOTA_HW_ID</code> and <code>fw_version</code>   from <code>FIRMWARE_VERSION</code>. The device reads them back (<code>ota_self_firmware()</code>), so a node's advertised   identity is correct regardless of how it was built - and the packaging tool reads them straight from a raw   <code>.bin</code> (no <code>--target-env</code>/<code>--fw-version</code> flags, no reliance on filenames; Section 9, Section 13). A dev build with no   dotted version simply carries <code>fw_version = 0</code> / empty <code>hw_id</code> (= unknown) - still a full 56-byte trailer.</li> <li>Size discovery: scan flash from the partition top downward for the <code>EndF</code> marker; the byte before it   is the last BODY byte (the trailer is always 56 bytes). See <code>ota_self_firmware()</code>.</li> <li>Delta base matching: a node's <code>body_hash</code> is read directly from its own <code>EndF</code>; a delta's <code>base_hash</code>   (Section 5) must equal it. <code>body_hash</code> is over BODY only.</li> <li>No circularity: <code>EndF</code> hashes only the BODY, never itself.</li> </ul> <p>The \"reconstructed image\" referenced by the manifest is the full <code>BODY || EndF</code> (what gets flashed).</p>"},{"location":"ota_protocol/#esp32-application-slot-profiles","title":"ESP32 application-slot profiles","text":"<p>ESP32 Companion firmware is exempt from the portable-slot limit. When an exact Full recipe exists, one expanded-partition image supplies USB, BLE, WiFi, source-only LoRa OTA, and persistent USB logging instead of separate transport artifacts. A small set of high-capacity, non-PSRAM classic ESP32 companions use 100 contacts, 8 group channels, and a 16-frame offline queue in that combined image to preserve internal-DRAM headroom. MQTT observers and ESP-NOW bridges always use FULL builds because fitting them into the legacy slot would require removing CLI and role features. Except for those FULL roles and the ESP32-C6 case below, non-companion ESP32 artifacts, including room, sensor, and repeater roles, must fit the legacy slot from <code>0x10000</code> up to <code>0x150000</code> (<code>0x140000</code>, 1,310,720 bytes), including the 56-byte <code>EndF</code> trailer. The build checks both that limit and the target's actual app partition. The ESP32-C6 <code>no_external_sensors</code> OTA siblings are the narrow exception: the Arduino 3.x WiFi runtime cannot fit that cross-family ceiling, so those images retain their established target-specific 1920 KiB or larger A/B app layout and are checked against the actual app partition. For standalone ESP32 and nRF52 repeaters that need a lean staging profile, <code>build.sh</code> also exposes an explicit <code>*_lora_ota_no_external_sensors</code> artifact: the ordinary repeater remains sensor-enabled, while that sibling trims selected optional environmental/ranging drivers for LoRa distribution. SolarXiao 30S and 33S use matched external QSPI staging, so their ordinary full-sensor repeater is already install-capable and no redundant lean sibling is generated. Integrated GPS and other board-native telemetry remain enabled where the target selects the GPS-preserving lean profile. The legacy suffix describes a driver trim, not removal of the generic I2C bus. Reduced RAK3401 and RAK4631 profiles retain INA219, INA226, INA260, and INA3221 voltage/current monitors. These are retained optional-sensor-table drivers, not the only I2C consumers: SSD1306 display, supported autodiscovered RTCs, and RAK12500 GPS remain separate I2C peripherals where selected by the board recipe. The RAK3401 OTA repeater also retains RAK12500 I2C and RAK12501/L76K UART GPS support; install either GPS module in sensor slot A because slot D conflicts with the RAK13302 radio's BUSY/DIO1 lines. The plain RAK4631 OTA repeater and its Serial2 bridge retain GPS. RAK12501 uses Serial1. Its explicitly compiled Serial1 bridge therefore omits the combined GPS provider, including RAK12500, even though RAK12500 itself does not use the UART.</p> <p>The firmware-configured INA3221 address and RAK12500 address are both <code>0x42</code>, so those devices cannot share one bus at those addresses. Keep RAK12500 at <code>0x42</code>, strap INA3221 A0 to SCL for <code>0x43</code>, and use firmware built with <code>-DTELEM_INA3221_ADDRESS=0x43</code> when both are installed.</p> <p>ESP32 siblings retain the compact browser WiFi updater and use the full 254-entry neighbor table. RP2040 and STM32 targets are not offered because those platforms do not yet have a safe bootloader/apply path.</p> <p>nRF52 LoRa-OTA siblings use size optimization rather than the Adafruit platform's default <code>-Ofast</code>. This keeps the runtime software Ed25519 fallback from being expanded into tens of kilobytes of repeated curve arithmetic while retaining CC310 hardware crypto, hardware RNG mixing, telemetry history, and board-native features.</p> <p>WiFi-heavy non-companion roles are not reduced to fit the legacy application slot. <code>build.sh</code> automatically promotes every ESP32 MQTT observer and ESP-NOW bridge to the expanded FULL partition profile. These artifacts retain the complete role CLI, WebConfig where supported, display and optional sensor support, full timezone and TLS behavior, and the board's normal power-management implementation. The compact CLI is not compiled into any build. Ordinary repeater builds remain sensor-enabled; only explicitly named <code>*_lora_ota_no_external_sensors</code> siblings trim selected optional environmental/ranging drivers for LoRa distribution, and those siblings retain the complete CLI and target-declared I2C peripherals.</p> <p>MQTT observer radio and bridge preferences use verified temporary files plus a recoverable backup. A reset during a settings save restores the last committed common preference image or publishes the completed new image; it does not leave a partially written <code>/com_prefs</code> file to fail on the next boot. A truncated legacy image is rejected before any partial radio or string fields are applied, then rewritten from safe defaults.</p> <p>Option 3 in <code>build.sh</code> emits one <code>*-full-usb-wifi-ota-*</code> ESP32 artifact for each FULL-capable non-companion hardware/role that has a matching MQTT environment. It compiles USB packet logging and direct WiFi MQTT together. A <code>*-full-logging-ota-*</code> fallback is emitted only when there is no MQTT sibling; ordinary non-OTA roles compile runtime USB logging into their canonical image, so separate standard-logging artifacts are not emitted. Non-MQTT FULL twins are also skipped for covered ESP32 roles. MQTT observers and ESP-NOW bridges are emitted only with expanded FULL partitions. Menu option 8, or <code>build-full-esp32-firmwares</code>, builds the unified profiles plus necessary fallbacks. Menu option 9, or <code>build-full-esp32-logging-firmwares</code>, builds only those fallbacks. FULL builds restore WebConfig, display support, optional external sensors, and the full role CLI and feature set, full ElegantOTA where that target declares the required library, and LoRa OTA for every included role, including room servers, sensors, observers, and bridges. They use expanded A/B partition tables: 1984 KiB application slots on 4 MiB boards and the framework's larger dual-OTA tables on 8 MiB and 16 MiB boards. Explicit <code>*_lora_ota_no_external_sensors</code> targets are not duplicated; their ordinary repeater build is the FULL, sensor-enabled counterpart. The <code>*-full-usb-wifi-ota-*</code> profile enables USB packet logging and MQTT, with a persistent <code>logging.output</code> selector; its verbose internal debug remains off. The fallback <code>*-full-logging-ota-*</code> profile enables USB debug and packet logging and has no MQTT target. Install a matching <code>*-full-usb-wifi-ota-*-merged.bin</code> or <code>*-full-logging-ota-*-merged.bin</code> over USB once to write the expanded partition table. After that, its matching non-merged FULL application image can be installed through USB, WiFi OTA, or LoRa OTA. Do not install a non-merged FULL image onto a node that still has its old partition table.</p> <p>Implementer note: the bootloader (and any non-Arduino consumer) MUST locate the body extent by scanning for <code>EndF</code>, never by trusting a stored size - see the bootloader contract in Section 12.</p>"},{"location":"ota_protocol/#3-the-mota-container","title":"3. The <code>.mota</code> container","text":"<p>The distributed form (host-built, wire-transferred). Parsed by <code>mota_parse()</code> in <code>MotaContainer.cpp</code>.</p> <pre><code>off            size   field\n0              4      MAGIC = 6D 4F 54 41\n4              4      MOTA_TOTAL_SIZE  uint32 LE - total container bytes (incl. manifest, leaves[],\n                                       payload, trailer). Lets a node pre-reserve staging and compute\n                                       write_start = staging_region_end - MOTA_TOTAL_SIZE.\n8              M      MANIFEST         (Section 4; M = 197 fixed + leaves[], 4*BC; no length field - BC from payload_size)\n8 + M          P      PAYLOAD          (payload_size bytes; delta or full image)\n8 + M + P      5      TRAILER = 76 6B 34 39 36\n</code></pre> <p><code>MOTA_TOTAL_SIZE = 4 + 4 + M + P + 5</code>. The manifest <code>M</code> includes <code>leaves[]</code>; the manifest-minus-leaves prefix (<code>mfl</code>, sent over the wire as <code>OTA_MANIFEST</code>) is <code>[8, leaves_off)</code>.</p> <p>Staged (in-flash) form. Written bottom-aligned so <code>TRAILER</code> ends at <code>staging_region_end</code>. Identical bytes, except the device mutates two regions in place (both NOR-safe, no re-erase): the <code>leaves[]</code> slots (filled as blocks arrive - Section 7) and the 4-byte <code>approval</code> field (on owner consent - Section 4.2). Everything else is immutable.</p>"},{"location":"ota_protocol/#4-the-manifest","title":"4. The manifest","text":"<p>Fixed layout. Every field sits at a constant offset and is always present - <code>base_hash</code>, <code>signer_pubkey</code> and <code>signature</code> are zero-filled when not applicable (a full image / an unsigned container). Only <code>leaves[]</code> is variable (one 4-byte hash per block). So the manifest-minus-leaves (<code>mfl</code>) is always 197 bytes and the parser is plain offset reads - no conditionals. Parsed by <code>mota_parse_manifest()</code>.</p> <pre><code>off  size   field            notes\n0    1      format_ver       = 0x02 application, or 0x03 privileged bootloader package\n1    1      flags            bit0 FULL; bit1 SIGNED; bit2 BOOTLOADER; bits3-7 reserved 0\n2    1      hash_algo        0x12 = sha2-256\n3    4      target_id        device/arch/role discriminator (Section 9)\n7    4      fw_version       MAJOR&lt;&lt;24 | MINOR&lt;&lt;16 | PATCH&lt;&lt;8 | pre   (comparable uint32)\n11   4      image_size       size of the reconstructed image (BODY||EndF)\n15   4      payload_size     PAYLOAD bytes in this container\n19   1      block_size_log2  e.g. 0x0B = 2048 (new application default); 0x0A = deployed 1024\n20   4      merkle_root      sha2-256:4 over PAYLOAD blocks (Section 6) - also the manifest_id\n24   32     image_hash       sha2-256:32 of the reconstructed image - SECURITY anchor\n56   1      codec_id         0=full/raw, 1=detools-sequential, 2=detools-in-place\n57   32     hw_id            NUL-padded ASCII hardware tag (e.g. \"RAK4631\"); same tag =&gt; bootable-compatible.\n                             SIGNED. Applier refuses a mismatch (brick-safety); empty on either side = skip.\n89   8      base_hash        sha2-256:8 of the BASE image's BODY (== that build's EndF.body_hash). 0 if FULL.\n97   32     signer_pubkey    Ed25519 public key. 0 if not SIGNED.\n129  64     signature        Ed25519 over manifest[0, 129). 0 if not SIGNED.\n193  4      approval         FF FF FF FF = not approved; 41 50 52 56 (\"APRV\") = approved\n--- end of manifest-minus-leaves: mfl = 197 (constant); leaves_off = 8 + 197 = 205 in the container ---\n197  4*BC   leaves[]         BC = ceil(payload_size / 2^block_size_log2). sha2-256:4 each (the only variable field)\n</code></pre> <p>The signature always covers <code>manifest[0, 129)</code> (the head + <code>base_hash</code> + <code>signer_pubkey</code>). <code>approval</code> is outside the signed region so it can be flipped in place on consent without breaking the signature.</p> <p>Manifest-minus-leaves size (<code>mfl</code>) is a constant 197 bytes for every container (full or delta, signed or unsigned). At 197 bytes the manifest exceeds one packet, so <code>OTA_MANIFEST</code> is always sent multi-fragment (Section 8.4, 2 fragments) and reassembled by the fetcher.</p> <p>The two versions are deliberately disjoint. Version 2 accepts application packages only and rejects the BOOTLOADER bit. Version 3 accepts only flags exactly <code>FULL|SIGNED|BOOTLOADER</code>; a non-bootloader v3 package is invalid. Consequently, deployed v2-only application parsers reject a bootloader package before they can mistake its raw 40 KiB payload for an application image.</p>"},{"location":"ota_protocol/#41-signed-region","title":"4.1 Signed region","text":"<p><code>signature</code> covers manifest bytes <code>[0, 129)</code> - the head + <code>base_hash</code> + <code>signer_pubkey</code>. It does not cover <code>approval</code> or <code>leaves[]</code>:</p> <ul> <li><code>leaves[]</code> are verified against the signed <code>merkle_root</code> (Section 6), so they need no separate signature.</li> <li><code>approval</code> is device-local consent (Section 4.2), deliberately outside the signature.</li> </ul>"},{"location":"ota_protocol/#42-the-approval-field","title":"4.2 The <code>approval</code> field","text":"<ul> <li>Distributed and forced on ingest to <code>FF FF FF FF</code> (a peer can never pre-approve).</li> <li>The local owner's <code>ota applydelta</code> writes <code>41 50 52 56</code> (<code>\"APRV\"</code>) - a single NOR-safe write (only clears   bits from the erased word). Any partial/other value reads as not-approved (fail-safe).</li> <li>Bound to this image (lives in this <code>.mota</code>'s manifest, re-erased when a new <code>.mota</code> is staged).</li> <li>A consent marker, not a security primitive. Authenticity = <code>signature</code> + <code>image_hash</code> + <code>hw_id</code>.</li> </ul>"},{"location":"ota_protocol/#43-privileged-nrf52-bootloader-package-profile","title":"4.3 Privileged nRF52 bootloader package profile","text":"<p>A v3 bootloader package has a deliberately narrow, non-extensible profile:</p> <ul> <li>flags exactly <code>FULL|SIGNED|BOOTLOADER</code>, <code>CODEC_FULL</code>, nonzero <code>fw_version</code>, zero <code>base_hash</code>;</li> <li>a raw payload and <code>image_size</code> of exactly <code>0xA000</code> (40 KiB), split into exactly forty 1024-byte blocks;</li> <li>a target derived from the installed CRC-valid embedded manifest identity. Deployed XIAO identities keep   raw board IDs <code>0x28860044</code>/<code>0x28860045</code>; generic identities use LE32(SHA-256(canonical padded hw32));</li> <li>signed <code>hw_id</code> exactly <code>XIAO_BL_28860044</code>/<code>XIAO_BL_28860045</code> for deployed XIAO, or the zero-padded   32-byte <code>NRF_BL_&lt;BOARD_ID&gt;_&lt;DEVICE_NAME&gt;</code> for a generic target;</li> <li>a sane nRF52840 vector table, exactly one CRC-valid embedded manifest v1 with the exact board/name pair,   followed by the required CRC-covered <code>BLM2</code>/<code>SOFT</code> continuity extension (embedded boot version,   SoftDevice family/FWID, application base, and layout ABI), with that complete 76-byte envelope at the   canonical final-image offset <code>0x9FB4</code>,   and exactly one <code>MOTABLDR</code> marker advertising ABI &gt;= 3, both application codecs (<code>FULL|INPLACE</code>, mask   <code>0x0005</code>), boot-update continuity, and the exact storage flags for the application layout (<code>0x09</code>   MeshTower V2 SD, <code>0x0E</code> XIAO QSPI, or <code>0x0A</code> shared internal staging).</li> </ul> <p>The incoming embedded identity must exactly match the installed CRC-valid bootloader identity. Both scans consider every aligned structurally valid candidate so magic bytes in a literal pool cannot shadow the real manifest. Duplicate accounting counts each CRC-valid 44-byte base record before interpreting adjacent continuity metadata, so a corrupt or half-present <code>BLM2</code> extension cannot hide a second identity; after exactly one base record is selected, malformed claimed continuity fails closed. A package must be signed by a key already in the device's trusted allowlist; unlike ordinary application packages, there is no unsigned manual-install exception. The signed outer <code>fw_version</code> must equal the embedded boot version. Qualified internal/QSPI targets may bootstrap a CRC-valid legacy-v1 installed bootloader once; MeshTower SD instead requires local BLM2 provisioning because it has no safe legacy media handoff. After bootstrap every remote successor must be strictly newer and match the live SoftDevice/application layout. Low-byte zero and all-ones boot versions are invalid. Remote rollback has no override and must use local DFU/SWD.</p>"},{"location":"ota_protocol/#5-payload-codecs-delta-base","title":"5. Payload, codecs &amp; delta base","text":"<p><code>PAYLOAD</code> is either the full reconstructed image (<code>FULL</code>) or a delta (<code>!FULL</code>).</p> <code>codec_id</code> Meaning Used by 0 full / raw PAYLOAD = reconstructed image (<code>BODY||EndF</code>). ESP32 A/B or an external SD/QSPI nRF52 target. 1 detools sequential random read of base + sequential write of result -&gt; ESP32 A-&gt;B inactive slot. 2 detools in-place bounded scratch; rewrites the app region in place -&gt; nRF52 single-slot. <p>For deltas, <code>base_hash</code> = the base build's <code>EndF.body_hash</code> (sha2-256:8 of its BODY). A node applies a delta only if <code>base_hash</code> matches its own <code>EndF.body_hash</code>. After applying, the result MUST hash (sha2-256:32) to <code>image_hash</code> before it is booted - the hard security gate.</p> <p>A fetcher only requests firmware it can apply. Each node declares the codec(s) it can apply (<code>set_apply_codec</code>/<code>set_apply_codec2</code>): ESP32 accepts <code>full</code> + <code>sequential</code> (+ <code>in-place</code>). Internal-staging nRF52 targets accept only <code>in-place</code> because internal flash cannot hold a second full application image. Matched SD and raw-QSPI nRF52 targets accept <code>full</code> + <code>in-place</code> because external media holds the container. A <code>.mota</code> with an unsupported codec is rejected at discovery time, before any blocks are requested. A manual pull to an external folder may accept other codecs because that path captures bytes and never installs them.</p> <p>Compression is internal to the detools patch and must be supported by the applier. Patches are produced by detools 0.53.0 (<code>tools/mota</code> -&gt; <code>detools.create_patch</code>) and decoded on-device by detools' embeddable C decoder, vendored verbatim at <code>src/helpers/ota/detools/</code> (see its <code>README.meshcore.txt</code>). That build enables only the self-contained <code>NONE</code> + <code>CRLE</code> compressions (no malloc/liblzma/heatshrink), so MeshCore deltas use <code>--compression crle</code>. Do not reimplement the codec - use the vendored decoder.</p>"},{"location":"ota_protocol/#6-merkle-tree-sha2-2564","title":"6. Merkle tree (sha2-256:4)","text":"<p>Verifies each PAYLOAD block against the signed <code>merkle_root</code> before the whole payload exists, so corruption/forgery is localized to a block. Implemented in <code>MerkleTree.cpp</code>.</p> <ul> <li>Blocks: PAYLOAD splits into <code>BC = ceil(payload_size / B)</code> blocks, <code>B = 2^block_size_log2</code> (new   application default 2048; deployed 1024-byte application packages remain valid). The last block is its   real length (no zero padding). Format-3 bootloader packages remain fixed at 1024 bytes.</li> <li>Leaf: <code>leaves[i] = sha2-256:4( block_i_bytes )</code>.</li> <li>Internal node: <code>node = sha2-256:4( left || right )</code> (4+4 input bytes).</li> <li>Odd level: an odd count promotes the last node unchanged to the next level (no duplication).</li> <li>Root: reduce until one node remains. <code>BC == 1</code> -&gt; root = <code>leaves[0]</code>. <code>BC == 0</code> is invalid.</li> </ul>"},{"location":"ota_protocol/#61-proofs","title":"6.1 Proofs","text":"<p>A proof for block <code>i</code> is the ordered list of sibling digests from leaf to root. Promoted levels contribute no element. Verification (needs <code>BC</code> to know the tree shape):</p> <pre><code>h = leaf_i ; idx = i ; n = BC ; p = 0\nwhile n &gt; 1:\n    if (n is odd) and (idx == n-1):        # this node was promoted\n        pass\n    else:\n        sib, side = proof[p] ; p += 1\n        h = sha2-256:4( sib || h ) if side==left else sha2-256:4( h || sib )\n    idx //= 2 ; n = (n + 1) // 2\naccept iff h == merkle_root and p == len(proof)\n</code></pre> <p>Over LoRa, <code>leaves[]</code> are omitted from the manifest transfer. A serving node computes a block's proof on demand from its stored <code>leaves[]</code> and normally sends <code>OTA_PROOF</code> immediately after that block's paced <code>OTA_DATA</code>. <code>OTA_REQ_PROOF</code> remains the fallback for an older source or a lost proactive proof. The fetcher fills its own <code>leaves[i]</code> as each verified block lands.</p>"},{"location":"ota_protocol/#7-block-availability-staging-resume","title":"7. Block availability, staging &amp; resume","text":"<p>There is no separate availability structure. Block <code>i</code> is present &lt;=&gt; <code>leaves[i]</code> is non-erased (<code>!= FF FF FF FF</code>). Because <code>leaves[]</code> live in the staged flash region, availability survives reboot.</p> <p>Commit order per block (crash-safe): (1) verify proof, (2) write block payload to its offset, (3) write <code>leaves[i]</code> last. A power loss before step 3 leaves the slot erased -&gt; the block is simply re-fetched (idempotent). On boot a node rebuilds an in-RAM present-bitmap by scanning <code>leaves[]</code>.</p> <p>Resume (<code>OtaManager::resumeStaged</code> + <code>OtaStore::checkpoint</code>/<code>reopen</code>): an interrupted fetch resumes from the staged container after a reboot - re-parse the stored manifest, recompute geometry, count present blocks, continue fetching the holes (or jump straight to COMPLETE). The checkpoint cadence (persist progress every N committed blocks) is runtime-tunable (<code>ota config checkpoint &lt;N&gt;</code>, 0 = only finalized containers resume). Boot-time adoption is an automatic fetch decision: current <code>autofetch</code> must be enabled, the stored target must equal the node target, policy <code>signed</code> requires the signed bit, and an enabled running-version floor requires a strictly newer manifest. An explicit MID pull may deliberately resume an older or unsigned package and keeps target <code>0</code> as a MID-only wildcard. Stores keep <code>leaves[]</code> in RAM until flush and never auto-GC, preserving resumable progress. The debug/operator equivalent is <code>ota dev resume &lt;MID8&gt;</code>; after a reboot the MID is mandatory, while a no-argument form may only reuse a still-active session MID. It never uses the <code>nullptr</code> automatic-adoption path, so a malformed MID or no active MID fails closed.</p> <p>Flash-store note (RX-safe writes): a flash page-erase halts the CPU (~85 ms on nRF52) and starves LoRa RX, so the flash stores (<code>OtaStoreFlashNrf52</code>/<code>OtaStoreFlashEsp32</code>) coalesce writes to the erase unit (4 KB page / sector) and commit each once off the per-packet path - RAM stays O(one page), not O(image). A small delta that fits page 0 does zero flash I/O until COMPLETE.</p>"},{"location":"ota_protocol/#8-lora-ota-protocol","title":"8. LoRa OTA protocol","text":"<p>Carried in MeshCore packets with <code>PAYLOAD_TYPE_OTA = 0x0C</code>. Every OTA packet payload is:</p> <pre><code>[0]    ota_msg_type      (OtaMsgType, OtaFormat.h)\n[1..]  body              (fixed per type; encode/decode in OtaProtocol.cpp)\n</code></pre> <p>Message types:</p> <code>ota_msg_type</code> val routing purpose <code>OTA_ADV</code> 0x01 discovery tiny per-node beacon (discovery tier 1) <code>OTA_QUERY</code> 0x02 discovery ask a source for its catalog (discovery tier 2) <code>OTA_HAVE</code> 0x03 discovery the catalog reply (fragmented, digest-tagged) <code>OTA_GET_MANIFEST</code> 0x04 transfer request a manifest's fragments (<code>want_mask</code>) by <code>manifest_id</code> <code>OTA_MANIFEST</code> 0x05 transfer the manifest-minus-leaves, fragmented <code>OTA_REQ</code> 0x06 transfer request fragments from an adaptive flight of 1-4 blocks (<code>want_mask</code> per block) <code>OTA_DATA</code> 0x07 transfer one self-describing fragment of a block's data <code>OTA_REQ_PROOF</code> 0x08 transfer request/re-request a missing proof <code>OTA_PROOF</code> 0x09 transfer the merkle proof for one block <code>OTA_GET_LEAVES</code> 0x0A transfer request the target's <code>leaves[]</code> fragments (<code>want_mask</code>) - warm-start only <code>OTA_LEAVES</code> 0x0B transfer a fragment of the <code>leaves[]</code> array (for host-side seed leaf-diff) <ul> <li><code>manifest_id</code> = the manifest's <code>merkle_root</code> (4 bytes) - a compact content id present in every   transfer message, so a multi-mota server dispatches each request to the right image.</li> <li>Priority: <code>OTA_ADV</code>, <code>OTA_QUERY</code>, and <code>OTA_HAVE</code> enqueue at background priority 250. Once a fetch is   active, manifest, block request, data, and proof messages enqueue at primary priority 0. Relay-only   nodes classify the wire message identically, so a transfer stays primary across the complete path.</li> <li>Reliability is eventual: the fetcher re-requests only missing fragments after an adaptive deadline   derived from packet airtime, outstanding response packets, duty pacing, and path length. The manager may   still run a one-second maintenance tick, but that tick is not itself a retry timer. No hard ACKs or global   ordering are required.</li> <li>Relay envelope: OTA still uses a bounded flood-shaped mesh header so the same packets can cross the   configured number of hops without first discovering an addressed return path. During TempRadio each node   forwards one copy; active OTA packets do not use the generic flood-retry subsystem. The fetcher verifies   every block against the signed root, and a repeater without <code>ENABLE_OTA</code> can transport   <code>PAYLOAD_TYPE_OTA</code> opaquely without the manager, staging store, installer, or destination bootloader.</li> <li>Hop limit + duty cycle: OTA floods accumulate one path-hash per relay (the mesh's flood routing). A   node with the OTA manager accepts a packet only if it arrived within <code>ota config hops</code> hops (default 3;   <code>0</code> = direct only) and relays it only while still under that limit, appending its own hash. Relay-only   repeaters instead use their ordinary flood limits and forwarding filters. Discovery relays remain   lowest-priority and may be skipped when the packet pool runs low. Active-transfer relays bypass that   background pool gate and use priority 0; operators should therefore treat TempRadio as a dedicated OTA   maintenance window because the transfer can delay unrelated mesh traffic.</li> </ul>"},{"location":"ota_protocol/#81-two-tier-discovery","title":"8.1 Two-tier discovery","text":"<p>Because a node may serve many mOTAs (its own firmware plus an external folder - Section 10), discovery is split so the periodic beacon stays tiny regardless of catalog size:</p> <p>Tier 1 - <code>OTA_ADV</code> beacon (10 bytes, constant). Flooded as a short burst at boot, then every <code>advert_mins</code> minutes (default 24h; runtime-tunable via <code>ota config advert</code>, <code>0</code> disables the periodic re-advertise). It is also emitted immediately whenever the served set changes (e.g. a <code>motatool</code> folder is attached/detached), so peers learn about newly-available firmware without waiting for the next interval:</p> <pre><code>seeder_id[4]    advertiser node id = pubkey[0:4]; the QUERY address + distinct-source id\nn_motas         uint8 - count of complete servable mOTAs (saturates at 255)\nset_digest[4]   sha2-256:4 over the SORTED set of served manifest_ids (see below)\n</code></pre> <p><code>set_digest</code> is a content hash of the offering, not a counter: canonical across nodes, and it changes iff the set of served mids changes. A peer that has already catalogued this <code>{seeder, set_digest}</code> ignores the beacon (steady state is query-free). For a single served mota, <code>set_digest = sha2-256:4(mid)</code>.</p> <p>Tier 2 - <code>OTA_QUERY</code> -&gt; <code>OTA_HAVE</code> (on interest only):</p> <pre><code>OTA_QUERY  (flood):  seeder_id[4]  set_digest[4]  filter_target(uint32) want_fragments(uint32)\n                     # filter_target 0 = everything; want_fragments 0 = every fragment\nOTA_HAVE   (flood):  seeder_id[4]  set_digest[4]  frag_idx(1) frag_total(1) n_rows(1)  rows[]\n  HaveRow (16 bytes, OTA_HAVE_ROW_BYTES): mid[4] target_id(4) fw_version(4) codec_id(1) flags(1) have_count(2)\n</code></pre> <p><code>have_count</code> is the number of blocks the source holds (<code>== block_count</code> for a complete offered image). Receivers do not advertise partial or completed downloads as new sources.</p> <p>A node interested in a source's offering schedules a QUERY; the source replies with its full catalog as <code>OTA_HAVE</code> rows (fragmented if they exceed one packet - 10 rows per fragment). A receiver marks the catalog complete only after all <code>frag_total</code> fragments arrive. If any are missing after the recovery timeout, it sends another QUERY whose <code>want_fragments</code> bitmap names only the holes. <code>want_fragments</code> is an append-only extension: an original 13-byte QUERY is still accepted and means \"send every fragment.\" The heavy manifest is fetched per-mid only on commit (Section 8.3).</p> <p>Fragment numbers are canonical pages of the complete catalog sorted by <code>manifest_id</code>. <code>filter_target</code> may remove rows from a requested page (and can therefore produce an empty fragment), but it never renumbers pages or changes <code>frag_total</code>. This keeps missing-fragment recovery unambiguous when filtered and unfiltered queries for the same <code>{seeder, set_digest}</code> are overheard together.</p>"},{"location":"ota_protocol/#82-anti-storm-mandatory-at-mesh-scale","title":"8.2 Anti-storm (mandatory at mesh scale)","text":"<p>If 50 neighbours all queried a new beacon at once, the mesh would collapse. Mitigations (gossip/mDNS pattern), all in <code>OtaManager</code>:</p> <ul> <li><code>OTA_HAVE</code> is flooded and digest-tagged. EVERY node that overhears it caches the rows passively   (keyed by <code>{seeder, set_digest}</code>) - no query of its own needed.</li> <li>Jittered query: a peer needing a catalog schedules its <code>OTA_QUERY</code> after a random delay   <code>OTA_QUERY_MIN_MS (300) + rand(OTA_QUERY_SPREAD_MS (4000))</code>, derived from <code>id +/ digest +/ self</code>.</li> <li>Overhear suppression: during the jitter window, overhearing another QUERY that covers the same scope,   or completing the HAVE fragment set for the same <code>{seeder, set_digest}</code>, cancels the pending query.</li> <li>Per-source recovery: each seeder has independent query/retry state. One source cannot overwrite another   source's timer, and a partial reply requests only missing fragments after 15 seconds (five bounded retries,   then another source ADV or explicit <code>ota ls</code> can start a fresh series).</li> </ul> <p>Net effect: a digest change costs ~1 query + ~1 HAVE flood mesh-wide; a stable mesh is query-free.</p>"},{"location":"ota_protocol/#83-fetch-handshake","title":"8.3 Fetch handshake","text":"<pre><code>fetcher                                   server (any node that has the mid)\n  OTA_GET_MANIFEST(mid, want_mask)  &gt;     (want_mask=0xFFFF first; only missing fragments on retry)\n                               &lt;-------   OTA_MANIFEST(mid, frag_idx, frag_total, bytes)   x requested frags\n  (reassemble manifest, verify, compute geometry: BC, block_size, payload_size)\n  for each adaptive flight of missing blocks (starts at 1, grows on clean flights):\n    OTA_REQ(mid, {block_idx, want_mask}[]) &gt;  (one packet; all fragments first, only holes on recovery)\n                               &lt;-------   OTA_DATA(mid, block_idx, frag_off, data) x requested frags/block\n                               &lt;-------   OTA_PROOF(mid, block_idx, n_proof, proof) x requested blocks\n    (independently reassemble + verify each block, but remain RX-silent until the flight drains)\n    [after adaptive deadline: recover one block's holes, or OTA_REQ_PROOF for a missing proof]\n    (clean flight grows by one block; recovered flight halves the next width)\n  when all blocks present: verify full merkle_root + image_hash -&gt; COMPLETE\n</code></pre> <p>Before allocating or writing the selected store, the receiver parses the reassembled manifest and requires its <code>merkle_root</code> to equal the requested/wire <code>manifest_id</code> and its <code>target_id</code> to equal the catalog or explicit-pull target that opened the receive slot. The wire envelope and HAVE row are advisory; they cannot label and stage a different manifest.</p>"},{"location":"ota_protocol/#84-message-bodies-transfer","title":"8.4 Message bodies (transfer)","text":"<p>All offsets after the 1-byte type. Encoders/decoders in <code>OtaProtocol.cpp</code>; constants in <code>OtaManager.h</code>.</p> <pre><code>OTA_GET_MANIFEST:  manifest_id[4]  want_mask(uint16)   # bit k = send manifest fragment k; 0xFFFF = all\nOTA_MANIFEST:      manifest_id[4]  frag_idx(1)  frag_total(1)  bytes[]     # up to OTA_MF_FRAG=176 B/frag\nOTA_REQ:           manifest_id[4]  { block_idx(uint16)  want_mask(uint16) }[1..4]\n                   # legacy: bit k requests its 160-byte fragment\n                   # v2: bit15=marker, bit14=allow transport DEFLATE,\n                   #     bit13=2 KiB descriptor, bits0..12=fragment bitmap;\n                   #     bit12 must be zero when bit13 is set (0xFFFF stays legacy)\nOTA_DATA legacy:   manifest_id[4]  block_idx(uint16)  frag_off(uint16)  data[&lt;=160]\nOTA_DATA v2:       manifest_id[4]  block_idx(uint16)  descriptor(uint16)\n                   stream_id[4]  data[&lt;=171]\n                   # deployed 1 KiB descriptor: bit15=marker, bit14=DEFLATE,\n                   #   bits13..10=fragment, bits9..0=complete encoded length minus one\n                   # negotiated 2 KiB descriptor: bit15=marker, bits14..11=fragment,\n                   #   bits10..0=complete encoded length minus one; DEFLATE iff that\n                   #   length is strictly less than the manifest-derived raw block length\nOTA_REQ_PROOF:     manifest_id[4]  block_idx(uint16)\nOTA_PROOF:         manifest_id[4]  block_idx(uint16)  n_proof(1)  proof[]   # n_proof x 4 bytes\nOTA_GET_LEAVES:    manifest_id[4]  want_mask(uint16)   # bit k = send leaves fragment k; 0xFFFF = all\nOTA_LEAVES:        manifest_id[4]  frag_idx(1)  frag_total(1)  bytes[]      # up to OTA_LEAVES_FRAG=176 leaf bytes\n</code></pre> <ul> <li> <p>Warm-start / leaf-diff (<code>OTA_GET_LEAVES</code>/<code>OTA_LEAVES</code>) - motatool folder-capture only. Capturing a   device's firmware into a <code>motatool serve</code> folder is slow (a full image is hundreds of blocks). Because   builds here are non-deterministic, you cannot reproduce the exact target on the host - but a similar   build (e.g. a fresh recompile) is ~99% identical. So <code>motatool serve --seed &lt;similar.mota&gt;</code> stages that   build's payload into the destination <code>.part</code>, and <code>ota pull &lt;mid8&gt; folder validate</code> makes the fetcher (1) bulk-   fetch the target's <code>leaves[]</code> via <code>OTA_GET_LEAVES</code>/<code>OTA_LEAVES</code> (bitmap-fragmented with a <code>want_mask</code>, same   anti-burst rule as <code>OTA_MANIFEST</code>), (2) recompute the merkle root from them and check it equals the   manifest root (authenticate), then (3) keep every seeded block whose leaf matches and pull full <code>OTA_DATA</code>   only for the blocks that differ. The <code>want_mask</code> is a fixed uint16, so <code>leaves[]</code> is capped at   <code>OTA_LEAVES_MAXFRAG=16</code> fragments (<code>OTA_DIFF_MAX_BLOCKS=704</code> blocks); larger images just fall back to a full   fetch. Normal P2P nodes never use this - they target only the blocks they want; the only always-on part   is answering <code>OTA_GET_LEAVES</code> with leaves the node already holds, so any node's firmware can be captured.</p> </li> <li> <p>Negotiated 171-byte fragments: the deployed profile remains unchanged: <code>frag_off</code> is a byte offset and   <code>data[]</code> carries at most 160 bytes. A new fetcher marks an <code>OTA_REQ</code> row as v2. For a deployed 1 KiB block,   its first request also includes every fragment bit needed by the legacy representation, so an old source can   answer it completely. The extended 2 KiB profile reserves bit 12 as zero; this both fits its twelve v2   fragments and ensures the deployed <code>0xFFFF</code> legacy all-fragments request is never misclassified. Receipt of   untagged <code>OTA_DATA</code> switches the fetch session to the old geometry. If no v2 data appears by the first   adaptive deadline, the fetcher retries with an ordinary legacy mask. New sources answer v2 with a packed descriptor, a repeated 4-byte representation   ID, and exactly 171 data bytes except the final fragment. A raw 1 KiB block falls from seven data packets to   six; a raw 2 KiB block falls from thirteen to twelve. Message type IDs do not change, so multi-hop relays   continue to forward request/data/proof packets opaquely with the same priority.</p> </li> <li>Transport-only DEFLATE: a fetcher sets the v2 DEFLATE-permission bit only when its application includes   and configures the decoder. A source may encode each logical block as an independent raw RFC 1951 stream   with full stored, fixed-Huffman, and dynamic-Huffman support (<code>BTYPE=0/1/2</code>). Compression is used only when   strictly smaller, otherwise the source returns raw v2 data. The   receiver inflates to the manifest-derived block length, then performs the unchanged Merkle proof and writes   the original bytes to staging. Thus staging and bootloader apply remain uncompressed. Deployed 1 KiB   <code>.mota</code> containers remain compatible; new 2 KiB containers require a receiver advertising the extended   descriptor. Format-3 bootloader packages retain their strict 1 KiB geometry. The 4-byte <code>stream_id</code> is   SHA-256:4 of the complete raw or compressed   representation and appears in every fragment. A receiver locks <code>{encoding, encoded length, stream_id}</code> for   a block, preventing fragments from independently encoded seeders from being mixed. After one sparse retry,   a second stalled interval clears the full in-flight window and switches the session to legacy geometry, so   a vanished v2 seeder cannot prevent an older source from taking over; proof verification remains unchanged.   Every <code>ENABLE_OTA</code> MeshCore application registers the vendored tinf 1.2.1 full raw decoder; its wrapper   bounds output to the exact logical block length and rejects truncation, malformed streams, and trailing   whole bytes. Builds without OTA do not link the decoder. This application capability is independent of the   bootloader because transport data is inflated before the unchanged staged container is written.</li> <li>Adaptive flight size is not signed block size. Each slot holds one manifest-defined block: 1 KiB for   deployed application containers or 2 KiB for new ones. A clean link changes how many complete blocks one   <code>OTA_REQ</code> names: 1, then 2, then 3, then the compiled cap. It never changes block geometry. Two KiB halves   the leaf, block-request, and proof count for a payload while giving each independent DEFLATE stream a larger   history window.</li> <li>Append-only request-window compatibility: the first four-byte request row is exactly the original   <code>block_idx + want_mask</code> body. Old sources decode that row and ignore appended bytes. New sources queue all   rows. If a new fetcher meets an old source, the unserved tail rows eventually time out and are recovered as   ordinary single-row requests; the dirty flight then contracts. Old fetchers continue sending nine-byte   single-row requests, which new sources accept normally.</li> <li>Fragment-level requests (anti-deadlock + anti-congestion): <code>OTA_REQ</code>, <code>OTA_GET_MANIFEST</code>, and <code>OTA_QUERY</code>   carry fragment masks. For catalog discovery, <code>want_fragments</code> is a 32-bit bitmap and covers the protocol   maximum 255-row catalog (26 fragments at the current packet size). For block and manifest transfer, the   <code>want_mask</code> is 16 bits. A fetcher requests the full set on the first ask   (<code>(1&lt;&lt;nf)-1</code>, or <code>0xFFFF</code> before <code>frag_total</code> is known) and only the still-missing bits on any retry,   so recovering one lost fragment re-sends one fragment, not the whole block/manifest. This is essential on   half-duplex radios: re-requesting a whole multi-fragment burst let the periodic retry (a transmit) collide   with the tail of the in-flight burst and drop the same fragment forever - a hang. Requesting only the hole   removes the burst, so there is nothing to collide with. The block/manifest mask matches the 16-bit   reassembly bitmap (&lt;=16 fragments/block; 1 KiB is 7 legacy or 6 raw-v2 fragments; 2 KiB is 13 legacy or 12   raw-v2 fragments). <code>OTA_PROOF</code> is a single packet and needs no mask.</li> <li>Data and proof remain separate packets, without a normal extra round trip. A server retains requested   blocks in a bounded descriptor queue, admits at most one response per main-loop pass, and sends one   <code>OTA_PROOF</code> after each block's requested fragments. Before admitting that proactive proof, the source leaves   an airtime/duty-aware 100-3000 ms RX turnaround gap. It accounts for one active transmission plus the two   paced-response queue credits. A legacy receiver uses the gap to send its immediate   <code>OTA_REQ_PROOF</code>; receiving that explicit request bypasses the remaining gap, avoiding a proof/request   collision and an otherwise multi-second legacy retry. A newer receiver uses an airtime/path-aware proof   grace (never less than 500 ms) and defers <code>OTA_REQ_PROOF</code> while any flight slot still expects DATA. Thus a   missing early proof cannot make the receiver transmit into the rest of a legitimate half-duplex response   train. After the complete-flight deadline, only one slot's missing fragments/proof is requested at a time.</li> </ul>"},{"location":"ota_protocol/#85-sizing-against-max_packet_payload-184","title":"8.5 Sizing against <code>MAX_PACKET_PAYLOAD = 184</code>","text":"message fixed overhead payload/packet <code>OTA_DATA</code> legacy 9 B (type+mid4+idx2+off2) <code>OTA_FRAG_DATA = 160</code> -&gt; 7 raw frags/1 KiB or 13/2 KiB <code>OTA_DATA</code> v2 13 B (legacy header + stream ID) <code>OTA_FRAG_DATA_V2 = 171</code> -&gt; 6 raw frags/1 KiB or 12/2 KiB; fewer when compressed <code>OTA_MANIFEST</code> 7 B <code>OTA_MF_FRAG = 176</code> -&gt; signed manifest ~ 2 frags <code>OTA_HAVE</code> 12 B 10 rows x 16 B per fragment <code>OTA_PROOF</code> 8 B up to ~44 sibling digests (&gt;&gt; any real tree) <p>A served mota supports up to 1024 leaves in the default 4 KiB proof scratch (about 2 MiB of payload at the new 2 KiB default, or 1 MiB for a deployed 1 KiB container); larger self-images pass a bigger scratch buffer.</p>"},{"location":"ota_protocol/#86-temporary-radio-and-transfer-boundary","title":"8.6 Temporary-radio and transfer boundary","text":"<p>OTA packets may cross normal mesh relay hops, but each participating node processes or relays them only while its <code>tempradio</code> window is actually running. A receiver selects missing blocks in serial order into a bounded request flight. Every session starts with one block. A clean completed flight increases the next request by one block; a flight requiring fragment/proof recovery halves the next width (<code>4 -&gt; 2</code>, <code>3 -&gt; 2</code>, <code>2 -&gt; 1</code>). The default compiled cap is two blocks; the RAK3401 LoRa-OTA target caps at four, so it probes <code>1 -&gt; 2 -&gt; 3 -&gt; 4</code>. All rows are sent in one backward-compatible <code>OTA_REQ</code>, and no freed slot is refilled until the current flight is finished. It never serves partial blocks. A normal install receiver never re-advertises its completed download. An SD archive node is the deliberate exception: after a fully proof-verified container is published to its persistent archive, it registers that complete file as a MotaSource and advertises it as a new seeder. This keeps each active transfer as one transmitter and one receiver while still allowing active temporary-radio repeaters between them and persistent archive nodes to improve future availability.</p> <p>TempRadio is treated as a private maintenance network. Active transfer packets use priority 0, bypass the public-flood receive holdoff, use the full transmit budget without overwriting the saved normal-radio airtime factor, retain the relay role's airtime-scaled transmit collision window, and do not schedule generic flood retries. Deployed firmware predating that TempRadio budget override can be accelerated manually with a saved <code>get af</code> / temporary <code>set af 0</code> / restore sequence. The bounded serving queue admits at most two DATA/PROOF packets ahead of the radio while preserving at least four free packet-pool entries. CAD remains enabled to arbitrate the half-duplex channel, but its busy retry is scaled to one-quarter of a packet airtime and clamped to 5-50 ms instead of the ordinary 120-360 ms cadence. Discovery traffic keeps collision jitter and background priority. The fetch deadline uses the active radio's measured maximum-packet airtime, remaining DATA/PROOF packet count, dispatcher airtime factor, and longest observed path (falling back to the configured hop horizon before one is observed), with bounded guard time. Faster SF/BW settings therefore recover loss sooner; slower or multi-hop settings do not spuriously re-request a response still on air. These changes remove software waits and duplicate bursts; they do not remove the one required forwarding transmission per hop.</p>"},{"location":"ota_protocol/#9-identity-trust-versioning","title":"9. Identity, trust &amp; versioning","text":"<ul> <li><code>target_id</code> (4 B): <code>sha2-256:4(pio_env_name)</code> (little-endian uint32). The env name uniquely captures   hardware and role/partition, so a node auto-fetches only matching firmware (a companion image is not   fetched onto a repeater even though it shares <code>hw_id</code>). It is self-described in the firmware's EndF   (Section 2, written by <code>pio_endf.py</code>) and read via <code>ota_self_firmware()</code>, so it is correct on any build;   <code>-D MOTA_TARGET_ID</code> / <code>MainBoard::getOtaTargetId()</code> is the fallback when no EndF identity is present.   <code>tools/mota</code> reads it from the firmware's EndF (or <code>--target-env</code>). A manual <code>ota pull</code>/<code>want</code> can override   target (deliberate role switch); the <code>hw_id</code> brick-safety gate (Section 4) still applies at apply time.</li> <li><code>target_id</code> vs <code>hw_id</code> - complementary, not redundant: <code>target_id</code> is the fetch-routing key   (hw + role + partition); <code>hw_id</code> is the human-readable brick-safety key (hardware only). Same board, two   roles =&gt; same <code>hw_id</code>, different <code>target_id</code>.</li> <li>Naming a <code>target_id</code> locally: only the 4-byte <code>target_id</code> ever travels on the wire. To show which   board/role a target is, a node (and <code>motatool</code>) reverse-looks-it-up in <code>src/helpers/ota/OtaTargets.h</code> -   a generated <code>target_id -&gt; env-name</code> table covering every <code>ENABLE_OTA</code> env (<code>tools/mota/gen_targets.py</code>,   resolved from <code>pio project config</code>). So <code>ota ls</code> can render <code>[Heltec_v3_repeater]</code> for a neighbour's   beacon without the string being transmitted. Unknown IDs show as raw <code>hw XXXXXXXX</code> / <code>N/A</code> values.</li> <li><code>fw_version</code>: packed comparable uint32 (<code>MAJOR&lt;&lt;24 | MINOR&lt;&lt;16 | PATCH&lt;&lt;8 | pre</code>); also self-described   in EndF. <code>ota ls</code> prints the stable eight-hex manifest ID and uses <code>[same target]</code>, <code>[unsupported]</code>, or   <code>[rescue]</code> after combining target equality with the local codec, bootloader, and EndF preflight. A known   different target is rendered by environment name; an unknown/unset target remains raw or <code>?</code>. Target   equality is routing information, not by itself an assertion that an image is safe to install.</li> <li><code>hw_id</code>: 32-byte NUL-padded ASCII hardware tag inside the signed head. The applier refuses a <code>.mota</code>   whose <code>hw_id</code> differs from the device's own tag (empty on either side = permissive). Brick-safety   independent of signature.</li> <li>Signing &amp; allowlist: a node keeps a runtime allowlist of trusted Ed25519 signer pubkeys (none embedded   in firmware; <code>ota key add/list/rm</code>). A <code>.mota</code> is eligible for auto-install only if signed by an   allowlisted key, the signature verifies, <code>image_hash</code> matches, and its nonzero signed <code>fw_version</code> is   strictly greater than the running hash-valid EndF version. Both catalog admission and final automatic   apply enforce the version floor, so a lying HAVE row cannot bypass it. Manual <code>ota install</code> is the explicit   equal-version/rollback override and generally permits unsigned packages,   but a package that claims to be signed must have a valid signature from an allowlisted key or it is rejected.   The removable-SD target is stricter: every application install needs a valid allowlisted signature because   the app mints an authenticated one-reset media authorization for OTAFIX.   Transfer needs no trust - blocks are content-addressed against the manifest's merkle root.</li> <li>Policies (persisted): <code>autofetch</code> in {off, any, signed} (default off) gates automatic block fetching of   own-target adverts; <code>autoinstall</code> in {off, trusted} (default off) gates auto-apply of a COMPLETE signed +   allowlisted fetch. Conservative defaults: a fresh node discovers + announces but never fetches/installs   without operator intent.</li> <li>Supersession: a newer version announced mid-download does not abort the in-progress transfer   (finish-current).</li> </ul>"},{"location":"ota_protocol/#10-multi-mota-serve-the-external-folder-relay","title":"10. Multi-mota serve &amp; the external \"folder\" relay","text":"<p>A node serves a set of mOTAs: its own firmware plus, optionally, an external folder of <code>.mota</code> files it relays without holding them in flash. To peers it simply \"has N mOTAs\"; the relay is trustless (fetchers verify everything). The serve side (<code>OtaManager</code>) keeps a lightweight registry of what it advertises and two resident \"views\": <code>view0</code> (its own firmware) and one on-demand view loaded from a source when a request targets an external mota. Every fetch message carries <code>manifest_id</code>, so dispatch is a registry lookup.</p> <p>The USB/TCP host-folder link can also be a pull destination (the reverse direction): <code>ota pull &lt;mid8&gt; folder</code> fetches a <code>.mota</code> off the mesh and streams it onto the host as <code>&lt;mid&gt;.mota</code> via the seeder STORAGE ops (<code>OP_STAT/BEGIN/WRITE/SREAD/FIN</code>, see <code>MotaSeederProto.h</code>), using a <code>FolderMotaStore</code> as the fetch's <code>OtaStore</code> instead of RAM/flash. This captures an exact copy of a device's firmware - e.g. to build a delta against firmware you don't have. Resume is bookkeeping-free: <code>BEGIN</code> 0xFF-fills the file and, on reconnect after a link drop (the fetch PAUSES, holding progress on the host - no RAM/flash fallback), <code>STAT</code>+<code>SREAD</code> let the fetcher recompute and refill only the missing blocks. The phone-oriented BLE link is deliberately source-only and does not register a folder destination.</p>"},{"location":"ota_protocol/#101-the-motasource-abstraction-otasourceh","title":"10.1 The <code>MotaSource</code> abstraction (<code>OtaSource.h</code>)","text":"<p>Transport-agnostic provider of one or more complete <code>.mota</code> as random-access bytes. The same serve code drives USB-serial, BLE, a WiFi URL list, an NFS/samba mount, etc. - only <code>read()</code> differs.</p> <pre><code>struct MotaDesc {                      // catalog metadata + region offsets (no whole image in RAM)\n  uint8_t mid[4]; uint32_t target_id, fw_version; uint8_t codec_id, flags;\n  uint8_t block_size_log2, source_caps;\n  uint32_t total_size, leaves_off, block_count, payload_off, payload_size;\n};\nclass MotaSource {\n  virtual uint8_t count();                                  // # mOTAs offered\n  virtual bool    describe(uint8_t idx, MotaDesc&amp; out);     // metadata + offsets\n  virtual bool    read(uint8_t idx, uint32_t off, uint8_t* buf, uint32_t len);   // random-access bytes\n  virtual bool    read_deflated_block(uint8_t idx, uint16_t block,\n                                      uint8_t* buf, uint16_t cap, uint16_t* len); // optional raw RFC 1951\n};\n</code></pre> <p>To serve an external mota the node reads its manifest-minus-leaves + <code>leaves[]</code> into RAM (&lt;=4 KiB for &lt;=1024 blocks) and streams payload blocks from the source on demand; proofs are generated from the read leaves.</p>"},{"location":"ota_protocol/#102-the-mota-seeder-transport-motaseederprotoh","title":"10.2 The <code>mota-seeder</code> transport (<code>MotaSeederProto.h</code>)","text":"<p>A <code>MotaSource</code> is fed by a host that serves a folder over the device's USB serial (the same console the CLI uses - no extra hardware), on an ESP32 WiFi companion or FULL ESP32 role over WiFi (TCP), or on an nRF52 Full Companion over an encrypted BLE GATT service. The host is the standalone Rust tool <code>motatool</code> (<code>motatool serve --serial &lt;port&gt;</code> / <code>--tcp &lt;host[:port]&gt;</code>, which also builds + verifies + inspects <code>.mota</code>). The device only emits request frames while actively serving a fetch, and reads the reply synchronously, so over the shared USB console binary frames coexist with the text CLI/logs (resync on magic + checksum). Little-endian, XOR-checksummed:</p> <pre><code>request  (device -&gt; host):  'M' 'S'  op(1)  args...                 xsum(1 = XOR of op+args)\nresponse (host -&gt; device):  'm' 's'  op(1)  status(1)  payload...    xsum(1 = XOR of all prior)\n\nOP_COUNT     0x01   args: -            -&gt; payload: count(1)\nOP_DESCRIBE  0x02   args: idx(1)       -&gt; payload: MotaDesc wire (38 B)\nOP_READ      0x03   args: idx(1) off(4) len(2)  -&gt; payload: len bytes\nOP_DEFLATE_BLOCK 0x09 args: idx(1) block(2) off(2) len(2)\n                         -&gt; payload: total_encoded_len(2) + requested bytes\nMotaDesc wire (38 B): mid[4] target_id(4) fw_version(4) codec(1) flags(1)\n                      total_size(4) leaves_off(4) block_count(4) payload_off(4) payload_size(4)\n                      block_size_log2(1) source_caps(1) reserved(2)\nstatus: 0 = OK, non-zero = error (out of range / past EOF).\n</code></pre> <p><code>SerialMotaSource</code> splits logical reads into replies of at most 192 payload bytes. A manifest's leaf table can exceed 256 bytes and new payload blocks are normally 2 KiB; requesting either in one transaction can overrun common USB CDC/UART receive rings even though the host successfully wrote the complete reply. Chunking is internal to the transport and does not change <code>OP_READ</code> or the <code>MotaSource</code> random-access contract.</p> <p><code>OP_DEFLATE_BLOCK</code> lets a host-folder source perform the optional transport compression without linking an encoder into the embedded seeder. <code>len=0, off=0</code> queries the exact encoded length; subsequent chunks are at most 190 bytes, keeping the total response payload at 192 bytes. The host independently encodes each manifest payload block as ordinary raw RFC 1951 at level 9. It returns an error for an invalid range, an unsupported operation, or a result that is not smaller than the raw block; <code>SerialMotaSource</code> then serves the ordinary raw v2 representation. A supporting host sets <code>source_caps bit 0</code> in every descriptor. Older hosts leave that formerly-reserved byte zero, so upgraded firmware skips the optional request instead of waiting for an old daemon that silently ignores unknown operations.</p> <p>Manifest fragments are retained as bounded response jobs and admitted one at a time. Their source-side gap follows the active maximum packet airtime and dispatcher duty spacing, clamped to 100-1000 ms. The 100 ms floor protects fast radios' TX-to-RX turnaround; the cap keeps the receiver's one-second manifest progress/retry observation responsive. The source uses the same radio-aware 100-3000 ms drain/turnaround gap before an unsolicited block proof, but immediately serves a legacy receiver's explicit <code>OTA_REQ_PROOF</code>. Relay collision delay is a separate setting: active OTA floods honor the relay role's configured <code>txdelay</code>, and the deployment runner temporarily uses <code>0.3</code> on managed relays.</p> <p>What to plug into <code>--serial</code>. Use the USB serial console of an OTA-enabled MeshCore node built with <code>OTA_FOLDER_SERIAL</code>. The node must have a working LoRa radio plus an <code>ota folder on</code> command; that command confirms it can host and advertise the folder. A KISS modem will not work: KISS firmware exposes a TNC/KISS frame interface, not the MeshCore CLI and <code>mota-seeder</code> request/response transport. An ESP32 WiFi companion or FULL ESP32 role with active WiFi is the alternative source connection: use its dedicated seeder port with <code>motatool serve --tcp &lt;host&gt;:5001</code>. An nRF52 Full Companion can instead pair with a phone or Linux host, subscribe to its mOTA request characteristic, and use protocol-v14 <code>CMD_BLE_MOTA_SOURCE</code>. That BLE path is source-only; it does not expose the reverse <code>FolderMotaStore</code> capture operations.</p> <p>Device CLI: <code>ota folder on</code> (attach + announce), <code>ota folder</code> (list), <code>ota folder off</code>. Build flag <code>OTA_FOLDER_SERIAL</code> (default stream = console <code>Serial</code>; override <code>OTA_FOLDER_SERIAL_STREAM</code> + define <code>OTA_FOLDER_SERIAL_BEGIN</code> for a dedicated UART). ESP32 WiFi companions and FULL ESP32 roles run a <code>WiFiServer</code> on the dedicated seeder port (<code>OTA_SEEDER_TCP_PORT</code>, default <code>5001</code>) while WiFi is usable. On a companion it is separate from the app port (<code>TCP_PORT</code>, default <code>5000</code>); on infrastructure roles it is separate from WebConfig and browser OTA on port 80. The node auto-attaches the source when a seeder client connects and detaches when it closes (no <code>ota folder on</code> needed over TCP). An already-active serial folder causes a TCP client to be rejected instead of silently replacing it. Verified on hardware: a RAK4631 relays a host folder to a Heltec V3 over one USB cable, and a host feeds a Heltec V3 over WiFi (<code>:5001</code>) while the companion serves a phone on <code>:5000</code> - every block merkle-checked.</p> <p>The attach reply and bare <code>ota folder</code> report <code>host=advertised/offered</code>. The registry is RAM-bounded (<code>OTA_MAX_SERVE</code>, with the node's own firmware consuming one slot), so a host may correctly index more valid files than this particular firmware can advertise. Omitted entries are now reported instead of silently disappearing. Operators should split a large chain or use a higher-capacity/SD seeder when the two counts differ.</p> <p>Transport-agnostic by design. The request/response semantics (<code>COUNT</code> / <code>DESCRIBE(idx)</code> / <code>READ(idx, off, len)</code> over a folder catalog) are independent of the link. The 2-byte magic + XOR checksum + resync framing above exists for the shared USB-UART (an unframed byte stream); it is harmless over a reliable stream and the WiFi (TCP) transport reuses it as-is - both ends just treat the socket as a byte stream (on-device, <code>SerialMotaSource</code> runs verbatim over an Arduino <code>Stream</code>-compatible <code>WiFiClient</code>; <code>motatool</code>'s <code>TcpTransport</code> mirrors its <code>SerialTransport</code>). The nRF52 Full Companion's BLE GATT path also reuses the exact frame and checksum. Device requests are notifications on a dedicated characteristic and host responses are ordered write-with-response fragments on a second characteristic. Keeping the same framing makes retries and corruption handling identical across USB, TCP, and GATT. The Linux reference implementation is <code>tools/ble_mota/ble_mota_seeder.py</code>; a phone app can implement the same transport-free catalog operations.</p>"},{"location":"ota_protocol/#11-cli-surface-otaclicpp","title":"11. CLI surface (<code>OtaCli.cpp</code>)","text":"<p>User-facing OTA data should travel via <code>CMD_OTA_*</code> companion binary frames; the text CLI below is debug/operator oriented and replies are <code>snprintf</code>-bounded into a 160-byte buffer.</p> <p>Commands take intuitive aliases (matched by the first word; see <code>is_cmd</code> in <code>OtaCli.cpp</code>) so they're easy to type and read - <code>status</code>/<code>neighbors</code>/<code>pull</code>/<code>drop</code>/<code>applydelta</code> are the canonical names, the aliases are the recommended user-facing forms. Output is plain-language (a user-facing guide lives at ota_user_guide.md).</p> <pre><code>ota help | ? | h                   list the commands\nota status | st  (or bare `ota`)   plain-language: running fw, the one fetch session (state/%/id), serving, keys\nota ls | neighbors | nbrs | updates | n [page]   paged updates (queries sources; rows arrive async via OTA_HAVE)\nota get | pull | download &lt;mid8|#index&gt; flash [rescue] | folder [validate]\n                                      fetch by stable mid8 (preferred) or current page index\nota install | apply | applydelta   verify + approve + (ESP32) apply / (nRF52) reboot-to-bootloader\nota rescue install &lt;base_hash16&gt;  internal-flash nRF52 only: recover from failed app-side EndF validation\nota bootloader [status]           capable allowlisted nRF52 repeater: installed BL identity/caps + staged confirmation\nota bootloader install &lt;MID8&gt; &lt;HASH16&gt;\n                                      explicitly verify/arm one complete trusted v3 package; never automatic\nota cancel | drop | stop           drop the fetch; durably invalidate device staging, or retain a folder partial for resume\nota announce | adv                 serve self + send a beacon now\nota self | id                      print this firmware's EndF (body/image size, base_hash)\nota qspi | storage                 QSPI nRF52 only: JEDEC/SR1/stage/latched storage error (read-only)\nota folder | fold [on|off]         attach/detach an external .mota folder (host daemon) ; bare = list\nota config | cfg | set [autofetch|autoinstall|checkpoint] ...   show/set persisted policy\nota key | keys [add|rm &lt;hex&gt;]      trusted signer allowlist ; bare = list\nota dev ...                        bring-up helpers (stage/recv/serve/resume &lt;MID8&gt;/verify)\n</code></pre> <p>For a device-backed pull, current firmware returns success only after the persistent store can no longer be reopened; flash/SD/QSPI I/O or readback failure is reported as an error even though the in-memory manager session was dropped. For a <code>folder</code> pull, cancellation detaches the live transfer but deliberately leaves the host <code>.part</code> file available for a later resume. If the shared receive engine is currently performing the MeshTower SD auto-archive capture, cancellation likewise detaches that archive transfer and retains its <code>.part</code> file; it does not erase the unrelated manual-install store.</p> <p></p>"},{"location":"ota_protocol/#12-apply-bootloader-contract","title":"12. Apply &amp; bootloader contract","text":"<ul> <li>ESP32 (A/B): applied in-firmware via the detools decoder into the inactive OTA slot   (<code>OtaApply.cpp::ota_apply_detools_mota</code> + <code>OtaStoreFlashEsp32</code>), then set-boot + reboot (power-safe,   rollback-capable). No bootloader changes. Erase ranges must be sector-aligned (4096).</li> <li>nRF52 (single-slot): the running firmware never flashes the app. <code>ota install</code> verifies the   container fully (<code>image_hash</code>, codec, signature/allowlist, <code>hw_id</code>, and <code>base_hash</code> for a delta), writes   <code>approval = \"APRV\"</code>, then reboots into the modified bootloader   (<code>Adafruit_nRF52_Bootloader_OTAFIX</code>). The bootloader:</li> <li>locates the staged <code>.mota</code> in the approved internal, raw-SD, or raw-QSPI store without trusting an      unchecked stored size,</li> <li>re-checks <code>TRAILER</code>, <code>image_hash</code>, and <code>approval == \"APRV\"</code>; for a delta it also checks that      <code>base_hash</code> equals the running firmware's <code>EndF.body_hash</code> (recomputed by scanning for <code>EndF</code> - never      trust <code>bank_0_size</code>),</li> <li>writes a full external-media payload or applies the in-place codec over the app region, then boots only      if the result hashes to <code>image_hash</code>.</li> <li>nRF52 internal staging ceiling: an internal-store application derives the ceiling from facts available   in every build, not a board-name list. A companion that actually links the internal ExtraFS datastore stays   below <code>0xD4000</code>; a default linker region or a role that does not mount ExtraFS can reclaim the unused   100 KiB through <code>0xED000</code>. An internal bootloader-self-update target keeps that normal linker and ceiling;   it does not reserve a second boot-package or scratch region. The application uses a larger-than-legacy   window only when the   installed bootloader advertises the GPREGRET2 ceiling-handoff capability. The bootloader treats every   unknown/legacy handoff value as   <code>0xD4000</code>, and accepts a container only at the bottom-aligned position for the selected ceiling.</li> <li>nRF52 dynamic apply window: the post-build hook records the resolved app base, linked app end,   internal-ExtraFS/SD/QSPI storage flags, and desired staging ceiling immediately before <code>EndF</code>. <code>motatool</code> reads that authenticated   firmware record and chooses <code>memory_size</code> from the actual patch size and bottom-aligned stage address;   firmware without the record retains the conservative <code>0x98000</code> default. Before writing <code>APRV</code>, an   internal-store app validates the staged-address bound; an external SD/QSPI app validates the full detools   geometry against the application workspace. The bootloader independently parses and validates the same   geometry before its first application write. Expanded auto-sized packages require a bootloader   with the ceiling-handoff capability; use <code>--inplace-memory 0x98000</code> when intentionally targeting an older   bootloader and the images still fit that window.</li> <li>nRF52 EndF rescue: <code>ota rescue install &lt;base_hash16&gt;</code> is a pre-provisioned recovery path for an   internal-flash nRF52 application that still runs but cannot validate its own EndF identity. It refuses   when normal EndF validation succeeds, requires the operator hash to exactly equal the staged delta's   <code>base_hash</code>, requires the package <code>target_id</code> to match and its <code>hw_id</code> to pass the normal hardware gate,   and retains the normal payload and signature/allowlist gates. Approval only delegates the base decision:   OTAFIX independently   locates the physical EndF, hashes the running app, and compares that value with the package before its   first app write. A physically absent/corrupt EndF or wrong base therefore returns to the unchanged app;   it still requires USB recovery if that app does not already contain this command.   A chain intended to cross historical firmware must introduce this command in its first bridge and retain   it in every later bridge. Manual pulls still use the build-provided target ID when app-side EndF parsing   fails, so a rescue-capable bridge can fetch its exact successor before invoking the guarded command. Such   a node must acknowledge the condition up front with <code>ota pull &lt;mid8&gt; flash rescue</code>; an ordinary flash pull   refuses before altering staged data. Firmware that predates both rescue commands still requires USB recovery.   Internal-bootloader-self-update builds are a stricter exception: because their ordinary linker may extend   through <code>0xED000</code>, an absent/corrupt live <code>EndF</code> disables every internal staging pull before erase instead   of trusting the legacy 608 KiB estimate.</li> <li>MeshTower V2 SD nRF52: the application stores a contiguous <code>/meshcore-ota.mota</code> on microSD. After   authenticating one exact signed manifest and verifying the leaves/payload/image, it hashes the exact full   container with only <code>APRV</code> normalized to zero and publishes a 72-byte reset-retained <code>MOTASDA2</code> record.   That record binds app-vs-boot purpose, format, raw sector range, total/card geometry, and normalized digest;   OTAFIX consumes and clears it before reading the card. There is no normal sector-1 handoff or additional   OTA-specific partition-layout requirement beyond what the bundled SdFat can mount. The matching   bootloader reads the authorized sectors without mounting FAT, supports either a full image or an in-place delta,   verifies the staged/full result hash, and never writes through <code>0xED000</code> where InternalFS begins. The   exact SD repeater also accepts a manually selected, signed v3 bootloader package when installed and   candidate markers are exactly <code>0x09</code> (<code>SD|BOOT_UPDATE</code>). MeshCore streams the same strict identity,   CRC, vector, signature, MID/hash-confirmation, and complete-image checks from the SD file. GPREGRET   <code>0x6B</code> plus GPREGRET2 <code>0x53</code> selects this privileged path. Both MeshCore and OTAFIX require a hash-valid   live <code>EndF</code> ending by <code>0xE0000</code>; when a nonzero boot-settings bank CRC is active, its recorded size must   also cover that complete live image and stop by <code>0xE0000</code>. For fmt3 MeshCore additionally writes a readback-checked   <code>MOTASDBL</code> token at <code>0xE0000</code> containing the exact total and signed <code>image_hash</code>. OTAFIX binds the parsed manifest,   streamed payload, and final scratch image to that   token, so a removable-media change can only fail closed. OTAFIX then uses <code>0xE0000..0xEA000</code> as temporary scratch; the normal   application linker remains at <code>0xED000</code> and ordinary application updates do not inherit this scratch   headroom restriction. Both fmt2 application apply and fmt3 bootloader apply require installed BLM2   continuity matching the live S140 FWID/application layout. Preview.12 must be upgraded locally over   USB/BLE DFU or SWD. MeshCore never writes a raw sector-1 handoff.</li> <li>Matched external-QSPI nRF52 repeaters: the application reserves the board's dedicated QSPI NOR as a   raw store beginning at offset zero. It obtains a 1-16 MiB capacity from JEDEC, checkpoints payload before   leaf metadata, and verifies each erased/programmed page. GPREGRET2 <code>0x51</code> selects QSPI only when the   matching bootloader advertises the QSPI storage bit; legacy markers retain the internal scan path. The   bootloader pre-hashes a full payload before invalidating the app, or applies an in-place delta with the   complete internal application region as workspace. Companion builds never enable this raw store: some use   QSPI as a filesystem, while others simply leave that chip outside OTA ownership. See   the nRF52 QSPI guide.</li> <li>XIAO bootloader self-update (explicit only): selected XIAO-module QSPI repeater builds link the   ordinary application below <code>0xE0000</code>, reserving <code>0xE0000..0xEA000</code> as a 40 KiB internal scratch bank.   They accept a v3 bootloader package only through an exact manual MID pull. Ordinary <code>ota install</code>,   autofetch, autoinstall, and every application apply backend reject it. The operator then copies the   staged package's exact values from <code>ota bootloader</code> into   <code>ota bootloader install &lt;MID8&gt; &lt;HASH16&gt;</code>. The app repeats the strict v3 geometry, installed/candidate   identity, vectors, embedded CRC/capabilities, complete payload/image hashes, signature, and trusted-key   gates before writing <code>APRV</code>. GPREGRET <code>0x6B</code> plus GPREGRET2 <code>0x51</code> hands the QSPI package to OTAFIX.   <code>APRV</code> carries the app's authenticated and explicitly confirmed authorization decision; OTAFIX does not   repeat Ed25519/allowlist, Merkle, or typed operator confirmation. It independently rechecks the strict v3   structure, canonical identity/capabilities, vectors, payload SHA, embedded CRC, and scratch/copy hashes,   uses the scratch bank to preserve the running application while replacing <code>0xF4000..0xFE000</code>, and reports   boot-update results in GPREGRET2 <code>0xC0..0xCF</code>   (<code>0xC8</code> success). This mechanism cannot bootstrap a stock/older bootloader; install an ABI-3,   boot-update-capable exact-board OTAFIX over USB/BLE DFU or SWD once first.</li> <li>Internal-flash bootloader self-update (explicit only): curated nRF52840 lean repeater/bridge targets   without an OTA-owned SD/QSPI store share the normal bottom-aligned internal store below <code>0xED000</code>.   It holds either an ordinary app delta or the exact 41,330-byte v3 container, never both. The boot package   bottom-aligns at <code>0xE2000</code>; a hash-valid live <code>EndF</code> must prove the complete running image ends at or below   that address before the first erase. OTAFIX reads each source window before erasing and compacts the   payload forward in the same eleven pages to raw <code>0xE2000..0xEC000</code>; no separate scratch bank or special   application linker exists. GPREGRET <code>0x6B</code> plus GPREGRET2 <code>0xED</code> selects boot update, while ordinary app   apply uses GPREGRET <code>0x6A</code> plus the same storage source. Exact installed/candidate capability flags are   <code>0x0A</code> (<code>STAGE_CEILING|BOOT_UPDATE</code>). Ordinary deltas remain dynamically sized, may start below   <code>0xE2000</code>, and reconstruct only below the normal <code>0xED000</code> app ceiling. The same signature, explicit   confirmation, exact identity, vector, CRC, and single-marker rules as the XIAO path apply. Bootloader FULL   admission is isolated from ordinary application FULL policy, and privileged partials are never resumed   automatically after an application reboot. See   the nRF52 bootloader-update guide for the exact target inventory.</li> </ul> <p>A signature, when present, proves author authenticity and must pass the device allowlist. Unsigned v2 application packages remain installable when local policy permits them. A v3 bootloader package is always signed and trusted. The one-shot <code>approval</code> marker records local consent before the bootloader may apply it.</p> <p>Bootloader testing note: always test apply with a real different image (base != target). A same-image (X-&gt;X) \"delta\" trivially reproduces the target and gives a false positive.</p>"},{"location":"ota_protocol/#13-versioning-of-this-spec","title":"13. Versioning of this spec","text":"<p>The fixed byte layout has two intentionally disjoint profiles: <code>format_ver = 2</code> for ordinary application packages and <code>format_ver = 3</code> only for the exact privileged bootloader profile in Section 4.3. A parser must reject v2+BOOTLOADER, v3 without exact <code>FULL|SIGNED|BOOTLOADER</code>, and every other version. The multihash <code>hash_algo</code> separately allows swapping the digest family without a format bump. Unknown <code>codec_id</code> / <code>ota_msg_type</code> values are ignored (a node simply will not fetch what it cannot apply).</p>"},{"location":"ota_user_guide/","title":"Updating your node over the air (OTA) - user guide","text":"<p>This guide is for node operators: how to update your MeshCore device's firmware over the radio, in plain language. No cables, no programmer - your node can download a new firmware from a neighbour and install it. (For the technical wire format, see the OTA protocol spec.)</p> <p>LoRa OTA download and installation are present only in supported Keymind destination artifacts; the receiver must already be running one of those install-capable builds. Some internal-staging nRF52 targets use a lean <code>lora_ota_no_external_sensors</code> target, while matched external-QSPI boards can retain their normal full-sensor repeater features. Release filenames include an OTA marker, but capability must still be confirmed on the running device. A source can be an OTA-enabled infrastructure node or a source-only Full Companion backed by <code>motatool</code>. Intermediate repeaters do not need OTA-enabled firmware: current repeater builds transport OTA floods opaquely, subject to their normal forwarding filters, duplicate checks, and flood limits. OTA radio traffic is accepted, generated, and relayed only while <code>tempradio</code> is actually running on that node. Every source, receiver, and intermediate repeater must therefore have an overlapping temporary-radio window.</p> <p>The recommended temporary OTA settings use 250 kHz bandwidth, SF5, CR5, and a 120-minute window. For a North American node currently configured for 909.950 MHz, run this on every participating node:</p> <pre><code>tempradio 909.950,250,5,5,120\n</code></pre> <p>Use the node's current permitted regional frequency in place of <code>909.950</code> when necessary.</p> <p>The scripted updater checks the firmware version of the receiver and every sender before deciding whether RX power saving can remain active. At SF5/BW250, an all-v1.17.1.5-or-newer path can use effective RXPS level 8 with the tuple-selected 64-symbol physical preamble. SF5/BW500 can use level 8 with 128 symbols. Other fast tuples remain at the shortest viable preamble, normally 32. A mixed, older, or unknown long-preamble path is put in continuous receive for the update, then the receiver's exact saved RXPS setting is restored. This preserves the RX benefit without risking missed packets from a legacy 32-symbol sender.</p> <p>Can my node install the update? Choose a release-table artifact explicitly labelled LoRa-OTA capable, then confirm <code>ota self</code> and <code>ota status</code> expose install support; do not infer support from the filename alone. LoRa OTA firmware is available for supported ESP32 boards and nRF52 repeater targets. Every nRF52 installation also requires the OTAFIX bootloader built for that exact board; having an OTA-capable application image alone is not enough. An intermediate repeater only relays packets and needs neither an install-capable image nor OTAFIX. Check the bootloader release for an exact board match before attempting an update.</p> <p>The following nRF52 repeater families gained firmware-side LoRa OTA targets in this release. Their ordinary repeater keeps its complete declared sensor recipe; the install-capable <code>lora_ota_no_external_sensors</code> sibling is smaller:</p> <ul> <li>Heltec Mesh Solar, T1, and Tower V2</li> <li>Keepteen LT1, LilyGo T-Impulse Plus, Mesh Pocket, and Nano G2 Ultra</li> <li>Minewsemi ME25LS01, RAK3401, SenseCAP Solar, and Wio WM1110</li> </ul> <p>The RAK3401 <code>RAK_3401_repeater_lora_ota_no_external_sensors</code> image trims selected optional environmental/ranging drivers but does not disable I2C. It retains the INA219, INA226, INA260, and INA3221 voltage/current monitors, board display and RTC support, and both RAK12500 I2C and RAK12501/L76K UART GPS paths. The four INA drivers are only the retained voltage/current entries in the optional environmental-sensor table; they are not the only I2C users. The SSD1306 OLED, autodiscovered DS3231/RV3028/PCF8563/RX8130CE RTCs, and RAK12500 GPS use I2C as separate board peripherals. Install one GPS module in sensor slot A. Slot D's reset/PPS lines conflict with the RAK13302 radio's BUSY/DIO1 lines.</p> <p>The firmware-configured INA3221 address and the RAK12500 address are both <code>0x42</code>, so those devices cannot share one bus at those addresses. To install both, leave the RAK12500 at <code>0x42</code>, strap INA3221 A0 to SCL for <code>0x43</code>, and use a firmware build with <code>-DTELEM_INA3221_ADDRESS=0x43</code>.</p> <p>The reduced RAK4631 profiles likewise retain the four INA monitors. The plain repeater and Serial2 bridge retain GPS: a RAK12501 can use sensor slot A or D, and a RAK12500 can use slot A or C. The runtime RS-232 bridge defaults to Serial2 so the UART RAK12501 can retain Serial1. The merged runtime image always reserves Serial1: a bounded silent probe cannot prove that a cold RAK12501 is absent, and turning the GPS setting off cannot stop a fitted module from driving the shared UART while WB_IO2/3V3_S remains powered. Use Serial2. Serial1 requires an explicit no-GPS/dedicated image. The reservation remains fail-closed even when an I2C RAK12500 is detected. The explicitly compiled <code>RAK_4631_repeater_bridge_rs232_serial1_lora_ota_no_external_sensors</code> target omits the combined GPS provider because its bridge owns the UART used by RAK12501; consequently that legacy image does not expose the I2C RAK12500 path either, even though RAK12500 itself does not use the UART.</p> <p>Selected nRF52 repeaters with dedicated external QSPI can now stage the complete package off-chip, so their normal full-sensor repeater build can install a full image or an in-place delta. The current matched families are XIAO nRF52840 and its XIAO-module derivatives, original LilyGo T-Echo, ThinkNode M1/M6, Wio Tracker L1, SenseCAP Solar, and the dedicated RAK4631 + RAK15001 slot-C target. The list also includes a separately wired W25Q16JV on RAK19007 with either RAK4631 or RAK3401 + RAK13302. These require the corresponding exact QSPI-aware OTAFIX bootloader; see the nRF52 QSPI guide.</p> <p>The W25Q16 option uses one permanent RAK19007 wiring for either core: CLK/MISO/ MOSI tap IO-connector pins 26/27/28, flash CS uses J11 AIN1, and power uses J12 VDD (3.3 V) and GND. Add an approximately 10 kOhm CS-to-VDD pull-up and never power the flash from VBAT. The three SPI signals require underside pads or an IO-connector interposer; the easy J10/J11/J12 headers do not expose them. The flash consumes no WisBlock slot, so a supported GPS can remain in slot A.</p> <p>The ordinary full-sensor <code>RAK_4631_repeater</code> image remains too large for the safe internal in-place update limit. Without external flash, use <code>RAK_4631_repeater_lora_ota_no_external_sensors</code>; it trims selected optional environmental/ranging drivers while retaining generic I2C, battery monitoring, the four INA monitors, and target-compatible GPS. A RAK4631 fitted with RAK15001 in sensor slot C can instead use <code>RAK_4631_repeater_rak15001_slot_c_lora_ota</code> to retain the full sensor/GPS set and stage full images or deltas off-chip.</p> <p>For the external Winbond breakout, use <code>RAK_4631_repeater_w25q16_lora_ota</code> on RAK4631 or <code>RAK_3401_repeater_rak13302_w25q16_lora_ota</code> on RAK3401 + RAK13302. They retain the full sensor/GPS recipe and require exactly a 2 MiB <code>EF4015</code> W25Q16 plus the bootloader for that same core/radio/flash combination. Install <code>wiscore_rak4631_w25q16</code> for RAK4631 or <code>wiscore_rak3401_rak13302_w25q16</code> for RAK3401 + RAK13302 as a one-time prerequisite. The physical wiring is shared, but the two firmware identities are deliberately different and cannot be substituted for one another.</p>"},{"location":"ota_user_guide/#the-important-part-first-its-safe","title":"The important part first: it's safe","text":"<ul> <li>Nothing installs by itself. Your node can discover and download an update, but   it only installs when you say so (unless you deliberately turn on auto-install - see below).</li> <li>Bad downloads can't sneak in. Every piece of the firmware is checked against a cryptographic   fingerprint as it arrives, and the whole image is verified again before install. A corrupt or tampered   download is rejected, not installed.</li> <li>You choose who to trust. Updates can be signed by their author. You can tell your node to only   auto-install firmware signed by keys you've added.</li> <li>Discovery stays quiet; a transfer is deliberate. Periodic update discovery uses background priority.   Once a download starts, its transfer packets are primary traffic across every relay hop, so use   TempRadio as an OTA maintenance window when delaying unrelated mesh traffic would matter.</li> <li>It can recover. If an install ever fails, the node falls back to a safe recovery mode (you can   re-flash a known-good firmware over USB) - it won't be left bricked.</li> </ul>"},{"location":"ota_user_guide/#how-to-talk-to-your-node","title":"How to talk to your node","text":"<p>Connect to your node's console - usually a USB serial terminal at 115200 baud (or whatever tool you already use to manage the node). You type <code>ota ...</code> commands and the node replies in plain words.</p> <p>The commands have short, friendly names (and most accept aliases, so you don't have to remember exact spelling): type <code>ota help</code> any time to see the list, or just <code>ota</code> for a status summary.</p>"},{"location":"ota_user_guide/#common-tasks","title":"Common tasks","text":""},{"location":"ota_user_guide/#1-see-what-im-running-and-whether-anything-is-going-on","title":"1. See what I'm running and whether anything is going on","text":"<pre><code>ota status\n</code></pre> <p>Shows your current firmware version, your node's update \"target\" (its hardware/role id), and whether a download is in progress.</p> <p>For a denser admin view - your firmware's content id (<code>mid</code>) and its body hash, the fingerprint of the set you're serving, live download progress, and the current policy - use:</p> <pre><code>ota stats\n</code></pre> <p>On a remote node this is admin-only (the remote command console requires the admin password) - send it from the app's repeater command screen, or the WiFi/serial OTA console.</p>"},{"location":"ota_user_guide/#2-find-updates-available-near-me","title":"2. Find updates available near me","text":"<pre><code>ota ls\nota ls 2                 # page 2 when more than two updates are available\n</code></pre> <p>Your node asks around and lists the firmware updates other nodes nearby are offering, in plain words - each with a temporary number, a stable eight-hex manifest ID, its version, whether it's a full image or a small delta, how many nodes have it, and how recently it was seen. For example:</p> <pre><code>Updates 1/1 (2 src; refreshing):\n 1) 838B8169 v1.2.3 delta [same target] 3n 5s\n 2) BF0AB0C4 v1.2.0 full [unsupported] 1n 12s\n</code></pre> <p>Each row shows the version, full-vs-delta, whether it fits your node, how many nodes have it, and how long ago it was seen. The fit marker:</p> <ul> <li>[same target] - the advertised target ID matches this hardware-and-role build. Download and apply   still enforce codec, bootloader, signed hardware tag, base hash, and integrity checks.</li> <li>[unsupported] - the target may match, but this build or its bootloader cannot apply that codec. A common   example is the source node's self-served full image on an internal-staging nRF52, which needs an   in-place delta. A matched external-QSPI nRF52 can accept that full codec.</li> <li>[rescue] - an installable in-place nRF52 delta for the same target, but this running firmware has no   valid app-side EndF. It requires the explicit rescue download and install flow below.</li> <li>[name] - a different known board or role (for example <code>[ProMicro_companion_radio_usb]</code>). Don't install it.</li> <li>[?] - can't tell (a build with no target id set, e.g. a bare IDE build rather than a release build).</li> </ul> <p>Run it again after a few seconds - discovery happens in the background, so the list fills in. Nothing is downloaded yet; this is just looking around. <code>refreshing</code> means the command has just sent asynchronous catalog queries, so run it again even when an older row is already visible. Two updates fit in each remote CLI reply; use <code>ota ls 2</code>, <code>ota ls 3</code>, and so on for later pages. Catalog rows can change while replies arrive, so use the displayed manifest ID for scripts and important operations rather than a numeric position. (<code>ota neighbors</code> / <code>ota updates</code> also work.)</p>"},{"location":"ota_user_guide/#3-download-an-update","title":"3. Download an update","text":"<p>Pick one from the list by its stable manifest ID (a number also works for interactive use), and say where to put it:</p> <pre><code>ota pull 838B8169 flash            # stage it in this node's flash, to install here\nota pull 838B8169 folder           # capture it onto a connected motatool folder as &lt;id&gt;.mota\nota pull 838B8169 folder validate  # warm-start capture from a motatool --seed build (much faster; below)\n</code></pre> <p>The destination is required - <code>ota pull 838B8169</code> on its own just shows the choices. <code>flash</code> is always available (stage here, then <code>ota install</code>). <code>folder</code> appears only while a <code>motatool serve</code> link is attached (it shows the link, e.g. <code>folder: tcp 192.168.4.5</code>); it streams the firmware straight onto the host folder - nothing is staged on this node. That's how you grab an exact copy of another device's firmware off the mesh (to a <code>.mota</code> file) so you can later build a delta against firmware you don't otherwise have. (<code>ota get</code> is an alias.)</p> <p><code>validate</code> (warm-start, advanced). Capturing a full image over the radio is slow. If you have a similar build on the computer (e.g. a fresh recompile of the same firmware), run motatool with <code>--seed &lt;that.mota&gt;</code> and add <code>validate</code>: the node fetches just the target's block fingerprints, keeps every block your seed already matches, and pulls over the radio only the handful that actually differ - turning a ~30-minute capture into seconds. The result is still a byte-exact, verified copy of the target.</p> <p>Where the seed comes from: it is the <code>--seed &lt;file&gt;</code> you pass to <code>motatool serve</code> - not a file you drop into the capture (<code>--dir</code>) folder, which is only the destination and starts empty. There is exactly one configured seed. When you run <code>... folder validate</code>, the node asks motatool to begin the capture and motatool stamps that seed's payload into the fresh <code>.part</code> in the same step - so it is always the file you named, with no guessing. <code>validate</code> is the switch: a plain <code>folder</code> pull ignores any seed and fetches from scratch; re-running a <code>validate</code> pull re-begins fresh (it never resumes a stale partial). Nothing about the seed is trusted - every kept block is checked against the target's own fingerprints, so a mismatched or missing seed just means those blocks are fetched over the radio (correct result, only slower).</p> <p>The node fetches from one source as primary traffic, with bounded adaptive request flights. Every session probes with one manifest block, then clean flights grow <code>1 -&gt; 2 -&gt; 3 -&gt; 4</code> blocks on RAK3401 OTA builds. New application packages use 2 KiB blocks; deployed 1 KiB packages remain supported. All blocks in a flight share one request packet, and the receiver stays silent until the source/relays finish returning them. A recovery halves the next flight. Retry timing follows the active SF/BW airtime, duty budget, and path length, so faster settings recover sooner without a fixed one-second request colliding with a valid multi-hop response. Mesh repeaters carry the packets only while their temporary-radio windows are active. Check progress with <code>ota status</code>.</p> <p>If a <code>folder</code> pull loses its link mid-transfer, <code>ota status</code> shows paused - the host keeps the partial and the pull resumes (filling only what's missing) the moment you reconnect motatool; it never falls back to flash. To stop a download you no longer want:</p> <pre><code>ota cancel\n</code></pre> <p>For a download staged on the node, success means current firmware also invalidated the persistent flash/SD/QSPI copy; it reports an error if that media operation cannot be verified. For a <code>folder</code> capture, cancel only detaches the live session and retains the host partial so it can be resumed or removed on the host deliberately. On a MeshTower SD auto-archive capture, cancel also detaches the live archive session and retains its card partial for the archive service to resume later; use <code>ota cache off</code> to stop new archive captures.</p>"},{"location":"ota_user_guide/#4-install-a-downloaded-update","title":"4. Install a downloaded update","text":"<p>Once <code>ota status</code> shows the download is ready to install:</p> <pre><code>ota install\n</code></pre> <p>The node verifies the firmware one last time, and if everything checks out it installs it and reboots into the new version. If the check fails, it tells you why and does not install. Unsigned images normally install only through this explicit command. The MeshTower V2 SD target is stricter and requires an allowlisted signature even for a manual application install, because it authorizes removable-media bytes for the bootloader. A signed image whose signer is not in the device allowlist is rejected; trusted signed images can auto-install only when that policy is enabled and the signed version is strictly newer than the running hash-valid EndF version. Manual <code>ota install</code> remains the deliberate equal-version/rollback override.</p> <p>After it reboots, run <code>ota status</code> to confirm the new version.</p>"},{"location":"ota_user_guide/#updating-an-nrf52-bootloader-advanced-explicit-only","title":"Updating an nRF52 bootloader (advanced, explicit only)","text":"<p>This is available on specially marked no-external-flash nRF52840 lean repeater/bridge builds, on the legacy XIAO nRF52840/Sense raw-QSPI builds, and on the exact <code>Heltec_tower_v2_sdcard_repeater_lora_ota_no_external_sensors</code> microSD build, after a one-time exact-board ABI-3 OTAFIX installation over USB/BLE DFU or SWD. It is not the normal firmware update path. Check support first:</p> <pre><code>ota bootloader\n</code></pre> <p>The reply must show a CRC-valid installed identity plus ABI 3 and the exact storage/boot-update capability bits for that build (<code>0x09</code> for MeshTower V2 microSD, <code>0x0A</code> for the shared internal store, or <code>0x0E</code> for XIAO raw QSPI). A bootloader package appears as <code>bootloader</code> in <code>ota ls</code>. It is never downloaded or installed automatically, even if both OTA automation settings are enabled. Use its stable ID explicitly:</p> <pre><code>ota pull &lt;MID8&gt; flash\n# wait until ota status says this bootloader download is ready\nota bootloader\nota bootloader install &lt;MID8&gt; &lt;HASH16&gt;\n</code></pre> <p>Copy both confirmation values exactly from the second <code>ota bootloader</code> reply. Ordinary <code>ota install</code> deliberately refuses this package. The privileged command requires an exact 40 KiB candidate payload in the fixed 41,330-byte container, a valid exact embedded identity/CRC and vector table, continued boot-update support, required <code>BLM2</code>/<code>SOFT</code> continuity metadata at canonical raw-image offset <code>0x9FB4</code>, a boot version that exactly matches the package and is newer than installed BLM2, and a valid signature from a key already in <code>ota key</code>'s trusted allowlist. It preserves the running application while OTAFIX replaces itself; <code>blup:C8</code> in post-reboot <code>ota status</code> means success. Remote rollback is refused. Any node lacking this command or those capabilities must update its bootloader locally instead.</p> <p>On an internal-flash target, the package shares the ordinary store below <code>0xED000</code> and bottom-aligns at <code>0xE2000</code>; there is no separate reserved scratch bank. A valid live <code>EndF</code> must prove the current image ends at or below that address before any page is erased. If <code>EndF</code> is missing/corrupt or the app is too large, the pull is refused and local DFU/SWD is required. On the MeshTower V2 SD target, the application linker remains at <code>0xED000</code>, but bootloader replacement needs temporary scratch beginning at <code>0xE0000</code>. A hash-valid live <code>EndF</code> must therefore prove the complete current image ends by <code>0xE0000</code>. A CRC-bound boot-settings bank must cover that complete image while also ending by <code>0xE0000</code>. MeshCore binds both application and bootloader SD approval to purpose, exact raw geometry, and a normalized SHA-256 in a reset-retained <code>MOTASDA2</code> record. Boot updates also bind the exact authenticated signed image hash in the E0000 token. OTAFIX consumes the retained record before media access, so a later card change or power cycle fails instead of authorizing different bytes. MeshCore never claims or writes raw sector 1. Both application and bootloader OTA wait until a matching BLM2 bootloader has been provisioned locally; preview.12 requires USB/BLE DFU or SWD first. Larger applications can continue to use normal application mOTA; only bootloader self-update is refused. See the nRF52 bootloader-update guide for the complete target inventory, storage layouts, and safety contract.</p>"},{"location":"ota_user_guide/#5-if-something-goes-wrong","title":"5. If something goes wrong","text":"<ul> <li>A download that stalls or gets interrupted just resumes later. Use   <code>ota cancel</code> to durably discard device staging; a folder capture keeps its   host partial for a later resume.</li> <li>A legacy app-only internal-flash nRF52 that still runs but reports <code>no EndF</code> can use the pre-provisioned rescue path   if its physical EndF is intact and only app-side validation is failing. Fetch the exact <code>[rescue]</code>   in-place delta with an explicit acknowledgement, obtain its 16-hex-digit <code>base_hash</code> from the package   metadata, then run:</li> </ul> <p><code>text   ota pull &lt;mid8&gt; flash rescue   # wait for ota status to say ready to install   ota rescue install &lt;base_hash16&gt;</code></p> <p>This is not a force option. It refuses a normally valid EndF, a different package hash, hardware or   target mismatch, corrupt payload, and invalid/untrusted signatures. The bootloader independently hashes   the running app and rejects a wrong base before writing the app. If the physical EndF is absent or the   rescue commands were not already in the running firmware, recover over USB.   Release chains should put this command in their first bridge and keep it in every bridge after that.   The shared-internal bootloader-update builds are intentionally excluded:   without valid live <code>EndF</code>, they refuse every internal pull before erase   because their normal application can extend through <code>0xED000</code>. Recover one   of those builds over USB/BLE DFU or SWD. - If an install fails, the node won't boot a broken image - it lands in recovery mode:   - nRF52: it appears as a USB drive; drag a known-good firmware <code>.uf2</code> for that exact board onto it     to recover.   - ESP32: it keeps the previous firmware in the other slot and rolls back. - When in doubt, you can always re-flash over USB the normal way.</p>"},{"location":"ota_user_guide/#optional-let-it-update-automatically","title":"Optional: let it update automatically","text":"<p>By default your node only discovers updates - it won't download or install on its own. If you want more automation (e.g. for a remote node you can't easily reach), you can opt in. These settings are saved.</p> <pre><code>ota config autofetch any        # auto-DOWNLOAD any compatible update for this node (still won't install)\nota config autofetch signed     # auto-download only signed updates\nota config autofetch off        # back to manual (default)\n\nota config autoinstall trusted  # auto-INSTALL only a trusted signed version newer than the running EndF\nota config autoinstall off      # never auto-install (default)\n\nota config advert 1440          # re-advertise every N minutes while temp radio is running\nota config advert 0             # only advertise when a temp-radio window starts\n\nota config hops 3               # how far OTA travels: accept from / relay up to N repeater hops (default 3)\nota config hops 0               # only exchange OTA with directly-connected nodes (never relay)\n\nota config                      # show the current settings\n</code></pre> <p>These policies also govern automatic adoption of an interrupted staged download after reboot. <code>off</code> leaves it untouched, <code>signed</code> requires the stored manifest's signed flag, and automatic resume requires the stored target to match this node and its version to be newer than the running valid EndF. Reissuing an explicit <code>ota pull &lt;MID8&gt;</code> remains the deliberate override for an older or unsigned partial. For bring-up/debugging, <code>ota dev resume &lt;MID8&gt;</code> performs the same explicit MID-bound re-adoption without starting a new network fetch. After reboot it requires the MID; bare <code>ota dev resume</code> is accepted only while an active/requested session MID still exists, and malformed or missing identifiers are rejected.</p> <p>Recommended for most people: leave both off and update by hand. Use <code>autoinstall trusted</code> only once you've added the signer's key (next section) and you trust them to push updates unattended. Automatic admission and final apply both reject zero, equal, or older signed versions; a dishonest catalog version cannot bypass the manifest check. Use manual <code>ota pull</code> plus <code>ota install</code> for an intentional rollback.</p> <p>The MeshTower V2 SD OTA target has a separate, default-on archive policy. It saves all mOTAs it sees to the SD card so the repeater can seed them later; this does not install them and does not change the install-oriented <code>autofetch</code> default above. Use <code>ota cache</code> for status and <code>ota cache off</code> or <code>ota config cache off</code> to stop new archive captures. Already cached files remain available to peers. Manual <code>ota pull</code> commands take priority and an interrupted archive capture resumes later. See Preload many mOTAs from a computer for the required <code>/mota/&lt;manifest-id&gt;.mota</code> filenames and the complete TempRadio seeding workflow.</p>"},{"location":"ota_user_guide/#optional-only-trust-updates-from-specific-people","title":"Optional: only trust updates from specific people","text":"<p>If you'll use auto-install, tell your node which signing keys to trust. The firmware author shares their public key (a hex string); you add it:</p> <pre><code>ota key add &lt;public-key-hex&gt;    # trust this signer\nota key list                    # show trusted signers\nota key rm &lt;public-key-hex&gt;     # stop trusting one\n</code></pre> <p>Only strictly newer updates signed by a trusted key are eligible for auto-install. Manual <code>ota install</code> permits an unsigned package after all integrity, hardware, base, and bootloader checks pass, except on the MeshTower V2 removable-SD path where all application installs must be signed and allowlisted. A signed package whose signer is not in the device allowlist is rejected rather than silently treated as unsigned.</p>"},{"location":"ota_user_guide/#sharing-updates-with-others-advanced","title":"Sharing updates with others (advanced)","text":""},{"location":"ota_user_guide/#relay-a-folder-of-firmware-from-a-computer","title":"Relay a folder of firmware from a computer","text":"<p>If your node is connected to a computer (e.g. a gateway on a Raspberry Pi), it can hand out a whole folder of firmware files to the mesh - without storing them itself. Useful for seeding a new release to a remote area.</p> <ol> <li>Put the firmware files (<code>.mota</code> files - see below) in a folder on the computer.</li> <li>Install the helper tool once - the standalone <code>motatool</code> CLI (https://github.com/vk496/motatool) -    then point it at your node and the folder - over the node's USB serial, over WiFi if it is    an ESP32 WiFi companion or FULL ESP32 node, or over encrypted Bluetooth if it is an nRF52 Full Companion:    <code>git clone https://github.com/vk496/motatool &amp;&amp; cargo install --path ./motatool    # over USB serial:    motatool serve --dir ./my_firmware/ --serial /dev/ttyACM0 -v    # ...or over WiFi: the seeder is on dedicated TCP port 5001:    motatool serve --dir ./my_firmware/ --tcp 192.168.1.50:5001 -v    # ...or over paired BLE to an nRF52 Full Companion (protocol v14):    python3 tools/ble_mota/ble_mota_seeder.py \\      --device MeshCore-MyCompanion --dir ./my_firmware/</code>    It answers the node's requests; your node then advertises those updates to neighbours, who can    <code>ota get</code> them like any other. (A WiFi node prints its IP + seeder port to the serial log on connect.    Details: https://github.com/vk496/motatool.)</li> </ol> <p>Check the device's attach reply or run <code>ota folder</code>: <code>host=X/Y</code> means the firmware is advertising <code>X</code> of the <code>Y</code> valid entries reported by the host. Serve registries are deliberately RAM-bounded on smaller builds, and the node's own firmware also consumes a slot. If <code>X &lt; Y</code>, split the chain across seeders/folders or use a higher-capacity seeder; <code>motatool</code> saying that every file is valid does not mean every file fit on-device.</p> <p>To stop, just stop the daemon - over WiFi the node auto-detaches when the connection closes; over USB you can also run <code>ota folder off</code> on the node. <code>ota folder</code> on its own lists what your node is offering. On a FULL repeater or room server, run <code>start webconfig</code> first if WiFi is not already active. Other FULL roles with browser OTA support can use the <code>MeshCore-OTA</code> access point from <code>start ota</code> and connect to <code>192.168.4.1:5001</code>. Every LoRa participant still needs an overlapping <code>tempradio</code> window.</p>"},{"location":"ota_user_guide/#everyone-helps-share","title":"Everyone helps share","text":"<p>You don't have to be a gateway to help. Once any node finishes downloading an update, it automatically offers it to its neighbours too. So a new firmware spreads outward node-to-node, instead of everyone hammering the one node that had it first. Discovery remains background traffic; an actual transfer is primary traffic for the duration of its TempRadio maintenance window.</p>"},{"location":"ota_user_guide/#where-firmware-files-come-from","title":"Where firmware files come from","text":"<p>OTA distributes <code>.mota</code> files - a packaged, verifiable firmware image (full image or a small \"delta\" that only contains what changed). You get them by:</p> <ul> <li>Downloading a build. This fork publishes a rolling <code>dev-latest</code> release on GitHub with the   current firmware for many boards, each accompanied by a <code>.full.mota</code> and a tiny <code>.delta.mota</code>. Grab the   one for your board to test.</li> <li>Building your own with the <code>mota</code> packaging tool - see tools/mota/README.md   (this is for people distributing updates, not everyday operators).</li> </ul>"},{"location":"ota_user_guide/#quick-reference","title":"Quick reference","text":"I want to... Command List all commands <code>ota help</code> See my firmware + any download <code>ota status</code> (or just <code>ota</code>) Admin: ids/hashes + serving + policy <code>ota stats</code> (admin-only remotely) Find updates nearby <code>ota ls</code> Download a listed update for installation <code>ota get &lt;mid8&gt; flash</code> Cancel a download <code>ota cancel</code> Install a finished download <code>ota install</code> Recover app-side <code>no EndF</code> on a legacy app-only internal nRF52 <code>ota rescue install &lt;base_hash16&gt;</code> Turn on auto-download <code>ota config autofetch any</code> Turn on auto-install (trusted only) <code>ota config autoinstall trusted</code> Trust a signer <code>ota key add &lt;hex&gt;</code> Relay a folder (gateway) <code>ota folder on</code> + the seeder daemon List what I'm offering <code>ota folder</code> <p>(Older names still work too: <code>neighbors</code>/<code>updates</code> = <code>ls</code>, <code>pull</code> = <code>get</code>, <code>applydelta</code>/<code>apply</code> = <code>install</code>, <code>drop</code>/<code>stop</code> = <code>cancel</code>.)</p>"},{"location":"ota_user_guide/#a-few-terms","title":"A few terms","text":"<ul> <li>Firmware - the software running your node. Updating it can add features or fix bugs.</li> <li><code>.mota</code> - a packaged firmware update file, with built-in integrity checks.</li> <li>Target - your node's hardware + role identity. Your node only auto-fetches updates built for the   same target, so it won't grab firmware meant for a different board.</li> <li>Delta - a small update containing only the changes from your current firmware (faster to send than a   full image). Your node rebuilds the complete firmware from it and verifies the result before installing.</li> <li>Signed - the update carries the author's cryptographic signature, so you can verify who made it.</li> </ul> <p>For the full technical details (the file format and the radio protocol), see the OTA protocol spec.</p>"},{"location":"packet_format/","title":"Packet Format","text":"<p>This document describes the MeshCore packet format.</p> <ul> <li><code>0xYY</code> indicates <code>YY</code> in hex notation.</li> <li><code>0bYY</code> indicates <code>YY</code> in binary notation.</li> <li>Bit 0 indicates the bit furthest to the right: <code>0000000X</code></li> <li>Bit 7 indicates the bit furthest to the left: <code>X0000000</code></li> </ul>"},{"location":"packet_format/#version-1-packet-format","title":"Version 1 Packet Format","text":"<p>This is the current version-1 MeshCore wire packet structure. Older firmware may support only a subset of the path encodings and payload types described here.</p> <pre><code>[header][transport_codes(optional)][path_length][path][payload]\n</code></pre> <ul> <li>header - 1 byte<ul> <li>8-bit Format: <code>0bVVPPPPRR</code> - <code>V=Version</code> - <code>P=PayloadType</code> - <code>R=RouteType</code></li> <li>Bits 0-1 - 2-bits - Route Type<ul> <li><code>0x00</code>/<code>0b00</code> - <code>ROUTE_TYPE_TRANSPORT_FLOOD</code> - Flood Routing + Transport Codes</li> <li><code>0x01</code>/<code>0b01</code> - <code>ROUTE_TYPE_FLOOD</code> - Flood Routing</li> <li><code>0x02</code>/<code>0b10</code> - <code>ROUTE_TYPE_DIRECT</code> - Direct Routing</li> <li><code>0x03</code>/<code>0b11</code> - <code>ROUTE_TYPE_TRANSPORT_DIRECT</code> - Direct Routing + Transport Codes</li> </ul> </li> <li>Bits 2-5 - 4-bits - Payload Type<ul> <li><code>0x00</code>/<code>0b0000</code> - <code>PAYLOAD_TYPE_REQ</code> - Request (destination/source hashes + MAC)</li> <li><code>0x01</code>/<code>0b0001</code> - <code>PAYLOAD_TYPE_RESPONSE</code> - Response to <code>REQ</code> or <code>ANON_REQ</code></li> <li><code>0x02</code>/<code>0b0010</code> - <code>PAYLOAD_TYPE_TXT_MSG</code> - Plain text message</li> <li><code>0x03</code>/<code>0b0011</code> - <code>PAYLOAD_TYPE_ACK</code> - Acknowledgment</li> <li><code>0x04</code>/<code>0b0100</code> - <code>PAYLOAD_TYPE_ADVERT</code> - Node advertisement</li> <li><code>0x05</code>/<code>0b0101</code> - <code>PAYLOAD_TYPE_GRP_TXT</code> - Group text message (unverified)</li> <li><code>0x06</code>/<code>0b0110</code> - <code>PAYLOAD_TYPE_GRP_DATA</code> - Group datagram (unverified)</li> <li><code>0x07</code>/<code>0b0111</code> - <code>PAYLOAD_TYPE_ANON_REQ</code> - Anonymous request</li> <li><code>0x08</code>/<code>0b1000</code> - <code>PAYLOAD_TYPE_PATH</code> - Returned path</li> <li><code>0x09</code>/<code>0b1001</code> - <code>PAYLOAD_TYPE_TRACE</code> - Trace a path, collecting SNR for each hop</li> <li><code>0x0A</code>/<code>0b1010</code> - <code>PAYLOAD_TYPE_MULTIPART</code> - Packet is part of a sequence of packets</li> <li><code>0x0B</code>/<code>0b1011</code> - <code>PAYLOAD_TYPE_CONTROL</code> - Control packet data (unencrypted)</li> <li><code>0x0C</code>/<code>0b1100</code> - <code>PAYLOAD_TYPE_OTA</code> - OTA-over-LoRa firmware distribution</li> <li><code>0x0D</code>/<code>0b1101</code> - reserved</li> <li><code>0x0E</code>/<code>0b1110</code> - reserved</li> <li><code>0x0F</code>/<code>0b1111</code> - <code>PAYLOAD_TYPE_RAW_CUSTOM</code> - Custom packet (raw bytes, custom encryption)</li> </ul> </li> <li>Bits 6-7 - 2-bits - Payload Version<ul> <li><code>0x00</code>/<code>0b00</code> - v1 - 1-byte src/dest hashes, 2-byte MAC</li> <li><code>0x01</code>/<code>0b01</code> - v2 - Future version (e.g., 2-byte hashes, 4-byte MAC)</li> <li><code>0x02</code>/<code>0b10</code> - v3 - Future version</li> <li><code>0x03</code>/<code>0b11</code> - v4 - Future version</li> </ul> </li> </ul> </li> <li><code>transport_codes</code> - 4 bytes (optional)<ul> <li>Only present for <code>ROUTE_TYPE_TRANSPORT_FLOOD</code> and <code>ROUTE_TYPE_TRANSPORT_DIRECT</code></li> <li><code>transport_code_1</code> - 2 bytes - <code>uint16_t</code> - calculated from region scope</li> <li><code>transport_code_2</code> - 2 bytes - <code>uint16_t</code> - reserved</li> </ul> </li> <li><code>path_length</code> - 1 byte - Encoded path metadata<ul> <li>Bits 0-5 store path hash count / hop count (<code>0-63</code>)</li> <li>Bits 6-7 store path hash size minus 1<ul> <li><code>0b00</code>: 1-byte path hashes</li> <li><code>0b01</code>: 2-byte path hashes</li> <li><code>0b10</code>: 3-byte path hashes</li> <li><code>0b11</code>: reserved / unsupported</li> </ul> </li> </ul> </li> <li><code>path</code> - <code>hop_count * hash_size</code> bytes - Path to use for Direct Routing or flood path tracking<ul> <li>Up to a maximum of 64 bytes, defined by <code>MAX_PATH_SIZE</code></li> <li>Effective byte length is calculated from the encoded hop count and hash size, not taken directly from <code>path_length</code></li> <li>v1.12.0 firmware and older only handled legacy 1-byte path hashes and dropped packets whose path bytes exceeded 64 bytes</li> </ul> </li> <li><code>payload</code> - variable length - Payload Data<ul> <li>Up to a maximum 184 bytes, defined by <code>MAX_PACKET_PAYLOAD</code></li> <li>Generally this is the remainder of the raw packet data</li> <li>The firmware parses this data based on the provided Payload Type</li> <li>v1.12.0 firmware and older drops packets with <code>payload</code> sizes larger than 184</li> </ul> </li> </ul>"},{"location":"packet_format/#packet-format_1","title":"Packet Format","text":"Field Size (bytes) Description header 1 Contains routing type, payload type, and payload version transport_codes 4 (optional) 2x 16-bit transport codes (if ROUTE_TYPE_TRANSPORT_*) path_length 1 Encodes path hash size in bits 6-7 and hop count in bits 0-5 path up to 64 (<code>MAX_PATH_SIZE</code>) Stores <code>hop_count * hash_size</code> bytes of path data if applicable payload up to 184 (<code>MAX_PACKET_PAYLOAD</code>) Data for the provided Payload Type <p>NOTE: see the Payloads documentation for more information about the content of specific payload types.</p>"},{"location":"packet_format/#header-format","title":"Header Format","text":"<p>Bit 0 means the lowest bit (1s place)</p> Bits Mask Field Description 0-1 <code>0x03</code> Route Type Flood, Direct, etc 2-5 <code>0x3C</code> Payload Type Request, Response, ACK, etc 6-7 <code>0xC0</code> Payload Version Versioning of the payload format"},{"location":"packet_format/#route-types","title":"Route Types","text":"Value Name Description <code>0x00</code> <code>ROUTE_TYPE_TRANSPORT_FLOOD</code> Flood Routing + Transport Codes <code>0x01</code> <code>ROUTE_TYPE_FLOOD</code> Flood Routing <code>0x02</code> <code>ROUTE_TYPE_DIRECT</code> Direct Routing <code>0x03</code> <code>ROUTE_TYPE_TRANSPORT_DIRECT</code> Direct Routing + Transport Codes"},{"location":"packet_format/#path-length-encoding","title":"Path Length Encoding","text":"<p><code>path_length</code> is not a raw byte count. It packs both hash size and hop count:</p> Bits Field Meaning 0-5 Hop Count Number of path hashes (<code>0-63</code>) 6-7 Hash Size Code Stored as <code>hash_size - 1</code> <p>Hash size codes:</p> Bits 6-7 Hash Size Notes <code>0b00</code> 1 byte Legacy / default mode <code>0b01</code> 2 bytes Supported in current firmware <code>0b10</code> 3 bytes Supported in current firmware <code>0b11</code> 4 bytes Reserved / invalid <p>Examples:</p> <ul> <li><code>0x00</code>: zero-hop packet, no path bytes</li> <li><code>0x05</code>: 5 hops using 1-byte hashes, so path is 5 bytes</li> <li><code>0x45</code>: 5 hops using 2-byte hashes, so path is 10 bytes</li> <li><code>0x8A</code>: 10 hops using 3-byte hashes, so path is 30 bytes</li> </ul>"},{"location":"packet_format/#payload-types","title":"Payload Types","text":"Value Name Description <code>0x00</code> <code>PAYLOAD_TYPE_REQ</code> Request (destination/source hashes + MAC) <code>0x01</code> <code>PAYLOAD_TYPE_RESPONSE</code> Response to <code>REQ</code> or <code>ANON_REQ</code> <code>0x02</code> <code>PAYLOAD_TYPE_TXT_MSG</code> Plain text message <code>0x03</code> <code>PAYLOAD_TYPE_ACK</code> Acknowledgment <code>0x04</code> <code>PAYLOAD_TYPE_ADVERT</code> Node advertisement <code>0x05</code> <code>PAYLOAD_TYPE_GRP_TXT</code> Group text message (unverified) <code>0x06</code> <code>PAYLOAD_TYPE_GRP_DATA</code> Group datagram (unverified) <code>0x07</code> <code>PAYLOAD_TYPE_ANON_REQ</code> Anonymous request <code>0x08</code> <code>PAYLOAD_TYPE_PATH</code> Returned path <code>0x09</code> <code>PAYLOAD_TYPE_TRACE</code> Trace a path, collecting SNR for each hop <code>0x0A</code> <code>PAYLOAD_TYPE_MULTIPART</code> Packet is part of a sequence of packets <code>0x0B</code> <code>PAYLOAD_TYPE_CONTROL</code> Control packet data (unencrypted) <code>0x0C</code> <code>PAYLOAD_TYPE_OTA</code> OTA-over-LoRa firmware distribution <code>0x0D</code> reserved reserved <code>0x0E</code> reserved reserved <code>0x0F</code> <code>PAYLOAD_TYPE_RAW_CUSTOM</code> Custom packet (raw bytes, custom encryption)"},{"location":"packet_format/#payload-versions","title":"Payload Versions","text":"Value Version Description <code>0x00</code> 1 1-byte src/dest hashes, 2-byte MAC <code>0x01</code> 2 Future version (e.g., 2-byte hashes, 4-byte MAC) <code>0x02</code> 3 Future version <code>0x03</code> 4 Future version"},{"location":"payloads/","title":"Payload Format","text":"<p>Inside each MeshCore Packet is a payload, identified by the payload type in the packet header. The types of payloads are:</p> <ul> <li>Request, response, and plain text (<code>0x00</code>-<code>0x02</code>).</li> <li>Acknowledgment and node advertisement (<code>0x03</code>-<code>0x04</code>).</li> <li>Group text and group datagram (<code>0x05</code>-<code>0x06</code>).</li> <li>Anonymous request and returned path (<code>0x07</code>-<code>0x08</code>).</li> <li>Trace, multipart, control, and OTA (<code>0x09</code>-<code>0x0C</code>).</li> <li>Custom raw data (<code>0x0F</code>).</li> </ul> <p>This document describes the shared payload envelopes implemented by the core. Application-specific request, response, control, and custom bodies can add their own formats.</p> <p>NOTE: all 16 and 32-bit integer fields are Little Endian.</p>"},{"location":"payloads/#important-concepts","title":"Important concepts:","text":"<ul> <li>Node hash: the first byte of the node's public key</li> </ul>"},{"location":"payloads/#node-advertisement","title":"Node advertisement","text":"<p>This kind of payload notifies receivers that a node exists, and gives information about the node</p> Field Size (bytes) Description public key 32 Ed25519 public key of the node timestamp 4 unix timestamp of advertisement signature 64 Ed25519 signature of public key, timestamp, and app data appdata rest of payload optional, see below <p>Appdata</p> Field Size (bytes) Description flags 1 specifies which of the fields are present, see below latitude 4 (optional) decimal latitude multiplied by 1000000, integer longitude 4 (optional) decimal longitude multiplied by 1000000, integer feature 1 2  (optional) reserved for future use feature 2 2  (optional) reserved for future use name rest of appdata name of the node <p>Appdata Flags</p> Value Name Description <code>0x01</code> is chat node advert is for a chat node <code>0x02</code> is repeater advert is for a repeater <code>0x03</code> is room server advert is for a room server <code>0x04</code> is sensor advert is for a sensor server <code>0x10</code> has location appdata contains lat/long information <code>0x20</code> has feature 1 Reserved for future use. <code>0x40</code> has feature 2 Reserved for future use. <code>0x80</code> has name appdata contains a node name"},{"location":"payloads/#acknowledgement","title":"Acknowledgement","text":"<p>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 acknowledgement packet. Current <code>CLI_DATA</code> commands do not cause acknowledgement responses, neither discrete nor extra; their text reply is the application-level result. Repeaters still ACK the legacy plain-text form before processing it.</p> <p>Repeater remote CLI keeps one volatile copy of the most recently completed reply, keyed by the authenticated sender, request timestamp, and command text. Repeating that same logical request re-sends the text reply without executing the command again. A retry must therefore preserve the original timestamp and command text. The cache is cleared by reboot and replaced by the next completed remote command; commands that intentionally produce no text reply remain silent.</p> Field Size (bytes) Description checksum 4 CRC checksum of message timestamp, text, and sender pubkey"},{"location":"payloads/#returned-path-request-response-and-plain-text-message","title":"Returned path, request, response, and plain text message","text":"<p>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.</p> Field Size (bytes) Description destination hash 1 first byte of destination node public key source hash 1 first byte of source node public key cipher MAC 2 MAC for encrypted data in next field ciphertext rest of payload encrypted message, see subsections below for details"},{"location":"payloads/#returned-path","title":"Returned path","text":"<p>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.</p> Field Size (bytes) Description path descriptor 1 low 6 bits are the hash count; high 2 bits encode hash size minus one path count \u00d7 size encoded node-hash prefixes, each 1-3 bytes; the four-byte code is reserved extra type 1 low nibble is the bundled payload type, such as acknowledgment or response; high nibble is reserved extra rest of data extra, bundled payload content, follows same format as main content defined by this document"},{"location":"payloads/#request","title":"Request","text":"Field Size (bytes) Description timestamp 4 sender time (unix timestamp) request data rest of payload application-defined request payload body <p>For the common chat/server helpers in <code>BaseChatMesh</code>, the current request type values are:</p> Value Name Description <code>0x01</code> get stats get stats of repeater or room server <code>0x02</code> keepalive keep-alive request used for maintained connections"},{"location":"payloads/#get-stats","title":"Get stats","text":"<p>Gets information about the node, possibly including the following:</p> <ul> <li>Battery level (millivolts)</li> <li>Current transmit queue length</li> <li>Current free queue length</li> <li>Last RSSI value</li> <li>Number of received packets</li> <li>Number of sent packets</li> <li>Total airtime (seconds)</li> <li>Total uptime (seconds)</li> <li>Number of packets sent as flood</li> <li>Number of packets sent directly</li> <li>Number of packets received as flood</li> <li>Number of packets received directly</li> <li>Error flags</li> <li>Last SNR value</li> <li>Number of direct route duplicates</li> <li>Number of flood route duplicates</li> <li>Number posted (?)</li> <li>Number of post pushes (?)</li> </ul>"},{"location":"payloads/#get-telemetry-data","title":"Get telemetry data","text":"<p>Not defined in <code>BaseChatMesh</code>. Sensor- and application-specific request payloads may be implemented by higher-level firmware.</p>"},{"location":"payloads/#get-telemetry","title":"Get Telemetry","text":"<p>Not defined in <code>BaseChatMesh</code>.</p>"},{"location":"payloads/#get-minmaxave-sensor-nodes","title":"Get Min/Max/Ave  (Sensor nodes)","text":"<p>Not defined in <code>BaseChatMesh</code>.</p>"},{"location":"payloads/#get-access-list","title":"Get Access List","text":"<p>Not defined in <code>BaseChatMesh</code>.</p>"},{"location":"payloads/#get-neighbors","title":"Get Neighbors","text":"<p>Not defined in <code>BaseChatMesh</code>.</p>"},{"location":"payloads/#get-owner-info","title":"Get Owner Info","text":"<p>Not defined in <code>BaseChatMesh</code>.</p>"},{"location":"payloads/#response","title":"Response","text":"Field Size (bytes) Description content rest of payload application-defined response body <p>Response contents are opaque application data. There is no single generic response envelope beyond the encrypted payload wrapper shown above.</p>"},{"location":"payloads/#plain-text-message","title":"Plain text message","text":"Field Size (bytes) Description timestamp 4 send time (unix timestamp) txt_type + attempt 1 upper six bits are txt_type (see below), lower two bits are attempt number (0..3) message rest of payload the message content, see next table <p>txt_type</p> Value Description Message content <code>0x00</code> plain text message the plain text of the message <code>0x01</code> CLI data CLI command OR reply text <code>0x02</code> signed plain text message first four bytes is sender pubkey prefix, followed by plain text message <code>0x03</code> CLI command (since v1.18+) CLI command text (explicit) <p>For a room post, companion firmware uses its own monotonic clock for the on-air timestamp and preserves that timestamp across application retries. Room servers track post timestamps separately from login, request, and CLI traffic. They also remember recent accepted posts by sender, timestamp, and text: an exact retry is ACKed again without storing a duplicate, while stale or same-timestamp mismatches are rejected.</p>"},{"location":"payloads/#anonymous-request","title":"Anonymous request","text":"Field Size (bytes) Description destination hash 1 first byte of destination node public key public key 32 sender's Ed25519 public key cipher MAC 2 MAC for encrypted data in next field ciphertext rest of payload encrypted message, see below for details"},{"location":"payloads/#room-server-login","title":"Room server login","text":"Field Size (bytes) Description timestamp 4 sender time (unix timestamp) sync timestamp 4 sender's \"sync messages SINCE x\" timestamp password rest of message password for room"},{"location":"payloads/#repeatersensor-login","title":"Repeater/Sensor login","text":"Field Size (bytes) Description timestamp 4 sender time (unix timestamp) password rest of message password for repeater/sensor"},{"location":"payloads/#repeater-regions-request","title":"Repeater - Regions request","text":"Field Size (bytes) Description timestamp 4 sender time (unix timestamp) req type 1 0x01 (request sub type) reply path len 1 path len for reply reply path (variable) reply path"},{"location":"payloads/#repeater-owner-info-request","title":"Repeater - Owner info request","text":"Field Size (bytes) Description timestamp 4 sender time (unix timestamp) req type 1 0x02 (request sub type) reply path len 1 path len for reply reply path (variable) reply path"},{"location":"payloads/#repeater-clock-and-status-request","title":"Repeater - Clock and status request","text":"Field Size (bytes) Description timestamp 4 sender time (unix timestamp) req type 1 0x03 (request sub type) reply path len 1 path len for reply reply path (variable) reply path"},{"location":"payloads/#group-text-message","title":"Group text message","text":"Field Size (bytes) Description channel hash 1 first byte of SHA256 of channel's shared key cipher MAC 2 MAC for encrypted data in next field ciphertext rest of payload encrypted message, see below for details <p>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 <code>0x00</code> because it is a \"plain text message\". The message will be of the form <code>&lt;sender name&gt;: &lt;message body&gt;</code> (eg., <code>user123: I'm on my way</code>).</p> <p>The sender name is unverified message text. Group messages contain no sender signature, so any channel-key holder can choose any sender name.</p>"},{"location":"payloads/#group-datagram","title":"Group datagram","text":"Field Size (bytes) Description channel hash 1 first byte of SHA256 of channel's shared key cipher MAC 2 MAC for encrypted data in next field ciphertext rest of payload encrypted data, see below for details <p>The data contained in the ciphertext uses the format below:</p> Field Size (bytes) Description data type 2 Identifier for type of data. (See number_allocations.md) data len 1 byte length of data data rest of payload (depends on data type)"},{"location":"payloads/#control-data","title":"Control data","text":"Field Size (bytes) Description flags 1 upper 4 bits is sub_type data rest of payload typically unencrypted data"},{"location":"payloads/#discover_req-sub_type","title":"DISCOVER_REQ (sub_type)","text":"Field Size (bytes) Description flags 1 0x8 (upper 4 bits), prefix_only (lowest bit) type_filter 1 bit for each ADV_TYPE_* tag 4 randomly generate by sender since 4 (optional) epoch timestamp (0 by default)"},{"location":"payloads/#discover_resp-sub_type","title":"DISCOVER_RESP (sub_type)","text":"Field Size (bytes) Description flags 1 0x9 (upper 4 bits), node_type (lower 4) snr 1 signed, SNR*4 tag 4 reflected back from DISCOVER_REQ pubkey 8 or 32 node's ID (or prefix)"},{"location":"payloads/#trace","title":"Trace","text":"<p>Trace packets use direct routing. Their normal direct-path header is empty; instead, the intended route follows a fixed nine-byte trace header in the payload. Each forwarding node appends its received SNR multiplied by four to the packet's route-accumulator field.</p> Field Size (bytes) Description tag 4 Sender-selected trace identifier. auth code 4 Application-defined authentication/correlation value. flags 1 Low two bits encode the route hash size. Current senders use the legacy <code>1 &lt;&lt; value</code> interpretation (1, 2, 4, or 8 bytes); receivers also accept the packed 1-4-byte interpretation where it is unambiguous. route rest Concatenated node-hash prefixes for the requested direct route. <p>At the destination, the application receives the tag, auth code, flags, accumulated SNR bytes, and original route bytes. Trace therefore differs from a normal direct packet whose path is carried entirely in the packet route field.</p>"},{"location":"payloads/#multipart","title":"Multipart","text":"<p>The first payload byte identifies the inner payload and how many packets remain:</p> Field Size (bytes) Description remaining + type 1 Upper nibble is the remaining-packet count; lower nibble is the inner payload type. inner data rest Data for the inner payload type. <p>The core currently creates and consumes multipart acknowledgments. For that form, the low nibble is <code>0x03</code> and the next four bytes are the acknowledgment CRC. Other multipart inner types are reserved for application or future use.</p>"},{"location":"payloads/#ota","title":"OTA","text":"<p>An OTA payload contains one OTA protocol message and is normally sent by flood. Its message types, integrity fields, and transfer state are defined in the OTA-over-LoRa protocol. Builds without OTA support can still relay an opaque OTA packet when their routing policy permits it.</p>"},{"location":"payloads/#custom-packet","title":"Custom packet","text":"<p>Custom packets have no defined format.</p>"},{"location":"qr_codes/","title":"QR Codes","text":"<p>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.</p>"},{"location":"qr_codes/#add-channel","title":"Add Channel","text":"<p>Example URL:</p> <pre><code>meshcore://channel/add?name=Public&amp;secret=8b3387e9c5cdea6ac9e5edbaa115cd72\n</code></pre> <p>Parameters:</p> <ul> <li><code>name</code>: Channel name (URL-encoded)</li> <li><code>secret</code>: 16-byte secret represented as 32 hex characters</li> <li><code>region_scope</code>: Region Scope (optional, URL-encoded if provided)<ul> <li>Supported by MeshCore App v1.47.0+</li> </ul> </li> </ul>"},{"location":"qr_codes/#add-contact","title":"Add Contact","text":"<p>Example URL:</p> <pre><code>meshcore://contact/add?name=Example+Contact&amp;public_key=9cd8fcf22a47333b591d96a2b848b73f457b1bb1a3ea2453a885f9e5787765b1&amp;type=1\n</code></pre> <p>Parameters:</p> <ul> <li><code>name</code>: Contact name (URL-encoded if needed)</li> <li><code>public_key</code>: 32-byte public key represented as 64 hex characters</li> <li><code>type</code>: numeric contact type<ul> <li><code>1</code>: Companion</li> <li><code>2</code>: Repeater</li> <li><code>3</code>: Room Server</li> <li><code>4</code>: Sensor</li> </ul> </li> </ul>"},{"location":"rak3401_mota_chain/","title":"RAK3401 1W repeater compact LoRa update chain","text":"<p>Status: published prerelease for controlled, recoverable lab use. On 29-Aug-2026 steps 1-9 completed on the target RAK3401 and are byte-for-byte identical to the corresponding transitions in the physically passed <code>fd98bc90</code> chain. The replacement step 10 installs the current <code>3f6eddd5</code> endpoint. That replacement package and the hardened current runner have passed offline reconstruction plus the exact deployed bootloader simulator, but have not had a new physical end-to-end run. Use the lab gate and keep local DFU/SWD recovery available. Multi-hop and alternate-bandwidth estimates remain planning data, not physical qualification.</p> <p>The prerelease is <code>rak3401-mota-v1.16.07-c1caa5ad-to-v1.17.1.6-3f6eddd5</code>. Use this asset:</p> <pre><code>RAK3401-update-chain-v1.16.7-c1caa5ad-to-v1.17.1.6-3f6eddd5.zip\n</code></pre> <ul> <li>prerelease ZIP SHA-256: <code>135783dd8777490db2422a7543f7d80e3cf03f621d5ac362da930abbc1850dc4</code></li> <li>inner <code>SHA256SUMS.txt</code> SHA-256: <code>93835ed497c579be0a2322292e7f15ab095e7c8ab7892833fe7df3130dbdaba4</code></li> <li>endpoint image SHA-256: <code>cd1e9b819f9e918f9f2ceaf37b8a74bf242e2be78f319af2cf02a42d7729d0f4</code></li> <li>endpoint EndF body hash: <code>9BD7CF682EE065AE</code></li> </ul> <p><code>--verify-only</code> remains the safe default. Live preflight and installation of this prerelease require <code>--accept-test-candidate</code>. That switch bypasses only the prerelease-status gate; it does not bypass the archive, identity, bootloader, route, watchdog, reachability, or post-boot checks.</p>"},{"location":"rak3401_mota_chain/#exact-destination","title":"Exact destination","text":"<p>This chain is intentionally specific to one firmware lineage and hardware target:</p> <ul> <li>target ID: <code>2FA509C1</code></li> <li>hardware: <code>RAK_3401</code></li> <li>role: <code>RAK_3401_repeater_lora_ota_no_external_sensors</code></li> <li>start: <code>v1.16.7.0-c1caa5ad</code>, EndF <code>71F4026CBE4B8B74</code></li> <li>endpoint source: MeshCore <code>3f6eddd5c20f1fa3df6ba1cc208efbe3e2fffb43</code></li> <li>endpoint label: <code>v1.17.1.6-halo-keymind-cascade-dev-3f6eddd5</code></li> <li>endpoint packed version: <code>0x01110106</code></li> <li>deployment target key: <code>63d8df6387eaffd2e25db7d2a8ad967a65202182a48d681d7e7a9260f917280d</code></li> </ul> <p>The exact starting application is the <code>lora-ota-v1.16.07-halo-keymind-cascade-dev-3a6af3bf</code> RAK3401 asset. Its outer ZIP SHA-256 is <code>58ead2ea18efafda186bc9d983fe08cdf65f69b0e5a3a1c72c18fe35948a254c</code>; its 566,912-byte <code>firmware.bin</code> SHA-256 is <code>4301fc63ebd661c70f9bc40e7eca44d3cb8a358cb3c0075e700d9676a57478cb</code>. The endpoint build ZIP SHA-256 is <code>a9fca9be145a96feb650b57c43b5ed173d74d2f3194da12e31b1c54352635b56</code>.</p>"},{"location":"rak3401_mota_chain/#retained-and-omitted-hardware-support","title":"Retained and omitted hardware support","text":"<p>Despite the legacy <code>no_external_sensors</code> target name, the endpoint retains the RAK12501 GPS provider and the common INA3221, INA219, INA226, and INA260 I2C voltage/current monitors. Install RAK12501 in sensor slot A. Do not use slot D with the RAK13302 1 W radio because the GPS reset/PPS signals overlap the radio's BUSY/DIO1 wiring.</p> <p>The reduced profile omits optional external environmental and ranging devices: AHTX0, BME280, BMP280, SHTC3, SHT4x, LPS22HB, MLX90614, VL53L0X, BME680, BMP085, RAK12035, and BME680 BSEC. Board radio, display, buttons, battery telemetry, GPS, and the INA monitor family remain. No additional \u201cremove I2C temperature\u201d image is needed: the optional I2C temperature/environment drivers are already in the omitted set, while removing the remaining I2C/INA support would discard desired voltage/current monitoring and create another firmware identity without helping this route.</p> <p>Do not use the chain on another target ID, hardware family, starting image, or firmware body hash. The runner checks all four.</p>"},{"location":"rak3401_mota_chain/#why-the-deployed-otafix24-and-old-staging-ceiling-work","title":"Why the deployed OTAFIX2.4 and old staging ceiling work","text":"<p>The deployed bootloader is not changed and no package uses the newer expanded <code>0xED000</code> ceiling. Each package remains bottom-aligned below the old bootloader's <code>0xD4000</code> scan ceiling. Its detools workspace is page-aligned and must satisfy:</p> <pre><code>0x26000 + inplace_memory &lt;= staged_package_start &lt; 0xD4000\n</code></pre> <p>The old bootloader already reads and validates that encoded detools geometry before its first destructive write. The previous application receiver was the limiting part: it reserved a fixed <code>0x98000</code> workspace before accepting a download. Step 1 therefore remains byte-for-byte identical to the physically passed 89,844-byte package. Step 2 is a 46,364-byte fixed-workspace package that installs the compatibility receiver. Later receivers stage above the real EndF image extent and let the bootloader enforce each package's selected workspace.</p> <p>Every package in this candidate is an ordinary application container using format ABI 2 and in-place codec 2. The historical bridge applications scan the bootloader capability marker byte-by-byte, so they recognize the released <code>0.9.2-OTAFIX2.4</code> marker at absolute address <code>0xFCD16</code>. That immutable marker advertises ABI 2, codec mask <code>0x0004</code>, and internal storage profile 0. The <code>3f6eddd5</code> endpoint retains the matching legacy application-update fallback. Its separately compiled internal bootloader-update feature remains unavailable because privileged self-update requires a current ABI 3 marker with the exact storage profile. Installing this chain therefore does not replace the bootloader, and the final application can still accept a future valid ABI-2/codec-2 application update.</p> <p>The exact installed bootloader is the <code>0.9.2-OTAFIX2.4</code> RAK4631 asset. Its outer ZIP SHA-256 is <code>5e29e7a8982cc2ed5f8868435556eb09387250fe5b9a7e8443bac325247dfed1</code>; its 191,040-byte <code>sd_bl.bin</code> SHA-256 is <code>a97f834388db0f1da6c29f6d8f458ff6d3e6a26034709044566384838919bb23</code>. The exact simulator was compiled from release commit <code>d73de8372e89b8ef352747c8bc7a1aaeab80fbfe</code>; its executable SHA-256 is <code>9dacf24b1023fe2f4c620419417649ccc9538dd4a611b47bc19b7fedb97ceba6</code>.</p> <p>The schema-2 exhaustive search checked 1,799 candidate geometries and found 12 feasible forward edges in the declared exact 12-node inventory. It found one shortest ten-package route and selected the smallest total container bytes as the secondary objective. This minimum applies only to that declared inventory and geometry table, not every conceivable new bridge image. The selected route is:</p> Step From To Workspace Package Margin 1 1.16.7.0 1.16.7.9 <code>0x98000</code> 89,844 0 2 1.16.7.9 1.16.7.10 <code>0x98000</code> 46,364 40,960 3 1.16.7.10 1.16.8.7 <code>0x91000</code> 106,029 12,288 4 1.16.8.7 1.16.9.105 <code>0x89000</code> 149,927 0 5 1.16.9.105 1.16.9.110 <code>0x8E000</code> 111,312 16,384 6 1.16.9.110 1.16.9.113 <code>0x8F000</code> 120,624 4,096 7 1.16.9.113 1.16.9.117 <code>0x8B000</code> 139,637 0 8 1.16.9.117 1.16.10.0 <code>0x7E000</code> 174,202 20,480 9 1.16.10.0 1.17.1.3 <code>0x6B000</code> 271,569 0 10 1.17.1.3 1.17.1.6 <code>0x76000</code> 197,825 28,672 <p>Total mOTA transfer data is 1,407,333 bytes. <code>ROUTE.json</code>, <code>CHAIN.csv</code>, and <code>validation-results.json</code> in the bundle pin the exact geometry and image hash for every transition.</p> <p>Steps 1-9 are byte-for-byte identical to the transitions that passed on the physical RAK3401. The replacement step 10, from the physically reached <code>FE65A6135A1E7B3F</code> v1.17.1.3 body to <code>9BD7CF682EE065AE</code>, has offline qualification only. All ten packages passed independent container checks, zero-filled and erased-workspace reconstruction, and the exact deployed <code>0.9.2-OTAFIX2.4</code> simulator. Those results prove the package bytes and apply geometry; they are not a physical claim for the replacement step 10 or the hardened runner.</p> <p>The 171-byte transport DEFLATE support lands only in the final <code>3f6eddd5</code> application. The starting receiver and every receiver that accepts steps 1-10 lack that inflate path, so all ten legacy-chain transfers remain raw and the 1,407,333-byte total above is not automatically reduced over LoRa. A later update can negotiate transport compression after this endpoint is running; the application inflates before staging, and the immutable bootloader still applies an ordinary ABI-2/codec-2 container.</p>"},{"location":"rak3401_mota_chain/#host-requirements","title":"Host requirements","text":"<p>Install Python 3.9 or newer, <code>meshcli</code> 1.6.0 or newer, the current <code>motatool</code>, and an OTA-enabled Full Companion or repeater that can seed mOTA files.</p>"},{"location":"rak3401_mota_chain/#verify-offline","title":"Verify offline","text":"<p>No password or device is needed:</p> <pre><code>python3 tools/lora_ota/rak3401_mota_chain.py \\\n  --bundle /path/to/RAK3401-update-chain-v1.16.7-c1caa5ad-to-v1.17.1.6-3f6eddd5.zip \\\n  --work-dir ./rak3401-mota-chain-work \\\n  --motatool /path/to/motatool \\\n  --verify-only\n</code></pre> <p>When given the ZIP, the runner checks its pinned outer hash and binds the extraction cache to that exact archive. An explicitly supplied extracted root starts at the pinned inner checksum list. In either case it checks complete inner coverage, all ten manifests, continuity, image anchors, both recovery images, and every container with <code>motatool</code>. Passing this command means offline and simulator qualification only; it does not unlock live use.</p>"},{"location":"rak3401_mota_chain/#guarded-prerelease-lab-command","title":"Guarded prerelease lab command","text":"<p>These direct-link arguments match the physical transition setup, but the current package replaces step 10 and the current host runner contains later cleanup and recovery fixes. Neither has been cleanly rerun through the whole chain. Keep local USB/SWD recovery available. The candidate switch bypasses only the prerelease-status block; all identity, checksum, bootloader, route, watchdog, reachability, and post-boot gates still run.</p> <p>Restore the test start locally with <code>recovery/test-start/RAK3401-test-start-v1.16.7-c1caa5ad.uf2</code>, then run:</p> <pre><code>export MESHCORE_ADMIN_PASSWORD='password'\n\npython3 tools/lora_ota/rak3401_mota_chain.py \\\n  --bundle /path/to/RAK3401-update-chain-v1.16.7-c1caa5ad-to-v1.17.1.6-3f6eddd5.zip \\\n  --work-dir ./rak3401-mota-chain-work \\\n  --controller-serial /dev/ttyACM0 \\\n  --source-tcp 192.168.1.51:5001 \\\n  --source-cli-tcp 192.168.1.51:5002 \\\n  --source-shares-controller \\\n  --target-key 63d8df63 \\\n  --temp-radio 909.950,500,5,5,120 \\\n  --ota-hops 0 \\\n  --legacy-full-airtime \\\n  --motatool /path/to/motatool \\\n  --accept-test-candidate \\\n  --yes\n</code></pre> <p>Keep the work directory. Rerunning the same command resumes only when the live EndF body hash matches an exact chain node. Never manually skip a package. <code>--legacy-full-airtime</code> temporarily sets the destination airtime factor to zero and restores it at the endpoint. Use that option only where the selected frequency and local duty-cycle rules permit a full transmit budget; omit it otherwise.</p>"},{"location":"rak3401_mota_chain/#superseded-b40d2e6c-prerelease","title":"Superseded <code>b40d2e6c</code> prerelease","text":"<p>The immediately preceding prerelease remains pinned for offline provenance:</p> <ul> <li>release: <code>rak3401-mota-v1.16.07-c1caa5ad-to-v1.17.1.5-b40d2e6c</code></li> <li>asset: <code>RAK3401-update-chain-v1.16.7-c1caa5ad-to-v1.17.1.5-b40d2e6c.zip</code></li> <li>outer ZIP SHA-256: <code>8e7f0c2565f37d4372fa51dc3ba72b591e7f38b74be09303e48641623f99bce4</code></li> <li>inner <code>SHA256SUMS.txt</code> SHA-256: <code>29a02a6c4c83eafa80168a80562b0ded5d8432e6cc02cfaca289cb2ed426681a</code></li> <li>endpoint image SHA-256: <code>a7761da8af1f2447d7f01d72e2b1456b99c0e874a165d6483f48ab1f58e8d905</code></li> <li>endpoint EndF body hash: <code>1FA6AAA3C28D8BD8</code></li> </ul> <p>Its first nine packages are byte-for-byte identical to the current release and the physical <code>fd98bc90</code> evidence. Its different step 10 had offline qualification only. The runner recognizes this exact archive separately and keeps live use gated; it is not interchangeable with the current <code>3f6eddd5</code> asset.</p>"},{"location":"rak3401_mota_chain/#legacy-fd98bc90-physical-and-swd-qualification","title":"Legacy <code>fd98bc90</code> physical and SWD qualification","text":"<p>The earlier local candidate remains the exact physical evidence source for this route:</p> <pre><code>RAK3401-update-chain-v1.16.7-c1caa5ad-to-v1.17.1.5-fd98bc90.zip\n</code></pre> <ul> <li>candidate ZIP SHA-256: <code>c0b33f4568985e8b2b8dc99411295907212cf2bad21764b6333d5e0ba298fd61</code></li> <li>inner <code>SHA256SUMS.txt</code> SHA-256: <code>3f8c4af8096b96a4aa6506825c387cc8a06f74d5213a29c9387bd11689546881</code></li> <li>endpoint image SHA-256: <code>31c182c888ceb1135e5afb2376610d93cee2e807b556c838e07fd4486c79d095</code></li> <li>endpoint EndF body hash: <code>9179B98432895924</code></li> </ul> <p>All ten exact <code>fd98bc90</code> transitions completed on the RAK3401 with its deployed <code>0.9.2-OTAFIX2.4</code> bootloader and a Heltec V4 source at 909.950 MHz / 500 kHz / SF5 / CR5. Every intermediate EndF hash matched. Independent SWD readback then matched the endpoint application, original bootloader, SoftDevice/MBR, and UICR byte-for-byte. Steps 1-9 are also the exact first nine packages in the <code>b40d2e6c</code> and <code>3f6eddd5</code> prereleases. All three candidates have different step 10 packages or endpoints, so the physical result and step-10 timing must not be attributed to either later prerelease.</p>"},{"location":"rak3401_mota_chain/#measured-direct-link-timing-for-fd98bc90","title":"Measured direct-link timing for <code>fd98bc90</code>","text":"<p>The first <code>ready to install</code> transfer ages were:</p> Step Blocks Transfer 1 88 598 s 2 45 42 s 3 103 81 s 4 146 105 s 5 109 76 s 6 118 94 s 7 136 102 s 8 170 127 s 9 264 187 s 10 169 193 s <p>The physically observed bulk-transfer total for those exact legacy packages is 1,605 seconds (26m45s). The log came from the pre-cleanup-fix runner revision. Step 1 was measured before the host began forcing source RXPS off and is therefore a conservative outlier. A new complete run with that fix is projected at roughly 18\u201319 minutes of bulk transfer, but that projection is not a substitute for the measured total. Allow about 70\u201375 minutes direct at BW500 for validation, ten transfers, installs/reboots, retained-store checks, and final restoration.</p> <p>The legacy step 10's longer per-block time was not a V4 TempRadio delay: the source RXPS readback was off. Its v1.17.1.3 requester uses non-overlapping adaptive flights and a five-second recovery floor and logged more block reloads than step 8. The V4 itself intentionally schedules its local radio handoff after 1.5 seconds so the normal-channel command reply can drain; the host waits three seconds and then checks the live TempRadio state.</p>"},{"location":"rak3401_mota_chain/#live-progress-and-speed-sanity-checks","title":"Live progress and speed sanity checks","text":"<p>The runner watches <code>motatool serve -v</code> locally, so its quarter-progress reports do not consume LoRa airtime. At BW500 direct, physically measured steps 2\u20139 averaged about 1.1\u20131.4 newly requested payload blocks per second; the legacy step 10 averaged about 0.88 blocks/s, and step 1's 0.15 blocks/s was the known pre-RXPS-fix outlier. Use those only as bench sanity ranges, not guarantees. Relays, narrower bandwidths, interference, and recovery reads lower the rate.</p> <p>Healthy output keeps advancing from <code>[download] passive source progress x/y</code> to <code>source read all y payload blocks</code>, followed by destination status <code>ready to install y/y (100%)</code> for the same manifest ID. Aggregate reads above the unique block count indicate recovery/retry traffic. A radio-scaled no-progress window causes one destination status check; the transfer timeout leaves the partial download staged for an exact-package resume. Stop and diagnose instead of installing if the manifest changes, progress remains flat through those checks, the final receiver count is not <code>y/y</code>, or the measured rate is far below the matching bandwidth/hop estimate without an understood RF cause.</p> <p>For planning only, scale the conservative measured <code>fd98bc90</code> 26m45s bulk baseline by the qualified adaptive-preamble airtime and by each additional relay transmission:</p> Bandwidth, SF5/CR5 Direct / 0 relays 1 relay 2 relays 500 kHz 26m45s 53m30s 1h20m15s 250 kHz 46m51s 1h33m42s 2h20m33s 125 kHz 1h27m03s 2h54m07s 4h21m11s 62.5 kHz 2h54m07s 5h48m15s 8h42m23s <p>These are transfer-only estimates, not measured alternate-bandwidth or relay results. Packet loss, relay contention, discovery, administrative commands, staged verification, and ten reboot cycles add time. The bandwidth factors are not simple powers of two because the adaptive wire preamble is 128 symbols at 500 kHz, 64 at 250 kHz, and 32 at 125/62.5 kHz.</p>"},{"location":"rak3401_mota_chain/#manual-operation","title":"Manual operation","text":"<p>The automated runner is preferred because it binds every transition to the expected MID and body hash. The manual details below document the checks used during qualification and recovery; they are not permission to skip the runner's candidate gate. Keep a written copy of each original setting and never skip a step even when a later package appears in <code>ota ls</code>.</p>"},{"location":"rak3401_mota_chain/#1-verify-and-extract-the-asset","title":"1. Verify and extract the asset","text":"<pre><code>sha256sum RAK3401-update-chain-v1.16.7-c1caa5ad-to-v1.17.1.6-3f6eddd5.zip\nunzip RAK3401-update-chain-v1.16.7-c1caa5ad-to-v1.17.1.6-3f6eddd5.zip\ncd RAK3401-update-chain-v1.16.7-c1caa5ad-to-v1.17.1.6-3f6eddd5\nsha256sum -c SHA256SUMS.txt\nfor package in motas/*.mota; do motatool verify \"$package\" || exit 1; done\n</code></pre> <p>The outer hash must be <code>135783dd8777490db2422a7543f7d80e3cf03f621d5ac362da930abbc1850dc4</code>, and the SHA-256 of the extracted <code>SHA256SUMS.txt</code> must be <code>93835ed497c579be0a2322292e7f15ab095e7c8ab7892833fe7df3130dbdaba4</code>. Do not continue after any checksum or verification error.</p>"},{"location":"rak3401_mota_chain/#2-record-and-prepare-the-destination","title":"2. Record and prepare the destination","text":"<p>Before changing anything, save the complete replies from:</p> <pre><code>ver\nota self\nget bootloader.ver\nget system.watchdog\nget radio.rxps\npowersaving\nget rxdelay\nget af\nota config\n</code></pre> <p>The starting <code>ota self</code> hash must be <code>71F4026CBE4B8B74</code>, the target must be <code>2FA509C1</code>, and the hardware must be <code>RAK_3401</code>. Disable the nRF52 system watchdog before the chain:</p> <pre><code>set system.watchdog off\n</code></pre> <p>The hardware watchdog cannot stop immediately. The RAK will reset once within about 60 seconds. Reconnect, wait at least 90 seconds from the command, and require <code>get system.watchdog</code> to report <code>&gt; off</code> before continuing.</p> <p>For a direct bench link, apply these temporary transfer guardrails to the RAK after every bridge reboot:</p> <pre><code>powersaving off\nset radio.rxps off\nset rxdelay 0\nota config hops 0\ntempradio 909.950,500,5,5,120\n</code></pre> <p>Where local duty-cycle rules permit it, <code>set af 0</code> can also remove the legacy firmware's saved airtime wait during this bounded maintenance window. Record <code>get af</code> first and restore that exact value after the final step. Current firmware grants the bounded TempRadio transfer budget without overwriting the saved airtime factor.</p> <p><code>powersaving off</code> is an isolation guardrail, not the fix for the observed failure. The actual source failure was an oversized USB CDC reply; current firmware splits those reads. Some historical bridge builds may report RXPS as unsupported while already operating continuously. Verify the reported state and do not substitute a normal reboot for the one-time watchdog reset. Direct tests use <code>hops 0</code>: <code>hops 1</code> makes the target echo each source response despite there being no intermediate relay, increasing half-duplex loss and legacy three-second retries.</p> <p>The exact candidate cannot use fast RXPS throughout because its historical bridge applications predate the v1.17.1.5 adaptive-preamble contract. Keep RXPS off for all ten steps whether using SF5/BW250 or the faster direct-bench SF5/BW500 tuple. After the final endpoint is proven, a later update whose target, controller, source, and relays are all v1.17.1.5 or newer can use the generic LoRa OTA runner and its qualified adaptive-preamble boundaries.</p> <p>Put the source on the identical TempRadio tuple. A current ASCII-first Full Companion recognizes <code>motatool</code>'s initial <code>ota folder on</code> line directly:</p> <pre><code>motatool serve \\\n  --dir ./motas \\\n  --serial /dev/ttyACM1 \\\n  --baud 115200 \\\n  -v\n</code></pre> <p>The same command also works with older Full Companion firmware in binary mode, where the idle parser recognizes the identical preamble. Restart <code>motatool</code> for every step so the source emits a fresh catalog advert. Leave it running during the download and stop it with Ctrl-C only after the destination reports <code>ready to install</code>.</p>"},{"location":"rak3401_mota_chain/#3-install-all-ten-packages-in-order","title":"3. Install all ten packages in order","text":"Step Manifest ID Before hash Expected version After hash 1 <code>C147BCEF</code> <code>71F4026CBE4B8B74</code> <code>1.16.7.9</code> <code>42BC53A64288E845</code> 2 <code>BEB578FC</code> <code>42BC53A64288E845</code> <code>1.16.7.10</code> <code>1AD2AA8B6C478DA6</code> 3 <code>6D8EF814</code> <code>1AD2AA8B6C478DA6</code> <code>1.16.8.7</code> <code>D709A25308BC1831</code> 4 <code>40AC4CEB</code> <code>D709A25308BC1831</code> <code>1.16.9.105</code> <code>457BEDA5E6406C81</code> 5 <code>F6C8890B</code> <code>457BEDA5E6406C81</code> <code>1.16.9.110</code> <code>E76BFA205634CAB8</code> 6 <code>82405E89</code> <code>E76BFA205634CAB8</code> <code>1.16.9.113</code> <code>65328FC8A1FBED2D</code> 7 <code>80F40DB6</code> <code>65328FC8A1FBED2D</code> <code>1.16.9.117</code> <code>AF7532E13337FADD</code> 8 <code>DBF6310D</code> <code>AF7532E13337FADD</code> <code>1.16.10.0</code> <code>22002359BBDFA76E</code> 9 <code>C2979E08</code> <code>22002359BBDFA76E</code> <code>1.17.1.3</code> <code>FE65A6135A1E7B3F</code> 10 <code>B5011420</code> <code>FE65A6135A1E7B3F</code> <code>1.17.1.5</code> <code>1FA6AAA3C28D8BD8</code> <p>For each row, first prove that <code>ota self</code> exactly matches its Before hash, then inspect the manager before changing it:</p> <pre><code>ota status\n</code></pre> <p>Proceed to discovery only after that status is reconciled. When the manager is idle, run:</p> <pre><code>ota ls\nota pull MANIFEST_ID flash\nota status\n</code></pre> <p>If the first status reports this row's MID as partial, use <code>ota pull</code> with that same MID to resume it. If this row's MID is already ready, do not pull or cancel it; continue with the install checks below. If status reports the immediately previous row's MID as <code>verifying staged blocks</code>, wait through the bounded discovery window; require either that exact MID to become <code>ready to install</code> or the manager to become <code>no download</code>, and re-prove the current Before hash. Cancel only the same previous MID while it is visibly attached and ready. If it has become idle, send no cancel. Stop on any other MID, failed or incomplete state, ambiguous reply, or timeout. Never issue a blind <code>ota cancel</code>: it can discard a resumable or unrelated session.</p> <p>Repeat <code>ota status</code> at a restrained interval until it says <code>ready to install</code>. If the manifest is initially absent, wait for a fresh source advert, run <code>ota ls</code> again, or restart <code>motatool</code>; do not pull a different ID. Stop the seeder and install:</p> <pre><code>get system.watchdog\nota install\n</code></pre> <p>The watchdog reply must still be <code>&gt; off</code>. Allow the current default five-minute readiness window for the USB/LoRa identity to return; automation probes every 10 seconds and returns early as soon as the exact body is visible. Then run <code>ver</code>, <code>ota self</code>, and <code>ota help</code>. Require the row's exact After hash, require <code>bootloader: apply OK</code>, and require <code>rescue install &lt;hash16&gt;</code> in the help before exposing that bridge to the next package. This rescue-help gate applies to steps 1-9; step 10 is the endpoint and is not exposed to another package in this chain. A normal-radio <code>ota status</code> response of <code>no download</code> proves only that the manager is idle; legacy internal-flash firmware does not durably erase a retained container by accepting an IDLE <code>ota cancel</code>. Do not claim otherwise. When the same expected manifest reports <code>verifying staged blocks</code> after the next TempRadio starts, wait only for the bounded discovery window and require that it become <code>ready to install</code> or <code>no download</code>; stop on a changed ID, failed/incomplete state, or timeout. Prove the exact running body before cancelling an attached completed session. OTAFIX consumes the approval word during a successful install, so a retained endpoint container is inert and a later valid pull replaces it. Reapply the transfer guardrails and TempRadio tuple, restart <code>motatool</code>, and continue with the next row.</p> <p>If the board boots but <code>ota self</code> says the EndF is invalid, stop. Only when <code>ota status</code> still identifies that row's complete staged package may the guarded <code>ota rescue install BEFORE_HASH</code> command be used. It is not a force option and must use that row's exact Before hash. If the board does not boot, recover the documented start/recovery UF2 locally over USB. Step 10 is the endpoint and has no successor package in this chain. If its EndF is invalid, use local DFU/SWD rather than attempting an unqualified LoRa package.</p>"},{"location":"rak3401_mota_chain/#4-intermediate-relays-and-restoration","title":"4. Intermediate relays and restoration","text":"<p>On every managed intermediate relay, save <code>get rxdelay</code> and <code>get txdelay</code>, then use the airtime-scaled collision window during the maintenance session:</p> <pre><code>set rxdelay 0\nset txdelay 0.3\n</code></pre> <p>Current OTA transfer packets honor that configured relay <code>txdelay</code>; setting <code>0.3</code> gives competing relays a small randomized, airtime-scaled forwarding window. The source's manifest-fragment gap independently follows active packet airtime and duty spacing, clamped to 100-1000 ms. These two delays solve different problems.</p> <p>After step 10 is proven, restore each saved destination and relay value exactly, including <code>rxdelay</code>, RXPS, CPU power saving, <code>af</code>, <code>ota config hops</code>, and relay timing. Current full-parser repeater firmware accepts <code>normalradio</code> and restores the saved tuple after replying on the temporary channel:</p> <pre><code>normalradio\n</code></pre> <p>The <code>b40d2e6c</code> endpoint supports that command. If a recovery build unexpectedly replies <code>Unknown command</code>, shorten its lease to one minute with the same tuple:</p> <pre><code>tempradio 909.950,500,5,5,1\n</code></pre> <p>Wait for the lease to expire, return the controller and ordinary source to their saved normal channels, and then re-enable the RAK system watchdog:</p> <pre><code>set system.watchdog on\nget system.watchdog\n</code></pre> <p>A Full Companion source is the exception: its local TCP console supports <code>normalradio</code> and the automated runner uses it before restoring the shared Binary API radio tuple.</p> <p>Final lab success requires version <code>v1.17.1.5-halo-keymind-cascade-dev-b40d2e6c</code>, body hash <code>1FA6AAA3C28D8BD8</code>, target <code>2FA509C1</code>, hardware <code>RAK_3401</code>, and <code>get system.watchdog</code> reporting <code>&gt; on</code>. If a relay cannot be restored before its TempRadio lease ends, wait for it to return to the normal channel and restore its saved <code>rxdelay</code> and <code>txdelay</code> there.</p>"},{"location":"rak3401_mota_chain/#two-relay-deployment","title":"Two-relay deployment","text":"<p>The first nine direct package transitions above were physically observed as the byte-identical first nine transitions of the legacy chain. Replacement step 10, this hardened host-runner revision, and multi-hop operation are not cleanly end-to-end physically qualified. A controlled, recoverable multi-hop lab can exercise two intermediate relays by listing them farthest-to-nearest and using three OTA hops. Run a non-mutating preflight first; even preflight requires the prerelease candidate override because the command connects to live devices:</p> <pre><code>python3 tools/lora_ota/rak3401_mota_chain.py \\\n  --bundle /path/to/RAK3401-update-chain-v1.16.7-c1caa5ad-to-v1.17.1.5-b40d2e6c.zip \\\n  --work-dir ./rak3401-mota-chain-work \\\n  --controller-serial /dev/ttyACM0 \\\n  --source-tcp SOURCE_IP:5001 \\\n  --source-cli-tcp SOURCE_IP:5002 \\\n  --source-shares-controller \\\n  --target-key 63d8df63 \\\n  --relay 'Far Repeater' \\\n  --relay 'Near Repeater' \\\n  --temp-radio 909.950,250,5,5,120 \\\n  --ota-hops 3 \\\n  --motatool /path/to/motatool \\\n  --accept-test-candidate \\\n  --preflight-only\n</code></pre> <p>After preflight succeeds, rerun with <code>--yes</code> in place of <code>--preflight-only</code>. Confirm that the selected frequency and bandwidth are legal at the deployment location.</p>"},{"location":"rak3401_mota_chain/#rescue-and-completion","title":"Rescue and completion","text":"<p>The guarded <code>ota rescue install &lt;base_body_hash&gt;</code> command is present after step 1 and remains available through the step-9 bridge. It is not a force command: it refuses a valid normal EndF, a base mismatch, wrong target/hardware, or invalid payload. A failure before step 1 completes still requires local USB recovery because the deployed start image predates the rescue command. The final <code>b40d2e6c</code> endpoint uses the stricter shared-slot profile; its invalid-EndF recovery is local DFU/SWD, not the rescue command.</p> <p>Before the first mutation, the runner saves the destination's RXPS periods, CPU power-saving state, RX flood delay, airtime factor, and OTA hop reach in the persistent work directory, flushing both the file and its directory entry before changing a guardrail. It also saves the managed source's exact RXPS preference in the chain-root <code>source-rxps-settings.json</code> before disabling it. Every step reuses that protected record, so a rerun after a killed host process restores the chain-start preference instead of treating the temporary off state as original. The record is accepted only for the same CLI endpoint. The runner retires that chain-root record only after it has proved the source is back on its normal radio and restored the exact preference at the verified endpoint. The runner reads the destination, controller, source, and relay versions before applying the same RXPS policy as the generic runner. The mixed historical chain therefore verifies <code>radio.rxps off</code> after every bridge reboot; a future all-v1.17.1.5-or-newer SF5/BW250 chain would instead keep RXPS on under the qualified level-8/preamble-64 boundary. It also verifies <code>powersaving off</code> and <code>rxdelay 0</code>, plus <code>af 0</code> when <code>--legacy-full-airtime</code> was explicitly selected. It restores every original value only after the exact endpoint is proven. An interrupted run deliberately leaves those transfer guardrails active; rerun the same command with the same work directory to resume and restore them. CPU power saving was not the cause of the observed folder-source failure: that was a USB CDC receive-ring overrun fixed by bounded serial reads. The runtime settings remain conservative isolation and fast-link reliability guardrails.</p> <p>For every named <code>--relay</code>, the per-step runner also captures <code>rxdelay</code> and <code>txdelay</code>, writes them to <code>relay-timing-settings.json</code>, applies <code>rxdelay 0</code> and <code>txdelay 0.3</code> during transfer, verifies the readback, and restores both before the relay leaves TempRadio.</p> <p>The runner also keeps the watchdog off across the chain, rechecks identity and OTA reach before every package, requires the exact post-boot EndF hash, and only re-enables the watchdog after step 10. Lab success requires endpoint body hash <code>1FA6AAA3C28D8BD8</code>, target <code>2FA509C1</code>, hardware <code>RAK_3401</code>, normal radio <code>910.525 MHz / 62.5 kHz / SF7 / CR5</code>, and the watchdog verified on.</p>"},{"location":"rak3401_mota_chain/#external-radio-startup-and-manual-usb-recovery","title":"External-radio startup and manual USB recovery","text":"<p>RAK3401 is a distinct target from RAK4631. Its RAK13300/RAK13302 radio is on the WisBlock SPI bus (<code>SPI1</code> in the Adafruit nRF52 core), with BUSY and DIO1 on P0.09/P0.10. Current builds explicitly enable those NFC-capable pads as GPIO and do not advertise the radio bus as an on-board QSPI flash device.</p> <p>The RAK13302's FEM and boost supply use switched <code>3V3_S</code>, but the SX1262 core uses unswitched 3V3. An MCU reset, a 1200-baud DFU touch, or disconnecting only USB may therefore leave a battery-powered SX1262 in its previous state. At startup, current firmware quiesces the FEM, reinitializes the dedicated SPI instance, asserts NRESET, and, if BUSY remains high, sends the Semtech NSS/GET_STATUS wake sequence without waiting on RadioLib first. The one-time board startup cold-starts <code>3V3_S</code>; later radio retries leave that shared rail enabled so they do not reset GPS or sensor modules.</p> <p>If BUSY still cannot be released, firmware must not enter a reset loop:</p> <ul> <li>Companion starts its USB/BLE management services after three bounded probes,   uses nRF52 hardware entropy if it needs a first-boot identity, and retries the   radio every 60 seconds. Radio statistics remain zero until recovery.</li> <li>Repeater keeps the same USB CDC session open and prints   <code>Radio unavailable; retrying in 60 seconds</code>. It repeats the board-level probe   in place. The normal repeater CLI and mesh transport cannot start until the   radio responds.</li> </ul> <p>A permanently high BUSY after NRESET and the direct wake transaction indicates an electrically unavailable radio, loose module, or power-domain fault; an MCU reboot cannot manufacture a response. If local access is possible, disconnect the battery as well as USB and reseat the WisBlock module. Remote firmware will continue retrying without requiring that physical intervention or churning the USB device.</p> <p>For an existing deployed tower using Preview 5, do not change the bootloader as part of this application chain. Its exact local recovery package is the Preview 5 RAK4631 ZIP. For a new RAK3401 installation or local recovery, use the OTAFIX 2.4.3 RAK3401 ZIP from the OTAFIX 2.4.3 release. These are local DFU/SWD recovery assets, not mOTA chain steps.</p> <p>For a local Serial DFU recovery with the repository helper:</p> <pre><code>cd /path/to/meshfirmware\nMCFIRMWARE_NO_SUDO=1 ./mcfirmware.sh\n</code></pre> <p>Select the serial entry whose USB identity is <code>WisCore RAK3401 Board</code>, then choose Custom, nrf52, and the exact RAK3401 <code>.zip</code>. Use flash-update to preserve InternalFS preferences and identity. Use flash-wipe + flash only when erasing application data is intentional. The helper follows the same USB device into bootloader mode, so do not substitute another <code>/dev/ttyACM*</code> merely because its number appears first.</p>"},{"location":"spiffs_regular_file_reads/","title":"SPIFFS regular-file reads and login replay state","text":"<p>Arduino-ESP32 SPIFFS can return a truthy directory handle from a read-open of a nonexistent filename. <code>File::operator bool()</code> alone does not prove that a regular file exists. A directory's <code>size()</code> and <code>read()</code> are zero.</p> <p>The first privileged login on an upgraded G2 encountered this in <code>ClientACL::writeClientLoginReplayCeiling()</code>: opening the not-yet-created <code>/s_login_replay</code> appeared successful, then subtracting the eight-byte trailer from size zero underflowed. Copying the supposed records failed and login was rejected. Waiting or changing the repeater clock cannot fix that file-open bug.</p>"},{"location":"spiffs_regular_file_reads/#fix","title":"Fix","text":"<p>Use <code>mesh::openFileRead()</code> for regular-file reads. It checks existence and rejects directory handles, while preserving real empty files. Replay record counts also validate the minimum trailer size, record alignment, and maximum count before subtraction. An existing replay file that becomes unreadable is not treated as a new store.</p> <p>No replay records are cleared and authentication is not weakened. Invalid or unwritable replay state still fails closed. The first successful privileged login creates a 44-byte file: one 36-byte identity/ceiling record plus its eight-byte integrity trailer.</p> <p>Setting the repeater clock must not clear this file. Admission compares the sender's timestamp with that sender's saved boundary, not with the repeater's current time. Clearing the boundary could make captured requests reusable. A sender clock rollback is a separate condition and remains subject to the saved boundary after this fix.</p> <p>Companion directory enumeration uses the separate <code>openDirectory()</code> API, which deliberately permits SPIFFS virtual directories. Regular-file reads are also enforced for companion data, repeater/room logs, flood-rule verification, and HTTP packet-log downloads (missing logs return 404; real empty logs 200).</p>"},{"location":"spiffs_regular_file_reads/#audit-boundary","title":"Audit boundary","text":"<p>The audit covered file opens and size arithmetic in <code>src</code> and <code>examples</code>. Identity, region, clock, and common preference loaders already gate reads with filesystem existence checks; SPIFFS's <code>exists()</code> explicitly excludes directory handles. Relevant MQTT length subtraction follows validated headers and exact reads. ESP32 OTA staging uses partition APIs, not these SPIFFS file handles. Intentional directory enumeration must not be changed to a regular-file read.</p>"},{"location":"spiffs_regular_file_reads/#regression-checks","title":"Regression checks","text":"<ul> <li><code>test/test_client_acl_spiffs.py</code> compiles the actual <code>ClientACL.cpp</code> against   a filesystem that reproduces the misleading missing-file directory handle.   It covers first creation, fresh/stale login, reboot ceilings, corrupt and   unreadable state, short writes, failed publication, and truncated sources.</li> <li><code>test/test_regular_file_reads.py</code> executes production companion readers,   flood-file verification, and HTTP log delivery with the same filesystem   behavior, including platform-specific file API differences.</li> <li><code>test/test_esp32_tinyusb_cooperative_output.py</code> exercises both real role log   pumps, including missing logs and bounded output.</li> <li>Native ACL transaction, login persistence, and client-path persistence suites   retain the existing security and recovery coverage.</li> </ul> <p>The pre-fix actual ACL code was reproduced as <code>first_login=rejected</code>, one missing read-open, and no replay file. The fixed code accepted that identical scenario without a missing read-open and created the valid 44-byte record. Host simulations do not replace a post-flash LoRa login test on the G2.</p>"},{"location":"stats_binary_frames/","title":"Stats Binary Frame Structures","text":"<p>Binary frame structures for companion radio stats commands. All multi-byte integers use little-endian byte order.</p>"},{"location":"stats_binary_frames/#command-codes","title":"Command Codes","text":"Command Code Description <code>CMD_GET_STATS</code> 56 Get statistics (2-byte command: code + sub-type)"},{"location":"stats_binary_frames/#stats-sub-types","title":"Stats Sub-Types","text":"<p>The <code>CMD_GET_STATS</code> command uses a 2-byte frame structure: - Byte 0: <code>CMD_GET_STATS</code> (56) - Byte 1: Stats sub-type:   - <code>STATS_TYPE_CORE</code> (0) - Get core device statistics   - <code>STATS_TYPE_RADIO</code> (1) - Get radio statistics   - <code>STATS_TYPE_PACKETS</code> (2) - Get packet statistics</p>"},{"location":"stats_binary_frames/#response-codes","title":"Response Codes","text":"Response Code Description <code>RESP_CODE_STATS</code> 24 Statistics response (2-byte response: code + sub-type)"},{"location":"stats_binary_frames/#stats-response-sub-types","title":"Stats Response Sub-Types","text":"<p>The <code>RESP_CODE_STATS</code> response uses a 2-byte header structure: - Byte 0: <code>RESP_CODE_STATS</code> (24) - Byte 1: Stats sub-type (matches command sub-type):   - <code>STATS_TYPE_CORE</code> (0) - Core device statistics response   - <code>STATS_TYPE_RADIO</code> (1) - Radio statistics response   - <code>STATS_TYPE_PACKETS</code> (2) - Packet statistics response</p>"},{"location":"stats_binary_frames/#resp_code_stats-stats_type_core-24-0","title":"RESP_CODE_STATS + STATS_TYPE_CORE (24, 0)","text":"<p>Total Frame Size: 11 bytes</p> Offset Size Type Field Name Description Range/Notes 0 1 uint8_t response_code Always <code>0x18</code> (24) - 1 1 uint8_t stats_type Always <code>0x00</code> (STATS_TYPE_CORE) - 2 2 uint16_t battery_mv Battery voltage in millivolts 0 - 65,535 4 4 uint32_t uptime_secs Device uptime in seconds 0 - 4,294,967,295 8 2 uint16_t errors Error flags bitmask - 10 1 uint8_t queue_len Outbound packet queue length 0 - 255"},{"location":"stats_binary_frames/#example-structure-cc","title":"Example Structure (C/C++)","text":"<pre><code>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</code></pre>"},{"location":"stats_binary_frames/#resp_code_stats-stats_type_radio-24-1","title":"RESP_CODE_STATS + STATS_TYPE_RADIO (24, 1)","text":"<p>Total Frame Size: 14 bytes</p> Offset Size Type Field Name Description Range/Notes 0 1 uint8_t response_code Always <code>0x18</code> (24) - 1 1 uint8_t stats_type Always <code>0x01</code> (STATS_TYPE_RADIO) - 2 2 int16_t noise_floor Radio noise floor in dBm -140 to +10 4 1 int8_t last_rssi Last received signal strength in dBm -128 to +127 5 1 int8_t last_snr SNR scaled by 4 Divide by 4.0 for dB 6 4 uint32_t tx_air_secs Cumulative transmit airtime in seconds 0 - 4,294,967,295 10 4 uint32_t rx_air_secs Cumulative receive airtime in seconds 0 - 4,294,967,295"},{"location":"stats_binary_frames/#example-structure-cc_1","title":"Example Structure (C/C++)","text":"<pre><code>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</code></pre>"},{"location":"stats_binary_frames/#resp_code_stats-stats_type_packets-24-2","title":"RESP_CODE_STATS + STATS_TYPE_PACKETS (24, 2)","text":"<p>Total Frame Size: 26 bytes (legacy) or 30 bytes (includes <code>recv_errors</code>)</p> Offset Size Type Field Name Description Range/Notes 0 1 uint8_t response_code Always <code>0x18</code> (24) - 1 1 uint8_t stats_type Always <code>0x02</code> (STATS_TYPE_PACKETS) - 2 4 uint32_t recv Total packets received 0 - 4,294,967,295 6 4 uint32_t sent Total packets sent 0 - 4,294,967,295 10 4 uint32_t flood_tx Packets sent via flood routing 0 - 4,294,967,295 14 4 uint32_t direct_tx Packets sent via direct routing 0 - 4,294,967,295 18 4 uint32_t flood_rx Packets received via flood routing 0 - 4,294,967,295 22 4 uint32_t direct_rx Packets received via direct routing 0 - 4,294,967,295 26 4 uint32_t recv_errors Receive/CRC errors (RadioLib); present only in 30-byte frame 0 - 4,294,967,295"},{"location":"stats_binary_frames/#notes","title":"Notes","text":"<ul> <li>Counters are cumulative from boot and may wrap.</li> <li><code>recv = flood_rx + direct_rx</code></li> <li><code>sent = flood_tx + direct_tx</code></li> <li>Clients should accept frame length &gt;= 26; if length &gt;= 30, parse <code>recv_errors</code> at offset 26.</li> </ul>"},{"location":"stats_binary_frames/#example-structure-cc_2","title":"Example Structure (C/C++)","text":"<pre><code>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</code></pre>"},{"location":"stats_binary_frames/#command-usage-example-python","title":"Command Usage Example (Python)","text":"<pre><code># 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</code></pre>"},{"location":"stats_binary_frames/#response-parsing-example-python","title":"Response Parsing Example (Python)","text":"<pre><code>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('&lt;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('&lt;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) &gt;= 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('&lt;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) &gt;= 30:\n        (recv_errors,) = struct.unpack('&lt;I', frame[26:30])\n        result['recv_errors'] = recv_errors\n    return result\n</code></pre>"},{"location":"stats_binary_frames/#command-usage-example-javascripttypescript","title":"Command Usage Example (JavaScript/TypeScript)","text":"<pre><code>// 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</code></pre>"},{"location":"stats_binary_frames/#response-parsing-example-javascripttypescript","title":"Response Parsing Example (JavaScript/TypeScript)","text":"<pre><code>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 &lt; 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 &gt;= 30) {\n        result.recv_errors = view.getUint32(26, true);\n    }\n    return result;\n}\n</code></pre>"},{"location":"stats_binary_frames/#field-size-considerations","title":"Field Size Considerations","text":"<ul> <li>Packet counters (uint32_t): May wrap after extended high-traffic operation.</li> <li>Time fields (uint32_t): Max ~136 years.</li> <li>SNR (int8_t, scaled by 4): Range -32 to +31.75 dB, 0.25 dB precision.</li> </ul>"},{"location":"telemetry_decoder/","title":"Telemetry decoder","text":"<p>Paste raw hexadecimal packet data copied from the Let's Mesh packet analyzer to decode a repeater's scheduled temperature, battery-voltage, or external I2C-voltage snapshot. The decoder also accepts the payload hex without its MeshCore packet header and the Base64 pages returned by repeater or room-server CLI commands. Decoding happens entirely in this browser; pasted data is not uploaded or sent anywhere.</p> <p>The Source ID in a raw-packet result is the first eight bytes of the sending repeater's public key. Match that 16-character hex value against the public-key prefix recorded for your repeaters. It comes from the telemetry payload itself, so it is available even when only the payload was copied.</p>"},{"location":"telemetry_decoder/#send-raw-telemetry-packets","title":"Send raw telemetry packets","text":"<p>From an administrator CLI session, first configure a direct route to the MQTT observer that will receive and upload the raw packets. Use <code>direct</code> when the observer is a zero-hop neighbor:</p> <pre><code>set telemetry.tx direct\nsend telemetry.tx now\n</code></pre> <p>For a routed observer, provide its comma-separated hop hashes instead:</p> <pre><code>set telemetry.tx A1B2,C3D4\nsend telemetry.tx now\n</code></pre> <p>Configuring the route also enables the default two-day schedule. To keep the route but use it only for manual tests, turn off the schedule before sending:</p> <pre><code>set telemetry.tx schedule off\nsend telemetry.tx now\n</code></pre> <p>The <code>send telemetry.tx now</code> command queues one <code>TTB1</code> temperature packet, one <code>TVB1</code> battery-voltage packet, and <code>IVB1</code> chunks for every connected I2C voltage channel. <code>TTB1</code> and <code>TVB1</code> carry up to 165 samples. Each <code>IVB1</code> carries 64, so a full 192-point/four-day channel takes three packets. Channels whose retained history is entirely zero are treated as disconnected and are not sent. The command requires at least one collected base sample and works even when the automatic schedule is off.</p>"},{"location":"telemetry_decoder/#decode-a-packet","title":"Decode a packetDecoded telemetry","text":"Try an analyzer example: Temperature packet Voltage packet I2C voltage packet I2C voltage CLI page Raw packet or payload hex <p>     Spaces, line breaks, colons, dashes, a leading <code>0x</code>, and a quoted     JSON field are accepted. CLI Base64 replies are also auto-detected. Paste     multiple compatible packet or reply lines together to merge them by     timestamp before downloading one CSV. Press Ctrl/Command+Enter to decode.   </p> Decode telemetry Clear        Show browser-local time      Download CSV Decode notes"},{"location":"telemetry_decoder/#analyzer-hex-examples","title":"Analyzer hex examples","text":"<p>The buttons load synthetic, protocol-valid zero-hop RAW_CUSTOM packets. A real scheduled snapshot normally has 165 samples and is much longer. Routed packets also contain path bytes before the <code>TTB1</code> or <code>TVB1</code> payload magic; the decoder finds and validates the payload automatically.</p>"},{"location":"telemetry_decoder/#temperature","title":"Temperature","text":"<pre><code>3E00545442311122334455667788800092651E0008000102354A4E5082\n</code></pre>"},{"location":"telemetry_decoder/#battery-voltage","title":"Battery voltage","text":"<pre><code>3E00545642311122334455667788800092651E000800010264C8FEFFDC\n</code></pre>"},{"location":"telemetry_decoder/#external-i2c-voltage","title":"External I2C voltage","text":"<pre><code>3E00495642311122334455667788800092651E00020800000004019026927109C427107FFF\n</code></pre> <p>All three examples identify the source as <code>1122334455667788</code>.</p>"},{"location":"telemetry_decoder/#cli-history-pages","title":"CLI history pages","text":"<p>The same page continues to decode the padded Base64 returned by these administrator commands:</p> Data Newest page Older-page example Samples per page MCU temperature <code>get telemetry.temp</code> <code>get telemetry.temp 2</code> 48 (24 hours) Battery voltage <code>get telemetry.volt</code> <code>get telemetry.volt 3</code> 48 (24 hours) I2C voltage <code>get telemetry.volt.i2c 2</code> <code>get telemetry.volt.i2c 2 4</code> 48 (24 hours) GPS position <code>get telemetry.gps</code> <code>get telemetry.gps 2</code> 24 (12 hours) <p>Paste either the complete reply beginning with <code>&gt;</code> or Base64 alone. For example:</p> <pre><code>get telemetry.volt 1\n&gt; EkDUcWoeMAAB5+bl5eTj4uLh4ODf3t7d3Nvb2tnZ2NfX1tXU1NPS0tHQ0M/Ozc3My8vKycnI/w==\n</code></pre> <p>Run <code>get telemetry.volt.i2c</code> without a channel first to list connected channels. For each channel, collect pages <code>1</code> through <code>4</code>. Paste all four reply lines into the decoder at once; it merges their timestamps into one 192-point, four-day table and downloads them as one CSV. The same merging works for the three <code>IVB1</code> analyzer packets from a full channel. Inputs must have the same telemetry type, source, LPP channel, and sample interval.</p> <p>An INA3221 exposes its three enabled hardware inputs as three consecutive LPP channels. When it is the only external sensor these are normally <code>2</code>, <code>3</code>, and <code>4</code>, in hardware-input order. Other sensors can shift the numbers, so copy the IDs reported by <code>get telemetry.volt.i2c</code> rather than assuming them.</p>"},{"location":"telemetry_decoder/#reading-the-table","title":"Reading the table","text":"<ul> <li>Timestamps default to UTC. Select Show browser-local time to convert   them for display and CSV export.</li> <li><code>TTB1</code> means a raw temperature snapshot, <code>TVB1</code> a raw battery-voltage   snapshot, and <code>IVB1</code> a packed external I2C-voltage chunk. The input summary   also reports the MeshCore route and path-hop count when a complete packet was   pasted.</li> <li>Temperature preserves exact whole degrees from <code>-50 C</code> through <code>+77 C</code>, plus   missing, below-range, and above-range states.</li> <li>Voltage preserves hundredths of a volt from <code>1.88 V</code> through <code>4.40 V</code>, plus   missing and out-of-range states.</li> <li>External I2C voltage uses a 15-bit code at <code>0.02 V</code> resolution. Code <code>0</code> is   missing/disconnected; codes <code>1</code> through <code>32767</code> cover <code>0.02 V</code> through   <code>655.34 V</code>. The LPP channel remains part of every page and raw chunk so   multiple monitor inputs cannot be mixed accidentally.</li> <li>GPS positions are reconstructed from signed 10-meter differentials. A zero   differential after the page origin is inherently ambiguous: it can represent   an unchanged fix, movement below the encoded resolution, or no fix. The table   labels those rows rather than inventing a coordinate.</li> <li>A GPS clipping warning means at least one movement exceeded the differential   range, so positions after that point can be less accurate.</li> </ul> <p>GPS history remains available through the administrator CLI, but <code>telemetry.tx</code> never puts GPS in RAW_CUSTOM packets. Location data therefore must come from a CLI Base64 page rather than analyzer hex.</p> <p>For the byte-level layouts, see Read repeater telemetry history.</p>"},{"location":"terminal_chat_cli/","title":"Terminal Chat CLI","text":"<p>Below are the commands you can enter into the Terminal Chat clients:</p>"},{"location":"terminal_chat_cli/#companion-usb-mode","title":"Companion USB mode","text":"<p>An ordinary Companion USB build starts in the normal binary Companion protocol at 115200 baud. Use this command to switch the same USB connection into terminal mode as soon as <code>picocom</code> opens it:</p> <pre><code>picocom --baud 115200 \\\n  --imap spchex \\\n  --initstring $'+++MESHCORE-TERM-START\\r' \\\n  /dev/ttyACM0\n</code></pre> <p><code>--initstring</code> sends this exact terminal-start line automatically:</p> <pre><code>+++MESHCORE-TERM-START\n</code></pre> <p>The carriage return is required in Binary mode. Control tokens are recognized only as complete CR/LF-delimited lines, so the same text embedded in unrelated unframed input cannot switch modes accidentally.</p> <p>Binary Companion frames can contain terminal control bytes. The <code>spchex</code> input map renders those bytes as bracketed hexadecimal during the short transition instead of allowing them to change the local terminal's character set or display state. It leaves high-bit bytes unchanged so a UTF-8 terminal displays emoji and non-ASCII text normally. Do not add <code>8bithex</code> unless you explicitly want UTF-8 bytes displayed as sequences such as <code>[f0][9f][91][8b]</code>. Once the terminal banner appears, the start sequence has already succeeded; do not enter it again as a terminal command.</p> <p>Send the following exact sequence to return to the binary protocol:</p> <pre><code>+++MESHCORE-TERM-STOP\n</code></pre> <p>Closing the serial connection also returns native-USB devices to binary mode. Boards whose USB connector is implemented by a USB-to-UART bridge cannot observe the host closing the port; on those boards, use the stop sequence or reboot the device.</p> <p>Both modes use the same port at 115200. Selecting 57600 is not a portable mode switch: native USB CDC devices ignore the requested baud, while USB-to-UART devices really change the UART timing and receive corrupt data. Binary mode is the framed Companion API used by apps and <code>meshcli</code>; close the terminal before opening that port from an app.</p> <p>Full Companion differs: its primary USB interface starts in ASCII after boot and automatically switches when it sees a complete <code>&lt;</code>-prefixed Companion frame at an empty prompt. The explicit start/stop tokens remain available. See Full Companion USB CLI and binary switcher for the state machine and limitations.</p>"},{"location":"terminal_chat_cli/#commands","title":"Commands","text":"<pre><code>set freq {frequency}\n</code></pre> <p>Set the LoRa frequency. Example:  set freq 915.8</p> <pre><code>set tx {tx-power-dbm}\n</code></pre> <p>Sets LoRa-chip transmit power in dBm. The firmware rejects values outside the radio/board limit; external-PA boards can have a lower input-power ceiling than the radio chip itself.</p> <pre><code>set name {name}\n</code></pre> <p>Sets your advertisement name.</p> <pre><code>get bluetooth.name\nset bluetooth.name {name|default}\n</code></pre> <p>Shows or changes the complete Bluetooth device name without changing the mesh advertisement identity. A custom name may contain spaces and is limited to 31 valid UTF-8 bytes. <code>default</code> restores <code>MeshCore-&lt;node name&gt;</code>. The saved change takes effect after reboot. <code>get ble.name</code> and <code>set ble.name</code> are short aliases.</p> <pre><code>set lat {latitude}\n</code></pre> <p>Sets your advertisement map latitude. (decimal degrees)</p> <pre><code>set lon {longitude}\n</code></pre> <p>Sets your advertisement map longitude. (decimal degrees)</p> <pre><code>set dutycycle {percent}\n</code></pre> <p>Sets the transmit duty cycle limit (1-100%). Example: <code>set dutycycle 10</code> for 10%.</p> <pre><code>set af {air-time-factor}\n</code></pre> <p>Sets the transmit air-time-factor. Deprecated - use <code>set dutycycle</code> instead.</p> <pre><code>powersaving\npowersaving {on|off}\nset powersaving {on|off}\n</code></pre> <p>Shows or changes Companion device power saving. On ESP32 this controls CPU and GPS idle behavior; it does not change LoRa RXPS or WiFi modem sleep.</p> <pre><code>get usb.logging\nset usb.logging {on|off} [reboot]\n</code></pre> <p>Shows or changes persistent live USB debug and packet output in an ordinary USB-loggable Companion or Full Companion. USB Companion and Full start off on a fresh install with logging disabled to protect framed traffic. nRF52 Full changes its interface count after a reboot and keeps Companion on interface <code>00</code>. Every ESP32 Full Companion has one TTY and needs no reboot: logging uses the active text terminal, disables framed Binary Companion on USB, and continues accepting <code>set usb.logging off</code>. Turning logging off leaves the port in the normal ASCII terminal, matching fresh firmware. Send <code>+++MESHCORE-TERM-STOP</code>, or let a Companion app send a valid framed probe, to switch it to Binary Companion afterward.</p> <pre><code>reboot\n</code></pre> <p>Sends an acknowledgement, then reboots the Companion one second later. The delay gives either the USB terminal or the Full Companion TCP terminal on port 5002 time to deliver the reply before its transport disappears.</p> <pre><code>get radio.rxps\nget radio.rxps.config\nset radio.rxps {off|on|level 1-10 [preamble 16|32]|rx_us sleep_us}\n</code></pre> <p>Shows or changes LoRa receive duty cycling on supported radios. <code>get radio.rxps.config</code> also reports the saved level and preamble assumption so automation can restore a level-based preference exactly. Fresh Cascade builds select level 8 with a 16-symbol timing assumption. The <code>preamble</code> argument controls the RXPS calculation; it does not change the physical wire preamble. A configured level is the minimum: when faster SF/BW settings shorten the timing window, firmware raises the effective level only as far as needed, up to level 10. Starting with v1.17.1.5, SF5-SF8 packets normally use a 32-symbol physical preamble. Firmware selects 64, then 128, only when every shorter choice fails to enable RXPS at any level. The configured values remain unchanged, so every radio change recalculates from the saved minimum. A slower tuple returns to that exact level and the shortest viable wire preamble.</p> <p>If neither adjustment leaves enough time for the radio to wake, RXPS stays logically enabled but receives continuously instead of rejecting the radio setting or starting an invalid duty cycle. The Companion terminal's <code>get radio.rxps</code> reports this as <code>mode=continuous-fast</code> and reports any <code>effective-level</code> or <code>effective-preamble</code> adjustment; <code>get radio.rxps.config</code> reports the persisted preference. A later compatible SF/BW change resumes duty cycling without another RXPS command.</p> <p>For the SX1262+TCXO boards tested here, these fast combinations are the useful RXPS boundary profiles (CR does not change the RXPS preamble timing):</p> SF BW (kHz) Wire preamble Effective preamble Minimum effective level RX / sleep 7 500 32 32 7 2731 / 6101 us 6 250 32 32 7 2731 / 6101 us 5 125 32 32 7 2731 / 6101 us 5 250 64 64 8 1252 / 6424 us 6 500 64 64 8 1252 / 6424 us 5 500 128 128 8 626 / 6398 us 5 62.5 32 16 10 4096 / 6272 us <p>The 64- and 128-symbol rows require the v1.17.1.5-or-newer adaptive-preamble contract on every sender that may reach the RXPS receiver. Cascade/USA builds on a Heltec V4 and WisMesh Tag (RAK4631 target) passed 16/16 packets in each direction at both SF5/BW250/64 and SF5/BW500/128, CR5, 909.950 MHz. An older sender makes a long-preamble timing window unsafe, so use continuous RX for a mixed deployment. Retry packets use the same physical preamble as other packets.</p> <pre><code>get wifi.powersave\nset wifi.powersave {none|min|max}\n</code></pre> <p>Shows or changes the persisted WiFi modem-sleep policy on ESP32 WiFi Companion builds. Full Companion requires at least <code>min</code> while BLE is present and rejects <code>none</code>. The WebConfig WiFi card and the normal binary Companion protocol expose the same setting; binary clients do not need the terminal-start token. On an ESP32 Full Companion whose primary mesh radio is ESP-NOW, <code>max</code> is also unavailable because maximum modem sleep can make the station miss ESP-NOW broadcasts, which the access point does not buffer. A previously saved <code>max</code> value is capped to and reported as <code>min</code>, and a new <code>max</code> selection is rejected. Such a WiFi/BLE/primary-ESP-NOW build therefore uses <code>min</code>.</p> <pre><code>get espnow.channel\nset espnow.channel &lt;1-13&gt;\n</code></pre> <p>On builds whose primary mesh radio is ESP-NOW, this shows or saves the primary radio's channel. The default is channel 1. Use only a channel permitted in your region, and restart or power-cycle the node after changing it. Every primary ESP-NOW peer must use the same channel.</p> <p>On Full Companion, the setup AP and infrastructure-WiFi station also share that channel, so the router's 2.4 GHz radio must remain fixed to it. Power saving does not permit separate channels. <code>wifi.powersave max</code> is unavailable on these ESP32 Full builds and <code>min</code> is the coexistence setting. This channel setting is also distinct from <code>bridge.channel</code>, which controls the optional ESP-NOW bridge transport. An updated LoRa-primary ESP-NOW bridge can join this raw primary transport by selecting the same channel and running <code>set bridge.format raw</code>; its default <code>wrapped</code> format remains the bridge-to-bridge protocol.</p> <pre><code>get radio.rxgain\nset radio.rxgain {on|off}\nget radio.fem.rxgain\nset radio.fem.rxgain {on|off}\nget radio.fem.txgain\nset radio.fem.txgain {on|off}\n</code></pre> <p><code>radio.rxgain</code> changes the radio chip's boosted receive-gain mode. The FEM settings control the external receive-path LNA or transmit-path gain on supported boards. Changes are applied immediately and saved across reboots; changing either receive-gain path also recalibrates the radio noise floor. Boards without the respective control report it as unsupported.</p> <pre><code>time {epoch-secs}\n</code></pre> <p>Set the device clock using UNIX epoch seconds. Example:  time 1738242833</p> <pre><code>advert\n</code></pre> <p>Sends an advertisement packet</p> <pre><code>clock\n</code></pre> <p>Displays current time per device's clock.</p> <pre><code>ver\n</code></pre> <p>Shows the device version and firmware build date.</p> <pre><code>card\n</code></pre> <p>Displays your 'business card', for others to manually import</p> <pre><code>import {card}\n</code></pre> <p>Imports the given card to your contacts.</p> <pre><code>list {n}\n</code></pre> <p>Lists favorite contacts first, then all remaining contacts. Each group is ordered by the most recent advertisement. Optional <code>{n}</code> limits the displayed contacts after applying that order.</p> <pre><code>show\nshow adverts {on|off}\nshow channels {on|off}\nshow emergency {on|off}\n</code></pre> <p>Controls unsolicited receive output in the USB terminal. Plain <code>show</code> reports the current settings, and <code>show {category}</code> reports one category. At boot, advertisements and ordinary channel messages are hidden while <code>#emergency</code> messages are shown. The three controls are independent, so <code>show channels on</code> does not override <code>show emergency off</code>.</p> <p>These filters affect terminal printing only. Messages still enter the offline queue and are delivered through the binary Companion protocol. Changes remain active when switching between terminal and binary mode and reset to their defaults after reboot.</p> <pre><code>to\n</code></pre> <p>Shows the name of current recipient contact. (for subsequent 'send' commands)</p> <pre><code>to {name-prefix}\n</code></pre> <p>Sets the recipient to the first matching contact (in 'list') by the name prefix. (ie. you don't have to type whole name)</p> <pre><code>path\n</code></pre> <p>Shows the saved outgoing path for the current <code>to</code> recipient. This command and all path changes require a recipient to be selected first.</p> <pre><code>path direct\npath clear\npath {hop-hash...}\n</code></pre> <p>Sets the outgoing path used by subsequent <code>login</code>, <code>send</code>, and <code>cmd</code> commands. <code>direct</code> selects a zero-hop route. <code>clear</code> forgets the saved route, causing the next operation to use flood routing and allowing normal path discovery to learn a replacement.</p> <p>Explicit paths use spaces, commas, or a mixture of both between hop hashes. Each hop must contain exactly 2, 4, or 6 hexadecimal digits, and every hop in one path must use the same width. Whitespace and hexadecimal letter case do not matter. The setting is saved with the selected contact.</p> <p>For example:</p> <pre><code>to Hilltop Repeater\npath A1B2C3,D4E5F6\npath 7773D0 7E7662\npath\nlogin my-admin-password\n</code></pre> <pre><code>login {admin-password}\n</code></pre> <p>Sends a remote login request to the current recipient. Select a repeater, room, or other remotely managed node with <code>to {name-prefix}</code> first. The password is masked with <code>*</code> while it is entered and must be 1-15 UTF-8 bytes; longer passwords are rejected instead of truncated. Login uses the route shown by <code>path</code>: a known or explicitly set route is direct, while an unknown route is flooded.</p> <p>Login results arrive asynchronously. A successful modern response displays the remote ACL permissions byte and server protocol level. A wrong password, an unreachable target, or a server that does not support remote login normally produces a timeout because those nodes do not send a rejection packet.</p> <pre><code>cmd {remote-command}\n</code></pre> <p>Sends CLI data to the current recipient. Wait for the login result before sending the first command. The remote node applies its own ACL permissions, and any reply appears asynchronously as <code>CLI -&gt; from {name}</code>. The response window is 300% of the route estimate. A routed send is displayed as <code>DIRECT via path {hop,...}</code> with the exact prefixes copied into the packet; in MeshCore, <code>DIRECT</code> is the route class for an explicit path, not a synonym for zero hops. A matched reply also shows its local round-trip time, measured from queueing the command through receiving the result. This includes both radio directions and remote execution; it is not execution-only CPU time. Only one terminal <code>cmd</code> can be pending at a time.</p> <p>For example:</p> <pre><code>to Hilltop Repeater\nlogin my-admin-password\nLOGIN -&gt; Hilltop Repeater accepted (ACL permissions 0x03, server v13)\ncmd ver\ncmd get radio\n</code></pre> <p>The exact commands and permissions depend on the target firmware. <code>cmd</code> does not run a command on the local Companion; it sends the text over LoRa to the selected node.</p> <p>Incoming direct-route messages are labeled <code>ROUTED</code>, not <code>DIRECT</code>. Forwarders consume direct-route prefixes as the packet travels, so the destination cannot recover the reply's actual hop history from the received packet. Use <code>trace</code> when the return route itself must be verified.</p> <pre><code>send {text}\n</code></pre> <p>Sends the text message (as DM) to current recipient.</p> <pre><code>trace\n</code></pre> <p>Traces the saved round-trip route to the current recipient and displays the SNR at each hop. Select the recipient first with <code>to {name-prefix}</code>.</p> <pre><code>trace {name-prefix}\n</code></pre> <p>Traces a recipient directly without changing the current <code>to</code> selection. A trace requires a known direct path; use normal messaging or path discovery first if the terminal reports that no valid path is available. Only one terminal trace can be pending at a time, and a missing response is reported as a timeout.</p> <p>For example:</p> <pre><code>to Hilltop Repeater\ntrace\ntrace Downtown\n</code></pre> <p>The displayed route uses one- or two-byte node hashes and per-hop SNR values. Saved three-byte paths are traced with two-byte prefixes because the trace packet format has no three-byte hash-size mode.</p> <p>To trace an explicit route instead of a saved contact path, provide the prefix size followed by the complete ordered route:</p> <pre><code>trace path 1 12 34 56 34 12\ntrace path 2 1234,ABCD,5678,ABCD,1234\ntrace path 4 12345678, ABCDEF01 89ABCDEF, ABCDEF01,12345678\n</code></pre> <p>Prefix separators may be spaces, commas, or any mixture of them. Each prefix must contain exactly 2, 4, or 8 hexadecimal digits for a 1-, 2-, or 4-byte trace respectively. Three-byte traces are not supported.</p> <p>The prefixes are used exactly in the order entered. To receive the trace result, enter the complete outward route followed by its return route, as in the mirrored examples above. A route that does not return to this node will eventually report a timeout.</p> <pre><code>reset path\n</code></pre> <p>Resets the path to current recipient, for new path discovery. This is retained as an alias for <code>path clear</code>.</p> <pre><code>public {text}\n</code></pre> <p>Sends the text message to the built-in <code>Public</code> group channel.</p> <pre><code>channels\n</code></pre> <p>Lists the configured channel slots and names without exposing their secrets.</p> <pre><code>channel {name-or-slot} {text}\n</code></pre> <p>Sends a message to any configured channel by its exact name or numeric slot. Use the slot shown by <code>channels</code> when a channel name contains spaces.</p> <p>For example:</p> <pre><code>channels\nchannel #rgdata Hello from Eugene\nchannel 2 Another message\nshow channels on\n</code></pre> <p>Messages are UTF-8. Emoji use multiple bytes toward the available message length, which also includes the sender-name prefix added over the air.</p>"},{"location":"usb_serial_backpressure/","title":"Native USB backpressure and radio liveness","text":"<p>ESP32-S2/S3 builds using native TinyUSB CDC (<code>ARDUINO_USB_MODE=0</code> and CDC-on-boot) must not wait for a computer to read USB output. In the bundled Arduino-ESP32 2.0.17 core, <code>USBCDC::write()</code> can wait indefinitely for transmit space; its configured timeout bounds a mutex, not that wait. This can stop the same loop that services LoRa, even while the USB connection still appears open.</p>"},{"location":"usb_serial_backpressure/#firmware-behavior","title":"Firmware behavior","text":"<ul> <li>Native CDC output uses a single FIFO attempt, not Arduino's wait-for-space   write or flush. TinyUSB's internal short mutex operations still apply; this   is a no-host-progress-wait guarantee, not a lock-free driver replacement.</li> <li>Functional text and diagnostics share one ordered 4 KiB queue. Diagnostics   leave 3 KiB reserved for commands. A diagnostic backlog alone does not prevent   command input. A stalled host may lose diagnostic records; radio work continues.</li> <li>A connected terminal that exceeds its bounded output capacity gets an explicit   dropped-byte notice when transmission resumes. Large local file dumps and   recent-repeater listings advance between radio service passes instead.</li> <li>File dumps stop at their initial file size and emit <code>-&gt; EOF</code> only after the   final accepted record. Corrupt stored lines exceeding 640 bytes are omitted   with a visible notice. Recent-repeater output is a live, bounded-cursor view;   incoming packets can change its ordering while it is being printed.</li> <li>Disconnects discard pending old-session text and reset the role's partial   command/listing state. Binary/mOTA transitions suppress pending text notices.   Bytes already transmitted cannot be recalled.</li> <li>Companion frames retain and retry short writes. An mOTA request is admitted   only when its complete, at-most-11-byte record fits.</li> <li>nRF52, UART, and USB-Serial-JTAG behavior is not changed by this native-CDC path.</li> </ul> <p>Host software must also keep reading independently of command writes. A serial relay should start its reader before the first command, use finite write and response deadlines, avoid discarding received packet logs, and cancel I/O during shutdown. A response timeout must not allow a late reply to satisfy another command: the CLI has no transaction identifiers. Updating firmware alone does not correct an indefinite host-side serial write.</p>"},{"location":"usb_serial_backpressure/#regression-checks","title":"Regression checks","text":"<p>Run only one PlatformIO process in the checkout at a time.</p> <pre><code>python test/test_esp32_tinyusb_nonblocking.py\npython test/test_esp32_tinyusb_role_hygiene.py\npython test/test_esp32_tinyusb_cooperative_output.py\npython test/test_esp32_usb_serial_hygiene.py\npython test/test_nrf52_usb_logging_contract.py\npio test -e native -f test_nrf52_debug_output -f test_serial_packet_log -f test_serial_mode_switch -f test_mesh_tables\n</code></pre> <p>The first test compiles the real USB facade against a simulated 64-byte FIFO, including stopped readers, reconnects, protocol transitions, and other-platform fallbacks. Host simulations cannot establish that every real USB driver or endpoint failure has recovered.</p> <p>A Full Station G2 validation build with USA Cascadia radio settings and the Cascade profile can be made using the normal build entry point. The portable <code>standard</code> recipe preserves the deployed partition layout but omits LoRa OTA; it still has the browser firmware uploader. The <code>auto</code>/<code>full</code> recipe instead enables the expanded feature set and partition layout: its merged image is not an app-only update for a device with the legacy layout.</p> <pre><code>MESHDEBUG_OVERRIDE=on PACKET_LOGGING_OVERRIDE=on \\\n  bash build.sh build-firmware Station_G2_repeater --build-profile full \\\n  --radio-preset usa-cascadia --profile cascade\n</code></pre> <p>Before installing on hardware, preserve the device identity, preferences, and existing partition layout. Then verify USB command responses and repeated LoRa logins with the relay running, paused, and stopped, including a host that leaves USB open without reading. Check LoRa recovery separately from USB OUT recovery; fixing transmit backpressure does not prove an unrelated OUT endpoint fault is resolved. Do not erase or repartition the radio as part of this test.</p>"}]}
\ No newline at end of file
+{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"],"fields":{"title":{"boost":1000.0},"text":{"boost":1.0},"tags":{"boost":1000000.0}}},"docs":[{"location":"","title":"Introduction","text":"<p>Welcome to the MeshCore documentation.</p> <p>Below are a few quick start guides.</p> <ul> <li>Frequently Asked Questions</li> <li>Firmware Picker</li> <li>CLI Commands</li> <li>LoRa CLI Host Service</li> <li>Filter Policy Playground</li> <li>Telemetry Decoder</li> <li>CLI Availability by Firmware Build</li> <li>Easy LoRa OTA: ESP32 and nRF52 firmware updates</li> <li>Scripted LoRa OTA: Bash and PowerShell</li> <li>nRF52 repeater OTA with external QSPI</li> <li>nRF52 bootloader updates over LoRa</li> <li>MeshTower V2 microSD self-updates</li> <li>GPS Tracking</li> <li>Companion Protocol</li> <li>Companion Offline Message Queue</li> <li>Full Companion: ESP32 and nRF52</li> <li>Full Companion USB CLI and binary switcher</li> <li>Packet Format</li> <li>QR Codes</li> </ul> <p>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.</p> <ul> <li>Documentation Source</li> </ul>"},{"location":"WiFi/","title":"WiFi and MQTT by Firmware Type","text":"<p>MeshCore itself does not require WiFi or the internet. LoRa packet exchange, repeating, room servers, companions, and sensors can all operate without either. WiFi is added by particular ESP32 firmware targets for one or more of these purposes:</p> <ul> <li>a TCP connection between a WiFi companion and a phone or computer;</li> <li>the WebConfig browser interface;</li> <li>MQTT uplinking from the radio to internet or LAN brokers;</li> <li>WiFi-assisted OTA services on builds that include them;</li> <li>ESP-NOW bridging, which uses the ESP32's 2.4 GHz radio but is not a connection   to a WiFi access point.</li> </ul> <p>The firmware role and the build profile are separate choices. For example, a logging repeater is not an MQTT observer, and a WiFi companion does not publish to MQTT unless its target name also contains <code>mqtt</code>.</p>"},{"location":"WiFi/#quick-reference","title":"Quick reference","text":"Firmware target or role Infrastructure WiFi MQTT What WiFi does <code>*_repeater</code> Build-dependent on ESP32 No FULL builds provide WebConfig, browser OTA, and the TCP 5001 LoRa-OTA seeder while WiFi is active <code>*_repeater_observer_mqtt</code> Yes Yes Uplinks heard and selected transmitted LoRa packets; repeating remains enabled by default <code>*_room_server</code> Build-dependent on ESP32 No FULL builds provide WebConfig, browser OTA, and the TCP 5001 LoRa-OTA seeder while WiFi is active <code>*_room_server_observer_mqtt</code> Yes Yes Runs the room server and uplinks radio traffic <code>*_companion_radio_wifi</code> Yes No Exposes the MeshCore companion protocol on TCP port 5000 <code>*_companion_radio_wifi_mqtt</code> Yes Yes Runs both the TCP companion interface and the MQTT uplink USB, BLE, or serial companion No No Uses the transport named by the target instead <code>*_repeater_bridge_espnow</code> Build-dependent on ESP32 No Uses ESP-NOW for its bridge; <code>bridge.format wrapped|raw</code> selects legacy bridge framing or primary-ESP-NOW compatibility; a FULL build also exposes the TCP 5001 LoRa-OTA seeder whenever WiFi is usable RS232 bridge No No Bridges through a serial interface Ethernet repeater/room server No WiFi No Uses wired Ethernet for its role-specific network interface <code>*_sensor</code> Build-dependent on ESP32 No A FULL ESP32 sensor can expose the TCP 5001 LoRa-OTA seeder through its browser-OTA setup AP Terminal-chat or KISS modem No in current targets No Uses LoRa and its role-specific local interface <code>*_lora_ota_no_external_sensors</code> On demand on ESP32 No Lean LoRa-OTA repeater image; ESP32 builds retain the compact <code>start ota</code> browser uploader <p>Direct on-device WiFi and MQTT are currently ESP32 features. nRF52, STM32, and the currently enabled RP2040 targets do not run this MQTT bridge. An nRF52 connected to a Raspberry Pi can still be logged or uplinked by software on the Pi, but that is a separate host-side bridge rather than MQTT running in the radio firmware.</p>"},{"location":"WiFi/#how-the-mqtt-bridge-works","title":"How the MQTT bridge works","text":"<p>The MQTT bridge is an outbound observer. It does not subscribe to MQTT topics and does not inject broker messages into LoRa.</p> <p>For a received packet, the flow is:</p> <pre><code>LoRa radio -&gt; successful packet parse -&gt; MQTT capture queue -&gt; broker slots\n                                  \\----&gt; normal MeshCore filtering/handling\n</code></pre> <p>Packets transmitted by the node can also be queued according to <code>mqtt.tx</code>. Receive capture happens before the packet is passed to the normal MeshCore flood filters and forwarding decision. A packet may therefore be observed on MQTT even when a later scope, path, region, duplicate, or repeat rule prevents the node from forwarding it over LoRa.</p> <p>MQTT publication and LoRa repetition are separate:</p> <ul> <li><code>set repeat on|off</code> controls whether an observer repeats eligible LoRa   packets;</li> <li><code>set bridge.enabled on|off</code> starts or stops the MQTT bridge;</li> <li><code>set mqtt.rx on|off</code> controls uplinking of received packets;</li> <li><code>set mqtt.tx off|advert|on</code> controls uplinking of transmitted packets.</li> </ul> <p>Fresh MQTT observer settings are:</p> <ul> <li>bridge and repeating enabled;</li> <li>received packet uplinking enabled;</li> <li>transmitted packet uplinking set to <code>advert</code>, meaning only the node's own   adverts are included;</li> <li>packet and status publishing enabled;</li> <li>raw publishing disabled;</li> <li>slot 1 set to <code>analyzer-us</code>;</li> <li>slot 2 set to <code>analyzer-eu</code>;</li> <li>slots 3 through 6 disabled;</li> <li>WiFi modem power saving set to <code>min</code> in the Cascade profile and <code>none</code> in   target-default builds;</li> <li>WiFi SSID and IATA code empty.</li> </ul> <p>Up to six broker configurations can be saved. The number that can be active at once depends on the target and available memory. A non-PSRAM ESP32 should normally use no more than two TLS/WSS brokers; some classic ESP32 targets are reliable with only one. Excess configured slots remain saved but show as inactive in <code>get mqtt.status</code>.</p> <p>The bridge has a bounded packet queue for broker or WiFi outages and reconnects automatically. A non-PSRAM build holds 6 packets and a PSRAM build holds 50. When the queue is full, the oldest item is replaced; after five minutes with no broker connected, stale queued packets are flushed. MQTT packet delivery is best effort rather than durable storage. Each enabled slot publishes independently, so one failed broker does not intentionally stop the other slots.</p> <p>See MQTT_IMPLEMENTATION.md for the complete preset list, custom broker configuration, topic formats, authentication, diagnostics, and memory limits.</p>"},{"location":"WiFi/#mqtt-observer-setup","title":"MQTT observer setup","text":"<p>Most full-size ESP32 MQTT observer builds have the shared WebConfig portal. On a fresh device with no saved SSID:</p> <ol> <li>Join the open <code>MeshCore-Setup-XXXX</code> access point.</li> <li>If the captive page does not open, browse to <code>http://192.168.4.1/</code>.</li> <li>Enter WiFi, radio, identity, and MQTT settings.</li> <li>Select Save &amp; Reboot.</li> <li>After reboot, check <code>get wifi.status</code> and <code>get mqtt.status</code>.</li> </ol> <p>The setup AP is unauthenticated unless the firmware was built with <code>WEBCONFIG_AP_PASSWORD</code>. It uses plain HTTP, so provision it in a trusted location. When WebConfig is running on the normal LAN, repeater and room-server builds require the node's admin password.</p> <p>On an expanded FULL profile with no saved SSID, this automatic setup AP has an absolute 30-minute window. Browser activity or a phone left associated with the AP does not extend it. If no SSID has been saved when the window expires, WebConfig closes and the ESP32 WiFi radio remains off automatically for the remainder of that boot. A reboot or power cycle starts a new 30-minute setup window; the timeout is deliberately not written to preferences. An administrator can still override the automatic cutoff with an explicit <code>start webconfig</code> command.</p> <p>Once an SSID is saved, the provisioning cutoff no longer applies. When WiFi is selected by <code>logging.output wifi|both</code>, the station stays enabled and keeps trying the saved network indefinitely: ESP automatic reconnect remains on and the explicit fallback advances through 15, 30, 60, 120, then 300-second retry intervals, remaining at five minutes until it reconnects. MQTT broker retries use their own backoff; a repeatedly failing broker eventually receives one probe every 30 minutes. Selecting <code>logging.output off|usb</code> keeps the MQTT bridge off, so saved credentials alone do not force WiFi on unless WebConfig is also enabled explicitly.</p> <p>The equivalent MQTT observer CLI setup is:</p> <pre><code>set wifi.ssid Your WiFi Name\nset wifi.pwd Your WiFi Password\nset mqtt.iata SEA\nset name MyObserver\nreboot\n</code></pre> <p>The SSID and password values are the rest of the command line. Spaces are allowed and quotes must not be added. SSIDs may contain at most 31 characters and passwords at most 63. Leave the password value empty for an open network.</p> <p>Useful checks are:</p> <pre><code>get wifi.ssid\nget wifi.status\nget wifi.powersave\nget wifi.cli\nget bridge.enabled\nget mqtt.rx\nget mqtt.tx\nget mqtt.status\nget mqtt1.diag\nget mqtt2.diag\n</code></pre> <p>To change a configured observer through WebConfig without leaving the portal enabled after every reboot:</p> <pre><code>start webconfig\n</code></pre> <p>This uses the LAN when WiFi is connected. To force the setup AP, the MQTT bridge must release WiFi first:</p> <pre><code>set bridge.enabled off\nstart webconfig ap\n</code></pre> <p>After provisioning, use Save &amp; Reboot, or stop the temporary portal and restart the bridge:</p> <pre><code>stop webconfig\nset bridge.enabled on\n</code></pre> <p>Current MQTT observer artifacts use the expanded FULL partition profile so WebConfig and the complete role CLI are retained. Install the matching merged image over USB once when moving a device from the legacy partition layout.</p>"},{"location":"WiFi/#wifi-companion-setup","title":"WiFi companion setup","text":"<p>A <code>*_companion_radio_wifi</code> build replaces the BLE or USB companion link with the MeshCore companion protocol over TCP port 5000. The phone or computer must be able to reach the device on the same LAN.</p> <p>Most ESP32 <code>*_companion_radio_full</code> targets keep all three Companion links at once: USB, BLE, and TCP port 5000. The two SenseCAP Indicator Full targets are the exception: USB remains available, while a saved next-boot selector starts exactly one secondary wireless Companion transport, either BLE or infrastructure WiFi/TCP. On the ESP-NOW Indicator, this selector never stops the primary ESP-NOW mesh radio. Full ESP32 images also provide a source-only LoRa mOTA service on ports 5001 and 5002 whenever their WiFi transport is active. See the full Companion guide for its build, terminal mode, and complete update-source workflow.</p> <p>The LilyGo T-Beam 1W Full Companion maps one press of the physical <code>BOOT</code> button (GPIO0) to a persistent WiFi on/off toggle. Turning WiFi off closes WebConfig, Companion TCP, mOTA, and MQTT network services while USB, BLE, the display, GPS, and LoRa remain available. Another BOOT press turns WiFi back on even after reboot. WiFi/WebConfig starts first; BLE starts two seconds later so the ESP32-S3 can reserve the setup server's internal heap before both radios run together.</p> <p>The companion loads runtime credentials saved in NVS. A non-placeholder compile-time <code>WIFI_SSID</code>/<code>WIFI_PWD</code> can be used as a first-boot fallback, but saved credentials take priority. With no credentials, its WebConfig portal starts in setup-AP mode. With credentials, the WebUI is enabled by default on the station IP.</p> <p>Full Companion can also be provisioned from its USB terminal or TCP port 5002:</p> <pre><code>get wifi.ssid\nget wifi.status\nset wifi.ssid SlowFi\nset wifi.pwd your-password\n</code></pre> <p>Credential writes are persisted immediately. After the reply has drained, the Companion restarts its WiFi station with the saved pair. A port-5002 client is expected to disconnect and can reconnect at the new LAN IP. USB masks the password as it is entered; <code>get wifi.pwd</code> is intentionally unavailable. The standalone credential store accepts an empty password, ordinary passphrases up to 63 characters, or an exact 64-character hexadecimal WPA/WPA2 PSK. A non-hexadecimal 64-character value and every longer value are rejected.</p> <p>After the saved station first connects following boot, every ESP32 WiFi Companion requests a fresh UTC time from NTP. A verified reply updates both the MeshCore clock and any detected hardware RTC; the next explicit refresh is due 24 hours after that success. A failed request times out without blocking the radio loop and retries after five minutes. While WiFi is disconnected or only the setup AP is available, the request waits for a station connection. Builds with a configured MQTT bridge use its boot-and-daily NTP owner instead, so two firmware services never reconfigure the ESP32 SNTP client at the same time. A later WiFi reconnect does not add another successful-sync request; it preserves the existing 24-hour deadline. Until a fresh internet reply succeeds, LoRa clock consensus remains available as the fallback.</p> <p>On Full Companion targets whose primary mesh radio is ESP-NOW, ESP-NOW, the setup AP, and the infrastructure-WiFi station must share one 2.4 GHz channel. The persisted channel defaults to 1 and can be inspected or changed from the text terminal:</p> <pre><code>get espnow.channel\nset espnow.channel 6\nreboot\n</code></pre> <p>Valid values are 1 through 13; use only a channel permitted in your region and supported by the router. <code>set espnow.channel</code> saves the new value but does not move the running radio; reboot the node to apply it. Every primary ESP-NOW node that should communicate with it must use the same channel, and the configured router's 2.4 GHz radio must be fixed to that channel as well. A router left on automatic channel selection can move the infrastructure connection away from the ESP-NOW mesh.</p> <p><code>espnow.channel</code> configures the node's primary ESP-NOW mesh radio. It is distinct from <code>bridge.channel</code>, which applies only to the separate ESP-NOW bridge feature. WiFi power saving does not let ESP-NOW and infrastructure WiFi operate on different channels. On an ESP32 Full build whose primary radio is ESP-NOW, <code>wifi.powersave max</code> is unavailable because a station using maximum modem sleep can miss ESP-NOW broadcasts; use <code>min</code> for coexistence. The primary mesh transport holds the driver's RF wake reference continuously, so <code>min</code> does not suspend its ESP-NOW receiver.</p> <p>ESP-NOW compatibility also depends on the bytes and PHY used above the common Espressif transport. The historical <code>*_repeater_bridge_espnow</code> firmware wraps each MeshCore packet with a magic value, checksum, and secret-based XOR, while <code>Generic_ESPNOW</code> and <code>SenseCapIndicator-ESPNow</code> send the serialized MeshCore packet directly using the ESP-NOW LR PHY. Updated bridge firmware can select either behavior without changing the board target:</p> <pre><code>get bridge.format\nset bridge.channel 1\nset bridge.format raw\n</code></pre> <p>On a Heltec V4, the ordinary <code>companion_radio_full</code> image remains a LoRa-primary Companion and does not instantiate this bridge. Select and flash the existing <code>heltec_v4_repeater_bridge_espnow</code> role before using these commands. Treat that Companion-to-repeater change as a role/partition migration: back up the node and use the exact V4 merged install artifact.</p> <p><code>wrapped</code> remains the default and interoperates with existing bridge nodes that use the same channel and <code>bridge.secret</code>. <code>raw</code> interoperates with primary-ESP-NOW nodes and other raw bridges; it requires channel 1-13, enables LR reception, forces LR transmission, and ignores <code>bridge.secret</code>. Receive parsing is strict to the selected format, so migrate peers deliberately rather than expecting one bridge to accept both. Match <code>bridge.channel</code> on the LoRa gateway to the primary nodes' <code>espnow.channel</code>; a primary-node channel change takes effect after its reboot.</p> <p>Raw mode retains MeshCore's normal packet parsing, authentication/encryption, and the bridge's duplicate suppression, but it does not provide the wrapper's secret-based network isolation. That XOR wrapper is itself only lightweight isolation, not cryptographic security. Multiple LoRa/ESP-NOW gateways covering the same nodes can temporarily amplify duplicates, even though seen-packet tracking prevents an individual bridge from immediately echoing a packet back.</p> <p>If the configured network remains unavailable for two minutes, the companion opens its setup AP so the credentials can be repaired. It continues retrying the saved network. WiFi modem sleep has its own persisted <code>wifi.powersave</code> setting and is independent of the Companion device <code>powersaving</code> setting. The WiFi card in Companion WebConfig exposes <code>none</code>, <code>min</code>, and <code>max</code>. Fresh Cascade-profile builds select <code>min</code>; target-default builds select <code>none</code>. A saved setting takes precedence after an upgrade.</p> <p>WiFi-only Companions can use all three modes. A Full Companion that runs WiFi and BLE simultaneously requires at least minimum modem sleep. It reports <code>min</code> when an old or target-default <code>none</code> value is found and rejects a new <code>none</code> selection. When ESP-NOW is also the primary mesh radio, <code>max</code> is unavailable: the access point does not buffer ESP-NOW broadcasts for a sleeping station, so maximum modem sleep can lose them. Firmware caps a previously saved <code>max</code> value to and reports it as <code>min</code>, and rejects a new <code>max</code> selection.</p> <p>The SenseCAP Indicator Full targets select BLE or infrastructure WiFi instead of running both. On a WiFi-selected boot, the LoRa layout accepts <code>none|min|max</code>, while the ESP-NOW layout accepts <code>none|min</code> and still rejects <code>max</code>. On a BLE-selected boot infrastructure WiFi is off; the LoRa layout accepts <code>min|max</code> for the saved WiFi setting, while ESP-NOW + BLE requires <code>min</code>. Device power saving remains independent of this modem policy.</p> <p>WiFi companions do not have the repeater/room-server admin CLI password model, so their LAN WebConfig page is intentionally unauthenticated. Use them only on a trusted LAN.</p> <p>The WebConfig Advanced card exposes device power saving on WiFi Companion, repeater, and room-server builds. It also exposes RX power saving on radio chips that support receive duty cycling. RXPS can select continuous receive, levels 1-10, automatic or explicit 16/32-symbol timing assumptions, or manual receive/sleep windows. The timing assumption does not change the radio's actual wire preamble. The WebConfig WiFi card exposes WiFi modem power saving. All three settings are persisted across reboots.</p> <p>The three settings are independent. A WiFi Companion keeps its transports available while device power saving reduces CPU and GPS idle power. An infrastructure node can sleep when device power saving is enabled, so its WiFi services may be temporarily unavailable. RXPS only duty-cycles the LoRa receiver. Fresh Cascade-profile builds default to device power saving on, RXPS on at level 8 with a 16-symbol preamble, and WiFi modem power saving at <code>min</code> on every build that includes ESP32 WiFi. The RXPS preamble value is a saved timing assumption, not the wire length: starting with v1.17.1.5, SF5-SF8 packets normally use a 32-symbol physical preamble. Firmware selects 64 for the whole SF/BW tuple only when 32 cannot enable RXPS at any level and 64 can (SF5/BW250 and SF6/BW500), then 128 only when neither shorter length works (SF5/BW500).</p> <p>When <code>ENABLE_OTA</code> is included, a WiFi companion also listens on:</p> <ul> <li>TCP 5001 for the OTA folder seeder used by <code>motatool serve --tcp</code>;</li> <li>TCP 5002 for a text management console.</li> </ul> <p>These ports do not replace the companion protocol on TCP 5000. On a <code>companion_radio_full</code> build, port 5002 is the same role-specific text terminal available over USB, including chat, remote administration, radio and power settings, WiFi/WebConfig management, <code>tempradio</code>, and the source-only <code>ota</code> commands. Other OTA-enabled Companion builds keep the bounded <code>ota ...</code> console. LoRa staging and installation on the Full Companion itself remain disabled.</p> <p>Port 5002 is plaintext and has no independent login gate. Use it only on a trusted LAN or temporary setup network, especially when entering a remote-node admin password with the terminal's <code>login</code> command.</p> <p>FULL ESP32 builds share the port 5001 folder seeder. It starts whenever that role has a usable WiFi station or setup access point and stops when WiFi stops. For example, a FULL repeater can run <code>start webconfig</code> to join its saved network, then accept:</p> <pre><code>motatool serve --dir ./motas --tcp &lt;repeater-ip&gt;:5001 -v\n</code></pre> <p>The TCP connection supplies <code>.mota</code> files for the node to advertise and relay over LoRa; it is not a raw <code>.bin</code> uploader. <code>start ota</code> continues to provide the direct browser uploader on HTTP port 80. A FULL role without WebConfig but with browser OTA support can use the <code>MeshCore-OTA</code> access point raised by <code>start ota</code>; its seeder address is <code>192.168.4.1:5001</code>.</p> <p>Only one external folder link can be active. A TCP client is rejected while <code>ota folder on</code> is using USB serial, and disconnecting <code>motatool</code> automatically removes the TCP folder. Port 5001 has no login layer, so expose it only on a trusted LAN or temporary setup network. Firmware target and hash checks still apply at the receiving node, along with its configured signature/trust policy.</p> <p>When the shared seeder is running, <code>get wifi.status</code> appends its live state:</p> <pre><code>OTA TCP 5001: listening\nOTA TCP 5001: client connected\n</code></pre> <p>The first state means WiFi is usable and the node is waiting for <code>motatool serve --tcp</code>. The second means a <code>motatool</code> folder is currently attached and available for LoRa OTA service.</p>"},{"location":"WiFi/#wifi-companion-with-mqtt","title":"WiFi companion with MQTT","text":"<p>A <code>*_companion_radio_wifi_mqtt</code> build combines both systems:</p> <ul> <li>the companion protocol remains available to the phone/computer on TCP 5000;</li> <li>the same WiFi station connection is shared with the MQTT bridge;</li> <li>received and selected transmitted LoRa packets can be published to the   configured MQTT slots.</li> </ul> <p>The companion owns WiFi connection and recovery in this build. The MQTT bridge waits for that connection rather than creating a second one. Stopping MQTT does not disable the TCP companion service.</p> <p>The same WebConfig page contains the MQTT settings. MQTT companions have no text admin CLI, so browser configuration is the normal setup method.</p>"},{"location":"WiFi/#webconfig-without-mqtt","title":"WebConfig without MQTT","text":"<p>Full-size ESP32 repeater and room-server builds can include WebConfig even when MQTT is absent. The portal then shows node, radio, and WiFi-related controls but removes the MQTT wizard step and MQTT tab.</p> <p>In this case WebConfig owns WiFi only while it is needed. Stopping the portal disconnects WiFi and turns the WiFi radio off. There is no persistent MQTT connection keeping WiFi active.</p> <p>Unified FULL USB + WiFi and FULL logging-fallback repeater/room-server builds both provide these CLI controls and status checks. The unified profile includes the MQTT bridge; the fallback is used only where no matching MQTT environment exists:</p> <pre><code>get wifi.ssid\nget wifi.status\nget wifi.powersave\nget wifi.cli\nget webui\nset wifi.ssid SlowFi\nset wifi.pwd your-password\nset wifi.powersave none\nset wifi.cli on\n</code></pre> <p><code>get wifi.status</code> distinguishes an unconfigured node, an inactive WiFi radio, a station connection attempt, the setup AP, a connection failure, and a working LAN connection. For a LAN connection it reports the SSID, IP address, and RSSI. If the shared OTA seeder is active, the same reply also reports whether TCP port 5001 is listening or has a <code>motatool</code> client attached. <code>get wifi.powersave</code> reports the saved standalone WebConfig setting as <code>none</code>, <code>min</code>, or <code>max</code>. An inactive status is normal when <code>webui</code> is off: run <code>start webconfig</code> to connect temporarily. Standalone credentials can be changed through WebConfig or with the listed CLI commands. Changing the SSID or password stops an active WebConfig session; start it again to connect with the new values. Use <code>set wifi.pwd</code> with no value for an open network. The password is write-only and is never returned by <code>get</code>. Standalone WiFi accepts ordinary passphrases up to 63 characters and exact 64-character hexadecimal WPA/WPA2 PSKs; other 64-character values and all longer values are rejected. MQTT observer WiFi passwords remain limited to 63 characters by their fixed persisted layout.</p> <p><code>get webui</code> starts with the saved boot setting, then reports the current session. For example, <code>&gt; off, http://192.168.1.130/</code> means automatic WebConfig startup is saved as off, but a temporary session started by <code>start webconfig</code> is currently active at that URL.</p>"},{"location":"WiFi/#webconfig-cli-terminal","title":"WebConfig CLI terminal","text":"<p>The terminal defaults to on. Enable or disable it from an existing admin CLI:</p> <pre><code>set wifi.cli on\nset wifi.cli off\nget wifi.cli\n</code></pre> <p>The saved <code>on</code> setting becomes active only when the WiFi station client is connected and WebConfig is running in LAN mode. It is never exposed on the open setup access point. When active, the WebConfig page has a CLI tab for sending commands directly to the repeater or room server. It uses the local administrator command parser and displays one reply at a time. The terminal is protected by the WebConfig admin login and uses remote-administrator permissions, so commands explicitly restricted to a physical serial connection remain unavailable.</p> <p>Use Single command for the normal prompt, or select Command block to paste up to 100 commands with one command per line. Blank lines are ignored. The browser validates all lines first, then sends one command at a time and waits for its reply before sending the next. The block queue is kept in the browser only, so closing the page or losing its WiFi connection stops the commands that have not yet been sent. Ctrl+Enter or Command+Enter starts a block.</p> <p>The up/down arrow keys recall commands entered during the current browser session in single-command mode. Commands available in the terminal still depend on the firmware role and build profile. Commands such as <code>stop webconfig</code>, <code>set wifi.cli off</code>, WiFi credential changes, and reboot operations stop the remaining block and can disconnect the page before it receives their final reply.</p>"},{"location":"WiFi/#build-profiles","title":"Build profiles","text":"<p><code>build.sh</code> produces several profiles. A profile changes the features compiled into a selected target; it does not change that target into another firmware role.</p> <p>This fork defaults every <code>build.sh</code> target to the USA Cascadia radio preset and the Cascade firmware profile. The script resolves the live <code>USA/Canada</code> entry by name, so its changing number in the downloaded menu does not affect builds. If the preset service is unavailable, it falls back to <code>910.525 MHz / BW62.5 / SF7 / CR5</code>. Use <code>--radio-preset target --profile default</code> only when a build intentionally needs the target's original radio and profile defaults. <code>--radio-preset usa-cascadia</code> is the stable explicit name; legacy numbered choices remain accepted but their meaning can change when the service reorders or adds presets.</p> Build profile WiFi/MQTT behavior Standard Uses the selected target's role. Where USB is a safe plaintext console, the same artifact embeds debug/packet logging behind persistent <code>get/set usb.logging</code>. Ordinary legacy-slot ESP32 repeater/room-server artifacts omit WebConfig when needed to fit. ESP32 MQTT observer and ESP-NOW bridge targets are automatically promoted to FULL; WiFi-companion targets keep their companion partition profile. Legacy logging No separate artifact is emitted; USB logging is part of the ordinary image. Logging output itself is not a direct MQTT uplink. MQTT Builds explicit MQTT observer or WiFi-companion-MQTT targets with USB packet logging off. Non-companion ESP32 MQTT observers always use FULL expanded partitions. FULL ESP32 USB + WiFi Uses the board's MQTT target with USB packet logging and direct WiFi MQTT together, expanded dual-OTA partitions, up to 254 neighbors, LoRa OTA, and full-size ESP32 features such as WebConfig where supported. <code>get/set logging.output off\\|usb\\|wifi\\|both</code> persists the active paths. Classic T-Beam MQTT observers retain their 50-entry table because their persistent discovery state exhausts internal DRAM at 254. FULL ESP32 logging fallback Uses the board's non-MQTT target only when no matching WiFi MQTT environment exists. It keeps debug and packet logging, expanded dual-OTA partitions, up to 254 neighbors, and LoRa OTA. Persistent <code>usb.logging off</code> also provides normal output-off operation, so ESP-NOW FULL roles need no second non-logging image. LoRa-OTA no-external-sensors A lean repeater image with no MQTT; ESP32 builds retain the compact on-demand browser WiFi uploader and 254 neighbors. <p>All repeater profiles use the full 254-entry neighbor table, including standard, logging, bridge, and LoRa-OTA builds on every supported platform. The classic T-Beam SX1262 and SX1276 MQTT observer repeaters retain 50 entries because their persistent MQTT discovery state leaves insufficient internal-DRAM margin at 254.</p> <p>The interactive Option 1 FULL everything choice and the standalone FULL command select the unified USB + WiFi image when a matching MQTT target exists; otherwise they select the logging fallback. The build matrix no longer emits any separate standard logging image, or a non-MQTT FULL twin for a role covered by the unified image. All FULL profiles include LoRa OTA, WebConfig where supported, up to 254 neighbors, and expanded dual-OTA partitions. Target-specific internal-DRAM limits still apply.</p> <p>FULL images change the ESP32 partition layout. Flash the matching <code>*-merged.bin</code> once when installing that layout. A partition-layout change can invalidate NVS, including saved WiFi, MQTT, name, and admin settings. Later updates using the same layout normally preserve them.</p>"},{"location":"WiFi/#wifi-power-behavior","title":"WiFi power behavior","text":"<p>MQTT observers and FULL standalone ESP32 repeater/room-server builds support:</p> <pre><code>set wifi.powersave none\nset wifi.powersave min\nset wifi.powersave max\n</code></pre> <p>Fresh Cascade-profile builds default to <code>min</code>; target-default builds use <code>none</code>, which gives the most predictable MQTT and radio performance at the highest power use. <code>min</code> and <code>max</code> reduce power but may add latency or reduce reliability on busy nodes. A saved operator setting takes precedence on an upgrade. ESP32 WiFi Companions expose the same values in their WebConfig WiFi card and USB text terminal. Full Companion also accepts the text commands from TCP port 5002. The normal binary Companion protocol can read or write the setting over USB, BLE, or TCP port 5000 without entering terminal mode. A Full Companion that runs BLE and infrastructure WiFi simultaneously rejects <code>none</code> because coexistence requires WiFi modem sleep. An ESP32 Full Companion whose primary mesh radio is ESP-NOW also rejects <code>max</code>; maximum modem sleep can cause the station to miss ESP-NOW broadcasts because the access point does not buffer them. A previously saved <code>max</code> value is capped to and reported as <code>min</code>. The SenseCAP Indicator exception uses the active-mode rules above rather than assuming BLE and infrastructure WiFi are active together. ESP-NOW and infrastructure WiFi still must use the same fixed channel.</p> <p>MQTT observer targets normally limit ESP32 WiFi transmit power to 11 dBm unless the board configuration overrides <code>MQTT_WIFI_TX_POWER</code>. This setting affects WiFi only, not LoRa transmit power.</p>"},{"location":"WiFi/#recognizing-the-wrong-firmware","title":"Recognizing the wrong firmware","text":"<p><code>get wifi.status</code>, <code>get wifi.ssid</code>, <code>get wifi.powersave</code>, and <code>get wifi.cli</code> are available on MQTT observers and on FULL non-MQTT repeater/room-server builds with WebConfig. ESP32 WiFi Companions expose the first three commands, credential setters, and <code>start webconfig [ap]</code> through their USB text terminal; <code>get/set wifi.cli</code> explicitly report that the repeater/room-server browser CLI is unavailable. Full Companion instead exposes its complete role-specific text terminal on TCP port 5002. MQTT commands such as <code>get mqtt.status</code> and <code>set mqtt1.preset ...</code> still require an MQTT observer target. Unknown settings return <code>Error: unknown setting: &lt;name&gt;</code>. Older firmware that used the discontinued compact CLI can instead report <code>Unsupported in this firmware</code> when a command was cut for space.</p> <p>Check the complete firmware filename and role. In particular:</p> <ul> <li><code>logging</code> does not mean MQTT;</li> <li><code>ota</code> does not mean MQTT;</li> <li><code>companion_radio_wifi</code> does not mean MQTT;</li> <li>the filename must contain <code>observer_mqtt</code> or <code>wifi_mqtt</code> for the corresponding   on-device MQTT feature.</li> </ul> <p>Rolling firmware back does not restore settings erased by a full flash or a partition-table change. If the correct MQTT target still has no configuration, provision WiFi and MQTT again.</p>"},{"location":"WiFi/#troubleshooting","title":"Troubleshooting","text":"<p>For an MQTT observer:</p> <pre><code>get wifi.status\nget bridge.enabled\nget mqtt.status\nget mqtt1.diag\nget mqtt2.diag\n</code></pre> <p>Common causes are:</p> <ul> <li>no saved SSID or a changed password;</li> <li>blank/invalid IATA for a preset that requires it;</li> <li>the bridge disabled;</li> <li>all MQTT slots disabled;</li> <li>too many TLS/WSS slots for the available internal memory;</li> <li>WiFi power saving being too aggressive;</li> <li>the wrong firmware role or an older compact-CLI build without WebConfig.</li> </ul> <p>For a WiFi companion, find its station IP in the router, connect the client to TCP port 5000, and use the open <code>MeshCore-Setup-XXXX</code> AP at <code>http://192.168.4.1/</code> if it cannot join the saved network. Current firmware normalizes both ESP32 WiFi interfaces to standard b/g/n before advertising the setup AP. Full Companion targets whose primary mesh radio is ESP-NOW use b/g/n+LR instead and keep the setup AP, infrastructure station, and mesh on the persisted <code>espnow.channel</code> (channel 1 by default). Their configured 2.4 GHz router and every other primary ESP-NOW node must use that same channel. MQTT diagnostics apply only to a <code>wifi_mqtt</code> companion target.</p>"},{"location":"cli_build_matrix/","title":"CLI Availability by Firmware Build","text":"<p>MeshCore command availability is determined in three layers:</p> <ol> <li>Role - repeater, room server, sensor, companion, bridge, or KISS modem.</li> <li>Build profile - standard, logging, OTA, or FULL.</li> <li>Compiled hardware features - WiFi, MQTT, GPS, external sensors, PSRAM,    Ethernet, and similar optional support.</li> </ol> <p>The complete command descriptions are in CLI Commands. This page describes the commands intentionally omitted or limited by build profile. The CLI Command Availability Matrix expands this summary into separate nRF52 and ESP32 command tables.</p>"},{"location":"cli_build_matrix/#selecting-a-build-profile","title":"Selecting a build profile","text":"<p>The runtime settings profile and the feature profile are separate switches:</p> <pre><code>bash build.sh build-firmware RAK_3401_repeater \\\n  --profile cascade \\\n  --build-profile auto\n</code></pre> <p><code>--profile default|cascade</code> selects saved-setting defaults. It does not select which code is linked. <code>--build-profile auto|standard|full</code> controls features and partition policy:</p> Selection Behavior <code>auto</code> For one explicit target, pass 1 builds the complete supported LoRa-OTA-capable recipe. ESP32 boards with a qualified expanded profile use it; other repeaters attempt the complete recipe in their current application region. A non-repeater keeps every capability declared by its resolved PlatformIO recipe, including LoRa OTA, and fails instead of silently removing one that does not fit. A measured repeater flash/partition overflow starts the standard <code>no_external_sensors</code> LoRa OTA pass. Internal-flash nRF52 repeaters publish that reduced pass even when the complete image fits, because the smaller running image leaves more room to stage a delta; matched QSPI/SD repeaters do not need the redundant artifact. Compiler errors and missing-capability checks never trigger or conceal a reduced build. Canonical bulk commands keep their established standard partition contract. <code>standard</code> Immediately uses the deployed/portable partition contract and its documented reductions. This is useful when the operator already knows the expanded or complete image is unsuitable. <code>full</code> Requires a qualified ESP32 expanded-partition target (or an explicitly named Full Companion). Install a matching merged image when this changes the partition table. <p>Successful builds also emit <code>&lt;firmware&gt;.capabilities.json</code>. The sidecar records the effective profile, logical OTA target, actual PlatformIO base, artifact name target, promised capabilities, and every reduction selected by the script. The build fails if a promised linked marker is absent. Current invariants include <code>retry.preset</code> for repeater/room-server roles, WebConfig for the Indicator and ESP32 Full Companion, TempRadio/OTA controls for install-capable Companions, host-mOTA controls for Full Companion, and the advanced flood-rule engine for Full room servers. Resume mode will not accept an old or failed artifact without a verified sidecar.</p>"},{"location":"cli_build_matrix/#role-comes-first","title":"Role comes first","text":"Role Text administration CLI Repeater Full repeater administration surface, subject to the profile differences below Room server Room-server administration surface, subject to the profile differences below Sensor Sensor command surface; it does not acquire the repeater administration tree Full, serial, Ethernet, USB, BLE, or WiFi companion Uses the companion protocol; Full combines every qualified transport for that exact board KISS modem Uses the KISS/TNC frame interface, not the repeater text CLI Bridge Uses its base role plus commands for the bridge transport compiled into that target <p>A command belonging to a different role is not considered a profile cut. For example, adding FULL features to a sensor does not turn it into a repeater administrator.</p> <p>Repeater profiles use 254 neighbor entries across supported platforms. The classic T-Beam SX1262 and SX1276 MQTT observer repeaters are the exception and retain 50 because their MQTT discovery tables are constrained by internal DRAM.</p>"},{"location":"cli_build_matrix/#profile-matrix","title":"Profile matrix","text":"Build/profile Command availability Standard non-MQTT repeater or room server Keeps the normal role CLI and, where USB is a safe plaintext console, embeds debug/packet logging behind persistent <code>get/set usb.logging</code>. The explicitly selected portable policy can omit WebConfig and browser WiFi OTA, so those commands are unavailable and the omission is recorded in the capability manifest. Legacy standard logging No longer emitted separately. Its behavior is compiled into the ordinary artifact. Size-constrained STM32 targets embed packet logging without verbose <code>MESH_DEBUG</code>. LoRa-OTA (<code>-ota-</code>) LoRa OTA adds the <code>ota ...</code> commands; it does not otherwise reduce the role CLI. ESP32 <code>no_external_sensors</code> artifacts retain the compact browser WiFi uploader, the complete CLI, and a 254-entry neighbor table. Internal-flash nRF52 repeater auto pair <code>full-ota</code> retains the board's external-sensor drivers; <code>reduced-ota</code> omits the declared optional sensors to leave additional internal-flash staging room. RAK3401 and RAK4631 reduced builds retain INA219, INA226, INA260, and INA3221 I2C voltage/current monitors at a measured cost below 5 KiB. Both artifacts carry the same stable OTA target identity and are checked for <code>ota ...</code> and <code>retry.preset</code>; RAK artifacts also verify the retained monitor drivers. ESP32 MQTT observer or ESP-NOW bridge Always uses the expanded FULL partition profile. The build never substitutes a reduced CLI to fit the legacy application slot. FULL ESP32 USB + WiFi Uses the matching MQTT target with packet logging on, verbose debug off, and the complete command surface supported by that role and hardware. <code>get/set logging.output off\\|usb\\|wifi\\|both</code> selects and persists the active output paths. FULL ESP32 logging fallback Uses the matching non-MQTT target only when no WiFi MQTT sibling exists, with debug and packet logging enabled and the complete command surface supported by that role and hardware. Its persistent USB gate also covers output-off operation, avoiding a second FULL ESP-NOW image. nRF52 dual-CDC Full Companion Fresh installs expose only interface <code>00</code>; it starts as an ASCII terminal and automatically hands a complete <code>&lt;</code> frame to framed Companion. The same interface also carries exclusive serial mOTA traffic. Enabling logging and rebooting adds interface <code>02</code> for plaintext logs. BLE and source-only LoRa OTA remain available. <code>get/set usb.logging</code> persistently controls whether the logging interface is present. ESP32 single-TTY Full Companion Every ESP32 Full image starts with the ASCII terminal on its one USB TTY and automatically hands a complete <code>&lt;</code> frame to framed Companion. <code>set usb.logging on</code> switches that TTY to an input-capable plaintext logging terminal and makes framed Companion unavailable on USB; <code>set usb.logging off</code> stops logging but leaves the TTY in normal ASCII mode. The terminal stop token or a valid incoming framed probe then performs the ordinary switch to Binary Companion. A saved logging-on setting starts directly in that logging terminal and disables automatic frame detection. BLE, WiFi, and source-only LoRa OTA remain available. ESP32 Full uses Arduino-ESP32 2.x where supported; RC32 and ESP32-C6 keep their board-required Arduino 3.x platform but still expose only one TTY. <code>no_external_sensors</code> Trims selected optional environmental/ranging drivers and their settings; it does not remove generic I2C, core repeater discovery, routing, or runtime RS-232 commands. RAK3401 and RAK4631 profiles retain the four common INA I2C voltage/current monitors. GPS-preserving RAK nRF52 OTA profiles retain their GPS commands and provider; RAK4631 defaults the bridge to UART 2 because RAK12501/L76K GPS uses UART 1. Legacy target suffixes remain stable for OTA identity compatibility. <p>The four retained INA drivers are entries in the optional environmental-sensor table, not the complete set of RAK I2C consumers. Compatible reduced profiles also retain the SSD1306 OLED, supported autodiscovered RTCs, and RAK12500 I2C GPS as separate board peripherals. RAK12501/L76K GPS uses UART Serial1. The explicit RAK4631 Serial1 bridge omits the combined GPS provider, including the otherwise non-UART RAK12500 path.</p> <p>The firmware-configured INA3221 and RAK12500 addresses are both <code>0x42</code>. To use both devices on one bus, leave RAK12500 at <code>0x42</code>, strap INA3221 A0 to SCL for <code>0x43</code>, and build with <code>-DTELEM_INA3221_ADDRESS=0x43</code>.</p> <p><code>logging</code>, <code>OTA</code>, and <code>FULL</code> describe independent build features in historical filenames. Current standard artifacts use no <code>-logging-</code> infix because their USB logging is runtime controlled.</p>"},{"location":"cli_build_matrix/#canonical-bulk-build-policy","title":"Canonical bulk-build policy","text":"<p>Bulk and release-matrix commands omit legacy names whose behavior is already available from a canonical image:</p> <ul> <li>Companion <code>_ps</code> names are replaced by the ordinary Companion image plus the   persisted <code>powersaving on|off</code> setting.</li> <li>Companion <code>_femoff</code> names are replaced by the matching controllable-FEM   image plus <code>radio.fem.rxgain on|off</code>. The old names remain explicit build   targets for compatibility.</li> <li><code>Station_G2_logging_*</code> and <code>Station_G3_ESP32_logging_*</code> hardware names are   replaced by their ordinary Station target. G2 boosted receive gain is the   persisted <code>radio.rxgain on|off</code> setting; the G3 alias changed only the   advertised default name.</li> <li> <p>When a board has a Full Companion, that one artifact replaces its   separate USB, BLE, ordinary WiFi, hardware-serial, Ethernet Companion, and   USB packet-logging Companion artifacts.   It provides BLE and source-only LoRa OTA; ESP32 also provides ordinary WiFi.   nRF52 keeps framed traffic on interface <code>00</code> and can add logging on interface   <code>02</code> after a reboot. Every ESP32 Full build instead switches its one USB TTY   into an input-capable logging terminal. Turning logging off restores the   normal ASCII terminal; the usual stop token or a valid framed probe then   switches it to Binary Companion.   Its LoRa OTA support is source-only: it can serve a host file to another node   but has no staging store and cannot update itself over LoRa.   Installing an ESP32 Full Companion may require one merged-image erase/flash   to adopt its expanded partition table. Once migrated, later Full Companion   releases use normal app updates. The transport-specific non-Full images stay   available as explicit build targets, but are not canonical release artifacts   when the qualified Full image fits.</p> </li> <li> <p>Standalone Terminal Chat is omitted when the same exact hardware has either   Full Companion or a USB Companion, because their local text terminal supplies   the same role. Heltec E290 and T190 similarly publish one combined USB + BLE   Companion. RAK4631 repeater and room-server Ethernet builds stay separate;   only the RAK4631 Ethernet Companion is folded into Full Companion.</p> </li> <li>Matching RS-232 bridge roles are compiled into the normal repeater and   selected at runtime with <code>bridge.enabled</code>, <code>bridge.baud</code>, and <code>bridge.uart</code>.   Historical bridge names remain directly buildable but are omitted from bulk   releases. Wio-E5 remains separate because its normal image has only 916   bytes free, while the combined image exceeds the fixed 240 KiB application   partition by 2,192 bytes.</li> </ul> <p>The old aliases still work with <code>build-firmware</code> and <code>build-matching-firmwares</code>. Dedicated LoRa OTA repeater images are not collapsed; they retain their exact storage, bootloader, role, and target identity contracts. Companion boards keep transport-specific canonical images only when no exact Full recipe has passed the combined flash/RAM qualification. ESP32 deliberately uses one TTY: Binary Companion and plaintext USB logging are mutually exclusive there. nRF52 retains its optional second CDC port.</p>"},{"location":"cli_build_matrix/#complete-cli-policy","title":"Complete CLI policy","text":"<p>The compact ESP32 CLI has been removed. <code>retry.preset</code> is a checked invariant for every repeater and room-server artifact, not a FULL-only command. MQTT observers and ESP-NOW bridges are automatically promoted to FULL builds with expanded partitions rather than dropping administration commands. This keeps <code>tempradio</code>, LoRa OTA, power saving, RXPS, logging, statistics, sensor, ACL, routing, and advanced radio commands whenever the role and compiled hardware support them.</p> <p>Some commands still have hardware or feature limits. MQTT neighbor-table publishing and <code>discover.scopes</code> require the compiled <code>WITH_MQTT_NEIGHBORS</code> feature. PSRAM boards enable it automatically, and selected non-PSRAM variants opt in with <code>MQTT_NEIGHBORS_WITHOUT_PSRAM</code>. <code>discover.neighbors</code> does not require MQTT or PSRAM.</p>"},{"location":"cli_build_matrix/#discovery-invariant","title":"Discovery invariant","text":"<p><code>discover.neighbors</code> sends the zero-hop node-discovery request used to refresh the repeater neighbor table. It is available in every repeater build profile, including standard, logging, OTA, unified FULL, and FULL logging-fallback builds.</p> <p>The exact command is:</p> <pre><code>discover.neighbors\n</code></pre> <p>It accepts no options and returns:</p> <pre><code>OK - Discover sent\n</code></pre> <p>Some MQTT room-server targets also expose the command as part of their compiled neighbor-table feature. It is not a cross-role guarantee: companion, KISS, sensor, and ordinary room-server firmware use different interfaces or do not maintain the repeater administrator neighbor table.</p>"},{"location":"cli_build_matrix/#feature-dependent-commands","title":"Feature-dependent commands","text":"<p>Even in a FULL build, a command can be unavailable when its underlying feature does not exist on that target:</p> <ul> <li>WebConfig and the <code>wifi.ssid</code>, <code>wifi.status</code>, and <code>wifi.powersave</code> command   family require an ESP32 WebConfig build. FULL standalone repeater and   room-server builds support the corresponding WiFi setters and status   commands. ESP32 WiFi Companions with WebConfig expose WiFi credentials,   connection status, WebConfig, and power-save controls from their USB   text terminal as well as power saving through WebConfig and the binary   protocol. The browser CLI tab and <code>wifi.cli</code> setting are repeater/room-server   features. Full Companion instead exposes its complete role-specific text   terminal on TCP port 5002.</li> <li>MQTT commands require an MQTT observer target.</li> <li><code>discover.scopes</code> requires an MQTT observer with compiled neighbor support;   it does not independently require PSRAM or the FULL parser.</li> <li>GPS and external-sensor commands require their drivers and pins.</li> <li>Ethernet and bridge commands require the corresponding transport.</li> <li>LoRa OTA commands require an artifact with OTA enabled.</li> <li><code>uf2reset</code> applies only to nRF52.</li> </ul> <p>When diagnosing an unavailable command, check the role first, then the filename profile, then the target's compiled hardware features and its adjacent <code>.capabilities.json</code> file. A current artifact that promises the command but does not contain its linked marker is rejected during the build.</p>"},{"location":"cli_command_availability/","title":"CLI Command Availability Matrix","text":"<p>This page is the command-by-command companion to CLI Availability by Firmware Build. Each command name links to its detailed documentation.</p> <p>The tables cover the text administration CLI used by repeater, room-server, sensor, and bridge firmware. Companion firmware uses the companion protocol, KISS firmware uses framed KISS/TNC commands, and terminal-chat firmware has its own interface, so those build roles are not represented here.</p> <p>Build columns mean:</p> <ul> <li>Standard - the ordinary non-MQTT artifact, without an explicit <code>ota</code>   filename marker. Safe plaintext-USB roles embed runtime USB logging.</li> <li>Logging - the legacy <code>-logging-</code> profile, now represented by the same   ordinary artifact and retained as a comparison column only.</li> <li>LoRa OTA - the explicit <code>-ota-</code> repeater or repeater-bridge artifact. A   legacy <code>no_external_sensors</code> profile trims selected optional environmental   and ranging drivers; it does not disable the generic I2C bus or unrelated   board-integrated peripherals. Reduced RAK3401 and RAK4631 profiles retain   INA219/INA226/INA260/INA3221 as voltage/current entries in the optional sensor   table. The SSD1306 OLED, supported autodiscovered RTCs, and RAK12500 GPS are   separate I2C peripherals in compatible recipes. RAK12501/L76K GPS instead   uses UART Serial1. The plain RAK profiles and RAK4631 Serial2 bridge retain   the combined GPS provider; the explicit RAK4631 Serial1 bridge omits that   provider, including RAK12500, because the bridge owns the RAK12501 UART.</li> <li>FULL unified - the expanded-partition ESP32 artifact with LoRa OTA, the   complete parser, USB packet logging, and direct WiFi MQTT. Its saved output   mode can be off, USB, WiFi, or both. MQTT observers use this profile.</li> <li>FULL fallback - the expanded-partition ESP32 non-MQTT artifact used only   where there is no MQTT sibling. It has the complete parser and a saved   USB-logging on/off gate. ESP-NOW bridges use this profile.</li> </ul> <p>The firmware-configured INA3221 and RAK12500 addresses are both <code>0x42</code>; they cannot coexist on one bus at those addresses. Leave RAK12500 at <code>0x42</code>, strap INA3221 A0 to SCL for <code>0x43</code>, and use a build with <code>-DTELEM_INA3221_ADDRESS=0x43</code> when both are installed.</p> <p>Cell values mean:</p> <ul> <li>Yes - the parser includes the command. The Scope column still applies.</li> <li>No - the profile does not expose the command.</li> <li>Feature - available only when the target compiles the feature or hardware   named in Scope.</li> <li>Serial - available only from the local serial console.</li> <li>Manifest - available only when the MQTT target defines   <code>OTA_MANIFEST_BASE</code>.</li> <li>Limited - the family exists, but the limitation in Scope applies.</li> </ul> <p>Runtime state can still make an included command fail. Examples include no GPS fix, no WiFi connection, an inactive bridge, or an nRF52 bootloader without <code>.mota</code> apply support.</p>"},{"location":"cli_command_availability/#companion-framed-cli","title":"Companion framed CLI","text":"<p>Companion builds are not represented by the role/profile matrices below. Their local terminal and command <code>0x42</code> (<code>CMD_RUN_CLI_COMMAND</code>) expose these settings over the normal binary USB, BLE, or TCP connection:</p> Command Availability <code>board</code> Every Companion text terminal and command <code>0x42</code> <code>version</code> Every Companion text terminal and protocol-v14 command <code>0x42</code>; returns the untruncated build identity <code>get storage.layout</code> Every Companion text terminal and command <code>0x42</code>; reports the running platform's storage layout <code>memory</code> ESP32 Full Companion text terminal and command <code>0x42</code> <code>get/set radio.rxgain</code> Companion with a supported radio <code>get/set radio.fem.rxgain</code> Companion on a board with controllable LoRa FEM LNA <code>get/set wifi.powersave</code> ESP32 WiFi Companion; active transport constraints still apply <code>get/set bluetooth.name</code> Companion firmware <code>uf2reset</code> Every nRF52 Companion text terminal and local command <code>0x42</code>; local only <p>Deprecated binary aliases remain receive-only for older clients; new clients should use command <code>0x42</code>. See Companion radio binary protocol.</p>"},{"location":"cli_command_availability/#nrf52","title":"nRF52","text":"Area Command Scope Standard Logging LoRa OTA Operational <code>reboot</code> All text CLI roles Yes Yes Yes Operational <code>poweroff</code>; <code>shutdown</code> Board power-off support Yes Yes Yes Operational <code>uf2reset</code> Local serial; supported UF2 boards Serial Serial Serial Operational <code>clkreboot</code> All text CLI roles Yes Yes Yes Operational <code>clock sync</code> All text CLI roles Yes Yes Yes Operational <code>clock</code> All text CLI roles Yes Yes Yes Operational <code>time &lt;epoch_seconds&gt;</code> Clock only moves forward Yes Yes Yes Operational <code>advert</code> Advert-capable role Yes Yes Yes Operational <code>advert.zerohop</code> Advert-capable role Yes Yes Yes Operational <code>erase</code> Local serial Serial Serial Serial Information <code>ver</code> All text CLI roles Yes Yes Yes Information <code>board</code> All text CLI roles Yes Yes Yes Diagnostics <code>get storage.layout</code> Internal layout and configured QSPI or SD storage Yes Yes Yes Diagnostics <code>memory</code> ESP32 only No No No Diagnostics <code>sensor</code> Hardware wiring summary Yes Yes Yes Diagnostics <code>powerlog</code> Reset, shutdown, and boot-voltage summary Yes Yes Yes Neighbors <code>neighbors</code> Role with a neighbor table Yes Yes Yes Neighbors <code>neighbor.remove &lt;pubkey_prefix&gt;</code> Role with a mutable neighbor table Yes Yes Yes Neighbors <code>discover.neighbors</code> Repeater; some MQTT room servers Yes Yes Yes Neighbors <code>discover.scopes</code> MQTT observer with compiled neighbor support No No No Statistics <code>clear stats</code> All full-parser text CLI roles Yes Yes Yes Statistics <code>stats-core</code> Local serial Serial Serial Serial Statistics <code>stats-radio</code> Local serial Serial Serial Serial Statistics <code>stats-radio-diag</code> Local serial Serial Serial Serial Statistics <code>stats-packets</code> Local serial Serial Serial Serial Statistics <code>get telemetry.temp/volt/volt.i2c</code>; optional GPS history Non-STM32 repeater or room server; I2C command requires a detected voltage monitor; GPS requires a provider; remote access requires administrator Yes Yes Yes Statistics <code>set telemetry.gps</code>; <code>get/set/send telemetry.tx</code> Non-STM32 repeater; GPS setting requires a provider; remote access requires administrator Yes Yes Yes Logging <code>log start</code>; <code>log stop</code>; <code>log erase</code> Storage-backed roles retain data; other roles can return empty data Yes Yes Yes Logging <code>log</code> Local serial Serial Serial Serial Logging <code>get/set usb.logging</code>; unified FULL <code>get/set logging.output</code> Ordinary safe-USB artifacts; CommonCLI USB gate is persistent; unified ESP32 FULL selects off/USB/WiFi/both; nRF52 Full Companion can add a reboot-controlled second CDC Yes Yes No Radio <code>get radio</code>; <code>set radio ...</code> All text CLI roles Yes Yes Yes Radio <code>get tx</code>; <code>set tx &lt;dbm&gt;</code> Board TX-power limits apply Yes Yes Yes Radio <code>tempradio ...</code>; <code>normalradio</code> Full parser Yes Yes Yes Radio <code>get/set/del radioat</code>; <code>get/set/del tempradioat</code> Full parser Yes Yes Yes Radio <code>get freq</code>; <code>set freq &lt;mhz&gt;</code> <code>set</code> is local serial only Yes Yes Yes Radio <code>get/set radio.rxgain</code> Supported radio Feature Feature Feature Radio <code>get/set radio.fem.rxgain</code> Controllable LoRa FEM Feature Feature Feature Radio <code>get/set radio.fem.txgain</code> Controllable LoRa FEM Feature Feature Feature Radio <code>get/set radio.rxps</code>; <code>get rxps.wd</code> RX power-saving support Feature Feature Feature System <code>get/set name</code> All text CLI roles Yes Yes Yes System <code>get/set lat</code> All text CLI roles Yes Yes Yes System <code>get/set lon</code> All text CLI roles Yes Yes Yes System <code>get/set prv.key</code> <code>get</code> is local serial only Yes Yes Yes System <code>password &lt;new_password&gt;</code> Administrator Yes Yes Yes System <code>get/set guest.password</code> Role with guest administration Yes Yes Yes System <code>get/set owner.info</code> All text CLI roles Yes Yes Yes System <code>get/set adc.multiplier</code> Board ADC override support Feature Feature Feature System <code>send text.flood &lt;message&gt;</code> Repeater Yes Yes Yes System <code>host &lt;text&gt;</code>; <code>get host</code> Repeater with host bridge; <code>host</code> requires a remote administrator and a USB/MQTT service Yes Yes Yes System <code>get/set battery.alert</code>; <code>get battery.alert.region</code> Repeater Yes Yes Yes System <code>get/set battery.alert.low</code>; <code>get/set battery.alert.critical</code> Repeater Yes Yes Yes System <code>get/set rx.watchdog</code> Repeater Yes Yes Yes System <code>get/set system.watchdog</code> nRF52 Yes Yes Yes System <code>get public.key</code> All text CLI roles Yes Yes Yes System <code>get role</code> All text CLI roles Yes Yes Yes System <code>powersaving</code>; <code>powersaving on/off</code> Supported repeater board Feature Feature Feature System <code>get/set reboot.interval</code> Full parser Yes Yes Yes Clock sync <code>get/set clock.sync.*</code>; <code>clock.sync.mesh now</code> Repeater, sensor, and room server; <code>clock.sync.internet</code> needs MQTT repeater Yes Yes Yes Routing <code>get/set repeat</code> Forwarding-capable role Yes Yes Yes Routing <code>get/set path.hash.mode</code> Role that supports path-hash selection Yes Yes Yes Routing <code>get/set loop.detect</code> Repeater Yes Yes Yes Routing <code>get/set txdelay</code> All text CLI roles, including bridges Yes Yes Yes Routing <code>get/set direct.txdelay</code> Full parser Yes Yes Yes Routing <code>get/set rxdelay</code> All text CLI roles, including bridges Yes Yes Yes Routing <code>get/set dutycycle</code> Full parser Yes Yes Yes Routing <code>get/set af</code> Full parser Yes Yes Yes Routing <code>get/set int.thresh</code> All text CLI roles Yes Yes Yes Routing <code>get/set cad</code> Radio CAD support Feature Feature Feature Routing <code>get/set agc.reset.interval</code> All text CLI roles Yes Yes Yes Routing <code>get/set radio.watchdog</code> MQTT observer No No No Routing <code>get/set multi.acks</code> Full parser Yes Yes Yes Routing <code>get/set flood.advert.interval</code> Repeater Yes Yes Yes Routing <code>get/set advert.interval</code> Advert-capable role Yes Yes Yes Routing <code>get/set flood.max</code> Repeater Yes Yes Yes Routing <code>get/set flood.max.unscoped</code> Repeater Yes Yes Yes Routing <code>get/set flood.max.advert</code> Repeater Yes Yes Yes Routing <code>get/set flood.channel.data</code>; <code>get/set flood.channel.data.hops</code> Repeater Yes Yes Yes Routing <code>get/set/del flood.channel.scope*</code> Repeater Yes Yes Yes Routing <code>get/set/del flood.channel.scope.require*</code> Repeater Yes Yes Yes Routing <code>get/set/del flood.rule*</code>; <code>get/set/del flood.filter*</code>; <code>get/set/del flood.filter.blacklist*</code> Repeater; <code>flood.rule</code>/<code>flood.filter</code> also on FULL ESP32 room server (no blacklist) Yes Yes Yes Routing <code>get/set/del flood.moderation*</code> Repeater Yes Yes Yes Routing <code>get/set outpath</code> Repeater remote-client context Yes Yes Yes Routing <code>get/set altpath</code> Repeater remote-client context Yes Yes Yes ACL <code>setperm &lt;pubkey&gt; &lt;permissions&gt;</code> Repeater, room server, or sensor Yes Yes Yes ACL <code>get acl</code> Local serial Serial Serial Serial ACL <code>get/set allow.read.only</code> Room server Yes Yes No Regions <code>region load</code>; <code>region save</code> Role with region storage Yes Yes Yes Regions <code>region allowf</code>; <code>region denyf</code> Role with region storage Yes Yes Yes Regions <code>region get</code>; <code>region list</code>; <code>region</code> Role with region storage Yes Yes Yes Regions <code>region home</code>; <code>region default</code> Role with region storage Yes Yes Yes Regions <code>region put</code>; <code>region def</code>; <code>region remove</code> Role with region storage Yes Yes Yes Retry <code>get/set direct.retry</code>; <code>get/set direct.retry.heard</code> Role with basic retry support Yes Yes Yes Retry <code>get/set retry.preset</code> Role with retry support Yes Yes Yes Retry <code>get/set flood.retry.count</code>; <code>get/set flood.retry.path</code>; <code>get/set flood.retry.group.path</code> Repeater Yes Yes Yes Retry <code>get/set flood.retry.advert</code>; <code>get/set flood.retry.prefixes</code>; <code>get/set flood.retry.ignore</code> Repeater Yes Yes Yes Retry <code>get/set flood.retry.bridge</code>; <code>get/set flood.retry.bucket</code> Repeater bridge retry support Feature Feature Feature Retry <code>get/set direct.retry.count</code>; <code>get/set direct.retry.base</code>; <code>get/set direct.retry.step</code> Role with retry support Yes Yes Yes Retry <code>get/set direct.retry.margin</code>; <code>get/set direct.retry.cr</code> Role with retry support Yes Yes Yes Retry <code>get/set/clear recent.repeater</code>; <code>get recent.repeaters</code> Repeater Yes Yes Yes GPS <code>gps</code>; <code>gps on/off</code> Compiled GPS Feature Feature Feature GPS <code>gps sync</code> Compiled GPS Feature Feature Feature GPS <code>gps setloc</code> Compiled GPS Feature Feature Feature GPS <code>gps advert [none/share/prefs]</code> Compiled GPS Feature Feature Feature Sensors <code>get/set telemetry.access</code> Sensor-capable role Feature Feature Limited Sensors <code>sensor list [start]</code> Compiled sensor manager; reduced OTA trims target-selected optional environmental/ranging drivers Feature Feature Limited Sensors <code>sensor get</code>; <code>sensor set</code> Compiled sensor setting; reduced OTA trims target-selected optional environmental/ranging drivers Feature Feature Limited Sensors <code>io [r/s/t]&lt;hex&gt;</code> Simple sensor role with board GPIO support Feature Feature No Bridge <code>get bridge.type</code> Compiled bridge Feature Feature Feature Bridge <code>get/set bridge.enabled</code>; <code>get bridge.running</code> Compiled bridge Feature Feature Feature Bridge <code>get/set bridge.delay</code> Compiled bridge Feature Feature Feature Bridge <code>get/set bridge.source</code> Compiled bridge Feature Feature Feature Bridge <code>get/set bridge.baud</code> RS-232 bridge Feature Feature Feature Bridge <code>get/set bridge.uart</code> RS-232 bridge Feature Feature Feature Bridge <code>get/set bridge.channel</code> ESP-NOW is ESP32 only No No No Bridge <code>get/set bridge.format</code> ESP-NOW bridge No No No Bridge <code>get/set bridge.secret</code> ESP-NOW is ESP32 only No No No Board <code>get bootloader.ver</code> nRF52 bootloader metadata Yes Yes Yes Board <code>get pwrmgt.support</code>; <code>get pwrmgt.source</code>; <code>get pwrmgt.bootreason</code>; <code>get pwrmgt.bootmv</code> Board power-management implementation Feature Feature Feature Ethernet <code>eth.status</code> Ethernet target Feature Feature No Browser OTA <code>start ota [ap]</code>; <code>stop ota</code> ESP32 browser uploader No No No WebConfig <code>start webconfig [ap]</code>; <code>stop webconfig</code>; <code>get/set webui</code> ESP32 WebConfig No No No WiFi <code>get/set wifi.ssid</code>; <code>set wifi.pwd</code>; <code>get wifi.status</code>; <code>get/set wifi.powersave</code> ESP32 WiFi No No No WiFi <code>get/set wifi.cli</code> ESP32 WebConfig No No No LoRa OTA <code>ota help</code>; <code>ota ?</code>; <code>ota h</code> LoRa OTA build No No Yes LoRa OTA <code>ota</code>; <code>ota status</code>; <code>ota st</code> LoRa OTA build No No Yes LoRa OTA <code>ota stats</code> LoRa OTA build No No Yes LoRa OTA <code>ota ls</code>; <code>ota neighbors</code>; <code>ota nbrs</code>; <code>ota updates</code>; <code>ota n</code> LoRa OTA build No No Yes LoRa OTA <code>ota get</code>; <code>ota pull</code>; <code>ota download</code> LoRa OTA build; internal-store nRF52 installs in-place deltas, while matched SD/QSPI nRF52 also accepts full images No No Yes LoRa OTA <code>ota install</code>; <code>ota apply</code>; <code>ota applydelta</code> Compatible bootloader and completed update No No Yes LoRa OTA <code>ota rescue install &lt;base_hash16&gt;</code> Legacy internal-flash nRF52 LoRa OTA build with failed app-side EndF validation; shared bootloader-update builds require valid EndF No No Feature LoRa OTA <code>ota bootloader</code>; <code>ota bootloader install &lt;MID8&gt; &lt;HASH16&gt;</code> Allowlisted internal-flash, XIAO-QSPI, or exact MeshTower V2 microSD nRF52 repeater with ABI-3 exact-board OTAFIX No No Feature LoRa OTA <code>ota cancel</code>; <code>ota drop</code>; <code>ota stop</code> LoRa OTA build No No Yes LoRa OTA <code>ota announce</code>; <code>ota adv</code> LoRa OTA build No No Yes LoRa OTA <code>ota self</code>; <code>ota id</code> Firmware with EndF trailer No No Yes LoRa OTA <code>ota qspi</code>; <code>ota storage</code> nRF52 build with raw-QSPI OTA staging Feature Feature Feature LoRa OTA <code>ota folder</code>; <code>ota fold</code> <code>on</code> needs compiled folder transport No No Feature LoRa OTA <code>ota config</code>; <code>ota cfg</code>; <code>ota set</code> LoRa OTA build No No Yes LoRa OTA <code>ota key</code>; <code>ota keys</code> LoRa OTA build No No Yes LoRa OTA <code>ota dev ...</code> Developer diagnostics No No Yes MQTT <code>get/set mqttN.preset</code> MQTT observer No No No MQTT <code>get/set mqttN.server</code>; <code>get/set mqttN.port</code>; <code>get/set mqttN.username</code>; <code>get/set mqttN.password</code> MQTT observer No No No MQTT <code>get/set mqttN.token</code>; <code>get/set mqttN.topic</code>; <code>get/set mqttN.audience</code> MQTT observer No No No MQTT <code>get mqttN.diag</code> MQTT observer No No No MQTT <code>get/set mqtt.origin</code>; <code>get/set mqtt.iata</code>; <code>get mqtt.presets</code> MQTT observer No No No MQTT <code>get mqtt.stats</code> MQTT observer No No No MQTT <code>get/set mqtt.status</code>; <code>get/set mqtt.packets</code>; <code>get/set mqtt.raw</code>; <code>get/set mqtt.interval</code> MQTT observer No No No MQTT <code>get/set mqtt.rx</code>; <code>get/set mqtt.tx</code> MQTT observer No No No MQTT <code>get/set mqtt.neighbors</code>; <code>get/set mqtt.neighbors.interval</code> MQTT observer with compiled neighbor support No No No MQTT <code>get/set mqtt.ntp</code> MQTT observer No No No MQTT <code>get mqtt.ntp.diag</code> Full MQTT observer No No No MQTT <code>get/set timezone</code>; <code>get/set timezone.offset</code> MQTT observer No No No MQTT <code>get/set mqtt.analyzer.us</code>; <code>get/set mqtt.analyzer.eu</code> Legacy MQTT aliases No No No MQTT <code>get/set mqtt.owner</code>; <code>get/set mqtt.email</code> MQTT observer; <code>get</code> is local serial only No No No MQTT <code>get mqtt.config.valid</code> MQTT observer No No No SNMP <code>get/set snmp</code>; <code>get/set snmp.community</code> MQTT target compiled with SNMP No No No Alerts <code>get/set alert</code>; <code>get/set alert.psk</code>; <code>get/set alert.hashtag</code>; <code>get/set alert.region</code>; <code>get/set alert.wifi</code>; <code>get/set alert.mqtt</code>; <code>get/set alert.interval</code> MQTT observer No No No Alerts <code>alert test [message]</code> MQTT observer with configured alert channel No No No TLS <code>tls.bundletest &lt;host&gt;</code> MQTT target with embedded certificate bundle No No No Manifest OTA <code>ota check</code> MQTT target with <code>OTA_MANIFEST_BASE</code> No No No Manifest OTA <code>ota update</code> MQTT target with <code>OTA_MANIFEST_BASE</code> No No No"},{"location":"cli_command_availability/#esp32","title":"ESP32","text":"Area Command Scope Standard Logging LoRa OTA FULL unified FULL fallback Operational <code>reboot</code> All text CLI roles Yes Yes Yes Yes Yes Operational <code>poweroff</code>; <code>shutdown</code> Board power-off support Yes Yes Yes Yes Yes Operational <code>uf2reset</code> nRF52 only No No No No No Operational <code>clkreboot</code> Full parser Yes Yes Yes Yes Yes Operational <code>clock sync</code> All text CLI roles Yes Yes Yes Yes Yes Operational <code>clock</code> All text CLI roles Yes Yes Yes Yes Yes Operational <code>time &lt;epoch_seconds&gt;</code> Clock only moves forward Yes Yes Yes Yes Yes Operational <code>advert</code> Advert-capable role Yes Yes Yes Yes Yes Operational <code>advert.zerohop</code> Advert-capable role Yes Yes Yes Yes Yes Operational <code>erase</code> Local serial Serial Serial Serial Serial Serial Display <code>get/set display.timeout</code>; <code>get/set display.flip</code> MQTT observer with display; flip needs a supported driver No No No Feature No Information <code>ver</code> All text CLI roles Yes Yes Yes Yes Yes Information <code>board</code> All text CLI roles Yes Yes Yes Yes Yes Diagnostics <code>get storage.layout</code> Detected flash size and live partition table Yes Yes Yes Yes Yes Diagnostics <code>memory</code> ESP32 heap and PSRAM summary Yes Yes Yes Yes Yes Diagnostics <code>sensor</code> Hardware wiring summary Yes Yes Yes Yes Yes Diagnostics <code>powerlog</code> Reset-reason summary Yes Yes Yes Yes Yes Neighbors <code>neighbors</code> Role with a neighbor table Yes Yes Yes Yes Yes Neighbors <code>neighbor.remove &lt;pubkey_prefix&gt;</code> Role with a mutable neighbor table Yes Yes Yes Yes Yes Neighbors <code>discover.neighbors</code> Repeater; some MQTT room servers Yes Yes Yes Yes Yes Neighbors <code>discover.scopes</code> MQTT observer with compiled neighbor support No No No Feature No Statistics <code>clear stats</code> Full parser Yes Yes Yes Yes Yes Statistics <code>stats-core</code> Local serial Serial Serial Serial Serial Serial Statistics <code>stats-radio</code> Local serial Serial Serial Serial Serial Serial Statistics <code>stats-radio-diag</code> Local serial Serial Serial Serial Serial Serial Statistics <code>stats-packets</code> Local serial Serial Serial Serial Serial Serial Statistics <code>get telemetry.temp/volt/volt.i2c</code>; optional GPS history Non-STM32 repeater or room server; I2C command requires a detected voltage monitor; GPS requires a provider; remote access requires administrator Yes Yes Yes Yes Yes Statistics <code>set telemetry.gps</code>; <code>get/set/send telemetry.tx</code> Non-STM32 repeater; GPS setting requires a provider; remote access requires administrator Yes Yes Yes Yes Yes Logging <code>log start</code>; <code>log stop</code>; <code>log erase</code> Storage-backed roles retain data Yes Yes Yes Yes Yes Logging <code>log</code> Local serial Serial Serial Serial Serial Serial Logging <code>get/set usb.logging</code>; unified FULL <code>get/set logging.output</code> Ordinary safe-USB artifacts; CommonCLI USB gate is persistent; unified ESP32 FULL selects off/USB/WiFi/both; every ESP32 Full Companion uses an input-capable single-TTY logging terminal with framed USB Companion disabled while logging Yes Yes No No Yes Radio <code>get radio</code>; <code>set radio ...</code> All text CLI roles Yes Yes Yes Yes Yes Radio <code>get tx</code>; <code>set tx &lt;dbm&gt;</code> Board TX-power limits apply Yes Yes Yes Yes Yes Radio <code>tempradio ...</code>; <code>normalradio</code> Full parser Yes Yes Yes Yes Yes Radio <code>get/set/del radioat</code>; <code>get/set/del tempradioat</code> Full parser Yes Yes Yes Yes Yes Radio <code>get freq</code>; <code>set freq &lt;mhz&gt;</code> <code>set</code> is local serial only Yes Yes Yes Yes Yes Radio <code>get/set radio.rxgain</code> Supported radio Feature Feature Feature Feature Feature Radio <code>get/set espnow.channel</code> Primary ESP-NOW mesh radio Feature Feature Feature Feature Feature Radio <code>get/set radio.fem.rxgain</code> Controllable LoRa FEM Feature Feature Feature Feature Feature Radio <code>get/set radio.fem.txgain</code> Controllable LoRa FEM Feature Feature Feature Feature Feature Radio <code>get/set radio.rxps</code>; <code>get rxps.wd</code> Full parser and RX power-saving support Feature Feature Feature Feature Feature System <code>get/set name</code> All full-parser text CLI roles Yes Yes Yes Yes Yes System <code>get/set lat</code> All full-parser text CLI roles Yes Yes Yes Yes Yes System <code>get/set lon</code> All full-parser text CLI roles Yes Yes Yes Yes Yes System <code>get/set prv.key</code> <code>get</code> is local serial only Yes Yes Yes Yes Yes System <code>password &lt;new_password&gt;</code> Administrator Yes Yes Yes Yes Yes System <code>get/set guest.password</code> Role with guest administration Yes Yes Yes Yes Yes System <code>get/set owner.info</code> Full parser Yes Yes Yes Yes Yes System <code>get/set adc.multiplier</code> Board ADC override support Feature Feature Feature Feature Feature System <code>send text.flood &lt;message&gt;</code> Repeater Yes Yes Yes Yes Yes System <code>host &lt;text&gt;</code>; <code>get host</code> Repeater with host bridge; <code>host</code> requires a remote administrator and a USB/MQTT service Yes Yes Yes Yes Yes System <code>get/set battery.alert</code>; <code>get battery.alert.region</code> Repeater Yes Yes Yes Yes Yes System <code>get/set battery.alert.low</code>; <code>get/set battery.alert.critical</code> Repeater Yes Yes Yes Yes Yes System <code>get/set rx.watchdog</code> Repeater Yes Yes Yes Yes Yes System <code>get/set system.watchdog</code> nRF52 only No No No No No System <code>get public.key</code> Full parser Yes Yes Yes Yes Yes System <code>get role</code> All text CLI roles Yes Yes Yes Yes Yes System <code>powersaving</code>; <code>powersaving on/off</code> Supported repeater board Feature Feature Feature Feature Feature System <code>get/set reboot.interval</code> Full parser Yes Yes Yes Yes Yes Clock sync <code>get/set clock.sync.*</code>; <code>clock.sync.mesh now</code> Repeater, sensor, and room server; <code>clock.sync.internet</code> needs MQTT repeater Yes Yes Yes Yes Yes Routing <code>get/set repeat</code> Forwarding-capable role Yes Yes Yes Yes Yes Routing <code>get/set path.hash.mode</code> Full parser Yes Yes Yes Yes Yes Routing <code>get/set loop.detect</code> Repeater, full common parser Yes Yes Yes Yes Yes Routing <code>get/set txdelay</code> All text CLI roles, including bridges Yes Yes Yes Yes Yes Routing <code>get/set direct.txdelay</code> Full parser Yes Yes Yes Yes Yes Routing <code>get/set rxdelay</code> All text CLI roles, including bridges Yes Yes Yes Yes Yes Routing <code>get/set dutycycle</code> Full parser Yes Yes Yes Yes Yes Routing <code>get/set af</code> Full parser Yes Yes Yes Yes Yes Routing <code>get/set int.thresh</code> All text CLI roles Yes Yes Yes Yes Yes Routing <code>get/set cad</code> Radio CAD support Feature Feature Feature Feature Feature Routing <code>get/set agc.reset.interval</code> All text CLI roles Yes Yes Yes Yes Yes Routing <code>get/set radio.watchdog</code> MQTT observer No No No Yes No Routing <code>get/set multi.acks</code> Full parser Yes Yes Yes Yes Yes Routing <code>get/set flood.advert.interval</code> Repeater, full common parser Yes Yes Yes Yes Yes Routing <code>get/set advert.interval</code> Full common parser Yes Yes Yes Yes Yes Routing <code>get/set flood.max</code> Repeater, full common parser Yes Yes Yes Yes Yes Routing <code>get/set flood.max.unscoped</code> Repeater, full common parser Yes Yes Yes Yes Yes Routing <code>get/set flood.max.advert</code> Repeater, full common parser Yes Yes Yes Yes Yes Routing <code>get/set flood.channel.data</code>; <code>get/set flood.channel.data.hops</code> Repeater, full common parser Yes Yes Yes Yes Yes Routing <code>get/set/del flood.channel.scope*</code> Repeater role handler Yes Yes Yes Yes Yes Routing <code>get/set/del flood.channel.scope.require*</code> Repeater role handler Yes Yes Yes Yes Yes Routing <code>get/set/del flood.rule*</code>; <code>get/set/del flood.filter*</code>; <code>get/set/del flood.filter.blacklist*</code> Repeater role handler; <code>flood.rule</code>/<code>flood.filter</code> also on FULL ESP32 room server (no blacklist) Yes Yes Yes Yes Yes Routing <code>get/set/del flood.moderation*</code> Repeater role handler Yes Yes Yes Yes Yes Routing <code>get/set outpath</code> Repeater remote-client context Yes Yes Yes Yes Yes Routing <code>get/set altpath</code> Repeater remote-client context Yes Yes Yes Yes Yes ACL <code>setperm &lt;pubkey&gt; &lt;permissions&gt;</code> Repeater, room server, or sensor Yes Yes Yes Yes Yes ACL <code>get acl</code> Local serial Serial Serial Serial Serial Serial ACL <code>get/set allow.read.only</code> Room server Yes Yes No Yes Yes Regions <code>region load</code>; <code>region save</code> Role with region storage Yes Yes Yes Yes Yes Regions <code>region allowf</code>; <code>region denyf</code> Role with region storage Yes Yes Yes Yes Yes Regions <code>region get</code>; <code>region list</code>; <code>region</code> Role with region storage Yes Yes Yes Yes Yes Regions <code>region home</code>; <code>region default</code> Role with region storage Yes Yes Yes Yes Yes Regions <code>region put</code>; <code>region def</code>; <code>region remove</code> Role with region storage Yes Yes Yes Yes Yes Retry <code>get/set direct.retry</code>; <code>get/set direct.retry.heard</code> Role with basic retry support Yes Yes Yes Yes Yes Retry <code>get/set retry.preset</code> Role with retry support Yes Yes Yes Yes Yes Retry <code>get/set flood.retry.count</code>; <code>get/set flood.retry.path</code>; <code>get/set flood.retry.group.path</code> Repeater Yes Yes Yes Yes Yes Retry <code>get/set flood.retry.advert</code>; <code>get/set flood.retry.prefixes</code>; <code>get/set flood.retry.ignore</code> Repeater Yes Yes Yes Yes Yes Retry <code>get/set flood.retry.bridge</code>; <code>get/set flood.retry.bucket</code> Repeater bridge retry support Feature Feature Feature Feature Feature Retry <code>get/set direct.retry.count</code>; <code>get/set direct.retry.base</code>; <code>get/set direct.retry.step</code> Role with retry support Yes Yes Yes Yes Yes Retry <code>get/set direct.retry.margin</code>; <code>get/set direct.retry.cr</code> Role with retry support Yes Yes Yes Yes Yes Retry <code>get/set/clear recent.repeater</code>; <code>get recent.repeaters</code> Repeater Yes Yes Yes Yes Yes GPS <code>gps</code>; <code>gps on/off</code> Compiled onboard GPS Feature Feature Feature Feature Feature GPS <code>gps sync</code> Compiled onboard GPS Feature Feature Feature Feature Feature GPS <code>gps setloc</code> Compiled onboard GPS Feature Feature Feature Feature Feature GPS <code>gps advert [none/share/prefs]</code> Compiled onboard GPS Feature Feature Feature Feature Feature Sensors <code>get/set telemetry.access</code> Sensor-capable full parser Feature Feature Limited Feature Feature Sensors <code>sensor list [start]</code> Compiled sensor manager; <code>no_external_sensors</code> trims target-selected environmental/ranging drivers, not generic I2C Feature Feature Limited Feature Feature Sensors <code>sensor get</code>; <code>sensor set</code> Compiled sensor setting; <code>no_external_sensors</code> trims target-selected environmental/ranging drivers, not generic I2C Feature Feature Limited Feature Feature Sensors <code>io [r/s/t]&lt;hex&gt;</code> Simple sensor role with board GPIO support Feature Feature No No Feature Bridge <code>get bridge.type</code> Compiled bridge Feature Feature Feature Yes Feature Bridge <code>get/set bridge.enabled</code>; <code>get bridge.running</code> Compiled bridge Feature Feature Feature Yes Feature Bridge <code>get/set bridge.delay</code> Compiled bridge Feature Feature Feature Yes Feature Bridge <code>get/set bridge.source</code> Compiled bridge Feature Feature Feature Yes Feature Bridge <code>get/set bridge.baud</code> RS-232 bridge Feature Feature Feature No Feature Bridge <code>get/set bridge.uart</code> RS-232 bridge Feature Feature Feature No Feature Bridge <code>get/set bridge.channel</code> ESP-NOW bridge No No No Feature Feature Bridge <code>get/set bridge.format</code> ESP-NOW bridge No No No Feature Feature Bridge <code>get/set bridge.secret</code> ESP-NOW bridge No No No Feature Feature Board <code>get bootloader.ver</code> nRF52 only No No No No No Board <code>get pwrmgt.support</code>; <code>get pwrmgt.source</code>; <code>get pwrmgt.bootreason</code>; <code>get pwrmgt.bootmv</code> nRF52 only No No No No No Ethernet <code>eth.status</code> Ethernet target Feature Feature No No Feature Browser OTA <code>start ota [ap]</code>; <code>stop ota</code> Compiled browser uploader No No Yes Feature Feature WebConfig <code>start webconfig [ap]</code>; <code>stop webconfig</code>; <code>get/set webui</code> Compiled WebConfig No No No Feature Feature WiFi <code>get/set wifi.ssid</code>; <code>set wifi.pwd</code>; <code>get wifi.status</code>; <code>get/set wifi.powersave</code> MQTT WiFi, or standalone FULL WebConfig; standalone has no <code>get wifi.pwd</code> No No No Yes Feature WiFi <code>get/set wifi.cli</code> Compiled WebConfig No No No Feature Feature LoRa OTA <code>ota help</code>; <code>ota ?</code>; <code>ota h</code> LoRa OTA build No No Yes Yes Yes LoRa OTA <code>ota</code>; <code>ota status</code>; <code>ota st</code> LoRa OTA build No No Yes Yes Yes LoRa OTA <code>ota stats</code> LoRa OTA build No No Yes Yes Yes LoRa OTA <code>ota ls</code>; <code>ota neighbors</code>; <code>ota nbrs</code>; <code>ota updates</code>; <code>ota n</code> LoRa OTA build No No Yes Yes Yes LoRa OTA <code>ota get</code>; <code>ota pull</code>; <code>ota download</code> LoRa OTA build No No Yes Yes Yes LoRa OTA <code>ota install</code>; <code>ota apply</code>; <code>ota applydelta</code> Compatible completed update No No Yes Yes Yes LoRa OTA <code>ota rescue install &lt;base_hash16&gt;</code> Legacy internal-flash nRF52 LoRa OTA build with failed app-side EndF validation; shared bootloader-update builds require valid EndF No No Feature No No LoRa OTA <code>ota bootloader</code>; <code>ota bootloader install &lt;MID8&gt; &lt;HASH16&gt;</code> Allowlisted nRF52 internal/QSPI repeater feature No No No No No LoRa OTA <code>ota cancel</code>; <code>ota drop</code>; <code>ota stop</code> LoRa OTA build No No Yes Yes Yes LoRa OTA <code>ota announce</code>; <code>ota adv</code> LoRa OTA build No No Yes Yes Yes LoRa OTA <code>ota self</code>; <code>ota id</code> Firmware with EndF trailer No No Yes Yes Yes LoRa OTA <code>ota qspi</code>; <code>ota storage</code> nRF52 build with raw-QSPI OTA staging No No No No No LoRa OTA <code>ota folder</code>; <code>ota fold</code> <code>on</code> needs compiled serial or TCP folder transport No No Feature Feature Feature LoRa OTA <code>ota config</code>; <code>ota cfg</code>; <code>ota set</code> LoRa OTA build No No Yes Yes Yes LoRa OTA <code>ota key</code>; <code>ota keys</code> LoRa OTA build No No Yes Yes Yes LoRa OTA <code>ota dev ...</code> Developer diagnostics No No Yes Yes Yes MQTT <code>get/set mqttN.preset</code> MQTT observer No No No Yes No MQTT <code>get/set mqttN.server</code>; <code>get/set mqttN.port</code>; <code>get/set mqttN.username</code>; <code>get/set mqttN.password</code> MQTT observer No No No Yes No MQTT <code>get/set mqttN.token</code>; <code>get/set mqttN.topic</code>; <code>get/set mqttN.audience</code> MQTT observer No No No Yes No MQTT <code>get mqttN.diag</code> MQTT observer No No No Yes No MQTT <code>get/set mqtt.origin</code>; <code>get/set mqtt.iata</code>; <code>get mqtt.presets</code> MQTT observer No No No Yes No MQTT <code>get mqtt.stats</code> MQTT observer No No No Yes No MQTT <code>get/set mqtt.status</code>; <code>get/set mqtt.packets</code>; <code>get/set mqtt.raw</code>; <code>get/set mqtt.interval</code> MQTT observer No No No Yes No MQTT <code>get/set mqtt.rx</code>; <code>get/set mqtt.tx</code> MQTT observer No No No Yes No MQTT <code>get/set mqtt.neighbors</code>; <code>get/set mqtt.neighbors.interval</code> MQTT observer with compiled neighbor support No No No Feature No MQTT <code>get/set mqtt.ntp</code> MQTT observer No No No Yes No MQTT <code>get mqtt.ntp.diag</code> MQTT observer No No No Yes No MQTT <code>get/set timezone</code>; <code>get/set timezone.offset</code> MQTT observer No No No Yes No MQTT <code>get/set mqtt.analyzer.us</code>; <code>get/set mqtt.analyzer.eu</code> Legacy MQTT aliases No No No Yes No MQTT <code>get/set mqtt.owner</code>; <code>get/set mqtt.email</code> MQTT observer; <code>get</code> is local serial only No No No Yes No MQTT <code>get mqtt.config.valid</code> MQTT observer No No No Yes No SNMP <code>get/set snmp</code>; <code>get/set snmp.community</code> MQTT target compiled with SNMP No No No Feature No Alerts <code>get/set alert</code>; <code>get/set alert.psk</code>; <code>get/set alert.hashtag</code>; <code>get/set alert.region</code>; <code>get/set alert.wifi</code>; <code>get/set alert.mqtt</code>; <code>get/set alert.interval</code> MQTT observer No No No Yes No Alerts <code>alert test [message]</code> MQTT observer with configured alert channel No No No Yes No TLS <code>tls.bundletest &lt;host&gt;</code> MQTT target with embedded certificate bundle No No No Feature No Manifest OTA <code>ota check</code> MQTT target with <code>OTA_MANIFEST_BASE</code> No No No Manifest No Manifest OTA <code>ota update</code> MQTT target with <code>OTA_MANIFEST_BASE</code> No No No Manifest No"},{"location":"cli_command_availability/#supplemental-command-notes","title":"Supplemental command notes","text":"<p>These short entries cover implemented commands that do not yet have their own section in the primary command reference.</p>"},{"location":"cli_command_availability/#memory","title":"<code>memory</code>","text":"<p>ESP32 only. Prints free heap, minimum heap, largest allocation, queue depth, internal heap, and PSRAM totals.</p>"},{"location":"cli_command_availability/#sensor-hardware-summary","title":"<code>sensor</code> hardware summary","text":"<p>Prints the configured I2C pins and GPS serial pins. This is a wiring/build diagnostic, distinct from <code>sensor list</code>, <code>sensor get</code>, and <code>sensor set</code>.</p>"},{"location":"cli_command_availability/#powerlog","title":"<code>powerlog</code>","text":"<p>Prints the last reset reason. nRF52 also prints the captured shutdown reason and boot voltage.</p>"},{"location":"cli_command_availability/#stats-radio-diag","title":"<code>stats-radio-diag</code>","text":"<p>Local-serial diagnostic that prints the extended radio diagnostic counters.</p> <p></p>"},{"location":"cli_command_availability/#radiorxps-and-rxpswd","title":"<code>radio.rxps</code> and <code>rxps.wd</code>","text":"<p><code>get radio.rxps</code> reports RX power-saving state and timing. <code>set radio.rxps ...</code> changes that configuration. <code>get rxps.wd</code> reports the soft and hard RX power-saving watchdog counters.</p> <p></p>"},{"location":"cli_command_availability/#rebootinterval","title":"<code>reboot.interval</code>","text":"<p><code>get reboot.interval</code> shows the scheduled reboot interval. Use <code>set reboot.interval &lt;hours&gt;</code> for 1-255 hours, or <code>set reboot.interval 0</code> to disable it.</p> <p></p>"},{"location":"cli_command_availability/#sensor-io","title":"Sensor <code>io</code>","text":"<p>The simple-sensor role exposes its board GPIO word as hexadecimal. <code>io</code> reads it; <code>io &lt;hex&gt;</code> replaces it; and <code>io r&lt;hex&gt;</code>, <code>io s&lt;hex&gt;</code>, or <code>io t&lt;hex&gt;</code> clear, set, or toggle selected bits.</p> <p></p>"},{"location":"cli_command_availability/#get-mqttndiag","title":"<code>get mqttN.diag</code>","text":"<p>Prints the runtime diagnostic summary for MQTT slot N, including its connection state and failure history.</p> <p></p>"},{"location":"cli_command_availability/#get-mqttstats","title":"<code>get mqtt.stats</code>","text":"<p>Prints the MQTT bridge runtime statistics summary.</p> <p></p>"},{"location":"cli_command_availability/#get-mqttconfigvalid","title":"<code>get mqtt.config.valid</code>","text":"<p>Reports whether the saved MQTT configuration has the minimum values needed to run.</p> <p></p>"},{"location":"cli_command_availability/#tlsbundletest","title":"<code>tls.bundletest</code>","text":"<p><code>tls.bundletest &lt;host[:port]|url&gt;</code> tests the embedded TLS certificate bundle against a remote host without changing the MQTT configuration.</p> <p></p>"},{"location":"cli_command_availability/#manifest-ota-check-and-ota-update","title":"Manifest <code>ota check</code> and <code>ota update</code>","text":"<p>On MQTT targets with <code>OTA_MANIFEST_BASE</code>, <code>ota check</code> fetches and checks the target manifest. <code>ota update</code> downloads and applies the compatible update selected by that manifest.</p>"},{"location":"cli_commands/","title":"CLI Commands","text":"<p>This document provides an overview of CLI commands that can be sent to MeshCore Repeaters, Room Servers and Sensors.</p> <p>See CLI Availability by Firmware Build for the role and profile matrix, including the commands intentionally omitted from portable firmware.</p> <p>See CLI Command Availability Matrix for the command-by-command nRF52 and ESP32 build tables.</p> <p>The first word of a command is case-insensitive, so <code>set</code>, <code>Set</code>, and <code>SET</code> are equivalent, as are <code>get</code>, <code>Get</code>, and the other command verbs. The case of arguments such as node names, passwords, and keys is left unchanged.</p>"},{"location":"cli_commands/#navigation","title":"Navigation","text":"<ul> <li>Operational</li> <li>Neighbors</li> <li>Statistics</li> <li>Logging</li> <li>Information</li> <li>Configuration</li> <li>Radio</li> <li>System<ul> <li>GPIO</li> </ul> </li> <li>Routing</li> <li>Flood Rules</li> <li>Group Text Moderation</li> <li>ACL</li> <li>Region Management<ul> <li>Region Examples</li> </ul> </li> <li>GPS</li> <li>Sensors</li> <li>Bridge</li> <li>Ethernet</li> </ul>"},{"location":"cli_commands/#operational","title":"Operational","text":""},{"location":"cli_commands/#reboot-the-node","title":"Reboot the node","text":"<p>Usage:  - <code>reboot</code></p> <p>Note: No reply is sent.</p>"},{"location":"cli_commands/#power-off-the-node","title":"Power-off the node","text":"<p>Usage: - <code>poweroff</code>, or - <code>shutdown</code></p> <p>Note: No reply is sent.</p>"},{"location":"cli_commands/#enter-the-uf2-bootloader-nrf52-only","title":"Enter the UF2 bootloader (nRF52 only)","text":"<p>Usage: - <code>uf2reset</code></p> <p>Serial Only: Yes</p> <p>Note: Reboots directly into the UF2 bootloader on supported nRF52 boards. This includes the Repeater, Room Server, Sensor, Companion, and Terminal Chat local serial command surfaces. It is never accepted as a remote mesh command.</p>"},{"location":"cli_commands/#reset-the-clock-and-reboot","title":"Reset the clock and reboot","text":"<p>Usage: - <code>clkreboot</code></p> <p>Note: No reply is sent.</p>"},{"location":"cli_commands/#sync-the-clock-with-the-remote-device","title":"Sync the clock with the remote device","text":"<p>Usage:  - <code>clock sync</code></p>"},{"location":"cli_commands/#display-current-time-in-utc","title":"Display current time in UTC","text":"<p>Usage: - <code>clock</code></p>"},{"location":"cli_commands/#set-the-time-to-a-specific-timestamp","title":"Set the time to a specific timestamp","text":"<p>Usage:  - <code>time &lt;epoch_seconds&gt;</code></p> <p>Parameters: - <code>epoch_seconds</code>: Unix epoch time</p>"},{"location":"cli_commands/#send-a-flood-advert","title":"Send a flood advert","text":"<p>Usage:  - <code>advert</code></p>"},{"location":"cli_commands/#send-a-zero-hop-advert","title":"Send a zero-hop advert","text":"<p>Usage: - <code>advert.zerohop</code></p>"},{"location":"cli_commands/#ask-a-usb-connected-host-service-over-lora-repeater-only","title":"Ask a USB-connected host service over LoRa (Repeater Only)","text":"<p>Usage:</p> <ul> <li><code>host &lt;text&gt;</code> - authenticated remote administrator only</li> <li><code>get host</code> - show bridge state and byte limits</li> </ul> <p><code>host</code> hands one remote LoRa CLI request to a service on the repeater's USB host and returns that service's reply over LoRa. It does not execute the text inside the firmware. The service has 4 seconds to prove the exact request is still pending, then 6 seconds to execute and reply. A second remote command receives busy while either phase is pending.</p> <p>Request text is limited to 155 UTF-8 bytes, or 152 bytes when a companion uses its legacy three-byte correlation prefix. The complete LoRa reply is limited to 162 bytes. USB records use Base64URL text, a random 64-bit nonce, and the repeater identity's Ed25519 signature. Before executing anything, the service must return a random one-time challenge and receive the repeater's signed live proof. This avoids any dependency on repeater/Pi clock agreement. Every <code>host.reply</code> USB command must carry the matching request ID and nonce; it is not accepted from LoRa or the Ethernet CLI.</p> <p>The included Raspberry Pi endpoint supports exact commands for <code>help</code>, <code>cpu-temp</code>, <code>hostname</code>, <code>uptime</code>, <code>load</code>, <code>memory</code>, <code>disk-free</code>, and <code>clock status</code>. It also provides strictly validated <code>clock sync</code> and <code>clock set &lt;unix_epoch&gt;</code> recovery actions, opt-in <code>network restart</code> and <code>reboot</code> actions, <code>action status &lt;operation_id&gt;</code>, and <code>run &lt;alias&gt; [arguments]</code> for locally allowlisted executables with typed arguments. Clock changes and host recovery actions are disabled by default, arbitrary executables are never accepted, and no action uses a shell. Clock set accepts only canonical unsigned decimal epochs from 2020 through 2099; a root-owned Unix-socket service revalidates the request and authenticates the local service account with <code>SO_PEERCRED</code> before changing system time. Network restart and reboot use a separate root-owned Unix-socket broker with fixed systemd units; installing clock control does not grant those actions. The endpoint never uses <code>sudo</code> for privileged host actions. See LoRa CLI host service for the complete <code>meshcoretomqtt</code> setup and security model.</p>"},{"location":"cli_commands/#start-or-stop-an-over-the-air-ota-firmware-update","title":"Start or stop an Over-The-Air (OTA) firmware update","text":"<p>Usage: - <code>start ota</code> - <code>start ota ap</code> - <code>stop ota</code></p> <p><code>start ota</code> serves the web upload page on the station IP when connected to WiFi; otherwise it raises the <code>MeshCore-OTA</code> access point. <code>start ota ap</code> always raises the access point, which is useful when the normal network uses client isolation.</p> <p>On an ESP32 build with WebConfig, the manual OTA uploader and WebConfig both use HTTP port 80 and cannot run together. Stop WebConfig before <code>start ota</code>, or stop OTA before <code>start webconfig</code>.</p> <p>FULL ESP32 builds also expose the <code>.mota</code> folder seeder on TCP port 5001 whenever WiFi is usable. This listener is independent of port 80, so a host can run <code>motatool serve --dir ./motas --tcp &lt;node-ip&gt;:5001</code> while WebConfig is active. The TCP connection auto-attaches and detaches the folder; do not run <code>ota folder on</code> at the same time because that command selects the USB-serial folder transport.</p>"},{"location":"cli_commands/#browser-configuration-portal-esp32-repeater-and-room-server","title":"Browser configuration portal (ESP32 repeater and room server)","text":"<p>Usage:</p> <ul> <li><code>start webconfig</code></li> <li><code>start webconfig ap</code></li> <li><code>stop webconfig</code></li> <li><code>set webui on</code></li> <li><code>set webui off</code></li> <li><code>get webui</code></li> <li><code>get wifi.ssid</code></li> <li><code>get wifi.status</code></li> <li><code>get wifi.powersave</code></li> <li><code>get wifi.cli</code></li> <li><code>set wifi.ssid &lt;network name&gt;</code></li> <li><code>set wifi.pwd [password]</code></li> <li><code>set wifi.powersave &lt;none|min|max&gt;</code></li> <li><code>set wifi.cli &lt;on|off&gt;</code></li> </ul> <p><code>set webui on</code> is the persistent master switch. It starts the portal now and again after future reboots; <code>set webui off</code> closes it and disables that boot start. <code>get webui</code> reports the saved on/off state plus whether the portal is inactive, joining WiFi, serving a setup AP, or serving a LAN URL. The default is <code>off</code> on repeater and room-server builds. On display-equipped repeaters, an otherwise-unused triple click toggles the same saved setting. Consequently, <code>&gt; off, http://192.168.1.130/</code> means the saved boot setting is off while a temporary WebConfig session is currently active at that URL.</p> <p><code>start webconfig</code> is a temporary start that does not change the saved switch. It serves the shared WiFi, radio, flood, loop, and status page and reports its URL. MQTT builds also show the MQTT tab and wizard step; non-MQTT builds remove them entirely. Sign in with the node's admin password. If the node has no saved WiFi SSID, the command starts the open <code>MeshCore-Setup-XXXX</code> captive AP at http://192.168.4.1/ instead.</p> <p><code>start webconfig ap</code> forces captive-AP mode. It will not interrupt an active MQTT bridge, so run <code>set bridge.enabled off</code> first. Use <code>stop webconfig</code> to close either mode for the current boot. (<code>stop webconfig</code> does not change a saved <code>webui on</code>.) LAN mode otherwise remains active until reboot. On expanded FULL builds, an unconfigured automatic setup AP receives one absolute 30-minute window per boot, then powers WiFi off even if a client remains attached; rebooting starts a new automatic window. An administrator can explicitly run <code>start webconfig</code> again without rebooting. Once an SSID is saved, the cutoff no longer applies and the selected WiFi/MQTT mode keeps reconnecting. Other setup sessions retain their profile's idle timeout.</p> <p>The saved <code>wifi.cli</code> setting defaults to <code>on</code>. Use <code>set wifi.cli off</code> to disable the CLI tab. <code>get wifi.cli</code> reports <code>off</code>, <code>on, waiting for WiFi client</code>, or <code>on, active</code>. The saved setting becomes active only in station/LAN mode while the WiFi client is connected. It is deliberately unavailable on the open setup access point. The tab sends one command at a time through the local administrator command parser and displays the reply in the browser. It uses remote-administrator command permissions, so commands explicitly restricted to a physical serial connection remain unavailable. Select Command block to paste up to 100 commands with one command per line. Blank lines are ignored, and every nonblank line must fit the normal 159-byte CLI command limit. The browser sends the lines sequentially and waits for each reply before sending the next line. The queue exists only in that browser page; closing it stops any commands that have not yet been sent. A lost connection also stops the remaining block.</p> <p>Up/down arrow keys recall commands from the current browser session in single-command mode. A command that stops WebConfig, changes its WiFi connection, disables <code>wifi.cli</code>, or reboots the node stops the remaining block and can close the page before its reply is collected.</p> <p>On unified FULL USB + WiFi and FULL logging-fallback ESP32 repeater/room-server builds, <code>get wifi.ssid</code> reports the saved standalone WebConfig network and <code>get wifi.status</code> reports whether WiFi is unconfigured, off, connecting, running the setup AP, failed, or connected. A connected result includes the SSID, LAN IP, and RSSI. When the shared OTA seeder is running, the reply appends <code>OTA TCP 5001: listening</code> or <code>OTA TCP 5001: client connected</code>. WiFi being off is normal while WebConfig is inactive; run <code>start webconfig</code> when a temporary connection is wanted. <code>get wifi.powersave</code> reports the saved standalone setting as <code>none</code>, <code>min</code>, or <code>max</code>. Fresh Cascade-profile builds default to <code>min</code>; target-default builds use <code>none</code>. A saved setting takes precedence after an upgrade.</p> <p>The WiFi <code>set</code> commands work on MQTT observers and on FULL standalone ESP32 repeater/room-server builds. On a standalone build, changing the SSID or password stops an active WebConfig session; run <code>start webconfig</code> again to use the new credentials. <code>set wifi.pwd</code> with no value selects an open network. Standalone WiFi also accepts an exact 64-character hexadecimal WPA/WPA2 PSK; ordinary passphrases remain limited to 63 characters. Other 64-character values and all longer values are rejected. MQTT observer WiFi passwords retain their fixed 63-character limit. Power-save changes are applied immediately when WiFi is running and otherwise take effect on the next connection. <code>get wifi.pwd</code> is intentionally unavailable so the standalone password is never returned by the CLI.</p> <p>ESP32 WiFi Companion WebConfig exposes the same <code>wifi.powersave</code> values in its WiFi card. Every ESP32 WiFi Companion with WebConfig exposes the standalone <code>wifi.ssid</code>, <code>wifi.status</code>, <code>wifi.powersave</code>, <code>wifi.cli</code>, and WebConfig command families through its USB text terminal. Full Companion exposes the same role-specific terminal on TCP port 5002. Credential writes reply before restarting the WiFi station, so a TCP client should expect to reconnect at the new address; USB password input is masked. Binary Companion clients can use USB, BLE, or TCP port 5000 without the terminal-start token: send command <code>0x42</code> (<code>CMD_RUN_CLI_COMMAND</code>) followed by the same CLI text, such as <code>get wifi.powersave</code> or <code>set wifi.powersave min</code>. WiFi-only Companions accept all three modes. A Full Companion that runs BLE and infrastructure WiFi simultaneously rejects <code>none</code> because coexistence requires modem sleep. Companion device <code>powersaving</code> and LoRa <code>radio.rxps</code> remain independent. On an ESP32 Full Companion whose primary mesh radio is ESP-NOW, <code>max</code> is also unavailable: a station using maximum modem sleep can miss ESP-NOW broadcasts, which the access point does not buffer for it. A previously saved conflicting value is capped to and reported as <code>min</code>, and a new conflicting selection is rejected. The primary mesh radio also holds the ESP-IDF WiFi wake reference continuously so unsolicited ESP-NOW frames remain receivable; selecting <code>min</code> does not put that primary receiver to sleep.</p> <p>SenseCAP Indicator Full is the exclusive-secondary exception. On a WiFi-selected boot, LoRa accepts <code>none|min|max</code> and ESP-NOW accepts <code>none|min</code>. On a BLE-selected boot infrastructure WiFi is not started; LoRa accepts <code>min|max</code> for the saved WiFi setting, while ESP-NOW + BLE requires <code>min</code>. USB and the primary LoRa or ESP-NOW radio remain available in every mode.</p>"},{"location":"cli_commands/#view-or-change-the-primary-esp-nowwifi-channel","title":"View or change the primary ESP-NOW/WiFi channel","text":"<p>Usage:</p> <ul> <li><code>get espnow.channel</code></li> <li><code>set espnow.channel &lt;channel&gt;</code></li> </ul> <p>Parameters:</p> <ul> <li><code>channel</code>: Shared 2.4 GHz WiFi channel from <code>1</code> through <code>13</code>; choose one   permitted in your region and supported by the router.</li> </ul> <p>Default: <code>1</code></p> <p>This command is available when ESP-NOW is the node's primary mesh radio. The setting is persisted. A <code>set</code> reply reports that reboot is required; until reboot, the running ESP-NOW radio remains on its previous channel. On builds that also provide ordinary WiFi, its station and setup AP share that channel.</p> <p>After reboot, ESP-NOW, the setup AP, and the infrastructure-WiFi station use the selected channel. Every primary ESP-NOW node that must communicate with this node, plus the configured router's 2.4 GHz radio, must use the same fixed channel. WiFi power saving does not allow the transports to use different channels. On an ESP32 Full build with primary ESP-NOW, <code>wifi.powersave max</code> is unavailable because maximum modem sleep can miss ESP-NOW broadcasts; use <code>min</code> for coexistence. The firmware keeps the primary ESP-NOW receiver awake while still using the <code>min</code> WiFi/Bluetooth coexistence policy.</p> <p><code>espnow.channel</code> is the channel of the primary ESP-NOW mesh transport. It is separate from <code>bridge.channel</code>, which configures only an ESP-NOW bridge on a firmware role whose primary mesh radio is LoRa.</p> <p>The browser portal is not compiled into the two 4 MB <code>LilyGo_TLora_V2_1_1_6_*_observer_mqtt</code> targets because it does not fit while retaining the two app slots required for LoRa OTA. Their normal CLI settings remain available.</p>"},{"location":"cli_commands/#erasefactory-reset","title":"Erase/Factory Reset","text":"<p>Usage: - <code>erase</code></p> <p>Serial Only: Yes</p> <p>Warning: This is destructive!</p>"},{"location":"cli_commands/#neighbors-repeater-only","title":"Neighbors (Repeater Only)","text":""},{"location":"cli_commands/#list-nearby-neighbors","title":"List nearby neighbors","text":"<p>Usage:  - <code>neighbors</code></p> <p>Note: The output of this command is limited to the 8 most recent adverts.</p> <p>Note: Each line is encoded as <code>{pubkey-prefix}:{timestamp}:{snr*4}</code></p>"},{"location":"cli_commands/#remove-a-neighbor","title":"Remove a neighbor","text":"<p>Usage:  - <code>neighbor.remove &lt;pubkey_prefix&gt;</code></p> <p>Parameters:  - <code>pubkey_prefix</code>: The public key of the node to remove from the neighbors list</p>"},{"location":"cli_commands/#discover-zero-hop-neighbors","title":"Discover zero hop neighbors","text":"<p>Usage:  - <code>discover.neighbors</code></p> <p>This command is available in every repeater build profile, including portable MQTT, standard, logging, OTA, unified FULL, and FULL logging-fallback artifacts. It does not require MQTT or PSRAM.</p>"},{"location":"cli_commands/#discover-neighbor-scopes-mqtt-observer-neighbors-feature","title":"Discover neighbor scopes (MQTT observer, neighbors feature)","text":"<p>Refreshes the zero-hop neighbor table, then queries each neighbor for its region scopes and publishes the assembled table to the MQTT <code>neighbors</code> topic once.</p> <p>Usage: - <code>discover.scopes</code></p> <p>Note: Requires an MQTT observer build with the neighbors feature compiled in (all PSRAM boards, plus non-PSRAM boards built with <code>MQTT_NEIGHBORS_WITHOUT_PSRAM</code>). Elsewhere it replies <code>Err - neighbors not enabled in this build</code>. If a <code>discover.neighbors</code> refresh is already in flight, the scope pass is queued behind it.</p>"},{"location":"cli_commands/#statistics","title":"Statistics","text":""},{"location":"cli_commands/#clear-stats","title":"Clear Stats","text":"<p>Usage: <code>clear stats</code></p> <p></p>"},{"location":"cli_commands/#system-stats-battery-uptime-queue-length-and-debug-flags","title":"System Stats - Battery, Uptime, Queue Length and Debug Flags","text":"<p>Usage:  - <code>stats-core</code></p> <p>Serial Only: Yes</p> <p></p>"},{"location":"cli_commands/#radio-stats-noise-floor-last-rssisnr-airtime-receive-errors","title":"Radio Stats - Noise floor, Last RSSI/SNR, Airtime, Receive errors","text":"<p>Usage: <code>stats-radio</code></p> <p>Serial Only: Yes</p> <p></p>"},{"location":"cli_commands/#packet-stats-packet-counters-received-sent","title":"Packet stats - Packet counters: Received, Sent","text":"<p>Usage: <code>stats-packets</code></p> <p>Serial Only: Yes</p> <p></p>"},{"location":"cli_commands/#read-repeater-and-room-server-telemetry-history","title":"Read repeater and room-server telemetry history","text":"<p>Repeater and room-server firmware record one UTC-aligned sample every 30 minutes. Temperature and battery voltage retain 336 samples (seven rolling days). Each detected INA219, INA226, INA260, or INA3221 voltage channel retains 192 samples (four rolling days). GPS-capable builds retain three GPS days by default; repeaters request a seven-day default at startup. Builds without a GPS provider omit the GPS history commands to conserve flash. All history and any runtime retention change are held in RAM and reset after a reboot.</p> <p>The feature is omitted from flash-constrained STM32 repeater and room images.</p> <p>Usage:</p> <ul> <li><code>get telemetry.temp [page]</code></li> <li><code>get telemetry.volt [page]</code></li> <li><code>get telemetry.volt.i2c [channel [page]]</code></li> <li><code>get telemetry.gps [page]</code></li> <li><code>set telemetry.gps &lt;days&gt;</code></li> <li><code>get telemetry.tx</code></li> <li><code>set telemetry.tx &lt;off|direct|path&gt;</code></li> <li><code>set telemetry.tx schedule &lt;off|1-30d&gt;</code></li> <li><code>send telemetry.tx now</code></li> </ul> <p>Parameters:</p> <ul> <li><code>page</code>: Page <code>1</code> is always newest. Temperature and voltage pages each hold   24 hours and accept <code>1</code>-<code>7</code>. GPS pages each hold 12 hours and accept <code>1</code>   through twice the current GPS retention in days. Omitting the page selects   page <code>1</code>.</li> <li><code>channel</code>: Cayenne LPP channel assigned to an external voltage monitor.   <code>get telemetry.volt.i2c</code> lists channels that have at least one non-zero   sample. Supplying a channel returns 48 points (24 hours) per page; pages   <code>1</code>-<code>4</code> cover all four days. A detected input whose complete retained history   is zero is treated as disconnected and is omitted until it reports a   non-zero voltage. An INA3221 contributes three consecutive entries, in   hardware-input order. If it is the only detected external sensor these are   normally LPP channels <code>2</code>, <code>3</code>, and <code>4</code>; always use the no-argument command   as the authoritative list because earlier detected sensors shift the LPP   numbers.</li> <li><code>days</code>: Requested GPS retention from <code>1</code> through <code>30</code> days. Retention above   three days uses heap memory. The allocator reduces the requested value as   needed to leave at least 2048 bytes free and replies with the days and pages   actually available. For example, a request can return   <code>OK - telemetry.gps days=18 pages=36 requested=30</code>.</li> <li><code>direct</code>: Send the binary temperature and voltage snapshots zero-hop to a   neighboring MQTT observer.</li> <li><code>path</code>: A comma-separated direct route using the same one-, two-, or   three-byte hop hashes accepted by <code>set outpath</code>.</li> <li><code>schedule</code>: Automatic interval in whole days. The default is <code>2d</code>; <code>off</code>   retains the configured direct path for manual test sends.</li> </ul> <p>Local serial and remote administrator CLI sessions can read the history on both roles. Collection uses the MCU temperature, battery voltage, external I2C voltage monitors, and an already-valid onboard GPS fix. It does not wake GPS, so an off, sleeping, or unfixed GPS produces a missing location sample without changing its power-saving schedule.</p> <p>External voltage history allocates 360 bytes for each detected monitor channel (1,080 bytes for all three INA3221 inputs). The allocation reserves all detected inputs so a sensor connected later can start recording, but all-zero inputs are omitted from command replies and LoRa transmission.</p> <p>Replies contain <code>&gt;</code> followed by standard padded Base64. After decoding, all multi-byte integers are little-endian. Packed fields are written most significant bit first, oldest sample first.</p> <p>Use the browser-based Telemetry history decoder to turn a reply into a timestamped table or downloadable CSV without uploading the data.</p> <p><code>telemetry.tx</code> is disabled by default. Its schedule and direct path are stored across reboots. Configuring <code>direct</code> or a routed path enables the default <code>2d</code> schedule; <code>set telemetry.tx schedule</code> changes it from one through 30 days or turns it off. An automatic run waits until 165 half-hour positions are available, then sends one maximum-size temperature packet, one maximum-size battery-voltage packet, and up to three <code>IVB1</code> packets for every populated I2C voltage channel. GPS is never included in this raw transmission. The history remains boot-local, so the first scheduled run after a reboot needs about 82.5 hours to fill. On the default two-day interval, each 82.5-hour temperature or battery packet overlaps its predecessor by 34.5 hours. Packets are paced two seconds apart. A queue failure is retried after 30 minutes only for the packet that did not queue; successfully queued packets are not duplicated.</p> <p><code>send telemetry.tx now</code> is an administrator-only test action. It queues temperature and battery-voltage snapshots plus the available I2C voltage chunks over the configured path. It uses all currently available base positions up to 165 and all available I2C positions up to 192 per populated channel. It works while the schedule is off and does not move the next scheduled send time. RAW_CUSTOM direct packets do not enter the normal encrypted direct-message retry mechanism.</p> <p>Full snapshots are 184-byte RAW_CUSTOM payloads. Manual tests can be shorter while history fills. Both formats are binary, not Base64 and not encrypted:</p> Bytes Meaning <code>0</code>-<code>3</code> ASCII magic <code>TTB1</code> for temperature or <code>TVB1</code> for voltage <code>4</code>-<code>11</code> First eight bytes of the repeater public key <code>12</code>-<code>15</code> First sample UTC epoch, unsigned 32-bit little-endian <code>16</code>-<code>17</code> Sample interval in minutes, unsigned 16-bit little-endian (<code>30</code>) <code>18</code> Sample count (<code>1</code>-<code>165</code>) <code>19</code> onward Oldest-to-newest encoded samples for the selected series <p>Temperature codes reserve <code>0</code> for no reading, <code>1</code> for below <code>-50 C</code>, and <code>2</code> for above <code>+77 C</code>. Codes <code>3</code> through <code>130</code> represent exact whole degrees from <code>-50 C</code> through <code>+77 C</code>; decode them as <code>code - 53</code>. Voltage codes use the same encoding as the paged voltage payload documented below.</p> <p>External voltage snapshots use a separate packed layout. A full four-day channel takes three 140-byte <code>IVB1</code> payloads of 64 points each:</p> Bytes Meaning <code>0</code>-<code>3</code> ASCII magic <code>IVB1</code> <code>4</code>-<code>11</code> First eight bytes of the source public key <code>12</code>-<code>15</code> First sample UTC epoch, unsigned 32-bit little-endian <code>16</code>-<code>17</code> Sample interval in minutes, unsigned 16-bit little-endian (<code>30</code>) <code>18</code> Cayenne LPP voltage channel <code>19</code> Sample count (<code>1</code>-<code>64</code>) <code>20</code> onward Oldest-to-newest packed 15-bit voltage codes <p>Code <code>0</code> means missing or disconnected. Codes <code>1</code>-<code>32767</code> represent <code>0.02 V</code> through <code>655.34 V</code> in <code>0.02 V</code> steps; decode millivolts as <code>code * 20</code>.</p> <p>Match bytes <code>4</code>-<code>11</code> to the first 16 hex characters of the repeater public key shown by its advert or <code>get public.key</code>. This compact identifier is useful for association but is not authenticated and can be spoofed. An MQTT observer can upload the received raw packet to LetsMesh Analyzer <code>/packets</code>; its packet hex contains the direct-route header and path followed by this payload.</p> <p>Temperature payload (<code>0x11</code>, 61 bytes):</p> Bytes Meaning <code>0</code> Format/type <code>0x11</code> <code>1</code>-<code>4</code> First sample UTC epoch, unsigned 32-bit <code>5</code> Sample interval in minutes (<code>30</code>) <code>6</code> Sample count (<code>48</code>) <code>7</code>-<code>18</code> 48 packed 2-bit temperature statuses <code>19</code>-<code>60</code> 48 packed 7-bit temperatures <p>Temperature status codes are <code>0</code> none, <code>1</code> value, <code>2</code> below range, and <code>3</code> above range. For status <code>1</code>, the 7-bit temperature is an exact whole-degree integer from <code>-50 C</code> through <code>+77 C</code>; decode it as <code>code - 50</code>. Low values use code <code>0</code>, and high values use code <code>127</code>. The separate status map is required because 7 bits contain exactly 128 codes, leaving no spare code for none, low, or high when the complete range is represented at 1 C resolution. No fractional temperature is stored or transmitted.</p> <p>Voltage payload (<code>0x12</code>, 55 bytes):</p> Bytes Meaning <code>0</code> Format/type <code>0x12</code> <code>1</code>-<code>4</code> First sample UTC epoch, unsigned 32-bit <code>5</code> Sample interval in minutes (<code>30</code>) <code>6</code> Sample count (<code>48</code>) <code>7</code>-<code>54</code> 48 8-bit voltage codes <p>Voltage codes reserve <code>0</code> for no reading, <code>1</code> for below <code>1.88 V</code>, and <code>255</code> for above <code>4.40 V</code>. Codes <code>2</code>-<code>254</code> represent <code>1.88 V</code> through <code>4.40 V</code> in <code>0.01 V</code> steps; decode millivolts as <code>1880 + (code - 2) * 10</code>.</p> <p>External I2C voltage payload (<code>0x14</code>, 98 bytes):</p> Bytes Meaning <code>0</code> Format/type <code>0x14</code> <code>1</code>-<code>4</code> First sample UTC epoch, unsigned 32-bit <code>5</code> Sample interval in minutes (<code>30</code>) <code>6</code> Sample count (<code>48</code>) <code>7</code> Cayenne LPP voltage channel <code>8</code>-<code>97</code> 48 packed 15-bit voltage codes <p>The codes have the same <code>0.02 V</code> through <code>655.34 V</code> meaning as <code>IVB1</code>.</p> <p>GPS payload (<code>0x13</code>, 101 bytes):</p> Bytes Meaning <code>0</code> Format/type <code>0x13</code> <code>1</code>-<code>4</code> First sample UTC epoch, unsigned 32-bit <code>5</code> Sample interval in minutes (<code>30</code>) <code>6</code> Sample count (<code>24</code>) <code>7</code>-<code>10</code> Page origin latitude in signed degrees times <code>10^7</code> <code>11</code>-<code>14</code> Page origin longitude in signed degrees times <code>10^7</code> <code>15</code> Origin sample index, or <code>255</code> when the page has no GPS fix <code>16</code> Flags; bit 0 means at least one differential was clipped <code>17</code>-<code>100</code> 24 records: signed 14-bit north then signed 14-bit east <p>GPS differentials use signed 14-bit two's-complement values at 10-meter resolution and are applied to the preceding decoded valid point. The origin sample begins at the header coordinates. A no-fix slot encodes <code>0,0</code> and does not advance the reference; a stationary valid fix also quantizes to <code>0,0</code>. When a page has no fixes, its origin is <code>0,0</code>, origin index is <code>255</code>, and all differentials are <code>0,0</code>. Values outside <code>-8192</code> through <code>8191</code> are clipped and set flag bit 0.</p>"},{"location":"cli_commands/#set-companion-display-rotation","title":"Set Companion display rotation","text":"<p>SSD1306 Full Companion builds support a persisted runtime orientation:</p> <pre><code>get display.rotation\nset display.rotation 0\nset display.rotation 90\nset display.rotation 180\nset display.rotation 270\n</code></pre> <p>The values are clockwise degrees. <code>0</code> clears the override and restores the board's compiled default. Unsupported display drivers return an error.</p>"},{"location":"cli_commands/#set-mqtt-observer-display-timeout-and-flip","title":"Set MQTT observer display timeout and flip","text":"<p>MQTT observer builds with a display support a persisted inactivity timeout:</p> <pre><code>get display.timeout\nset display.timeout 0\nset display.timeout 60\n</code></pre> <p>The value is seconds. <code>0</code> keeps the display on; <code>1</code> through <code>3600</code> blanks it after that much inactivity. The default is <code>60</code>. A change applies immediately and restarts the countdown. On the Heltec V4 R8 Expansion Kit V2 observer, a panel tap or USER-button click can also blank or wake the display.</p> <p>Supported observer displays, including the R8 OLED and ST7789 panels, can also be turned 180 degrees relative to their compiled orientation:</p> <pre><code>get display.flip\nset display.flip off\nset display.flip on\n</code></pre> <p><code>0</code> and <code>1</code> are accepted aliases for <code>off</code> and <code>on</code>. This is intentionally different from Full Companion <code>display.rotation</code>: observer <code>display.flip</code> is a relative 180-degree mounting choice and cannot switch between portrait and landscape. The value is harmless on an observer display driver that does not support flipping.</p> <p>Both settings survive reboot and firmware updates that preserve the filesystem; erasing flash restores the <code>60</code>/<code>off</code> defaults. The boot log reports the saved flip state on display-enabled observer builds.</p>"},{"location":"cli_commands/#logging","title":"Logging","text":"<p>Builds compiled with <code>MESH_PACKET_LOGGING</code> emit one <code>RAW:</code> line for every received radio frame. Serial output uses backpressure: if a connected host temporarily stops reading, packet processing waits for USB transmit space instead of silently omitting the record. A disconnected host cannot retain an unbounded capture, so logging deployments should keep the reader attached and draining the serial port.</p> <p>Every valid received frame also emits the decoded RX summary, including signal, timing, hash, type, route, and payload information. Frames that cannot be decoded still emit their <code>RAW:</code> line. Transmitted packets emit the decoded TX summary.</p> <p>Ordinary non-OTA artifacts compile packet logging into the canonical image and control its live USB output at runtime; no separate <code>-logging-</code> artifact is emitted. Use the separately named <code>-ota-</code> artifact when LoRa OTA is required. A <code>-full-usb-wifi-ota-</code> artifact combines USB packet logging, direct WiFi MQTT, LoRa OTA, and the expanded FULL feature set. A <code>-full-logging-ota-</code> artifact is emitted only when that hardware/role has no matching WiFi MQTT environment.</p>"},{"location":"cli_commands/#control-live-usb-logging","title":"Control live USB logging","text":"<p>Usage:</p> <pre><code>get usb.logging\nset usb.logging on\nset usb.logging off\nset usb.logging on reboot\nset usb.logging off reboot\n</code></pre> <p>These commands are compiled into ordinary USB-loggable artifacts and every Full Companion. They control live USB debug and packet output. CommonCLI roles save the setting in <code>/com_prefs</code>, so it survives reboot; their first boot defaults to on. Full Companion and ordinary USB Companion start off on a fresh installation so diagnostics cannot corrupt framed traffic.</p> <p>On Full Companion these lines belong to its text terminal, not <code>meshcli</code>'s Binary <code>get/set</code> parameter namespace. Open interface <code>00</code>, send <code>+++MESHCORE-TERM-START</code>, and then issue the command. Running <code>meshcli ... get usb.logging</code> directly can instead return <code>Unknown var usb.logging</code> because that is a different protocol operation.</p> <p>nRF52 Full Companion defaults logging to off and enumerates only USB interface <code>00</code>, which carries Companion, terminal, and serial mOTA traffic. Enabling logging adds interface <code>02</code>, its dedicated plaintext logging port, on the next boot. Disabling it removes interface <code>02</code> on the next boot. A command without the optional <code>reboot</code> argument saves the choice and reports that a reboot is required when the USB interface count must change. The exact <code>set usb.logging on reboot</code> and <code>set usb.logging off reboot</code> forms save the choice, send their reply, and reboot one second later only when needed.</p> <p>On every ESP32 Full Companion, enter the USB text terminal and use <code>set usb.logging on</code> to turn that TTY into a logging-repeater-style plaintext stream. Framed Binary Companion is unavailable on USB while logging is on. The TTY remains an input-capable CLI, so <code>set usb.logging off</code> works on the same TTY. After its reply, logging stops and the TTY remains in the normal ASCII terminal, just as it does after a fresh Full installation. Send <code>+++MESHCORE-TERM-STOP</code>, or let a Companion app send a valid framed probe, to switch it to Binary Companion. No reboot is needed because the USB interface count does not change.</p> <p>Turning USB logging off does not disable CLI replies. nRF52 keeps Companion frames active on interface <code>00</code>; ESP32 resumes the ordinary ASCII/Binary switcher after the logging terminal turns logging off. This setting does not change the node-storage capture controlled by <code>log start</code> and <code>log stop</code>.</p> <p>Unified non-Companion ESP32 FULL USB+WiFi observer builds add one saved selector for both output paths. Full Companion builds control USB diagnostics with <code>usb.logging</code> instead; their text-command parser does not expose <code>logging.output</code>:</p> <pre><code>get logging.output\nset logging.output off\nset logging.output usb\nset logging.output wifi\nset logging.output both\n</code></pre> <p><code>usb</code> emits <code>RAW:</code> packets for a USB-connected service such as meshcoretomqtt. <code>wifi</code> enables the direct MQTT bridge configured by the <code>wifi.*</code> and <code>mqtt.*</code> commands. <code>both</code> intentionally duplicates the radio stream to both consumers; do not point both consumers at the same broker unless the downstream setup deduplicates messages. Fresh unified FULL installs start in <code>both</code> mode.</p>"},{"location":"cli_commands/#begin-capture-of-rx-log-to-node-storage","title":"Begin capture of rx log to node storage","text":"<p>Usage: <code>log start</code></p>"},{"location":"cli_commands/#end-capture-of-rx-log-to-node-storage","title":"End capture of rx log to node storage","text":"<p>Usage: <code>log stop</code></p>"},{"location":"cli_commands/#erase-captured-log","title":"Erase captured log","text":"<p>Usage: <code>log erase</code></p>"},{"location":"cli_commands/#print-the-captured-log-to-the-serial-terminal","title":"Print the captured log to the serial terminal","text":"<p>Usage: <code>log</code></p> <p>Serial Only: Yes</p>"},{"location":"cli_commands/#info","title":"Info","text":""},{"location":"cli_commands/#get-the-version","title":"Get the Version","text":"<p>Usage: <code>ver</code></p> <p>On Full Companion, the Binary device-info frame retains its legacy fixed-width version field. Use <code>version</code> in the text terminal, or send <code>version</code> through Binary protocol command <code>0x42</code> (<code>CMD_RUN_CLI_COMMAND</code>), to read the complete untruncated firmware string together with protocol and build date.</p>"},{"location":"cli_commands/#show-the-hardware-name","title":"Show the hardware name","text":"<p>Usage: <code>board</code></p>"},{"location":"cli_commands/#show-the-storage-layout","title":"Show the storage layout","text":"<p>Usage: <code>get storage.layout</code></p> <p>Reports a compact, read-only summary of the storage compiled into the running firmware:</p> <ul> <li>ESP32 reports the detected internal flash size and the live partition table.   Partition addresses after <code>@</code> are hexadecimal, sizes after <code>+</code> are KiB, and   <code>*</code> marks the running application. <code>...</code> means later entries did not fit in   the CLI reply.</li> <li>nRF52 reports the physical internal flash size, linked application range,   InternalFS range, and any configured external store. Raw QSPI OTA storage   includes its detected size and JEDEC ID; SD storage includes total, used, and   free space.</li> <li>RP2040 and STM32 report their fixed internal flash and filesystem geometry.</li> </ul> <p>The command does not write, format, or resize storage. A raw-QSPI or SD build may briefly probe, wake, or mount its configured external storage to read its capacity. Remote use follows the existing administrator-command permissions.</p>"},{"location":"cli_commands/#configuration","title":"Configuration","text":""},{"location":"cli_commands/#radio","title":"Radio","text":""},{"location":"cli_commands/#view-or-change-this-nodes-radio-parameters","title":"View or change this node's radio parameters","text":"<p>Usage: - <code>get radio</code> - <code>set radio &lt;freq&gt;,&lt;bw&gt;,&lt;sf&gt;,&lt;cr&gt;</code></p> <p>Parameters: - <code>freq</code>: Frequency in MHz - <code>bw</code>: Bandwidth in kHz. Most targets allow <code>7.8</code>, <code>10.4</code>, <code>15.6</code>, <code>20.8</code>, <code>31.25</code>, <code>41.7</code>, <code>62.5</code>, <code>125</code>, <code>250</code>, <code>500</code>. LR1110 targets allow <code>62.5</code>, <code>125</code>, <code>250</code>, <code>500</code>. - <code>sf</code>: Spreading factor (5-12) - <code>cr</code>: Coding rate (5-8)</p> <p>Set by build flag: <code>LORA_FREQ</code>, <code>LORA_BW</code>, <code>LORA_SF</code>, <code>LORA_CR</code></p> <p>Default: <code>869.525,250,11,5</code></p> <p>Note: Requires reboot to apply. If RXPS is enabled and the saved minimum level/preamble cannot safely cover the new radio timing, the command reply reports the effective level and preamble, or <code>RXPS continuous-fast</code> when no level through 10 is safe. Slower settings recalculate from the saved RXPS minimum and return to it exactly when it is safe.</p>"},{"location":"cli_commands/#view-or-change-this-nodes-transmit-power","title":"View or change this node's transmit power","text":"<p>Usage: - <code>get tx</code> - <code>set tx &lt;dbm&gt;</code></p> <p>Parameters: - <code>dbm</code>: Requested radio-chip power in dBm. The valid range depends on the   radio family, selected PA path, and any board-specific external-PA limit.</p> <p>Set by build flag: <code>LORA_TX_POWER</code></p> <p>Default: Varies by board</p> <p>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.</p> <p>The command strictly rejects malformed values and saves the new preference only after the active radio driver accepts it. On LR2021, the chip range is <code>-9</code> to <code>22</code> dBm below 1500 MHz and <code>-19</code> to <code>12</code> dBm above 1500 MHz. A lower board-specific external-PA limit still takes precedence. A saved profile is clamped to the applicable limit when its frequency changes; temporary radio settings use a safe effective power without replacing the saved preference.</p>"},{"location":"cli_commands/#change-the-radio-parameters-for-a-set-duration","title":"Change the radio parameters for a set duration","text":"<p>Usage:  - <code>tempradio &lt;freq&gt;,&lt;bw&gt;,&lt;sf&gt;,&lt;cr&gt;,&lt;timeout_mins&gt;</code> - <code>normalradio</code></p> <p>Parameters: - <code>freq</code>: Frequency in MHz (150-2500) - <code>bw</code>: Bandwidth in kHz (same allowed values as <code>set radio</code>) - <code>sf</code>: Spreading factor (5-12) - <code>cr</code>: Coding rate (5-8) - <code>timeout_mins</code>: Duration in minutes (must be &gt; 0)</p> <p>Notes: - <code>tempradio</code> is not saved to preferences and clears on reboot. - <code>normalradio</code> cancels pending and active temporary-radio windows, then   restores the saved radio tuple after its CLI reply has drained on the   current channel. Permanent <code>radioat</code> entries are not removed.</p>"},{"location":"cli_commands/#schedule-radio-parameter-changes","title":"Schedule radio parameter changes","text":"<p>Usage: - <code>set radioat &lt;freq&gt;,&lt;bw&gt;,&lt;sf&gt;,&lt;cr&gt;,&lt;start_time&gt;</code> - <code>get radioat [n|all]</code> - <code>del radioat [n|all]</code> - <code>set tempradioat &lt;freq&gt;,&lt;bw&gt;,&lt;sf&gt;,&lt;cr&gt;,&lt;start_time&gt;,&lt;end_time&gt;</code> - <code>get tempradioat [n|all]</code> - <code>del tempradioat [n|all]</code></p> <p>Parameters: - <code>freq</code>: Frequency in MHz (150-2500) - <code>bw</code>: Bandwidth in kHz (same allowed values as <code>set radio</code>) - <code>sf</code>: Spreading factor (5-12) - <code>cr</code>: Coding rate (5-8) - <code>start_time</code>: Unix epoch time when the setting starts - <code>end_time</code>: Unix epoch time when a temporary setting reverts - <code>n</code>: Scheduled entry number from <code>get radioat</code> or <code>get tempradioat</code></p> <p>Notes: - <code>get radioat</code> and <code>get tempradioat</code> list all entries when <code>n</code> is omitted. - <code>del radioat</code> and <code>del tempradioat</code> delete all entries when <code>n</code> is omitted. - Each queue supports 3 entries. Scheduled entries are not saved across reboot. - <code>radioat</code> saves the new radio preferences when it fires. <code>tempradioat</code> applies temporarily, then reverts to the saved radio preferences. - A successful scheduling reply notes any RXPS effective-level/preamble change   required by the scheduled tuple. <code>RXPS continuous-fast</code> means the tuple is   accepted but will use continuous receive because no safe duty-cycle level is   available. Returning to slower settings recalculates from the saved RXPS   minimum.</p> <p>On SX1262+TCXO boards, the fast-setting boundaries are:</p> SF BW (kHz) Wire preamble Effective timing preamble Minimum effective RXPS level RX / sleep 7 500 32 32 7 2731 / 6101 us 6 250 32 32 7 2731 / 6101 us 5 125 32 32 7 2731 / 6101 us 5 250 64 64 8 1252 / 6424 us 6 500 64 64 8 1252 / 6424 us 5 500 128 128 8 626 / 6398 us 5 62.5 32 16 10 4096 / 6272 us <p>SF7/BW500, SF6/BW250, and SF5/BW125 are timing-equivalent because each has a 256 us LoRa symbol. SF5/BW250 and SF6/BW500 have 128 us symbols; both need 64 wire symbols to cover the 6 ms transition. SF5/BW500 has 64 us symbols and needs 128.</p> <p>The wire preamble is a firmware property, not a <code>radio.rxps</code> preference. The effective preamble is the conservative length RXPS uses for its timing window, which is why SF5/BW62.5 can retain a saved 16-symbol assumption while the radio transmits 32. Starting with v1.17.1.5, firmware tries 32 first at SF5-SF8, then 64 and 128 only when each shorter length cannot enable RXPS at any level. It uses 16 at SF9-SF12. Every packet on a tuple, including retries, uses that tuple's selected length.</p> <p>Cascade/USA builds on a Heltec V4 and WisMesh Tag (RAK4631 target) passed 16/16 packets in each direction at both SF5/BW250/64 and SF5/BW500/128, CR5, 909.950 MHz. A 64- or 128-symbol timing window is safe only when every possible sender to the RXPS receiver follows the v1.17.1.5-or-newer adaptive-preamble contract; a shorter legacy sender would create a receive gap. LoRa OTA automation treats that version as the wire-format capability boundary.</p>"},{"location":"cli_commands/#view-or-change-this-nodes-frequency","title":"View or change this node's frequency","text":"<p>Usage: - <code>get freq</code> - <code>set freq &lt;frequency&gt;</code></p> <p>Parameters: - <code>frequency</code>: Frequency in MHz</p> <p>Default: <code>869.525</code></p> <p>Note: Requires reboot to apply Serial Only: <code>set freq &lt;frequency&gt;</code></p>"},{"location":"cli_commands/#view-or-change-this-nodes-rx-boosted-gain-mode-sx12xx-and-lr1110-v1141","title":"View or change this node's rx boosted gain mode (SX12xx and LR1110, v1.14.1+)","text":"<p>Usage: - <code>get radio.rxgain</code> - <code>set radio.rxgain &lt;state&gt;</code></p> <p>Parameters:   - <code>state</code>: <code>on</code>|<code>off</code></p> <p>Default: Target-specific. Most SX1262 and LR1110 targets default to <code>on</code>; Station G2/G3 targets default to <code>off</code>.</p> <p>Notes: - The saved setting is applied immediately and persists across reboots. - Periodic AGC resets restore the saved runtime setting; they do not replace it   with the target's compile-time default. - Existing installations retain their previously saved value after an upgrade.</p>"},{"location":"cli_commands/#view-or-change-rx-duty-cycle-power-saving","title":"View or change RX duty-cycle power saving","text":"<p>Usage: - <code>get radio.rxps</code> - <code>get radio.rxps.config</code> - <code>get radio.rxps.rfrx_disabled</code> - <code>get rxps.wd</code> - <code>set radio.rxps.rfrx_disabled &lt;state&gt;</code> - <code>set radio.rxps off</code> - <code>set radio.rxps on</code> - <code>set radio.rxps conservative</code> - <code>set radio.rxps balanced</code> - <code>set radio.rxps &lt;1-10&gt;</code> - <code>set radio.rxps level &lt;1-10&gt;</code> - <code>set radio.rxps level &lt;1-10&gt; preamble &lt;16|32&gt;</code> - <code>set radio.rxps &lt;rx_us&gt; &lt;sleep_us&gt;</code></p> <p>Parameters: - <code>rx_us</code>, <code>sleep_us</code>: Receive and sleep durations in microseconds (<code>1000</code>-<code>30000000</code>). - <code>level</code>: A power-saving level from <code>1</code> (most conservative) to <code>10</code> (least power saving). - <code>preamble</code>: RXPS timing assumption in symbols; <code>16</code> or <code>32</code>. This does not   change the radio's actual transmitted preamble. - <code>state</code>: <code>on</code> or <code>off</code>.</p> <p>Notes: - <code>get rxps.wd</code> reports the RXPS watchdog's soft and hard recovery counts. - <code>get radio.rxps.config</code> adds the persisted level and preamble assumption to   the on/off and timing values. Deployment tools use it to restore a   level-based preference without converting it to fixed manual timings. - <code>radio.rxps.rfrx_disabled</code> is a runtime-only diagnostic setting and resets to <code>off</code> after reboot. - Its default <code>off</code> state keeps the host-controlled SX1262 receive path enabled during RX duty-cycle mode. Setting it to <code>on</code> reproduces the old missing-RF_RX behavior and can significantly reduce receive sensitivity, making remote commands harder to receive. - <code>radio.rxps.rfrx_disabled</code> is supported only on SX1262 targets with a host-controlled RX enable pin. - <code>on</code> and <code>conservative</code> select level <code>1</code> with a 16-symbol preamble; <code>balanced</code> selects level <code>5</code> with a 16-symbol preamble. - Fresh Cascade-profile builds start with RXPS on at level <code>8</code> and a 16-symbol preamble. Saved operator settings still take precedence after an upgrade. - Level-based settings automatically recalculate their timings when the spreading factor or bandwidth changes. Custom <code>&lt;rx_us&gt; &lt;sleep_us&gt;</code> timings remain fixed. - <code>get radio.rxps</code> keeps the legacy on/off, RX, and sleep reply. The new   <code>get radio.rxps.config</code> reply adds the saved level and preamble assumption.   Radio-change replies and the Full Companion terminal status report any   effective level/preamble adjustment. Effective preamble 64 or 128 appears   only when the active tuple's physical wire preamble has that length. - The selected mode is applied immediately, persisted, and restored after reboot.</p>"},{"location":"cli_commands/#view-or-change-the-lora-fem-receive-path-gain-state-on-supported-boards","title":"View or change the LoRa FEM receive-path gain state on supported boards","text":"<p>Usage: - <code>get radio.fem.rxgain</code> - <code>set radio.fem.rxgain &lt;state&gt;</code></p> <p>Parameters: - <code>state</code>: <code>on</code>|<code>off</code></p> <p>Notes: - This controls the external LoRa FEM receive-path LNA where the board supports it. - This is separate from <code>radio.rxgain</code>, which controls the radio chip receive gain mode.</p>"},{"location":"cli_commands/#view-or-change-the-lora-fem-transmit-path-gain-state-on-supported-boards","title":"View or change the LoRa FEM transmit-path gain state on supported boards","text":"<p>Usage: - <code>get radio.fem.txgain</code> - <code>set radio.fem.txgain &lt;state&gt;</code></p> <p>Parameters: - <code>state</code>: <code>on</code>|<code>off</code></p> <p>Notes: - This controls a software-selectable external LoRa FEM transmit gain where the board supports it. - On Station G3, remove the PA PL1 jumper to allow software control. <code>on</code> selects PA PL1 high/short and <code>off</code> selects PA PL1 low/open. The PA PL2 hardware jumper determines whether this switches between power levels 1/3 or 2/4. - Select an operating level and SX1262 transmit power that comply with local RF limits and the Station G3 power-supply requirements. - The setting is saved immediately, but on Station G3 the level is applied to the hardware at the start of the next transmit, so that the PA supply rail is never re-targeted while the PA is being driven. <code>get</code> reports the configured state, which may lead the hardware until the node next transmits.</p>"},{"location":"cli_commands/#system","title":"System","text":""},{"location":"cli_commands/#view-or-change-this-nodes-name","title":"View or change this node's name","text":"<p>Usage: - <code>get name</code> - <code>set name &lt;name&gt;</code></p> <p>Parameters: - <code>name</code>: Node name</p> <p>Set by build flag: <code>ADVERT_NAME</code></p> <p>Default: Varies by board</p> <p>Note: Advertised names can use up to 23 bytes when location is included and 31 bytes otherwise. Emoji and Unicode characters may take more than one byte. Names that exceed the available advert space are truncated at a valid UTF-8 code point boundary.</p>"},{"location":"cli_commands/#view-or-change-the-independent-bluetooth-name-companion","title":"View or change the independent Bluetooth name (Companion)","text":"<p>Usage:</p> <ul> <li><code>get bluetooth.name</code></li> <li><code>set bluetooth.name &lt;name|default&gt;</code></li> </ul> <p><code>get ble.name</code> and <code>set ble.name ...</code> are accepted aliases. This command is specific to Companion firmware. The default is <code>MeshCore-&lt;advert name&gt;</code>; <code>default</code> (or <code>clear</code>) removes a custom override. Names are limited to 31 valid UTF-8 bytes without control characters and take effect after reboot.</p> <p>A binary Companion client should carry the same text in command <code>0x42</code> (<code>CMD_RUN_CLI_COMMAND</code>), which works over USB, BLE, or TCP without entering USB terminal mode. See Companion radio binary protocol for the frame and reply format.</p>"},{"location":"cli_commands/#view-or-change-this-nodes-latitude","title":"View or change this node's latitude","text":"<p>Usage: - <code>get lat</code> - <code>set lat &lt;degrees&gt;</code></p> <p>Set by build flag: <code>ADVERT_LAT</code></p> <p>Default: <code>0</code></p> <p>Parameters: - <code>degrees</code>: Latitude in degrees</p>"},{"location":"cli_commands/#view-or-change-this-nodes-longitude","title":"View or change this node's longitude","text":"<p>Usage: - <code>get lon</code> - <code>set lon &lt;degrees&gt;</code></p> <p>Set by build flag: <code>ADVERT_LON</code></p> <p>Default: <code>0</code></p> <p>Parameters: - <code>degrees</code>: Longitude in degrees</p>"},{"location":"cli_commands/#view-or-change-this-nodes-identity-private-key","title":"View or change this node's identity (Private Key)","text":"<p>Usage: - <code>get prv.key</code> - <code>set prv.key &lt;private_key&gt;</code></p> <p>Parameters: - <code>private_key</code>: Private key in hex format (64 hex characters)</p> <p>Serial Only: - <code>get prv.key</code>: Yes - <code>set prv.key</code>: No</p> <p>Note: Requires reboot to take effect after setting</p>"},{"location":"cli_commands/#change-this-nodes-admin-password","title":"Change this node's admin password","text":"<p>Usage: - <code>password &lt;new_password&gt;</code></p> <p>Parameters: - <code>new_password</code>: New admin password</p> <p>Set by build flag: <code>ADMIN_PASSWORD</code></p> <p>Default: <code>password</code></p> <p>Note: Command reply echoes the updated password for confirmation.</p> <p>Note: Any node using this password will be added to the admin ACL list.</p>"},{"location":"cli_commands/#view-or-change-this-nodes-guest-password","title":"View or change this node's guest password","text":"<p>Usage: - <code>get guest.password</code> - <code>set guest.password &lt;password&gt;</code></p> <p>Parameters: - <code>password</code>: Guest password</p> <p>Set by build flag: <code>ROOM_PASSWORD</code> (Room Server only)</p> <p>Default: <code>&lt;blank&gt;</code></p>"},{"location":"cli_commands/#view-or-change-this-nodes-owner-info","title":"View or change this node's owner info","text":"<p>Usage: - <code>get owner.info</code> - <code>set owner.info &lt;text&gt;</code></p> <p>Parameters: - <code>text</code>: Owner information text</p> <p>Default: <code>&lt;blank&gt;</code></p> <p>Note: <code>|</code> characters are translated to newlines</p> <p>Note: Requires firmware 1.12+</p>"},{"location":"cli_commands/#fine-tune-the-battery-reading","title":"Fine-tune the battery reading","text":"<p>Usage: - <code>get adc.multiplier</code> - <code>set adc.multiplier &lt;value&gt;</code></p> <p>Parameters: - <code>value</code>: ADC multiplier (0.0-10.0)</p> <p>Default: <code>0.0</code> (value defined by board)</p> <p>Note: Returns \"Error: unsupported by this board\" if hardware doesn't support it</p>"},{"location":"cli_commands/#send-a-repeater-flood-text","title":"Send a repeater flood text","text":"<p>Usage: - <code>send text.flood &lt;message&gt;</code></p> <p>Parameters: - <code>message</code>: Text to send to the shared <code>#repeaters</code> flood channel, prefixed with this node's name. Any <code>:</code> in the node name is sent as <code>;</code> so the prefix delimiter stays unambiguous.</p> <p>Example:</p> <pre><code>send text.flood checking ridge link\n</code></pre>"},{"location":"cli_commands/#view-or-change-battery-alert-state","title":"View or change battery alert state","text":"<p>Usage: - <code>get battery.alert</code> - <code>get battery.alert.region</code> - <code>set battery.alert on [region]</code> - <code>set battery.alert off</code></p> <p>Parameters: - <code>region</code>: Optional named region scope. When omitted, the repeater selects the single deepest (most narrow) named region in the configured hierarchy. If multiple regions tie for deepest, specify one explicitly.</p> <p>Defaults: - <code>battery.alert</code>: <code>off</code> - <code>battery.alert.region</code>: <code>&lt;unset&gt;</code></p> <p>Notes: - Enabling fails until at least one usable named region is defined. Alerts are never sent as unscoped floods. If the selected region is later removed, alerts stop until battery alerts are enabled again with a valid region. - Region hierarchy edits are not persistent until <code>region save</code> is run. After <code>region def west pnw wa w-wa sea</code>, run <code>region save</code> before enabling the alert if the hierarchy must survive a reboot. - A region must have a usable transport key. Public named regions derive one automatically; a private region without an available key is rejected. - The first alert is suppressed until the repeater has been up for at least 30 minutes. After that, the repeater checks every 30 minutes and sends low-battery warnings to the <code>#repeaters</code> channel in the selected region. - Once an alert finishes transmitting, another battery alert is suppressed for at least 12 hours. A queue rejection, stale-queue drop, or radio send failure does not start the cooldown. Battery recovery or toggling alerts off and back on does not bypass a completed alert's cooldown during the same boot. - With <code>region def west pnw wa w-wa sea</code>, <code>set battery.alert on</code> selects <code>sea</code>; <code>set battery.alert on w-wa</code> overrides that default. - <code>get battery.alert.region</code> returns the selected scope, for example <code>&gt; sea</code>. - The battery check never requests a wake earlier than its 30-minute deadline. If the normal loop is already awake when that deadline has elapsed, the check is effectively free of an additional wake. Time in light/event sleep counts toward the startup delay, and a pending alert keeps the repeater awake until the packet is handled.</p>"},{"location":"cli_commands/#view-or-change-battery-alert-thresholds","title":"View or change battery alert thresholds","text":"<p>Usage: - <code>get battery.alert.low</code> - <code>set battery.alert.low &lt;1-100&gt;</code> - <code>get battery.alert.critical</code> - <code>set battery.alert.critical &lt;0-99&gt;</code></p> <p>Defaults: - <code>battery.alert.low</code>: <code>20</code> - <code>battery.alert.critical</code>: <code>10</code></p> <p>Note: The low threshold must be greater than the critical threshold. Alerts at or below the critical threshold use <code>CRITICAL BATTERY</code> in the message; both severities use the same 12-hour resend cooldown.</p>"},{"location":"cli_commands/#enable-or-disable-the-rx-inactivity-watchdog-repeater-only","title":"Enable or disable the RX inactivity watchdog (Repeater Only)","text":"<p>Usage: - <code>get rx.watchdog</code> - <code>set rx.watchdog on</code> - <code>set rx.watchdog off</code></p> <p>Default: <code>off</code></p> <p>Notes: - When enabled, the first check is due after a full 12-hour observation window. The repeater then checks roughly every 12 hours and reboots if it has not successfully received a radio packet during the preceding 12 hours. - Enabling the watchdog starts a new 12-hour observation window. Rebooting also starts a new window, so a quiet mesh can reboot no more often than once every 12 hours. - The check reuses the radio driver's existing last-receive timestamp. It does not poll, sample, or wake the radio or CPU. A due check waits for the next normal loop/wake, so its actual cadence can drift around the 12-hour target. With RX power saving enabled, packets received during normal listening windows count as activity; the watchdog does not alter the RX/sleep timing.</p>"},{"location":"cli_commands/#enable-or-disable-the-nrf52-system-watchdog","title":"Enable or disable the nRF52 system watchdog","text":"<p>Usage: - <code>get system.watchdog</code> - <code>set system.watchdog on</code> - <code>set system.watchdog off</code></p> <p>Default: <code>on</code></p> <p>Notes: - This nRF52-only hardware watchdog resets the device if the application loop stops for 60 seconds, including an indefinite SoftDevice flash-write wait. - Enabling takes effect without a reboot. - The nRF52 hardware cannot stop a watchdog after it has started. Disabling is persisted immediately, then the current firmware stops feeding it so the board performs one watchdog restart within 60 seconds. It remains off after that restart. - This setting is nRF52-only. The SoftDevice flash deadlock does not apply to ESP32, whose existing watchdog behavior is unchanged.</p>"},{"location":"cli_commands/#estimate-and-correct-infrastructure-node-time-after-startup","title":"Estimate and correct infrastructure-node time after startup","text":"<p>Usage: - <code>get clock.sync</code> - <code>get clock.sync.status</code> - <code>get clock.sync.status.table</code> - <code>get clock.sync.status.&lt;1-16&gt;</code> - <code>get clock.sync.mesh</code> - <code>set clock.sync.mesh &lt;on|off&gt;</code> - <code>get clock.sync.mesh.edge</code> - <code>set clock.sync.mesh.edge &lt;on|off&gt;</code> - <code>clock.sync.mesh now</code> - <code>get clock.sync.internet</code> - <code>set clock.sync.internet &lt;on|off&gt;</code> - <code>get clock.sync.drift</code> - <code>set clock.sync.drift &lt;30-86400&gt;</code> - <code>get clock.sync.samples</code> - <code>set clock.sync.samples &lt;3-16&gt;</code></p> <p>Defaults: - <code>clock.sync.mesh</code>: <code>on</code> for all repeater, sensor, and room-server builds - <code>clock.sync.mesh.edge</code>: <code>on</code> - <code>clock.sync.internet</code>: <code>off</code> - <code>clock.sync.drift</code>: <code>600</code> seconds (10 minutes) - <code>clock.sync.samples</code>: <code>9</code></p> <p>When either source is enabled, the node makes its first clock-bootstrap attempt after 30 minutes of uptime, or immediately when the configured number of fresh evidence sources has been collected, whichever comes first. A successful estimate changes the RTC only when the absolute difference is greater than <code>clock.sync.drift</code>; correction can move the clock forward or backward. A valid estimate within the threshold counts as a successful sync without changing the clock. Seven days after each successful estimate, the node evaluates time again; the seven-day deadline therefore starts from the last successful estimate rather than from boot. This is a lazy uptime deadline: the check runs on the first normal loop/wake after it becomes due and does not wake the device by itself. If no source or consensus is available, the node retries every 30 minutes, and newly collected evidence triggers another immediate evaluation once the configured source count is present. Every reboot starts with the initial bootstrap attempt. An existing saved setting always overrides the platform default.</p> <p><code>clock.sync.mesh now</code> bypasses the startup/seven-day deadline and queues a LoRa-only consensus evaluation on the next normal loop, even when the internet source is also enabled. It uses any currently fresh samples without clearing the 16-slot table. If there is not yet enough evidence, mesh collection remains open and the next attempt follows the normal 30-minute retry. The command requires <code>clock.sync.mesh</code> to be on and does not bypass CLI, GPS, or NTP suppression; it also retains the normal quorum, timestamp-validity, and drift checks. The separate <code>clock</code> command only displays the current RTC and does not request a synchronization attempt.</p> <p><code>clock.sync.mesh</code> collects signature-verified advert timestamps and MAC-valid, decrypted Public-channel plain-text timestamps. In normal path mode, collection occurs only after the packet passes every forwarding filter. Sources are deduplicated by advert public key or case-insensitive Public-channel display name. Every fresh sample must also have a different full received path; all direct, zero-hop receptions count as the same empty path. This prevents repeated packets or multiple names arriving over one route from increasing the vote count.</p> <p>For a node at the edge of the network where every packet arrives through one relay path, <code>set clock.sync.mesh.edge on</code> changes the evidence requirement from distinct receive paths to distinct sources. Signature-verified adverts are deduplicated by public key, and Public-channel timestamps are deduplicated by case-insensitive display name. Repeated packets from one source still count once. Edge mode observes this verified evidence on the receive path, independently of the forwarding decision, so <code>repeat off</code> and forwarding filters do not prevent clock collection. Other packet types are observed normally but cannot be clock evidence because they do not provide a suitable authenticated Unix timestamp. Changing edge mode clears the in-memory sample table so evidence collected under the other policy is not reused. The setting is persistent and defaults on.</p> <p>At least the configured number of distinct fresh evidence sources (nine by default) and a strict majority of all fresh samples must fall within ten minutes of the median. In normal mode each source must use a distinct receive path. In edge mode signed adverts are distinct by public key and Public-channel messages are distinct by display name, but all may use the same receive path. The effective quorum is therefore the larger of <code>clock.sync.samples</code> and half the fresh sample count plus one. For example, a 9-vs-7 split can succeed but an 8-vs-8 split cannot. The median is used. <code>clock.sync.samples</code> accepts <code>3</code> through <code>16</code>; samples older than two hours are ignored. Status reports <code>mode=paths</code> or <code>mode=edge</code> and labels the collected evidence as <code>paths</code> or <code>sources</code>. It reports <code>reason=need-more-paths</code> or <code>reason=need-more-sources</code> when fewer than the configured number exist, and <code>reason=no-consensus</code> when enough evidence exists but the effective quorum does not agree. Mesh collection begins immediately after boot. Following a successful estimate, it resumes two hours before the next seven-day deadline so only evidence that can still be fresh at evaluation time is processed.</p> <p><code>get clock.sync.status</code> reports whether the clock was set and a <code>reason</code> when it was not. Common reasons include <code>waiting-deadline</code>, <code>need-more-sources</code>, <code>need-more-paths</code>, <code>no-consensus</code>, <code>within-drift</code>, <code>mesh-off</code>, and suppression by CLI, GPS, or internet time. It also reports whether collection is active, the fresh evidence count, the number of occupied table slots, and the next evaluation deadline.</p> <p><code>get clock.sync.status.table</code> shows the active sample table in compact form. Each item is <code>slot:type:id-prefix:age</code>, where type <code>A</code> is a signed advert and type <code>P</code> is a Public-channel message. A trailing <code>!</code> marks a stale sample. If the compact reply is truncated, query any slot with <code>get clock.sync.status.&lt;1-16&gt;</code>. The detail view reports the full source and path hashes, age-adjusted epoch, difference from the local clock, and freshness.</p> <p>A timestamp is eligible for a clock-sync sample only when it falls between the UTC build epoch embedded by <code>build.sh</code> and that time plus ten calendar years. Direct developer builds that bypass <code>build.sh</code> fall back to the compiler timestamp. Validation happens before a slot is selected or written, so an advert or Public-channel timestamp outside that window is not recorded as a clock sample.</p> <p>Before voting, the node advances each packet timestamp by an estimated transit time. The estimate sums the radio airtime at the original packet length and at each progressively longer relay length, plus the expected midpoint of the random flood-forward delay at every prior hop. The normal elapsed time since the radio recorded local receipt is then added when consensus is evaluated, so local signature/decryption/filter processing time is included too. This is better than using hop count alone because LoRa airtime changes with packet length and radio settings. Transit compensation is capped at the ten-minute consensus window. It cannot know sender queueing, channel contention, or a remote relay's non-matching <code>txdelay</code>, so the consensus window and median still absorb residual error.</p> <p>If a <code>clock sync</code> or <code>time &lt;epoch&gt;</code> CLI command successfully sets the clock, or a GPS provider writes a valid GPS time, LoRa-derived clock collection and correction are suppressed for the rest of that boot. Turning <code>clock.sync.mesh</code> off and back on does not clear this safety latch; only a reboot does. <code>get clock.sync.mesh</code> and <code>get clock.sync.status</code> report whether CLI or GPS time caused the suppression. On a WiFi MQTT build, a successful NTP sync is authoritative and also suppresses LoRa correction for the rest of that boot. Source selection starts fresh after a reboot, so LoRa remains the fallback when NTP cannot obtain internet time during that boot.</p> <p>Public-channel display names are not authenticated and can be spoofed. Received path hashes are also truncated, unauthenticated routing hints; requiring unique paths prevents ordinary duplicate-route inflation but is not a cryptographic identity check. Signed adverts authenticate the advert contents but do not prove that the advertising node's own clock is correct. Mesh time is therefore a consensus estimate, not an authoritative time service. Edge mode intentionally gives up receive-path diversity. Public-channel display names can be spoofed, so one sender can claim multiple names and inflate the edge-mode vote count.</p> <p><code>clock.sync.internet</code> is available on WiFi MQTT repeater-observer builds. Its initial and seven-day queries run on the MQTT/WiFi task and are read-only until the repeater applies the configured drift test. Failed queries retry after 30 minutes. On other infrastructure-node builds, the preference can be stored but status reports that internet time is unavailable. MQTT builds retain their existing startup NTP behavior required for MQTT/TLS/JWT operation; this setting controls the additional delayed drift checks. Startup NTP is always preferred when it succeeds, regardless of this setting.</p> <p>Sensor and room-server builds support mesh clock consensus and report <code>clock.sync.internet</code> as unavailable. Changing any <code>clock.sync.*</code> setting starts a new attempt for the current boot. Settings are persistent in <code>/clock_sync</code>; samples and schedule state are not.</p> <p>A backward correction is intentionally allowed, but peers that already recorded a later timestamp from this node may temporarily reject its lower timestamps as replays until corrected time passes the previously observed value.</p> <p>Example:</p> <pre><code>set clock.sync.drift 600\nset clock.sync.samples 3\nset clock.sync.mesh on\nset clock.sync.mesh.edge on\nclock.sync.mesh now\nget clock.sync.status\n</code></pre>"},{"location":"cli_commands/#view-this-nodes-public-key","title":"View this node's public key","text":"<p>Usage: <code>get public.key</code></p>"},{"location":"cli_commands/#view-this-nodes-firmware-version","title":"View this node's firmware version","text":"<p>Usage: <code>ver</code></p>"},{"location":"cli_commands/#view-this-nodes-configured-role","title":"View this node's configured role","text":"<p>Usage: <code>get role</code></p>"},{"location":"cli_commands/#view-or-change-this-nodes-power-saving-flag","title":"View or change this node's power saving flag","text":"<p>Usage: - <code>powersaving</code> - <code>powersaving on</code> - <code>powersaving off</code> - <code>set powersaving on</code> - <code>set powersaving off</code></p> <p>Parameters:  - <code>on</code>: enable power saving - <code>off</code>: disable power saving</p> <p>Default: <code>on</code> for fresh Cascade-profile builds and Companion firmware; <code>off</code> for other infrastructure profiles</p> <p>Note: Infrastructure firmware enters sleep between radio transmissions. It refuses to enable power saving from the local serial console or while an active USB serial data connection is detected; USB power alone does not block power saving.</p> <p>Companion firmware defaults this setting to <code>on</code>. Full Companion accepts the command from its local USB terminal and exposes the same setting in WebConfig. On ESP32, it lowers the CPU clock to 80 MHz, enables idle yielding, and enables the configured GPS duty cycle. USB and each active wireless transport remain available; SenseCAP Indicator Full keeps only its selected BLE or infrastructure-WiFi secondary transport active. <code>powersaving off</code> restores the board's normal CPU clock and disables the GPS duty cycle. This device setting is separate from LoRa RXPS (<code>radio.rxps</code>) and WiFi modem power save (<code>wifi.powersave</code>). Infrastructure WebConfig uses the <code>set powersaving</code> form; enabling it can put the node to sleep and make WiFi temporarily unavailable.</p>"},{"location":"cli_commands/#view-or-set-the-reboot-interval-repeater-and-room-server","title":"View or set the reboot interval (Repeater and room server)","text":"<p>Usage: - <code>get reboot.interval</code> - <code>set reboot.interval &lt;hours&gt;</code></p> <p>Parameters: - <code>hours</code>: <code>0-255</code>; <code>0</code> disables scheduled reboots.</p> <p>Default: <code>0</code> (disabled)</p>"},{"location":"cli_commands/#control-an-exposed-gpio","title":"Control an exposed GPIO","text":"<p>Availability: ESP32 Repeater, Room Server, Bridge, and Sensor firmware. Companion firmware does not expose these commands. On nRF52, the commands are enabled only for Sensor builds on the Heltec T096, ProMicro, RAK3401, and RAK4631. GPIO expanders are not supported.</p> <p>Usage:</p> <ul> <li><code>get gpio</code> - list the Arduino pin numbers this firmware build permits</li> <li><code>get gpio state</code>, <code>get gpio states</code>, or <code>get gpio status</code> - list every available pin currently controlled by the user (anything not in <code>reset</code>)</li> <li><code>get gpio state &lt;pin&gt;</code> - show one pin's state; <code>states</code> and <code>status</code> are accepted here too</li> <li><code>get gpio &lt;pin&gt;</code> - show <code>on</code>, <code>off</code>, or <code>reset</code>, plus any pending timed transition</li> <li><code>set gpio &lt;pin&gt; on</code></li> <li><code>set gpio &lt;pin&gt; off</code></li> <li><code>set gpio &lt;pin&gt; reset</code></li> <li><code>set gpio &lt;pin&gt; &lt;on|off&gt; &lt;duration&gt; &lt;on|off|reset&gt;</code></li> </ul> <p>Examples:</p> <ul> <li><code>set gpio 16 on 30 off</code> - drive GPIO16 high for 30 seconds, then drive it low</li> <li><code>set gpio 16 on 5ms off</code> - drive GPIO16 high for 5 milliseconds, then drive it low</li> <li><code>set gpio 16 off 5 reset</code> - drive GPIO16 low for 5 seconds, then return it to high impedance</li> </ul> <p>An integer duration has seconds as its default unit, so <code>5</code> means 5 seconds. Add <code>ms</code> for milliseconds (<code>5ms</code>); an explicit <code>s</code> suffix is also accepted (<code>5s</code>). The maximum duration is 24 hours (86,400 seconds or 86,400,000 milliseconds). <code>on</code> or <code>off</code> without a duration remains in that state until another command, reset, or reboot.</p> <p><code>reset</code> changes the pin to an input with no pull resistor (high impedance). It does not reboot the node. It also cancels any pending timer for that pin. A new timed command for the same pin cancels and replaces the previous timer. GPIOs begin in <code>reset</code>; states and timers are not saved and are lost on reboot.</p> <p>The immediate reply confirms the applied state and any pending transition. When a timed transition finishes, a command issued over the authenticated remote CLI receives a second report such as <code>&gt; GPIO 16 timer complete: off</code>. Retries of the same authenticated timed command are recognized and do not restart its countdown.</p> <p>The pin number is the Arduino pin number used by that target (the normal GPIO number on ESP32 and the board's <code>D</code>/pin index on nRF52). The available-pin list is build-specific. Radio, flash/PSRAM, USB, serial console, display, GPS, I2C, buttons, LEDs, battery measurement, power control, bridge, Ethernet, watchdog, and other pins claimed by the firmware are rejected. A pin must also be physically broken out on your board; <code>get gpio</code> cannot detect wiring or an attached peripheral that is not represented by the firmware configuration.</p> <p>Electrical warning: GPIOs use 3.3 V logic and have limited drive current. Do not power a relay, motor, solenoid, or other load directly from a GPIO. Use a suitable transistor, MOSFET, optocoupler, or driver with the required protection components.</p>"},{"location":"cli_commands/#routing","title":"Routing","text":""},{"location":"cli_commands/#view-or-set-the-direct-path-override-for-the-current-remote-client","title":"View or set the direct path override for the current remote client","text":"<p>Usage: - <code>get outpath</code> - <code>get outpath path</code> - <code>set outpath &lt;hop1_hex,hop2_hex,...&gt;</code> - <code>set outpath path</code> - <code>set outpath direct</code> - <code>set outpath clear</code> - <code>set outpath flood</code></p> <p>Parameters: - <code>hopN_hex</code>: Hop hash with <code>2</code>, <code>4</code>, or <code>6</code> hexadecimal characters. Every hop must use the same width.</p> <p>Notes: - These commands require remote client context and update the caller's ACL entry. - <code>get outpath path</code> reports the reciprocal <code>PAYLOAD_TYPE_PATH</code> received after   the caller's latest flood login without changing the selected output route.   Because that packet is asynchronous, an immediate query can report   <code>&gt; path pending</code>; retry shortly. The observation window expires after one   minute, and the captured login path is not automatically selected. - <code>set outpath path</code> copies that observed route to <code>outpath</code> and saves it. It   returns an error without changing <code>outpath</code> if no route was received. - <code>direct</code> selects a zero-hop route for a directly reachable caller. - <code>clear</code> forgets the override, replies <code>&gt; outpath cleared</code>, and allows normal   path discovery to repopulate it. - <code>flood</code> forces replies to use flood packets until the client logs in again.</p>"},{"location":"cli_commands/#view-or-change-this-nodes-repeat-flag","title":"View or change this node's repeat flag","text":"<p>Usage: - <code>get repeat</code> - <code>set repeat &lt;state&gt;</code></p> <p>Parameters:   - <code>state</code>: <code>on</code>|<code>off</code></p> <p>Default: <code>flood.channel.data on</code>; <code>flood.channel.data.hops h=all</code></p>"},{"location":"cli_commands/#view-or-change-this-nodes-advert-path-hash-size","title":"View or change this node's advert path hash size","text":"<p>Usage: - <code>get path.hash.mode</code> - <code>set path.hash.mode &lt;value&gt;</code></p> <p>Parameters: - <code>value</code>: Path hash size (0-2)   - <code>0</code>: 1 Byte hash size (256 unique ids)[64 max flood]   - <code>1</code>: 2 Byte hash size (65,536 unique ids)[32 max flood]   - <code>2</code>: 3 Byte hash size (16,777,216 unique ids)[21 max flood]   - <code>3</code>: DO NOT USE (Reserved) </p> <p>Default: <code>0</code></p> <p>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 &gt;= 1.14. This feature was added in firmware 1.14</p> <p>Temporary Note: adverts with ID/hash sizes of 2 or 3 bytes may have limited flood propagation 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 supported. Consider your install base of firmware &gt;=1.14 has reached a criticality for effective network flooding before implementing higher ID/hash sizes. </p>"},{"location":"cli_commands/#view-or-change-this-nodes-loop-detection","title":"View or change this node's loop detection","text":"<p>Usage: - <code>get loop.detect</code> - <code>set loop.detect &lt;state&gt;</code></p> <p>Parameters: - <code>state</code>:    - <code>off</code>: no loop detection is performed   - <code>minimal</code>: 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)   - <code>moderate</code>: 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)   - <code>strict</code>: 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)</p> <p>Default: <code>off</code></p> <p>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 (probably 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</p> <p>Example: If preference is <code>loop.detect minimal</code>, 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. </p>"},{"location":"cli_commands/#view-or-change-the-retransmit-delay-factor-for-flood-traffic","title":"View or change the retransmit delay factor for flood traffic","text":"<p>Usage: - <code>get txdelay</code> - <code>set txdelay &lt;value&gt;</code></p> <p>Parameters: - <code>value</code>: Transmit delay factor (0-2)</p> <p>Default: <code>0.5</code></p> <p>Note: When multiple nearby repeaters all hear the same flood packet, each waits a random amount of time before retransmitting to avoid simultaneous collisions. This factor scales the size of that random window. Higher values reduce collision risk at the cost of added latency. <code>0</code> disables the window entirely.</p>"},{"location":"cli_commands/#view-or-change-the-retransmit-delay-factor-for-direct-traffic","title":"View or change the retransmit delay factor for direct traffic","text":"<p>Usage: - <code>get direct.txdelay</code> - <code>set direct.txdelay &lt;value&gt;</code></p> <p>Parameters: - <code>value</code>: Direct transmit delay factor (0-2)</p> <p>Default: <code>0.2</code></p> <p>Note: Same collision-avoidance random window as <code>txdelay</code>, 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.</p>"},{"location":"cli_commands/#experimental-view-or-change-the-processing-delay-for-received-traffic","title":"[Experimental] View or change the processing delay for received traffic","text":"<p>Usage: - <code>get rxdelay</code> - <code>set rxdelay &lt;value&gt;</code></p> <p>Parameters: - <code>value</code>: Receive delay base (0-20)</p> <p>Default: <code>0.0</code></p> <p>Note: When enabled, repeaters that received a flood packet with a weak signal are held in a delay queue before processing, while those that received it with a strong signal process it immediately. This gives strong-signal paths forwarding priority. By the time weak-signal nodes process their copy, the packet may have already propagated and will be suppressed as a duplicate, reducing redundant retransmissions.</p>"},{"location":"cli_commands/#view-or-change-the-duty-cycle-limit","title":"View or change the duty cycle limit","text":"<p>Usage: - <code>get dutycycle</code> - <code>set dutycycle &lt;value&gt;</code></p> <p>Parameters: - <code>value</code>: Duty cycle percentage (1-100)</p> <p>Default: <code>50%</code> (equivalent to airtime factor 1.0)</p> <p>Examples: - <code>set dutycycle 100</code> - no duty cycle limit - <code>set dutycycle 50</code> - 50% duty cycle (default) - <code>set dutycycle 10</code> - 10% duty cycle - <code>set dutycycle 1</code> - 1% duty cycle (strictest EU requirement)</p> <p>Note: Added in firmware v1.15.0</p>"},{"location":"cli_commands/#view-or-change-the-airtime-factor-duty-cycle-limit","title":"View or change the airtime factor (duty cycle limit)","text":"<p>Deprecated as of firmware v1.15.0. Use <code>get/set dutycycle</code> instead.</p> <p>Usage: - <code>get af</code> - <code>set af &lt;value&gt;</code></p> <p>Parameters: - <code>value</code>: 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:   - <code>af = 1</code> -&gt; ~50% duty   - <code>af = 2</code> -&gt; ~33% duty   - <code>af = 3</code> -&gt; ~25% duty   - <code>af = 9</code> -&gt; ~10% duty   You are responsible for choosing a value that is appropriate for your jurisdiction and channel plan (for example EU 868 Mhz 10% duty cycle regulation).</p> <p>Default: <code>1.0</code></p>"},{"location":"cli_commands/#view-or-change-the-local-interference-threshold","title":"View or change the local interference threshold","text":"<p>Usage: - <code>get int.thresh</code> - <code>set int.thresh &lt;value&gt;</code></p> <p>Parameters: - <code>value</code>: Interference threshold value</p> <p>Default: <code>0.0</code></p>"},{"location":"cli_commands/#enable-or-disable-hardware-channel-activity-detection-cad","title":"Enable or disable hardware Channel Activity Detection (CAD)","text":"<p>Usage: - <code>get cad</code> - <code>set cad &lt;on|off&gt;</code></p> <p>Description: When enabled, the radio performs a hardware Channel Activity Detection scan before transmitting and defers if the channel is busy. Runs independently of <code>int.thresh</code> - either, both, or none may be active.</p> <p>The Cascade firmware profile defaults CAD to <code>on</code>; target-default builds continue to default it to <code>off</code>. The repeater applies the saved toggle to the radio during its periodic noise-floor service. With one runnable packet, a busy result uses the normal CAD retry delay and allows roughly four seconds of continuous busy results. As the runnable transmit queue grows, both delays are divided by its depth: retry spacing will not fall below 50 ms and the busy ceiling will not fall below 500 ms. Reaching the busy ceiling records a CAD-timeout error and attempts the next queued transmission rather than waiting indefinitely. Future-scheduled packets do not accelerate CAD. <code>get cad</code> includes the hardware busy-result count.</p> <p>Parameters: - <code>on|off</code>: Enable or disable hardware CAD</p> <p>Default: <code>off</code></p>"},{"location":"cli_commands/#view-or-change-the-agc-reset-interval","title":"View or change the AGC Reset Interval","text":"<p>Usage: - <code>get agc.reset.interval</code> - <code>set agc.reset.interval &lt;value&gt;</code></p> <p>Parameters: - <code>value</code>: Interval in seconds rounded down to a multiple of 4 (17 becomes 16). 0 to disable.</p> <p>Default: <code>0.0</code></p>"},{"location":"cli_commands/#view-or-change-the-radio-watchdog-interval-mqtt-observer-only","title":"View or change the radio watchdog interval (MQTT observer only)","text":"<p>Usage: - <code>get radio.watchdog</code> - <code>set radio.watchdog &lt;minutes&gt;</code></p> <p>Parameters: - <code>minutes</code>: <code>0</code> to disable, or <code>1-120</code> minutes</p> <p>Default: <code>5</code></p> <p>Note: This watchdog belongs to the MQTT observer runtime and is not available on a standalone FULL repeater. On quiet meshes, increasing it can reduce false recoveries when no traffic is expected.</p>"},{"location":"cli_commands/#enable-or-disable-multi-acks-support","title":"Enable or disable Multi-Acks support","text":"<p>Usage: - <code>get multi.acks</code> - <code>set multi.acks &lt;state&gt;</code></p> <p>Parameters: - <code>state</code>: <code>0</code> (disable) or <code>1</code> (enable)</p> <p>Default: <code>0</code></p>"},{"location":"cli_commands/#view-or-change-the-flood-advert-interval","title":"View or change the flood advert interval","text":"<p>Usage: - <code>get flood.advert.interval</code> - <code>set flood.advert.interval &lt;hours&gt;</code></p> <p>Parameters: - <code>hours</code>: Interval in hours (3-168)</p> <p>Default: <code>12</code> (Repeater) - <code>0</code> (Sensor)</p>"},{"location":"cli_commands/#view-or-change-the-zero-hop-advert-interval","title":"View or change the zero-hop advert interval","text":"<p>Usage: - <code>get advert.interval</code> - <code>set advert.interval &lt;minutes&gt;</code></p> <p>Parameters: - <code>minutes</code>: Interval in minutes rounded down to the nearest multiple of 2 (61 becomes 60) (60-240)</p> <p>Default: <code>0</code></p>"},{"location":"cli_commands/#limit-the-number-of-hops-for-a-flood-message","title":"Limit the number of hops for a flood message","text":"<p>Usage: - <code>get flood.max</code> - <code>set flood.max &lt;value&gt;</code></p> <p>Parameters: - <code>value</code>: Maximum flood hop count (0-64)</p> <p>Default: <code>64</code></p>"},{"location":"cli_commands/#limit-the-number-of-hops-for-an-unscoped-flood-message","title":"Limit the number of hops for an unscoped flood message","text":"<p>Usage: - <code>get flood.max.unscoped</code> - <code>set flood.max.unscoped &lt;value&gt;</code></p> <p>Parameters: - <code>value</code>: Maximum flood hop count (0-64) for a packet without a scope (no region set)</p> <p>Default: <code>0xFF</code> - indicates it hasn't been set, will track flood.max until it is.</p> <p>Note: An alternative to <code>region denyf *</code>, setting <code>flood.max.unscoped</code> to a lower value such as <code>3</code> would allow for local unscoped messages to propagate, while preventing noisy neighbors from flooding a local region.</p>"},{"location":"cli_commands/#limit-the-number-of-hops-for-an-advert-flood-message","title":"Limit the number of hops for an advert flood message","text":"<p>Usage: - <code>get flood.max.advert</code> - <code>set flood.max.advert &lt;value&gt;</code></p> <p>Parameters: - <code>value</code>: Maximum flood hop count (0-64) for an advert packet</p> <p>Default: <code>8</code></p>"},{"location":"cli_commands/#forward-flood-group-data-packets-on-repeaters","title":"Forward flood group data packets on repeaters","text":"<p>Usage: - <code>get flood.channel.data</code> - <code>get flood.channel.data.hops</code> - <code>set flood.channel.data &lt;on|off&gt;</code> - <code>set flood.channel.data.hops &lt;all|1-7&gt;</code></p> <p>Parameters: - <code>on</code>: Retransmit received flood <code>GRP_DATA</code> channel packets. - <code>off</code>: Do not retransmit received flood <code>GRP_DATA</code> channel packets. - <code>all</code>: When <code>flood.channel.data</code> is <code>off</code>, block <code>GRP_DATA</code> at any received flood hop count. - <code>1-7</code>: When <code>flood.channel.data</code> is <code>off</code>, repeat <code>GRP_DATA</code> at this hop count or lower and block longer paths.</p> <p>Default: <code>flood.channel.data on</code>; <code>flood.channel.data.hops h=all</code></p> <p>Forwarding behavior: Repeater firmware only. The repeater still receives and logs the packet when logging is enabled; this only blocks retransmission. On generalized repeaters these commands manage an ordinary visible FPF7 <code>type=grp_data</code> drop row. <code>off</code> with <code>all</code> maps to <code>hops=all</code>; <code>off</code> with <code>N</code> maps to <code>hops=N+1+</code>. The 240 KB compact FPF6 profiles retain the legacy hard gate. Because it is an ordinary FPF7 row, a matching higher-priority <code>stop</code> rule can exempt traffic from it. The compact <code>get flood.filter</code> list marks the managed row with <code>~data</code>. Flood group text (<code>GRP_TXT</code>) is unaffected by this setting.</p> <p><code>get flood.channel.data</code> includes the active hop gate as <code>h=all</code> or <code>h&gt;N</code>.</p>"},{"location":"cli_commands/#block-selected-flood-channels-with-fpf7","title":"Block selected flood channels with FPF7","text":"<p>The separate <code>flood.channel.block</code> command and 15-row table have been retired. Generalized repeaters use the 63-row FPF7 forward phase for authenticated channel blocks:</p> <pre><code>set flood.rule type=any channel=#test hops=all drop\nset flood.rule.2 type=any channel=#wardriving hops=5+ drop\nset flood.rule type=any channel=9cd8fcf22a47333b591d96a2b848b73f hops=4+ drop\nget flood.rule\ndel flood.rule.2\n</code></pre> <p><code>type=any</code> with a channel condition can authenticate only <code>GRP_TXT</code> and <code>GRP_DATA</code>, so it does not match other payload types. Use <code>hops=all</code> to block at every received hop count. To preserve the old <code>h=N</code> meaning of repeating through <code>N</code> hops and blocking longer paths, use <code>hops=N+1+</code>; old <code>h=4</code> is therefore <code>hops=5+</code>.</p> <p>New generalized repeater tables seed slot 2 with the second example. Existing FCB2 rows are imported once into free FPF7 slots and the retired file is then removed. The fixed-size STM32WL FPF6 build cannot match authenticated channels.</p>"},{"location":"cli_commands/#force-a-transport-scope-onto-floods","title":"Force a transport scope onto floods","text":"<p>Usage: - <code>get flood.channel.scope</code> - <code>get flood.channel.scope.&lt;n&gt;</code> - <code>set flood.channel.scope &lt;channel|txt:*|login:*|other:*&gt; &lt;region|scope=name&gt; [path=blacklist|path=bucket:1-6] [tx=slow]</code> - <code>set flood.channel.scope.&lt;n&gt; &lt;channel|txt:*|login:*|other:*&gt; &lt;region|scope=name&gt; [path=blacklist|path=bucket:1-6] [tx=slow]</code> - <code>del flood.channel.scope.&lt;n&gt;</code> - <code>del flood.channel.scope all</code></p> <p>Parameters: - <code>n</code>: Slot number within the table compiled for the target. Roomy ESP32 builds   provide <code>1-255</code>; DRAM-tight classic ESP32 LoRa-OTA repeaters and nRF52/other   normal constrained builds provide <code>1-31</code>; very-tight STM32WL repeaters provide   <code>1-15</code>; the no-PSRAM LilyGo T-LoRa V2.1 repeater/observer provides <code>1-4</code>. - <code>channel</code>: <code>public</code>, a public <code>#channel</code>, or a 128/256-bit channel key in hex. - <code>txt:*</code>: Unauthenticated fallback for otherwise-unmatched <code>GRP_TXT</code> and   <code>GRP_DATA</code>. Plain <code>*</code> is an alias for <code>txt:*</code>. - <code>login:*</code>: Type-based wildcard for the remote-login/admin family: <code>REQ</code>,   <code>RESPONSE</code>, <code>TXT_MSG</code>, <code>ANON_REQ</code>, and <code>PATH</code> (<code>0x00</code>, <code>0x01</code>, <code>0x02</code>,   <code>0x07</code>, and <code>0x08</code>). It classifies the outer type; a transit repeater cannot   authenticate whether a packet is actually part of a login session. - <code>other:*</code>: Type-based wildcard for every remaining flood payload type,   including flood-form TRACE, ACK, advert, multipart, control, OTA, reserved   types, and raw custom. - <code>region</code>: Existing named region with a usable transport key. A unique region   name prefix is accepted; wildcard region <code>*</code> is not a scope target. - <code>scope=&lt;name&gt;</code>: Regionless alternative to <code>region</code>. The public name is   normalized with a leading <code>#</code>, and its 128-bit transport key is derived   directly from that hashtag exactly as for <code>flood.filter scope=&lt;name&gt;</code>. It   does not need to exist in the region list. Public names up to 30 characters   are accepted; private <code>$</code> scopes are not. - <code>path=blacklist</code>: Optional. Require the received path to match the passive   <code>flood.filter.blacklist</code> ID table. No <code>flood.filter</code> drop row needs to be   enabled. One exact listed ID qualifies a 3-byte path. A 2-byte path requires   two matching received path entries, while a 1-byte path never qualifies. - <code>path=bucket:&lt;1-6&gt;</code>: Optional alternative to <code>path=blacklist</code>. Match IDs in   the selected persistent <code>flood.retry.bucket</code>. Each bucket holds up to 17   three-byte IDs and remains usable when <code>flood.retry.bridge</code> is off. It uses   the same 3-byte, 2-byte, and 1-byte thresholds as <code>path=blacklist</code>.   <code>recent.repeater</code> freshness and <code>flood.retry.ignore</code> do not affect this   passive match. - <code>tx=slow</code>: Optional. Use an effective inbound <code>rxdelay</code> base of   <code>max(2, configured rxdelay * 2)</code>, keep normal outbound queue priority, and   schedule retransmission with the maximum supported <code>txdelay</code> factor of   <code>2.0</code> after changing the scope. The default is fast; <code>tx=fast</code> may be   supplied explicitly when replacing a slow row.</p> <p>Default: No forced scopes.</p> <p>Remote ACL permission <code>4</code> (region/scope manager) can use all <code>get</code>, <code>set</code>, and <code>del flood.channel.scope</code> forms. Filter managers and other non-admin roles cannot change this table.</p> <p>Without <code>.n</code>, <code>set</code> updates the row for the same exact channel key or wildcard class with the same path selector, otherwise it uses the first empty slot. This permits an ordinary fallback and separate blacklist or bridge-bucket rows for the same channel. With <code>.n</code>, it replaces that slot. The three wildcard classes are independent and consume one slot each. <code>get flood.channel.scope</code> reports active/total slot counts; use the numbered form for row detail. Keyed rows are displayed by the first four bytes of their derived channel hash because channel secrets are never returned. Regionless targets are displayed with their normalized leading <code>#</code>.</p> <p>This acts on received <code>ROUTE_TYPE_FLOOD</code> and <code>ROUTE_TYPE_TRANSPORT_FLOOD</code> packets. An unscoped packet gains the configured scope; an already-scoped packet has its existing transport codes replaced. For <code>GRP_TXT</code> and <code>GRP_DATA</code>, all exact channel-key rows are tried first and must validate the packet MAC/decryption. Matching path-qualified exact rows are   tried before ordinary exact fallback rows. A region-backed row whose target   is missing or unusable is skipped; later exact rows and then <code>txt:*</code> are tried. Exact keyed rows with a usable target therefore beat <code>txt:*</code> regardless of slot number. Within each wildcard class, path-qualified rows similarly precede ordinary fallback rows. <code>login:*</code> and <code>other:*</code> select their non-overlapping outer-type families without decrypting the payload. The lowest usable slot wins within each priority tier.</p> <p>Standard traceroute is direct-routed and is therefore outside this flood-only table. A custom flood-form <code>TRACE</code> is treated like every other flood: an applicable wildcard may rewrite it and region/unknown-code gates still apply.</p> <p>On a match, the repeater sets the route to <code>ROUTE_TYPE_TRANSPORT_FLOOD</code>, computes transport code 0 from the selected region or direct hashtag key and packet payload, and sets transport code 1 to zero. This occurs before region enforcement, forwarding filters, and the seen-packet lookup. For an already-scoped packet, the selected code replaces both incoming transport-code fields. Direct routes are never rewritten. A packet converted from unscoped is no longer subject to <code>flood.max.unscoped</code>; all rewritten packets remain subject to normal payload handling, <code>flood.max</code>, <code>flood.filter</code>, loop detection, and moderation. Assigning a scope does not make a packet type forwardable if the core would otherwise reject it. By default, if the selected scope differs and the rewritten packet is accepted for forwarding, its initial retransmission uses zero <code>txdelay</code> and the highest outbound queue priority so the newly scoped copy can win at the next hop. Adding <code>tx=slow</code> uses an effective inbound <code>rxdelay</code> base of <code>max(2, configured rxdelay * 2)</code>, keeps the ordinary queue priority, and uses the maximum <code>txdelay</code> factor of <code>2.0</code> for the retransmission. As with ordinary <code>txdelay</code>, the actual transmit delay is randomized from zero through the resulting window; factor <code>2.0</code> gives a maximum of ten packet airtimes. Neither mode preempts an active radio transmission or bypasses CAD and airtime-budget limits. Selecting the scope already carried by the packet is a no-op and does not grant special transmit treatment.</p> <p>A region-backed target must be locally flood-allowed and remains subject to the normal region gate. A <code>scope=&lt;name&gt;</code> target is trusted for this matched receive pass even though it has no region-list entry, matching the behavior of <code>flood.filter scope=&lt;name&gt;</code>. It does not create a region, consume a region slot, or change the allow/deny state for unrelated packets carrying the same transport code.</p> <p>If a region-backed row's target has been removed or has no usable key, the repeater tries the next applicable row. For group packets this means later authenticated exact rows followed by <code>txt:*</code>; wildcard duplicates likewise fall through to the next usable slot. When no usable mapping exists, the packet retains its original unscoped or scoped route.</p> <p>LoRa OTA remains functional when <code>other:*</code> is configured. OTA packets are given that target's transport code, replacing an existing code when necessary, but the OTA handler still accepts and re-floods them during the temporary-radio window. A region target must allow flooding; a direct target follows the regionless trust behavior above. The OTA core itself is dormant outside that window; no default flood filter row is needed for that behavior. Forced scope does not make OTA operate outside the window.</p> <p>Capacity cost: Each rule slot retains its 36-byte runtime and persistent record. A separate 32-byte-name table holds up to the smaller of the rule count or 32 distinct regionless targets; very-tight STM32WL builds hold one reusable direct target. Region-backed targets do not consume this table. The four-slot minimum uses 272 bytes RAM and a 278-byte file; it has room for the three wildcard classes plus one exact channel mapping. Very-tight 15-slot builds use 572 bytes RAM and a 578-byte file. The 31-slot table uses 2,108 bytes RAM and a 2,114-byte file. Roomy ESP32 builds use 255 rule slots and 32 direct-target slots: 10,204 bytes RAM and a 10,210-byte file. Classic ESP32 LoRa-OTA builds that cannot afford the 255-rule table use 31 slots instead. Both configured regions and regionless targets can be reused by any number of rules.</p> <p>Duplicate behavior: Mesh dedup hashes payload type and payload bytes; it does not hash route type, transport codes, or the ordinary flood path. Adding a transport scope therefore does not create a new duplicate identity. If the same payload later arrives scoped, unscoped, or through a different region, it is still the same seen packet. <code>TRACE</code> is the exception only in that its encoded <code>path_len</code> byte is also hashed.</p> <p>While equivalent non-TRACE flood copies are waiting in <code>rxdelay</code>, the normal receive-quality timing still selects the packet to process, but that winner receives a scope from the queued scoped copies with the same dedupe identity. If the copies carry different locally allowed scopes, the scope from the shortest received path wins. Unknown and denied transport codes are not candidates and therefore cannot overwrite an unscoped winner. With equal path lengths, the deeper child region wins because it is narrower. A remaining tie keeps queue order. The winner's own path, SNR reading, and scheduled time are not changed, and an already-scoped winner may have its code replaced by the better queued scope.</p> <p>The comparison is deferred until dequeue so each copy retains its original scope and path for arbitration. It can only use copies still present in <code>rxdelay</code>; it cannot replace a packet that already won the dedupe race. Flood-form TRACE participates in this arbitration; direct traceroute does not enter the flood queue.</p> <p>A packet that matches a fast <code>flood.channel.scope</code> or <code>flood.filter scope=</code> action and needs its scope changed bypasses the inbound <code>rxdelay</code> queue. A <code>tx=slow</code> row remains in that queue with twice the configured base, floored at <code>2.0</code>, and participates in normal queued-copy scope arbitration.</p> <p>Examples:</p> <pre><code>region put west\nregion save\nset flood.channel.scope #local west\nset flood.channel.scope.2 txt:* west tx=slow\nset flood.channel.scope.3 login:* west\nset flood.channel.scope.4 other:* west\nget flood.channel.scope\nget flood.channel.scope.1\ndel flood.channel.scope.2\n</code></pre> <p>A regionless exact mapping needs no <code>region</code> command:</p> <pre><code>set flood.channel.scope #rgdata scope=BlackHole86\nget flood.channel.scope\nget flood.channel.scope.1\n</code></pre> <p>For example, if an authenticated <code>#rgdata</code> packet arrives carrying scope <code>#usa</code>, that rule replaces <code>#usa</code> with <code>#BlackHole86</code> before forwarding. The rule also assigns <code>#BlackHole86</code> when the packet is unscoped or carries any other scope; it is a channel-to-target mapping, not an incoming-scope filter.</p> <p>To use bridge bucket 1 to assign <code>east</code> to <code>public</code> packets whose received 3-byte path contains <code>7576FB</code>, while assigning <code>west</code> to every other authenticated <code>public</code> packet:</p> <pre><code>set flood.retry.bucket 1 7576FB\nset flood.channel.scope public west\nset flood.channel.scope public east path=bucket:1\n</code></pre> <p>Additional 3-byte IDs may be added to bucket 1 later; any one exact hit qualifies the <code>east</code> row. This use is passive and does not require <code>flood.retry.bridge</code> to be enabled. The separate blacklist selector remains available for tables shared with <code>flood.filter path=blacklist</code> rules.</p>"},{"location":"cli_commands/#require-valid-incoming-scopes-only-on-selected-channels","title":"Require valid incoming scopes only on selected channels","text":"<p>Usage: - <code>get flood.channel.scope.require</code> - <code>get flood.channel.scope.require.&lt;n&gt;</code> - <code>set flood.channel.scope.require &lt;public|#channel|128/256-bit-key&gt;</code> - <code>set flood.channel.scope.require.&lt;n&gt; &lt;public|#channel|128/256-bit-key&gt;</code> - <code>del flood.channel.scope.require.&lt;n&gt;</code> - <code>del flood.channel.scope.require all</code></p> <p>Default: Empty; normal global region enforcement remains active.</p> <p>Once this table contains a row, received flood <code>GRP_TXT</code> and <code>GRP_DATA</code> packets use selective region enforcement. A packet authenticating against a listed channel key must already carry a transport scope matching a locally flood-allowed region. Listed channels arriving unscoped, with an unknown code, or with a denied region are not retransmitted. This tests the original incoming scope before any <code>flood.channel.scope</code> or <code>flood.filter scope=</code> rewrite. Those rewrite actions are skipped for a rejected listed channel, so they cannot rescue it or grant special receive/transmit timing.</p> <p>Other group channels bypass the region/unknown-code gate while the table is active. They remain subject to every other forwarding control, including <code>repeat</code>, <code>flood.max*</code>, packet filters, loop detection, payload validation, and moderation. Non-channel flood payload types retain normal global region enforcement.</p> <p>Channel matching validates the packet MAC/decryption with the configured key; the visible one-byte channel hash is only a prefilter. Public hashtag channels use their derived public key. Without <code>.n</code>, setting an existing key updates it and a new key uses the first empty slot. Numbered <code>set</code> replaces that slot. <code>get ...&lt;n&gt;</code> reports a four-byte derived prefix and key size without exposing the key. The table uses the same build-dependent slot count as <code>flood.channel.scope</code>.</p> <p>Remote ACL permission <code>4</code> can manage this table. Deleting its final row restores normal global region enforcement for group channels.</p> <p>Example:</p> <pre><code>set flood.channel.scope.require #bot\nget flood.channel.scope.require\nget flood.channel.scope.require.1\n</code></pre>"},{"location":"cli_commands/#change-persistent-flood-rules-in-the-field","title":"Change persistent flood rules in the field","text":"<p>For setup guidance, interactions with the existing forwarding controls, and worked moderation examples, see Flood Filtering and Moderation.</p> <p>Usage: - <code>get flood.rule</code> - <code>get flood.rule.&lt;n&gt;</code> - <code>set flood.rule[.&lt;n&gt;] type=&lt;type&gt; [hops=&lt;range&gt;] [channel=&lt;channel&gt;] [prefix=&lt;path-prefix&gt;] [in=&lt;input-scope&gt;] &lt;drop|scope=&lt;name&gt;|region=&lt;name&gt;|rate=&lt;N&gt;/min|retry|stop&gt; [priority=&lt;0-255&gt;] [tx=slow] [suspend=tempradio]</code> - <code>del flood.rule.&lt;n&gt;</code> - <code>del flood.rule all</code> - <code>get flood.filter</code> - <code>get flood.filter.&lt;n&gt;</code> - <code>get flood.filter.blacklist</code> - <code>get flood.filter.blacklist.&lt;n&gt;</code> - <code>set flood.filter.blacklist &lt;ID[,ID...]&gt;</code> - <code>set flood.filter.blacklist.&lt;n&gt; &lt;ID[,ID...]&gt;</code> - <code>del flood.filter.blacklist</code> - <code>del flood.filter.blacklist.&lt;n&gt;</code> - <code>set flood.filter &lt;type&gt; [hops] [path=blacklist] [scope=&lt;name&gt;] [require=region] [tx=slow] [suspend=tempradio]</code> - <code>set flood.filter.&lt;n&gt; &lt;type&gt; [hops] [path=blacklist] [scope=&lt;name&gt;] [require=region] [tx=slow] [suspend=tempradio]</code> - <code>del flood.filter.&lt;n&gt;</code> - <code>del flood.filter all</code></p> <p>The extended table is available on repeaters with the rule engine enabled and on FULL-profile ESP32 room servers. A FULL room server exposes both <code>flood.rule</code> and <code>flood.filter</code>, has 31 slots, and requires an administrator for remote changes. It does not have the repeater's passive path blacklist, so <code>flood.filter.blacklist*</code> and <code>path=blacklist</code> are repeater-only; use the ordered <code>prefix=</code> match on a room server. Standard room-server profiles do not compile this table.</p> <p>Parameters: - <code>n</code>: Forward-rule slot in the build's compiled table (<code>1-63</code> on generalized   repeaters and <code>1-31</code> on FULL room servers; compact profiles may use fewer). - <code>type</code>: Payload type name, full <code>PAYLOAD_TYPE_*</code> name, decimal value <code>0-15</code>,   hexadecimal value <code>0x00-0x0F</code>, or <code>any</code>. - <code>hops</code>: Optional; omitted means <code>all</code>.   - <code>N</code>: Match only at received hop count <code>N</code>.   - <code>N+</code>: Match at received hop count <code>N</code> and higher.   - <code>N-M</code>: Match the inclusive received-hop range.   - <code>all</code>: Match every received hop count (<code>0-63</code>).   - <code>0+</code>, <code>all</code>, and an omitted hop expression are equivalent. The CLI displays     the saved range as <code>all</code>. - <code>channel=*|public|#name|hash:XX|128-bit-key|256-bit-key</code>: Optional channel match.   <code>channel=*</code> means no channel condition at all, so the row matches everything   selected by <code>type=</code> (including all flood payload types with <code>type=any</code>). It   does not authenticate a packet. <code>public</code>, <code>#name</code>, and raw keys authenticate   one channel and therefore narrow the row to <code>GRP_TXT</code>/<code>GRP_DATA</code>.   <code>hash:XX</code> matches only the visible one-byte group-channel hash; <code>short:XX</code>   and a bare two-digit byte are accepted aliases and are displayed as   <code>hash:XX</code>. This form is deliberately unauthenticated. It can collide with   another channel once in 256 hash values, and a sender can choose the byte,   so use an exact channel name or key whenever it is available. In particular,   <code>channel=hash:11</code> does not mean Public: it matches Public plus every collision   or deliberately selected <code>0x11</code> value. <code>channel=public</code> performs the deeper   MAC/decrypt check with the Public channel key. That distinguishes an ordinary   <code>0x11</code> collision, but it is channel authentication rather than sender   authentication: the group MAC is two bytes and the Public key is shared. - <code>prefix=&lt;ID[,ID...]&gt;</code>: Optional ordered source-path prefix of one to three   pbyte IDs. IDs must all be 2, 4, or 6 hex characters, matching a packet's   1-, 2-, or 3-byte pbyte width. <code>path=&lt;prefix&gt;</code> is an alias. - <code>in=any|none|scoped|allowed|unknown|scope:&lt;name&gt;|region:&lt;name&gt;</code>: Optional   condition on the original incoming scope, before any rule rewrites it.   <code>none</code> is an unscoped flood. <code>scope:name</code> is the exact public   hashtag-derived scope. <code>region:name</code> is an exact allowed region match. - <code>drop</code>: Explicit drop action. The <code>flood.rule</code> form requires an explicit   action. For compatibility, a legacy <code>flood.filter</code> row with no rewrite,   rate, or stop action is treated as drop. - <code>scope=&lt;name&gt;</code>: Direct public-name scope rewrite. It derives a transport key   from the name and does not require a configured region. For example,   <code>scope=BlackHole86</code> is a regionless sink scope; <code>region=BlackHole86</code> would   instead require a real configured, flood-allowed region with that name. - <code>region=&lt;name&gt;</code>: Rewrite using an existing locally allowed region and one of   that region's transport keys. - <code>rate=N/min</code>: Per-node, per-row fixed one-minute forwarding limit. It can be   the only action or accompany <code>scope=</code>/<code>region=</code>. Counters are charged only   for packets that pass all forwarding gates. - <code>retry</code>, <code>retry=on</code>, <code>retry=allow</code>, or <code>action=retry</code>: Allow a matching   received flood packet to enter the configured flood-retry sequence. With no   active <code>retry</code> rows, retry eligibility remains backward compatible and is   controlled by the global retry settings. Once any active <code>retry</code> row exists,   the matching rows become a retry allow-list: a received flood must match at   least one surviving <code>retry</code> row. <code>flood.retry.bridge</code> still selects ordinary   or bridge-bucket completion for the allowed packet. This action can accompany   rewrite, rate, or stop, but not <code>drop</code>; compact syntax uses <code>f=r</code>. - <code>priority=0-255</code>: Optional primary processing order. Higher values run first.   At the same numeric priority, authenticated channel matches run before raw   <code>hash:XX</code> matches, which run before <code>channel=*</code>; lower slot number breaks the   remaining tie. The default is <code>0</code>; <code>pri=</code> is an alias. An explicitly higher   numeric priority still overrides this automatic specificity ordering. - <code>stop</code> or <code>action=stop</code>: Apply this matching row, then stop lower-order FPF7   rows from processing. It can stand alone or accompany drop, rewrite, or   rate. A stop-only row acts as an exception to lower-priority FPF7 rules.   If the same row uses <code>region=</code> and that configured region is missing, denied,   wildcard, or has no usable transport key, both the rewrite and its <code>stop</code>   are inert so lower-order safety rows still run. A direct <code>scope=</code> target does   not depend on region configuration. - <code>suspend=tempradio</code>: Optional. Skip this row only while the temporary radio   is actually active. - <code>require=region</code>: Legacy alias for <code>in=allowed</code>. Apply the row only if the   original incoming packet already passes this repeater's   region gate. An incoming transport scope must resolve to a locally allowed   region; an unscoped flood must be allowed by the wildcard region. The check   occurs before any scope rewrite during this receive pass. - <code>tx=slow</code>: Optional and valid with <code>scope=</code> or <code>region=</code>. Use an effective inbound   <code>rxdelay</code> base of <code>max(2, configured rxdelay * 2)</code>, keep normal outbound   queue priority, and retransmit with the maximum supported <code>txdelay</code> factor   of <code>2.0</code>. Scope rows default to fast; <code>tx=fast</code> explicitly restores that   default when replacing a slow row. - <code>path=blacklist</code>: Optional unordered path condition. The persistent blacklist   is repeater-only. It contains up to 255 unique 3-byte repeater IDs on ESP32   builds and 18 on other builds, each written as six hexadecimal digits. A   packet with 3-byte path hashes matches after one exact ID hit. A packet with   2-byte path hashes matches after two path entries match the first two bytes   of listed IDs. Packets with 1-byte path hashes never match this condition.   Each received path entry is counted at most once.</p> <p>The payload names follow the MeshCore packet-format allocation:</p> Value Short name Full name <code>0x00</code> <code>req</code> <code>PAYLOAD_TYPE_REQ</code> <code>0x01</code> <code>response</code> <code>PAYLOAD_TYPE_RESPONSE</code> <code>0x02</code> <code>txt_msg</code> <code>PAYLOAD_TYPE_TXT_MSG</code> <code>0x03</code> <code>ack</code> <code>PAYLOAD_TYPE_ACK</code> <code>0x04</code> <code>advert</code> <code>PAYLOAD_TYPE_ADVERT</code> <code>0x05</code> <code>grp_txt</code> <code>PAYLOAD_TYPE_GRP_TXT</code> <code>0x06</code> <code>grp_data</code> <code>PAYLOAD_TYPE_GRP_DATA</code> <code>0x07</code> <code>anon_req</code> <code>PAYLOAD_TYPE_ANON_REQ</code> <code>0x08</code> <code>path</code> <code>PAYLOAD_TYPE_PATH</code> <code>0x09</code> <code>trace</code> <code>PAYLOAD_TYPE_TRACE</code> <code>0x0A</code> <code>multipart</code> <code>PAYLOAD_TYPE_MULTIPART</code> <code>0x0B</code> <code>control</code> <code>PAYLOAD_TYPE_CONTROL</code> <code>0x0C</code> <code>ota</code> <code>PAYLOAD_TYPE_OTA</code> (this fork's LoRa OTA extension; reserved upstream) <code>0x0D</code> <code>13</code> reserved <code>0x0E</code> <code>14</code> reserved <code>0x0F</code> <code>raw_custom</code> <code>PAYLOAD_TYPE_RAW_CUSTOM</code> <p>Route scope: Rules are evaluated only for the two flood route values: <code>ROUTE_TYPE_TRANSPORT_FLOOD</code> (<code>0x00</code>, flood plus transport codes) and <code>ROUTE_TYPE_FLOOD</code> (<code>0x01</code>, unscoped flood). Direct routes <code>0x02</code> and <code>0x03</code> are never affected.</p> <p>Behavior: Match fields within one row are ANDed. Every FPF7 row is matched against the same immutable receive-time packet, before any rule changes its scope. Matching rows are processed in descending <code>priority</code>. At equal numeric priority, authenticated channel matches precede raw hashes, which precede an unrestricted channel matcher; lower slot wins after that. The first matching <code>stop</code> row is included and all lower-order FPF7 matches are discarded. A stop cannot undo an earlier drop or bypass hard forwarding gates or the other policy phases. A row with <code>path=blacklist</code> must meet the path condition as well as its other conditions; blacklist IDs can occur anywhere in the received path and their configured order is irrelevant. In contrast, <code>prefix=</code> begins at the first received path entry and preserves order. A matching drop row prevents retransmission. The highest-order remaining matching scope/region row wins; matching drop and rate rows remain independent and can still block the rewritten packet. Scope rewriting happens before region enforcement and is trusted even when its name is absent from the local region list. It does not bypass <code>repeat</code>, <code>flood.max</code>, other drop rows, loop detection, or moderation.</p> <p>Retry selection uses that same ordered, stop-truncated match set. With at least one active <code>retry</code> row, a received flood starts a retry sequence only when one of those matching rows includes <code>retry</code>. This selector cannot override <code>flood.retry.count</code>, path/type attempt caps, <code>flood.retry.advert</code>, disabled forwarding, a drop decision, or any other hard forwarding gate. Locally originated floods retain the normal global retry behavior.</p> <p>With <code>require=region</code>, a failed check makes that scope row ineligible. It leaves the packet unchanged and does not set the filter-scope trust bypass, so an unknown or denied incoming region is rejected normally unless another independent scope rule rewrites it. Later eligible filter scope rows may still match.</p> <p>By default, when a scope row will change the packet's transport codes, the packet bypasses inbound <code>rxdelay</code>; its retransmission then uses zero <code>txdelay</code> and the highest outbound queue priority. With <code>tx=slow</code>, the rewrite instead uses an effective inbound <code>rxdelay</code> base of <code>max(2, configured rxdelay * 2)</code>, normal queue priority, and the maximum <code>txdelay</code> factor of <code>2.0</code>. The actual randomized transmit wait ranges from zero to ten packet airtimes. Selecting the scope already carried is a no-op and does not grant special treatment. An active radio transmission is not preempted, and CAD and airtime-budget limits still apply.</p> <p>The packet is still received and can still be logged. Rules are persistent data and can be changed over serial or authenticated remote CLI without an OTA or reboot. <code>flood.rule</code> and <code>flood.filter</code> address the same table on extended builds; FPF6 files are migrated in memory and the next save writes FPF7. FPF1-FPF5 files are rejected and filtering fails open. FPF7 stores canonical region names rather than transient numeric region IDs. Removing, reordering, or reusing a region ID therefore cannot silently retarget a rule. If a saved input or target region name is absent, that input match or rewrite is inert; restoring the same region name reactivates it. While the temporary radio is active, only rows explicitly marked <code>suspend=tempradio</code> are skipped. <code>tempradio</code> is a radio state, not an OTA mode; normal payload types can also use the temporary channel. Other rows remain in force. A malformed persisted table fails open (no general rules are applied).</p> <p>Within one receive evaluation, rows that use the same channel key share one authentication result. The cache is discarded after that packet and stores neither plaintext nor passwords; different keys are authenticated separately. Raw <code>hash:XX</code> rows skip this authentication and compare only the one visible byte.</p> <p>Per-channel retry examples:</p> <pre><code># Use bridge-bucket retry only for authenticated Public and #hamradio traffic.\nset flood.retry.bridge on\nset flood.rule.2 type=any channel=public retry\nset flood.rule.3 type=any channel=#hamradio retry\n\n# If the channel key/name is unavailable, select visible channel hash A7.\n# This is an unauthenticated 1-byte hint, not a channel identity.\nset flood.rule.4 type=any channel=hash:A7 retry\n</code></pre> <p>Because Public's visible hash is <code>0x11</code>, a bare <code>hash:11 drop</code> row also matches Public. To exempt authenticated Public while dropping other packets that carry the same visible byte, put the exact Public rule first and stop lower-priority rules after it:</p> <pre><code># Retry and preserve authenticated Public; drop other channel-hash 11 packets.\nset flood.rule.2 type=any channel=public retry stop\nset flood.rule.3 type=any channel=hash:11 drop\n</code></pre> <p>The Public row matches only after its MAC/decrypt check succeeds. A colliding channel therefore misses that <code>stop</code> and reaches the raw-hash drop row. Both rows use the default numeric priority, but authenticated-channel specificity automatically orders Public first even if its slot number is higher. Without <code>stop</code>, both rows match Public and the sticky <code>drop</code> action wins. Omit <code>retry</code> from the Public row when only the forwarding exemption is wanted. An operator can deliberately reverse this order by assigning the hash row a higher numeric <code>priority</code>.</p> <p>Deleting or replacing the last active <code>retry</code> row restores the legacy global retry eligibility. Firmware that predates the <code>retry</code>/<code>hash:XX</code> FPF7 extension cannot preserve tables containing those rows; remove them before downgrading.</p> <p>Default row: Repeater firmware and FULL ESP32 room-server firmware seed a new flood-filter table with <code>ota all suspend=tempradio</code> in slot 1. This blocks repeated LoRa OTA (<code>0x0C</code>) floods at every received hop unless temporary radio is actually active. The OTA core independently refuses OTA receive, relay, and transmit outside temporary radio. The row is editable and deletable; once the table is saved, deletion is persistent. Restore the exact seeded row with:</p> <pre><code>set flood.filter.1 0x0C all suspend=tempradio\n</code></pre> <p>Omitting <code>all</code> is equivalent. Omit <code>.1</code> as well to reuse an identical rule or the first empty slot instead of replacing slot 1.</p> <p>Remote-admin lockout warning: There are no hidden payload-type or short-hop exceptions. FPF7 drop and rate rows may block <code>req</code>, <code>response</code>, <code>txt_msg</code>, <code>anon_req</code>, <code>path</code>, ACK, and multipart traffic beginning at hop <code>0</code> when their match fields say so. Transit repeaters cannot decrypt these outer types to distinguish an admin exchange from ordinary peer traffic. Keep a serial or other recovery path and stage broad deny/rate rules carefully.</p> <p>Without <code>.n</code>, <code>set</code> reuses an identical rule or uses the first empty slot. With <code>.n</code>, it replaces that slot, which is the intended way to change a row's match or action. <code>get flood.filter</code> or <code>get flood.rule</code> gives a compact list. Use the numbered form for full details, including channel, prefix, original-scope condition, action, timing, rate, and temporary-radio suspension.</p> <p>If all of those fields plus long names would exceed one CLI reply, the numbered form automatically switches to a non-truncating compact spelling. The compact aliases are also accepted by <code>set</code>: <code>c=</code> means <code>channel=</code>, <code>p=</code> means <code>prefix=</code>, <code>i=*|n|s|a|u|s:&lt;scope&gt;|r:&lt;region&gt;</code> means the corresponding <code>in=</code> condition, <code>q=N</code> means <code>rate=N/min</code>, <code>pri=N</code> means priority, and <code>f=str</code> combines slow timing (<code>s</code>), temporary-radio suspension (<code>t</code>), and retry allowance (<code>r</code>). Packet type is shown numerically in that fallback. Normal-sized rows keep the descriptive spelling above.</p> <p>On generalized repeaters, filter rows, scope-rewrite rows, the shared blacklist, and <code>flood.channel.data</code> compatibility state are committed in one atomic FPF7 image. Compact FPF6 profiles retain separate files. Replacing or deleting the blacklist does not delete rows containing <code>path=blacklist</code>; such rows remain dormant while the list is empty. Path hashes are truncated routing identifiers, not authenticated identities, so this is a forwarding signal rather than proof that a particular repeater handled a packet.</p> <p>A common use is containment of bulk internet-to-mesh dumping: list the path IDs associated with the offending gateways, then add a broad <code>type=any hops=all path=blacklist drop</code> row. This prevents this repeater from retransmitting matching floods; it does not delete them from local logs or prove who originated them.</p> <p>The unnumbered blacklist <code>set</code> replaces the whole list and accepts up to 18 IDs so it fits every CLI transport. Numbered <code>set</code> writes up to 18 consecutive entries beginning at an existing slot or exactly the next slot, allowing an ESP32 list to grow to 255 entries in batches. Numbered deletion compacts subsequent slots. The unnumbered <code>get</code> reports the total and as many leading IDs as fit in one reply; use numbered <code>get</code> to inspect entries beyond that reply.</p> <p>Standard traceroute is direct-routed and therefore outside <code>flood.filter</code> entirely. A custom flood-form trace participates normally: <code>type=any</code>, explicit <code>trace</code>, rewrite, rate, drop, and stop rows can all apply.</p> <p>Examples:</p> <pre><code>set flood.rule.2 type=grp_data hops=4+ channel=#rgdata in=none scope=BlackHole86\nset flood.rule.3 type=grp_data channel=#rgdata in=scope:usa scope=BlackHole86\nset flood.rule.4 type=any prefix=860C rate=10/min\nset flood.rule.5 type=grp_data hops=0-2 channel=#rgdata priority=200 stop\nget flood.rule.2\nset flood.filter grp_data 4+\nset flood.filter.2 PAYLOAD_TYPE_ADVERT 6+\nset flood.filter ota 2-4\nset flood.filter.1 0x0C all suspend=tempradio\nset flood.filter grp_data all suspend=tempradio\nset flood.filter grp_txt all scope=local\nset flood.filter grp_data all scope=local require=region\nset flood.filter grp_data all path=blacklist scope=local tx=slow\nset flood.filter.blacklist A1B2C3,D4E5F6,112233\nset flood.filter.blacklist.4 445566\nset flood.filter.blacklist.19 778899,AABBCC,DDEEFF\nset flood.filter any all path=blacklist\nget flood.filter.blacklist\nget flood.filter.blacklist.4\nset flood.filter any 12+\nget flood.filter\nget flood.filter.2\ndel flood.filter.2\n</code></pre> <p>The first rule authenticates <code>#rgdata</code>, requires more than three received hops, and adds <code>#BlackHole86</code> only when no scope was present. The second rewrites the exact incoming <code>#usa</code> scope. The third demonstrates a two-byte pbyte source prefix and a global per-row rate cap. The fourth authenticates <code>#rgdata</code> at zero through two hops, applies no FPF7 action of its own, and stops lower-order FPF7 forward rows; hard gates and the rewrite/moderation phases still apply.</p> <p>The fixed 240 KB STM32WL profiles leave <code>MESH_ENABLE_FLOOD_RULE_ENGINE=0</code> and retain the compact, persistent FPF6 <code>flood.filter</code> and blacklist commands. They still filter floods, but do not expose the <code>flood.rule</code> alias or its extended channel, prefix, input-scope, region-action, or rate fields. No partition size changes are required.</p>"},{"location":"cli_commands/#moderate-flood-group-text-by-channel-sender-and-source-path","title":"Moderate flood group text by channel, sender, and source path","text":"<p>Usage: - <code>get flood.moderation</code> - <code>get flood.moderation.&lt;n&gt;</code> - <code>set flood.moderation &lt;channel&gt; &lt;sender&gt; &lt;action&gt; [action...]</code> - <code>set flood.moderation.&lt;n&gt; &lt;channel&gt; &lt;sender&gt; &lt;action&gt; [action...]</code> - <code>del flood.moderation.&lt;n&gt;</code> - <code>del flood.moderation all</code></p> <p>Parameters: - <code>n</code>: Moderation slot from <code>1</code> to <code>16</code>. - <code>channel</code>:   - <code>public</code>: Built-in Public channel.   - <code>#channel</code>: Derive the well-known hashtag-channel key.   - A 128-bit or 256-bit channel key in hex, for any other/private channel. - <code>sender</code>: Exact group-text display name. Matching is ASCII case-insensitive.   Quote names containing spaces, for example <code>\"Field User\"</code>. - <code>drop</code>: Do not forward matching messages. Equivalent to <code>rate=0/min</code>. - <code>rate=X/min</code>: Forward at most <code>X</code> matching messages per 60-second local   window. This option requires an exact sender rather than <code>*</code>. - <code>hops=N</code>: Do not forward a matching message whose received flood path count   is <code>N</code> or higher. <code>hops=all</code> removes this constraint. - <code>path=H1[,H2,H3]</code>: Match the start of the flood path. One to three hashes are   accepted; every hash must have the same 1-, 2-, or 3-byte width. - <code>path=*</code>: Match any source path (the default).</p> <p>At least one of <code>drop</code>, <code>rate=X/min</code>, or <code>hops=N</code> is required. Rate and hop limits can be combined. Rate counters are local to this repeater and rule, use a 60-second window beginning with the first matching message, and reset on reboot.</p> <p>Decode and identity behavior: Moderation applies only to flood <code>PAYLOAD_TYPE_GRP_TXT</code>. The repeater first checks the packet's channel-hash byte, then validates and decrypts with the configured key. It extracts the text before the first <code>:</code> from the standard <code>&lt;sender&gt;: &lt;message&gt;</code> plaintext. The channel key is stored locally but is never printed by <code>get</code>.</p> <p>The group-text sender is an unverified display name, not a public key. It can be spoofed. Combining it with the first one to three path hashes makes a more useful moderation signal, but path hashes are truncated and are not proof of the originating user. A path-qualified rule begins matching only after the packet contains all configured starting hops; it cannot identify a first hop on a zero-hop packet.</p> <p>As with general filtering, matching messages are still received/logged; only retransmission is denied. There are no moderation rules by default.</p> <p>Examples:</p> <pre><code>set flood.moderation public \"Noisy User\" rate=5/min\nset flood.moderation #local bot drop path=A1B2C3,D4E5F6\nset flood.moderation.3 00112233445566778899AABBCCDDEEFF alice rate=10/min hops=4 path=71CE82\nget flood.moderation\nget flood.moderation.3\ndel flood.moderation.3\n</code></pre>"},{"location":"cli_commands/#acl","title":"ACL","text":""},{"location":"cli_commands/#add-update-or-remove-permissions-for-a-companion","title":"Add, update or remove permissions for a companion","text":"<p>Usage:  - <code>setperm &lt;pubkey&gt; &lt;permissions&gt;</code></p> <p>Parameters: - <code>pubkey</code>: Companion public key - <code>permissions</code>:    - <code>0</code>: Guest   - <code>1</code>: Read-only   - <code>2</code>: Read-write   - <code>3</code>: Admin   - <code>4</code>: Region/scope manager (repeater delegated region and forced-scope management)   - <code>5</code>: Filter manager (repeater delegated forwarding-filter management)</p> <p>Filter manager scope: Permission <code>5</code> can use an explicit allowlist of non-secret operational/filter status commands and can change the forwarding controls <code>repeat</code>, <code>loop.detect</code>, <code>flood.max*</code>, <code>flood.channel.data*</code>, <code>flood.filter*</code>, <code>flood.rule*</code>, and <code>flood.moderation*</code>. It cannot read guest, WiFi, MQTT, bridge, or other credentials, and it cannot change regions, ACL entries, radio settings, or other admin configuration. Permission <code>4</code> is limited to region commands, <code>flood.channel.scope*</code>, and the same non-secret status allowlist. Both delegated manager roles are protected from least-recently-active ACL eviction like administrators.</p> <p>Note: Removes the entry when <code>permissions</code> is omitted</p>"},{"location":"cli_commands/#view-the-current-acl","title":"View the current ACL","text":"<p>Usage:  - <code>get acl</code></p> <p>Serial Only: Yes</p>"},{"location":"cli_commands/#recover-a-repeaters-future-dated-replay-timestamp","title":"Recover a repeater's future-dated replay timestamp","text":"<p>This is an explicit recovery operation after correcting a bad clock, not a contact deletion. It lowers selected replay timestamps to the repeater's current UTC epoch only when they are later than that epoch. Earlier values, public keys, permissions, stored paths, and historical identity records remain. The replay file is committed before the live table changes. No extra 60-second login reservation is added by this command.</p> <p>First set/synchronize and verify the repeater's clock (<code>clock</code>); a build-default clock without a manual or observed synchronization is not accepted. Also fix the companion's clock before its next login.</p> <p>USB console:</p> <pre><code>replay reset &lt;full-64-hex-public-key&gt;\nreplay reset all CONFIRM\n</code></pre> <p>Authenticated LoRa admin, including a resumed admin session:</p> <pre><code>replay reset &lt;full-64-hex-public-key&gt;\n</code></pre> <p>The reply shows <code>now=&lt;epoch&gt;</code>, <code>ttl=&lt;remaining-seconds&gt;s</code>, and a confirmation command containing the same full key and a one-use 32-hex-character token. Verify the displayed time and send that command before the original 300-second deadline. During the first 120 seconds, repeated requests for the same key by the same admin return the same token without restarting either timer. From 120 through 300 seconds, the token is retained for confirmation only: requests do not resend or replace it. This leaves at least 180 seconds to deliver a confirmation after the last permitted token response is generated (radio transit time still counts toward expiry). At 300 seconds it expires and a new request can receive a new token. Confirmation can succeed immediately; there is no requirement to wait for the resend window to close. The displayed TTL decreases on retries and is measured when the reply is generated, not when it reaches the companion.</p> <p>It can target the caller's own key or another exact key; prefixes, <code>self</code>, wildcards, and <code>all</code> are not allowed over LoRa. Tokens are bound to both the requesting admin and target, expire on reboot, and are invalid after use or a clock correction outside the five-second confirmation tolerance. A failed write requires a new confirmation. Challenge requests consult live token state instead of replaying cached challenge text; completed confirmation results remain cacheable without executing the reset again. Normal packet freshness checks still apply to retries.</p> <p>Only the physical serial console grants <code>all</code> access. Ethernet, browser and internal command callbacks do not count as USB. Guest, read-only, region-manager and filter-manager roles cannot reset replay state. This command is implemented in repeater firmware; room-server and sensor CLI are unchanged.</p> <p>Normal login and command admission checks remain in force: a fully locked-out caller that cannot send an accepted admin command needs another working admin or USB access. A corrupt/unreadable replay file fails closed and is not erased or formatted by this operation. Unknown keys do not create records.</p> <p>Security trade-off: lowering a replay boundary can admit previously captured future-dated login/command packets above the new boundary, including packets that could raise it again. The one-use token prevents the recovery command itself from being repeatedly executed; it does not replace the protocol's timestamp-based replay protection. Use recovery only after verifying clocks. Setting a clock alone never automatically resets this table.</p>"},{"location":"cli_commands/#view-or-change-this-room-servers-read-only-flag","title":"View or change this room server's 'read-only' flag","text":"<p>Usage: - <code>get allow.read.only</code> - <code>set allow.read.only &lt;state&gt;</code></p> <p>Parameters: - <code>state</code>: <code>on</code> (enable) or <code>off</code> (disable)</p> <p>Default: <code>off</code></p>"},{"location":"cli_commands/#region-management-v110","title":"Region Management (v1.10.+)","text":""},{"location":"cli_commands/#bulk-load-region-lists","title":"Bulk-load region lists","text":"<p>Usage:  - <code>region load</code> - <code>region load &lt;name&gt; [flood_flag]</code></p> <p>Parameters: - <code>name</code>: A name of a region. <code>*</code> represents the wildcard region</p> <p>Note: <code>flood_flag</code>: Optional <code>F</code> to allow flooding</p> <p>Note: Indentation creates parent-child relationships (max 8 levels)</p> <p>Note: <code>region load</code> with an empty name will not work remotely (it's interactive)</p>"},{"location":"cli_commands/#save-any-changes-to-regions-made-since-reboot","title":"Save any changes to regions made since reboot","text":"<p>Usage:  - <code>region save</code></p>"},{"location":"cli_commands/#allow-a-region","title":"Allow a region","text":"<p>Usage:  - <code>region allowf &lt;name&gt;</code></p> <p>Parameters:  - <code>name</code>: Region name (or <code>*</code> for wildcard)</p> <p>Note: Setting on wildcard <code>*</code> allows packets without region transport codes</p>"},{"location":"cli_commands/#block-a-region","title":"Block a region","text":"<p>Usage:  - <code>region denyf &lt;name&gt;</code></p> <p>Parameters:  - <code>name</code>: Region name (or <code>*</code> for wildcard)</p> <p>Note: Setting on wildcard <code>*</code> drops packets without region transport codes</p>"},{"location":"cli_commands/#show-information-for-a-region","title":"Show information for a region","text":"<p>Usage:  - <code>region get &lt;name&gt;</code></p> <p>Parameters: - <code>name</code>: Region name (or <code>*</code> for wildcard)</p>"},{"location":"cli_commands/#view-or-change-the-home-region-for-this-node","title":"View or change the home region for this node","text":"<p>Usage:  - <code>region home</code> - <code>region home &lt;name&gt;</code></p> <p>Parameters: - <code>name</code>: Region name</p>"},{"location":"cli_commands/#view-or-change-the-default-scope-region-for-this-node","title":"View or change the default scope region for this node","text":"<p>Usage:  - <code>region default</code> - <code>region default {name|&lt;null&gt;}</code></p> <p>Parameters: - <code>name</code>: Region name,  or  to reset/clear"},{"location":"cli_commands/#create-a-new-region","title":"Create a new region","text":"<p>Usage:  - <code>region put &lt;name&gt; [parent_name]</code></p> <p>Parameters: - <code>name</code>: Region name - <code>parent_name</code>: Parent region name (optional, defaults to wildcard)</p> <p>Note: In firmware v1.15.0 and later, <code>region put</code> enables flooding for that region by default (you do not need a separate <code>region allowf &lt;name&gt;</code> after each <code>put</code>). On v1.14.0 and earlier, new regions may still require <code>region allowf</code> for flooding-see <code>region allowf</code>.</p>"},{"location":"cli_commands/#define-region-hierarchy-single-line","title":"Define region hierarchy (single line)","text":"<p>Usage: - <code>region def &lt;token&gt; [&lt;token&gt; ...]</code></p> <p>Parameters (tokens): Space-separated. A logical cursor starts at the wildcard <code>*</code>.</p> <ul> <li><code>name</code> - Create <code>name</code> as a child of the current cursor (equivalent to <code>region put name</code> with the cursor as parent). Cursor moves to <code>name</code>.</li> <li><code>name|jump</code> (or <code>name,jump</code>) - Create <code>name</code> as a child of the current cursor, then move the cursor to <code>jump</code> (must already exist on the node, or have been created earlier in this command). <code>jump</code> is not the parent of <code>name</code>; use this form to pop back up and start another branch.</li> </ul> <p>Behavior: Each created region defaults to flood-allowed (same as <code>region put</code>). The reply is the resulting region tree (same format as bare <code>region</code>); review it before running <code>region save</code> to persist. The command is transactional: invalid names, unknown or ambiguous jumps, table overflow, and hierarchy cycles return <code>Err - ...</code> without changing the existing tree.</p> <p>Existing regions: <code>region def</code> does not clear the existing tree - if a name already exists, its parent is updated to the current cursor; otherwise a new region is created. To start from scratch, <code>region remove</code> the unwanted regions first.</p> <p>Limits: Repeater serial accepts one line up to 160 characters. For larger trees, split across multiple <code>region def</code> commands; the cursor resets to <code>*</code> between commands, so lead the next command with <code>child|ancestor</code> to reposition. Each token splits at most once on <code>|</code> - <code>region def a|b|c|d</code> is not a flat-list shorthand; see the flat-list example below.</p> <p>Example - linear chain (each token becomes a child of the previous):</p> <pre><code>region def a b c d e\nregion save\n</code></pre> <p>Example - branched tree (equivalent to <code>region put a</code>, <code>region put b a</code>, <code>region put c b</code>, <code>region put d c</code>, <code>region put e b</code>, <code>region put f e</code>):</p> <pre><code>region def a b c d|b e f\nregion save\n</code></pre> <p>Example - transactional error:</p> <pre><code>region def a b c|nope d\n</code></pre> <p>The reply is <code>Err - unknown or ambiguous jump: nope</code>. The existing tree is unchanged; re-run with a corrected jump.</p> <p>Example - flat list (each region a child of <code>*</code>). Use <code>|*</code> after each token to pop the cursor back to the root before the next token:</p> <pre><code>region def a|* b|* c|* d|* e|* f\nregion save\n</code></pre>"},{"location":"cli_commands/#remove-a-region","title":"Remove a region","text":"<p>Usage:  - <code>region remove &lt;name&gt;</code></p> <p>Parameters: - <code>name</code>: Region name</p> <p>Note: Must remove all child regions before the region can be removed </p>"},{"location":"cli_commands/#view-all-regions","title":"View all regions","text":"<p>Usage:  - <code>region list &lt;filter&gt;</code></p> <p>Serial Only: Yes</p> <p>Parameters: - <code>filter</code>: <code>allowed</code>|<code>denied</code></p> <p>Note: Requires firmware 1.12+</p>"},{"location":"cli_commands/#dump-all-defined-regions-and-flood-permissions","title":"Dump all defined regions and flood permissions","text":"<p>Usage:  - <code>region</code></p> <p>Serial Only: For firmware older than 1.12.0</p>"},{"location":"cli_commands/#region-examples","title":"Region Examples","text":"<p>Example 1: Using F Flag with Named Public Region</p> <pre><code>region load\n#Europe F\n&lt;blank line to end region load&gt;\nregion save\n</code></pre> <p>Explanation: - Creates a region named <code>#Europe</code> with flooding enabled - Packets from this region will be flooded to other nodes</p> <p>Example 2: Using Wildcard with F Flag</p> <pre><code>region load \n* F\n&lt;blank line to end region load&gt;\nregion save\n</code></pre> <p>Explanation: - Creates a wildcard region <code>*</code> with flooding enabled - Enables flooding for all regions automatically - Applies only to packets without transport codes</p> <p>Example 3: Using Wildcard Without F Flag</p> <pre><code>region load \n*\n&lt;blank line to end region load&gt;\nregion save\n</code></pre> <p>Explanation: - Creates a wildcard region <code>*</code> without flooding - This region exists but doesn't affect packet distribution - Used as a default/empty region</p> <p>Example 4: Nested Public Region with F Flag</p> <pre><code>region load \n#Europe F\n  #UK\n    #London\n    #Manchester\n  #France\n    #Paris\n    #Lyon\n&lt;blank line to end region load&gt;\nregion save\n</code></pre> <p>Explanation: - Creates <code>#Europe</code> region with flooding enabled - Adds nested child regions (<code>#UK</code>, <code>#France</code>) - All nested regions inherit the flooding flag from parent</p> <p>Example 5: Wildcard with Nested Public Regions</p> <pre><code>region load \n* F\n  #NorthAmerica\n    #USA\n      #NewYork\n      #California\n    #Canada\n      #Ontario\n      #Quebec\n&lt;blank line to end region load&gt;\nregion save\n</code></pre> <p>Explanation: - Creates wildcard region <code>*</code> with flooding enabled - Adds nested <code>#NorthAmerica</code> hierarchy - Enables flooding for all child regions automatically - Useful for global networks with specific regional rules</p>"},{"location":"cli_commands/#direct-retry","title":"Direct Retry","text":"<p>Direct retry resends direct-routed packets when the downstream echo is not heard. It applies to direct messages, ACK packets, multipart packets carrying ACK payloads, and TRACE packets.</p> <p>The shared state, count, base, and step controls work on repeater, room-server, and sensor firmware. Recent-repeater/SNR controls are repeater-only because the other roles do not keep the repeater reachability table they require.</p>"},{"location":"cli_commands/#view-or-change-direct-retry-state","title":"View or change direct retry state","text":"<p>Usage: - <code>get direct.retry</code> - <code>set direct.retry &lt;state&gt;</code></p> <p>Parameters: - <code>state</code>: <code>on</code>|<code>off</code></p> <p>Default: <code>on</code></p> <p>Notes: - New installs and older preference files without direct retry settings default to <code>on</code> with the <code>rooftop</code> preset.</p> <p>Examples:</p> <pre><code>get direct.retry\nset direct.retry on\nset direct.retry off\n</code></pre>"},{"location":"cli_commands/#view-or-change-direct-retry-heard-table-gate","title":"View or change direct retry heard-table gate","text":"<p>Usage: - <code>get direct.retry.heard</code> - <code>set direct.retry.heard &lt;state&gt;</code></p> <p>Parameters: - <code>state</code>: <code>on</code>|<code>off</code></p> <p>Default: <code>on</code></p> <p>Note: This command is repeater-only. When enabled, the recent repeater table is the direct retry eligibility gate. Prefixes missing from the table are assumed reachable; prefixes in the table below the active SNR gate are blocked.</p> <p>Examples:</p> <pre><code>get direct.retry.heard\nset direct.retry.heard on\nset direct.retry.heard off\n</code></pre>"},{"location":"cli_commands/#view-or-apply-a-retry-preset","title":"View or apply a retry preset","text":"<p>Usage: - <code>get retry.preset</code> - <code>set retry.preset &lt;preset&gt;</code></p> <p>Parameters: - <code>preset</code>: <code>infra</code>|<code>rooftop</code>|<code>mobile</code></p> <p>Notes: - Applies shared direct retry and flood retry defaults. - <code>infra</code>: fewer, slower retries for stable fixed infrastructure. - <code>rooftop</code>: default long retry window for weak rooftop links. - <code>mobile</code>: long retry count with shorter spacing for moving or changing links; flood retry count is <code>15</code>. - Changing <code>direct.retry.count</code>, <code>direct.retry.base</code>, <code>direct.retry.step</code>, <code>direct.retry.margin</code>, <code>flood.retry.count</code>, <code>flood.retry.path</code>, or <code>flood.retry.group.path</code> makes the preset report as <code>custom</code>.</p> <p>Examples:</p> <pre><code>get retry.preset\nset retry.preset infra\nset retry.preset rooftop\nset retry.preset mobile\n</code></pre>"},{"location":"cli_commands/#flood-retry","title":"Flood Retry","text":"<p>Flood retry resends flood-routed packets when the same packet is not heard from another qualifying repeater.</p> <p>The count, path, group-data path, and advert controls work on repeater, room-server, and sensor firmware. Flood forwarding must also be enabled for retries to run. Prefix, ignore, bridge, and bucket controls are repeater-only.</p>"},{"location":"cli_commands/#view-or-change-flood-retry-count","title":"View or change flood retry count","text":"<p>Usage: - <code>get flood.retry.count</code> - <code>set flood.retry.count &lt;count&gt;</code></p> <p>Parameters: - <code>count</code>: Base retry attempts after the original send, from <code>0</code> to <code>15</code>. <code>0</code> disables flood retry.</p> <p>Note: The role first calculates its retry count: path count 0 uses <code>count * 2</code>, path count 1 uses <code>count * 1.5</code> rounded up, and path count 2 and higher uses the configured base count, with a hard cap of <code>15</code>. A shared payload policy then applies to every build: <code>REQ</code> never retries; <code>GRP_TXT</code> keeps the role-calculated count; remote-login-critical <code>RESPONSE</code>, <code>TXT_MSG</code>, <code>ANON_REQ</code>, and <code>PATH</code> packets keep up to <code>15</code> at the originating node (path count 0) and cap at <code>2</code> after entering the path; all other flood payload types cap at <code>1</code>. These caps never raise a lower role-calculated count. Setting <code>count</code> to <code>0</code> immediately removes queued and future flood retries; a packet already transmitting is allowed to finish.</p> <p>Forwarded neighbor adverts have an additional loop guard independent of the advert retry setting. After this node completes an advert transmission and hears a downstream copy with a longer path, it does not forward that same advert again while the advert's signed timestamp is less than six hours old. Self-originated adverts, adverts without a heard echo, and adverts six hours old or older are unaffected.</p> <p>An enabled self-originated advert retry waits at least one additional minute beyond the normal airtime-aware retry delay. Once a newer self advert has successfully entered the outbound queue, its retry sequence replaces queued or future retries for older self adverts; an older advert already transmitting is allowed to finish. Companion firmware permits this single slow retry for its own adverts while continuing to block retry attempts for neighbor adverts it forwards.</p> <p>Defaults: - <code>infra</code>: <code>1</code> - <code>rooftop</code>: <code>3</code> - <code>mobile</code>: <code>15</code></p> <p>Examples:</p> <pre><code>get flood.retry.count\nset flood.retry.count 0\nset flood.retry.count 15\n</code></pre>"},{"location":"cli_commands/#view-or-change-flood-retry-path-gate","title":"View or change flood retry path gate","text":"<p>Usage: - <code>get flood.retry.path</code> - <code>set flood.retry.path &lt;count|off&gt;</code></p> <p>Parameters: - <code>count</code>: Maximum flood path hash count eligible for retry, from <code>0</code> to <code>63</code>. - <code>off</code>: Disable the path-length gate.</p> <p>Defaults: - <code>infra</code>: <code>1</code> - <code>rooftop</code>: <code>2</code> - <code>mobile</code>: <code>1</code></p> <p>Examples:</p> <pre><code>get flood.retry.path\nset flood.retry.path 1\nset flood.retry.path off\n</code></pre>"},{"location":"cli_commands/#view-or-change-the-group-data-flood-retry-path-gate","title":"View or change the group-data flood retry path gate","text":"<p>Usage: - <code>get flood.retry.group.path</code> - <code>set flood.retry.group.path &lt;count|off&gt;</code></p> <p>Parameters: - <code>count</code>: Maximum flood path hash count eligible for retry for group data packets (<code>PAYLOAD_TYPE_GRP_DATA</code>/type 6), from <code>0</code> to <code>63</code>. - <code>off</code>: Disable only the group-data-specific gate. The general <code>flood.retry.path</code> gate still applies.</p> <p>Default: <code>1</code> for <code>infra</code>, <code>rooftop</code>, and <code>mobile</code> presets.</p> <p>Note: The stricter of <code>flood.retry.path</code> and <code>flood.retry.group.path</code> is used. A value of <code>1</code> allows retry sequences at path counts <code>0</code> and <code>1</code>; group data at path count <code>2</code> or higher is still forwarded normally but does not start a flood retry sequence. A value of <code>0</code> allows retries only at the originating sender.</p> <p>Setting <code>flood.retry.path</code> to <code>0</code> also sets <code>flood.retry.group.path</code> to <code>off</code> because the general zero-hop gate is already stricter. While the general gate remains <code>0</code>, attempts to set the group-data gate keep it <code>off</code>. Applying a named retry preset restores the group-data default of <code>1</code>.</p> <p>Examples:</p> <pre><code>get flood.retry.group.path\nset flood.retry.group.path 1\nset flood.retry.group.path off\n</code></pre>"},{"location":"cli_commands/#view-or-change-flood-retry-advert-handling","title":"View or change flood retry advert handling","text":"<p>Usage: - <code>get flood.retry.advert</code> - <code>set flood.retry.advert &lt;on|off&gt;</code></p> <p>Parameters: - <code>on</code>: Retry node advert floods. - <code>off</code>: Do not retry node advert floods.</p> <p>Default: <code>off</code></p> <p>Examples:</p> <pre><code>get flood.retry.advert\nset flood.retry.advert off\n</code></pre>"},{"location":"cli_commands/#view-or-change-flood-retry-target-prefixes","title":"View or change flood retry target prefixes","text":"<p>Usage: - <code>get flood.retry.prefixes</code> - <code>set flood.retry.prefixes &lt;prefixes|none|off&gt;</code></p> <p>Parameters: - <code>prefixes</code>: Comma-separated 3-byte path hash prefixes, up to 8 entries. - <code>none</code> or <code>off</code>: Clear the list.</p> <p>Note: When set, non-bridge flood retry only accepts same-packet echoes whose last hop matches one of these prefixes. When unset, any non-ignored last hop can cancel the retry.</p> <p>Examples:</p> <pre><code>get flood.retry.prefixes\nset flood.retry.prefixes A58296,860CCA,425E5C\nset flood.retry.prefixes none\n</code></pre>"},{"location":"cli_commands/#view-or-change-flood-retry-ignored-prefixes","title":"View or change flood retry ignored prefixes","text":"<p>Usage: - <code>get flood.retry.ignore</code> - <code>set flood.retry.ignore &lt;prefixes|none|off&gt;</code></p> <p>Parameters: - <code>prefixes</code>: Comma-separated 3-byte path hash prefixes, up to 8 entries. - <code>none</code> or <code>off</code>: Clear the list.</p> <p>Note: Non-bridge flood retry does not cancel on same-packet echoes whose last hop matches this list. Bridge mode also excludes these prefixes from bucket and <code>other</code> hits.</p> <p>Examples:</p> <pre><code>get flood.retry.ignore\nset flood.retry.ignore 71CE82,C7618C\nset flood.retry.ignore none\n</code></pre>"},{"location":"cli_commands/#view-or-change-flood-retry-bridge-mode","title":"View or change flood retry bridge mode","text":"<p>Usage: - <code>get flood.retry.bridge</code> - <code>set flood.retry.bridge &lt;on|off&gt;</code></p> <p>Note: Bridge mode retries until each configured fresh bucket, plus the non-source <code>other</code> bucket, has been heard or the retry count is exhausted. If prefixes in different buckets share their first byte, configuration commands return a warning because a 1-byte path cannot distinguish those buckets. The configuration remains valid: an ambiguous source is treated as belonging to every matching source bucket, and an ambiguous echo credits every matching target bucket so it cannot force retry exhaustion.</p> <p>Flood retry timing retains its fixed maximum-frame plus 20 packet-airtime wait, then adds a random <code>0-200%</code> of one additional packet airtime on every attempt. This de-synchronizes repeaters that may have missed the same echo while capping the added wait at two frames.</p> <p>Only one active retry sequence is kept for a given logical flood packet. An identical flood can still transmit normally, but it does not create a second sequence of extra attempts. Retry state is released if a queued packet is evicted, and the final echo window retains metadata without reserving a packet-pool entry.</p> <p>Bridge reachability learned from earlier hops in a successful echo is cached separately from <code>recent.repeater</code>. Only the final RF hop updates <code>recent.repeater</code> and its SNR, so indirect path entries cannot affect direct-retry SNR gating or coding-rate selection.</p> <p>Examples:</p> <pre><code>get flood.retry.bridge\nset flood.retry.bridge on\n</code></pre>"},{"location":"cli_commands/#view-or-change-flood-retry-bridge-buckets","title":"View or change flood retry bridge buckets","text":"<p>Usage: - <code>get flood.retry.bucket.&lt;n&gt;</code> - <code>set flood.retry.bucket &lt;n&gt; &lt;prefixes|none|off&gt;</code></p> <p>Parameters: - <code>n</code>: Bucket number from <code>1</code> to <code>6</code>. - <code>prefixes</code>: Comma-separated 3-byte path hash prefixes, up to 17 entries per bucket. - <code>none</code> or <code>off</code>: Clear the bucket.</p> <p>Examples:</p> <pre><code>get flood.retry.bucket.1\nset flood.retry.bucket 1 71CE82,C7618C\nset flood.retry.bucket 2 none\n</code></pre>"},{"location":"cli_commands/#view-or-change-direct-retry-count","title":"View or change direct retry count","text":"<p>Usage: - <code>get direct.retry.count</code> - <code>set direct.retry.count &lt;count&gt;</code></p> <p>Parameters: - <code>count</code>: Maximum retry attempts after the original send, from <code>1</code> to <code>15</code>.</p> <p>Default: <code>15</code> with the <code>rooftop</code> preset</p> <p>Note: Direct-routed type 2 text packets always use 21 retry attempts in the shared retry logic, regardless of this setting or the repeater short-path cap.</p> <p>Examples:</p> <pre><code>get direct.retry.count\nset direct.retry.count 1\nset direct.retry.count 4\nset direct.retry.count 15\n</code></pre>"},{"location":"cli_commands/#view-or-change-direct-retry-base-delay","title":"View or change direct retry base delay","text":"<p>Usage: - <code>get direct.retry.base</code> - <code>set direct.retry.base &lt;ms&gt;</code></p> <p>Parameters: - <code>ms</code>: First retry wait in milliseconds, from <code>10</code> to <code>5000</code>.</p> <p>Default: <code>175</code> with the <code>rooftop</code> preset</p> <p>Explanation: - The first retry waits for <code>base + packet-length add-on + random forwarding jitter</code>   after the preceding transmission completes. - TRACE and   ANON_REQ/type 7 packets use a 3x line-time add-on. TXT_MSG/type 2   packets use 7x. Other direct retry packets use 6x. - Room-server and sensor firmware use this configured base with the same   packet-type add-ons. - Larger values reduce channel pressure and give slow repeaters more time. - Smaller values recover faster but create tighter retry bursts.</p> <p>Examples:</p> <pre><code>get direct.retry.base\nset direct.retry.base 175\nset direct.retry.base 275\nset direct.retry.base 500\n</code></pre>"},{"location":"cli_commands/#view-or-change-direct-retry-step-delay","title":"View or change direct retry step delay","text":"<p>Usage: - <code>get direct.retry.step</code> - <code>set direct.retry.step &lt;ms&gt;</code></p> <p>Parameters: - <code>ms</code>: Extra milliseconds added for each subsequent retry, from <code>0</code> to <code>5000</code>.</p> <p>Default: <code>100</code> with the <code>rooftop</code> preset</p> <p>Explanation: - Retry delay is <code>base + packet-length add-on + random forwarding jitter + attempt_index * step</code>. - TRACE and ANON_REQ/type 7 packets   use a 3x packet-length add-on. TXT_MSG/type 2 packets use 7x.   Other direct retry packets use 6x. - Room-server and sensor firmware use this configured step with the same   packet-type add-ons. - With <code>base=175</code> and <code>step=100</code>, the fixed portion is <code>175</code>, <code>275</code>, <code>375</code>,   <code>475</code> ms, and so on, before the packet-length add-on and random jitter. - <code>step=0</code> keeps every retry at the same delay. - Larger steps spread retries over time and are safer on busy channels.</p> <p>Examples:</p> <pre><code>get direct.retry.step\nset direct.retry.step 0\nset direct.retry.step 50\nset direct.retry.step 100\nset direct.retry.step 250\n</code></pre>"},{"location":"cli_commands/#view-or-change-direct-retry-snr-margin","title":"View or change direct retry SNR margin","text":"<p>Usage: - <code>get direct.retry.margin</code> - <code>set direct.retry.margin &lt;snr_db&gt;</code></p> <p>Parameters: - <code>snr_db</code>: Extra SNR margin above the SF receive floor, from <code>0</code> to <code>40</code>.</p> <p>Default: <code>5.00</code> with the <code>rooftop</code> preset</p> <p>Notes: - This command is repeater-only. - Unknown repeaters are still retried. - Known repeaters below the receive floor plus this margin are skipped. - Failed attempts lower the recent repeater SNR estimate by <code>0.25 dB</code>.</p> <p>Examples:</p> <pre><code>get direct.retry.margin\nset direct.retry.margin 0\nset direct.retry.margin 2.5\nset direct.retry.margin 5\nset direct.retry.margin 10\n</code></pre>"},{"location":"cli_commands/#view-or-change-adaptive-direct-retry-coding-rate","title":"View or change adaptive direct retry coding rate","text":"<p>Usage: - <code>get direct.retry.cr</code> - <code>set direct.retry.cr off</code> - <code>set direct.retry.cr on</code> (room-server and sensor) - <code>set direct.retry.cr &lt;cr4_min&gt;,&lt;cr5_min&gt;,&lt;cr7_min&gt;,&lt;cr8_max&gt;</code></p> <p>Parameters: - <code>cr4_min</code>: Minimum SNR in dB to retry at CR4. - <code>cr5_min</code>: Minimum SNR in dB to retry at CR5. - <code>cr7_min</code>: Minimum SNR in dB to retry at CR7. - <code>cr8_max</code>: Maximum SNR in dB that forces CR8.</p> <p>Default: <code>10.00,7.50,2.50,2.50</code></p> <p>Explanation: - Higher SNR uses faster coding rates. - Lower SNR uses more robust coding rates. - Repeater retry attempts escalate from the adaptive starting CR. CR4 starts as CR4, CR5, CR7, CR7, then CR8. CR5 starts as CR5, CR7, CR7, then CR8. CR7 gets two attempts, then CR8. - Repeater adaptive CR selection intentionally skips CR6. - Non-repeater retry packets start at the current radio CR and follow the same escalation pattern, clamped at CR8. With the normal CR5 radio setting this is CR5, CR7, CR7, then CR8. - Room-server and sensor firmware accept <code>on</code> or <code>off</code>; numeric SNR thresholds   are repeater-only because those roles do not keep recent-repeater SNR data. - <code>off</code> disables per-packet retry CR overrides and uses the current radio CR. - Retry packets may use a different coding rate, but they keep the radio's normal physical preamble. - Unknown repeaters start at <code>+3.00 dB</code> for adaptive CR selection. - A failed unknown repeater is seeded at <code>+2.75 dB</code>. - Each later failure lowers the SNR estimate by <code>0.25 dB</code>.</p> <p>Examples:</p> <pre><code>get direct.retry.cr\nset direct.retry.cr off\nset direct.retry.cr on\nset direct.retry.cr 10.0,7.5,2.5,2.5\nset direct.retry.cr 12.0,8.0,4.0,1.0\nset direct.retry.cr 8.0,5.0,1.5,0\nset direct.retry.cr 6.0,3.0,0,-2.0\nset direct.retry.cr 20.0,12.0,6.0,2.0\nset direct.retry.cr 4.0,2.0,0,-4.0\n</code></pre> <p>Example profiles: - Conservative weak-link profile:</p> <pre><code>set direct.retry.cr 12.0,8.0,4.0,1.0\n</code></pre> <ul> <li>Balanced rooftop profile:</li> </ul> <pre><code>set direct.retry.cr 10.0,7.5,2.5,2.5\n</code></pre> <ul> <li>Faster strong-link profile:</li> </ul> <pre><code>set direct.retry.cr 6.0,3.0,0,-2.0\n</code></pre> <ul> <li>Very cautious noisy-link profile:</li> </ul> <pre><code>set direct.retry.cr 20.0,12.0,6.0,2.0\n</code></pre>"},{"location":"cli_commands/#view-seed-or-clear-the-recent-repeater-table","title":"View, seed, or clear the recent repeater table","text":"<p>Usage: - <code>get recent.repeater</code> - <code>get recent.repeater &lt;page&gt;</code> - <code>get recent.repeaters &lt;page&gt;</code> - <code>get recent.repeaters search &lt;prefix&gt; [page]</code> - <code>set recent.repeater &lt;prefix&gt; [snr_db]</code> - <code>clear recent.repeater</code></p> <p>Parameters: - <code>prefix</code>: Repeater path-hash prefix as 2, 4, or 6 hex characters. - <code>snr_db</code>: Optional SNR in dB. If omitted or invalid, defaults to <code>3.0</code>. - <code>page</code>: 1-based result page.</p> <p>Note: These commands are repeater-only.</p> <p>Output order: - <code>get recent.repeater</code> lists 3-byte prefixes first, then 2-byte prefixes, then 1-byte prefixes. - Within each prefix length, entries are sorted from highest SNR to lowest SNR. - <code>search</code> returns every overlapping path-hash entry. For example, searching   <code>860C</code> can return <code>86</code>, <code>860C</code>, and <code>860CCA</code>; it does not return a different   branch such as <code>86D0</code>. - Search rows include the monotonic age of the entry's most recent recording,   compacted to a whole <code>s</code>, <code>m</code>, or <code>h</code> field. Search pages contain up to six   rows so the result remains within the remote CLI reply limit.</p> <p>SNR details: - Recent repeater SNR is stored internally in quarter-dB units. - Heard repeater samples update an existing table entry with a weighted blend: <code>75%</code> existing SNR and <code>25%</code> new heard SNR, rounded up. - Direct retry success also feeds the heard echo SNR back into the same weighted table. - Direct retry failure is not weighted: each final echo-timeout failure lowers that repeater's SNR by <code>0.25 dB</code>. - Unknown repeaters start at <code>+3.00 dB</code> for adaptive CR selection. - If an unknown repeater fails, it is seeded into the table at <code>+2.75 dB</code>. - <code>set recent.repeater &lt;prefix&gt; [snr_db]</code> seeds a missing prefix or adds another weighted sample for an existing prefix. - Successful <code>set recent.repeater</code> replies include the stored prefix and SNR, for example <code>OK - set A1B2C3 at 3.0 SNR</code>. - Entries strictly older than 24 hours are removed during a sweep every three hours, so an entry can remain for at most approximately 27 hours.</p> <p>Examples:</p> <pre><code>get recent.repeater\nget recent.repeater 2\nget recent.repeaters search 86\nget recent.repeaters search 860C page 2\nset recent.repeater A1B2C3 8.5\nset recent.repeater 71CE82 -3.25\nset recent.repeater A1B2C3\nclear recent.repeater\n</code></pre>"},{"location":"cli_commands/#gps-when-gps-support-is-compiled-in","title":"GPS (When GPS support is compiled in)","text":""},{"location":"cli_commands/#view-or-change-gps-state","title":"View or change GPS state","text":"<p>Usage: - <code>gps</code> - <code>gps &lt;state&gt;</code></p> <p>Parameters: - <code>state</code>: <code>on</code>|<code>off</code></p> <p>Default: <code>off</code></p> <p>Note: Output format: - <code>off</code> when the GPS hardware is disabled - <code>on, {active|deactivated}, {fix|no fix}, {sat count} sats</code> when the GPS hardware is enabled</p>"},{"location":"cli_commands/#sync-this-nodes-clock-with-gps-time","title":"Sync this node's clock with GPS time","text":"<p>Usage:  - <code>gps sync</code></p> <p>The GPS must be enabled. When GPS power saving has put an enabled receiver to sleep, this command schedules a sync and wakes it; after <code>gps off</code>, it reports <code>gps is off</code> without scheduling work.</p>"},{"location":"cli_commands/#set-this-nodes-location-based-on-the-gps-coordinates","title":"Set this node's location based on the GPS coordinates","text":"<p>Usage:  - <code>gps setloc</code></p>"},{"location":"cli_commands/#view-or-change-the-gps-advert-policy","title":"View or change the GPS advert policy","text":"<p>Usage: - <code>gps advert</code> - <code>gps advert &lt;policy&gt;</code></p> <p>Parameters:  - <code>policy</code>: <code>none</code>|<code>share</code>|<code>prefs</code>    - <code>none</code>: don't include location in adverts   - <code>share</code>: share gps location (from SensorManager)   - <code>prefs</code>: location stored in node's lat and lon settings</p> <p>Default: <code>prefs</code> on every repeater, room-server, and sensor build that uses the common advert policy. A previously saved <code>none</code>, <code>share</code>, or <code>prefs</code> choice still overrides the first-boot default after an update.</p>"},{"location":"cli_commands/#sensors-when-sensor-support-is-compiled-in","title":"Sensors (When sensor support is compiled in)","text":""},{"location":"cli_commands/#view-or-change-telemetry-access-mode","title":"View or change telemetry access mode","text":"<p>Usage: - <code>get telemetry.access</code> - <code>set telemetry.access &lt;mode&gt;</code></p> <p>Parameters: - <code>mode</code>: <code>all</code>|<code>acl</code>   - <code>all</code>: allow telemetry requests using the requester-provided telemetry mask   - <code>acl</code>: require ACL read-only or higher for telemetry, including GPS</p> <p>Default: <code>all</code></p> <p>Note: <code>all</code> matches the previous sensor telemetry behavior.</p>"},{"location":"cli_commands/#view-the-list-of-sensors-on-this-node","title":"View the list of sensors on this node","text":"<p>Usage: <code>sensor list [start]</code></p> <p>Parameters: - <code>start</code>: Optional starting index (defaults to 0)</p> <p>Note: Output format: <code>&lt;var_name&gt;=&lt;value&gt;\\n</code></p>"},{"location":"cli_commands/#view-or-change-the-value-of-a-sensor","title":"View or change the value of a sensor","text":"<p>Usage:  - <code>sensor get &lt;key&gt;</code> - <code>sensor set &lt;key&gt; &lt;value&gt;</code></p> <p>Parameters: - <code>key</code>: Sensor setting name - <code>value</code>: The value to set the sensor to</p>"},{"location":"cli_commands/#bridge-when-bridge-support-is-compiled-in","title":"Bridge (When bridge support is compiled in)","text":""},{"location":"cli_commands/#view-the-compiled-bridge-type","title":"View the compiled bridge type","text":"<p>Usage: <code>get bridge.type</code></p>"},{"location":"cli_commands/#view-or-change-the-bridge-enabled-flag","title":"View or change the bridge enabled flag","text":"<p>Usage: - <code>get bridge.enabled</code> - <code>get bridge.running</code> - <code>set bridge.enabled &lt;state&gt;</code></p> <p>Parameters: - <code>state</code>: <code>on</code>|<code>off</code></p> <p><code>bridge.enabled</code> is the saved intent. <code>bridge.running</code> reports whether the bridge actually started in this boot; they can differ after a hardware conflict, missing credentials, or a transient initialization failure. Normal merged repeater images default to <code>off</code>; dedicated bridge images may default to <code>on</code>.</p>"},{"location":"cli_commands/#add-a-delay-to-packets-routed-through-this-bridge","title":"Add a delay to packets routed through this bridge","text":"<p>Usage: - <code>get bridge.delay</code> - <code>set bridge.delay &lt;ms&gt;</code></p> <p>Parameters: - <code>ms</code>: Delay in milliseconds (0-10000)</p> <p>Default: <code>500</code></p>"},{"location":"cli_commands/#view-or-change-the-source-of-packets-bridged-to-the-external-interface","title":"View or change the source of packets bridged to the external interface","text":"<p>Usage: - <code>get bridge.source</code> - <code>set bridge.source &lt;source&gt;</code></p> <p>Parameters: - <code>source</code>:   - <code>rx</code>: bridges received packets   - <code>tx</code>: bridges transmitted packets</p> <p>Default: <code>tx</code></p> <p>Note: For MQTT bridges, use <code>mqtt.rx</code> and <code>mqtt.tx</code> instead of <code>bridge.source</code>. These provide independent per-direction control and support both RX and TX simultaneously. <code>bridge.source</code> still works as a convenience alias for MQTT (setting <code>bridge.source rx</code> sets <code>mqtt.rx on</code> + <code>mqtt.tx off</code>, and vice versa), but <code>mqtt.rx</code>/<code>mqtt.tx</code> are preferred.</p>"},{"location":"cli_commands/#view-or-change-mqtt-rx-packet-uplinking","title":"View or change MQTT RX packet uplinking","text":"<p>Usage: - <code>get mqtt.rx</code> - <code>set mqtt.rx &lt;on|off&gt;</code></p> <p>Parameters: - <code>on</code>: uplink received (RX) packets to MQTT brokers - <code>off</code>: disable RX packet uplinking</p> <p>Default: <code>on</code></p>"},{"location":"cli_commands/#view-or-change-mqtt-tx-packet-uplinking","title":"View or change MQTT TX packet uplinking","text":"<p>Usage: - <code>get mqtt.tx</code> - <code>set mqtt.tx &lt;on|off|advert&gt;</code></p> <p>Parameters: - <code>on</code>: uplink all transmitted (TX) packets to MQTT brokers - <code>advert</code>: uplink only this node's own advert packets (self-originated advertisements only - forwarded adverts from other nodes are filtered out) - <code>off</code>: disable TX packet uplinking</p> <p>Default: <code>advert</code></p> <p>Note: <code>mqtt.rx</code> and <code>mqtt.tx</code> take effect immediately - no restart required. Both can be enabled simultaneously.</p>"},{"location":"cli_commands/#view-or-change-periodic-neighbors-publishing-mqtt-observer-neighbors-feature","title":"View or change periodic neighbors publishing (MQTT observer, neighbors feature)","text":"<p>Usage: - <code>get mqtt.neighbors</code> - <code>set mqtt.neighbors &lt;on|off&gt;</code></p> <p>Parameters: - <code>on</code>: periodically discover neighbor scopes and publish the neighbor table to the <code>neighbors</code> topic - <code>off</code>: disable periodic neighbors publishing</p> <p>Default: <code>off</code></p> <p>Note: Requires a build with the neighbors feature compiled in (all PSRAM boards, plus non-PSRAM boards built with <code>MQTT_NEIGHBORS_WITHOUT_PSRAM</code>); elsewhere this replies <code>Err - neighbors not enabled in this build</code>. Non-PSRAM builds publish at most 20 neighbours per pass to bound internal-DRAM use, and set <code>truncated</code> with the true <code>total_neighbors</code> when the table is larger. The setting is read live by the mesh loop - no restart required; enabling it triggers a discovery on the next pass. While enabled, <code>get mqtt.status</code> gains a trailing <code>nbr: &lt;next&gt;/&lt;last&gt;</code> field (time to next publish, and how the last publish went).</p>"},{"location":"cli_commands/#view-or-change-the-neighbors-publish-interval-mqtt-observer-neighbors-feature","title":"View or change the neighbors publish interval (MQTT observer, neighbors feature)","text":"<p>Usage: - <code>get mqtt.neighbors.interval</code> - <code>set mqtt.neighbors.interval &lt;hours&gt;</code></p> <p>Parameters: - <code>hours</code>: how often to publish the neighbor table (12-336, default 24)</p> <p>Default: <code>24</code> (hours)</p> <p>Note: Out-of-range values are rejected (not clamped). Requires a build with <code>WITH_MQTT_NEIGHBORS</code>; PSRAM boards enable it automatically and selected non-PSRAM variants opt in with <code>MQTT_NEIGHBORS_WITHOUT_PSRAM</code>.</p>"},{"location":"cli_commands/#view-or-change-the-ntp-server-mqtt-observer-only","title":"View or change the NTP server (MQTT observer only)","text":"<p>Usage: - <code>get mqtt.ntp</code> - <code>set mqtt.ntp &lt;hostname&gt;</code> - <code>set mqtt.ntp none</code></p> <p>Description: Sets the primary NTP server used for clock sync (required for JWT MQTT auth). On <code>set</code>, the device attempts an immediate sync of the just-configured server (primary only, so a typo fails fast) when WiFi is connected and the MQTT bridge is running.</p> <p>Fallbacks: If the primary fails, the firmware tries <code>pool.ntp.org</code>, <code>time.google.com</code>, <code>time.cloudflare.com</code>, <code>time.aws.com</code>, and <code>time.nist.gov</code> in order (skipping duplicates).</p> <p>Default: <code>pool.ntp.org</code> (when unset or <code>none</code>)</p>"},{"location":"cli_commands/#diagnose-ntp-server-connectivity-mqtt-observer-only","title":"Diagnose NTP server connectivity (MQTT observer only)","text":"<p>Usage: - <code>get mqtt.ntp.diag</code></p> <p>Description: Probes every configured NTP server (the custom primary, if set, plus the built-in fallbacks) and reports whether each responds. This is a pure connectivity diagnostic - it does not change the system clock.</p> <ul> <li>Serial console: prints a detailed table with each server's reported UTC time (or <code>FAIL</code>).</li> <li>Over LoRa: returns a compact <code>&lt;server&gt; ok|fail</code> list, one per line.</li> </ul> <p>Requires WiFi connected and the MQTT bridge running.</p>"},{"location":"cli_commands/#view-or-change-the-speed-of-the-bridge-rs-232-only","title":"View or change the speed of the bridge (RS-232 only)","text":"<p>Usage: - <code>get bridge.baud</code> - <code>set bridge.baud &lt;rate&gt;</code></p> <p>Parameters: - <code>rate</code>: Baud rate (<code>9600</code>, <code>19200</code>, <code>38400</code>, <code>57600</code>, or <code>115200</code>)</p> <p>Default: <code>115200</code></p>"},{"location":"cli_commands/#view-or-change-the-uart-used-by-the-bridge-rs-232-only","title":"View or change the UART used by the bridge (RS-232 only)","text":"<p>Usage: - <code>get bridge.uart</code> - <code>set bridge.uart &lt;port&gt;</code></p> <p>Parameters: - <code>port</code>: Hardware UART number compiled for the board. Most boards expose one   fixed UART. RAK4631 accepts <code>1</code> or <code>2</code>; UART 2 is the default so UART 1 can   remain available to the RAK12501/L76K GPS. RAK12500 GPS uses I2C rather than   this UART, but the explicit legacy Serial1 bridge omits the combined GPS   provider and therefore does not expose either GPS path.</p> <p>The setting is persistent and restarts an enabled bridge immediately. Normal repeater artifacts start with <code>bridge.enabled off</code>; configure the UART and baud rate before running <code>set bridge.enabled on</code>. On the canonical RAK4631 runtime image, UART 1 is reserved even if the bounded boot probe hears no RAK12501. Silence cannot prove that a cold L76K is physically absent, and that module remains powered by the shared WB_IO2/3V3_S rail. Use UART 2. UART 1 requires an explicit no-GPS/dedicated Serial1 bridge image. This fail-closed reservation also applies when the detected GPS is an I2C RAK12500; that receiver does not electrically use UART 1, but its presence cannot rule out another silent UART module.</p>"},{"location":"cli_commands/#view-or-change-the-channel-used-for-bridging-espnow-only","title":"View or change the channel used for bridging (ESPNow only)","text":"<p>Usage: - <code>get bridge.channel</code> - <code>set bridge.channel &lt;channel&gt;</code></p> <p>Parameters: - <code>channel</code>: Channel number from 1 through 13 in either format. This matches   the primary-ESP-NOW policy and the default regulatory range used by the   supported ESP32 targets.</p> <p>This controls the optional ESP-NOW bridge transport; it does not change a node's primary ESP-NOW mesh channel. Primary-ESP-NOW firmware uses <code>get espnow.channel</code> and <code>set espnow.channel &lt;1-13&gt;</code> instead.</p>"},{"location":"cli_commands/#view-or-change-the-esp-now-bridge-wire-format","title":"View or change the ESP-NOW bridge wire format","text":"<p>Usage: - <code>get bridge.format</code> - <code>set bridge.format &lt;format&gt;</code></p> <p>Parameters: - <code>format</code>:   - <code>wrapped</code>: the original ESP-NOW bridge framing (magic, checksum, and XOR     using <code>bridge.secret</code>)   - <code>raw</code>: the exact serialized MeshCore packet used by primary     <code>ESPNOWRadio</code> firmware</p> <p>Default: <code>wrapped</code></p> <p>The setting is persistent and restarts an enabled bridge immediately. Receive parsing is strict: <code>wrapped</code> accepts only wrapped frames and <code>raw</code> accepts only raw MeshCore frames. Coordinate the format and channel on every ESP-NOW peer; there is no automatic dual-format receive mode because it would permit ambiguous, asymmetric bridge deployments.</p> <p>Use <code>raw</code> to connect a LoRa-primary <code>*_repeater_bridge_espnow</code> node to <code>Generic_ESPNOW</code>, <code>SenseCapIndicator-ESPNow</code>, or another primary-ESP-NOW node. Raw mode enables the ESP-NOW LR PHY and sends at the same LR rate used by those targets. All nodes must use the same 1-13 channel. On a primary-ESP-NOW node, change that side with <code>set espnow.channel &lt;1-13&gt;</code> and reboot; on the bridge, use <code>set bridge.channel &lt;1-13&gt;</code>.</p> <p>Raw mode ignores <code>bridge.secret</code> and removes the bridge wrapper's lightweight network isolation. MeshCore's own packet authentication/encryption still applies where the packet type provides it, but public frames and routing metadata remain visible. The wrapped format's XOR is isolation, not strong cryptography. Bridge duplicate tracking remains active in both formats, but deploying multiple gateways between the same LoRa and ESP-NOW coverage areas can still increase duplicate traffic while their seen-packet tables converge.</p> <p>One ESP-NOW frame carries at most 250 payload bytes. In raw mode, serialized MeshCore packets up to that size remain byte-for-byte compatible with existing raw endpoints. Updated raw endpoints split 251-255-byte transport units into two versioned fragments and reassemble them by source MAC, length, and CRC; both endpoints must include this support for those sizes. Current valid MeshCore packet geometry reaches 254 bytes, while 255 is retained as transport headroom. Wrapped mode retains its legacy 246-byte maximum after the four-byte magic and checksum overhead, and drops larger packets instead of truncating them.</p>"},{"location":"cli_commands/#set-the-esp-now-secret","title":"Set the ESP-Now secret","text":"<p>Usage:  - <code>get bridge.secret</code> - <code>set bridge.secret &lt;secret&gt;</code></p> <p>Parameters: - <code>secret</code>: ESP-NOW bridge secret, 1-15 characters</p> <p>Default: Varies by board</p> <p>This setting is used only by <code>bridge.format wrapped</code>; raw mode ignores it.</p>"},{"location":"cli_commands/#view-the-bootloader-version-nrf52-only","title":"View the bootloader version (nRF52 only)","text":"<p>Usage: <code>get bootloader.ver</code></p>"},{"location":"cli_commands/#view-power-management-support","title":"View power management support","text":"<p>Usage: <code>get pwrmgt.support</code></p>"},{"location":"cli_commands/#view-the-current-power-source","title":"View the current power source","text":"<p>Usage: <code>get pwrmgt.source</code></p> <p>Note: Returns an error on boards without power management support.</p>"},{"location":"cli_commands/#view-the-boot-reset-and-shutdown-reasons","title":"View the boot reset and shutdown reasons","text":"<p>Usage: <code>get pwrmgt.bootreason</code></p> <p>Note: Returns an error on boards without power management support.</p>"},{"location":"cli_commands/#view-the-boot-voltage","title":"View the boot voltage","text":"<p>Usage: <code>get pwrmgt.bootmv</code></p> <p>Note: Returns an error on boards without power management support.</p>"},{"location":"cli_commands/#ethernet-when-ethernet-support-is-compiled-in","title":"Ethernet (when Ethernet support is compiled in)","text":"<p>Ethernet support is available on RAK4631 boards with a RAK13800 (W5100S) Ethernet module. Use the <code>_ethernet</code> firmware variants (e.g. <code>RAK_4631_repeater_ethernet</code>) to enable this feature.</p>"},{"location":"cli_commands/#view-ethernet-connection-status","title":"View Ethernet connection status","text":"<p>Usage: - <code>eth.status</code></p> <p>Output: - <code>ETH: &lt;ip&gt;:&lt;port&gt;</code> when connected (e.g. <code>ETH: 192.168.1.50:23</code>) - <code>ETH: not connected</code> when Ethernet is not active</p> <p>Notes: - Available on repeater and room server firmware only. Companion radio ethernet firmware does not expose a CLI. - The Ethernet interface obtains an IP address via DHCP automatically on boot. - A TCP server listens on port 23 (default) for CLI connections. - Connect with any TCP client (e.g. <code>nc</code>, PuTTY) to access the same CLI available over serial.</p>"},{"location":"companion_offline_queue/","title":"Companion Offline Message Queue","text":"<p>Companion firmware keeps received channel data, channel messages, and direct messages in one pending queue until a Companion client requests them with the sync-next-message command. This is volatile RAM, not message history in flash. A reboot clears it.</p>"},{"location":"companion_offline_queue/#default-capacities","title":"Default capacities","text":"Platform or memory profile Pending frames ESP32 with configured PSRAM 512 ESP32 without PSRAM 256 nRF52840 256 RP2040 256 STM32 16 Known constrained classic ESP32 target override 128 Meshadventurer Full Companion 64 Constrained Full ESP32 fallback 16 <p>An explicit target <code>OFFLINE_QUEUE_SIZE</code> overrides the platform default. The Heltec V2 and TLora V2 Full Companion profiles, for example, use 16 frames so their combined WiFi, BLE, and LoRa mOTA image retains enough internal DRAM. Meshadventurer SX1262 and SX1268 Full Companion use 64 frames together with 160 contacts and 30 group channels; their ordinary transport-specific images keep 128 frames and 40 channels.</p> <p>Standard, logging, MQTT, and Cascade build overlays retain the selected target capacity; they do not silently shrink the queue.</p> <p>Each queue slot currently costs 177 bytes. A 256-frame queue reserves 45,312 bytes, while a 512-frame queue reserves 90,624 bytes. There is no 256-frame protocol limit: the queue length and indexes can represent 512 or more. The practical limit is available RAM and the heap and stack headroom required by the transports and display.</p> <p>On ESP32 boards marked with <code>BOARD_HAS_PSRAM</code>, the queue is allocated from PSRAM before WiFi and BLE start. A failed 512-frame allocation retries at 256, then 128, and finally uses a 16-frame internal fallback. Full Companion prints the capacity actually allocated in its startup memory line as <code>offline_queue=&lt;frames&gt;</code>.</p>"},{"location":"companion_offline_queue/#full-queue-behavior","title":"Full queue behavior","text":"<p>The capacity is shared across Public, other channels, channel data, and direct messages. It is not a per-channel count. When the queue is full, firmware replaces the oldest queued channel frame so newer traffic can still arrive. If the full queue contains only direct messages, a new frame is dropped rather than deleting a direct message.</p> <p>Queue order is preserved. Removal uses a ring index, so delivering one pending message no longer copies every remaining frame; only the less-common removal of an old channel frame from a full queue may shift entries.</p> <p>Capacity is selected when firmware is compiled. There is no CLI or Companion protocol setting to resize it at runtime.</p>"},{"location":"companion_protocol/","title":"Companion Protocol","text":"<ul> <li>Last Updated: 2026-08-26</li> <li>Protocol Version: 14 (<code>FIRMWARE_VER_CODE</code>)</li> </ul> <p>The command and response catalogs track <code>examples/companion_radio/MyMesh.cpp</code>. Applications should negotiate the protocol and validate lengths because older firmware exposes a subset.</p> <p>This document is a practical guide to MeshCore's binary companion protocol. The same protocol frames can be carried by the enabled BLE, USB serial, Wi-Fi, or Ethernet companion interface; connection details differ by build.</p> <p>On builds exposing more than one transport, delivery-required replies follow the interface which supplied the command. The multi-frame contact-list response holds that route until <code>END_OF_CONTACTS</code>; best-effort asynchronous observations may still be broadcast to enabled clients. Treat the device as one Companion session rather than as independent per-transport sessions.</p> <p>The examples focus on BLE, but the packet formats are transport-independent.</p>"},{"location":"companion_protocol/#official-libraries","title":"Official Libraries","text":"<p>Please see the following repos for existing MeshCore Companion Protocol libraries.</p> <ul> <li>JavaScript: https://github.com/meshcore-dev/meshcore.js</li> <li>Python: https://github.com/meshcore-dev/meshcore_py</li> </ul>"},{"location":"companion_protocol/#important-security-note","title":"Important Security Note","text":"<p>All secrets, hashes, and cryptographic values shown in this guide are example values only.</p> <ul> <li>All hex values, public keys and hashes are for demonstration purposes only</li> <li>Never use example secrets in production</li> <li>Always generate new cryptographically secure random secrets</li> <li>Please implement proper security practices in your implementation</li> <li>This guide is for protocol documentation only</li> </ul>"},{"location":"companion_protocol/#table-of-contents","title":"Table of Contents","text":"<ol> <li>BLE Connection</li> <li>Packet Structure</li> <li>Commands</li> <li>Channel Management</li> <li>Message Handling</li> <li>Response Parsing</li> <li>Example Implementation Flow</li> <li>Best Practices</li> <li>Troubleshooting</li> </ol>"},{"location":"companion_protocol/#ble-connection","title":"BLE Connection","text":""},{"location":"companion_protocol/#service-and-characteristics","title":"Service and Characteristics","text":"<p>MeshCore Companion devices expose a BLE service with the following UUIDs:</p> <ul> <li>Service UUID: <code>6E400001-B5A3-F393-E0A9-E50E24DCCA9E</code></li> <li>RX Characteristic (App -&gt; Firmware): <code>6E400002-B5A3-F393-E0A9-E50E24DCCA9E</code></li> <li>TX Characteristic (Firmware -&gt; App): <code>6E400003-B5A3-F393-E0A9-E50E24DCCA9E</code></li> </ul> <p>An nRF52 Full Companion also exposes a separate LoRa mOTA source service. It does not replace or multiplex the normal Companion UART service:</p> <ul> <li>mOTA Service: <code>14518FC2-7E7A-4D84-8CAE-6664B0234CF2</code></li> <li>Device Request (notify): <code>2BFAA1EE-7030-459A-B65A-E7CFD5B09735</code></li> <li>Host Response (write with response): <code>ACF38A51-DD58-4DCE-917F-0B1135E41B1A</code></li> </ul> <p>All three mOTA attributes require an encrypted, MITM-authenticated connection using the Companion's six-digit PIN. The source remains inactive until the client subscribes to Device Request and explicitly starts it with command <code>0x4B</code>. See Bluetooth LoRa mOTA source.</p> <p>ESP32 and nRF52 Companion UART characteristics require the same PIN-protected, MITM-authenticated link. ESP32 advertises DisplayOnly capability so a central must enter the PIN shown by the Companion; a Just Works bond is insufficient.</p>"},{"location":"companion_protocol/#connection-steps","title":"Connection Steps","text":"<ol> <li> <p>Scan for Devices</p> <ul> <li>Scan for BLE devices advertising the MeshCore Service UUID</li> <li>Optionally filter by device name (typically contains \"MeshCore\" prefix)</li> <li>Note the device MAC address for reconnection</li> </ul> </li> <li> <p>Connect to GATT</p> <ul> <li>Connect to the device using the discovered MAC address</li> <li>Wait for connection to be established</li> </ul> </li> <li> <p>Discover Services and Characteristics</p> <ul> <li>Discover the service with UUID <code>6E400001-B5A3-F393-E0A9-E50E24DCCA9E</code></li> <li>Discover the RX characteristic <code>6E400002-B5A3-F393-E0A9-E50E24DCCA9E</code><ul> <li>Your app writes to this, the firmware reads from this</li> </ul> </li> <li>Discover the TX characteristic <code>6E400003-B5A3-F393-E0A9-E50E24DCCA9E</code><ul> <li>The firmware writes to this, your app reads from this</li> </ul> </li> </ul> </li> <li> <p>Enable Notifications</p> <ul> <li>Subscribe to notifications on the TX characteristic to receive data from the firmware</li> </ul> </li> <li> <p>Send Initial Commands</p> <ul> <li>Send <code>CMD_APP_START</code> to identify your app to firmware and get radio settings</li> <li>Send <code>CMD_DEVICE_QUERY</code> to fetch device info and negotiate supported protocol versions</li> <li>Send <code>CMD_SET_DEVICE_TIME</code> to set the firmware clock</li> <li>Send <code>CMD_GET_CONTACTS</code> to fetch all contacts</li> <li>Send <code>CMD_GET_CHANNEL</code> multiple times to fetch all channel slots</li> <li>Send <code>CMD_SYNC_NEXT_MESSAGE</code> to fetch the next message stored in firmware</li> <li>Setup listeners for push codes, such as <code>PUSH_CODE_MSG_WAITING</code> or <code>PUSH_CODE_ADVERT</code></li> <li>See Commands section for information on other commands</li> </ul> </li> </ol> <p>Note: MeshCore devices may disconnect after periods of inactivity. Implement auto-reconnect logic with exponential backoff.</p>"},{"location":"companion_protocol/#ble-write-type","title":"BLE Write Type","text":"<p>When writing commands to the RX characteristic, specify the write type:</p> <ul> <li>Write with Response (default): Waits for acknowledgment from device</li> <li>Write without Response: Faster but no acknowledgment</li> </ul> <p>Platform-specific:</p> <ul> <li>Android: Use <code>BluetoothGattCharacteristic.WRITE_TYPE_DEFAULT</code> or <code>WRITE_TYPE_NO_RESPONSE</code></li> <li>iOS: Use <code>CBCharacteristicWriteType.withResponse</code> or <code>.withoutResponse</code></li> <li>Python (bleak): Use <code>write_gatt_char()</code> with <code>response=True</code> or <code>False</code></li> </ul> <p>Recommendation: Use write with response for reliability.</p>"},{"location":"companion_protocol/#mtu-maximum-transmission-unit","title":"MTU (Maximum Transmission Unit)","text":"<p>The default BLE MTU is 23 bytes (20 bytes payload). For larger commands like <code>SET_CHANNEL</code> (50 bytes), you may need to:</p> <ol> <li>Request Larger MTU: Request MTU of 512 bytes if supported<ul> <li>Android: <code>gatt.requestMtu(512)</code></li> <li>iOS: <code>peripheral.maximumWriteValueLength(for:)</code></li> <li>Python (bleak): MTU is negotiated automatically</li> </ul> </li> </ol>"},{"location":"companion_protocol/#command-sequencing","title":"Command Sequencing","text":"<p>Critical: Commands must be sent in the correct sequence:</p> <ol> <li> <p>After Connection:</p> <ul> <li>Wait for BLE connection to be established</li> <li>Wait for services/characteristics to be discovered</li> <li>Wait for notifications to be enabled</li> <li>Now you can safely send commands to the firmware</li> </ul> </li> <li> <p>Command-Response Matching:</p> <ul> <li>Send one command at a time</li> <li>Wait for a response before sending another command</li> <li>Use a timeout (typically 5 seconds)</li> <li>Match response to command by type (e.g: <code>CMD_GET_CHANNEL</code> -&gt; <code>RESP_CODE_CHANNEL_INFO</code>)</li> </ul> </li> </ol>"},{"location":"companion_protocol/#command-queue-management","title":"Command Queue Management","text":"<p>For reliable operation, implement a command queue.</p> <p>Queue Structure:</p> <ul> <li>Maintain a queue of pending commands</li> <li>Track which command is currently waiting for a response</li> <li>Only send next command after receiving response or timeout</li> </ul> <p>Error Handling:</p> <ul> <li>On timeout, clear current command, process next in queue</li> <li>On error, log error, clear current command, process next</li> </ul>"},{"location":"companion_protocol/#packet-structure","title":"Packet Structure","text":"<p>The MeshCore protocol uses a binary format with the following structure:</p> <ul> <li>Commands: Sent from app to firmware via RX characteristic</li> <li>Responses: Received from firmware via TX characteristic notifications</li> <li>All multi-byte integers: Little-endian byte order (except CayenneLPP which is Big-endian)</li> <li>All strings: UTF-8 encoding</li> </ul> <p>Most packets follow this format:</p> <pre><code>[Packet Type (1 byte)] [Data (variable length)]\n</code></pre> <p>The first byte indicates the packet type (see Response Parsing).</p>"},{"location":"companion_protocol/#commands","title":"Commands","text":"<p>The first byte selects the command. This is the current protocol-v14 command catalog; bytes <code>0x2C</code>-<code>0x31</code> are parked and <code>0x35</code> is unused.</p> Byte Firmware name Purpose <code>0x01</code> <code>CMD_APP_START</code> Start an app session and request self information. <code>0x02</code> <code>CMD_SEND_TXT_MSG</code> Send text to a contact. <code>0x03</code> <code>CMD_SEND_CHANNEL_TXT_MSG</code> Send channel text. <code>0x04</code> <code>CMD_GET_CONTACTS</code> Enumerate contacts, optionally modified since a timestamp. <code>0x05</code> / <code>0x06</code> <code>CMD_GET_DEVICE_TIME</code> / <code>CMD_SET_DEVICE_TIME</code> Read or set the device clock. <code>0x07</code> / <code>0x08</code> <code>CMD_SEND_SELF_ADVERT</code> / <code>CMD_SET_ADVERT_NAME</code> Advertise self or change the advertised name. <code>0x09</code> <code>CMD_ADD_UPDATE_CONTACT</code> Add or update a contact. <code>0x0A</code> <code>CMD_SYNC_NEXT_MESSAGE</code> Dequeue the next pending message. <code>0x0B</code> / <code>0x0C</code> <code>CMD_SET_RADIO_PARAMS</code> / <code>CMD_SET_RADIO_TX_POWER</code> Set radio parameters or transmit power. <code>0x0D</code> <code>CMD_RESET_PATH</code> Reset a contact's learned path. <code>0x0E</code> <code>CMD_SET_ADVERT_LATLON</code> Set advertised coordinates. <code>0x0F</code> <code>CMD_REMOVE_CONTACT</code> Remove a contact. <code>0x10</code> / <code>0x11</code> / <code>0x12</code> <code>CMD_SHARE_CONTACT</code> / <code>CMD_EXPORT_CONTACT</code> / <code>CMD_IMPORT_CONTACT</code> Share, export, or import contact data. <code>0x13</code> <code>CMD_REBOOT</code> Reboot after the required confirmation body. <code>0x14</code> <code>CMD_GET_BATT_AND_STORAGE</code> Read battery and storage usage. <code>0x15</code> <code>CMD_SET_TUNING_PARAMS</code> Set tuning parameters. <code>0x16</code> <code>CMD_DEVICE_QUERY</code> Negotiate protocol support and read device information. <code>0x17</code> / <code>0x18</code> <code>CMD_EXPORT_PRIVATE_KEY</code> / <code>CMD_IMPORT_PRIVATE_KEY</code> Export or import identity key material when enabled. <code>0x19</code> <code>CMD_SEND_RAW_DATA</code> Send an application raw-data packet. <code>0x1A</code>-<code>0x1D</code> <code>CMD_SEND_LOGIN</code> through <code>CMD_LOGOUT</code> Manage a server connection. <code>0x1E</code> <code>CMD_GET_CONTACT_BY_KEY</code> Look up a contact by public-key prefix. <code>0x1F</code> / <code>0x20</code> <code>CMD_GET_CHANNEL</code> / <code>CMD_SET_CHANNEL</code> Read or write a channel slot. <code>0x21</code>-<code>0x23</code> <code>CMD_SIGN_START</code> through <code>CMD_SIGN_FINISH</code> Stream data for identity signing. <code>0x24</code> <code>CMD_SEND_TRACE_PATH</code> Trace a direct route. <code>0x25</code> <code>CMD_SET_DEVICE_PIN</code> Set or clear the device PIN. <code>0x26</code> <code>CMD_SET_OTHER_PARAMS</code> Set telemetry, location, ACK, and related preferences. <code>0x27</code> <code>CMD_SEND_TELEMETRY_REQ</code> Send the legacy telemetry request. <code>0x28</code> / <code>0x29</code> <code>CMD_GET_CUSTOM_VARS</code> / <code>CMD_SET_CUSTOM_VAR</code> Read or set custom variables. <code>0x2A</code> <code>CMD_GET_ADVERT_PATH</code> Read a cached advertisement path. <code>0x2B</code> <code>CMD_GET_TUNING_PARAMS</code> Read tuning parameters. <code>0x32</code> <code>CMD_SEND_BINARY_REQ</code> Send an application binary request. <code>0x33</code> <code>CMD_FACTORY_RESET</code> Factory-reset after the required confirmation body. <code>0x34</code> <code>CMD_SEND_PATH_DISCOVERY_REQ</code> Request path discovery. <code>0x36</code> <code>CMD_SET_FLOOD_SCOPE_KEY</code> Select scoped or unscoped flood behavior. <code>0x37</code> <code>CMD_SEND_CONTROL_DATA</code> Send zero-hop control data. <code>0x38</code> <code>CMD_GET_STATS</code> Read core, radio, or packet statistics. <code>0x39</code> <code>CMD_SEND_ANON_REQ</code> Send an anonymous request. <code>0x3A</code> / <code>0x3B</code> <code>CMD_SET_AUTOADD_CONFIG</code> / <code>CMD_GET_AUTOADD_CONFIG</code> Write or read automatic-contact policy. <code>0x3C</code> <code>CMD_GET_ALLOWED_REPEAT_FREQ</code> Read allowed client-repeat frequency ranges. <code>0x3D</code> <code>CMD_SET_PATH_HASH_MODE</code> Set path-hash width mode. <code>0x3E</code> <code>CMD_SEND_CHANNEL_DATA</code> Send a channel binary datagram. <code>0x3F</code> / <code>0x40</code> <code>CMD_SET_DEFAULT_FLOOD_SCOPE</code> / <code>CMD_GET_DEFAULT_FLOOD_SCOPE</code> Write or read the default flood scope. <code>0x41</code> <code>CMD_SEND_RAW_PACKET</code> Queue a fully encoded raw mesh packet. <code>0x42</code> <code>CMD_RUN_CLI_COMMAND</code> Run a local CLI command (protocol v14+). <code>0x4A</code> <code>CMD_EXEC_LOCAL_OTA_CONTROL</code> Run one bounded local TempRadio or OTA command when the Companion includes the OTA CLI. <code>0x4B</code> <code>CMD_BLE_MOTA_SOURCE</code> Query, start, or stop an nRF52 Full Companion's Bluetooth-backed LoRa mOTA source. <code>0x78</code>-<code>0x7F</code> Deprecated hardware-setting aliases Receive-only compatibility for clients shipped before command <code>0x42</code> became the canonical settings path. <p>The sections below detail the most common frames. Refer to the source named above for command bodies that are not expanded here.</p> <p><code>CMD_RUN_CLI_COMMAND</code> is followed by the local CLI text without a terminating NUL. The device returns <code>RESP_CODE_CLI_REPLY</code> (<code>0x1D</code>) followed by the reply text. This is separate from sending a remote on-air CLI command with <code>CMD_SEND_TXT_MSG</code> and <code>TXT_TYPE_CLI_COMMAND</code>. The body must contain at least one byte and must not contain an embedded NUL. An unknown command is returned as the normal CLI reply text <code>Unknown command</code>, not as an error frame. Clients may prefix the CLI text with any two-character correlation tag and <code>|</code> (for example, <code>A7|get radio.rxgain</code>); the reply preserves that prefix.</p> <p>Full Companion clients can send <code>version</code> through this command to receive the untruncated build identity, for example <code>Companion 1.17.1.5-... (protocol 14, build 31-Aug-2026)</code>. This deliberately supplements rather than changes the 20-byte legacy version field in <code>RESP_CODE_DEVICE_INFO</code>, so existing clients keep the same frame layout.</p> <p>Firmware from this fork predating the upstream <code>0x42</code> allocation used <code>0x42</code>-<code>0x49</code> for these eight settings. This firmware accepts those values as deprecated inbound aliases so existing clients continue to work. A one-byte <code>0x42</code> frame is the legacy FEM-gain GET; <code>0x42</code> followed by text is the official <code>CMD_RUN_CLI_COMMAND</code>. New clients should use <code>CMD_RUN_CLI_COMMAND</code> for all of these settings, rather than allocating additional command bytes. For example, send <code>0x42</code> followed by <code>get radio.rxgain</code> or <code>set radio.rxgain on</code>. The reply is <code>RESP_CODE_CLI_REPLY</code> followed by the normal CLI reply text.</p> <p>Two deprecated binary alias blocks remain receive-only for compatibility:</p> Setting Original alias Later fork alias GET body/reply SET body/reply FEM receive gain <code>0x42</code> / <code>0x43</code> <code>0x78</code> / <code>0x79</code> No body; <code>OK, state</code> One byte <code>0</code>/<code>1</code>; <code>OK</code> Radio receive gain <code>0x44</code> / <code>0x45</code> <code>0x7A</code> / <code>0x7B</code> No body; <code>OK, state</code> One byte <code>0</code>/<code>1</code>; <code>OK</code> WiFi power save <code>0x46</code> / <code>0x47</code> <code>0x7C</code> / <code>0x7D</code> No body; <code>OK, mode</code> One mode byte <code>0</code>-<code>2</code>; <code>OK</code> Bluetooth name <code>0x48</code> / <code>0x49</code> <code>0x7E</code> / <code>0x7F</code> No body; <code>OK, custom, name</code> Zero to 31 UTF-8 bytes; <code>OK</code> <p>Each pair lists GET then SET. Here <code>OK</code> is <code>RESP_CODE_OK</code>; the remaining reply bytes have the same meanings as the CLI settings below. A bare <code>0x42</code> is the old FEM GET, while <code>0x42</code> plus at least one text byte is <code>CMD_RUN_CLI_COMMAND</code>. New clients must use the framed CLI form; these aliases exist only so deployed clients do not break after a firmware update.</p> <p>The equivalent framed CLI commands are:</p> Setting Commands Radio receive gain <code>get radio.rxgain</code>; <code>set radio.rxgain on|off</code> FEM receive gain <code>get radio.fem.rxgain</code>; <code>set radio.fem.rxgain on|off</code> WiFi power save <code>get wifi.powersave</code>; <code>set wifi.powersave none|min|max</code> Bluetooth name <code>get bluetooth.name</code>; <code>set bluetooth.name &lt;name|default&gt;</code> <p>The framed form works over the normal binary USB, BLE, or TCP transport and does not need the USB terminal-start token. Unsupported settings return the same explanatory text as the local CLI.</p> <p>WiFi power-save modes are:</p> Value Mode <code>0</code> <code>min</code> - minimum modem sleep <code>1</code> <code>none</code> - no modem sleep <code>2</code> <code>max</code> - maximum modem sleep <p>A Full Companion that runs BLE and infrastructure WiFi simultaneously rejects WiFi mode <code>none</code> because coexistence requires modem sleep. A Full Companion using ESP-NOW as its primary mesh radio also rejects <code>max</code>, because maximum modem sleep can miss broadcasts that the access point cannot buffer. If an older image saved a conflicting value, the effective mode is capped to and reported as <code>min</code>. Device <code>powersaving</code> remains independent.</p> <p>The SenseCAP Indicator Full profiles run exactly one secondary wireless Companion transport per boot. Their active-mode constraints are:</p> Indicator mode Accepted <code>wifi.powersave</code> values LoRa + infrastructure WiFi <code>none</code>, <code>min</code>, <code>max</code> LoRa + BLE <code>min</code>, <code>max</code>; infrastructure WiFi is not started ESP-NOW + infrastructure WiFi <code>none</code>, <code>min</code>; <code>max</code> conflicts with primary ESP-NOW ESP-NOW + BLE <code>min</code>; infrastructure WiFi is not started and primary ESP-NOW remains active <p>The Bluetooth name can be configured over USB, BLE, or TCP. Use <code>set bluetooth.name default</code> to restore <code>MeshCore-&lt;advert name&gt;</code>; an empty CLI value is rejected. (<code>clear</code> is also accepted as an alias for <code>default</code>.) A custom name is limited to 31 valid UTF-8 bytes and takes effect after reboot.</p>"},{"location":"companion_protocol/#bluetooth-lora-mota-source","title":"Bluetooth LoRa mOTA source","text":"<p>Protocol v14 lets a phone control an install-capable Companion's own LoRa OTA session. An nRF52 Full Companion can additionally act as the source for a remote repeater update without a USB computer. The normal Companion service still carries contacts, repeater login, CLI messages, and these two control commands. The separate mOTA service carries only host-folder request/response frames.</p> <p><code>CMD_EXEC_LOCAL_OTA_CONTROL</code> (<code>0x4A</code>) is followed by 1-174 printable ASCII bytes. A Companion built with the OTA CLI accepts only these local command families:</p> <pre><code>tempradio &lt;freq_kHz&gt;,&lt;bw_kHz&gt;,&lt;sf&gt;,&lt;cr&gt;,&lt;minutes&gt;\nnormalradio\nota ...\n</code></pre> <p><code>ota folder ...</code> is deliberately rejected because USB and Bluetooth source ownership must not be changed through the wrong transport. Embedded NUL, CR, LF, other control bytes, non-ASCII bytes, empty commands, and oversized frames return <code>ERR_CODE_ILLEGAL_ARG</code>. A recognized command replies with <code>RESP_CODE_OK</code>, one unsigned reply-length byte, and exactly that many printable result bytes. Shell metacharacters are rejected as well; the text is dispatched only to the in-firmware parser and is never passed to a host shell. Firmware without the OTA CLI feature returns <code>ERR_CODE_UNSUPPORTED_CMD</code>.</p> <p><code>CMD_BLE_MOTA_SOURCE</code> (<code>0x4B</code>) has one action byte:</p> Action Meaning <code>0</code> Read status without changing it. <code>1</code> Attach and enumerate the subscribed Bluetooth host's <code>.mota</code> catalog. <code>2</code> Detach the Bluetooth source. <p>Current firmware returns eleven bytes (legacy protocol-v14 previews returned the seven-byte prefix only):</p> <pre><code>00 action flags offered_le16 advertised_le16 source_packets_sent_le32\n</code></pre> <p>Flag bit <code>0x01</code> means the encrypted GATT channel is connected and Device Request notifications are enabled. Bit <code>0x02</code> means the Bluetooth catalog is attached. Bit <code>0x04</code> means USB or another folder transport currently owns the source slot. Start without a ready subscription, or while another source link owns the slot, returns <code>ERR_CODE_BAD_STATE</code>. A non-nRF52 Full Companion returns <code>ERR_CODE_UNSUPPORTED_CMD</code>. <code>source_packets_sent</code> is a per-attachment count of OTA packets accepted by the Companion's LoRa transmit adapter, including catalog/manifest traffic, data, proofs, and retries. It wraps as an unsigned 32-bit value. Clients should accept the legacy seven-byte response and display the packet counter as unavailable.</p> <p>After a successful start, the device sends the same bounded seeder frames used by <code>motatool serve</code> on Device Request:</p> <pre><code>device -&gt; host: 'M' 'S' op args... xor(op || args)\nhost -&gt; device: 'm' 's' op status payload... xor(all prior bytes)\n</code></pre> <p>Device requests are at most 11 bytes. A source response is at most 197 bytes. The host may split one response across multiple write-with-response operations when the negotiated ATT payload is smaller; it must preserve byte order and must not interleave another response. Bad checksums, partial frames, overflow, unsubscribe, loss of encryption, or disconnect fail closed. The firmware then detaches the catalog and stops advertising its entries. USB and Bluetooth folder sources are mutually exclusive.</p> <p>A Linux reference controller and seeder is provided at <code>tools/ble_mota/ble_mota_seeder.py</code>. It verifies every input with <code>motatool</code> before offering it. A mobile implementation should apply the same complete container verification before serving files.</p>"},{"location":"companion_protocol/#1-app-start","title":"1. App Start","text":"<p>Purpose: Initialize communication with the device. Must be sent first after connection.</p> <p>Command Format:</p> <pre><code>Byte 0: 0x01\nBytes 1-7: Reserved (currently ignored by firmware)\nBytes 8+: Application name (UTF-8, optional)\n</code></pre> <p>Example (hex):</p> <pre><code>01 00 00 00 00 00 00 00 6d 63 63 6c 69\n</code></pre> <p>Response: <code>PACKET_SELF_INFO</code> (0x05)</p>"},{"location":"companion_protocol/#2-device-query","title":"2. Device Query","text":"<p>Purpose: Query device information.</p> <p>Command Format:</p> <pre><code>Byte 0: 0x16\nByte 1: Highest companion protocol version understood by the app\n</code></pre> <p>Example (hex):</p> <pre><code>16 0E\n</code></pre> <p>Response: <code>PACKET_DEVICE_INFO</code> (0x0D) with device information</p>"},{"location":"companion_protocol/#3-get-channel-info","title":"3. Get Channel Info","text":"<p>Purpose: Retrieve information about a specific channel.</p> <p>Command Format:</p> <pre><code>Byte 0: 0x1F\nByte 1: Channel index (0 through max_channels - 1)\n</code></pre> <p>Example (get channel 1):</p> <pre><code>1F 01\n</code></pre> <p>Response: <code>PACKET_CHANNEL_INFO</code> (0x12) with channel details</p>"},{"location":"companion_protocol/#4-set-channel","title":"4. Set Channel","text":"<p>Purpose: Create or update a channel on the device.</p> <p>Command Format:</p> <pre><code>Byte 0: 0x20\nByte 1: Channel index (0 through max_channels - 1)\nBytes 2-33: Channel Name (32 bytes, UTF-8, null-padded)\nBytes 34-49: Secret (16 bytes)\n</code></pre> <p>Total Length: 50 bytes</p> <p>Channel index: - Slot count is build-specific. Read <code>max_channels</code> from byte 3 of   <code>PACKET_DEVICE_INFO</code>; current profiles commonly expose 1, 8, or 40 slots. - No slot number has an intrinsic public/private meaning.</p> <p>Channel Name: - UTF-8 encoded - Maximum 32 bytes - Padded with null bytes (0x00) if shorter</p> <p>Secret Field (16 bytes): - Supply the exact 16-byte channel key. A private channel normally uses a   cryptographically random key; known public and hashtag channels use their   defined or derived key. - An all-zero key is not the public-channel key.</p> <p>Example (create channel \"SMS\" at index 1 with secret):</p> <pre><code>20 01 53 4D 53 00 00 ... (name padded to 32 bytes)\n    [16 bytes of secret]\n</code></pre> <p>Note: The 32-byte secret variant is unsupported and returns <code>PACKET_ERROR</code>.</p> <p>Response: <code>PACKET_OK</code> (0x00) on success, <code>PACKET_ERROR</code> (0x01) on failure</p>"},{"location":"companion_protocol/#5-send-channel-message","title":"5. Send Channel Message","text":"<p>Purpose: Send a text message to a channel.</p> <p>Command Format:</p> <pre><code>Byte 0: 0x03\nByte 1: 0x00\nByte 2: Channel index (0 through max_channels - 1)\nBytes 3-6: Timestamp (32-bit little-endian Unix timestamp, seconds)\nBytes 7+: Message Text (UTF-8, variable length)\n</code></pre> <p>Timestamp: Unix timestamp in seconds (32-bit unsigned integer, little-endian)</p> <p>Example (send \"Hello\" to channel 1 at timestamp 1234567890):</p> <pre><code>03 00 01 D2 02 96 49 48 65 6C 6C 6F\n</code></pre> <p>Response: <code>PACKET_MSG_SENT</code> (0x06) on success</p>"},{"location":"companion_protocol/#6-send-channel-data-datagram","title":"6. Send Channel Data Datagram","text":"<p>Purpose: Send a binary datagram to a channel. Unlike channel text messages, datagrams carry no built-in sender identity and no timestamp - applications needing either must encode them inside the binary payload.</p> <p>Command Format:</p> <pre><code>Byte 0:                         0x3E\nByte 1:                         Channel index (0 through max_channels - 1)\nByte 2:                         Encoded path descriptor (0xFF = flood)\nBytes 3+:                       Encoded path bytes (omitted for 0xFF)\nNext 2 bytes (little-endian):   Data Type (`data_type`, uint16)\nRemaining bytes:                Binary payload (variable length)\n</code></pre> <p>For a direct send, the descriptor's low six bits are the hash count and its high two bits are the hash size minus one. Current mesh packets accept one-, two-, or three-byte hashes; the four-byte code is reserved. The following path therefore occupies <code>hash_count * hash_size</code> bytes; the descriptor itself is not a raw byte count.</p> <p>Example (flood, <code>DATA_TYPE_DEV</code>, payload <code>A1 B2 C3</code>, channel 1):</p> <pre><code>3E 01 FF FF FF A1 B2 C3\n</code></pre> <p>Data Type / Transport Mapping: - <code>0x0000</code> (<code>DATA_TYPE_RESERVED</code>) is invalid and rejected with <code>PACKET_ERROR</code>. - <code>0xFFFF</code> (<code>DATA_TYPE_DEV</code>) is the developer namespace for experimenting and developing apps. - Registered application/community namespaces occupy <code>0x0100</code>-<code>0xFEFF</code>; the remaining nonzero ranges are reserved for internal or development use. See the Registered data_type values table below.</p> <p>Limits: - Maximum payload length is <code>MAX_CHANNEL_DATA_LENGTH = MAX_FRAME_SIZE - 9 = 167</code> bytes. - Larger payloads are rejected with <code>PACKET_ERROR</code> (<code>ERR_CODE_ILLEGAL_ARG</code>).</p> <p>Response: <code>PACKET_OK</code> (0x00) on success, or <code>PACKET_ERROR</code> (0x01) with one of: - <code>ERR_CODE_NOT_FOUND</code> (2) - unknown <code>channel_idx</code> - <code>ERR_CODE_ILLEGAL_ARG</code> (6) - invalid <code>path_len</code>, reserved <code>data_type</code> (<code>0x0000</code>), or payload larger than <code>MAX_CHANNEL_DATA_LENGTH</code> - <code>ERR_CODE_TABLE_FULL</code> (3) - outbound send queue is full; retry later</p> <p>Inbound datagrams are delivered to the host via <code>RESP_CODE_CHANNEL_DATA_RECV</code> (0x1B); see Receive Channel Data Datagram.</p>"},{"location":"companion_protocol/#registered-data_type-values","title":"Registered <code>data_type</code> values","text":"<p><code>data_type</code> is an application identifier, not a payload-format identifier. Each registered value identifies an application that owns its own internal payload schemas. The firmware does not inspect payload contents - <code>data_type</code> is transported opaquely.</p> Value Constant Purpose 0x0000 <code>DATA_TYPE_RESERVED</code> Reserved; invalid on send 0x0001 - 0x00FF - Reserved for internal use 0x0100 - 0xFEFF - Registered application namespaces (see number_allocations.md) 0xFF00 - 0xFFFE - Testing/development; no registration required 0xFFFF <code>DATA_TYPE_DEV</code> Developer/experimental namespace <p>To register a new application, submit a PR adding a row to the table in docs/number_allocations.md. Internal sub-formats within an allocated application ID are owned by that application and are not tracked in MeshCore firmware or this document.</p>"},{"location":"companion_protocol/#receive-channel-data-datagram","title":"Receive Channel Data Datagram","text":"<p>Inbound group datagrams (radio-level <code>PAYLOAD_TYPE_GRP_DATA</code>, 0x06) are forwarded to the host as <code>RESP_CODE_CHANNEL_DATA_RECV</code> notifications.</p> <p>Frame Format (<code>RESP_CODE_CHANNEL_DATA_RECV</code>, 0x1B):</p> <pre><code>Byte 0:                 0x1B (packet type)\nByte 1:                 SNR (signed int8, scaled x4 - divide by 4.0 to recover dB)\nBytes 2-3:              Reserved (clients MUST ignore)\nByte 4:                 Channel index (0 through max_channels - 1)\nByte 5:                 Path Length (actual path length when flooded, otherwise 0xFF for direct)\nBytes 6-7:              Data Type (uint16 little-endian)\nByte 8:                 Data Length\nBytes 9 .. 8+data_len:  Payload\n</code></pre> <p>Path bytes are not forwarded: Only <code>path_len</code> is reported in the receive frame - the path itself is not copied to the host. There are no path bytes between byte 5 and the data_type field at bytes 6-7, regardless of <code>path_len</code>.</p> <p>Path Length semantics differ between send and receive:</p> Direction <code>path_len = 0xFF</code> <code>path_len != 0xFF</code> Send Flood the network Direct route; the encoded path follows (low 6 bits = hash count, top 2 bits + 1 = hash size; on-wire byte count = <code>hash_count x hash_size</code>) Receive Packet arrived via direct route Packet was flooded; this is the encoded <code>pkt-&gt;path_len</code> field as observed (no path bytes follow) <p>In other words, the meaning of <code>0xFF</code> is inverted between the two directions, and on receive the field carries metadata only - never a routable path. <code>path_len</code> is an encoded byte (see <code>Packet::isValidPathLen</code> / <code>Packet::writePath</code> in <code>src/Packet.cpp</code>), not a raw byte count.</p> <p>Note: The device may also emit <code>PACKET_MESSAGES_WAITING</code> (0x83) to notify the host that datagrams are queued; poll with <code>CMD_SYNC_NEXT_MESSAGE</code> (0x0A) to retrieve them.</p> <p>Parsing Pseudocode:</p> <pre><code>def parse_channel_data_recv(data):\n    if len(data) &lt; 9:\n        return None\n    snr_byte = data[1]\n    snr = (snr_byte if snr_byte &lt; 128 else snr_byte - 256) / 4.0\n    channel_idx = data[4]\n    path_len = data[5]\n    data_type = int.from_bytes(data[6:8], 'little')\n    data_len = data[8]\n    if 9 + data_len &gt; len(data):\n        return None\n    payload = data[9:9 + data_len]\n    return {\n        'snr': snr,\n        'channel_idx': channel_idx,\n        'path_len': path_len,\n        'data_type': data_type,\n        'payload': bytes(payload),\n    }\n</code></pre>"},{"location":"companion_protocol/#7-get-message","title":"7. Get Message","text":"<p>Purpose: Request the next queued message from the device.</p> <p>Command Format:</p> <pre><code>Byte 0: 0x0A\n</code></pre> <p>Example (hex):</p> <pre><code>0A\n</code></pre> <p>Response:  - <code>PACKET_CHANNEL_MSG_RECV</code> (0x08) or <code>PACKET_CHANNEL_MSG_RECV_V3</code> (0x11) for channel messages - <code>PACKET_CONTACT_MSG_RECV</code> (0x07) or <code>PACKET_CONTACT_MSG_RECV_V3</code> (0x10) for contact messages - <code>PACKET_CHANNEL_DATA_RECV</code> (0x1B) for channel data datagrams - <code>PACKET_NO_MORE_MSGS</code> (0x0A) if no messages available</p> <p>Note: Poll this command periodically to retrieve queued messages. The device may also send <code>PACKET_MESSAGES_WAITING</code> (0x83) as a notification when messages are available.</p>"},{"location":"companion_protocol/#8-get-battery-and-storage","title":"8. Get Battery and Storage","text":"<p>Purpose: Query device battery voltage and storage usage.</p> <p>Command Format:</p> <pre><code>Byte 0: 0x14\n</code></pre> <p>Example (hex):</p> <pre><code>14\n</code></pre> <p>Response: <code>PACKET_BATTERY</code> (0x0C) with battery millivolts and storage information</p>"},{"location":"companion_protocol/#channel-management","title":"Channel Management","text":""},{"location":"companion_protocol/#channel-types","title":"Channel Types","text":"<ol> <li>Public Channel<ul> <li>Uses a publicly known 16-byte key: <code>8b3387e9c5cdea6ac9e5edbaa115cd72</code></li> <li>Anyone can join this channel, messages should be considered public</li> <li>Used as the default public group chat</li> </ul> </li> <li>Hashtag Channels<ul> <li>Uses a secret key derived from the channel name</li> <li>It is the first 16 bytes of <code>sha256(\"#test\")</code></li> <li>For example hashtag channel <code>#test</code> has the key: <code>9cd8fcf22a47333b591d96a2b848b73f</code></li> <li>Traffic is encrypted on air, but anyone who knows or guesses the channel   name can derive the key. Hashtag channels should not be treated as private.</li> <li>Used as a topic based public group chat, separate from the default public channel</li> </ul> </li> <li>Private Channels<ul> <li>Uses a randomly generated 16-byte secret key</li> <li>Messages should be considered private between those that know the secret</li> <li>Users should keep the key secret, and only share with those you want to communicate with</li> <li>Used as a secure private group chat</li> </ul> </li> </ol>"},{"location":"companion_protocol/#channel-lifecycle","title":"Channel Lifecycle","text":"<ol> <li>Set Channel:<ul> <li>Read <code>max_channels</code> from device info, fetch those slots, and choose an   unused slot (normally an empty name and zeroed key)</li> <li>Generate or provide a 16-byte secret</li> <li>Send <code>CMD_SET_CHANNEL</code> with name and a 16-byte secret</li> </ul> </li> <li>Get Channel:<ul> <li>Send <code>CMD_GET_CHANNEL</code> with channel index</li> <li>Parse <code>RESP_CODE_CHANNEL_INFO</code> response</li> </ul> </li> <li>Delete Channel:<ul> <li>Send <code>CMD_SET_CHANNEL</code> with empty name and all-zero secret</li> <li>Or overwrite with a new channel</li> </ul> </li> </ol>"},{"location":"companion_protocol/#message-handling","title":"Message Handling","text":""},{"location":"companion_protocol/#receiving-messages","title":"Receiving Messages","text":"<p>Messages are received via the TX characteristic (notifications). The device sends:</p> <ol> <li>Channel Messages:</li> <li><code>PACKET_CHANNEL_MSG_RECV</code> (0x08) - Standard format</li> <li> <p><code>PACKET_CHANNEL_MSG_RECV_V3</code> (0x11) - Version 3 with SNR</p> </li> <li> <p>Contact Messages:</p> </li> <li><code>PACKET_CONTACT_MSG_RECV</code> (0x07) - Standard format</li> <li> <p><code>PACKET_CONTACT_MSG_RECV_V3</code> (0x10) - Version 3 with SNR</p> </li> <li> <p>Notifications:</p> </li> <li><code>PACKET_MESSAGES_WAITING</code> (0x83) - Indicates messages are queued</li> </ol>"},{"location":"companion_protocol/#contact-message-format","title":"Contact Message Format","text":"<p>Standard Format (<code>PACKET_CONTACT_MSG_RECV</code>, 0x07):</p> <pre><code>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</code></pre> <p>V3 Format (<code>PACKET_CONTACT_MSG_RECV_V3</code>, 0x10):</p> <pre><code>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</code></pre> <p>Parsing Pseudocode:</p> <pre><code>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 &lt; 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</code></pre>"},{"location":"companion_protocol/#channel-message-format","title":"Channel Message Format","text":"<p>Standard Format (<code>PACKET_CHANNEL_MSG_RECV</code>, 0x08):</p> <pre><code>Byte 0: 0x08 (packet type)\nByte 1: Channel index (0 through max_channels - 1)\nByte 2: Path Length\nByte 3: Text Type\nBytes 4-7: Timestamp (32-bit little-endian)\nBytes 8+: Message Text (UTF-8)\n</code></pre> <p>V3 Format (<code>PACKET_CHANNEL_MSG_RECV_V3</code>, 0x11):</p> <pre><code>Byte 0: 0x11 (packet type)\nByte 1: SNR (signed byte, multiplied by 4)\nBytes 2-3: Reserved\nByte 4: Channel index (0 through max_channels - 1)\nByte 5: Path Length\nByte 6: Text Type\nBytes 7-10: Timestamp (32-bit little-endian)\nBytes 11+: Message Text (UTF-8)\n</code></pre> <p>Parsing Pseudocode:</p> <pre><code>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 &lt; 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</code></pre>"},{"location":"companion_protocol/#sending-messages","title":"Sending Messages","text":"<p>Use the <code>SEND_CHANNEL_MESSAGE</code> command (see Commands).</p> <p>Important:  - The shared text envelope permits up to 160 UTF-8 bytes. For channel text,   firmware prepends <code>&lt;sender name&gt;:</code> inside that envelope, so the available   message body is <code>160 - prefix_bytes</code> and varies with the configured name. - Count encoded UTF-8 bytes, not Unicode characters. Split a longer message at   valid UTF-8 boundaries. - Include a chunk indicator (e.g., \"[1/3] message text\")</p>"},{"location":"companion_protocol/#response-parsing","title":"Response Parsing","text":""},{"location":"companion_protocol/#terminology","title":"Terminology","text":"<p>This document uses a spec-level naming convention (<code>PACKET_*</code>) for bytes the firmware sends back to the host. In the firmware source these same values are split across two <code>#define</code> families by purpose:</p> <ul> <li><code>RESP_CODE_*</code> - direct replies to a command (e.g. <code>RESP_CODE_CHANNEL_DATA_RECV</code> = <code>PACKET_CHANNEL_DATA_RECV</code> = 0x1B).</li> <li><code>PUSH_CODE_*</code> - asynchronous notifications not tied to a specific command (e.g. <code>PUSH_CODE_MSG_WAITING</code> = <code>PACKET_MESSAGES_WAITING</code> = 0x83).</li> </ul> <p>Byte values are authoritative; names are aliases. When reading firmware source, <code>RESP_CODE_X</code> / <code>PUSH_CODE_X</code> correspond to this doc's <code>PACKET_X</code> of the same numeric value.</p>"},{"location":"companion_protocol/#response-types","title":"Response types","text":"Value Firmware name Description <code>0x00</code> <code>RESP_CODE_OK</code> Command succeeded. <code>0x01</code> <code>RESP_CODE_ERR</code> Command failed; byte 1 is the error code. <code>0x02</code> <code>RESP_CODE_CONTACTS_START</code> Contact enumeration started. <code>0x03</code> <code>RESP_CODE_CONTACT</code> One contact record. <code>0x04</code> <code>RESP_CODE_END_OF_CONTACTS</code> Contact enumeration ended. <code>0x05</code> <code>RESP_CODE_SELF_INFO</code> Device self-information. <code>0x06</code> <code>RESP_CODE_SENT</code> Send accepted, with route/tag/timeout data. <code>0x07</code> / <code>0x08</code> <code>RESP_CODE_CONTACT_MSG_RECV</code> / <code>RESP_CODE_CHANNEL_MSG_RECV</code> Queued legacy-format message. <code>0x09</code> <code>RESP_CODE_CURR_TIME</code> Current device time. <code>0x0A</code> <code>RESP_CODE_NO_MORE_MESSAGES</code> Offline queue is empty. <code>0x0B</code> <code>RESP_CODE_EXPORT_CONTACT</code> Exported contact bytes. <code>0x0C</code> <code>RESP_CODE_BATT_AND_STORAGE</code> Battery and storage values. <code>0x0D</code> <code>RESP_CODE_DEVICE_INFO</code> Protocol and build information. <code>0x0E</code> <code>RESP_CODE_PRIVATE_KEY</code> Exported identity key, when enabled. <code>0x0F</code> <code>RESP_CODE_DISABLED</code> Requested sensitive feature is disabled. <code>0x10</code> / <code>0x11</code> <code>RESP_CODE_CONTACT_MSG_RECV_V3</code> / <code>RESP_CODE_CHANNEL_MSG_RECV_V3</code> Queued message with SNR fields. <code>0x12</code> <code>RESP_CODE_CHANNEL_INFO</code> Channel slot information. <code>0x13</code> / <code>0x14</code> <code>RESP_CODE_SIGN_START</code> / <code>RESP_CODE_SIGNATURE</code> Signing capacity or completed signature. <code>0x15</code> <code>RESP_CODE_CUSTOM_VARS</code> Custom-variable data. <code>0x16</code> <code>RESP_CODE_ADVERT_PATH</code> Cached advertisement path. <code>0x17</code> <code>RESP_CODE_TUNING_PARAMS</code> Tuning parameters. <code>0x18</code> <code>RESP_CODE_STATS</code> Requested statistics subtype. <code>0x19</code> <code>RESP_CODE_AUTOADD_CONFIG</code> Automatic-contact policy. <code>0x1A</code> <code>RESP_ALLOWED_REPEAT_FREQ</code> Allowed repeat-frequency ranges. <code>0x1B</code> <code>RESP_CODE_CHANNEL_DATA_RECV</code> Queued channel datagram. <code>0x1C</code> <code>RESP_CODE_DEFAULT_FLOOD_SCOPE</code> Default flood-scope data. <code>0x1D</code> <code>RESP_CODE_CLI_REPLY</code> Text returned by <code>CMD_RUN_CLI_COMMAND</code>."},{"location":"companion_protocol/#asynchronous-push-types","title":"Asynchronous push types","text":"Value Firmware name Description <code>0x80</code> <code>PUSH_CODE_ADVERT</code> Advertisement received. <code>0x81</code> <code>PUSH_CODE_PATH_UPDATED</code> A contact path changed. <code>0x82</code> <code>PUSH_CODE_SEND_CONFIRMED</code> A sent message was acknowledged. <code>0x83</code> <code>PUSH_CODE_MSG_WAITING</code> One or more offline frames are waiting. <code>0x84</code> <code>PUSH_CODE_RAW_DATA</code> Raw application data received. <code>0x85</code> / <code>0x86</code> <code>PUSH_CODE_LOGIN_SUCCESS</code> / <code>PUSH_CODE_LOGIN_FAIL</code> Server login result. <code>0x87</code> <code>PUSH_CODE_STATUS_RESPONSE</code> Server status response. <code>0x88</code> <code>PUSH_CODE_LOG_RX_DATA</code> Radio receive log data. <code>0x89</code> <code>PUSH_CODE_TRACE_DATA</code> Completed trace data. <code>0x8A</code> <code>PUSH_CODE_NEW_ADVERT</code> Newly stored contact advertisement. <code>0x8B</code> <code>PUSH_CODE_TELEMETRY_RESPONSE</code> Telemetry response. <code>0x8C</code> <code>PUSH_CODE_BINARY_RESPONSE</code> Binary request response. <code>0x8D</code> <code>PUSH_CODE_PATH_DISCOVERY_RESPONSE</code> Path-discovery response. <code>0x8E</code> <code>PUSH_CODE_CONTROL_DATA</code> Control/discovery data. <code>0x8F</code> <code>PUSH_CODE_CONTACT_DELETED</code> Oldest contact was deleted while making room. <code>0x90</code> <code>PUSH_CODE_CONTACTS_FULL</code> Contact storage is full."},{"location":"companion_protocol/#parsing-responses","title":"Parsing Responses","text":"<p>PACKET_OK (0x00):</p> <pre><code>Byte 0: 0x00\nBytes 1-4: Optional value (32-bit little-endian integer)\n</code></pre> <p>PACKET_ERROR (0x01):</p> <pre><code>Byte 0: 0x01\nByte 1: Error code (optional)\n</code></pre> <p>PACKET_CHANNEL_INFO (0x12):</p> <pre><code>Byte 0: 0x12\nByte 1: Channel Index\nBytes 2-33: Channel Name (32 bytes, null-terminated)\nBytes 34-49: Secret (16 bytes)\n</code></pre> <p>Note: The device returns the 16-byte channel secret in this response.</p> <p>PACKET_DEVICE_INFO (0x0D):</p> <pre><code>Byte 0: 0x0D\nByte 1: Firmware Version (uint8)\nBytes 2+: Variable length based on firmware version\n\nFor firmware version &gt;= 3:\nByte 2: Max Contacts Raw (uint8, actual = value * 2)\nByte 3: Max Channels (uint8)\nBytes 4-7: Active BLE PIN (32-bit little-endian; includes a generated session PIN)\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</code></pre> <p>Parsing Pseudocode:</p> <pre><code>def parse_device_info(data):\n    if len(data) &lt; 2:\n        return None\n\n    fw_ver = data[1]\n    info = {'fw_ver': fw_ver}\n\n    if fw_ver &gt;= 3 and len(data) &gt;= 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    if fw_ver &gt;= 9 and len(data) &gt;= 81:\n        info['client_repeat'] = data[80] != 0\n    if fw_ver &gt;= 10 and len(data) &gt;= 82:\n        info['path_hash_mode'] = data[81]\n\n    return info\n</code></pre> <p>PACKET_BATTERY (0x0C):</p> <pre><code>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</code></pre> <p>Parsing Pseudocode:</p> <pre><code>def parse_battery(data):\n    if len(data) &lt; 3:\n        return None\n\n    mv = int.from_bytes(data[1:3], 'little')\n    info = {'battery_mv': mv}\n\n    if len(data) &gt;= 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</code></pre> <p>PACKET_SELF_INFO (0x05):</p> <pre><code>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</code></pre> <p>Parsing Pseudocode:</p> <pre><code>def parse_self_info(data):\n    if len(data) &lt; 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 &gt;&gt; 4) &amp; 0b11\n    info['telemetry_mode_loc'] = (telemetry_mode &gt;&gt; 2) &amp; 0b11\n    info['telemetry_mode_base'] = telemetry_mode &amp; 0b11\n    info['manual_add_contacts'] = data[offset + 3] &gt; 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 &lt; len(data):\n        name_bytes = data[offset:]\n        info['name'] = name_bytes.decode('utf-8').rstrip('\\x00').strip()\n\n    return info\n</code></pre> <p>PACKET_MSG_SENT (0x06):</p> <pre><code>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</code></pre> <p>PACKET_SEND_CONFIRMED (0x82):</p> <pre><code>Byte 0: 0x82\nBytes 1-4: ACK code (32-bit little-endian)\nBytes 5-8: Round-trip time (32-bit little-endian, milliseconds)\n</code></pre>"},{"location":"companion_protocol/#error-codes","title":"Error Codes","text":"<p><code>PACKET_ERROR</code> (0x01) carries a single-byte error code in byte 1. Values match the <code>ERR_CODE_*</code> constants defined in <code>examples/companion_radio/MyMesh.cpp</code>:</p> Code Constant (firmware) Description 1 <code>ERR_CODE_UNSUPPORTED_CMD</code> Unknown or unsupported command byte / sub-command 2 <code>ERR_CODE_NOT_FOUND</code> Target not found (channel, contact, message, etc.) 3 <code>ERR_CODE_TABLE_FULL</code> Internal queue or table is full - retry later 4 <code>ERR_CODE_BAD_STATE</code> Operation not valid in current device state (e.g. iterator already running) 5 <code>ERR_CODE_FILE_IO_ERROR</code> Filesystem or storage I/O failure 6 <code>ERR_CODE_ILLEGAL_ARG</code> Invalid argument (bad length, out-of-range value, reserved field, etc.) <p>Note: Error codes may vary by firmware version. Always check byte 1 of <code>PACKET_ERROR</code> response, and treat unknown codes as generic errors.</p>"},{"location":"companion_protocol/#frame-handling","title":"Frame Handling","text":"<p>BLE implementations enqueue and deliver one protocol frame per BLE write/notification at the firmware layer.</p> <ul> <li>Apps should treat each characteristic write/notification as exactly one companion protocol frame</li> <li>Apps should still validate frame lengths before parsing</li> <li>Future transports or firmware revisions may differ, so avoid assuming fixed payload sizes for variable-length responses</li> </ul>"},{"location":"companion_protocol/#response-handling","title":"Response Handling","text":"<ol> <li>Command-Response Pattern:</li> <li>Send command via RX characteristic</li> <li>Wait for response via TX characteristic (notification)</li> <li>Match the response by the expected response type; frames do not carry a      general command sequence number</li> <li>Handle timeout (typically 5 seconds)</li> <li> <p>Use command queue to prevent concurrent commands</p> </li> <li> <p>Asynchronous Messages:</p> </li> <li>Device may send messages at any time via TX characteristic</li> <li>Handle <code>PACKET_MESSAGES_WAITING</code> (0x83) by polling <code>GET_MESSAGE</code> command</li> <li>Parse incoming messages and route to appropriate handlers</li> <li> <p>Validate frame length before decoding</p> </li> <li> <p>Response Matching:</p> </li> <li> <p>Match responses to commands by expected packet type:</p> <ul> <li><code>APP_START</code> -&gt; <code>PACKET_SELF_INFO</code></li> <li><code>DEVICE_QUERY</code> -&gt; <code>PACKET_DEVICE_INFO</code></li> <li><code>GET_CHANNEL</code> -&gt; <code>PACKET_CHANNEL_INFO</code></li> <li><code>SET_CHANNEL</code> -&gt; <code>PACKET_OK</code> or <code>PACKET_ERROR</code></li> <li><code>SEND_CHANNEL_MESSAGE</code> -&gt; <code>PACKET_MSG_SENT</code></li> <li><code>GET_MESSAGE</code> -&gt; <code>PACKET_CHANNEL_MSG_RECV</code>, <code>PACKET_CONTACT_MSG_RECV</code>, <code>PACKET_CHANNEL_DATA_RECV</code>, or <code>PACKET_NO_MORE_MSGS</code></li> <li><code>SEND_CHANNEL_DATA</code> -&gt; <code>PACKET_OK</code> or <code>PACKET_ERROR</code></li> <li><code>GET_BATTERY</code> -&gt; <code>PACKET_BATTERY</code></li> </ul> </li> <li> <p>Timeout Handling:</p> </li> <li>Default timeout: 5 seconds per command</li> <li>On timeout: Log error, clear current command, proceed to next in queue</li> <li>Some commands may take longer (e.g., <code>SET_CHANNEL</code> may need 1-2 seconds)</li> <li> <p>Consider longer timeout for channel operations</p> </li> <li> <p>Error Recovery:</p> </li> <li>On <code>PACKET_ERROR</code>: Log error code, clear current command</li> <li>On connection loss: Clear command queue, attempt reconnection</li> <li>On invalid response: Log warning, clear current command, proceed</li> </ol>"},{"location":"companion_protocol/#example-implementation-flow","title":"Example Implementation Flow","text":""},{"location":"companion_protocol/#initialization","title":"Initialization","text":"<pre><code># 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</code></pre>"},{"location":"companion_protocol/#creating-a-private-channel","title":"Creating a Private Channel","text":"<pre><code># 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 = choose_unused_slot(max_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</code></pre>"},{"location":"companion_protocol/#sending-a-message","title":"Sending a Message","text":"<pre><code># 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</code></pre>"},{"location":"companion_protocol/#receiving-messages_1","title":"Receiving Messages","text":"<pre><code>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</code></pre>"},{"location":"companion_protocol/#best-practices","title":"Best Practices","text":"<ol> <li>Connection Management:</li> <li>Implement auto-reconnect with exponential backoff</li> <li>Handle disconnections gracefully</li> <li> <p>Store last connected device address for quick reconnection</p> </li> <li> <p>Secret Management:</p> </li> <li>Always use cryptographically secure random number generators</li> <li>Store secrets securely (encrypted storage)</li> <li> <p>Never log or transmit secrets in plain text</p> </li> <li> <p>Message Handling:</p> </li> <li>Send <code>CMD_SYNC_NEXT_MESSAGE</code> when <code>PUSH_CODE_MSG_WAITING</code> is received</li> <li> <p>Implement message deduplication to avoid displaying the same message twice</p> </li> <li> <p>Channel Management:</p> <ul> <li>Fetch all channel slots even if you encounter an empty slot</li> <li>Ideally save new channels into the first empty slot</li> </ul> </li> <li> <p>Error Handling:</p> </li> <li>Implement timeouts for all commands (typically 5 seconds)</li> <li>Handle <code>RESP_CODE_ERR</code> responses appropriately</li> </ol>"},{"location":"companion_protocol/#troubleshooting","title":"Troubleshooting","text":""},{"location":"companion_protocol/#connection-issues","title":"Connection Issues","text":"<ul> <li>Device not found: Ensure device is powered on and advertising</li> <li>Connection timeout: Check Bluetooth permissions and device proximity</li> <li>GATT errors: Ensure proper service/characteristic discovery</li> </ul>"},{"location":"companion_protocol/#command-issues","title":"Command Issues","text":"<ul> <li>No response: Verify notifications are enabled, check connection state</li> <li>Error responses: Verify command format and check error code</li> <li>Timeout: Increase timeout value or try again</li> </ul>"},{"location":"companion_protocol/#message-issues","title":"Message Issues","text":"<ul> <li>Messages not received: Poll <code>GET_MESSAGE</code> command periodically</li> <li>Duplicate messages: Implement message deduplication using timestamp/content as a unique id</li> <li>Message truncation: Send long messages as separate shorter messages</li> </ul>"},{"location":"companion_radio_full/","title":"Full Companion","text":"<p><code>companion_radio_full</code> combines every qualified Companion transport for its platform into one artifact and acts as a host-backed LoRa mOTA source for updating other nodes. Most targets can run those transports simultaneously; the SenseCAP Indicator exception selects one secondary wireless transport per boot as described below.</p> <p>The full Companion is deliberately not a LoRa OTA destination: it has no firmware staging store, refuses <code>ota install</code>, and never advertises its own firmware as an mOTA image.</p> Capability ESP32 full nRF52 full USB Binary Companion Yes Yes BLE Binary Companion Yes Yes USB ASCII terminal Yes Yes Dedicated USB plaintext logging No - shares the one USB TTY Yes Host-backed LoRa mOTA source WiFi TCP 5001 Exclusive USB mode or encrypted BLE WiFi Companion/WebConfig Yes No - nRF52840 has no WiFi Hardware serial Companion On targets with assigned serial pins On targets with assigned serial pins Ethernet Companion On targets with an Ethernet module On RAK4631 with RAK13800 LoRa self-update No No"},{"location":"companion_radio_full/#sensecap-indicator-transport-and-rendering-exception","title":"SenseCAP Indicator transport and rendering exception","text":"<p>Both SenseCAP Indicator Full layouts keep USB available and start exactly one secondary wireless Companion transport per boot: BLE or infrastructure WiFi. The saved <code>companion.transport</code> selection takes effect after reboot. BLE mode does not start infrastructure WiFi, WebConfig, MQTT, TCP Companion, or network OTA services. WiFi mode never initializes BLE and releases its controller and host memory. LoRa remains the primary radio on the LoRa layout. ESP-NOW remains the primary mesh radio in both ESP-NOW modes, including BLE mode; only the infrastructure-WiFi services are omitted.</p> <p>The requested 4-bit internal render profiles are:</p> Primary radio Secondary Companion transport Canvas LoRa Infrastructure WiFi Native 480x480 LoRa BLE Native 480x480 ESP-NOW Infrastructure WiFi Native 480x480 ESP-NOW BLE 320x320, scaled 1.5x to the 480x480 panel <p>All four modes retain the same 160x160 logical UI. If a contiguous native DMA-capable block is unavailable, startup keeps the device usable with the 320x320 emergency fallback and reports the canvas actually retained. Such a fallback is not a successful native-480 validation result.</p>"},{"location":"companion_radio_full/#build-and-install","title":"Build and install","text":"<p>The target is synthesized by <code>build.sh</code> only for an exact board recipe that has passed the combined-transport size check:</p> <ul> <li>The normal automatic path requires matching WiFi, USB, and BLE recipes on   ESP32, or matching USB and BLE recipes on nRF52.</li> <li>A measured qualification list also promotes an exact BLE recipe when the   same board can safely add its platform's remaining transports. It never   substitutes the pin map or peripherals from another board.</li> </ul> <p>The measured ESP32 additions are M5Stack Unit C6L; XIAO C6/S3, Meshimi, WHY2025 Badge, LilyGo T-LoRa C6, T3S3 SX1262/SX1276, T-Deck, TETH Elite, classic T-Beam SX1262/SX1276, and T-Beam S3 Supreme; Heltec Wireless Tracker, Wireless Paper, E213, E290, T190, CT62, and V4 expansion-kit TFT; Generic ESP-NOW; SenseCAP Indicator ESP-NOW/LoRa; Ebyte EoRa-S3; and Meshadventurer SX1262/SX1268. The measured nRF52 additions are GAT562 Mesh Watch13, LilyGo T-Echo Lite, LilyGo T-Impulse Plus, and Wio Tracker L1 E-Ink. Their old transport-specific names remain available for explicit compatibility builds, but the Full image is the canonical release artifact.</p> <p>Every ESP32 Full image includes ordinary WiFi Companion, WebConfig, and the TCP mOTA services, even when its historical build base was USB- or BLE-only. On <code>Generic_ESPNOW</code> and <code>SenseCapIndicator-ESPNow</code>, ESP-NOW is also the primary mesh radio and shares the same 2.4 GHz hardware. Those two Full images retain B/G/N for ordinary clients alongside ESP-NOW LR. Their ESP-NOW mesh, setup AP, and infrastructure connection all use one persisted channel, which defaults to 1. Configure the router's 2.4 GHz radio and every other primary ESP-NOW node for that same fixed channel. Turning Companion WiFi off stops its TCP/AP services but deliberately leaves the ESP-NOW mesh radio running on the selected channel.</p> <p>Every ESP32 Full Companion with a station connection synchronizes its UTC clock from NTP after boot and explicitly refreshes it every 24 hours. The common WiFi path owns this for non-MQTT and runtime-unconfigured nodes; a configured MQTT bridge owns the same boot-and-daily schedule. Successful sync updates an attached hardware RTC as well as the ESP32 clock and suppresses LoRa clock fallback for that boot. Reconnecting WiFi preserves the existing daily deadline. A timeout leaves the existing clock and fallback intact and retries without blocking radio work.</p> <p>Inspect or change the shared channel from the Full Companion text terminal:</p> <pre><code>get espnow.channel\nset espnow.channel 6\nreboot\n</code></pre> <p>The accepted range is 1 through 13; use only a channel permitted in your region and supported by the router. The setter persists the selection, but the running radio stays on its current channel until reboot. Coordinate the change across every primary ESP-NOW node and the router before rebooting, or the node will lose one or both links. This primary-radio setting is not <code>bridge.channel</code>; that command belongs to the separate ESP-NOW bridge feature. To attach a LoRa-primary <code>*_repeater_bridge_espnow</code> gateway to these nodes, match its <code>bridge.channel</code> and select <code>set bridge.format raw</code>; the bridge's backward-compatible default is the distinct wrapped format. WiFi power saving cannot put infrastructure WiFi and ESP-NOW on different channels. On these two primary-ESP-NOW Full targets, <code>max</code> is unavailable because maximum modem sleep can make the station miss ESP-NOW broadcasts; use <code>min</code> for WiFi/BLE/ESP-NOW coexistence. The firmware also holds the ESP-IDF RF wake reference for the primary mesh radio, so the ESP-NOW receiver remains continuous even though the reported coexistence setting is <code>min</code>.</p> <p>List the available targets:</p> <pre><code>bash build.sh list | grep companion_radio_full\n</code></pre> <p>Build by using one exact listed name:</p> <pre><code>bash build.sh build-firmware heltec_v4_r8_companion_radio_full \\\n  --firmware-version v1.17.0\n\nbash build.sh build-firmware RAK_4631_companion_radio_full \\\n  --firmware-version v1.17.0\n</code></pre> <p>To build every canonical full Companion target, select the corresponding interactive menu item or run:</p> <pre><code>bash build.sh build-full-companion-firmwares \\\n  --firmware-version v1.17.0\n</code></pre> <p>Canonical Companion bulk builds also omit legacy <code>_ps</code> and <code>_femoff</code> aliases. Power saving and controllable FEM receive gain are persisted runtime settings; the old names remain available through an explicit <code>build-firmware</code> command for compatibility. Full Companion replaces separate USB, BLE, ordinary WiFi, hardware-serial, Ethernet Companion, Terminal Chat, and USB-only packet-logging release artifacts whenever the exact board supports those combined transports. Direct builds of the legacy targets remain available. RAK4631 repeater and room server Ethernet builds remain separate because they are different standalone roles, not Companion transports. nRF52 separates framed traffic and logs; ESP32 makes those modes mutually exclusive on its one USB TTY. In WebConfig, use the FEM RX boost switch. From the text terminal (USB, or TCP 5002 on ESP32), use:</p> <pre><code>get radio.rxgain\nset radio.rxgain off\nset radio.rxgain on\nget radio.fem.rxgain\nset radio.fem.rxgain off\nset radio.fem.rxgain on\nget radio.fem.txgain\nset radio.fem.txgain off\nset radio.fem.txgain on\n</code></pre> <p><code>radio.rxgain</code> controls the radio chip's boosted receive-gain mode; the FEM commands control the external receive and transmit paths. The selected states are applied immediately and retained after reboot. FEM TX gain is reported as unsupported on boards without software-selectable PA gain.</p> <p>SSD1306 display builds also persist a runtime orientation. This replaces the separate rotated Full Companion release image:</p> <pre><code>get display.rotation\nset display.rotation 90\nset display.rotation 180\nset display.rotation 270\nset display.rotation 0\n</code></pre> <p><code>0</code> resets the screen to that board's compiled default orientation.</p> <p>Heltec E290 and T190 now use their Full Companion artifacts for simultaneous USB, BLE, and WiFi. Their older <code>usb_ble</code>, USB-only, and BLE-only names remain available only as explicit compatibility builds.</p> <p>Heltec V3 and base OLED V4 Full Companion also include the former direct WiFi MQTT Companion capability. Configure and enable MQTT at runtime through WebConfig; the canonical release therefore publishes the Full image instead of a second <code>companion_radio_wifi_mqtt</code> image. V4 TFT and expansion-kit layouts remain separate hardware images because their display and I2C wiring differs.</p> <p>Device power saving is separate from LoRa RXPS. It can be changed in WebConfig with the Device power saving switch or from the text terminal:</p> <pre><code>powersaving\npowersaving on\npowersaving off\n</code></pre> <p>On ESP32, WiFi modem power saving is a third independent setting. Select it in the WebConfig WiFi card, or use the Full Companion text terminal:</p> <pre><code>get wifi.ssid\nget wifi.status\nget wifi.powersave\nget webui\nset wifi.ssid MyNetwork\nset wifi.pwd my-password\nset wifi.powersave min\nset wifi.powersave max\nstart webconfig\nstop webconfig\n</code></pre> <p>Full Companion does not expose the repeater/room-server browser CLI tab, so <code>get/set wifi.cli</code> explicitly report that the browser terminal is unavailable. Its complete Companion text terminal remains available over USB and TCP port 5002; this does not reduce that command surface.</p> <p>On the two primary-ESP-NOW Full targets, the same terminal also provides <code>get espnow.channel</code> and <code>set espnow.channel &lt;1-13&gt;</code>. A channel change is persisted and requires a reboot, unlike a WiFi power-save change.</p> <p>SSID and password writes return their reply first, then restart the Companion WiFi station with the saved credentials. A TCP terminal therefore disconnects shortly after either write; reconnect to the IP reported by the new network. The password is write-only and is masked while it is entered over USB. It may be empty for an open network, an ordinary passphrase of up to 63 characters, or an exact 64-character hexadecimal WPA/WPA2 PSK. Other 64-character values and all longer values are rejected.</p> <p>The normal binary Companion connection can also read or write this setting over USB, BLE, or TCP port 5000 without entering terminal mode. The mode values are <code>0</code> for <code>min</code>, <code>1</code> for <code>none</code>, and <code>2</code> for <code>max</code>; see the Companion protocol. A Full Companion that runs WiFi and BLE simultaneously rejects <code>none</code> because coexistence requires modem sleep. A primary-ESP-NOW Full target also rejects <code>max</code>; unlike infrastructure traffic, peer ESP-NOW broadcasts cannot be buffered by the access point while the station sleeps. If an older image saved a conflicting value, firmware applies and reports <code>min</code> instead. The SenseCAP Indicator uses the active-mode constraints in the exception above: LoRa + WiFi accepts all three values, ESP-NOW + WiFi accepts <code>none|min</code>, LoRa + BLE accepts <code>min|max</code> for the inactive WiFi setting, and ESP-NOW + BLE requires <code>min</code>. Fresh Cascade builds select <code>min</code>, and an existing valid saved selection takes precedence.</p> <p>On radios with RX duty-cycle support, WebConfig and the text terminal also expose the persisted RXPS setting:</p> <pre><code>get radio.rxps\nset radio.rxps off\nset radio.rxps on\nset radio.rxps level 8 preamble 16\nset radio.rxps 65625 60000\n</code></pre> <p>Fresh Cascade-profile Full Companion builds start with RXPS on at level 8 and a 16-symbol preamble. Changing it takes effect immediately and remains selected after reboot.</p> <p>Companion firmware defaults device power saving to on. Version 1.17.1.2 also turns it on once when upgrading an older Companion preference file, including one written by the short-lived default-off regression. After that one-time migration, an explicit <code>powersaving off</code> selection remains persistent.</p> <p>On ESP32, enabling it lowers the CPU clock to 80 MHz, enables idle yielding, and enables the configured GPS duty cycle. Disabling it restores the normal CPU clock and keeps GPS awake. Active Full Companion transports remain available in both states; on the SenseCAP Indicator this means USB plus the selected BLE or infrastructure-WiFi secondary transport. WiFi modem sleep stays enabled when BLE and the ESP32 WiFi radio are active together because coexistence requires it. Changing device power saving does not overwrite the saved WiFi power-save mode. While a native-USB host is enumerated, the platform sleep attempt is held off so USB CDC remains responsive; detaching the host releases that guard. CPU, radio-modem, and GPS power-saving settings remain active, and USB power from a charger alone does not create a Companion session. The selected state is retained after reboot.</p> <p>On the LilyGo T-Beam 1W Full Companion, press the physical <code>BOOT</code> button once to turn the ESP32 WiFi radio and all WiFi services off or on. The screen confirms <code>WiFi: OFF</code> or <code>WiFi: ON</code>, and the selected state is retained after reboot. When WiFi is off, TCP ports 5000-5002, WebConfig, and MQTT are stopped; USB, BLE, the display, GPS, and LoRa continue to operate. Press BOOT again to restore WiFi, including the saved station or setup-AP mode. On boot, BLE starts two seconds after WiFi/WebConfig so their peak startup allocations do not overlap.</p> <p>Artifacts are written to <code>out/</code> by default.</p> <p>Full Companion behavior is selected with independent capability macros for TempRadio, the OTA CLI, the TCP terminal, USB folder seeding, and memory diagnostics. The legacy <code>COMPANION_RADIO_FULL</code> flag remains an input for older target recipes, but application behavior no longer uses that umbrella as an unrelated compile guard. In particular, ESP32 WiFi/WebConfig terminal controls are compiled from their actual WiFi/WebConfig capability. On targets that run ESP32 WiFi and BLE simultaneously, BLE is started first to avoid heap fragmentation. The SenseCAP Indicator starts only its selected secondary transport. Compile-time prerequisite checks reject inconsistent feature flags. After linking, the capability sidecar verifies USB, BLE, the OTA CLI, TempRadio, and each platform's host-folder transport; it also verifies the TCP terminal, WebConfig, and WiFi seeder on ESP32, plus dedicated logging on nRF52.</p> <p>On 4 MB ESP32 boards, the full target uses a single 3 MB application partition so WiFi, BLE, WebConfig, and source-only mOTA fit in one artifact. The T-Beam 1W Full Companion uses that same LilyGo factory-compatible boot layout on its 16 MB flash because this source-only role does not install updates into a second app slot. Flash the generated <code>-merged.bin</code> when first installing this partition layout. Other boards with 8 MB or more retain dual application partitions. Heltec V2 and TLora V2 use 100 contacts, 8 group channels, and a 16-frame offline queue in this combined profile because of internal DRAM limits. Meshadventurer SX1262 and SX1268 retain 160 contacts, use 30 group channels, and use a 64-frame queue. That is the smallest measured reduction which cleared their classic ESP32 internal-DRAM link limit; their ordinary transport-specific images retain 160 contacts, 40 channels, and 128 queued frames.</p> <p>Full Companions normally retain 256 pending Companion message frames. ESP32 boards with configured PSRAM retain 512 and allocate that queue from PSRAM before WiFi and BLE start. If PSRAM is unavailable at runtime, allocation falls back through 256 and 128 frames, then to a 16-frame internal buffer. The Full Companion startup memory line reports the capacity actually allocated as <code>offline_queue=&lt;frames&gt;</code>. The queue is volatile and shared by all channels and direct messages; it is not flash-backed history. See Companion offline message queue for all platform defaults and full-queue behavior.</p> <p>The nRF52 target inherits the board's ordinary USB Companion installation format and adds BLE plus the serial mOTA source. It does not enable an SD cache or any other board-specific storage behavior; host files are streamed as they are requested. Its image is bounded by the board's normal application region, not the smaller OTAFIX in-place workspace reserved for firmware that can update itself.</p>"},{"location":"companion_radio_full/#interfaces","title":"Interfaces","text":"Platform Interface Purpose Both USB, 115200 baud ASCII after boot; automatically switches on the first complete Binary Companion frame Both BLE Binary Companion; display builds show a random session PIN, while headless builds default to <code>123456</code> ESP32 TCP 5000 Binary Companion over WiFi ESP32 HTTP 80 Companion WebConfig and first-boot WiFi setup ESP32 TCP 5001 Host <code>.mota</code> folder from <code>motatool serve --tcp</code> ESP32 TCP 5002 Full Companion text terminal; same role commands as the USB terminal nRF52 USB mOTA mode Host <code>.mota</code> folder from <code>motatool serve --serial</code> nRF52 Encrypted BLE mOTA service Paired phone/tablet/Linux host <code>.mota</code> catalog <p>Delivery-required replies are returned only to the interface which supplied the latest command. A contact-list stream keeps that route locked from <code>CONTACTS_START</code> through <code>END_OF_CONTACTS</code>; commands waiting on another interface are read after the stream finishes. Best-effort asynchronous observations such as adverts remain broadcast so passive clients can refresh their views. Companion session state is device-wide, so use one active Companion application at a time. On nRF52, BLE remains available while USB is in terminal or mOTA mode.</p> <p>USB Binary output is queued as complete length-prefixed frames. Temporary CDC or UART backpressure pauses the contact stream; a frame may drain through a smaller hardware FIFO in ordered chunks, but its remainder is retained and no later frame can interleave with it or cause it to be discarded.</p> <p>When a BLE client requests pairing, a display-equipped build wakes the screen, switches to the first home page, and keeps the active six-digit PIN visible until Bluetooth connects or the two-minute pairing window expires. USB, WiFi, Ethernet, and hardware-serial connections do not suppress this screen. With no saved BLE PIN, display builds generate a new PIN at boot; builds without a physical display use <code>123456</code>. A PIN saved through the Companion protocol takes effect after reboot.</p> <p>The Bluetooth device name is independently configurable. In the text terminal, use <code>get bluetooth.name</code> and <code>set bluetooth.name &lt;name&gt;</code>; use <code>set bluetooth.name default</code> to restore <code>MeshCore-&lt;node name&gt;</code>. The WebConfig Node card exposes the same optional field on Bluetooth-capable ESP32 builds. Custom names replace the complete Bluetooth label rather than inheriting the prefix, accept up to 31 valid UTF-8 bytes, and take effect after reboot. This does not change the node's mesh advertisement name.</p> <p>ESP32 ports 5000, 5001, 5002, and WebConfig have no independent login layer. Expose them only on a trusted LAN or temporary setup network. See WiFi setup for credential setup and reconnect behavior.</p>"},{"location":"companion_radio_full/#usb-binary-and-text-terminal-modes","title":"USB Binary and text terminal modes","text":"<p>Full Companion USB starts in the ASCII terminal after boot. MeshCore apps and <code>meshcli</code> send a <code>&lt;</code>-prefixed framed command, which automatically hands the untouched frame to the Binary Companion parser:</p> <pre><code>meshcli -s /dev/ttyACM0 -b 115200 ver\n</code></pre> <p>The automatic probe runs only at an empty prompt. A complete frame confirms binary mode; an incomplete probe returns to ASCII after one second. Binary mode then remains selected until reboot or the explicit terminal start token. See Full Companion USB CLI and binary switcher for the byte-level state machine, logging and mOTA ownership, recovery paths, and known limitations.</p> <p>Immediately after boot, an ordinary terminal can issue ASCII commands without a start token. If the device is already in Binary Companion mode, open the port with the terminal start token sent automatically:</p> <pre><code>picocom -b 115200 \\\n  --imap spchex \\\n  --initstring $'+++MESHCORE-TERM-START\\r' \\\n  /dev/ttyACM0\n</code></pre> <p>The input map prevents any Binary Companion control bytes received during the mode transition from changing the local terminal's character set or display state while leaving UTF-8 emoji intact. The banner confirms that terminal mode is active; do not enter the start token again after it appears.</p> <p>The terminal supports Companion chat commands, including <code>channels</code>, <code>channel &lt;name-or-slot&gt; &lt;message&gt;</code>, remote administration with <code>login &lt;admin-password&gt;</code> and <code>cmd &lt;remote-command&gt;</code>, and routed <code>trace [recipient-name-or-prefix]</code>, plus local <code>ota</code>, <code>tempradio</code>, and <code>normalradio</code> controls. <code>board</code> reports the exact hardware target. ESP32 Full Companion also provides <code>memory</code>, which reports heap, internal allocation, PSRAM, and offline-queue usage; it is omitted from non-ESP32 help. ESP32 builds also provide local WiFi credential, status, WebConfig, and power-save controls. Every Full Companion provides persistent <code>get/set usb.logging</code> and starts with logging off on a fresh installation.</p>"},{"location":"companion_radio_full/#esp32-single-usb-serial-port","title":"ESP32 single USB serial port","text":"<p>Every ESP32 Full Companion exposes one USB TTY with two exclusive modes. It starts as the ASCII terminal unless a saved logging-on preference boots directly into the logging terminal. If it is already binary, enter its text terminal with <code>+++MESHCORE-TERM-START</code>, then run <code>set usb.logging on</code>; the same TTY emits plaintext packet/debug logs and continues accepting CLI commands, including <code>set usb.logging off</code>. Framed Binary Companion is unavailable on USB while logging owns the TTY. Turning logging off sends the command reply, stops the logs, and leaves that TTY in the normal ASCII terminal, matching a fresh Full installation. Send <code>+++MESHCORE-TERM-STOP</code>, or let a Companion app send a valid framed probe, to switch it to Binary Companion afterward. A saved logging-on preference boots directly into this input-capable logging terminal. BLE and Wi-Fi Companion remain available while USB is logging on simultaneous targets. On the SenseCAP Indicator, only the selected BLE or Wi-Fi Companion transport remains available alongside the logging terminal.</p> <p>ESP32 Full Companion uses the repository's Arduino-ESP32 2.x platform base where the board supports it. RC32 and ESP32-C6 retain their board-required Arduino 3.x platform, but follow the same one-TTY policy. No ESP32 Full image creates an optional second CDC interface. The single-TTY behavior applies to native-USB ESP32-S3 boards and boards using a USB-UART bridge.</p>"},{"location":"companion_radio_full/#nrf52-dual-usb-serial-ports","title":"nRF52 dual USB serial ports","text":"<p>Current nRF52 Full Companion firmware can expose two CDC ACM serial interfaces on one physical USB cable:</p> <ul> <li>USB interface <code>00</code> is the primary Companion, text-terminal, and serial-mOTA   source port. It is always present, starts in ASCII after boot, and   automatically hands a complete <code>&lt;</code> frame to Binary Companion.</li> <li>USB interface <code>02</code> is the optional write-only plaintext packet/debug logging   port. Host input on this interface is ignored and cannot invoke firmware   commands.</li> </ul> <p>A fresh Full Companion starts with USB logging off and therefore enumerates only interface <code>00</code>. Use <code>set usb.logging on</code> to save logging on; the reply says that a reboot is required. Use <code>set usb.logging on reboot</code> to save it and have the node reboot automatically after the reply. The second interface appears after that reboot. Likewise, <code>set usb.logging off reboot</code> removes interface <code>02</code>. The optional <code>reboot</code> word is accepted only in these exact command forms and triggers a reboot only when the descriptor actually needs to change.</p> <p>These are Full Companion text-terminal commands. The superficially similar <code>meshcli ... get usb.logging</code> command uses the Binary Companion parameter registry and can report <code>Unknown var usb.logging</code>; it does not forward that line to the text terminal. Enter terminal mode on interface <code>00</code> with the <code>+++MESHCORE-TERM-START</code> token as described above, then issue the command.</p> <p>When logging is on, Linux normally shows two <code>/dev/ttyACM*</code> devices. Match the stable <code>/dev/serial/by-id/*-if00</code> and <code>*-if02</code> links, or use a udev rule matching <code>ID_USB_INTERFACE_NUM</code>, rather than assuming which tty number is assigned. On Windows they appear as two COM ports; identify them by USB interface instead of depending on a particular COM number. The nRF52 bootloader temporarily exposes its normal DFU serial interface during an update.</p> <p>Opening the nRF52 logging port prints <code>MeshCore USB logging port</code> followed by its portable identity, <code>USB CDC 1; interface 02; Linux stable suffix: -if02</code>. <code>get usb.logging</code> reports the same endpoint. Firmware cannot print the exact <code>/dev/ttyACM*</code> or <code>COM*</code> name because Linux, macOS, or Windows assigns that name after USB enumeration; use the <code>*-if02</code> link on Linux to obtain the exact path. For example, <code>readlink -f /dev/serial/by-id/*-if02</code> prints the host-assigned <code>/dev/ttyACM*</code> name.</p> <p>Every ESP32-S3 Full Companion image uses DIO flash mode, including the RAK3112 and RC32 profiles. The S3 ROM supports DIO while loading the software bootloader, and some flash configurations fail before the application starts when a merged image inherits QIO. DIO trades some maximum flash-read throughput for compatibility; it does not change a board's PSRAM type or any ordinary non-Full firmware profile.</p> <p>On nRF52, point MeshCore Companion software, <code>meshcli</code>, and <code>motatool</code> at interface <code>00</code>. When enabled and rebooted, point a plaintext reader or USB-connected MQTT service at interface <code>02</code>. On ESP32, use its only USB TTY for Binary Companion while logging is off, or for the plaintext CLI/logger while logging is on; close one consumer before switching modes. Turning logging off returns to ASCII, so the normal stop token or a valid framed probe is still required before Binary Companion owns the port.</p> <p>ESP32 Full Companion exposes this same text terminal on TCP port 5002. Connect with <code>nc DEVICE_IP 5002</code>; no USB control token is needed. USB terminal mode and the TCP terminal share recipient, login, command, trace, and display state, so only one may own the terminal at a time. The idle startup USB prompt yields to a TCP connection when no USB data client or partial command is present, and is restored when TCP disconnects. An active USB session rejects TCP; entering USB terminal mode later closes an active TCP session. On USB-Serial-JTAG and USB-to-UART hardware, the firmware cannot observe an idle host open, so actual buffered USB activity\u2014not the physical cable alone\u2014claims ownership. Disconnecting TCP clears pending terminal-only state without cancelling Binary Companion delivery or radio retries.</p> <p>Both terminal transports accept <code>reboot</code>. The reply is sent first and the device reboots one second later, so a script can distinguish an accepted reboot from an abruptly lost connection.</p> <p>Port 5002 is plaintext and has no device-local login gate. A remote-admin password entered with <code>login</code> is sent across the LAN connection as typed even though the terminal does not echo it. Use port 5002 only on a trusted LAN or a temporary setup network.</p> <p>For example:</p> <pre><code>channels\nchannel #rgdata Hello from Eugene \ud83d\udc4b\nshow\nshow channels on\nto Hilltop Repeater\npath A1B2C3,D4E5F6\npath 7773D0 7E7662\nlogin my-admin-password\ncmd ver\ntrace\n</code></pre> <p>The terminal <code>list [n]</code> command displays favorite contacts first and orders each favorite/non-favorite group by its most recent advertisement. This does not alter the binary Companion contact-list protocol.</p> <p>Unsolicited terminal output starts in a quiet mode: advertisements and ordinary channel messages are hidden, while <code>#emergency</code> messages remain visible. Use <code>show adverts on|off</code>, <code>show channels on|off</code>, and <code>show emergency on|off</code> to control each category independently; plain <code>show</code> reports their state. These runtime filters affect terminal printing only and reset to their defaults after reboot.</p> <p>The <code>to</code> command selects the remote-administration target. <code>path</code> shows its saved outgoing route; <code>path direct</code>, <code>path clear</code>, or a list separated by spaces, commas, or both changes the route used by subsequent <code>login</code>, <code>send</code>, and <code>cmd</code> commands. Every hop must use the same 2-, 4-, or 6-digit hexadecimal width. Login passwords are masked during entry and limited by the radio protocol to 15 UTF-8 bytes. Wait for the asynchronous login result before using <code>cmd</code>; command replies appear as <code>CLI -&gt; from &lt;name&gt;</code> and use a response window of 300% of the route estimate. <code>DIRECT via path &lt;hop,...&gt;</code> displays the exact saved prefixes copied into the packet. Remote ACL permissions determine which commands the target accepts. The matching reply reports its round-trip time from local queueing through result reception, including radio transit and remote execution. Only one terminal <code>cmd</code> can be pending at a time.</p> <p>Incoming unicast replies are labeled <code>ROUTED</code>. Their exact return prefixes are not available at the destination because each forwarder consumes its prefix; use <code>trace</code> to verify the return route.</p> <p>With no argument, <code>trace</code> uses the current <code>to</code> recipient. A name-prefix argument traces that contact directly without changing the current recipient. The contact must already have a known direct path; results show the SNR at each hop, or a timeout if the round trip does not return.</p> <p>An explicit route can use 1-, 2-, or 4-byte hexadecimal prefixes. Spaces, commas, and mixed separators are accepted:</p> <pre><code>trace path 1 12 34 56 34 12\ntrace path 2 1234,ABCD,5678,ABCD,1234\ntrace path 4 12345678, ABCDEF01 89ABCDEF, ABCDEF01,12345678\n</code></pre> <p>The entered route must include both the outward and return prefixes. Exact three-byte traces are not supported.</p> <p>Return to Binary mode with:</p> <pre><code>+++MESHCORE-TERM-STOP\n</code></pre> <p>Closing an armed ASCII USB data connection also changes the port to Binary mode when the hardware can report disconnect. A USB-to-UART bridge may not be able to report this event. A different baud rate, including 57600, does not select ASCII mode.</p> <p>On an ESP32 Full Companion built with <code>OTA_FOLDER_SERIAL</code>, <code>motatool</code> can keep the USB serial port open as an mOTA folder source when WiFi is unavailable:</p> <pre><code>motatool serve --serial /dev/ttyACM0 --dir ./motas -v\n</code></pre> <p>The tool sends the exact completed <code>ota folder on</code> line when it opens the port. Firmware recognizes it in startup ASCII or idle Binary Companion mode, then transfers the port to exclusive USB mOTA ownership before binary request/reply frames begin. The text terminal and Binary Companion are unavailable on that TTY until <code>motatool</code> detaches the folder. This matches the nRF52 ownership behavior described below. TCP port 5001 remains the preferred unattended source transport.</p>"},{"location":"companion_radio_full/#nrf52-usb-mota-mode","title":"nRF52 USB mOTA mode","text":"<p>The nRF52 full target has a third, exclusive USB mode for the host folder. Unmodified <code>motatool serve --serial</code> sends <code>ota folder on</code> when it opens the port. The startup ASCII terminal recognizes that exact completed line, leaves terminal mode, and gives the stream directly to exclusive mOTA handling. If the port is already in Binary Companion mode, the idle binary parser recognizes the same control sequence. The sequence is not examined inside a framed Binary Companion packet. See the switcher guide for the ownership transitions.</p> <p>While mOTA mode owns USB:</p> <ul> <li>mOTA manifests and blocks stream from the computer on demand.</li> <li>USB Binary and the USB text terminal are unavailable.</li> <li>BLE Binary Companion remains available.</li> <li><code>motatool</code> sending <code>ota folder off</code>, or disconnecting the USB data session,   detaches the folder and restores Binary mode.</li> </ul> <p>No modified <code>motatool</code> build, terminal token, or preliminary mode change is required.</p>"},{"location":"companion_radio_full/#nrf52-bluetooth-mota-source","title":"nRF52 Bluetooth mOTA source","text":"<p>Protocol v14 also lets a phone, tablet, or Bluetooth-capable Linux host feed the <code>.mota</code> catalog to an nRF52 Full Companion. Normal Companion commands stay on the Nordic UART service. Firmware data uses a separate GATT service, so binary app traffic cannot be mistaken for a firmware block.</p> <p>The client must pair with the Companion PIN, subscribe to the mOTA Device Request characteristic, and send <code>CMD_BLE_MOTA_SOURCE</code> action <code>start</code> over the normal Binary Companion connection. The source is available only while that encrypted MITM-authenticated connection remains active. Disconnecting, unsubscribing, overflowing a frame, or receiving malformed data automatically detaches the catalog. USB and BLE source modes are mutually exclusive.</p> <p>The included Raspberry Pi reference client validates each <code>.mota</code> with <code>motatool</code>, schedules the local TempRadio window, serves until interrupted, then detaches and restores the normal radio tuple:</p> <pre><code>python3 tools/ble_mota/ble_mota_seeder.py \\\n  --device MeshCore-MyCompanion \\\n  --dir ./motas \\\n  --local 'tempradio 909.950,250,5,5,120'\n</code></pre> <p>Prefer this relative <code>tempradio</code> form when the phone/Pi and radio clocks may disagree. It starts a duration on the Companion and does not compare their wall clocks. Use the absolute <code>tempradioat</code> scheduler only after synchronizing the participating nodes.</p> <p>Use <code>--pair</code> when the Linux host has not already bonded. BlueZ must have an agent capable of entering or confirming the six-digit PIN. Use <code>--source status</code> without <code>--dir</code> for a read-only channel/status check. The complete UUID, frame, action, and status definitions are in the Companion protocol.</p> <p>This reference process stands in for the phone application. A mobile app can use the same sequence while retaining its normal contact and Repeater Admin UI: log in to the destination, put each required node on the same bounded TempRadio tuple, start the local Bluetooth catalog, then send the normal remote <code>ota ls</code>, <code>ota pull</code>, and <code>ota install</code> commands. The destination still checks container geometry, hardware identity, hashes, signature policy, and the OTAFIX bootloader before installation.</p>"},{"location":"companion_radio_full/#serve-mota-images-manually","title":"Serve mOTA images manually","text":"<p>First put the destination, required relays, controller, and source on the same bounded TempRadio tuple. The example frequency below is not legal everywhere; choose a legal tuple supported by every participating radio.</p>"},{"location":"companion_radio_full/#esp32-source","title":"ESP32 source","text":"<p>Use the local console to start TempRadio:</p> <pre><code>nc 192.168.1.50 5002\n</code></pre> <pre><code>tempradio 909.950,250,5,5,120\nota status\n</code></pre> <p>Then start the dedicated TCP seeder:</p> <pre><code>motatool serve --dir ./motas --tcp 192.168.1.50:5001 -v\n</code></pre>"},{"location":"companion_radio_full/#nrf52-source","title":"nRF52 source","text":"<p>Use the USB terminal briefly to schedule TempRadio, then return to Binary mode and close the terminal:</p> <pre><code>picocom -b 115200 \\\n  --imap spchex \\\n  --initstring $'+++MESHCORE-TERM-START\\r' \\\n  /dev/ttyACM1\n</code></pre> <pre><code>tempradio 909.950,250,5,5,120\n+++MESHCORE-TERM-STOP\n</code></pre> <p>After sending the stop token, exit <code>picocom</code> with Ctrl-A, Ctrl-X.</p> <p>Start the serial seeder on that same port:</p> <pre><code>motatool serve --dir ./motas --serial /dev/ttyACM1 --baud 115200 -v\n</code></pre> <p><code>motatool</code> switches the port into mOTA mode automatically. Stop it with Ctrl-C to detach the folder. Reopen the terminal and use <code>normalradio</code> if the source should return early; otherwise the saved radio settings return when the bounded window expires.</p> <p>As a cable-free alternative, keep the normal Companion BLE session open and run the Bluetooth reference client shown in the nRF52 Bluetooth section. Do not run the USB seeder at the same time.</p> <p>Both platforms intentionally refuse firmware installation commands such as:</p> <pre><code>ota pull &lt;id&gt; flash\nota install\nota dev ...\n</code></pre>"},{"location":"companion_radio_full/#script-a-complete-update","title":"Script a complete update","text":"<p>The Bash and PowerShell wrappers accept a release ZIP or ready <code>.mota</code>, set up TempRadio, run <code>motatool</code>, monitor the exact image, install it on the destination, and restore the radio path. Use a separate Companion as the controller.</p> <p>For an ESP32 full source:</p> <pre><code>export MESHCORE_ADMIN_PASSWORD='target-admin-password'\n\n./tools/lora_ota/lora_ota.sh ./release.zip \"Roof Node\" \\\n  --controller-serial /dev/ttyACM0 \\\n  --source-tcp 192.168.1.50:5001 \\\n  --source-cli-tcp 192.168.1.50:5002\n</code></pre> <p>For an nRF52 full source, the script automatically detects the token-switched terminal and uses the same source port sequentially for control and seeding:</p> <pre><code>export MESHCORE_ADMIN_PASSWORD='target-admin-password'\n\n./tools/lora_ota/lora_ota.sh ./release.zip \"Roof Node\" \\\n  --controller-serial /dev/ttyACM0 \\\n  --source-serial /dev/ttyACM1\n</code></pre> <pre><code>$env:MESHCORE_ADMIN_PASSWORD = 'target-admin-password'\n\n&amp; .\\tools\\lora_ota\\lora_ota.ps1 '.\\release.zip' 'Roof Node' `\n  --controller-serial COM7 `\n  --source-serial COM8\n</code></pre> <p>See the start-to-finish LoRa OTA guide for package selection, nRF52 in-place deltas, relays, trust checks, and recovery behavior.</p>"},{"location":"docs/","title":"Local Documentation","text":"<p>This document explains how to build and view the MeshCore documentation locally.</p>"},{"location":"docs/#building-and-viewing-docs","title":"Building and viewing Docs","text":"<pre><code>pip install mkdocs\npip install mkdocs-material\n</code></pre> <ul> <li><code>mkdocs serve</code> - Start the live-reloading docs server.</li> <li><code>mkdocs build</code> - Build the documentation site.</li> </ul>"},{"location":"faq/","title":"Frequently Asked Questions","text":"<p>A list of frequently-asked questions and answers for MeshCore</p> <ul> <li>Frequently Asked Questions</li> <li>1. Introduction<ul> <li>1.1. Q: What is MeshCore?</li> <li>1.2. Q: What do you need to start using MeshCore?<ul> <li>1.2.1. Hardware</li> <li>1.2.2. Firmware</li> <li>1.2.3. Companion Radio Firmware</li> <li>1.2.4. Repeater</li> <li>1.2.5. Room Server</li> </ul> </li> </ul> </li> <li>2. Initial Setup<ul> <li>2.1. Q: How many devices do I need to start using MeshCore?</li> <li>2.2. Q: Does MeshCore cost any money?</li> <li>2.3. Q: What frequencies are supported by MeshCore?</li> <li>2.4. Q: What is an \"advert\" in MeshCore?</li> <li>2.5. Q: Is there a hop limit?</li> </ul> </li> <li>3. Server Administration<ul> <li>3.1. Q: How do you configure a repeater or a room server?</li> <li>3.2. Q: Do I need to set the location for a repeater?</li> <li>3.3. Q: What is the password to administer a repeater or a room server?</li> <li>3.4. Q: What is the password to join a room server?</li> <li>3.5. Q: Can I retrieve a repeater's private key or set a repeater's private key?</li> <li>3.6. Q: The first byte of my repeater's public key collides with an existing repeater on the mesh. How do I get a new private key with a matching public key that has its first byte of my choosing?</li> <li>3.7. Q: My repeater may be suffering from deafness due to high power interference near my mesh's frequency, it is not hearing other in-range MeshCore radios. What can I do?</li> <li>3.8. Q: How do I make my repeater an observer on the mesh?</li> <li>3.9. Q: What is multibyte support? What do 1-byte, 2-byte, 3-byte adverts and messages mean?</li> <li>3.9.1. Q: What path hash sizes will my repeater forward?</li> <li>3.9.2. Q: What determines a packet's path hash size?</li> <li>3.9.3. Q: How do I change my companion's path hash size?</li> <li>3.9.4. Q: What does the CLI command <code>path.hash.mode</code> do on a repeater?</li> <li>3.9.5. Q: Why use 2- or 3-byte path hash for adverts?</li> <li>3.9.6. Q: When can we move away from 1-byte path hash for channel and direct messages?</li> </ul> </li> <li>4. T-Deck Related<ul> <li>4.1. Q: Is there a user guide for T-Deck, T-Pager, T-Watch, or T-Display Pro?</li> <li>4.2. Q: What are the steps to get a T-Deck into DFU (Device Firmware Update) mode?</li> <li>4.3. Q: Why is my T-Deck Plus not getting any satellite lock?</li> <li>4.4. Q: Why is my OG (non-Plus) T-Deck not getting any satellite lock?</li> <li>4.5. Q: What size of SD card does the T-Deck support?</li> <li>4.6. Q: What is the public key for the default public channel?</li> <li>4.7. Q: How do I get maps on T-Deck?</li> <li>4.8. Q: Where do the map tiles go?</li> <li>4.9. Q: How to unlock deeper map zoom and server management features on T-Deck?</li> <li>4.10. Q: How to decipher the diagnostics screen on T-Deck?</li> <li>4.11. Q: The T-Deck sound is too loud?</li> <li>4.12. Q: Can you customize the sound?</li> <li>4.13. Q: What is the 'Import from Clipboard' feature on the t-deck and is there a way to manually add nodes without having to receive adverts?</li> <li>4.14. Q: How to capture a screenshot on T-Deck?</li> </ul> </li> <li>5. General<ul> <li>5.1. Q: What are BW, SF, and CR?</li> <li>5.2. Q: Do MeshCore clients repeat?</li> <li>5.3. Q: What happens when a node learns a route via a mobile repeater, and that repeater is gone?</li> <li>5.4. Q: How does a node discover a path to its destination and then use it to send messages in the future, instead of flooding every message it sends like Meshtastic?</li> <li>5.5. Q: Do public channels always flood? Do private channels always flood?</li> <li>5.6. Q: What is the public key for the default public channel?</li> <li>5.7. Q: Is MeshCore open source?</li> <li>5.8. Q: How can I support MeshCore?</li> <li>5.9. Q: How do I build MeshCore firmware from source?</li> <li>5.10. Q: Are there other MeshCore related open source projects?</li> <li>5.11. Q: Does MeshCore support ATAK?</li> <li>5.12. Q: How do I add a node to the MeshCore Map?</li> <li>5.13. Q: Can I use a Raspberry Pi to update a MeshCore radio?</li> <li>5.14. Q: Are there projects built around MeshCore?</li> <li>5.15. Q: Are there client applications for Windows or Mac?</li> <li>5.16. Q: Are there any resources that compare MeshCore to other LoRa systems?</li> </ul> </li> <li>6. Troubleshooting<ul> <li>6.1. Q: My client says another client or a repeater or a room server was last seen many, many days ago.</li> <li>6.2. Q: A repeater or a client or a room server I expect to see on my discover list (on T-Deck) or contact list (on a smart device client) are not listed.</li> <li>6.3. Q: How to connect to a repeater via BLE (Bluetooth)?</li> <li>6.4. Q: My companion isn't showing up over Bluetooth?</li> <li>6.5. Q: I can't connect via Bluetooth, what is the Bluetooth pairing code?</li> <li>6.6. Q: My Heltec V3 keeps disconnecting from my smartphone. It can't hold a solid Bluetooth connection.</li> <li>6.7. Q: My RAK/T1000-E/xiao_nRF52 device seems to be corrupted, how do I wipe it clean to start fresh?</li> <li>6.8. Q: WebFlasher fails on Linux with failed to open</li> </ul> </li> <li>7. Other Questions:<ul> <li>7.1. Q: How to update nRF (RAK, T114, Seeed XIAO) companion, repeater and room server firmware over the air using the new simpler DFU app?<ul> <li>7.1.1 Q: Can I update Seeed Studio Wio Tracker L1 Pro using OTA?</li> </ul> </li> <li>7.2. Q: How to update ESP32-based devices over the air?</li> <li>7.3. Q: Is there a way to lower the chance of a failed OTA device firmware update (DFU)?</li> <li>7.4. Q: are the MeshCore logo and font available?</li> <li>7.5. Q: What is the format of a contact or channel QR code?</li> <li>7.6. Q: How do I connect to the companion via Wi-Fi, e.g. using a Heltec V3?</li> <li>7.7. Q: I have a Station G2, or a Heltec V4, or an Ikoka Stick, or a radio with an EByte E22-900M30S or an EByte E22-900M33S module, what should their transmit power be set to?</li> <li>7.8. Q: How do I use Ethernet with a RAK4631?</li> </ul> </li> </ul>"},{"location":"faq/#1-introduction","title":"1. Introduction","text":""},{"location":"faq/#11-q-what-is-meshcore","title":"1.1. Q: What is MeshCore?","text":"<p>A: MeshCore is a multi-platform system for enabling secure text-based communications utilizing LoRa radio hardware. It can be used for Off-Grid Communication, Emergency Response &amp; Disaster Recovery, Outdoor Activities, Tactical Security including law enforcement and private security and also IoT sensor networks. (source)</p> <p>MeshCore is free and open source:</p> <ul> <li>MeshCore is the routing and firmware etc., available on GitHub under MIT license</li> <li>There are clients made by the community, such as the web clients, these are free to use, and some are open source too</li> <li>The cross-platform mobile app developed by Liam Cottle for Android/iOS/PC etc. is free to download and use</li> <li>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</li> </ul> <p>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.</p> <p>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 utilize the advanced features.</p> <p>Anyone is able to build anything they like on top of MeshCore without paying anything.</p>"},{"location":"faq/#12-q-what-do-you-need-to-start-using-meshcore","title":"1.2. Q: What do you need to start using MeshCore?","text":"<p>A: Everything you need for MeshCore is available at:</p> <ul> <li>Main Website: https://meshcore.io</li> <li>Firmware Flasher: https://flasher.meshcore.io</li> <li>MeshCore Firmware on GitHub: https://github.com/meshcore-dev/MeshCore</li> <li>MeshCore Companion Web App: https://app.meshcore.nz</li> <li>MeshCore Map: https://map.meshcore.io</li> <li>Liam Cottle's MeshCore Technical Presentation</li> </ul> <p>You need LoRa hardware devices to run MeshCore firmware as clients or server (repeater and room server).</p>"},{"location":"faq/#121-hardware","title":"1.2.1. Hardware","text":"<p>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.</p> <p>For an up-to-date list of supported devices, please go to https://flasher.meshcore.io</p> <p>To use MeshCore without using a phone as the client interface, you can run MeshCore on a LilyGo T-Deck, T-Deck Plus, T-Pager, T-Watch, or T-Display Pro. MeshCore Ultra firmware running on these devices is a complete off-grid secure communication solution.</p>"},{"location":"faq/#122-firmware","title":"1.2.2. Firmware","text":"<p>MeshCore firmware is organized by role and, for companions, by host transport. The main roles are Companion, Repeater, Room Server, and Sensor. The tree also contains specialized terminal-chat and KISS-modem builds. Availability depends on the board; use the flasher or that board's PlatformIO environments as the current source of truth.</p>"},{"location":"faq/#123-companion-radio-firmware","title":"1.2.3. Companion Radio Firmware","text":"<p>Companion radios connect MeshCore client software to LoRa. Depending on the board and build profile, the companion protocol can be exposed over BLE, USB serial, Wi-Fi, or Ethernet. Some boards also provide a Full Companion profile with additional local administration features. Check the exact build name and transport before flashing. Pending messages are held in a volatile shared queue; capacity depends on the platform and memory profile. See the Companion offline message queue for the exact defaults and limitations. See https://meshcore.io and the web client at https://app.meshcore.nz.</p>"},{"location":"faq/#124-repeater","title":"1.2.4. Repeater","text":"<p>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.</p> <p>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.</p>"},{"location":"faq/#125-room-server","title":"1.2.5. Room Server","text":"<p>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.</p> <p>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.</p> <p>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.</p> <p>When a client logs into a room server, the client will receive the previously 32 unseen messages.</p> <p>Although room server can also repeat with the command line command <code>set repeat on</code>, it is not recommended nor encouraged. A room server with repeat set to <code>on</code> lacks the full set of repeater and remote administration features that are only available in the repeater firmware.</p> <p>The recommendation is to run repeater and room server on separate devices for the best experience.</p>"},{"location":"faq/#2-initial-setup","title":"2. Initial Setup","text":""},{"location":"faq/#21-q-how-many-devices-do-i-need-to-start-using-meshcore","title":"2.1. Q: How many devices do I need to start using MeshCore?","text":"<p>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.</p> <p>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 nearby friends and family.</p> <p>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.</p> <p>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:</p> <p><code>set freq {frequency}</code></p> <p>The repeater and room server CLI reference is here: https://docs.meshcore.io/cli_commands</p> <p>If you have more supported devices, you can use your additional devices with the room server firmware.</p>"},{"location":"faq/#22-q-does-meshcore-cost-any-money","title":"2.2. Q: Does MeshCore cost any money?","text":"<p>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.</p> <p>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.</p> <p>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.</p>"},{"location":"faq/#23-q-what-frequencies-are-supported-by-meshcore","title":"2.3. Q: What frequencies are supported by MeshCore?","text":"<p>A: Supported frequencies depend on the radio hardware and the rules for the country in which it operates. Common MeshCore hardware covers portions of the 433, 868, and 915 MHz ISM bands.</p> <p>Use the current regional preset offered by the client or flasher, confirm it with the local MeshCore community, and comply with local frequency, bandwidth, duty-cycle, and power limits. Do not copy an old frequency from this FAQ. Narrow presets commonly use BW62.5 with a lower spreading factor; their exact frequency and SF are region-specific and can change as deployments coordinate.</p> <p>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.</p>"},{"location":"faq/#24-q-what-is-an-advert-in-meshcore","title":"2.4. Q: What is an \"advert\" in MeshCore?","text":"<p>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.</p> <p>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\".</p> <ul> <li>Zero hop means your advert is broadcast to anyone that can hear it, and that's it.</li> <li>Flooded means it's broadcast and then repeated by all the repeaters that hear it.</li> </ul> <p>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:</p> <p><code>set flood.advert.interval {hours}</code></p> <p>The separate <code>set advert.interval {minutes}</code> command controls the local zero-hop advert timer.</p>"},{"location":"faq/#25-q-is-there-a-hop-limit","title":"2.5. Q: Is there a hop limit?","text":"<p>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.</p>"},{"location":"faq/#3-server-administration","title":"3. Server Administration","text":""},{"location":"faq/#31-q-how-do-you-configure-a-repeater-or-a-room-server","title":"3.1. Q: How do you configure a repeater or a room server?","text":"<p>A: When MeshCore is flashed onto a LoRa device 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.</p> <p>Repeater or room server can be administered with one of the options below:</p> <ul> <li>After a repeater or room server firmware is flashed onto a LoRa device, go to https://config.meshcore.io and use the web user interface to connect to the LoRa device via USB serial. From there you can set the name of the server, its frequency and other related settings, location, passwords etc.</li> </ul> <p></p> <ul> <li> <p>Connect the server device using a USB cable to a computer running Chrome on https://flasher.meshcore.io, then use the <code>console</code> feature to connect to the device</p> </li> <li> <p>Use a MeshCore smartphone client to remotely administer servers via LoRa.</p> </li> <li> <p>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:</p> </li> </ul> <p>https://buymeacoffee.com/ripplebiz/e/249834</p>"},{"location":"faq/#32-q-do-i-need-to-set-the-location-for-a-repeater","title":"3.2. Q: Do I need to set the location for a repeater?","text":"<p>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:</p> <p><code>set lat &lt;GPS Lat&gt;</code></p> <p><code>set lon &lt;GPS Lon&gt;</code></p> <p>You can get the latitude and longitude from Google Maps by right-clicking the location you are at on the map.</p>"},{"location":"faq/#33-q-what-is-the-password-to-administer-a-repeater-or-a-room-server","title":"3.3. Q: What is the password to administer a repeater or a room server?","text":"<p>A: The default admin password to a repeater and room server is <code>password</code>. Use the following command to change the admin password:</p> <p><code>password {new-password}</code></p>"},{"location":"faq/#34-q-what-is-the-password-to-join-a-room-server","title":"3.4. Q: What is the password to join a room server?","text":"<p>A: The default guest password to a room server is <code>hello</code>. Use the following command to change the guest password:</p> <p><code>set guest.password {guest-password}</code></p>"},{"location":"faq/#35-q-can-i-retrieve-a-repeaters-private-key-or-set-a-repeaters-private-key","title":"3.5. Q: Can I retrieve a repeater's private key or set a repeater's private key?","text":"<p>A: You can issue these commands to get or set a repeater's private key using a USB serial connection.</p> <p><code>get prv.key</code> to print a repeater's private key on the serial console <code>set prv.key &lt;hex&gt;</code> to set a repeater's private key on the serial console</p> <p>Reboot the repeater after <code>set prv.key &lt;hex&gt;</code> command for the new private key to take effect.</p>"},{"location":"faq/#36-q-the-first-byte-of-my-repeaters-public-key-collides-with-an-existing-repeater-on-the-mesh-how-do-i-get-a-new-private-key-with-a-matching-public-key-that-has-its-first-byte-of-my-choosing","title":"3.6. Q: The first byte of my repeater's public key collides with an existing repeater on the mesh. How do I get a new private key with a matching public key that has its first byte of my choosing?","text":"<p>A: You can generate a new private key and specify the first byte of its public key here: https://gessaman.com/mc-keygen</p> <p>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.</p> <p>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.</p>"},{"location":"faq/#37-q-my-repeater-may-be-suffering-from-deafness-due-to-high-power-interference-near-my-meshs-frequency-it-is-not-hearing-other-in-range-meshcore-radios-what-can-i-do","title":"3.7. Q: My repeater may be suffering from deafness due to high power interference near my mesh's frequency, it is not hearing other in-range MeshCore radios. What can I do?","text":"<p>A: This may be due to the SX1262 radio's auto gain control feature. You can use this command to periodically reset its AGC.</p> <p><code>set agc.reset.interval &lt;number&gt;</code></p> <p>The <code>&lt;number&gt;</code> unit is in seconds and is incremented by 4. <code>set agc.reset.interval 4</code> works well to cure deafness.</p> <p>The reset is skipped while a packet is pending, being received, or being transmitted. When safe, <code>RadioLibWrapper::resetAGC()</code> warm-sleeps the radio, returns the wrapper to idle so receive mode is re-armed, reapplies the cached RX boost setting, and starts a fresh noise-floor calibration.</p>"},{"location":"faq/#371-q-can-firmware-recover-an-external-radio-whose-busy-pin-is-stuck-high","title":"3.7.1. Q: Can firmware recover an external radio whose BUSY pin is stuck high?","text":"<p>A: Current firmware first attempts a non-destructive RX/AGC re-arm and then uses a physical radio reset when the board exposes one. A normal RadioLib reinitialization is not reported as a hard reset unless firmware can actually pulse NRST or cycle the radio's power rail.</p> <p>Most supported external-radio boards expose NRST directly. RAK3401 pulses its dedicated NRST while leaving the shared peripheral rail and SPI controller intact, and LilyGo T-Beam 1W can cycle the radio regulator. The generic Tenstar C3 target describes a user-wired radio and has no reset connection by default. For unattended recovery on that target, wire NRST to a free GPIO and override <code>P_LORA_RESET</code> with that GPIO in the build configuration.</p> <p>The SenseCAP T1000-E LR1110 path was hardware-qualified with 50 successful radio-only resets: 25 in continuous receive and 25 with RX power saving active. The saved radio tuple, TX power, RX gain, and RX power-saving configuration were restored after every reset, bidirectional LoRa status traffic still passed, and the nRF52840 uptime remained continuous.</p> <p>An integrated STM32WL radio has no independently resettable RF peripheral, so it intentionally remains on the bounded soft-recovery path. If its radio core cannot recover, resetting only the radio is electrically impossible; the MCU must be restarted.</p>"},{"location":"faq/#372-q-does-firmware-automatically-update-lr1110-transceiver-firmware","title":"3.7.2. Q: Does firmware automatically update LR1110 transceiver firmware?","text":"<p>A: No. A transceiver update erases and rewrites the LR1110 itself, so it is not performed as a side effect of installing ordinary device firmware. Use the hardware vendor's physical-access maintenance procedure and verify the exact LR1110 and bootloader versions before changing them.</p> <p>Full remediation of Semtech SEM-PSA-2026-001 requires LR1110 BL2 0x1001 as well as the applicable transceiver firmware. It is a separate two-stage maintenance procedure and is not performed automatically by MeshCore.</p>"},{"location":"faq/#373-q-how-does-firmware-handle-lr2021-lowhigh-band-changes","title":"3.7.3. Q: How does firmware handle LR2021 low/high-band changes?","text":"<p>A: Firmware first selects the board's matching RF path, retunes the radio, and then reapplies output power so the LR2021 selects the correct low- or high-frequency PA. It also uses the matching RF-switch mode when RX or TX is launched. LR2021 high-band output power is limited to 12 dBm; a lower board-specific limit still takes precedence.</p> <p>On Meshnology W12, the two external FEM supplies are mutually exclusive: GPIO4 powers the sub-GHz GC1109 path and GPIO3 powers the 2.4 GHz RFX2402E path. Both supplies are disabled before the selected one is enabled. Temporary radio settings preserve the saved TX power and safely clamp only the active band; returning to the saved settings restores its applicable power. A permanent frequency change clamps the saved TX power to the new band's limit.</p> <p>The external SX1262, SX1268, LLCC68, LR1110, and LR2021 drivers also bound the post-SetTx BUSY wait. A failed PA ramp therefore returns an error and can enter the physical-reset recovery path instead of hanging the node indefinitely.</p>"},{"location":"faq/#38-q-how-do-i-make-my-repeater-an-observer-on-the-mesh","title":"3.8. Q: How do I make my repeater an observer on the mesh?","text":"<p>A: The observer instruction is available here: https://analyzer.letsmesh.net/observer/onboard</p>"},{"location":"faq/#39-q-what-is-multibyte-support-what-do-1-byte-2-byte-3-byte-adverts-and-messages-mean","title":"3.9. Q: What is multibyte support? What do 1-byte, 2-byte, 3-byte adverts and messages mean?","text":"<p>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.</p> <p>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 any way. It does make it harder for tools to analyze paths with duplicated repeater IDs.</p> <p>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.</p>"},{"location":"faq/#391-q-what-path-hash-sizes-will-my-repeater-forward","title":"3.9.1. Q: What path hash sizes will my repeater forward?","text":"<p>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.</p>"},{"location":"faq/#392-q-what-determines-a-packets-path-hash-size","title":"3.9.2. Q: What determines a packet's path hash size?","text":"<p>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.</p>"},{"location":"faq/#393-q-how-do-i-change-my-companions-path-hash-size","title":"3.9.3. Q: How do I change my companion's path hash size?","text":"<p>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 <code>Settings (gear icon)</code>, <code>Experimental Settings</code>.</p> <p>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.</p>"},{"location":"faq/#394-q-what-does-the-cli-command-pathhashmode-do-on-a-repeater","title":"3.9.4. Q: What does the CLI command <code>path.hash.mode</code> do on a repeater?","text":"<p>This CLI command <code>path.hash.mode</code> 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.</p> <p>Usage: <code>set path.hash.mode {0|1|2}</code>:</p> <pre><code>+----------------+-----------------------+\n| path.hash.mode | Advert path hash size |\n+----------------+-----------------------+\n| 0              | 1 byte (default)      |\n+----------------+-----------------------+\n| 1              | 2 bytes               |\n+----------------+-----------------------+\n| 2              | 3 bytes               |\n+----------------+-----------------------+\n</code></pre> <p>It is safe to set your 1.14+ repeaters to mode 1 or 2.</p> <p></p>"},{"location":"faq/#395-q-why-use-2-or-3-byte-path-hash-for-adverts","title":"3.9.5. Q: Why use 2- or 3-byte path hash for adverts?","text":"<p>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 is 21 or 32 hops away.</p>"},{"location":"faq/#396-q-when-can-we-move-away-from-1-byte-path-hash-for-channel-and-direct-messages","title":"3.9.6. Q: When can we move away from 1-byte path hash for channel and direct messages?","text":"<p>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 <code>path.hash.mode</code> 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.</p>"},{"location":"faq/#4-t-deck-related","title":"4. T-Deck Related","text":""},{"location":"faq/#41-q-is-there-a-user-guide-for-t-deck-t-pager-t-watch-or-t-display-pro","title":"4.1. Q: Is there a user guide for T-Deck, T-Pager, T-Watch, or T-Display Pro?","text":"<p>A: Yes, it is available on https://buymeacoffee.com/ripplebiz/ultra-v7-7-guide-meshcore-users</p>"},{"location":"faq/#42-q-what-are-the-steps-to-get-a-t-deck-into-dfu-device-firmware-update-mode","title":"4.2. Q: What are the steps to get a T-Deck into DFU (Device Firmware Update) mode?","text":"<p>A:</p> <ol> <li>Device off</li> <li>Connect USB cable to device</li> <li>Hold down trackball (keep holding)</li> <li>Turn on device</li> <li>Hear USB connection sound</li> <li>Release trackball</li> <li>T-Deck in DFU mode now</li> <li>At this point you can begin flashing using https://flasher.meshcore.io</li> </ol>"},{"location":"faq/#43-q-why-is-my-t-deck-plus-not-getting-any-satellite-lock","title":"4.3. Q: Why is my T-Deck Plus not getting any satellite lock?","text":"<p>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.</p> <p>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 <code>GPS Info</code> screen; you should see the <code>Sentences:</code> counter increasing if the baud rate is correct.</p> <p>Source</p>"},{"location":"faq/#44-q-why-is-my-og-non-plus-t-deck-not-getting-any-satellite-lock","title":"4.4. Q: Why is my OG (non-Plus) T-Deck not getting any satellite lock?","text":"<p>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.</p>"},{"location":"faq/#45-q-what-size-of-sd-card-does-the-t-deck-support","title":"4.5. Q: What size of SD card does the T-Deck support?","text":"<p>A: Users have had no issues using 16GB or 32GB SD cards. Format the SD card to FAT32.</p>"},{"location":"faq/#46-q-what-is-the-public-key-for-the-default-public-channel","title":"4.6. Q: What is the public key for the default public channel?","text":"<p>A: T-Deck uses the same key the smartphone apps use but in base64 <code>izOH6cXN6mrJ5e26oRXNcg==</code></p> <p>There is no <code>=</code> key on the T-Deck's hardware keyboard. You can use the on-screen software keyboard to enter <code>=</code>. Tap the text box to enable the on-screen software keyboard. The third character is the capital letter <code>O</code> (Oh), not zero <code>0</code></p> <p>The smartphone app key is in hex: <code>8b3387e9c5cdea6ac9e5edbaa115cd72</code></p> <p>Source</p>"},{"location":"faq/#47-q-how-do-i-get-maps-on-t-deck","title":"4.7. Q: How do I get maps on T-Deck?","text":"<p>A: You need map tiles. You can get pre-downloaded map tiles here (a good way to support development):</p> <ul> <li>https://buymeacoffee.com/ripplebiz/e/342543 (Europe)</li> <li>https://buymeacoffee.com/ripplebiz/e/342542 (US)</li> </ul> <p>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</p> <p>There is also a modified script that adds additional error handling and parallel downloads: https://github.com/TheBestJohn/MTD-Script</p>"},{"location":"faq/#48-q-where-do-the-map-tiles-go","title":"4.8. Q: Where do the map tiles go?","text":"<p>Once you have the tiles downloaded, copy the <code>\\tiles</code> folder to the root of your T-Deck's SD card.</p>"},{"location":"faq/#49-q-how-to-unlock-deeper-map-zoom-and-server-management-features-on-t-deck","title":"4.9. Q: How to unlock deeper map zoom and server management features on T-Deck?","text":"<p>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</p>"},{"location":"faq/#410-q-how-to-decipher-the-diagnostics-screen-on-t-deck","title":"4.10. Q: How to decipher the diagnostics screen on T-Deck?","text":"<p>A: Space is tight on T-Deck's screen, so the information is a bit cryptic. The format is : <code>{hops} l:{packet-length}({payload-len}) t:{packet-type} snr:{n} rssi:{n}</code></p> <p>See here for packet-type: https://github.com/meshcore-dev/MeshCore/blob/main/src/Packet.h#L19</p> Value Payload <code>0x00</code> Request <code>0x01</code> Response <code>0x02</code> Plain text message <code>0x03</code> Acknowledgment <code>0x04</code> Node advertisement <code>0x05</code> Group text <code>0x06</code> Group datagram <code>0x07</code> Anonymous request <code>0x08</code> Returned path <code>0x09</code> Trace <code>0x0A</code> Multipart <code>0x0B</code> Control/discovery data <code>0x0C</code> OTA-over-LoRa data <code>0x0D</code>-<code>0x0E</code> Reserved <code>0x0F</code> Raw custom data <p>See Packet Format and Payload Format for the maintained descriptions.</p> <p>Source</p>"},{"location":"faq/#411-q-the-t-deck-sound-is-too-loud","title":"4.11. Q: The T-Deck sound is too loud?","text":""},{"location":"faq/#412-q-can-you-customize-the-sound","title":"4.12. Q: Can you customize the sound?","text":"<p>A: You can customize the sounds on the T-Deck, by placing <code>.mp3</code> files onto the <code>root</code> dir of the SD card. The files are:</p> <ul> <li><code>startup.mp3</code></li> <li><code>error.mp3</code></li> <li><code>alert.mp3</code></li> <li><code>new-advert.mp3</code></li> <li><code>existing-advert.mp3</code></li> </ul>"},{"location":"faq/#413-q-what-is-the-import-from-clipboard-feature-on-the-t-deck-and-is-there-a-way-to-manually-add-nodes-without-having-to-receive-adverts","title":"4.13. Q: What is the 'Import from Clipboard' feature on the t-deck and is there a way to manually add nodes without having to receive adverts?","text":"<p>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://...\")</p>"},{"location":"faq/#414-q-how-to-capture-a-screenshot-on-t-deck","title":"4.14. Q: How to capture a screenshot on T-Deck?","text":"<p>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.</p>"},{"location":"faq/#5-general","title":"5. General","text":""},{"location":"faq/#51-q-what-are-bw-sf-and-cr","title":"5.1. Q: What are BW, SF, and CR?","text":"<p>A:</p> <p>BW is bandwidth - width of frequency spectrum that is used for transmission</p> <p>SF is spreading factor - how much should the communication spread in time</p> <p>CR is coding rate - from: https://www.thethingsnetwork.org/docs/lorawan/fec-and-code-rate</p> <p>TL;DR: default CR to 5 for good stable links. If it is not a solid link and is intermittent, change CR to 7 or 8.</p> <p>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.</p> <p>The Code Rate of a forward error correction expresses the proportion of bits in a data stream that actually carry useful information.</p> <p>There are 4 code rates used in LoRaWAN:</p> <p>4/5 4/6 5/7 4/8</p> <p>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.</p> <p>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.</p> <p>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 talking in a noisy place (a bar for example). If you're far from each other, you have to talk slow (SF10), but if you're close, you can talk faster (SF7)</p> <p>So, it's a balancing act between speed of the transmission and resistance to noise. The Things Network is mainly focused on LoRaWAN, but the LoRa low-level stuff still checks out for any LoRa project</p>"},{"location":"faq/#52-q-do-meshcore-clients-repeat","title":"5.2. Q: Do MeshCore clients repeat?","text":"<p>A: Companion clients do not repeat by default. Supported builds can opt into bounded client repeating on permitted frequencies, and the emergency-channel path has a bounded delayed relay behavior. Dedicated repeaters remain the normal and recommended way to extend network coverage. Room servers can repeat when explicitly configured, but separating the roles is generally preferable.</p>"},{"location":"faq/#53-q-what-happens-when-a-node-learns-a-route-via-a-mobile-repeater-and-that-repeater-is-gone","title":"5.3. Q: What happens when a node learns a route via a mobile repeater, and that repeater is gone?","text":"<p>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.</p> <p>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.</p>"},{"location":"faq/#54-q-how-does-a-node-discover-a-path-to-its-destination-and-then-use-it-to-send-messages-in-the-future-instead-of-flooding-every-message-it-sends-like-meshtastic","title":"5.4. Q: How does a node discover a path to its destination and then use it to send messages in the future, instead of flooding every message it sends like Meshtastic?","text":"<p>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.</p> <p>Source</p>"},{"location":"faq/#55-q-do-public-channels-always-flood-do-private-channels-always-flood","title":"5.5. Q: Do public channels always flood? Do private channels always flood?","text":"<p>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 <code>set flood.max</code> CLI command. Administrators of repeaters get to set the rules of their repeaters.</p> <p>Source</p>"},{"location":"faq/#56-q-what-is-the-public-key-for-the-default-public-channel","title":"5.6. Q: What is the public key for the default public channel?","text":"<p>A: The smartphone app key is in hex:</p> <p><code>8b3387e9c5cdea6ac9e5edbaa115cd72</code></p> <p>T-Deck uses the same key but in base64:</p> <p><code>izOH6cXN6mrJ5e26oRXNcg==</code></p> <p>The third character is the capital letter <code>O</code>, not zero <code>0</code>.</p> <p>Source</p>"},{"location":"faq/#57-q-is-meshcore-open-source","title":"5.7. Q: Is MeshCore open source?","text":"<p>A: Most of the firmware is freely available. Everything is open source except the T-Deck firmware and Liam's native mobile apps.</p> <p>Firmware repo: https://github.com/meshcore-dev/MeshCore</p>"},{"location":"faq/#58-q-how-can-i-support-meshcore","title":"5.8. Q: How can I support MeshCore?","text":"<p>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.</p> <p>Support Liam Cottle's smartphone client development by unlocking the server administration wait gate with in-app purchase</p> <p>Support Rastislav Vysoky (recrof)'s flasher website and the map website development through PayPal or Revolut</p>"},{"location":"faq/#59-q-how-do-i-build-meshcore-firmware-from-source","title":"5.9. Q: How do I build MeshCore firmware from source?","text":"<p>A: See instructions here: https://discord.com/channels/826570251612323860/1330643963501351004/1341826372120608769</p> <p>Build instructions for MeshCore:</p> <p>For Windows, first install WSL and Python+pip via: https://plainenglish.io/python/setting-up-python-on-windows-subsystem-for-linux-wsl-26510f1b2d80</p> <p>(Linux, Windows+WSL) In the terminal/shell:</p> <pre><code>sudo apt update\nsudo apt install libpython3-dev\nsudo apt install python3-venv\n</code></pre> <p>Mac: python3 should be already installed.</p> <p>Then it should be the same for all platforms:</p> <pre><code>python3 -m venv meshcore\ncd meshcore &amp;&amp; source bin/activate\npip install -U platformio\ngit clone https://github.com/meshcore-dev/MeshCore.git\ncd MeshCore\n</code></pre> <p>Choose an exact environment listed by <code>pio project config</code> or in the target board's <code>variants/*/platformio.ini</code>. For example:</p> <pre><code>pio run -e RAK_4631_repeater\n</code></pre> <p>The output is under <code>.pio/build/RAK_4631_repeater/</code>. Set the radio parameters to your current regional preset after flashing; if changing build defaults, keep that local change out of commits unless it is intended for every user.</p>"},{"location":"faq/#510-q-are-there-other-meshcore-related-open-source-projects","title":"5.10. Q: Are there other MeshCore related open source projects?","text":"<p>A: Liam Cottle's MeshCore web client and MeshCore JavaScript library are open source under MIT license.</p> <p>Web client: https://github.com/liamcottle/meshcore-web JavaScript: https://github.com/meshcore-dev/meshcore.js</p>"},{"location":"faq/#511-q-does-meshcore-support-atak","title":"5.11. Q: Does MeshCore support ATAK?","text":"<p>A: This repository does not ship or document an official ATAK integration. An external integration must account for LoRa airtime, moving endpoints, stale direct paths, and the collision cost of frequent flood fallback. Optional, bounded Companion repeating does not turn every mobile client into a dedicated repeater and does not remove those capacity constraints. Check current community projects before designing a deployment.</p> <p>Source</p>"},{"location":"faq/#512-q-how-do-i-add-a-node-to-the-meshcore-map","title":"5.12. Q: How do I add a node to the MeshCore Map?","text":"<p>A:</p> <p>To add a BLE Companion radio, connect to the BLE Companion radio from the MeshCore smartphone app. In the app, tap the <code>3 dot</code> menu icon at the top right corner, then tap <code>Internet Map</code>. Tap the <code>3 dot</code> menu icon again and choose <code>Add me to the Map</code></p> <p>To add a Repeater or Room Server to the map, go to the Contact List, tap the <code>3 dot</code> next to the Repeater or Room Server you want to add to the Internet Map, tap <code>Share</code>, then tap <code>Upload to Internet Map</code>.</p> <p>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.</p>"},{"location":"faq/#513-q-can-i-use-a-raspberry-pi-to-update-a-meshcore-radio","title":"5.13. Q: Can I use a Raspberry Pi to update a MeshCore radio?","text":"<p>A: Yes. Below are the instructions to flash firmware onto a supported LoRa device using a Raspberry Pi over USB serial.</p> <p>Instructions for nRF devices like RAK, T1000-E, T114 are immediately after the ESP instructions</p> <p>For ESP-based devices (e.g. Heltec V3) you need:</p> <ol> <li>Download the firmware file from https://flasher.meshcore.io.<ul> <li>Select the exact board and role. Artifact names and release URLs include a   changing version and commit, so copy the current download URL instead of   using an example URL from a guide.</li> <li>A non-merged application image is for an already compatible bootloader   and partition table. A merged image also contains low-level flash data.   Back up settings before either operation; do not assume a merged flash   preserves configuration, pairing data, or a previous partition layout.</li> <li>To download a copied URL from the shell, use   <code>curl -L '&lt;copied-url&gt;' -o &lt;firmware&gt;.bin</code>.</li> </ul> </li> <li>Confirm the <code>ttyXXXX</code> device path on your Raspberry Pi.<ul> <li>Run <code>ls /dev/ttyACM* /dev/ttyUSB* 2&gt;/dev/null</code> before and after connecting   the board. ESP devices can appear under either name.</li> </ul> </li> <li>Install esptool in a virtual environment.<ul> <li><code>python3 -m venv .venv &amp;&amp; . .venv/bin/activate</code></li> <li><code>python -m pip install --upgrade esptool</code></li> </ul> </li> <li>Flash the firmware.<ul> <li>For non-merged bin:<ul> <li><code>python -m esptool --port /dev/ttyUSB0 --chip auto write-flash 0x10000 &lt;non-merged-firmware&gt;.bin</code></li> </ul> </li> <li>For merged bin:<ul> <li><code>python -m esptool --port /dev/ttyUSB0 --chip auto write-flash 0x00000 &lt;merged-firmware&gt;.bin</code></li> </ul> </li> </ul> </li> </ol> <p>Instructions for nRF devices:</p> <p>For nRF devices (e.g. RAK, Heltec T114) you need the following:</p> <ol> <li>Download the firmware file from https://flasher.meshcore.io.<ul> <li>Select the exact board and role, and download its current ZIP package.   Do not rename a package from another board or reuse a static versioned URL.</li> </ul> </li> <li>Confirm the <code>ttyXXXX</code> device path on your Raspberry Pi.<ul> <li>Run <code>ls /dev/ttyACM* /dev/ttyUSB* 2&gt;/dev/null</code>; nRF bootloaders commonly   appear as <code>/dev/ttyACM0</code>, but the number can change.</li> </ul> </li> <li>In a virtual environment, install adafruit-nrfutil:<ul> <li><code>python3 -m venv .venv &amp;&amp; . .venv/bin/activate</code></li> <li><code>python -m pip install --upgrade adafruit-nrfutil</code></li> </ul> </li> <li>Flash the nRF device.<ul> <li><code>adafruit-nrfutil --verbose dfu serial --package &lt;firmware-package&gt;.zip -p /dev/ttyACM0 -b 115200 --singlebank --touch 1200</code></li> </ul> </li> </ol> <p>To manage a repeater or room server connected to a Pi over USB serial using shell commands, you need to install <code>picocom</code>. To install <code>picocom</code>, run the following command:</p> <ul> <li><code>sudo apt install picocom</code></li> </ul> <p>To start managing your USB serial-connected device using picocom, use the following command:</p> <ul> <li><code>picocom -b 115200 /dev/ttyUSB0 --imap lfcrlf</code></li> </ul> <p>From here, reference repeater and room server command line commands in the MeshCore docs here:</p> <ul> <li>https://docs.meshcore.io/cli_commands</li> </ul>"},{"location":"faq/#514-q-are-there-projects-built-around-meshcore","title":"5.14. Q: Are there projects built around MeshCore?","text":"<p>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 Assistant.</p> <p>As new MeshCore community projects become available on a weekly basis, we have stopped tracking them here in this FAQ. samuk maintains a very exhaustive list of MeshCore community project at https://github.com/samuk/awesome-meshcore/blob/main/README.md. samuk accepts PRs and merges them regularly.</p>"},{"location":"faq/#515-q-are-there-client-applications-for-windows-or-mac","title":"5.15. Q: Are there client applications for Windows or Mac?","text":"<p>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</p> <p>Both the Windows and Mac versions of the client app are fully unlocked and are free to use.</p>"},{"location":"faq/#516-q-are-there-any-resources-that-compare-meshcore-to-other-lora-systems","title":"5.16. Q: Are there any resources that compare MeshCore to other LoRa systems?","text":"<p>A: Here is a list of MeshCore comparison resources:</p> <ul> <li>The Comms Channel on YouTube: https://www.youtube.com/watch?v=guDoKGs02Us</li> <li>MeshCore Advantages by MCarper: https://github.com/mikecarper/meshfirmware/blob/main/MeshCoreAdvantages.md</li> <li>MeshCore vs Meshtastic by austinmesh.org: https://www.austinmesh.org/about/meshcore-vs-meshtastic/</li> </ul>"},{"location":"faq/#6-troubleshooting","title":"6. Troubleshooting","text":""},{"location":"faq/#61-q-my-client-says-another-client-or-a-repeater-or-a-room-server-was-last-seen-many-many-days-ago","title":"6.1. Q: My client says another client or a repeater or a room server was last seen many, many days ago.","text":""},{"location":"faq/#62-q-a-repeater-or-a-client-or-a-room-server-i-expect-to-see-on-my-discover-list-on-t-deck-or-contact-list-on-a-smart-device-client-are-not-listed","title":"6.2. Q: A repeater or a client or a room server I expect to see on my discover list (on T-Deck) or contact list (on a smart device client) are not listed.","text":"<p>A:</p> <ul> <li>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).</li> <li>If you are using the Android or iOS client, the other client, repeater, or room server may have the wrong time.</li> </ul> <p>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 <code>time</code> command in the USB serial console with the server device connected.</p>"},{"location":"faq/#63-q-how-to-connect-to-a-repeater-via-ble-bluetooth","title":"6.3. Q: How to connect to a repeater via BLE (Bluetooth)?","text":"<p>A: You can't connect to a device running repeater firmware via Bluetooth. You can connect to devices running the BLE companion firmware via Bluetooth using the Android app.</p>"},{"location":"faq/#64-q-my-companion-isnt-showing-up-over-bluetooth","title":"6.4. Q: My companion isn't showing up over Bluetooth?","text":"<p>A: Make sure that you flashed the Bluetooth companion firmware and not the USB-only companion firmware.</p>"},{"location":"faq/#65-q-i-cant-connect-via-bluetooth-what-is-the-bluetooth-pairing-code","title":"6.5. Q: I can't connect via Bluetooth, what is the Bluetooth pairing code?","text":"<p>A: The default Bluetooth pairing code is <code>123456</code> on builds without a physical display. Display-equipped Companion builds generate a six-digit PIN at boot and show it when a client requests pairing. The display stays awake on the PIN page until Bluetooth connects or the two-minute pairing window expires.</p>"},{"location":"faq/#66-q-my-heltec-v3-keeps-disconnecting-from-my-smartphone-it-cant-hold-a-solid-bluetooth-connection","title":"6.6. Q: My Heltec V3 keeps disconnecting from my smartphone. It can't hold a solid Bluetooth connection.","text":"<p>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.</p>"},{"location":"faq/#67-q-my-rakt1000-exiao_nrf52-device-seems-to-be-corrupted-how-do-i-wipe-it-clean-to-start-fresh","title":"6.7. Q: My RAK/T1000-E/xiao_nRF52/... device seems to be corrupted, how do I wipe it clean to start fresh?","text":"<p>A: If you're able to connect to the device from your MeshCore app 1. Navigate to Gear icon(Settings) on the upper right corner 2. Click on <code>Export Settings</code> button, choose <code>Select All</code> and Confirm. This will save your Node configuration 3. Now choose <code>Factory Reset</code> option 4. Confirm that you want to reset your device 5. Go to Bluetooth System settings and remove pairing of the device, so you can connect again 6. Connect your device in the app and enter the PIN 7. Navigate to Gear icon(Settings) on the upper right corner 8. Click on <code>Import Settings</code> and choose the file from 2., click on <code>Select All</code> and Confirm 9. Find <code>Reboot</code> button on of the Settings list</p> <p>B: You're not able to connect to the App 1. Connect USB cable to your device 2. Go to https://flasher.meshcore.io 3. Search for your device in the list 4. Choose <code>Companion Bluetooth</code> 5. Press <code>Enter DFU mode</code> button, choose your USB device 6. Press <code>Erase Flash</code> button, choose the device again and wait until it completes 7. Press <code>Flash!</code> button and choose the USB device last time 8. The device is erased and newest firmware is installed 9. You might need to remove the pairing in Bluetooth System Settings in order to re-pair the app again.</p> <p>An erase application or ordinary application ZIP/UF2 does not repair a damaged or partially overwritten SoftDevice. This can happen after flashing an nRF52 image for a different board or SoftDevice layout. A characteristic failure is that the application can boot and read its filesystem, but reboots or hangs when it writes or formats internal flash. Repeating <code>Erase Flash</code> is not a recovery for that condition.</p> <p>Recover it with a combined bootloader + SoftDevice package for the exact board (including XIAO Sense versus non-Sense), installed through serial/BLE DFU or SWD. With <code>adafruit-nrfutil</code>, the serial form is:</p> <pre><code>adafruit-nrfutil dfu serial -p &lt;port&gt; \\\n  -pkg &lt;exact-board-bootloader-with-softdevice&gt;.zip -sb -t 1200\n</code></pre> <p>Then install the exact-board MeshCore application. Do not use an application- only UF2, filesystem formatter, or a similarly named package from another nRF52 board as a substitute. See the confirmed XIAO recovery in issue #3284 and obtain the matching package from the OTAFIX releases.</p> <p>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 holding down the user button of the device within 8 seconds of boot. Then you can use the 'Console' on https://flasher.meshcore.io</p>"},{"location":"faq/#68-q-webflasher-fails-on-linux-with-failed-to-open","title":"6.8. Q: WebFlasher fails on Linux with failed to open","text":"<p>A: If the usb port doesn't have the right ownership for this task, the process fails with the following error:</p> <p><code>NetworkError: Failed to execute 'open' on 'SerialPort': Failed to open serial port.</code></p> <p>Allow user access on your USB port:</p> <p><code>sudo setfacl -m u:$USER:rw /dev/ttyUSB0</code></p>"},{"location":"faq/#7-other-questions","title":"7. Other Questions:","text":""},{"location":"faq/#71-q-how-to-update-nrf-rak-t114-seeed-xiao-companion-repeater-and-room-server-firmware-over-the-air-using-the-new-simpler-dfu-app","title":"7.1. Q: How to update nRF (RAK, T114, Seeed XIAO) companion, repeater and room server firmware over the air using the new simpler DFU app?","text":"<p>A: The steps below work on both Android and iOS as nRF has made both apps' user interface the same on both platforms:</p> <ol> <li>Download nRF's DFU app from iOS App Store or Android's Play Store, you can find the app by searching for <code>nrf dfu</code>, the app's full name is <code>nRF Device Firmware Update</code></li> <li>On https://flasher.meshcore.io, download the ZIP version of the firmware for your nRF device (e.g. RAK or Heltec T114 or Seeed Studio's Xiao)</li> <li>From the MeshCore app, log in remotely to the repeater you want to update with admin privileges</li> <li>Go to the Command Line tab, type <code>start ota</code> and hit enter.</li> <li>You should see <code>OK</code> to confirm the repeater device is now in OTA mode</li> <li>Run the DFU app, then tap <code>Settings</code> in the top-right corner</li> <li>Enable <code>Packet receipt notifications</code>, and change <code>Number of Packets</code> to 10 for RAK, 8 for T114. 8 also works for RAK.</li> <li>Select the firmware zip file you downloaded</li> <li>Select the device you want to update. If the device you want to update is not on the list, try enabling <code>OTA</code> on the device again</li> <li>If the device is not found, enable <code>Force Scanning</code> in the DFU app</li> <li>Tap <code>Upload</code> to begin OTA update</li> <li>If it fails, try toggling Bluetooth on your phone. If that doesn't work, try rebooting your phone. If you keep getting failures at the \"Enabling Bootloader\" step, try forgetting the nRF board in your iOS or Android device's Bluetooth settings and re-pair it through the DFU app.</li> <li>Wait for the update to complete. It can take a few minutes.</li> <li>It is strongly recommended that you install and use the OTAFIX bootloader at https://github.com/oltaco/Adafruit_nRF52_Bootloader_OTAFIX.</li> <li>A companion must be running a build that exposes <code>start ota</code>; consult the     current flasher release notes rather than relying on a version threshold in     this FAQ.</li> <li>Please see the MeshCore Blog for additional information on OTA firmware flashing:<ul> <li>https://blog.meshcore.io/2026/04/06/otafix-bootloader</li> <li>https://blog.meshcore.io/2026/04/02/nrf-ota-update</li> </ul> </li> </ol>"},{"location":"faq/#711-q-can-i-update-seeed-studio-wio-tracker-l1-pro-using-ota","title":"7.1.1 Q: Can I update Seeed Studio Wio Tracker L1 Pro using OTA?","text":"<p>A:  You can flash this safer bootloader to the Wio Tracker L1 Pro https://github.com/oltaco/Adafruit_nRF52_Bootloader_OTAFIX</p> <p>After this bootloader is flashed onto the device, you can trigger an over-the-air update using Bluetooth by holding the button next to the D-Pad and then clicking the reset button. Then follow the same OTA update instructions above. You can skip the <code>start ota</code> instruction and start the update using the DFU app.</p>"},{"location":"faq/#72-q-how-to-update-esp32-based-devices-over-the-air","title":"7.2. Q: How to update ESP32-based devices over the air?","text":"<p>A: For ESP32-based devices (e.g. Heltec V3):</p> <ol> <li>On https://flasher.meshcore.io, download the current non-merged    application image for the exact ESP32 board and role (no <code>merged</code> in the    filename).</li> <li>From the MeshCore app, log in remotely to the repeater you want to update with admin privileges.</li> <li>Go to the Command Line tab, type <code>start ota</code> and hit enter.</li> <li>You should see <code>OK</code> to confirm the repeater device is now in OTA mode.</li> <li>If the ESP32 is not already joined to Wi-Fi, <code>start ota</code> starts an open hotspot named <code>MeshCore-OTA</code> at <code>192.168.4.1</code>. If it is already joined, the command reports and uses its router-assigned address instead.</li> <li>From your phone or computer, connect to the <code>MeshCore-OTA</code> hotspot when one was started.</li> <li>Open the URL reported by <code>start ota</code> and upload the non-merged bin from the flasher. When the device started <code>MeshCore-OTA</code>, the URL is http://192.168.4.1/update.</li> </ol> <p>On an MQTT observer, stop WebConfig before running <code>start ota</code>; both servers use HTTP port 80. Likewise, stop the OTA uploader before running <code>start webconfig</code>.</p>"},{"location":"faq/#73-q-is-there-a-way-to-lower-the-chance-of-a-failed-ota-device-firmware-update-dfu","title":"7.3. Q: Is there a way to lower the chance of a failed OTA device firmware update (DFU)?","text":"<p>A: Yes, developer <code>che aporeps</code> 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.</p> <p>Refer to https://github.com/oltaco/Adafruit_nRF52_Bootloader_OTAFIX for the latest information.</p> <p>Currently, the following boards are supported:</p> <ul> <li>Elecrow ThinkNode M1, M3, and M6</li> <li>Heltec Automation Mesh Node T114 / HT-nRF5262</li> <li>LilyGO T-Echo</li> <li>Minewsemi MX25LE01</li> <li>Nologo ProMicro NRF52840 (aka SuperMini NRF52840)</li> <li>RAK4631</li> <li>RAK WisMesh Tag</li> <li>Seeed Studio SenseCAP Card Tracker T1000-E</li> <li>Seeed Studio SenseCAP Solar Node P1</li> <li>Seeed Studio Wio Tracker L1</li> <li>Seeed Studio XIAO nRF52840 BLE</li> <li>Seeed Studio XIAO nRF52840 BLE SENSE</li> </ul>"},{"location":"faq/#74-q-are-the-meshcore-logo-and-font-available","title":"7.4. Q: Are the MeshCore logo and font available?","text":"<p>A: Yes, it is on the MeshCore GitHub repo here: https://github.com/meshcore-dev/MeshCore/tree/main/logo</p>"},{"location":"faq/#75-q-what-is-the-format-of-a-contact-or-channel-qr-code","title":"7.5. Q: What is the format of a contact or channel QR code?","text":"<p>A:</p> <p>Channel: <code>meshcore://channel/add?name=&lt;name&gt;&amp;secret=&lt;secret&gt;</code></p> <p>Contact: <code>meshcore://contact/add?name=&lt;name&gt;&amp;public_key=&lt;secret&gt;&amp;type=&lt;type&gt;</code></p> <p>Where <code>&amp;type</code> is:</p> <ul> <li><code>chat = 1</code></li> <li><code>repeater = 2</code></li> <li><code>room = 3</code></li> <li><code>sensor = 4</code></li> </ul>"},{"location":"faq/#76-q-how-do-i-connect-to-the-companion-via-wi-fi-eg-using-a-heltec-v3","title":"7.6. Q: How do I connect to the companion via Wi-Fi, e.g. using a Heltec V3?","text":"<p>A: Flash an ESP32 companion Wi-Fi build. Its shared WebUI is enabled by default. If it has no saved Wi-Fi configuration, it starts an open <code>MeshCore-Setup-XXXX</code> access point. Join it and browse to http://192.168.4.1/. The wizard configures WiFi, node identity, and radio settings; MQTT companion builds add an MQTT step and MQTT tab, while non-MQTT companions remove those controls. After saving, the page and device screen show the station IP assigned by your router.</p> <p>If a saved network remains unreachable for two minutes, the setup AP starts as a fallback. If the original network returns, the companion closes that recovery portal and resumes normal LAN operation.</p> <p>The setup AP always uses <code>192.168.4.1</code>; the companion's station IP is assigned by DHCP and can be different. A real <code>WIFI_SSID</code> and <code>WIFI_PWD</code> can still be supplied at compile time as initial defaults, but they are no longer required.</p> <p>On the LAN, the WebUI remains available at the companion's station IP and the companion protocol remains available on TCP port <code>5000</code>. Companion builds do not have an admin CLI password, so this configuration page trusts the local LAN; do not put the companion on an untrusted WiFi network.</p> <p>ESP32 repeater and room-server builds use the same page, but keep it off by default. Run <code>set webui on</code> from the admin CLI, open the reported LAN URL, and sign in with the admin password; <code>get webui</code> reports its current address. Their MQTT observer variants expose the MQTT controls, while ordinary builds do not. The two 4 MB <code>LilyGo_TLora_V2_1_1_6_*_observer_mqtt</code> builds retain CLI-only configuration so their flash can keep two app slots for LoRa OTA.</p>"},{"location":"faq/#77-q-i-have-a-station-g2-or-a-heltec-v4-or-an-ikoka-stick-or-a-radio-with-an-ebyte-e22-900m30s-or-an-ebyte-e22-900m33s-module-what-should-their-transmit-power-be-set-to","title":"7.7. Q: I have a Station G2, or a Heltec V4, or an Ikoka Stick, or a radio with an EByte E22-900M30S or an EByte E22-900M33S module, what should their transmit power be set to?","text":"<p>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 <code>set tx</code>. You can get their current value using command line command <code>get tx</code></p> <p>[WARN] WARNING: Set these values at your own risk. Incorrect power settings can permanently damage your radio hardware.</p> Device / Model Region / Description In-App Setting (dBm) Target Radio Output Notes Station G2 Reference US915 Max Output 19 dBm 36.5 dBm (4.46W) US915 Max at 1dB compression point 16 dBm 35 dBm (3.16W) 1dB compression point EU868  Max at 1dB compression point 15 dBm 34.5 dBm (2.82W) 1dB compression point US915 1W Output 10 dBm 1W Refer to your local government's requirements EU868 1W Output 9 dBm 1W Refer to your local government's requirements Ikoka Stick E22-900M30S 1W Model 19 dBm 1W DO NOT EXCEED (Risk of burn out) data sheet Ikoka Stick E22-900M33S 2W Model 9 dBm 2W DO NOT EXCEED (Risk of burn out) data sheet Refer to your local government's requirements Heltec V4 Standard Output 10 dBm 22 dBm (~0.15W) High Output 22 dBm 28 dBm (~0.5W to 0.6W)"},{"location":"faq/#78-q-how-do-i-use-ethernet-with-a-rak4631","title":"7.8. Q: How do I use Ethernet with a RAK4631?","text":"<p>A: MeshCore supports Ethernet on RAK4631 boards using the RAK13800 WisBlock Ethernet module (based on the W5100S chip).</p> <p>Hardware required: - RAK4631 WisBlock Core - RAK19007 or RAK19018 WisBlock Base Board (with an available IO slot) - RAK13800 WisBlock Ethernet module - Ethernet cable connected to a network with a DHCP server</p> <p>Firmware: Flash one of the Ethernet-enabled firmware variants: - <code>RAK_4631_repeater_ethernet</code> - Repeater with Ethernet CLI access - <code>RAK_4631_room_server_ethernet</code> - Room server with Ethernet CLI access - <code>RAK_4631_companion_radio_ethernet</code> - Companion radio over Ethernet (replaces BLE)</p> <p>Connecting: - The device obtains an IP address via DHCP automatically on boot. - For repeaters and room servers, connect to the device on TCP port 23 using any TCP client (e.g. <code>nc &lt;ip&gt; 23</code> or PuTTY in raw mode). This gives you the same CLI available over serial/USB. - For companion radio firmware, the Ethernet interface replaces BLE as the transport to companion apps. Connect on TCP port 5000 (same as the WiFi companion radio). - Use the <code>eth.status</code> CLI command to check connection status and see the assigned IP address.</p>"},{"location":"filter_tool/","title":"Filter policy playground","text":"<p>Build a forwarding policy, see its readable definition, and simulate how a repeater handles a packet. Rules match received packet facts, then apply actions such as dropping, scoping, rate-limiting, or retrying a flood.</p> <p>Everything runs locally in this browser. Channel keys, packet facts, and policy drafts are not uploaded anywhere.</p> Policy design preview <p>     The phases and core conditions model current FPF7 behavior, including its     forward rows, scope rewrites, and shared blacklist. The readable policy     language, JSON, and Base64 bundle are still a prototype: current firmware     is configured with <code>set flood.*</code> commands and cannot install a     bundle from this page.   </p>"},{"location":"filter_tool/#build-a-policy","title":"Build a policy","text":"<p>Start with an example or build a rule, then test the draft against packet facts in the simulator below. The examples draw from Flood Filtering and Moderation.</p> Remote login and direct routes <p>       This policy only decides whether a relay retransmits a flood. Direct       packets and local delivery are unaffected. Rules matching the login/admin       family can still reduce multi-hop remote-login reach, so the analyzer       flags them.     </p> Example policies Choose one to load its full rules into the builder and draft. <p>         Read each summary as <code>when</code> all conditions match,         <code>do</code> the actions. A match alone does not stop forwarding.       </p> Payload selectors <code>type=</code> valueMatches <code>grp_data</code>Only the named payload type; see every exact type below <code>any</code>Every payload type <code>class:group</code>GRP_TXT and GRP_DATA <code>class:login</code>REQ, RESPONSE, TXT_MSG, ANON_REQ, and PATH <code>class:other</code>Every remaining payload type that is not group or login Other conditions and actions FieldMeaning <code>hops=</code>Received hop count: <code>all</code>, <code>3+</code>, <code>2-6</code>, or <code>3</code> <code>channel=</code><code>*</code> means no channel condition; a name or key authenticates one group channel; <code>hash:XX</code> is an unauthenticated one-byte fallback <code>rx.scope=</code>Original incoming transport scope <code>path=</code>Path prefix, blacklist, bucket, or loop match <code>tempradio=</code>Temporary-radio state <code>do drop</code>Do not retransmit <code>do scope=</code>Set the outgoing transport scope <code>do rate=</code>Apply a per-minute rate and burst <code>do timing=</code>Select fast, normal, or slow scheduling <p>         There is no <code>class:txt</code>. Use <code>type=grp_txt</code> for         channel text or <code>type=txt_msg</code> for peer text.       </p> Set #BlackHole86 scope on all #rgdata group traffic <code>when type=class:group hops=all channel=#rgdata do scope=#BlackHole86 timing=fast</code> Add #BlackHole86 scope to unscoped #rgdata data <code>when type=grp_data hops=all channel=#rgdata rx.scope=none do scope=#BlackHole86 timing=fast</code> Replace #usa with #BlackHole86 on #rgdata data <code>when type=grp_data hops=all channel=#rgdata rx.scope=scope:usa do scope=#BlackHole86 timing=fast</code> Rate-limit packets whose path starts with 860C <code>when type=any hops=all path=prefix:860C do rate=10/min burst=10</code> Drop selected flood types at their hop limits <code>when type=control hops=1+ do dropwhen type=req hops=3+ do drop; same for type=grp_datawhen type=response hops=9+ do drop; same for type=anon_req and type=path</code> Rate-limit Public messages from \u201cNoisy User\u201d <code>when type=grp_txt hops=all channel=public sender=\"Noisy User\" do rate=5/min burst=5</code> Stop forwarding traffic from blacklisted internet gateways <code>when type=any hops=all path=blacklist do drop</code> Drop OTA outside temporary-radio mode and distant #wardriving <code>when type=ota hops=all tempradio=inactive do dropwhen type=any channel=#wardriving hops=5+ do drop</code> Set #BlackHole86 scope on login and bucket-matched other traffic <code>when type=class:login hops=all do scope=#BlackHole86 timing=fastwhen type=class:other hops=all path=bucket:2 do scope=#BlackHole86 timing=slow</code> <p>Rule builder</p> Reset form Common match settings            Payload type or class            Any payload type Class: group text and data Class: login/admin family Class: every other payload REQ RESPONSE TXT_MSG ACK ADVERT GRP_TXT GRP_DATA ANON_REQ PATH TRACE MULTIPART CONTROL OTA Reserved type 13 Reserved type 14 RAW_CUSTOM            Received hops                       Channel (optional)                       Original incoming scope                       Path matcher            No path condition Ordered 1/2/3-byte pbyte prefix Passive blacklist Path bucket 1 Path bucket 2 Path bucket 3 Path bucket 4 Path bucket 5 Path bucket 6 Own-ID loop: strict Own-ID loop: moderate Own-ID loop: minimal            Ordered pbyte prefix                       Decrypted sender (optional)                       Temporary-radio state            Either state Inactive Active Common actions <p>         Choosing a phase-specific action automatically selects a compatible         phase and ACL owner. Open the advanced section to inspect or override         those choices.       </p>            Forwarding verdict            No verdict change Drop / do not retransmit            Region-gate decision            Leave global gate unchanged Require original allowed region Bypass global gate for this packet            Scope rewrite target            Do not rewrite scope Regionless public scope Configured region            Target name                       Token rate per minute (optional)                       Burst tokens                       Rewrite timing            Inherit normal behavior Fast-track rewrite Normal queue timing Slow receive/transmit timing            Queue priority            Inherit High Normal Low            Retry path bucket            No retry action Bucket 1 Bucket 2 Bucket 3 Bucket 4 Bucket 5 Bucket 6            Retry attempts                       Decision tag (optional)            Advanced execution, ownership, and flood route <p>           Direct packets already carry a supplied path and are intentionally           outside this engine. The route condition below only distinguishes           unscoped floods from transport-scoped floods.         </p>              Stable rule ID                           Processing phase              1 - Incoming scope gate 2 - Scope rewrite 3 - Forwarding decision 4 - Decrypted content 5 - Scheduling and retry              Rule owner / capability              ACL 4 - Region/scope manager ACL 5 - Filter manager Administrator Firmware-managed system rule              Priority                           Mode              Active Shadow - observe only Disabled              Rule processing after a match              Continue to later rules Skip later rules in this phase Skip all later policy rules              Flood route              Either flood route Unscoped flood only Transport-scoped flood only Readable policy definition <code></code> <p></p> Add rule to policy Copy definition <p>Policy draft</p> Clear policy            Approximate target budget            Compact STM32 - 2 KB nRF52 - 8 KB Classic ESP32 - 16 KB Roomy ESP32 - 64 KB <p>         Rules match the same immutable packet facts. Ordering is phase, then         descending priority, then authenticated channel, raw hash, or wildcard         specificity, then stable rule ID. Drop decisions are sticky.       </p>          Add a rule or load an example to start exploring.        <p>Immutable packet simulator</p> Reset packet Read a raw MeshCore packet <p>             Paste an on-air packet as hexadecimal. The decoder follows the             MeshCore wire format, displays its             header, route, pbyte path, and clear payload envelope, then loads             only facts actually present on the wire into the simulator.           </p> Runs locally          Raw packet hex         014e912ceebb98918b86772df5dacf1bcba9e4127ffffaa8665596aa3e2903a3b1901fdc53497dfca6b5d7df2d771bea68de Decode and load packet          Received route          Unscoped flood Transport-scoped flood          Payload type          REQ RESPONSE TXT_MSG ACK ADVERT GRP_TXT GRP_DATA ANON_REQ PATH TRACE MULTIPART CONTROL OTA Reserved type 13 Reserved type 14 RAW_CUSTOM          Received hops                   Channel                   Received pbyte path                   Original scope status          Unscoped Allowed region Unknown or denied scope          Original scope name                   Resolved region name                   Decrypted sender                   Passive blacklist result          No match Matched          Matching path buckets                   Own-ID loop result          No loop match Strict only Moderate and strict Minimal, moderate, and strict          Temporary radio is active        Run policy simulation <p>Import and explain</p> <p>       Accepts one-line <code>policy set ... when ... do ...</code> definitions,       playground JSON, or a playground Base64 bundle.     </p> Explain input Load into builder <p>Export</p> Readable policy Policy JSON Playground Base64 <p>Proposed human-readable definition. Current firmware does not accept it yet.</p> <p>Structured draft used by this page.</p> <p>Browser-playground interchange only. It is not the final packed firmware codec.</p> Copy visible export Download JSON"},{"location":"filter_tool/#filter-builder-title","title":"Create a policy rule","text":""},{"location":"filter_tool/#filter-policy-title","title":"Rules in execution order","text":""},{"location":"filter_tool/#filter-simulator-title","title":"Explain an evaluation","text":""},{"location":"filter_tool/#filter-import-title","title":"Paste readable policy or a saved draft","text":""},{"location":"filter_tool/#filter-export-title","title":"Move or save this design","text":""},{"location":"filter_tool/#payload-type-reference","title":"Payload type reference","text":"<p>Use an exact <code>type=</code> value when a rule should match only one payload type. The class column shows which broader selector also matches it.</p> <code>type=</code> value Payload Class <code>req</code> Request <code>class:login</code> <code>response</code> Response <code>class:login</code> <code>txt_msg</code> Peer text message <code>class:login</code> <code>ack</code> Acknowledgment <code>class:other</code> <code>advert</code> Node advertisement <code>class:other</code> <code>grp_txt</code> Group-channel text <code>class:group</code> <code>grp_data</code> Group-channel datagram <code>class:group</code> <code>anon_req</code> Anonymous request <code>class:login</code> <code>path</code> Returned path <code>class:login</code> <code>trace</code> Path trace <code>class:other</code> <code>multipart</code> One frame in a multipart sequence <code>class:other</code> <code>control</code> Control or discovery data <code>class:other</code> <code>ota</code> OTA-over-LoRa data <code>class:other</code> <code>13</code> Reserved payload type 13 <code>class:other</code> <code>14</code> Reserved payload type 14 <code>class:other</code> <code>raw_custom</code> Application-defined raw data <code>class:other</code>"},{"location":"filter_tool/#current-fpf7-command-mapping","title":"Current FPF7 command mapping","text":"Firmware command FPF7 role <code>flood.rule</code> / <code>flood.filter</code> Forward-phase match and action rows <code>flood.channel.data</code> Compatibility view over one visible <code>type=grp_data</code> forward drop row <code>flood.channel.scope</code> Scope-rewrite phase rows <code>flood.filter.blacklist</code> One shared unordered path-ID set referenced by <code>path=blacklist</code> rows <p>Generalized repeaters expose 63 forward rows and commit those sections together. The blacklist is useful for refusing to retransmit floods associated with internet gateways dumping bulk traffic, but a path ID is truncated and unauthenticated; it identifies a routing pattern, not a person.</p>"},{"location":"filter_tool/#proposed-evaluation-contract","title":"Proposed evaluation contract","text":"<p>The simulator uses these rules:</p> <ol> <li>Only flood retransmission enters the policy. Direct routing and local packet    delivery remain outside it.</li> <li>Every matcher reads the same immutable receive-time packet facts.</li> <li>Rules run by phase and descending numeric priority. At an equal priority,    authenticated channel matches run before raw one-byte hash matches, which    run before wildcard channel matches; stable rule ID breaks the remaining    tie. An explicitly higher numeric priority overrides channel specificity.</li> <li>A drop decision is sticky and cannot be undone by a later rule.</li> <li>The first matching scope, timing, queue, and retry action in execution order    wins.</li> <li>All matching token-bucket rate constraints remain attached to the decision.</li> <li><code>stop=phase</code> skips later rules in that phase. <code>stop=policy</code> skips later    configurable rules, but never mandatory packet validation or radio safety.</li> <li>Shadow rules report what they would do without changing the decision or    stopping other rules.</li> <li>Expensive facts such as channel-key matching, decryption, and path-table    lookup are resolved once per packet and reused by every matching rule.</li> </ol> <p>The byte-budget display is deliberately approximate until the packed firmware codec exists. It demonstrates why simple mappings should not reserve a maximum- sized structure for every possible condition and action.</p>"},{"location":"firmware_picker/","title":"Firmware picker","text":"<p>Pick the choices in any order. Every selection narrows all the other controls to firmware combinations that were actually built in the current release set.</p> <p>The picker reads public release metadata from GitHub. It does not upload device information. Hardware names, target names, and download links come directly from the published firmware assets.</p> Current release set <p>Loading release information...</p> <p>       For a new installation, choose the exact board and role, prefer a       FULL / complete profile when it is available, and select       Erase &amp; fresh install (merged .bin). Narrower profiles       remain available when their reduced transport or feature set is intentional.     </p> <p>     Pick in any order. Use Any to clear one choice, or clear     everything with the button below.   </p> Hardware Loading hardware... Hardware variant Choose hardware first Install operation          Loading install choices...        Firmware role          Loading roles...        Logging / MQTT          Loading logging choices...        OTA capability          Loading OTA choices...        Connection / bridge mode Loading modes... Feature profile          Loading profiles...        Firmware variant Loading variants... Clear all choices      Loading the current firmware catalog...    <p>Exact firmware match</p> Recommended download <p></p> No exact firmware matched <p></p> Browse all firmware releases Advanced: search current release filenames <p>       Use this for uncommon board suffixes or expert recovery. A filename match       is not a board-identity check.     </p>        Filename contains"},{"location":"firmware_picker/#what-the-choices-mean","title":"What the choices mean","text":"Choice Use Companion A phone, computer, or host application controls the radio Repeater Standalone mesh relay Room Server Hosts room conversations and history Sensor / telemetry Publishes supported sensor data Terminal Chat Standalone serial-terminal interface USB logging / USB-connected MQTT Node remains attached to a computer over a data-capable USB cable Wi-Fi MQTT observer Firmware connects directly to MQTT over Wi-Fi; this is not USB logging USB logging + Wi-Fi MQTT Unified FULL image sends to both paths; avoid two publishers aimed at the same broker unless messages are deduplicated No logging Normal standalone operation without the dedicated logging/MQTT profile LoRa OTA repeater Repeater profile that can stage an exact matching update received over LoRa LoRa OTA source only Full Companion serving a host-supplied update to another node without self-installing it <p>Connection and bridge choices depend on the selected role. Companion firmware may offer Full, combined USB + Bluetooth, Bluetooth, USB, Wi-Fi, serial, or Ethernet transports. Normal repeater firmware includes runtime-controlled RS-232 support where the board has room; use <code>set bridge.enabled on</code> after configuring <code>bridge.uart</code> and <code>bridge.baud</code>. The Wio-E5 remains the capacity exception and offers a separate RS-232 image. Choose Wi-Fi MQTT under Logging / MQTT; it is an output mode, not a second connection choice. Repeaters may still offer separate ESP-NOW or Ethernet bridge firmware because those paths use different compiled drivers.</p> <p>An ESP-NOW bridge target keeps LoRa as its primary mesh radio. Its runtime <code>bridge.format</code> setting chooses the peer protocol: <code>wrapped</code> (the backward-compatible bridge-to-bridge default using <code>bridge.secret</code>) or <code>raw</code> (direct MeshCore ESP-NOW LR frames for <code>Generic_ESPNOW</code>, <code>SenseCapIndicator-ESPNow</code>, and other primary-ESP-NOW nodes). This is one firmware choice, not two board images. Match <code>bridge.channel</code> to the primary nodes' <code>espnow.channel</code> before selecting <code>set bridge.format raw</code>. For Heltec V4 specifically, <code>companion_radio_full</code> is still a LoRa-primary Companion; choose the existing <code>heltec_v4_repeater_bridge_espnow</code> firmware to make that board the LoRa/ESP-NOW gateway. Use its exact merged artifact when changing roles or partition layouts.</p>"},{"location":"firmware_picker/#full-versus-standard","title":"FULL versus standard","text":"<p>For a new installation, use the FULL / complete profile when it exists and the board has enough flash. FULL profiles keep the complete supported feature set and CLI. Standard profiles remain useful for boards without a FULL build, for an intentionally narrower transport, or when retaining an existing compatible partition layout.</p> <p>Changing between standard and FULL ESP32 layouts requires the exact-board merged image over USB. A running application cannot safely move its own active and inactive partitions.</p> <p>Current <code>full-usb-wifi</code> profiles use one binary for no external output, USB packet logging/USB-connected MQTT, direct WiFi MQTT, or both. The picker shows that same exact binary for each compatible logging choice; select the saved runtime mode with <code>set logging.output off|usb|wifi|both</code>. A FULL logging-fallback profile is listed only when no WiFi MQTT sibling exists; it appears for both the no-output and USB choices because <code>set usb.logging off|on</code> is persistent. On a fresh unified FULL install with no saved SSID, the setup AP and WiFi radio remain available for 30 minutes per boot, then turn off automatically until the next reboot or power cycle. An explicit administrator <code>start webconfig</code> remains available as an override. A saved SSID switches to the normal indefinite reconnect behavior instead.</p> <p>Full Companion profiles use one binary for USB, BLE, ordinary Wi-Fi on ESP32, source-only LoRa OTA, Terminal Chat, optional USB packet logging, and any board-qualified serial or Ethernet Companion transport. Bulk builds therefore omit separate attached-transport, Terminal Chat, and USB-logging artifacts whenever the exact Full recipe exists. RAK4631 repeater and room-server Ethernet images remain separate roles. Fresh installs default to logging off. Heltec V3 and base OLED V4 Full images also contain the former direct Wi-Fi MQTT Companion capability, configured at runtime through WebConfig, so their separate <code>companion_radio_wifi_mqtt</code> artifacts are omitted from canonical builds as well.</p> <p>When Full Companion does not fit but a matching USB Companion does, that USB artifact also supplies Terminal Chat and replaces its standalone release image. Heltec E290 and T190 now publish one Full USB + BLE + WiFi Companion; their old combined and single-transport names are explicit-build compatibility aliases. SSD1306 Full Companion builds use <code>set display.rotation 90|180|270</code>; <code>0</code> restores the board default, so a separate rotated release image is not recommended.</p> <p>Ordinary non-OTA roles also use one artifact for normal operation and USB logging. Select the saved mode with <code>set usb.logging off|on</code>; no <code>-logging-</code> artifact is emitted. KISS, BLE-only Companion, and constrained LoRa OTA repeater images retain their protocol/partition contracts and do not inherit plaintext USB logging.</p> <p>nRF52 Full Companion keeps the multi-role primary interface on <code>00</code>; it starts as an ASCII terminal and automatically hands a complete <code>&lt;</code> frame to Binary Companion. <code>set usb.logging on reboot</code> adds its plaintext interface <code>02</code>.</p> <p>Every ESP32 Full Companion instead exposes one USB TTY. Logging is off by default, so the TTY serves the ASCII/Binary Companion switcher. Use <code>set usb.logging on</code> to turn that same TTY into an input-capable plaintext CLI/logging stream; framed Binary Companion is unavailable on USB while logging owns it. <code>set usb.logging off</code> stops the logs and leaves the TTY in the normal ASCII terminal, matching a fresh Full installation. Send <code>+++MESHCORE-TERM-STOP</code>, or let a Companion app send a valid framed probe, to switch from there to Binary Companion. BLE and Wi-Fi Companion remain usable while the USB TTY is logging. ESP32 Full builds use the repository's Arduino-ESP32 2.x base where the board supports it; RC32 and ESP32-C6 retain their board-required Arduino 3.x platform but still expose only one USB TTY. A second ESP32 CDC interface is not part of the release profile.</p>"},{"location":"firmware_picker/#installation-methods","title":"Installation methods","text":"File Use <code>-merged.bin</code> Erase/fresh install, recovery, role migration, or partition-profile change on ESP32 over USB Non-merged <code>.bin</code> Update an existing same-board, same-role, same-partition installation <code>.zip</code> Native nRF52 Serial DFU update package; it is not an extra archive <code>.uf2</code> UF2 bootloader drag-and-drop install or update <code>.hex</code> Erase/recovery flash with a supported wired programmer <p>Never send a merged ESP32 image through browser OTA or LoRa OTA. Back up the node configuration and verify every filename suffix before flashing.</p>"},{"location":"firmware_picker/#lora-ota-and-otafix","title":"LoRa OTA and OTAFIX","text":"<p>A LoRa OTA repeater build installs repeater firmware that can receive and stage updates. A later LoRa update still needs an exact target identity, compatible partition signature, matching radio settings, and the correct update package.</p> <p>nRF52 LoRa OTA requires an OTAFIX bootloader built for the exact board. There is no universal bootloader file. Use the latest stable OTAFIX release and select the hardware-matched HEX, Serial DFU ZIP, or bootloader-update UF2.</p>"},{"location":"firmware_picker/#hardware-and-variant-names","title":"Hardware and variant names","text":"<p>Hardware families with multiple released targets get a second hardware-variant menu. It separates revisions, display type, expansion kit, radio/PA layout, pin map, and other physical differences without crowding the first menu. The firmware-variant menu separately exposes choices that still require different code or wiring, such as serial port or the legacy <code>no_external_sensors</code> target suffix. The picker labels that suffix Reduced optional environmental/ranging drivers: it does not disable generic I2C or unrelated board-integrated peripherals. Reduced RAK3401 and RAK4631 targets retain INA219/INA226/INA260/INA3221 as voltage/current entries in the optional sensor table. They are not the only I2C users: the SSD1306 OLED, supported autodiscovered RTCs, and RAK12500 GPS remain separate I2C peripherals in compatible recipes. RAK12501/L76K GPS uses Serial1 instead. The explicit RAK4631 Serial1 bridge omits the combined GPS provider because its bridge owns the RAK12501 UART, so that legacy image does not expose RAK12500 either. The firmware-configured INA3221 and RAK12500 addresses are both <code>0x42</code>; to install both, keep RAK12500 at <code>0x42</code>, strap INA3221 A0 to SCL for <code>0x43</code>, and use a build with <code>-DTELEM_INA3221_ADDRESS=0x43</code>. Companion power saving, controllable FEM receive gain, and radio-chip receive gain are saved settings rather than separate recommended firmware files. Do not substitute a similarly named physical target.</p> <p>The header-wired RAK19007 W25Q16 LoRa-OTA recipes are also exact hardware variants. Choose the W25Q16 variant for RAK4631 or for RAK3401 + RAK13302 only when that core/radio combination, the <code>EF4015</code> flash wiring, and its matching OTAFIX bootloader are all present. The common base-board wiring does not make the two firmware or bootloader identities interchangeable.</p> <p>The picker recommends one Full Companion image instead of separate USB, BLE, ordinary WiFi, and USB-logging images. On ESP32, logging is off by default so the one USB TTY starts in ASCII and automatically changes to framed Companion when a complete <code>&lt;</code> frame arrives. Enabling logging gives that TTY to the plaintext CLI/logger and disables framed USB Companion until logging is turned off and the normal ASCII-to-binary mode switch occurs. nRF52 Full Companion retains its optional dedicated interface <code>02</code>. Exact filename search still finds old aliases from earlier releases.</p>"},{"location":"flood_filtering/","title":"Flood Filtering and Moderation","text":"<p>This guide explains the Keymind forwarding filters. Repeaters expose the full set of channel, rule, blacklist, and moderation controls described here. FULL-profile ESP32 room servers expose the generalized <code>flood.rule</code> table (and its <code>flood.filter</code> alias) with 31 forward-rule slots, but not the repeater's scope-rewrite, passive-blacklist, or text-moderation phases. Standard room-server profiles do not compile the rule table. Filters decide whether the node retransmits a packet and can assign a transport scope before that decision. They do not stop local reception, packet logging, or MQTT observation.</p> <p>Only flood routes are filtered:</p> <ul> <li><code>0x00</code> / <code>ROUTE_TYPE_TRANSPORT_FLOOD</code> - flood routing with transport codes</li> <li><code>0x01</code> / <code>ROUTE_TYPE_FLOOD</code> - unscoped flood routing</li> </ul> <p>Direct routes <code>0x02</code> and <code>0x03</code> are never affected by these rules. The route and payload values follow the upstream packet-format reference and payload layouts, with this fork's LoRa OTA assignment noted below.</p>"},{"location":"flood_filtering/#before-making-changes","title":"Before making changes","text":"<p>On a repeater, show the current forwarding controls:</p> <pre><code>get repeat\nget flood.max\nget flood.max.unscoped\nget flood.max.advert\nget flood.channel.data\nget flood.channel.data.hops\nget flood.channel.scope\nget flood.channel.scope.require\nget flood.filter\nget flood.rule\nget flood.filter.blacklist\nget flood.moderation\n</code></pre> <p><code>flood.rule</code> is an alias for <code>flood.filter</code>, not another table. Generalized repeater FPF7 has 63 forward-rule slots plus scope-rewrite and shared-blacklist sections in the same atomic policy file. FULL room servers have 31 forward slots and empty repeater-only sections. Compact target profiles retain their separate FPF6-era controls. <code>flood.moderation</code> has 16 slots. A new repeater FPF7 table starts with <code>ota all suspend=tempradio</code> in slot 1 and an authenticated <code>#wardriving hops=5+</code> drop in slot 2; FULL room servers seed only the OTA row. <code>flood.moderation</code> starts empty. A row can opt into <code>suspend=tempradio</code>; temporary radio is not synonymous with OTA and can carry normal packet types too. A corrupt or truncated table fails open, so corrupt storage does not silently enable blocking.</p> <p>On a FULL ESP32 room server, use <code>get flood.rule</code> (or <code>get flood.filter</code>) for the available table. Remote rule changes require room-server administrator access. <code>flood.filter.blacklist*</code> and <code>path=blacklist</code> are repeater-only; use the ordered <code>prefix=</code> condition on a room server.</p>"},{"location":"flood_filtering/#force-floods-into-a-transport-scope","title":"Force floods into a transport scope","text":"<p><code>flood.channel.scope</code> can add a scope to a received unscoped flood or replace the scope of a transport-scoped flood before this repeater forwards it:</p> <pre><code>set flood.channel.scope &lt;channel|txt:*|login:*|other:*&gt; &lt;region|scope=name&gt; [path=blacklist|path=bucket:1-6] [tx=slow]\nset flood.channel.scope.&lt;slot&gt; &lt;channel|txt:*|login:*|other:*&gt; &lt;region|scope=name&gt; [path=blacklist|path=bucket:1-6] [tx=slow]\nget flood.channel.scope\nget flood.channel.scope.&lt;slot&gt;\ndel flood.channel.scope.&lt;slot&gt;\ndel flood.channel.scope all\n</code></pre> <p>The channel may be <code>public</code>, <code>#channel</code>, or a 128/256-bit hex key. A bare target names an existing region with a usable transport key. Use <code>scope=&lt;name&gt;</code> instead to derive a regionless public hashtag scope exactly as <code>flood.filter scope=&lt;name&gt;</code> does. The direct name is normalized with a leading <code>#</code>, may contain up to 30 characters, and does not need a region-list entry. Keyed rules first check the one-byte channel hash carried in the packet, then validate the MAC by decrypting with the configured channel key. A hash collision alone cannot force a scope.</p> <p>For example, this authenticates only <code>#rgdata</code> and rewrites it to <code>#BlackHole86</code> without creating a region:</p> <pre><code>set flood.channel.scope #rgdata scope=BlackHole86\nget flood.channel.scope.1\n</code></pre> <p>If that channel arrives scoped to <code>#usa</code>, the rule replaces <code>#usa</code> with <code>#BlackHole86</code>. It also handles unscoped packets and replaces any other incoming scope; the source scope is not a condition on the rule.</p> <p>Add <code>path=blacklist</code> to make a channel-scope row eligible only when the received path matches the passive <code>flood.filter.blacklist</code> ID table. It does not require an enabled <code>flood.filter</code> drop row. With 3-byte paths, one exact listed ID qualifies. With 2-byte paths, two received path entries must match the first two bytes of listed IDs. A 1-byte path never qualifies.</p> <p>Use <code>path=bucket:&lt;1-6&gt;</code> to match one of the existing <code>flood.retry.bucket</code> tables instead. Each bridge bucket holds up to 17 three-byte IDs and remains usable by channel scoping while <code>flood.retry.bridge</code> is off. Bucket matching uses the same thresholds as the blacklist: one exact hit for 3-byte paths, two qualifying entries for 2-byte paths, and no matches for 1-byte paths. Channel scoping reads the configured IDs directly; <code>recent.repeater</code> freshness and <code>flood.retry.ignore</code> do not change this match.</p> <p>There are three independent wildcard classes:</p> <ul> <li><code>txt:*</code> handles otherwise-unmatched <code>GRP_TXT</code> and <code>GRP_DATA</code>; plain <code>*</code> is   its alias.</li> <li><code>login:*</code> handles <code>REQ</code>, <code>RESPONSE</code>, <code>TXT_MSG</code>, <code>ANON_REQ</code>, and <code>PATH</code>.</li> <li><code>other:*</code> handles every remaining flood payload type, including flood-form   TRACE and OTA.</li> </ul> <p><code>login:*</code> and <code>other:*</code> classify only the visible outer payload type; they do not authenticate its contents. Exact channel rows with usable targets always take precedence over <code>txt:*</code>, even if that wildcard has a lower slot number. Within the exact class, matching path-qualified rows are tried before ordinary fallback rows. The same qualified-then-fallback order applies within each wildcard class. A missing or unusable target is skipped, so later rows remain eligible. The lowest usable slot wins within each priority tier.</p> <p>For example, this uses bridge bucket 1 to assign <code>east</code> to <code>public</code> packets whose received 3-byte path contains <code>7576FB</code>, and assigns <code>west</code> to all other authenticated <code>public</code> packets:</p> <pre><code>set flood.retry.bucket 1 7576FB\nset flood.channel.scope public west\nset flood.channel.scope public east path=bucket:1\n</code></pre> <p>More 3-byte IDs can be added to bucket 1 later. Any one of them qualifies the <code>east</code> row. Replacing or clearing that bucket changes which paths qualify but leaves both channel-scope rows intact. Bridge retry does not need to be enabled.</p> <p>On a successful match, an unscoped route changes from <code>ROUTE_TYPE_FLOOD</code> to <code>ROUTE_TYPE_TRANSPORT_FLOOD</code>; an already-scoped route remains transport-flood but receives replacement codes. Transport code 0 is calculated with the target region or direct hashtag key over the payload type and payload, and code 1 becomes zero. The change happens before region enforcement, forwarding filters, and deduplication. Consequently <code>flood.max.unscoped</code> no longer applies to a packet converted from unscoped, while <code>flood.max</code>, <code>flood.filter</code>, loop detection, and moderation still apply to every rewritten packet. A region target must be flood-allowed. A regionless target is trusted for this matched receive pass, but it neither creates a region nor changes how unrelated packets with the same transport code pass the region gate. By default, if the selected scope differs and the rewritten packet passes those checks, its initial retransmission uses zero <code>txdelay</code> and the highest outbound queue priority so the newly scoped copy can win at the next hop. Add <code>tx=slow</code> to use an effective inbound <code>rxdelay</code> base of <code>max(2, configured rxdelay * 2)</code>, retain normal outbound queue priority, and force the maximum <code>txdelay</code> factor of <code>2.0</code>. The actual transmit delay is still randomized, from zero through ten packet airtimes. It does not preempt an active radio transmission or bypass CAD and airtime-budget limits. Selecting the scope already present is a no-op and does not grant special treatment.</p> <p>Direct routes are never rewritten. Standard traceroute is direct-routed and therefore remains outside this flood-only table. A custom flood-form TRACE is treated like every other flood: an applicable wildcard may rewrite it and the normal region/unknown-code gates still apply. Scope assignment does not override normal payload validation or make an otherwise non-forwardable packet type forwardable.</p> <p>LoRa OTA (<code>0x0C</code>) falls under <code>other:*</code>. A matching row adds the selected transport code or replaces the existing one, but OTA still operates normally during the temporary-radio window because the OTA handler accepts both unscoped and transport-scoped flood routes. A region target must allow flooding; a direct target uses the regionless trust behavior above. A new repeater also seeds <code>ota all suspend=tempradio</code> in flood-filter slot 1. That visible rule blocks OTA forwarding at every received hop outside temporary-radio operation and is skipped while temporary radio is active. Independently, the OTA core refuses OTA receive, relay, and transmit outside an actually active temporary-radio window, even if the seeded row is deleted or replaced.</p> <p>Capacity is selected at build time:</p> <ul> <li>Roomy ESP32 builds: 255 rewrite slots and 32 regionless-target slots, 10,204   bytes RAM.</li> <li>DRAM-tight classic ESP32 LoRa-OTA repeaters, nRF52, and other normal   constrained builds: 31 rewrite and regionless-target slots, 2,108 bytes RAM.</li> <li>Very-tight STM32WL builds: 15 rewrite slots and one reusable regionless-target   slot, 572 bytes RAM.</li> <li>The no-PSRAM LilyGo T-LoRa V2.1 repeater/observer: 4 rewrite and   regionless-target slots, 272 bytes RAM. This minimum holds the   three wildcard classes and one exact channel mapping.</li> </ul> <p>Each rule retains its 36-byte record. A separate table holds 32-byte normalized names for up to the smaller of the rule count or 32 distinct regionless targets, except that very-tight STM32WL builds retain one reusable direct target. Both configured regions and regionless targets can be reused by any number of rules.</p> <p>On generalized builds these records are the FPF7 rewrite phase, and the file stores only through the highest occupied slot. Compact FPF6 builds retain the standalone FCS5 file and the file sizes described by their build profile.</p>"},{"location":"flood_filtering/#require-valid-incoming-scopes-only-on-selected-channels","title":"Require valid incoming scopes only on selected channels","text":"<p><code>flood.channel.scope.require</code> changes region enforcement for received flood <code>GRP_TXT</code> and <code>GRP_DATA</code> packets from a global policy to a channel opt-in policy:</p> <pre><code>set flood.channel.scope.require &lt;public|#channel|128/256-bit-key&gt;\nset flood.channel.scope.require.&lt;slot&gt; &lt;public|#channel|128/256-bit-key&gt;\nget flood.channel.scope.require\nget flood.channel.scope.require.&lt;slot&gt;\ndel flood.channel.scope.require.&lt;slot&gt;\ndel flood.channel.scope.require all\n</code></pre> <p>An empty table preserves the normal global region behavior. Once at least one row exists, a group-channel packet that authenticates against a listed key must arrive as <code>ROUTE_TYPE_TRANSPORT_FLOOD</code> with a transport code matching a locally flood-allowed region. An unscoped packet, an unknown transport code, or a code for a denied region is not retransmitted. The check uses the original incoming scope before <code>flood.channel.scope</code> or <code>flood.filter scope=</code> can rewrite it. Those rewrite actions are skipped for a rejected listed channel, so they cannot rescue it or grant special receive/transmit timing.</p> <p>Group-channel packets that do not authenticate against any listed key bypass the region/unknown-code forwarding gate. They still pass through <code>repeat</code>, <code>flood.max*</code>, <code>flood.filter</code>, loop detection, payload validation, and moderation. Non-channel flood payload types retain the normal global region behavior. A one-byte channel-hash collision is only a prefilter; the packet must also pass MAC validation/decryption with the configured key.</p> <p>Without <code>.slot</code>, setting an existing key updates its row and a new key uses the first empty row. Numbered <code>set</code> replaces that slot. Detail output displays only the first four derived hash bytes and key size, never the secret. The table has the same build-dependent slot count as <code>flood.channel.scope</code>; each row consumes 34 bytes of RAM and storage, plus a five-byte file header. ACL permission <code>4</code> can manage it.</p> <p>For example, this requires an allowed incoming scope on <code>#bot</code>, while every other group channel bypasses region enforcement:</p> <pre><code>set flood.channel.scope.require #bot\nget flood.channel.scope.require\n</code></pre>"},{"location":"flood_filtering/#interaction-with-duplicate-detection","title":"Interaction with duplicate detection","text":"<p>The seen-packet hash contains the payload type and exact payload bytes. It does not contain the route type, either transport code, or the ordinary flood path. For <code>TRACE</code> only, the encoded <code>path_len</code> byte is also included. Therefore an unscoped packet and the same packet after this repeater adds a transport code are the same duplicate. A later copy with a different scope is also the same duplicate; changing or adding scope cannot evade the seen table.</p> <p>When equivalent non-TRACE flood copies overlap in <code>rxdelay</code>, the normal receive-quality timing still chooses the packet to process, but that winner takes a scope from the queued copies whose transport code matches an allowed region in this repeater. Unknown and denied scopes are ignored. If eligible copies have different scopes, the shortest received path supplies the scope. Equal path lengths prefer the deepest matching child region (the narrowest configured scope). A remaining tie keeps queue order. The winner keeps its own path, SNR, and delay schedule; only its route and transport codes can change, including replacement of a less-preferred scope it already carried.</p> <p>Scope selection happens at dequeue so the original scopes remain available for comparison. It applies only while copies are queued and cannot alter a copy already processed into the seen table. Flood-form TRACE participates in the same arbitration. Direct traceroute never enters this flood queue.</p> <p>A packet that already matches a configured fast <code>flood.channel.scope</code> or <code>flood.filter scope=</code> action and needs its scope changed bypasses this inbound <code>rxdelay</code> queue entirely. A <code>tx=slow</code> row remains in the queue with twice the configured base, floored at <code>2.0</code>, and participates in normal queued-copy scope arbitration.</p>"},{"location":"flood_filtering/#runtime-flood-rules","title":"Runtime flood rules","text":"<p>On repeaters with the rule engine enabled and on FULL-profile ESP32 room servers, <code>flood.rule</code> and <code>flood.filter</code> are two names for the same persistent table. The evaluator is fixed firmware, but every row is data, so an authenticated operator can add, replace, inspect, or delete a row without an OTA or reboot. Existing <code>flood.filter</code> commands remain compatible. Only FPF6 and FPF7 files are accepted; FPF1-FPF5 files are rejected and filtering fails open. A row saved by the extended engine uses FPF7. Older firmware cannot preserve an FPF7 table containing the packed <code>retry</code> action or one-byte <code>hash:XX</code> matcher; remove those rows before downgrading.</p> <p>The former <code>flood.channel.block</code> table is now represented by ordinary FPF7 rows. On a generalized repeater, an existing FCB2 file is imported once into free FPF7 slots and then removed. For example, an old <code>#wardriving h=4</code> row becomes <code>type=any channel=#wardriving hops=5+ drop</code>. The 63-row table can hold all 31 former general filter rows, all 15 legacy channel-block rows, and the migrated global <code>flood.channel.data</code> gate. Compact STM32WL FPF6 builds cannot match authenticated channels and retain the older separate gate.</p> <p>On generalized repeaters, <code>flood.channel.data*</code> is a compatibility view over one ordinary visible FPF7 <code>type=grp_data ... drop</code> row. Turning it off creates or updates that row; turning it on removes the row. Its hop setting maps to <code>hops=all</code> or <code>hops=N+1+</code>. There is no hidden GRP_DATA forwarding check ahead of FPF7. Normal ordering applies, so a matching higher-priority <code>stop</code> row can exempt selected traffic. The compact rule list marks the managed row with <code>~data</code>.</p> <p>FPF7 binds <code>in=region:&lt;name&gt;</code> and <code>region=&lt;name&gt;</code> to canonical region names, not numeric region IDs. Removing, reordering, or reusing a region ID cannot silently redirect a rule. If the saved name is missing, an input-region match does not match and a target-region rewrite is skipped. Re-adding the same name reactivates the rule.</p> <p>The extended form is:</p> <pre><code>set flood.rule[.&lt;slot&gt;] type=&lt;type&gt; [hops=&lt;range&gt;] [channel=&lt;channel&gt;]\n    [prefix=&lt;ID[,ID...]&gt;] [in=&lt;input-scope&gt;] &lt;action&gt; [rate=&lt;N&gt;/min]\n    [priority=&lt;0-255&gt;] [stop] [tx=fast|slow] [suspend=tempradio]\nget flood.rule\nget flood.rule.&lt;slot&gt;\ndel flood.rule.&lt;slot&gt;\ndel flood.rule all\n</code></pre> <p>The command must be entered on one line. Match fields in one row are ANDed. Every row is matched against the same immutable packet state captured on receive, before any rule rewrites its scope. Matching rows are then processed by descending numeric <code>priority</code>. At an equal numeric priority, authenticated channel matches run before raw <code>hash:XX</code> matches, raw hashes run before <code>channel=*</code>, and lower slot number breaks the remaining tie. Priority defaults to <code>0</code>; an explicitly higher numeric priority overrides specificity.</p> <p>The first matching <code>stop</code> row ends the FPF7 forward phase after that row. Higher-order matches and the stop row still apply; lower-order matches do not. A stop-only row is therefore an exception to lower-priority FPF7 rows. It cannot undo a higher-priority drop and it does not bypass hard forwarding gates or the scope-rewrite and moderation phases. Without a stop row, matching drop and rate rows remain independent and the highest-order matching scope or region rewrite wins.</p> <p>Match fields:</p> <ul> <li><code>type=</code> accepts the same packet names and numeric values as legacy   <code>flood.filter</code>. The positional form remains accepted.</li> <li><code>hops=</code> accepts <code>all</code>, <code>N</code>, <code>N+</code>, or <code>N-M</code>. The positional form remains   accepted. Received hops over 3 are written as <code>hops=4+</code>.</li> <li><code>channel=*|public|#name|hash:XX|128-bit-key|256-bit-key</code> optionally narrows by   channel. <code>channel=*</code> is an unconstrained wildcard: it performs no channel   authentication and matches every payload selected by <code>type=</code>. Thus   <code>type=any channel=*</code> means every flood payload type. <code>public</code>, <code>#name</code>, and   raw keys authenticate one channel and narrow the row to <code>GRP_TXT</code> or   <code>GRP_DATA</code>. <code>hash:XX</code> compares only the visible one-byte group-channel hash.   <code>short:XX</code> and a bare two-digit byte are aliases; saved output uses   <code>hash:XX</code>. This matcher is unauthenticated, has a 1-in-256 collision space,   and can be selected by a sender, so prefer an exact name or key when known.   <code>hash:11</code> is not an alias for Public: it includes Public and every <code>0x11</code>   collision, while <code>public</code> verifies and decrypts with the Public key. This is   channel authentication, not sender authentication: the group MAC is two   bytes and the Public key is shared.</li> <li><code>prefix=</code> is a source-path prefix containing one to three comma-separated   pbyte IDs. Every ID must use the packet's pbyte width: 2, 4, or 6 hex   characters for 1-, 2-, or 3-byte paths. Order matters and matching begins at   the first received path entry. <code>path=&lt;prefix&gt;</code> is an alias;   <code>path=blacklist</code> retains its separate unordered-list behavior.</li> <li><code>in=any|none|scoped|allowed|unknown|scope:&lt;name&gt;|region:&lt;name&gt;</code> tests the   original incoming route before any rewrite. <code>none</code> means an unscoped flood;   <code>scoped</code> means any transport flood; <code>scope:name</code> compares the exact public   hashtag-derived scope; and <code>region:name</code> compares an allowed configured   region. <code>allowed</code> is the legacy <code>require=region</code> test and includes an   unscoped packet when the wildcard region allows it. <code>unknown</code> means a scoped   packet that does not resolve to an allowed local region.</li> </ul> <p>Actions:</p> <ul> <li><code>drop</code> prevents retransmission when the row matches. The strict   <code>flood.rule</code> form requires an explicit action. For backward compatibility,   only a legacy <code>flood.filter</code> row with no rewrite, rate, or stop action means   drop implicitly.</li> <li><code>scope=&lt;name&gt;</code> derives a public transport scope directly from the name; no   region entry is consulted. <code>scope=BlackHole86</code> is therefore a valid   regionless sink. <code>region=&lt;name&gt;</code> is different: it resolves a configured,   flood-allowed region and one of that region's transport keys.</li> <li>A <code>stop</code> on a row whose <code>region=</code> target is currently unusable is also inert,   allowing lower-priority safety rules to run. Direct <code>scope=</code> targets do not   have this configuration dependency.</li> <li><code>rate=N/min</code> is a per-node, per-row fixed one-minute forwarding limit. It can   stand alone or accompany a scope/region rewrite. Quota is charged only after   every other forwarding gate, including moderation, accepts the packet. It is   not keyed per sender; use <code>flood.moderation</code> when a group-text rate must be   tied to an exact display name.</li> <li><code>retry</code> allows a matching received flood to start the configured retry   sequence. <code>retry=on</code>, <code>retry=allow</code>, and <code>action=retry</code> are aliases. If the   table has no active <code>retry</code> rows, global retry behavior is unchanged. If it   has one or more, those rows are a retry allow-list: at least one must remain   in the ordered, stop-truncated match set. The action may accompany rewrite,   rate, or stop, but not <code>drop</code>; its compact flag is <code>f=r</code>.</li> <li><code>priority=0-255</code> controls the primary processing order. Higher values run   first. Equal values use automatic channel specificity (authenticated, then   raw hash, then wildcard) before slot order. <code>pri=</code> is the compact alias.</li> <li><code>stop</code> (or <code>action=stop</code>) applies this row and prevents lower-order FPF7 rows   from acting. It can stand alone or accompany drop, rewrite, or rate.</li> </ul> <p>When several rows use the same channel key, authentication is performed once for that packet and reused by those rows. This cache lives only for the current receive evaluation; it is not persisted and never stores plaintext or a password. A <code>hash:XX</code> row deliberately skips authentication and uses only the one visible byte.</p> <p>The global retry controls remain hard gates. A <code>retry</code> row does not override a zero <code>flood.retry.count</code>, path/type attempt caps, disabled forwarding, <code>flood.retry.advert</code>, a drop verdict, or any other forwarding rejection. <code>flood.retry.bridge</code> independently chooses ordinary retry or bridge-bucket completion for an allowed packet. The selector applies to received floods; locally originated floods retain the normal global behavior.</p> <p>The exact requested examples are:</p> <pre><code># If #rgdata arrives unscoped with more than 3 received hops, add\n# the regionless #BlackHole86 scope.\nset flood.rule.2 type=grp_data hops=4+ channel=#rgdata in=none scope=BlackHole86\n\n# Rewrite the exact incoming #usa scope to #BlackHole86 for #rgdata.\nset flood.rule.3 type=grp_data channel=#rgdata in=scope:usa scope=BlackHole86\n\n# Match a two-byte source-path prefix and cap forwarding at 10 per minute.\nset flood.rule.4 type=any prefix=860C rate=10/min\n\n# Keep authenticated #rgdata at two hops or less out of lower-priority FPF7\n# rules. Hard gates and separate tables still apply.\nset flood.rule.5 type=grp_data hops=0-2 channel=#rgdata priority=200 stop\n\n# Retry received Public and #hamradio floods, using bridge completion.\n# Once these rows exist, other received floods are not retried.\nset flood.retry.bridge on\nset flood.rule.6 type=any channel=public retry\nset flood.rule.7 type=any channel=#hamradio retry\n\n# Fall back to an unauthenticated one-byte match if only the visible hash is known.\nset flood.rule.8 type=any channel=hash:A7 retry\n\nget flood.rule.2\nget flood.rule.3\nget flood.rule.4\n</code></pre> <p>Public's visible channel hash is <code>0x11</code>, so a <code>hash:11 drop</code> row also matches Public unless an earlier exact-channel rule stops it. This standalone example preserves authenticated Public while dropping other packets that use the same visible byte:</p> <pre><code>set flood.rule.2 type=any channel=public retry stop\nset flood.rule.3 type=any channel=hash:11 drop\n</code></pre> <p>The Public rule's MAC/decrypt check must succeed before its <code>stop</code> applies. A colliding channel misses that rule and reaches the hash drop. With equal numeric priorities, authenticated-channel specificity automatically puts the Public rule first regardless of slot order. Without <code>stop</code>, both rows match Public and the sticky drop wins. Remove <code>retry</code> from the Public row if the exemption should not also opt Public into flood retry. An explicitly higher numeric priority on the hash rule remains an operator override.</p> <p>The 240 KB STM32WL profiles keep <code>MESH_ENABLE_FLOOD_RULE_ENGINE=0</code> and retain the persistent compact FPF6 <code>flood.filter</code> and blacklist syntax below. They still perform filtering, but omit the generalized <code>flood.rule</code> parser and extended fields. No partition size is changed by this feature.</p> <p>The compatible filter and blacklist commands are:</p> <pre><code>set flood.filter.blacklist &lt;ID[,ID...]&gt;\nset flood.filter.blacklist.&lt;slot&gt; &lt;ID[,ID...]&gt;\nget flood.filter.blacklist\nget flood.filter.blacklist.&lt;slot&gt;\ndel flood.filter.blacklist\ndel flood.filter.blacklist.&lt;slot&gt;\nset flood.filter &lt;type&gt; [hops] [path=blacklist] [scope=&lt;name&gt;] [require=region] [tx=slow] [suspend=tempradio]\nset flood.filter.&lt;slot&gt; &lt;type&gt; [hops] [path=blacklist] [scope=&lt;name&gt;] [require=region] [tx=slow] [suspend=tempradio]\nget flood.filter\nget flood.filter.&lt;slot&gt;\ndel flood.filter.&lt;slot&gt;\ndel flood.filter all\n</code></pre> <p>The blacklist holds up to 255 unique 3-byte repeater IDs on ESP32 builds and 18 on other builds. Each is written as six hexadecimal digits. For example:</p> <pre><code>set flood.filter.blacklist A1B2C3,D4E5F6,112233\nset flood.filter.blacklist.4 445566\nset flood.filter any all path=blacklist\n</code></pre> <p>This is intended for abuse containment, such as refusing to retransmit floods that repeatedly enter the mesh through known internet gateways dumping bulk traffic. The list is shared by every FPF7 row and scope-rewrite row that uses <code>path=blacklist</code>; it is not copied into each rule.</p> <p>An unnumbered <code>set</code> replaces the list with up to 18 IDs, the largest command that fits every CLI transport. A numbered <code>set</code> writes a batch of up to 18 IDs beginning at an existing slot or the next consecutive slot. This is how an ESP32 list grows beyond 18. Deleting a numbered entry compacts the entries after it. Unnumbered <code>get</code> reports the total and prints the leading IDs that fit; numbered <code>get</code> retrieves one specific entry.</p> <p><code>path=blacklist</code> is an unordered precondition on that row. With 3-byte path hashes, one or more exact blacklist hits qualifies the packet. With 2-byte path hashes, two or more received path entries must match the first two bytes of listed IDs. Each received entry is counted at most once. A 1-byte path never qualifies. The IDs may occur anywhere in the received path; neither their list order nor their path order matters.</p> <p>Without a slot number, <code>set</code> reuses an identical row or selects the first empty slot. Use a slot number to replace a row whose match or action is changing. Omitting the hop expression means <code>all</code> (<code>0-63</code>).</p> <p>Numbered <code>get</code> normally uses the long field names. If a rule containing several maximum-length names would exceed one CLI reply, it switches to a non-truncating compact spelling that <code>set</code> also accepts: <code>c=</code> is <code>channel=</code>, <code>p=</code> is <code>prefix=</code>, <code>i=*|n|s|a|u|s:&lt;scope&gt;|r:&lt;region&gt;</code> represents <code>in=</code>, <code>q=N</code> is <code>rate=N/min</code>, and <code>f=str</code> combines slow timing (<code>s</code>), temporary-radio suspension (<code>t</code>), and retry allowance (<code>r</code>). The fallback prints packet type numerically.</p> <p>A legacy row without <code>scope=</code> is the existing drop action. On extended builds, an explicit <code>drop</code> has the same result, while <code>rate=</code> by itself creates a rate-only row. A row with <code>scope=</code> adds transport scope to an unscoped packet or replaces the codes on an already-scoped packet. The scope name is normalized with a leading <code>#</code>, and the 128-bit transport key is derived directly from that hashtag. The name does not need to exist in the region list and is not added to it. Public names up to 30 characters are accepted; private <code>$</code> scopes are not.</p> <p><code>require=region</code> is the legacy spelling of <code>in=allowed</code>. The repeater evaluates the packet's original route before any rewrite in that receive pass. An incoming transport scope must match a locally allowed region; an unscoped flood must be allowed by the wildcard region. If the check fails, that row is skipped, the filter does not grant a region bypass, and the unchanged packet is allowed to fail normal region enforcement. Other independently configured scope rows still apply in their normal order.</p> <p>When multiple scope or region rows match, the highest numeric-priority row wins. Equal priorities use authenticated channel, raw hash, then wildcard specificity before the slot-number tie-break. Rewrite rows do not approve a packet: any matching drop row and every remaining forwarding gate can still reject it. A filter-assigned scope is trusted without local region-list validation, but <code>repeat</code>, <code>flood.max</code>, loop detection, and moderation still apply. By default, a changed scope bypasses inbound <code>rxdelay</code>, then is retransmitted with zero <code>txdelay</code> and the highest outbound queue priority. Add <code>tx=slow</code> to use an effective inbound <code>rxdelay</code> base of <code>max(2, configured rxdelay * 2)</code>, retain normal queue priority, and force the maximum <code>txdelay</code> factor of <code>2.0</code>; the randomized transmit delay ranges from zero through ten packet airtimes. <code>tx=fast</code> explicitly restores the default. Selecting the scope already present does not grant special treatment. Active radio transmission, CAD, and airtime-budget limits are unchanged.</p> <p>On generalized repeaters, forward rules, <code>flood.channel.scope</code> rewrite rows, the shared blacklist, and the <code>flood.channel.data</code> compatibility state are one atomic FPF7 policy image. Existing <code>/flood_ch_scope</code>, <code>/flood_filter_bl</code>, FPF6, and FCB2 data is imported once; the old files are removed only after the new image verifies and commits. Compact FPF6 repeaters retain separate files. Deleting the blacklist leaves <code>path=blacklist</code> rows in place but dormant until IDs are configured again. Path hashes are truncated routing identifiers and are not authenticated proof that a particular repeater\u2014or a particular person\u2014handled a packet. FULL room servers reject blacklist commands.</p> <p>On first initialization, flood-filter slot 1 is seeded with:</p> <pre><code>set flood.filter.1 0x0C all suspend=tempradio\n</code></pre> <p>This is a normal editable row. After the table has been saved, deleting it remains persistent across reboot; the firmware does not recreate it. Run the same command to restore the exact seeded row, or omit <code>.1</code> to preserve existing slot assignments and use the first empty slot. Operators may add <code>suspend=tempradio</code> to any other row that should be skipped while the radio is on a temporary channel.</p> <p>Suspension does not approve a packet or bypass the rest of the filter table. It skips that row, then evaluation continues with the next row and the remaining forwarding gates. An ordinary drop <code>any</code> row therefore still applies during the temporary-radio window unless an earlier matching stop row ends FPF7 processing. <code>repeat</code>, <code>flood.max*</code>, region handling, loop detection, and the OTA subsystem's own hop limit also remain in force.</p> <p>Standard traceroute uses direct routing and never enters <code>flood.filter</code>. For a custom flood-form trace, <code>type=any</code>, explicit <code>trace</code>, scope, region, rate, and drop rows all behave normally. The stock core does not normally flood-forward TRACE packets.</p>"},{"location":"flood_filtering/#remote-administration-lockout-warning","title":"Remote-administration lockout warning","text":"<p>There are no hidden payload-type or short-hop exemptions in FPF7. Drop and rate rules can block <code>req</code>, <code>response</code>, <code>txt_msg</code>, <code>anon_req</code>, <code>path</code>, ACK, and multipart traffic beginning at hop <code>0</code> when their match fields say so.</p> <p>A flooded login starts as <code>ANON_REQ</code>; its reply is commonly a <code>PATH</code> packet carrying an encrypted <code>RESPONSE</code>. Before a direct return path is established, administrative replies and CLI text can also be flooded. Transit repeaters do not have the session key and cannot distinguish those encrypted admin exchanges from ordinary peer packets with the same outer type. A rule therefore affects the complete outer packet class, not only packets that ultimately authenticate as administrators. Keep a serial or other recovery path and stage broad deny/rate rules carefully.</p> <p>Hop expressions are based on the path count when this repeater receives the packet:</p> <ul> <li><code>N</code> matches exactly <code>N</code> received hops.</li> <li><code>N+</code> matches <code>N</code> or more received hops.</li> <li><code>N-M</code> matches the inclusive range.</li> <li><code>all</code> matches <code>0</code> through <code>63</code> hops.</li> <li><code>0+</code>, <code>all</code>, and omitting the hop expression are equivalent. <code>get</code> reports   the stored range using the canonical spelling <code>all</code>.</li> </ul> <p>Examples:</p> <pre><code># Stop forwarding group data once it arrives with four or more path entries.\nset flood.filter grp_data 4+\n\n# Stop long adverts, while still allowing shorter adverts.\nset flood.filter.2 advert 6+\n\n# Keep LoRa OTA floods from crossing this repeater at path counts 2 through 4.\nset flood.filter.3 ota 2-4\n\n# Assign #local scope to group text without requiring #local in the region map.\nset flood.filter grp_txt all scope=local\n\n# Rewrite only packets whose incoming region was already acceptable.\nset flood.filter grp_data all scope=local require=region\n\n# Rewrite matching blacklisted paths without fast-tracking their retransmission.\nset flood.filter grp_data all path=blacklist scope=local tx=slow\n\n# Drop matching flood types after the unordered path blacklist qualifies.\nset flood.filter.blacklist A1B2C3,D4E5F6,112233\nset flood.filter any all path=blacklist\n\n# Apply a hard ceiling to flood payload types at 12 or more received hops.\nset flood.filter any 12+\n</code></pre>"},{"location":"flood_filtering/#high-traffic-mesh-example","title":"High-traffic mesh example","text":"<p>This preset limits request and group-data propagation early while allowing the login-capable response, anonymous-request, and path types to travel farther:</p> <pre><code>set flood.filter req 3+\nset flood.filter response 9+\nset flood.filter 0x06 3+\nset flood.filter 0x07 9+\nset flood.filter path 9+\nset flood.filter control 1+\nget flood.filter\n</code></pre> Rule Stops retransmission when received with <code>req 3+</code> 3 or more path entries <code>response 9+</code> 9 or more path entries <code>0x06 3+</code> (<code>grp_data</code>) 3 or more path entries <code>0x07 9+</code> (<code>anon_req</code>) 9 or more path entries <code>path 9+</code> 9 or more path entries <code>control 1+</code> 1 or more path entries <p>On a new table, the factory OTA rule occupies slot 1, so these unnumbered commands normally fill slots 2 through 7. Existing tables may choose different free slots. All six rules take effect at the thresholds shown; there are no hidden short-hop exceptions. The Control rule allows a flood received with path count <code>0</code> to be forwarded once, then stops it at the next repeater. Normal node-discovery Control packets are direct zero-hop packets and never enter <code>flood.filter</code>. These rules affect only retransmission by the repeater; local reception and logging remain unchanged.</p> <p>Accepted payload names are:</p> Value Short name Full name <code>0x00</code> <code>req</code> <code>PAYLOAD_TYPE_REQ</code> <code>0x01</code> <code>response</code> <code>PAYLOAD_TYPE_RESPONSE</code> <code>0x02</code> <code>txt_msg</code> <code>PAYLOAD_TYPE_TXT_MSG</code> <code>0x03</code> <code>ack</code> <code>PAYLOAD_TYPE_ACK</code> <code>0x04</code> <code>advert</code> <code>PAYLOAD_TYPE_ADVERT</code> <code>0x05</code> <code>grp_txt</code> <code>PAYLOAD_TYPE_GRP_TXT</code> <code>0x06</code> <code>grp_data</code> <code>PAYLOAD_TYPE_GRP_DATA</code> <code>0x07</code> <code>anon_req</code> <code>PAYLOAD_TYPE_ANON_REQ</code> <code>0x08</code> <code>path</code> <code>PAYLOAD_TYPE_PATH</code> <code>0x09</code> <code>trace</code> <code>PAYLOAD_TYPE_TRACE</code> <code>0x0A</code> <code>multipart</code> <code>PAYLOAD_TYPE_MULTIPART</code> <code>0x0B</code> <code>control</code> <code>PAYLOAD_TYPE_CONTROL</code> <code>0x0C</code> <code>ota</code> <code>PAYLOAD_TYPE_OTA</code> in this fork <code>0x0D</code> <code>13</code> reserved <code>0x0E</code> <code>14</code> reserved <code>0x0F</code> <code>raw_custom</code> <code>PAYLOAD_TYPE_RAW_CUSTOM</code> <p>Decimal values <code>0</code> through <code>15</code>, hexadecimal values <code>0x00</code> through <code>0x0F</code>, the full <code>PAYLOAD_TYPE_*</code> names, and <code>any</code> are also accepted. Upstream currently reserves <code>0x0C</code>; this fork assigns it to LoRa OTA. Rows are suspended during temporary-radio operation only when explicitly configured that way.</p>"},{"location":"flood_filtering/#moderate-group-text-by-channel-and-username","title":"Moderate group text by channel and username","text":"<p>Use <code>flood.moderation</code> for flood <code>GRP_TXT</code> messages. The repeater validates and decrypts the selected channel, extracts the display name before the first <code>:</code>, then applies the rule:</p> <pre><code>set flood.moderation &lt;channel&gt; &lt;sender&gt; &lt;action&gt; [action...]\nset flood.moderation.&lt;slot&gt; &lt;channel&gt; &lt;sender&gt; &lt;action&gt; [action...]\nget flood.moderation\nget flood.moderation.&lt;slot&gt;\ndel flood.moderation.&lt;slot&gt;\ndel flood.moderation all\n</code></pre> <p>Channels can be specified as:</p> <ul> <li><code>public</code> for the built-in Public channel</li> <li><code>#name</code> for a well-known hashtag channel</li> <li>a 128-bit or 256-bit channel key in hexadecimal</li> </ul> <p>The key is stored locally so packets can be authenticated and decrypted. It is not included in <code>get flood.moderation</code> output.</p> <p>Available actions are:</p> <ul> <li><code>drop</code> - do not retransmit any matching message</li> <li><code>rate=X/min</code> - retransmit at most <code>X</code> messages per local 60-second window</li> <li><code>hops=N</code> - do not retransmit when the received path count is <code>N</code> or higher</li> <li><code>path=H1[,H2,H3]</code> - require the first one to three path hashes to match</li> <li><code>path=*</code> - match every path; this is the default</li> </ul> <p>At least one of <code>drop</code>, <code>rate=X/min</code>, or <code>hops=N</code> is required. Rate and hop limits can be combined. <code>rate=0/min</code> is equivalent to <code>drop</code>.</p>"},{"location":"flood_filtering/#per-user-per-channel-rate-limits","title":"Per-user, per-channel rate limits","text":"<p>Rate limits require an exact username; <code>*</code> is not accepted for a rate rule. Username comparison is ASCII case-insensitive, and names containing spaces must be quoted. A rule's counter is independent from rules for the same name on other channels, so this directly supports \"X messages per minute from user X on channel Y.\" Counters are local to this repeater and reset on reboot.</p> <pre><code># At most five Public-channel messages per minute from this display name.\nset flood.moderation public \"Noisy User\" rate=5/min\n\n# A separate limit for the same name on #local.\nset flood.moderation #local \"Noisy User\" rate=10/min\n\n# Combine a rate limit with a maximum forwarding distance.\nset flood.moderation public alice rate=4/min hops=5\n</code></pre>"},{"location":"flood_filtering/#match-the-start-of-a-path","title":"Match the start of a path","text":"<p>Path matching accepts one-, two-, or three-byte hashes. Every hash in one rule must use the same width, and matching always starts at the beginning of the received path:</p> <pre><code>set flood.moderation #local bot drop path=A1B2C3,D4E5F6\nset flood.moderation public alice rate=3/min path=71\n</code></pre> <p>A path-qualified rule cannot match a zero-hop packet and does not match until the packet contains all path entries listed by the rule.</p>"},{"location":"flood_filtering/#how-the-forwarding-controls-combine","title":"How the forwarding controls combine","text":"<p>A flood packet is retransmitted only if it passes every applicable control. In other words, the controls combine as deny rules:</p> <ol> <li><code>flood.channel.scope.require</code> evaluates a listed group channel against the    original incoming scope; unlisted group channels bypass the later region    gate while the table is active.</li> <li><code>flood.channel.scope</code> tries a path-qualified channel row before that    channel's ordinary fallback, then adds or replaces the scope from either a    configured region or a direct <code>scope=&lt;name&gt;</code> target.</li> <li>All extended <code>flood.rule</code> match fields are evaluated against the same    original incoming packet. Matches are ordered by descending numeric    priority, then authenticated/raw-hash/wildcard channel specificity, then    ascending slot. The first matching <code>stop</code> row removes every later FPF7    match. The highest-order remaining <code>scope=</code> or <code>region=</code> row may replace the    channel-scope result; a direct scope does not require a region-list entry.</li> <li><code>repeat</code> and <code>flood.max*</code> are checked.</li> <li>The FPF7 forward phase, including any row managed through    <code>flood.channel.data*</code>, applies drop and rate decisions using that saved    match result. No packet type or short-hop range is silently exempted.</li> <li>Region and loop-detection rules are checked; a regionless scope assigned by    either table is already trusted when it has no region-list match, except    that it cannot rescue a channel rejected by    <code>flood.channel.scope.require</code>.</li> <li><code>flood.moderation</code> checks decrypted group text, username, rate, hops, and    path. If it accepts the packet, matching general-rule rate counters are    charged immediately before retransmission is approved.</li> </ol> <p>The first denial is enough to prevent retransmission. A packet that is denied can still appear in local logs or MQTT output. Moderation runs last because its rate counters are charged only for packets that pass every other forwarding control and will actually be retransmitted.</p>"},{"location":"flood_filtering/#delegate-filter-management","title":"Delegate filter management","text":"<p>On repeaters, ACL permission <code>5</code> is the filter-manager role:</p> <pre><code>setperm &lt;companion-public-key-hex&gt; 5\n</code></pre> <p>A filter manager can read non-secret operational status and manage <code>repeat</code>, <code>loop.detect</code>, <code>flood.max*</code>, <code>flood.channel.data*</code>, <code>flood.filter*</code>, <code>flood.rule*</code>, and <code>flood.moderation*</code>. Delegated <code>get</code> access uses an explicit allowlist: it cannot retrieve guest, WiFi, MQTT, bridge, or other credentials, and it cannot change regions, ACL entries, radio settings, or unrelated administrator settings. Because <code>flood.filter scope=</code> derives a public hashtag key directly, a filter manager can configure that action without region-manager permission; it still cannot edit the region hierarchy.</p> <p>FULL ESP32 room servers use their existing administrator check for remote <code>flood.rule</code> and <code>flood.filter</code> commands; they do not grant this table through permission <code>5</code>.</p> <p>ACL permission <code>4</code>, the region/scope-manager role, can read, add, replace, and delete <code>flood.channel.scope</code> and <code>flood.channel.scope.require</code> rows and manage regions. This lets the same delegate create target regions, assign forced scopes from regions or direct hashtag names, and select the channels that require valid incoming scopes.</p>"},{"location":"flood_filtering/#security-limitations","title":"Security limitations","text":"<p>Public and hashtag channels use shared, well-known keys. A valid channel MAC proves that the sender knew the channel key; it does not identify a person. The <code>&lt;sender&gt;</code> value is an unverified display name and can be spoofed. Path hashes are truncated routing hints and can collide or be manipulated; they are not authenticated user identities.</p> <p>Use username and path rules as traffic moderation, not as an authorization boundary. For a strict network boundary, combine these tools with region ACLs, private transport/channel keys, and controlled device access.</p>"},{"location":"flood_filtering/#restore-the-factory-seeded-rows","title":"Restore the factory-seeded rows","text":"<p>The repeater's factory-seeded forwarding rows can be restored through the CLI:</p> <pre><code>set flood.rule.1 type=ota hops=all drop suspend=tempradio\nset flood.rule.2 type=any channel=#wardriving hops=5+ drop\n</code></pre> <p>These commands explicitly replace the two seeded generalized-repeater slots. Inspect them first if they may now contain other rules. Compact FPF6 builds use only the first command's <code>flood.filter.1 0x0C all suspend=tempradio</code> form.</p>"},{"location":"flood_filtering/#remove-the-custom-rules","title":"Remove the custom rules","text":"<p>To save both tables in an empty state:</p> <pre><code>del flood.filter all\ndel flood.moderation all\nget flood.filter\nget flood.moderation\n</code></pre> <p>This does not change the older <code>flood.max*</code>, loop-detection, or region settings; inspect or reset those separately when troubleshooting.</p>"},{"location":"full_companion_usb_switcher/","title":"Full Companion USB CLI and binary switcher","text":"<p>Full Companion uses one primary USB serial interface for two incompatible wire formats:</p> <ul> <li>a human-readable ASCII command line;</li> <li>the framed Binary Companion protocol used by MeshCore apps and <code>meshcli</code>.</li> </ul> <p>The primary interface starts in the ASCII terminal after each boot. A Binary Companion client does not need to send a special mode command: its first valid frame automatically hands the interface to the binary parser.</p> <p>This automatic behavior is compiled only into <code>companion_radio_full</code> targets. Ordinary USB Companion builds continue to use the explicit <code>+++MESHCORE-TERM-START</code> and <code>+++MESHCORE-TERM-STOP</code> controls described in the Terminal Chat CLI guide.</p>"},{"location":"full_companion_usb_switcher/#wire-formats","title":"Wire formats","text":"<p>Host-to-device Binary Companion frames use this layout:</p> <pre><code>'&lt;'  length-low  length-high  payload[length]\n</code></pre> <p>Device-to-host frames use the same little-endian length with a different marker:</p> <pre><code>'&gt;'  length-low  length-high  payload[length]\n</code></pre> <p>For example, a representative two-byte device query is:</p> <pre><code>3C 02 00 16 03\n</code></pre> <p>The ASCII terminal is line-oriented and accepts commands such as:</p> <pre><code>get radio.cad\nset display.rotation 90\nreboot\n</code></pre> <p>Changing the configured baud rate does not select a mode. Use 115200 for compatibility even though native USB CDC hardware does not use UART timing.</p>"},{"location":"full_companion_usb_switcher/#state-transitions","title":"State transitions","text":"<pre><code>                         complete '&lt;' frame\n                 +--------------------------------+\n                 |                                v\nboot ------&gt; ASCII terminal                  Binary Companion\n                 ^                                |\n                 |                                | +++MESHCORE-TERM-START\n                 | incomplete '&lt;' probe           |\n                 | (one-second timeout)            |\n                 +--------------------------------+\n\nASCII terminal -- +++MESHCORE-TERM-STOP ------&gt; Binary Companion\nASCII terminal -- observable USB disconnect ---&gt; Binary Companion\nESP32 logging terminal -- usb.logging off -----&gt; ASCII terminal\nany mode ------- reboot ------------------------&gt; ASCII terminal\n</code></pre> <p>Serial mOTA and single-TTY logging add exclusive ownership states described below. BLE, WiFi, Ethernet, and hardware-serial Companion transports are not switched; they remain binary.</p>"},{"location":"full_companion_usb_switcher/#how-automatic-detection-works","title":"How automatic detection works","text":"<ol> <li>Full Companion initializes the normal USB Binary Companion interface, then    gives its primary stream to the ASCII terminal before normal loop service    begins.</li> <li>While the prompt has no buffered input, the terminal peeks at the next byte.    It does not remove that byte.</li> <li>If the byte is <code>&lt;</code>, the terminal temporarily releases the stream and enables    the existing <code>ArduinoSerialInterface</code> frame parser.</li> <li>The parser consumes the original <code>&lt;</code>, the two-byte length, and the payload.    There is no second parser and no copied or synthetic frame.</li> <li>A monotonically increasing completed-frame counter confirms that the parser    received a complete frame. The interface then remains in Binary Companion    mode.</li> <li>If no complete frame arrives within one second, the parser state is reset    and the ASCII terminal prints a new banner and prompt.</li> </ol> <p>The switcher checks framing, not client identity. Any syntactically complete Binary Companion frame confirms binary mode; it does not require the first command to be <code>CMD_APP_START</code> or <code>CMD_DEVICE_QUERY</code>. Normal command validation still occurs after the frame parser returns the payload.</p> <p>The empty-prompt requirement prevents a literal <code>&lt;</code> in the middle of a command from silently changing modes. A literal <code>&lt;</code> typed as the first character does start a probe, but the terminal returns after the one-second timeout if no binary header and payload follow.</p>"},{"location":"full_companion_usb_switcher/#manual-controls","title":"Manual controls","text":"<p>The original controls remain available.</p> <p>From Binary Companion, send this exact unframed line while the parser is idle:</p> <pre><code>+++MESHCORE-TERM-START\n</code></pre> <p>Terminate it with CR or LF. The binary parser accepts control tokens only as complete delimiter-bounded lines; prefixes, suffixes, and partial tokens are ignored.</p> <p>From the ASCII terminal, send this exact sequence to return to binary mode:</p> <pre><code>+++MESHCORE-TERM-STOP\n</code></pre> <p>The stop sequence takes effect as soon as its last byte arrives in ASCII mode. The start sequence is recognized only as a completed line while the binary parser is idle and is not examined inside a length-prefixed frame.</p> <p><code>meshcli</code> can normally connect directly after boot:</p> <pre><code>meshcli -s /dev/ttyACM0 -b 115200 ver\n</code></pre> <p>An explicit terminal start token is still useful when the device is already in binary mode:</p> <pre><code>picocom -b 115200 \\\n  --imap spchex \\\n  --initstring $'+++MESHCORE-TERM-START\\r' \\\n  /dev/ttyACM0\n</code></pre>"},{"location":"full_companion_usb_switcher/#logging-and-mota-ownership","title":"Logging and mOTA ownership","text":"<p>The switcher never attempts to mix ASCII, framed Companion traffic, or binary mOTA traffic on the same stream.</p> Situation Primary USB behavior Full Companion after boot ASCII; a complete <code>&lt;</code> frame switches to Binary Companion nRF52 logging enabled Primary interface still follows the switcher; logs use the optional second interface ESP32 logging enabled at boot Logging terminal owns the only USB TTY; automatic <code>&lt;</code> detection is disabled nRF52 USB serial mOTA active mOTA owns primary USB; ASCII and Binary Companion are unavailable there BLE/WiFi/Ethernet/hardware serial Always Binary Companion and unaffected by the USB mode <p>On every ESP32 Full Companion, use <code>set usb.logging off</code> in its logging terminal before trying to use USB with an app. That command stops logging and returns to the ordinary ASCII terminal; it does not select Binary Companion. The app's first valid framed probe can perform the normal automatic switch, or a human can send <code>+++MESHCORE-TERM-STOP</code> first. The framed/binary Companion parser is disabled while logging owns that TTY. BLE and WiFi Companion transports remain available while USB is logging. ESP32 Full builds use the Arduino-ESP32 2.x base where supported; RC32 and ESP32-C6 keep their board-required Arduino 3.x platform but follow the same one-TTY policy. No ESP32 Full build enumerates a second CDC interface.</p> <p>On nRF52, serial <code>motatool</code> is also text-first. Its exact initial <code>ota folder on</code> line is recognized in either startup ASCII or Binary Companion mode. From ASCII, the firmware leaves terminal mode and directly enters exclusive mOTA ownership; from binary, the idle frame parser recognizes the same control sequence. The following mOTA request/reply frames therefore cannot be consumed by the ASCII line editor. <code>motatool serve --serial</code> can be the first client after boot and does not require a terminal token or disconnect workaround.</p> <p>Only the exact completed line selects mOTA from ASCII. Extra arguments, leading/trailing whitespace, or a partial line remain ordinary terminal input.</p>"},{"location":"full_companion_usb_switcher/#shortcomings-and-edge-cases","title":"Shortcomings and edge cases","text":"<p>This mechanism is deliberately small and deterministic, but it is not a full protocol negotiation layer.</p>"},{"location":"full_companion_usb_switcher/#it-is-startup-selection-not-per-connection-negotiation","title":"It is startup selection, not per-connection negotiation","text":"<p>After the first complete binary frame, the device stays in Binary Companion mode. Closing <code>meshcli</code> does not automatically restore ASCII. Use the terminal start token or reboot when an ASCII prompt is needed again.</p> <p>Conversely, closing an ASCII terminal on native USB normally changes the port to binary mode because the firmware can observe USB DTR/data disconnect. The next client therefore sees binary mode, not a new ASCII session. A USB-to-UART bridge often cannot report disconnect, so it can remain in ASCII until the stop token or a reboot.</p>"},{"location":"full_companion_usb_switcher/#detection-works-only-at-an-empty-prompt","title":"Detection works only at an empty prompt","text":"<p>If part of an ASCII command is already buffered, an incoming <code>&lt;</code> is treated as ordinary terminal input. Clear or submit the line before starting a Binary Companion client. Only one process should have the serial port open.</p>"},{"location":"full_companion_usb_switcher/#the-first-frame-has-a-one-second-deadline","title":"The first frame has a one-second deadline","text":"<p>The complete marker, length, and payload must arrive within the probe window. This is generous for local USB but may reject a heavily buffered serial proxy, a debugger that pauses the MCU, or a tool that writes the header and body with a long delay. A timed-out client can retry after the ASCII banner appears.</p>"},{"location":"full_companion_usb_switcher/#framing-confirmation-is-not-authentication","title":"Framing confirmation is not authentication","text":"<p>Any complete length-prefixed frame selects binary mode, even if its command is unknown or malformed at the application layer. This is safe for stream separation but means a random complete frame can leave the device in binary mode until manually switched back.</p>"},{"location":"full_companion_usb_switcher/#the-terminal-banner-is-best-effort","title":"The terminal banner is best effort","text":"<p>The firmware enters ASCII mode during boot, often before a host opens the CDC device. The banner may therefore be absent even though the terminal is ready; send a newline or a harmless <code>get</code> command rather than treating a missing banner as proof of binary mode.</p> <p>A host that remains connected across a reboot may receive ASCII banner and prompt bytes before the first binary response. Binary clients should discard leading bytes until a plausible <code>&gt;</code> frame marker and length are found, reject implausible lengths, and resynchronize. The ordinary open-after-boot path has been tested with <code>meshcli</code>, but third-party clients that assume byte zero is always <code>&gt;</code> may fail.</p>"},{"location":"full_companion_usb_switcher/#text-and-binary-output-cannot-be-interleaved","title":"Text and binary output cannot be interleaved","text":"<p>Primary USB suppresses Binary Companion output while the terminal owns the stream. Packet/debug logging must use its dedicated CDC interface or the exclusive single-TTY logging mode. Writing diagnostic text directly to the primary binary stream will corrupt clients regardless of the switcher.</p>"},{"location":"full_companion_usb_switcher/#a-literal-leading-briefly-hides-the-prompt","title":"A literal leading <code>&lt;</code> briefly hides the prompt","text":"<p>Typing <code>&lt;</code> as the first terminal character begins a binary probe. With no complete frame, the prompt returns after one second and the banner is printed again. There is currently no escape syntax for entering a literal leading <code>&lt;</code>; prefix it with another character if it is needed as command text.</p>"},{"location":"full_companion_usb_switcher/#troubleshooting","title":"Troubleshooting","text":"<p>If <code>meshcli</code> cannot connect:</p> <ol> <li>close every terminal or logging reader using the primary interface;</li> <li>on ESP32, confirm that saved USB logging is off;</li> <li>reboot and let <code>meshcli</code> be the first process to open the data interface;</li> <li>use the stable <code>/dev/serial/by-id/*-if00</code> path on Linux when available;</li> <li>if a prompt appears after one second, the client's first frame was not    completed inside the probe window.</li> </ol> <p>If an ASCII terminal shows no banner, press Enter and issue a harmless query such as <code>get radio.cad</code>. If binary bytes appear, send the exact terminal start token or reboot.</p> <p>The switch policy is implemented in <code>UsbAsciiBinarySwitch.h</code>, with stream ownership in <code>main.cpp</code> and framing in <code>ArduinoSerialInterface.cpp</code>.</p>"},{"location":"gps_tracking/","title":"GPS Tracking","text":"<p>This document describes how GPS telemetry works for companion/client nodes and sensor nodes.</p>"},{"location":"gps_tracking/#scope","title":"Scope","text":"<p>GPS tracking uses the existing CayenneLPP GPS telemetry field. It does not add a new phone app protocol field.</p> <p>The GPS telemetry value contains latitude, longitude, and altitude. Speed, heading, and freshness are not sent as separate telemetry fields.</p> <p>If the firmware does not have a valid fresh GPS cache, it omits the GPS field from telemetry. This is intentional: stale or missing fixes are not reported as zero coordinates.</p>"},{"location":"gps_tracking/#freshness","title":"Freshness","text":"<p>GPS telemetry is cached separately from advert location.</p> <p>The cache behavior is:</p> <ul> <li>Refresh the cached GPS value every 2 hours only when at least one contact or   ACL client can receive location telemetry.</li> <li>Try for up to 15 minutes during a refresh.</li> <li>If the position stays within about 100 meters for 30 seconds, cache a weighted   average of the stable fixes, with newer fixes weighted more heavily.</li> <li>If the position moves outside that 100 meter circle during acquisition, cache   the latest valid fix.</li> <li>Omit GPS from telemetry if there is no fix or if the cached fix is more than   12 hours old.</li> </ul> <p>When a telemetry request asks for location, GPS is kept on for 2 hours after the latest location request. During that hold window, later location telemetry requests can use fresh GPS data as soon as valid fixes are available.</p> <p>If GPS is manually enabled, it stays on and valid fixes continue to update the cache.</p> <p>If no contact or ACL client can receive location telemetry, the scheduled 2-hour refresh does not run. A real location telemetry request still turns GPS on for the 2-hour hold window, and manual GPS-on still keeps the cache updated.</p>"},{"location":"gps_tracking/#companionclient-nodes","title":"Companion/Client Nodes","text":"<p>Companion/client telemetry uses the existing companion telemetry permission system:</p> <ul> <li>base telemetry</li> <li>location telemetry</li> <li>environment telemetry</li> </ul> <p>Location telemetry is sent only when the requester's effective telemetry permissions include location. Those permissions are derived from the companion telemetry mode settings and contact flags.</p> <p>The scheduled GPS cache refresh runs only when at least one stored contact has effective location telemetry access:</p> <ul> <li><code>location: allow all</code> with at least one stored contact</li> <li><code>location: allow flags</code> with at least one stored contact whose flags include   location</li> </ul> <p>No new phone app behavior is required. Existing clients see the existing GPS telemetry field when it is present.</p>"},{"location":"gps_tracking/#sensor-nodes","title":"Sensor Nodes","text":"<p>Sensor telemetry access is controlled by:</p> <pre><code>get telemetry.access\nset telemetry.access all\nset telemetry.access acl\n</code></pre> <p><code>all</code> is the default and matches the previous sensor telemetry behavior. A request that reaches the normal sensor telemetry request path can receive the requested telemetry fields, including GPS, subject to the request mask and GPS freshness rules.</p> <p><code>acl</code> gates telemetry through the sensor ACL. A requester with read-only or higher permissions receives the existing telemetry set, including GPS. Guest or unknown requesters receive no telemetry fields.</p> <p>The scheduled GPS cache refresh follows the same access setting:</p> <ul> <li><code>all</code>: runs only when at least one ACL client exists</li> <li><code>acl</code>: runs only when at least one ACL client is read-only or higher</li> </ul> <p>Use the existing ACL command to grant access:</p> <pre><code>setperm &lt;pubkey&gt; 1\n</code></pre> <p>Permission values:</p> <ul> <li><code>1</code>: read-only, suitable for telemetry access</li> <li><code>2</code>: read-write</li> <li><code>3</code>: admin</li> </ul>"},{"location":"gps_tracking/#advert-location","title":"Advert Location","text":"<p>Advert location is separate from telemetry GPS. The advert policy is controlled with:</p> <pre><code>gps advert\ngps advert none\ngps advert share\ngps advert prefs\n</code></pre> <p>Policies:</p> <ul> <li><code>none</code>: do not include location in adverts</li> <li><code>share</code>: use the live/shared sensor manager location</li> <li><code>prefs</code>: use the stored node latitude and longitude preferences</li> </ul> <p><code>prefs</code> is the first-boot default for every repeater, room-server, and sensor build. Firmware updates retain an explicitly saved policy from the existing preferences filesystem.</p> <p>Telemetry GPS can be fresh while advert location is fixed or disabled, depending on this policy.</p>"},{"location":"gps_tracking/#recommended-setup","title":"Recommended Setup","text":"<p>For private sensor tracking:</p> <pre><code>set telemetry.access acl\nsetperm &lt;owner_pubkey&gt; 3\nsetperm &lt;trusted_pubkey&gt; 1\n</code></pre> <p>For compatibility with the older sensor behavior:</p> <pre><code>set telemetry.access all\n</code></pre> <p>For GPS telemetry behavior, leave the phone app unchanged. The firmware omits GPS when it is stale or missing and sends the existing GPS telemetry field when fresh data is available.</p>"},{"location":"halo_keymind_settings/","title":"Halo and Keymind Branch Settings","text":"<p>This file covers only CLI settings and helper commands added by the Halo or Keymind branches. Use <code>docs/cli_commands.md</code> for the general MeshCore CLI. See Repeater Flood Filtering and Moderation for a focused filter setup and troubleshooting guide.</p>"},{"location":"halo_keymind_settings/#quick-start","title":"Quick Start","text":"<pre><code>set retry.preset rooftop\nset direct.retry.heard on\nset flood.retry.advert off\nset flood.retry.bridge off\nset flood.retry.prefixes none\nset flood.retry.ignore none\n</code></pre> <p>Then verify:</p> <pre><code>get retry.preset\nget direct.retry.heard\nget flood.retry.advert\nget flood.retry.prefixes\nget flood.retry.ignore\n</code></pre> <p>Use prefixes from the analyzer or neighbors list or <code>get recent.repeater</code> after the repeater has been online for a few hours.</p>"},{"location":"halo_keymind_settings/#common-examples","title":"Common Examples","text":"<p>Disable retrying advert packets:</p> <pre><code>set flood.retry.advert off\nget flood.retry.advert\n</code></pre> <p>Ignore a repeater as a successful flood retry echo: Use this if you have a car repeater and a house repeater; have the house ignore the car.</p> <pre><code>set flood.retry.ignore 71CE82,C7618C\nget flood.retry.ignore\n</code></pre> <p>Only accept specific downstream relays as flood retry success: You're in a hole and need to hit a mountain top repeater to get out; keep trying till one you see one of these send out your packet.</p> <pre><code>set flood.retry.prefixes A58296,860CCA,425E5C\nget flood.retry.prefixes\n</code></pre> <p>Bridge two groups of repeaters:</p> <pre><code>set flood.retry.bridge on\nset flood.retry.bucket 1 71CE82,C7618C\nset flood.retry.bucket 2 BEEBB0,425E5C\nget flood.retry.bucket.1\nget flood.retry.bucket.2\n</code></pre> <p>Return to simple non-bridge flood retry:</p> <pre><code>set flood.retry.bridge off\nset flood.retry.prefixes none\nset flood.retry.ignore none\n</code></pre>"},{"location":"halo_keymind_settings/#added-settings","title":"Added Settings","text":"Setting What it does How to use Example <code>telemetry.temp</code>, <code>telemetry.volt</code>, <code>telemetry.volt.i2c</code>, <code>telemetry.gps</code> Repeater and room builds record 30-minute MCU temperature and battery samples for seven days. Detected INA voltage channels retain four days at 0.02 V resolution through 655.34 V; all-zero channels are omitted as disconnected. GPS-capable builds retain GPS separately. Repeater <code>telemetry.tx</code> sends temperature, battery, and per-channel I2C RAW_CUSTOM packets over a configured direct path on a persistent 1-30 day schedule (default two days) or immediately for testing; GPS is never included. History resets on reboot. <code>get telemetry.temp [page]</code>, <code>get telemetry.volt [page]</code>, <code>get telemetry.volt.i2c [channel [page]]</code>, <code>get telemetry.gps [page]</code>, <code>set telemetry.gps &lt;1-30&gt;</code>, <code>get telemetry.tx</code>, <code>set telemetry.tx &lt;off|direct|path&gt;</code>, <code>set telemetry.tx schedule &lt;off|1-30d&gt;</code>, <code>send telemetry.tx now</code> <code>get telemetry.volt.i2c 2 1</code> <code>battery.alert</code> Sends opt-in, region-scoped low-battery warnings to <code>#repeaters</code> after 30 minutes of uptime. <code>get battery.alert</code>, <code>get battery.alert.region</code>, <code>set battery.alert on [region]</code>, <code>set battery.alert off</code> <code>set battery.alert on sea</code> <code>battery.alert.low</code> Warning threshold percentage. Must be greater than <code>battery.alert.critical</code>. <code>get battery.alert.low</code>, <code>set battery.alert.low &lt;1-100&gt;</code> <code>set battery.alert.low 20</code> <code>battery.alert.critical</code> Critical threshold percentage. Critical and warning alerts use the same 12-hour resend cooldown. <code>get battery.alert.critical</code>, <code>set battery.alert.critical &lt;0-99&gt;</code> <code>set battery.alert.critical 10</code> <code>recent.repeater</code> Shows, searches, seeds, or clears the recent repeater prefix/SNR table used by direct retry and bridge freshness checks. Search results include the last-recorded age. Entries older than 24 hours are removed by a three-hour sweep. <code>get recent.repeater [page]</code>, <code>get recent.repeaters search &lt;2|4|6 hex&gt; [page]</code>, <code>set recent.repeater &lt;prefix&gt; &lt;snr_db&gt;</code>, <code>clear recent.repeater</code> <code>get recent.repeaters search A1B2</code> <code>flood.channel.data</code> Compatibility view for a visible FPF7 <code>type=grp_data</code> drop row on generalized repeaters. <code>off</code> creates the row and <code>on</code> removes it; compact FPF6 builds retain the legacy gate. Use an authenticated <code>channel=</code> row when only selected channels should be blocked. <code>get flood.channel.data</code>, <code>set flood.channel.data on/off</code> <code>set flood.channel.data off</code> <code>flood.channel.data.hops</code> Sets the compatibility row's hop range: <code>all</code> maps to <code>hops=all</code>; <code>1</code>-<code>7</code> repeats through that hop count and maps to <code>hops=N+1+</code>. <code>get flood.channel.data.hops</code>, <code>set flood.channel.data.hops &lt;all|1-7&gt;</code> <code>set flood.channel.data.hops 7</code> <code>flood.channel.scope</code> FPF7 rewrite-phase rows that add a transport scope to received unscoped floods or replace the scope of already-scoped floods. A bare target uses an existing flood-allowed region; <code>scope=&lt;name&gt;</code> derives a public hashtag target directly without creating a region, exactly like <code>flood.filter scope=</code>. By default, a changed packet bypasses inbound <code>rxdelay</code> and is forwarded at the highest outbound queue priority with zero initial <code>txdelay</code>, so the selected scope can win at the next hop. <code>tx=slow</code> uses an effective inbound <code>rxdelay</code> base of <code>max(2, configured rxdelay * 2)</code>, retains normal queue priority, and forces the maximum <code>txdelay</code> factor of <code>2.0</code>; its actual randomized transmit delay ranges from zero through ten packet airtimes. <code>path=blacklist</code> and <code>path=bucket:&lt;1-6&gt;</code> make a row path-qualified; bridge buckets remain usable while bridge retry is off. An already-matching scope is a no-op. Exact channel keys beat <code>txt:*</code>; path-qualified rows beat the ordinary channel fallback. <code>login:*</code> covers the remote-login family, and <code>other:*</code> covers every remaining flood type, including flood-form TRACE and OTA. Direct traceroute remains outside the flood table. Generalized builds commit these rows with the forward phase and blacklist; compact FPF6 builds retain separate storage. ACL permission <code>4</code> can manage the table. <code>get flood.channel.scope[.n]</code>, <code>set flood.channel.scope[.n] &lt;channel|txt:*|login:*|other:*&gt; &lt;region|scope=name&gt; [path=blacklist|path=bucket:1-6] [tx=slow]</code>, <code>del flood.channel.scope.&lt;n&gt;|all</code> <code>set flood.channel.scope #rgdata scope=BlackHole86</code> <code>flood.channel.scope.require</code> Switches group-channel region enforcement to opt-in when the table has entries. Listed authenticated <code>GRP_TXT</code>/<code>GRP_DATA</code> channels must arrive already scoped to a locally allowed region; unscoped, unknown, or denied incoming scopes are dropped before any rewrite can rescue them. Unlisted group channels bypass only the region gate and retain all other forwarding controls. An empty table preserves global region behavior; non-channel payloads are unchanged. ACL permission <code>4</code> can manage the table. <code>get flood.channel.scope.require[.n]</code>, <code>set flood.channel.scope.require[.n] &lt;public|#channel|key&gt;</code>, <code>del flood.channel.scope.require.&lt;n&gt;|all</code> <code>set flood.channel.scope.require #bot</code> <code>flood.filter</code> Persistent flood-route rules selected by payload type and optional hop range. Generalized repeaters have 63 FPF7 forward slots; FULL ESP32 room servers have 31. Repeaters store their scope-rewrite phase, shared unordered blacklist, and channel-data compatibility state in the same atomic FPF7 image. <code>path=blacklist</code> is intended for forwarding abuse containment, including bulk internet-to-mesh dumping, but truncated path IDs are not authenticated identities. Fixed 240 KB STM32WL repeaters retain compact FPF6 filtering and separate blacklist storage. New generalized repeater tables seed slot 1 with <code>ota all suspend=tempradio</code> and slot 2 with an authenticated <code>#wardriving hops=5+</code> drop. Direct routes and local receive/logging are unchanged. <code>get flood.filter[.n]</code>, <code>set flood.filter[.n] &lt;type&gt; [N|N+|N-M|all] [scope=&lt;name&gt;] [require=region] [tx=slow] [suspend=tempradio]</code>, <code>del flood.filter.&lt;n&gt;|all</code>; repeater only: <code>get/set/del flood.filter.blacklist[.n]</code> <code>set flood.filter grp_txt all scope=local tx=slow</code> <code>flood.rule</code> Live alias for extended <code>flood.filter</code> on rule-engine repeaters and FULL ESP32 room servers. A row can AND packet type, hop range, optional channel match, ordered 1/2/3-byte pbyte source prefix, and original scope/region conditions, then drop, rewrite to a direct scope or configured region, enforce a per-row rate, allow flood retry, and/or stop lower-priority FPF7 rules. <code>channel=*</code> means no channel condition; <code>public</code>, <code>#name</code>, and keys authenticate; <code>hash:XX</code> is an unauthenticated one-byte fallback with collision/spoof risk. With no <code>retry</code> rows, global retry behavior is unchanged; once any exists, matching <code>retry</code> rows allow-list received floods while the global retry gates and <code>flood.retry.bridge</code> algorithm still apply. <code>scope=BlackHole86</code> directly derives a regionless sink scope; <code>region=BlackHole86</code> would require a configured flood-allowed region. All rows match the original receive-time packet. Higher numeric <code>priority</code> runs first; equal values automatically order authenticated channels before raw hashes before <code>channel=*</code>, then use lower slot as the final tie-break. Repeated rows with one channel key share a per-packet authentication result. Persistent FPF7 stores canonical region names, so region ID reorder or reuse cannot retarget a rule. A missing saved region makes its <code>region=</code> rewrite and paired <code>stop</code> inert until the name returns, allowing lower safety rows to run. Fixed 240 KB STM32WL profiles keep FPF6 and do not expose this alias; partition sizes are unchanged. <code>get flood.rule[.n]</code>, <code>set flood.rule[.n] type=&lt;type&gt; [hops=...] [channel=...] [prefix=...] [in=...] &lt;drop|scope=...|region=...|rate=N/min|retry|stop&gt; [priority=0-255]</code>, <code>del flood.rule.&lt;n&gt;|all</code> <code>set flood.rule.2 type=any channel=#hamradio retry</code> <code>flood.moderation</code> Decrypts keyed <code>GRP_TXT</code> channels and applies drop, per-username messages/minute, and maximum-hop controls, optionally matched against the first 1-3 path hashes. Supports <code>public</code>, <code>#channel</code>, and 128/256-bit channel keys. Sender names and truncated path hashes are moderation hints, not authenticated identities. <code>get flood.moderation[.n]</code>, <code>set flood.moderation[.n] &lt;channel&gt; &lt;sender&gt; &lt;drop|rate=X/min|hops=N&gt; [path=...]</code>, <code>del flood.moderation.&lt;n&gt;|all</code> <code>set flood.moderation public \"Noisy User\" rate=5/min hops=4</code> <code>clock.sync.mesh</code> Defaults on for all repeater, sensor, and room-server builds; a saved setting overrides that default. It estimates UTC as soon as the configured number of fresh signed-advert or valid Public-channel sources is collected, with a 30-minute bootstrap/retry timer when evidence is still insufficient, then repeats lazily seven days after each successful estimate. New evidence retriggers evaluation after a no-consensus result. <code>clock.sync.mesh now</code> queues an immediate LoRa-only attempt without bypassing quorum or source suppression. Only timestamps from firmware build time through build time plus ten years are recorded. Successful CLI, GPS, or WiFi/NTP clock updates suppress LoRa time collection until reboot; after reboot LoRa is the fallback if NTP cannot sync. Status reports the reason a clock was not set; its <code>.table</code> and <code>.1</code> through <code>.16</code> forms inspect collected samples. <code>get clock.sync.mesh</code>, <code>set clock.sync.mesh &lt;on|off&gt;</code>, <code>clock.sync.mesh now</code>, <code>get clock.sync.status[.table|.1-.16]</code> <code>set clock.sync.mesh on</code> <code>clock.sync.mesh.edge</code> Defaults on so edge infrastructure nodes can collect clock evidence when all packets arrive through one relay path. Verified evidence is observed before the forwarding decision, so disabled forwarding and forwarding filters do not prevent collection. Signed adverts are deduplicated by public key and Public-channel timestamps by case-insensitive display name; all may share one receive path. Public display names are unauthenticated and can be spoofed. Changing this setting clears current clock samples. <code>get clock.sync.mesh.edge</code>, <code>set clock.sync.mesh.edge &lt;on|off&gt;</code> <code>set clock.sync.mesh.edge on</code> <code>clock.sync.internet</code> Adds a read-only internet/NTP estimate at the same initial and seven-day checks on WiFi MQTT repeater-observer builds. Other builds retain the setting but report internet unavailable. <code>get clock.sync.internet</code>, <code>set clock.sync.internet &lt;on|off&gt;</code> <code>set clock.sync.internet on</code> <code>clock.sync.drift</code> Absolute correction threshold in seconds; the default is 600 seconds (10 minutes). The clock is moved forward or backward only when the estimate differs by more than this value. <code>get clock.sync.drift</code>, <code>set clock.sync.drift &lt;30-86400&gt;</code> <code>set clock.sync.drift 600</code> <code>clock.sync.samples</code> Minimum fresh evidence count before mesh time can be used: distinct receive paths in normal mode or distinct advert keys/Public-channel display names in edge mode. A strict majority of all fresh samples is also required. Range <code>3-16</code>; default <code>9</code>. <code>get clock.sync.samples</code>, <code>set clock.sync.samples &lt;3-16&gt;</code> <code>set clock.sync.samples 9</code> <code>outpath</code> Overrides the primary direct route used for replies to the current remote client. <code>get outpath</code>, <code>set outpath &lt;hops&gt;</code>, <code>set outpath direct</code>, <code>set outpath clear</code>, <code>set outpath flood</code> <code>set outpath A1B2C3,D4E5F6</code> <code>altpath</code> Adds a secondary direct route for repeater replies to the current remote client. <code>get altpath</code>, <code>set altpath &lt;hops&gt;</code>, <code>set altpath direct</code>, <code>set altpath clear</code>, <code>set altpath flood</code> <code>set altpath 71CE82,BA09F0</code>"},{"location":"halo_keymind_settings/#other-keymind-commands","title":"Other Keymind Commands","text":"Command What it does How to use Example <code>send text.flood</code> Sends a <code>#repeaters</code> flood text message formatted as <code>&lt;node_name&gt;: &lt;message&gt;</code>, with <code>:</code> in the node name sent as <code>;</code>. <code>send text.flood &lt;message&gt;</code> <code>send text.flood checking ridge link</code>"},{"location":"halo_keymind_settings/#battery-alerts","title":"Battery Alerts","text":"<p>Battery alerts are off by default. Enabling requires a named region. With no region argument, the repeater selects the single deepest (most narrow) region in the hierarchy; if multiple regions tie, the command asks for an explicit region. For example, after <code>region def west pnw wa w-wa sea</code>, <code>set battery.alert on</code> selects <code>sea</code>, while <code>set battery.alert on w-wa</code> overrides the default. Alerts are never sent as unscoped floods, and removing the selected region stops alerts until a valid scope is selected again.</p> <p>The repeater suppresses alerts for its first 30 minutes of uptime. It then checks every 30 minutes and sends a flood text warning to <code>#repeaters</code> when voltage is above <code>1 V</code> and the estimated battery percent is below <code>battery.alert.low</code>.</p> <p>Warnings and critical alerts both use a <code>12</code>-hour resend cooldown, beginning only after the radio reports that the alert transmission completed.</p> <p>Defaults:</p> Setting Default <code>battery.alert</code> <code>off</code> <code>battery.alert.region</code> <code>&lt;unset&gt;</code> <code>battery.alert.low</code> <code>20</code> <code>battery.alert.critical</code> <code>10</code> <p>Example:</p> <pre><code>set battery.alert.low 20\nset battery.alert.critical 10\nset battery.alert on\nget battery.alert\nget battery.alert.region\n</code></pre> <p>CPU power saving remains compatible with the check. The battery timer never requests a wake earlier than its 30-minute deadline; when the normal loop is already awake after that deadline, no additional wake is needed. Sleeping time counts toward the startup delay, and an outbound warning prevents another sleep until the queued packet has been handled. This is separate from RX duty-cycle power saving, which only cycles the LoRa receiver and does not stop the main loop's battery timer.</p>"},{"location":"halo_keymind_settings/#recent-repeater-table","title":"Recent Repeater Table","text":"<p>Direct retry uses the recent repeater table when <code>direct.retry.heard</code> is <code>on</code>. Bridge buckets also use this table: a configured bucket prefix is active only when it was heard within the last hour.</p> <p>Show learned rows:</p> <pre><code>get recent.repeater\nget recent.repeater 2\nget recent.repeaters 2\nget recent.repeater page 3\nget recent.repeaters search A1\nget recent.repeaters search A1B2 page 2\n</code></pre> <p>Search matches overlapping 1-, 2-, and 3-byte path hashes. Each matching row shows its stored SNR and a whole <code>s</code>, <code>m</code>, or <code>h</code> age measured from the most recent recording. Search pages contain up to six rows.</p> <p>Seed or correct a prefix:</p> <pre><code>set recent.repeater A1B2C3 8.5\n</code></pre> <p>Clear learned and manually seeded rows:</p> <pre><code>clear recent.repeater\n</code></pre> <p>Rows are sorted by prefix width, then SNR. A full direct retry failure lowers the matching row by <code>0.25 dB</code>. Unfiltered paged replies contain up to <code>10</code> rows; an unpaged local serial query prints the full table.</p>"},{"location":"halo_keymind_settings/#direct-path-overrides","title":"Direct Path Overrides","text":"<p><code>outpath</code> and <code>altpath</code> apply to the current remote client ACL entry. They need remote client context, so they are not useful from the local serial CLI.</p> <p>Set paths with comma-separated hop hashes. Each hop must be <code>2</code>, <code>4</code>, or <code>6</code> hex characters, and all hops in one path must use the same width. Hex input is case-insensitive. Replies use uppercase hex and retain the commas, so the value can be copied directly into another <code>set outpath</code> or <code>set altpath</code> command.</p> <pre><code>get outpath\nget outpath path\nset outpath A1B2C3,D4E5F6\nset outpath path\nset outpath direct\nset outpath clear\nset outpath flood\nget altpath\nset altpath 71CE82,BA09F0\nset altpath clear\n</code></pre> <p>For example, both <code>set altpath 600000,0d2784,f8dada</code> and <code>Set altpath 600000,0d2784,f8dada</code> store the same path and reply with:</p> <pre><code>&gt; 600000,0D2784,F8DADA\n</code></pre> <p>The first CLI word is case-insensitive (<code>set</code>, <code>Set</code>, and <code>SET</code> are the same, as are <code>get</code>, <code>Get</code>, and the other command verbs). Argument case is preserved.</p> <p><code>get outpath path</code> reports the reciprocal path received after the latest flood login without changing <code>outpath</code>. That packet arrives asynchronously, so retry shortly if the first query reports <code>&gt; path pending</code>; the observation window expires after one minute. The login path is not automatically selected. <code>set outpath path</code> copies the observed route into <code>outpath</code> and saves it; it leaves the current route unchanged when no observed route is available.</p> <p><code>set outpath direct</code> sets a zero-hop direct route for a client reachable without repeaters. <code>set outpath clear</code> forgets the override, replies <code>&gt; outpath cleared</code>, and lets normal path discovery fill it again. <code>set outpath flood</code> forces replies to use flood packets until the client logs in again.</p> <p>When <code>outpath</code> is a valid direct path and <code>altpath</code> is also a valid, different direct path, repeater DM replies send two packets: one on <code>outpath</code> and one on <code>altpath</code>. The secondary <code>altpath</code> copy does not create its own direct-retry state, so retry tracking stays attached to the primary <code>outpath</code> packet. <code>altpath clear</code> disables the secondary direct reply. <code>altpath flood</code> is accepted for command symmetry, but it does not create a second flood reply; only a valid direct <code>altpath</code> sends the second packet.</p>"},{"location":"halo_keymind_settings/#direct-retry-settings","title":"Direct Retry Settings","text":"<p>Direct retry applies to direct-routed packets. A queued resend is canceled when the next-hop echo is heard. Repeaters expose the settings below; non-repeater firmware uses the same packet-type timing rules with fixed shared base/step timing.</p> Setting What it does How to use Example <code>retry.preset</code> Applies shared direct and flood retry defaults. Values: <code>infra</code>, <code>rooftop</code>, <code>mobile</code> or <code>0</code>, <code>1</code>, <code>2</code>. <code>get retry.preset</code>, <code>set retry.preset &lt;value&gt;</code> <code>set retry.preset rooftop</code> <code>direct.retry.heard</code> Uses the recent repeater table as the direct retry eligibility gate. <code>get direct.retry.heard</code>, <code>set direct.retry.heard on/off</code> <code>set direct.retry.heard on</code> <code>direct.retry.margin</code> SNR margin in dB above the SF-specific receive floor. <code>get direct.retry.margin</code>, <code>set direct.retry.margin &lt;0-40&gt;</code> <code>set direct.retry.margin 5</code> <code>direct.retry.count</code> Maximum direct retry attempts after initial TX. Direct-routed type 2 text packets always use 21 attempts regardless of this setting or the short-path cap. <code>get direct.retry.count</code>, <code>set direct.retry.count &lt;1-15&gt;</code> <code>set direct.retry.count 15</code> <code>direct.retry.base</code> Base wait in milliseconds before retry; packet-length add-on is 3x for TRACE and ANON_REQ/type 7, 7x for TXT_MSG/type 2, and 6x for other direct retry packets. <code>get direct.retry.base</code>, <code>set direct.retry.base &lt;10-5000&gt;</code> <code>set direct.retry.base 175</code> <code>direct.retry.step</code> Milliseconds added per retry attempt after the base, packet-length add-on, and random forwarding jitter. <code>get direct.retry.step</code>, <code>set direct.retry.step &lt;0-5000&gt;</code> <code>set direct.retry.step 100</code> <code>direct.retry.cr</code> Adaptive coding-rate thresholds for repeater direct retry packets. Repeaters use <code>CR4</code>, <code>CR5</code>, <code>CR7</code>, or <code>CR8</code>, then escalate by attempt: CR4, CR5, CR7, CR7, then CR8 from a CR4 start; CR5, CR7, CR7, then CR8 from a CR5 start. Non-repeaters start at the current radio CR and follow the same escalation pattern, clamped at CR8. <code>get direct.retry.cr</code>, <code>set direct.retry.cr &lt;cr4_min&gt;,&lt;cr5_min&gt;,&lt;cr7_min&gt;,&lt;cr8_max&gt;</code>, <code>set direct.retry.cr off</code> <code>set direct.retry.cr 10.0,7.5,2.5,0</code> <p>The default adaptive coding-rate profile is <code>10.0,7.5,2.5,2.5</code>. SNR <code>10.0 dB</code> and up uses <code>CR4</code>, <code>7.5 dB</code> and up uses <code>CR5</code>, <code>2.5 dB</code> and down uses <code>CR8</code>, and the middle band uses <code>CR7</code>. If no recent repeater table entry is available, retry packets use <code>CR5</code>. Use <code>set direct.retry.cr off</code> to disable adaptive coding-rate overrides. Repeater attempts escalate from the adaptive starting CR: <code>CR4</code>, <code>CR5</code>, <code>CR7</code>, <code>CR7</code>, then <code>CR8</code> from a <code>CR4</code> start; <code>CR5</code>, <code>CR7</code>, <code>CR7</code>, then <code>CR8</code> from a <code>CR5</code> start. Non-repeaters use the current radio CR as the first retry CR and follow the same pattern up to <code>CR8</code>.</p> <p>Preset details:</p> Preset Base Count Step SNR gate <code>infra</code> <code>275 ms</code> <code>4</code> <code>150 ms</code> SF floor + <code>15 dB</code> <code>rooftop</code> <code>175 ms</code> <code>15</code> <code>100 ms</code> SF floor + <code>5 dB</code> <code>mobile</code> <code>175 ms</code> <code>15</code> <code>50 ms</code> SF floor <p>Example for a quiet fixed repeater:</p> <pre><code>set retry.preset rooftop\nset direct.retry.heard on\nset direct.retry.margin 5\n</code></pre> <p>Example for a moving or weak-link node:</p> <pre><code>set retry.preset mobile\nset direct.retry.margin 0\n</code></pre>"},{"location":"halo_keymind_settings/#flood-and-advert-settings","title":"Flood And Advert Settings","text":"<p>Flood retry applies to flood-routed packets. A queued retry is canceled when the same packet is heard from a qualifying, non-ignored repeater. Bridge mode uses the bucket rules below instead.</p> Setting What it does How to use Example <code>flood.retry.count</code> Base flood retry attempts after initial TX. Role path scaling happens first, then all builds apply payload caps: <code>REQ</code> is <code>0</code>; <code>GRP_TXT</code> keeps up to <code>15</code>; remote-login <code>RESPONSE</code>, <code>TXT_MSG</code>, <code>ANON_REQ</code>, and <code>PATH</code> keep up to <code>15</code> at path count 0 and cap at <code>2</code> in transit; every other flood type caps at <code>1</code>. A lower calculated value is preserved, and <code>0</code> disables flood retry. <code>get flood.retry.count</code>, <code>set flood.retry.count &lt;0-15&gt;</code> <code>set flood.retry.count 7</code> <code>flood.retry.path</code> Maximum path hash count eligible for flood retry, or <code>off</code> to disable the gate. <code>get flood.retry.path</code>, <code>set flood.retry.path &lt;0-63/off&gt;</code> <code>set flood.retry.path 1</code> <code>flood.retry.group.path</code> Additional path gate for group data (<code>type=6</code>) flood retries. The stricter of this and <code>flood.retry.path</code> applies; <code>off</code> disables only this additional gate. Setting the general path gate to <code>0</code> forces this setting to <code>off</code>; a named preset restores the default of <code>1</code>. <code>get flood.retry.group.path</code>, <code>set flood.retry.group.path &lt;0-63/off&gt;</code> <code>set flood.retry.group.path 1</code> <code>flood.retry.advert</code> Allows or blocks retry for node advert packets (<code>type=4</code>). Default is <code>off</code>. <code>get flood.retry.advert</code>, <code>set flood.retry.advert on/off</code> <code>set flood.retry.advert off</code> <code>flood.retry.prefixes</code> Target prefixes. If set, only same-packet echoes from matching last-hop prefixes cancel a retry. <code>get flood.retry.prefixes</code>, <code>set flood.retry.prefixes &lt;prefixes/none/off&gt;</code> <code>set flood.retry.prefixes BEEBB0,425E5C</code> <code>flood.retry.ignore</code> Ignored prefixes. In non-bridge retry, ignored last-hop echoes do not cancel retry. <code>get flood.retry.ignore</code>, <code>set flood.retry.ignore &lt;prefixes/none/off&gt;</code> <code>set flood.retry.ignore 71CE82,C7618C</code> <code>flood.retry.bridge</code> Enables bucket-based bridge retry logic. <code>get flood.retry.bridge</code>, <code>set flood.retry.bridge on/off</code> <code>set flood.retry.bridge on</code> <code>flood.retry.bucket.&lt;n&gt;</code> Shows one bridge bucket. Buckets are numbered <code>1</code>-<code>6</code>. <code>get flood.retry.bucket.&lt;n&gt;</code> <code>get flood.retry.bucket.1</code> <code>flood.retry.bucket</code> Sets bridge bucket prefixes. <code>set flood.retry.bucket &lt;1-6&gt; &lt;prefixes/none/off&gt;</code> <code>set flood.retry.bucket 1 71CE82,C7618C</code> <p>Extended <code>flood.rule</code> rows can select which received floods may use these settings. For example, enable bridge completion only for Public and <code>#hamradio</code> with <code>set flood.rule type=any channel=public retry</code> and a second row using <code>channel=#hamradio</code>. Adding the first active <code>retry</code> row changes received retry selection into an allow-list; deleting the last restores the legacy global selection. <code>channel=hash:XX</code> is available when only the visible one-byte hash is known, but it is not authenticated and is collision-prone. For example, <code>hash:11</code> includes Public and any other packet using <code>0x11</code>; <code>channel=public</code> alone performs the Public-key MAC/decrypt check.</p> <p>Bridge buckets may also be reused as passive <code>flood.channel.scope</code> path selectors with <code>path=bucket:&lt;1-6&gt;</code>. This does not require <code>flood.retry.bridge</code> to be enabled and does not depend on recent-repeater freshness or the retry ignore list.</p> <p>Forwarded neighbor adverts also use an automatic echo guard in every build. If this node hears a downstream, longer-path echo after transmitting an advert whose signed timestamp is less than six hours old, it will not forward that exact advert again during the six-hour age window. This guard works even when <code>flood.retry.advert</code> is off and does not affect self-originated adverts.</p> <p>Self-originated advert retries are deliberately slow: the first retry waits at least one extra minute beyond the normal airtime-aware delay. Queueing a newer self advert retires queued and future retry attempts for older self adverts without disturbing other flood retry sequences. Companion firmware allows the one slow retry for its own adverts but not for neighbor adverts it relays.</p> <p>The shared retry preset sets these flood defaults:</p> Preset Retry count Path gate Group-data path gate <code>infra</code> <code>1</code> <code>1</code> <code>1</code> <code>rooftop</code> <code>3</code> <code>2</code> <code>1</code> <code>mobile</code> <code>15</code> <code>1</code> <code>1</code> <p>Example for path-gated retry:</p> <pre><code>set retry.preset rooftop\nset flood.retry.path 1\nset flood.retry.group.path 1\nset flood.retry.advert off\nset flood.retry.ignore 71CE82,C7618C\n</code></pre>"},{"location":"halo_keymind_settings/#north-south-buckets","title":"North South Buckets","text":"<p>Buckets describe groups of repeaters on different sides of this relay. Bucket numbers do not have built-in meanings; this example uses bucket <code>1</code> for North and bucket <code>2</code> for South.</p> <pre><code>              North bucket 1\n        +-----------------------+\n        | A1B2C3       D4E5F6   |\n        | North A      North B  |\n        +-----------+-----------+\n                    |\n                    v\n              +-----------+\n              | This node |\n              +-----------+\n                    ^\n                    |\n        +-----------+-----------+\n        | 71CE82       C7618C   |\n        | South A      South B  |\n        +-----------------------+\n              South bucket 2\n</code></pre> <p>Configure the buckets:</p> <pre><code>set flood.retry.bridge on\nset flood.retry.bucket 1 A1B2C3,D4E5F6\nset flood.retry.bucket 2 71CE82,C7618C\nset flood.retry.ignore none\n</code></pre> <p>Packet heard from the North:</p> <pre><code>     heard source\n         |\n         v\n  +--------------+        retry targets\n  | North bucket | -----&gt; South bucket\n  | bucket 1     | -----&gt; Other fresh/unbucketed relays\n  +--------------+\n</code></pre> <p>Packet heard from the South:</p> <pre><code>     heard source\n         |\n         v\n  +--------------+        retry targets\n  | South bucket | -----&gt; North bucket\n  | bucket 2     | -----&gt; Other fresh/unbucketed relays\n  +--------------+\n</code></pre> <p>Packet heard from an unbucketed or pathless source:</p> <pre><code>     heard source\n         |\n         v\n  +--------------+        retry targets\n  | Other bucket | -----&gt; North bucket\n  | implicit     | -----&gt; South bucket\n  +--------------+\n</code></pre> <p>Bridge retry stays eligible until every target bucket has been heard or <code>flood.retry.count</code> is exhausted. A configured bucket is a target only when at least one of its prefixes is fresh in <code>recent.repeater</code>. Prefixes in <code>flood.retry.ignore</code> never count as bucket hits.</p> <p>Configuration reports a warning when prefixes in different buckets, including bucket 7 (<code>flood.retry.prefixes</code>), share the same first byte. A 1-byte path cannot distinguish those buckets. Bridge mode therefore excludes every matching bucket when that short prefix is the source, and credits every matching target bucket when it is heard as an echo. This prevents an ambiguous short prefix from keeping an impossible target outstanding through every retry.</p> <p>Each flood retry wait retains the fixed maximum-frame plus 20 packet-airtime delay, then adds random jitter from zero to 200 percent of one additional packet airtime. This keeps nearby repeaters from repeating a collision on fixed timing while capping the added wait at two frames.</p> <p>Only one enhanced retry sequence can be active for the same logical flood packet. Identical floods still receive their normal transmission, but do not multiply the extra attempts. Evicted queued retries release their bridge state, and the final echo wait does not reserve a packet-pool entry.</p> <p>Earlier path hops from a successful bridge echo refresh a separate per-bucket reachability cache without an SNR value. Only the final hop, which actually sent the received RF frame, updates <code>recent.repeater</code> and its SNR. Indirect path hops therefore cannot change direct-retry SNR gating or coding-rate selection.</p>"},{"location":"halo_keymind_settings/#troubleshooting","title":"Troubleshooting","text":"<p>If advert packets are still retrying:</p> <pre><code>get flood.retry.advert\nset flood.retry.advert off\n</code></pre> <p>If ignored prefixes still appear in <code>flood retry good</code> logs:</p> <pre><code>get flood.retry.ignore\nset flood.retry.ignore &lt;prefix&gt;\n</code></pre> <p>The ignored prefix must match the last hop shown as <code>heard=&lt;prefix&gt;</code>. For example, this log needs <code>C7618C</code> in the ignore list:</p> <pre><code>flood retry good (... path=7773D0&gt;C7618C, heard=C7618C ...)\n</code></pre> <p>If retries are too aggressive:</p> <pre><code>set flood.retry.count 1\nset flood.retry.path 1\nset direct.retry.count 4\n</code></pre> <p>If retries are too sparse:</p> <pre><code>set flood.retry.count 7\nset flood.retry.path 2\n</code></pre>"},{"location":"hardware_validation_checklist/","title":"Hardware validation checklist","text":"<p>Use this checklist for release-candidate hardware runs. A check is complete only when its log identifies the physical device, firmware artifact, artifact hash, command result, and cold/warm boot outcome. Do not infer success from a tool's exit code when the tool has a documented false-success mode.</p>"},{"location":"hardware_validation_checklist/#current-marathon-ledger-through-2026-09-04","title":"Current marathon ledger (through 2026-09-04)","text":"Hardware Stable identity Current state Next blocking check Seeed XIAO nRF52840 <code>B35E71C1C3726CE7</code> OTAFIX candidate <code>0x02040405</code> passed exact serial install and corrected Legacy DIS model gates; the patched Bluetooth repeater-updater application was restored over BLE and returned as exact <code>2886:8044</code> USB Use the updater for an identity-gated Bluetooth transfer to another repeater, then prove current-build cold persistence Seeed Tracker T1000-E <code>34A9141999729D5D</code> OTAFIX candidate <code>0x02040405</code> and the <code>uf2reset</code>-fixed Full Companion are installed. The real text command returned exact <code>2886:0057</code> boot USB, the same fixed app was restored, and refreshed bonded BLE services pass as <code>MeshCore-09848C15</code> Restore the protected Repeater identity when Companion qualification is complete; cold boot, then force LR1110 reset RAK3401 <code>0B81C9C68D8D01B4</code>; FICR <code>8D8D01B4 0B81C9C6</code> OTAFIX test version <code>0x02040403</code> passes bidirectional application UF2, exact SWD application/bootloader readback, unchanged UICR, and a 74-block direct V4 LoRa apply from exact <code>3caf9dcf</code> to current HEAD <code>9fd580c8</code>. Post-apply USB and LoRa identity/hash checks pass and the temporary 0 dBm bench setting is restored to 22 dBm Add exact RF packet counters, then repeat the supported-bandwidth and controlled/passive/mixed routed-hop matrix Heltec T096 <code>651F8E496197F882</code> OTAFIX candidate <code>0x02040405</code> and the <code>uf2reset</code>-fixed no-footer Full Companion are installed. The real text command returned exact boot USB, and final USB terminal/Binary mode, dual CDC, version, help, and BLE identity pass Perform a privileged or physical host-driven USB bus reset without resetting the MCU; complete the deferred multi-click/long-press physical matrix Heltec MeshTower V2 with SD <code>9352162A72082314</code> OTAFIX candidate <code>0x02040405</code> passed serial combined install, the historical cached DIS handles, BLE application restore, and exact application USB return. Card format/cooldown/forced-format/raw-erase/remount and the live SD apply contract passed earlier Signed interrupted-download resume, corruption/signature rejection, then full/delta apply Heltec V4 USB MAC <code>44:1B:F6:6A:E8:44</code>; BLE <code>44:1B:F6:6A:E8:45</code> USB/BLE/Wi-Fi and all three TCP services pass on hardware. The final fresh-NTP-gated Full Companion image builds with 4.31 MB app space free Flash the exact final NTP build, prove NTP-before-TLS success/failure ordering, then OTA seeding SenseCAP Indicator LoRa CH340 plus USB MAC <code>D8:3B:DA:75:23:AC</code>; BLE <code>D8:3B:DA:75:23:AD</code> The current dark-layout application is SHA-256 <code>81bebdc07b6a8349c1c975cb5a0e30c5f6019d35bcac641e5f3d4df951f7406b</code>; identity-gated flash, USB ASCII/Binary switching, runtime logging, and separate configured-Wi-Fi, BLE, and TCP checks pass. Fresh-NTP HTTPS recovery, strict Range resume, STAGEV2 install, and RP USB readback passed on earlier exact artifacts; the final coordinator source still needs its blocked-UDP/123 hardware gate Physical display-wrap and four-mode render/heap checks, exact-final blocked-NTP recovery gate, LoRa/TempRadio, and non-empty OTA seeding <p>The current source checkpoint passes 1,132/1,132 native cases, 68/68 host broker/endpoint cases, all 318 LoRa-OTA chain/route/bundle cases, and 41/41 MOTA format/signature/delta cases under the documented pipx <code>detools</code> interpreter. Indicator geometry, dark-theme, and font-recovery contracts pass 4/4, 6/6, and 25/25. A serialized real Indicator ESP32-S3 Wi-Fi/USB profile also compiles at 95,944 bytes RAM and 1,589,433 bytes flash. The direct system-Python MOTA invocation predictably lacks <code>detools</code>; that environment boundary is not a firmware failure and must not be worked around by installing the package globally.</p> <p>The RAK failure log is <code>/home/mikec/hwtest/runs/rak3401-syncidle-clean-tSp7PLgA/result.txt</code> on the Mercerwood Pi. The tested UF2 SHA-256 was <code>650c9fda456685cdf99c1f2996c60f1f551cc9216d2b746a22c8cb78464b0ff7</code>. <code>cp</code> returned success in 95 ms, but <code>sync -f</code> failed with <code>EIO</code> after 157,188 ms. Post-failure SWD readback proved that all seven ordinary sectors whose bytes differed between the old and intended builds still contained the old values, and the settings page was still erased. The only available pre-copy SWD dump was taken several hours earlier, however, so it cannot prove that zero unchanged blocks were written during this attempt or establish when the stale S140-v7 tail in the first application page appeared. The next run must capture an immediate pre-copy dump as well as the post-copy dump. Serial DFU recovery then completed in 35,698 ms with the exact <code>Device programmed.</code> marker. All 1,830 UF2 payload blocks matched SWD readback after recovery, and the application passed a subsequent real power-removal boot.</p> <p>The corrected 2.4.4-preview.2 candidate was installed through identity-gated SWD from combined-image SHA-256 <code>9b1654baccd2a920f68651893e31d79170400d1a7982a3f854ae640f1d3513a8</code>. An immediate pre-copy dump closed the earlier evidence gap. A deliberately old UF2 then copied and flushed successfully in 16,568 ms, and the exact formerly failing UF2 above copied and flushed successfully in 16,601 ms. After each direction, all 1,830 payload blocks matched a full SWD readback with zero header or payload mismatches. The return update changed 123 bytes across five expected application pages, UICR remained byte-identical, and a subsequent downstream USB power removal plus Pi reboot returned the RAK as the same stable identity. It reported the intended <code>3caf9dcf</code> application, board, node name, USA radio tuple, and 22 dBm setting after that cold boot. The new bootloader's CLI source string is truncated before the injected preview number, so the independently hashed SWD artifact is the authoritative candidate identity for this run.</p> <p>The later TinyUSB lifecycle/generation candidate identifies itself as test version <code>0x02040403</code>. Its exact 40,960-byte bootloader readback SHA-256 is <code>f609eb18754070c54f127325b1cb48547baf5c6b1c695d36fd0c8e0874713c13</code>. With that candidate installed, a full <code>CURRENT.UF2</code> read completed before each write. The 936,960-byte <code>bf092b24</code> application UF2 (SHA-256 <code>12477a9734cf12eb920361bd21024e39bf303953fcf79d0bf720e00847e2ae92</code>) copied and flushed in 28,203 ms and returned to application mode four seconds later. The exact <code>3caf9dcf</code> application UF2 (SHA-256 <code>650c9fda456685cdf99c1f2996c60f1f551cc9216d2b746a22c8cb78464b0ff7</code>) then copied and flushed in 26,479 ms and also returned in four seconds. Both boots retained <code>RAK3401-OTA-BENCH</code> and <code>910.525/62.5/SF7/CR5</code>.</p> <p>Identity-gated SWD then read the entire 468,480-byte padded UF2 application range. Its SHA-256 exactly matched the converted source on both sides at <code>b2e37a7681027ca91d1b2bd8e39b55395d9e91d4863aed17131e50c1ba1d2227</code>. The bootloader still matched the installed <code>0x02040403</code> image byte-for-byte, and UICR still matched the pre-test image at <code>d029ea630c2f632a1b690cb52b2a96a28b6f870c656c3e1bd74ba3a571c53b9c</code>. The authoritative logs are under <code>/home/mikec/hwtest/runs/rak3401-uf2-02040403-20260830-170829</code> and <code>/home/mikec/hwtest/runs/rak3401-uf2-return-02040403-sfHiGEqA</code> on Mercerwood.</p> <p>The subsequent direct LoRa qualification used the V4 as controller/seeder and the RAK's exact <code>bf092b24</code> body <code>91CF4EC2882F23D6</code> as the base. Its mandatory fixed three-minute rehearsal passed on <code>909.95/250/SF5/CR5</code>, including natural expiry and exact normal-radio recovery. The 2,132-byte, two-block in-place delta reached <code>2/2</code> and ready in six seconds; install was accepted, and the new body appeared at the 60-second reboot probe. The automation took 514 seconds including rehearsal, clock/radio safety checks, and post-install verification. The final body was <code>27A223DDFC3A8F47</code>, version <code>1.17.1.5</code> at <code>3caf9dcf</code>, and the bootloader reported <code>blrc:B8</code>, which is OTAFIX's successful application apply result rather than an error. Exact target TX power was wrapped from 22 dBm to 0 dBm for the co-located transfer and restored to 22 dBm afterward; the source RXPS configuration and both normal radio tuples were also restored.</p> <p>Identity-gated SWD then read the live application at <code>0x26000</code>. All 468,384 bytes matched the intended release image exactly (SHA-256 <code>b496e3f4419c9f771564ed3c74b3407822f45acdf60cbd6c4625a54b181ca084</code>), and the independently recomputed EndF hash was <code>27A223DDFC3A8F47</code>. The target ID was <code>2FA509C1</code>, hardware ID was <code>RAK_3401</code>, and version word decoded to <code>1.17.1.5</code>. The 40,024-byte bootloader readback also matched the exact installed <code>ffb1580</code>/test-version-<code>0x02040402</code> artifact byte-for-byte; UICR was unchanged. After SWD reset-halt/resume, USB again reported the expected application, identity, name, radio, 22 dBm, no TempRadio lease, and <code>blrc:00</code> (the retained success diagnostic is intentionally cleared by the next normal boot).</p> <p>The current <code>0x02040403</code> bootloader candidate then passed a second direct V4 LoRa qualification using a materially larger application change. The unsigned in-place package was 75,614 bytes with 75,108 payload bytes and 74 transfer blocks. Its mandatory fixed three-minute rehearsal passed, including natural TempRadio expiry and exact normal-channel recovery; one lost read-only <code>ota status</code> reply was reconciled by its bounded exact retry. The transfer reached 74/74 and READY in 122 seconds, the explicit unsigned install was accepted, and reboot produced exact HEAD <code>9fd580c8</code> with body <code>744BC4443891ED10</code>. The complete safety-wrapped run took 589.487 seconds, including rehearsal, recovery, and final verification. The first postboot <code>ver</code> reply was lost and its exact read-only retry passed. Independent USB checks then confirmed target <code>2FA509C1</code>, hardware <code>RAK_3401</code>, unchanged identity/name/radio/RXPS/watchdog state, bootloader CRC <code>6683C066</code>, ABI 3, apply result <code>blrc:B8</code>, and no active TempRadio/download/seeder/key state. After the separate host-recovery exercise, the near-field TX setting was restored from 0 dBm to its exact original 22 dBm and read back over an authenticated LoRa session. The sanitized authoritative log is <code>/home/mikec/hwtest/runs/rak3401-02040403-head-vzWOXVxT/qualification-redacted.log</code> with SHA-256 <code>3e53dcaa5922c7c18a7890963b8fc092311d2db01caa5603640f43f1482802f6</code>.</p> <p>A serialized VM build of the six connected-board qualification profiles then completed 6/6 in 136.122 seconds: XIAO nRF52 BLE Companion, T1000-E BLE Companion, RAK3401 LoRa-OTA Repeater, SenseCAP Indicator LoRa USB/Wi-Fi Companion, MeshTower V2 SD LoRa-OTA Repeater, and the consolidated Heltec V4 V4.2/V4.3 Full Companion. The earlier V4 selector typo was rejected before any compile began and is not a firmware build failure.</p> <p>After the fresh-NTP download gate, shared SNTP coordinator, MQTT-to-MeshCore RTC handoff, and daily refresh policy were added, the complete native matrix passed 1,102/1,102 cases in 93.953 seconds. The scheduler is host-tested at 24-hours-minus-one-millisecond, the exact 24-hour boundary, normal and wrapped <code>millis()</code> values, a short retry that overrides the daily cadence, the zero deadline sentinel, and a Wi-Fi event latch. A reconnect after a successful sample preserves the existing deadline, so successful samples are requested after boot and then only once per day. All current Python and shell contract suites passed, and the expanded LoRa-OTA automation suite passed 317/317 cases.</p> <p>Serialized real builds also passed after that change. The final event-safe implementation uses an atomic <code>GOT_IP</code> latch so even a short initial connection before the 10-second MQTT status sample cannot skip the required boot NTP request. The final Heltec V4 MQTT Observer application is 1,853,304 bytes with SHA-256 <code>1938ae88fcdbe601cf8698df44b548656079562d899801886b808af913e5f9ac</code>. The consolidated Full V4 image used 2,250,801/6,553,600 flash bytes and left 4,302,799 bytes of app-image space. Its 2,251,272-byte application image has SHA-256 <code>05131eac29164be46d1bcceeb4f03455f5ea8d61c8d4f529b77d8adfe25fdb6a</code>; the 2,316,808-byte merged image has SHA-256 <code>c4c1fc639b6d0087c795a81aca79c07eba56dc4e071eb374dc70da0bec81815e</code>. The focused daily-NTP policy suites passed all 42 cases after the latch was added, and the Full capability manifest verified all ten expected features. The reduced RAK3401 LoRa-OTA Repeater also compiled with the verified WisBlock I2C aliases. At that source state its link used 471,344/815,104 flash bytes; the reduced external-sensor contract retains INA219/INA226/INA260/INA3221 as the voltage/current entries in the optional environmental-telemetry table. These are not the image's only I2C consumers. The image separately retains its SSD1306 display, auto-discovered I2C RTCs, RAK12500 I2C GPS, and RAK12501/L76K UART GPS paths. The configured INA3221 and RAK12500 both default to I2C address <code>0x42</code>; those two devices cannot coexist at those addresses. The supported combined arrangement leaves RAK12500 at <code>0x42</code>, straps INA3221 A0 to SCL for <code>0x43</code>, and uses a build with <code>-DTELEM_INA3221_ADDRESS=0x43</code>. The nRF52840 die-temperature and ADC battery-voltage paths are also retained. The 472,227-byte DFU ZIP SHA-256 is <code>fdd369005a61635756efa9e38b217376a952f334b0864f927a46799b65264fa9</code>, and the matching 943,104-byte UF2 SHA-256 is <code>2155632fde730e0ae2e4a72ce64f89910861f6c5105a4bd7ac96aaa538a33dca</code>. These VM results do not replace the remaining exact-final hardware test with UDP/123 blocked.</p> <p>The later serialized RAK3401 contract build, after the non-blocking nRF52 USB logging change, used 471,576 bytes before its 56-byte EndF trailer. Its EndF body hash is <code>026749684bf6ee8f</code>, target ID is <code>2FA509C1</code>, hardware ID is <code>RAK_3401</code>, and version word is <code>0x01110105</code>. The 472,435-byte DFU ZIP has SHA-256 <code>cf0880b26f2d6bd8157f8af76a6718fe1f998de8ea7df8cd952e734448201fb9</code>; the 943,616-byte UF2 has SHA-256 <code>f893a8cebf309af12a4a6f5483acb28f94158e18632f660e011658c846e8ca7f</code>. The linked ELF contains GPS, SSD1306, RTC, and the four INA families, while an exact symbol audit finds none of AHT10/20, BME280, BMP280, SHTC3, SHT4X, LPS22HB, MLX90614, VL53L0X, BME680/BSEC, BMP085, or RAK12035. The complete native matrix passed 1,112/1,112 cases at that intermediate source state. These are VM gates only; flash the exact artifacts and repeat the physical peripheral and blocked-clock checks before marking any later source state hardware-qualified.</p> <p>Subsequent source hardening changed RAK peripheral discovery: the shared 3V3_S rail remains enabled, UART GPS requires a complete checksum-valid NMEA sentence, an exact INA3221 identity blocks a conflicting u-blox probe, and a successful I2C GPS claim suppresses a sensor only on the same bus and address. The hashes and sizes above describe their recorded intermediate artifacts; they are not current-HEAD evidence and must not be reused for the hardened source.</p> <p>The immutable font endpoint was re-probed only after the VM reported <code>NTPSynchronized=yes</code>. GitHub returned HTTP 206 for bytes <code>0-65535</code>, an exact 65,536-byte match to the checked-in font (range SHA-256 <code>8b0dd308eb01469d1f9e732fba260720a80cc86f6cb5385c28e8a16c76dcfbf3</code>), with total length 1,302,608 and strong ETag <code>\"39ff0cfbe37e36905507697d042869c05374c3202dd96d5a9f98812153f324c1\"</code>. This validates the current strict Range assumptions against the live service; the exact-final Indicator still needs the negative hardware run proving that blocked UDP/123 prevents every TLS request and RP2040 staging write.</p> <p>Mercerwood subsequently recovered without a target write. Both its Tailscale and LAN addresses again accepted SSH, Bluetooth was idle, and the exact T1000-E stable serial <code>34A9141999729D5D</code> was present as application USB <code>239a:8029</code>. The RAK3401 simultaneously uses the same VID/PID, which confirms that every continuation must resolve the stable serial/by-id identity rather than VID/PID. The T1000-E remained in the exact bonded Full Companion application; no stale DFU, scanner, <code>meshcli</code>, or HCI-capture process was running.</p> <p>The post-reboot seven-TTY inventory was also resolved without assuming that one board owned adjacent device names. <code>ttyUSB0</code> is the SenseCAP Indicator's ESP32-S3 CH340 UART and <code>ttyACM5</code> is its RP2040; their sibling physical USB paths and the Indicator's live TCP board reply agree. The separately attached <code>ttyACM4</code> is the MeshTower V2 native <code>HT-n5262</code> endpoint and returned the qualified MeshTower build over its own console. The remaining ACM endpoints independently identify the RAK3401, XIAO nRF52840, Heltec V4, and T1000-E.</p> <p>ModemManager had restarted after the Pi reboot and could probe otherwise idle radio consoles. Six serial-bearing boards now use stable-serial-only <code>ID_MM_DEVICE_IGNORE</code> rules. Because the Indicator CH340 has no stable serial, its separate rule requires the exact current physical port chain and exact <code>1a86:7523</code> identity; there is no broad CH340, product, or VID/PID-only rule. A controlled ModemManager restart reported zero modems, displaced no TTY owner, caused no USB disconnect/re-enumeration, and left all seven endpoints ignored. The same mctomqtt process retained sole ownership of the RAK, while a subsequent Indicator TCP query still returned the expected board and build. Reversible root-only backups were retained on the Pi before each rule update.</p>"},{"location":"hardware_validation_checklist/#run-wide-gates","title":"Run-wide gates","text":"<ul> <li>[ ] Record commit, version string, role/profile, artifact filename, size, and       SHA-256 before flashing.</li> <li>[ ] Archive the exact ELF and symbol/objdump map beside each qualification       firmware. A rebuilt ELF is acceptable for diagnosis only after its       firmware binary matches byte-for-byte; compiler <code>__DATE__</code>/<code>__TIME__</code>       strings can otherwise change both bytes and the EndF body hash.</li> <li>[ ] Bind every operation to a stable USB serial number or physical USB path;       never rely on a changing <code>ttyACM</code>/<code>ttyUSB</code> number.</li> <li>[ ] After erasing/reflashing a BLE board that reuses its Bluetooth address,       remove any stale host bond and pair again with the board's current PIN       before diagnosing service-discovery disconnects. On Linux, verify the       BlueZ agent actually accepted the passkey; a scanner seeing the device is       not proof that Companion GATT is usable.</li> <li>[ ] Do not use BlueZ's advertisement <code>service_uuids</code> as a same-address warm       handoff identity gate. After application/bootloader transitions BlueZ can       merge the bootloader's cached GATT UUIDs into the live application's       advertisement. Gate the application advertisement by exact address and       name, then require the live connected BLEDfu service, control/revision       characteristics, retained bond/encryption, notification subscription,       and observed target disconnect before accepting the handoff.</li> <li>[ ] Do not treat <code>meshcli -P</code> as an infallible pairing probe. Immediately       after one successful post-DFU session, a second invocation with the exact       paired XIAO address hit the meshcore-cli <code>NoneType ... pair/disconnect</code>       path before it created a Bleak client. BlueZ still reported the exact       bond and the same command without <code>-P</code> connected and synchronized the       clock successfully. Capture this as a host-tool failure, then verify the       device independently before blaming firmware.</li> <li>[ ] After a successful <code>BleakClient.connect()</code>, start a fresh disconnect       generation before beginning DFU. BlueZ can fail one internal LE attempt,       retry successfully, and still deliver the failed attempt's callback. A       stale event caused the host to stop notifications and issue a local HCI       disconnect after a valid image CRC but before ACTIVATE; the target and       bootloader had not dropped the link. Preserve an HCI trace through       activation so local-host and remote-target disconnects remain       distinguishable.</li> <li>[ ] Before a BLE pairing/throughput test on a Wi-Fi-managed Pi, record both       management addresses and a same-LAN recovery vantage point. The XIAO       pairing run completed, but Mercerwood then stopped answering on both its       Wi-Fi and Tailscale addresses; BellevueBBS confirmed the old LAN address       was absent at ARP and no replacement LAN host exposed SSH. This is an       infrastructure outage until Pi logs prove a cause, not a firmware or BLE       failure. The T1000-E pairing run reproduced the management outage: its       exact application paired successfully and exposed the complete DFU       service, then Mercerwood stopped accepting SSH and ultimately stopped       answering Tailscale pings. No buttonless DFU write had been sent, and the       T1000 remained in its valid application. Capture Pi Wi-Fi/firmware logs       after recovery and avoid leaving discovery enabled between operations.</li> <li>[ ] Confirm the selected board and role before every erase or flash.</li> <li>[ ] Before every SWD write, read the target FICR device ID and match it to the       intended board's stable USB serial (and physical wiring record). A USB       product name or remembered cable position is not sufficient.</li> <li>[ ] Confirm no other PlatformIO process is active; run only one PlatformIO       build, test, clean, or upload at a time.</li> <li>[ ] Record the installed bootloader, SoftDevice, partition table, or flash       layout independently of the application banner where applicable.</li> <li>[ ] Test both a software reboot and a real power removal/cold boot.</li> <li>[ ] After an update, read back identity, version, radio tuple, node name, and       persistent settings instead of assuming they survived.</li> <li>[ ] Save command output and elapsed milliseconds. Mark a test <code>FAIL</code>, not       <code>PASS</code>, if the transport reports an I/O error even when firmware later       boots.</li> <li>[ ] Before calling a node hung, validate that the probe uses that profile's       command terminator, check a second transport, and capture PC/LR/watchdog       state over identity-gated SWD before reset. Resume once and retest before       using reset as recovery so the diagnostic state is not destroyed first.</li> <li>[ ] Treat a remote login acknowledgement and the following command reply as       separate LoRa packets. A lost login acknowledgement is not proof of       failed authentication when a command-matched private reply from the       selected contact key is present; an explicit negative login result still       fails closed.</li> <li>[ ] Restore the intended USA radio preset and normal-radio mode after tests.</li> <li>[ ] Compare both semantic version and exact EndF/body hash. A transition       between two commits carrying the same version string must stop at the       normal reinstall guard unless the run plan explicitly records and passes       <code>--allow-non-upgrade</code>; a different commit name alone is not authorization.</li> <li>[ ] Do not allow a non-interactive transmission-failure prompt to continue       retry cycles forever. Optional capability probes must fail/fall back after       a bounded interval, while mutations and cleanup retain their stronger       bounded-lease recovery rules.</li> <li>[ ] Before the first remote command after any controller/source reboot, read       its RTC and compare it with a trusted host clock. Advance a clock which is       behind and prove readback; never move a radio clock backward. Fail closed       when it is more than 10 minutes ahead. During the RAK rehearsal the V4       rebooted to <code>2026-03-01</code> while the RAK remained at <code>2026-08-30</code>; the RAK       received the direct packets but correctly rejected their old timestamps       as replays. Setting the V4 to host epoch immediately restored login and       the exact public-key reply at SNR -1.5 dB.</li> <li>[ ] Before every external HTTPS download, require a fresh SNTP response for       that bounded operation, a plausible signed wall clock, connected Wi-Fi,       and a non-expired proof immediately before opening TLS. Re-check the proof       before every resumed/Range TLS connection. A retained plausible RTC or       mesh time is not a substitute for observing NTP, and failure must occur       before any HTTP request body or flash writer begins.</li> <li>[ ] Treat an unacknowledged immediate <code>tempradio</code> mutation as potentially       active, not merely lost. On the tested repeater, scheduled-radio expiry       deliberately waits for <code>hasOutbound()</code> to clear; a CLI reply stranded on       the temporary tuple can therefore hold the node there beyond its nominal       lease. Prefer one fixed absolute <code>tempradioat</code> window per node, so duplicate       delivery cannot extend it, and prove the return on both tuples before a       transfer. If recovering an older immediate handoff, join the exact       temporary tuple to drain the reply before issuing <code>normalradio</code>.</li> <li>[ ] Do not diagnose a co-located high-power LoRa bench failure as weak RF       without an overdrive check. On the RAK3401/V4 bench, the RAK at 22 dBm       produced only 3/6 status replies around -1.5 dB SNR, while a reversible       0 dBm setting produced 6/6 replies in 5--8 seconds at +12 to +12.5 dB       SNR. Read the original power, lower it only for the near-field test, and       require exact restoration afterward.</li> </ul>"},{"location":"hardware_validation_checklist/#compute-placement-gate","title":"Compute-placement gate","text":"<ul> <li>[ ] Run firmware builds, PlatformIO, mOTA/delta generation, compression,       full-image hashing sweeps, symbol generation, and other sustained CPU or       memory work on the VM. Do not offload these jobs to a Pi merely because       the hardware and source artifacts are attached there.</li> <li>[ ] Use the Mercerwood Pi as the identity-gated hardware gateway, SWD/USB/BLE       test host, and LoRa/Wi-Fi seeder. Copy only the completed artifact plus       its manifest/hash to the Pi, then verify the copied SHA-256 before use.</li> <li>[ ] Run CPU work on a Pi only when Pi performance or deployment behavior is       itself the test subject, and label that exception in the run log.</li> <li>[ ] Do not assume a non-interactive SSH session has the same <code>PATH</code> as an       interactive shell. Resolve pipx-installed tools such as esptool and       detools to their explicit venv path, record the version, and fail before       erase if the pinned executable is unavailable.</li> <li>[ ] Treat short serial/BLE/SWD control scripts on the Pi as hardware I/O, not       as permission to generate artifacts there. Use the explicit Python from       the relevant pipx environment when a probe needs one of its dependencies;       the Pi system Python did not contain <code>pyserial</code> during the RAK run.</li> </ul>"},{"location":"hardware_validation_checklist/#lora-controlled-host-recovery-gate","title":"LoRa-controlled host recovery gate","text":"<ul> <li>[x] The privileged recovery boundary is a root-owned, group-restricted       AF_UNIX broker with a fixed command grammar and fixed <code>systemctl</code> argv.       The unprivileged MQTT endpoint cannot gain privileges under       <code>NoNewPrivileges</code>, cannot select an executable or unit, and commits an       action only after its signed challenge/reply has been published and       confirmed. The installed broker passed its cold activation, peer       credential, socket owner/mode, injection, duplicate, timeout, durable       reservation, and ambiguous-outcome checks.</li> <li>[x] A signed <code>host network restart</code> was accepted exactly once in 4.088       seconds. The broker retained one <code>network-restart</code> record at sequence 1,       and the fixed unit journal had exactly one start/finish pair. Independent       management probing measured 7.184 seconds from last successful probe to       first recovered success and 6.314 seconds from first failure to recovery.       Pi-local loopback MQTT delivered 107/107 samples; mosquitto, mctomqtt,       and the endpoint retained their exact PIDs, and mctomqtt remained the sole       owner of the RAK USB port. One read-only LoRa status reply was lost at the       temporary 0 dBm bench setting, then authenticated status returned       <code>scheduled</code>; no mutation was replayed. One monitor parsed two       <code>systemctl --value</code> columns in reverse order, so its boolean labels are       discarded; its PID/MQTT trace and the independent postchecks remain       valid.</li> <li>[x] A signed <code>host reboot</code> was accepted exactly once in 3.312 seconds and       armed the fixed 10-second timer. A changed boot ID and one observed       outage prove one reboot; management recovery took 35.763 seconds from       the last pre-outage success and 31.276 seconds from the first failed       probe. Postboot signed LoRa uptime replied in 3.651 seconds. All seven       exact USB identities returned, only the RAK port was owned, the deployed       configuration hashes were unchanged, and NetworkManager, Tailscale,       mosquitto, mctomqtt, the endpoint, and both privileged sockets were       active. Broker action state is intentionally under <code>/run</code> and persistent       journaling was unavailable, so exactly-once evidence is the accepted       reply, one boot-ID transition, one outage, an inactive timer, and no       second outage; do not claim a durable postboot operation record.</li> <li>[x] Reboot auto-started the still-enabled ModemManager service, but all seven       exact devices retained <code>ID_MM_DEVICE_IGNORE=1</code>, zero modems appeared,       and no TTY was probed or claimed. The service was returned to its       pretest inactive state without disabling or masking it. The RAK then       passed exact identity/body/radio gates; an explicit radio-busy rejection       left TX at 0 dBm, one bounded idempotent retry after idle returned OK,       and authenticated readback proved exact restoration to 22 dBm. V4       identity, power-saving, RXPS, TempRadio, and seeder state also matched       their pretest values.</li> </ul> <p>The sanitized host-recovery evidence bundle is under <code>out/host-actions-live-20260831/</code>. Its <code>SHA256SUMS</code> manifest has SHA-256 <code>5acff71ed98f483bb769e8c99c577bf358d0491355ac72855ee7093cd658bf21</code>, and <code>sha256sum -c</code> verifies every deployed-hash, pre/post-state, radio, OTA, network, and reboot record in that manifest.</p>"},{"location":"hardware_validation_checklist/#mercerwood-pi-usb-power-cycle-gate","title":"Mercerwood Pi USB power-cycle gate","text":"<ul> <li>[ ] Confirm the Pi is reachable through Wi-Fi/Tailscale and that <code>eth0</code> is not       the active management path before cycling its downstream USB tree.</li> <li>[ ] Stop all flashes/transfers, run <code>sync</code>, and release SWD GPIO 8 and GPIO 11       to inputs with no pulls before removing USB power. This prevents an SWD       signal from partially back-powering an otherwise unpowered nRF52.</li> <li>[ ] Never issue a standalone <code>uhubctl ... -a off</code> to Pi root hub location <code>1</code>.       Once its only port is off, the hub disappears from <code>uhubctl</code> discovery and       a separate <code>-a on</code> command fails with <code>No compatible devices detected at       location 1!</code>. This has interrupted two hardware runs.</li> <li>[ ] A downstream hub may be cycled only after resolving the board's stable       USB serial to an exact sysfs path and proving that hub advertises       per-port power switching. Record the hub location and port, cycle only       that port, and gate the re-enumerated VID/PID/serial before continuing.       The T1000-E qualification safely used child hub <code>1-1.2</code>, port 3; this is       not permission to cycle the ganged root hub at location <code>1</code>.</li> <li>[ ] Do not use <code>uhubctl</code> <code>off</code>, <code>on</code>, or atomic <code>cycle</code> on Mercerwood root       hub location <code>1</code>. Physical testing showed that even one atomic <code>cycle</code>       powers the ganged root hub down and then cannot rediscover it to restore       power. Use a planned Wi-Fi-issued <code>sudo reboot</code>, which is the verified       recovery, or arrange a true upstream VBUS removal when that distinction       is part of the test.</li> <li>[ ] Treat root hub <code>1</code> as a ganged operation: every attached test board and USB       Ethernet adapter loses power. After recovery, enumerate every stable       <code>/dev/serial/by-id</code> identity again before resuming any board-specific test.</li> <li>[ ] On this heavily populated root hub, inspect kernel logs for real transfer       faults before and after a flash, and stop ModemManager while it could open       a test TTY. A CH340/ESP32-S3 write which lost the chip at 460800 baud       completed and verified at 115200 after a planned Pi reboot; start at the       board-qualified conservative rate rather than treating a fast partial       transfer as firmware failure.</li> <li>[ ] Under non-interactive SSH, do not let <code>udisksctl</code> fall through to an       interactive polkit password prompt. After resolving the exact UF2 block       device by board serial, either use an already-mounted volume or an       explicit <code>sudo -n mount</code> at a board-specific mount point; re-check       <code>INFO_UF2.TXT</code> model/version before copying.</li> </ul>"},{"location":"hardware_validation_checklist/#seeed-xiao-nrf52840","title":"Seeed XIAO nRF52840","text":"<ul> <li>[ ] Stable USB identity distinguishes application (<code>2886:8044</code>) from UF2       bootloader (<code>2886:0044</code>).</li> <li>[ ] Do not repeat the known-failing full-application UF2 copy under the       installed initial 2.4.4 candidate. The identity-gated 897,024-byte copy       returned exit 0, then <code>sync -f</code> failed with <code>EIO</code> in 850 ms; the kernel       logged an offline device, lost queued writes, and FAT errors before USB       disappeared. Recover through a separately hash-gated BLE/serial path and       qualify a corrected bootloader candidate before retrying UF2.</li> <li>[ ] SWD readback exactly matches the intended bootloader-region SHA-256.</li> <li>[ ] Actual SoftDevice FWID and runtime application base match the artifact       (<code>S140 7.3.0</code>: FWID <code>0x0123</code>, application base <code>0x27000</code>).</li> <li>[ ] Exercise and independently verify the exact-board combined       bootloader+SoftDevice recovery path before relying on it in the field.       A wrong-layout nRF52840 application can overwrite part of S140 while the       UF2 bootloader still accepts files and the application still reads flash;       internal writes or <code>InternalFS.format()</code> may then hang or reboot. An       application-only UF2 and a filesystem erase cannot repair that state.       The known XIAO incident in upstream issue #3284 recovered only after the       matching Sense/non-Sense OTAFIX bootloader+S140 ZIP was installed. Keep       board identity, SoftDevice FWID, application base, and package contents       as four separate pre-write gates.</li> <li>[ ] Invalid settings enter persistent UF2 recovery after a cold boot.</li> <li>[ ] UF2 application copy returns success; <code>sync -f</code> returns success; the host       has no offline-sector, lost-write, or FAT I/O errors.</li> <li>[ ] Application enumerates after update and reports the expected board,       version, role, and radio tuple.</li> <li>[ ] Legacy serial DFU crosses all application pages, emits the exact       <code>Device programmed.</code> success marker, and rejects false-success output.       Two application serial-DFU attempts on this board timed out waiting for       the start ACK while <code>adafruit-nrfutil</code> still returned exit 0, so exit       status alone is explicitly insufficient.</li> <li>[ ] Legacy BLE DFU verifies each cumulative PRN receipt exactly and fails on       a missing, short, regressive, or overreported offset; it may adapt       only among the packet-size-specific safe receipt windows after timely       exact receipts and must step back down on slow exact receipts. Final       application/SoftDevice/bootloader CRC and a peer disconnect are mandatory       before declaring success.</li> <li>[ ] Every upward PRN move is a bounded adjacent-level probe. A failed probe       or a later real demotion blocks further increases for that transfer, while       additional slow exact receipts may still negotiate down one level at a       time. This prevents <code>4 -&gt; 8 -&gt; 4 -&gt; 8</code> churn without disabling a safe       initial probe or a <code>32 -&gt; 16 -&gt; 8</code> fallback.</li> <li>[x] The exact Full Companion ZIP       <code>Xiao_nrf52_companion_radio_full-v1.17.1.5-halo-keymind-cascade-3caf9dcf.zip</code>       (SHA-256 <code>9a916c1a3ea83d8f6dd704465fe9c044a363478f852a4369cf6b13424a7a9430</code>)       installed over BLE in 237,297 ms at about 2,110 B/s using ATT MTU 247,       244-byte writes, PRN 4, and exact cumulative receipts. Validate and the       target-initiated disconnect passed. USB then reported the exact expected       version/hash, USA radio tuple, key, RXPS policy, and reversible       Terminal/Binary mode; the new application advertised NUS as       <code>MeshCore-4610BBD2</code>.</li> <li>[x] The post-update application was paired through BlueZ with the expected       PIN. Companion GATT then returned the same public key, USA radio tuple,       22 dBm limit, non-repeater role, board, and build over BLE. Its RTC was       18,038 seconds behind the trusted host; <code>clock sync</code> advanced it and the       immediate readback was within one second of the host interval. No       backward clock write was performed.</li> <li>[x] A second exact same-image update exercised application buttonless DFU and       retained-peer bootloader entry. The bootloader deliberately reused the       bonded application address <code>E5:C3:A8:B0:60:66</code> rather than the cold-entry       address ending in <code>:67</code>; exact name, Legacy DFU service, and DIS model       gates still passed. The first adaptive threshold remained at PRN 4 and       completed all 448,416 bytes at about 877 B/s in 527,832 ms; validate,       target disconnect, USB identity, application key, role, and USA radio       readback all passed. The application clock was then about 10 minutes       behind because its RTC did not advance during the bootloader transfer;       it was advanced to the host clock and proved by immediate readback.</li> <li>[x] A third same-image A/B run used bounded neutral-window exploration. At       244-byte writes, two exact neutral PRN-4 receipts triggered one adjacent       PRN-8 probe. PRN 8 measured about 845 B/s against an approximately       879 B/s PRN-4 baseline, so the helper rolled back to PRN 4 after two       receipts and never re-probed. All 448,416 bytes completed at about       870 B/s in 531,804 ms; CRC validation, target disconnect, USB return,       exact Companion key/role/radio readback, and post-DFU forward clock sync       passed. This proves up/down sender-window adaptation and no churn, while also showing       that PRN receipt overhead is not the bonded-path bottleneck on this run.</li> <li>[x] A bootloader candidate built from exact ZIP SHA-256       <code>9c70200fc15a315a50ec68d2a905b5bcf2fc07a796a21fbd439535ec19a608be</code>       disabled inherited slave latency locally during DFU DATA. The controller       trace still reported the peer-negotiated 30 ms interval and latency 4,       with no connection-parameter update after START; the change is therefore       a local event-attendance override, not a GAP speed renegotiation. A cold       address-generation control completed 448,416 bytes at 2,231 B/s and       passed validation/activation in 226,103 ms.</li> <li>[x] Two subsequent bonded application-to-bootloader runs completed the exact       same 448,416-byte image at 3,524 and 3,534 B/s. Their complete elapsed       times, including exact application advertisement proof, buttonless       handoff, bootloader scan, erase, DATA, CRC validation, activation, and       reboot, were 169,414 and 169,221 ms. Both targets initiated the final       disconnect; USB returned as stable serial <code>B35E71C1C3726CE7</code>; the public       key, 22 dBm setting, USA <code>910.525/62.5/SF7/CR5</code> tuple, board, and build       read back exactly. Compared with the prior roughly 877 B/s bonded run,       the DATA rate improved by about 4.0x without increasing the PRN window       beyond 8.</li> <li>[x] An exact bonded B-A-B link-profile sequence used the same Full Companion       ZIP SHA-256 <code>9a916c1a3ea83d8f6dd704465fe9c044a363478f852a4369cf6b13424a7a9430</code>,       lab helper SHA-256 <code>4909c617de37b5666cc622b7190568f002280f55bf26a05843ea283f2be8f566</code>,       handoff helper SHA-256       <code>1bad570173079b623bbe2bbb9e5ba7c4f8ac379bf966bfd4382c5266fb9fd214</code>,       stable USB serial, bonded address, and 448,416-byte application throughout.       First B, <code>xiao-ble-event-length-prestart-20260830-072641-W7COxm</code>, used one       exact pre-START 15 ms/latency-0 update with <code>0/0</code> no-preference event-length       hints and completed DATA in 72.030 seconds at 6,225 B/s; DFU through target       disconnect was 102.792 seconds and the full workflow was 117,064 ms.       Control A, <code>xiao-ble-control-prestart-20260830-073149-yKf0lO</code>, requested no       update, retained the bootloader connection's 30 ms/latency-4 link, and       completed DATA in 134.131 seconds at 3,343 B/s; DFU was 165.137 seconds and       the full workflow was 182,624 ms. Final B,       <code>xiao-ble-exact15-prestart-20260830-073554-FuGPfH</code>, repeated exact 15 ms and       completed DATA in 71.970 seconds at 6,231 B/s; DFU was 102.799 seconds and       the full workflow was 117,179 ms. Both B rates were about 1.86x control and       differed by only 0.096%.</li> <li>[x] The B-A-B protocol and link gates passed independently. Both B runs probed       PRN 4 -&gt; 8 after an exact 0.135-second four-packet receipt, rolled back       once to PRN 4 after the exact 0.345-second eight-packet receipt, and never       re-probed. Control A likewise probed after 0.269 seconds and rolled back       after 0.600 seconds. Each B bootloader connection had exactly one matching       HCI Update Complete before START; control A had no bootloader-connection       update. All three captures contained zero connection updates from START       through DATA, CRC validation, activation, and the target-initiated       disconnect. Each run ended <code>RESULT=PASS</code>, <code>RC=0</code>, <code>STAGE=complete</code>; final B       returned the exact Full Companion application as USB <code>2886:8044</code>, stable       serial <code>B35E71C1C3726CE7</code>, with current application name       <code>MeshCore-4610BBD2</code>. A fresh post-B binary Companion query independently       re-gated the unchanged public identity, name, Full Companion role, 22 dBm       power, and USA <code>910.525/62.5/SF7/CR5</code> radio tuple. A separate bonded BLE       application query then returned the same board, build, and Full Companion       role, so the USB return did not mask a broken Companion BLE path or stale       bootloader alias.</li> <li>[x] The current host-controller ceiling is independently characterized. The       Pi Zero 2 W Broadcom UART controller reports HCI/LMP 4.2 but supports only       LE 1M; LE Read Maximum Data Length and Read Suggested Default Data Length       both return Unknown HCI Command. The final B capture contains 1,837 full       244-byte firmware writes,       each split into ten 27-byte HCI ACL fragments; all 18,425 transmitted ACL       fragments received completed-packet accounting. The median full-write gap       was 29.947 ms at 15 ms versus 59.936 ms in control A. A BLE 5 controller       with working Data Length Extension is therefore the next host-side speed       experiment; this built-in controller cannot exercise DLE or LE 2M.</li> <li>[x] The host helper now clears a disconnect callback left by an unsuccessful       internal BlueZ connection attempt only after <code>connect()</code> has returned a       live link, and labels PRN changes as adaptation rather than link       negotiation. All 81 strict host tests pass. The first physical run before       this fix still proved the 3,520 B/s DATA rate and returned a successful       validation response, but is correctly recorded as FAIL because the stale       host event prevented ACTIVATE.</li> <li>[ ] Warm app-to-bootloader handoff is tested with the application watchdog       active; cold recovery is tested separately.</li> <li>[ ] BLE Companion/recovery behavior and radio-reset recovery are exercised.</li> <li>[x] The post-Pi-recovery application still enumerated as exact       <code>2886:8044</code> / <code>B35E71C1C3726CE7</code>, but one identity-gated, bounded USB       Binary Companion attempt received no protocol response. <code>meshcore-cli</code>       1.6.0 printed both of its no-response error lines and nevertheless exited       zero; the supervisor treated the attempt as a failure and independently       proved that no process retained the serial port. The exact terminal-stop       token and an identity/path-gated USB bus reset also failed, which excludes       an ordinary startup Terminal-mode hold and host USB endpoint state. The       external tool defect remains in upstream <code>meshcore-cli</code> 1.6.3: its serial       creation failure returns normally, so callers must validate command output       instead of trusting exit zero. The LoRa-OTA controller has an exact       three-diagnostic regression and continues to fail closed.</li> <li>[x] An exact hash-recorded Full Companion application DFU erased/replaced only       the application and completed in 36 seconds. The transferred ZIP was       440,083 bytes with SHA-256       <code>9946b8417c389784ac92c20e4ce5cf0b6a0123a58136627c0689815637f96992</code>.       The same stable USB serial returned as interface <code>00</code>; USB and the existing       bonded BLE identity both reported <code>Seeed Xiao-nrf52</code>, the 31-Aug-2026       build, and Companion role. Preserved settings included a roughly six-month       stale clock, which Binary Companion <code>clock sync</code> advanced to one second of       the Pi without changing the role.</li> <li>[x] The recovered application passed explicit Terminal start/stop, exact board       query, saved <code>usb.logging off</code>, source-only OTA status, and a real serial       <code>motatool serve</code> attach/detach with an empty folder (<code>COUNT -&gt; 0</code>). Binary       Companion returned after both terminal and mOTA ownership. Enabling USB       logging and rebooting produced exact interfaces <code>00</code> and <code>02</code>; interface       <code>02</code> emitted 123 bytes of entirely printable log data while Binary       Companion stayed usable on <code>00</code>. Disabling and rebooting removed <code>02</code>,       restored the single-interface descriptor, and read back logging off.</li> <li>[ ] A physical power-removal cold test is still needed to prove persistence of       the current application. It cannot retrospectively determine whether a       power cycle alone would have cleared the original stall. Answer that only       after reproducing the stall under a bounded stress loop, capturing state,       and power-cycling before any DFU. The application DFU proves recovery but       intentionally does not claim the underlying stall trigger is fixed.</li> </ul>"},{"location":"hardware_validation_checklist/#seeed-tracker-t1000-e","title":"Seeed Tracker T1000-E","text":"<ul> <li>[x] The cross-role <code>uf2reset</code> repair was hardware-qualified with Full       Companion ZIP SHA-256       <code>16e470c0d66bec14e1e9f2d4ebe04d83ffb30efa606465f885cbe9fc3d004a14</code>.       It was built from <code>f2c15225</code> with GCC 14.2.1, the USA Cascadia/Cascade       profile, and embedded version       <code>v1.17.1-uf2reset-f2c15225-f2c15225</code>. Serial DFU took 32.196 seconds and       stable application USB returned in 35.888 seconds. Terminal entry,       version, help, the exact no-argument command, application disconnect, and       stable <code>2886:0057</code> boot USB all passed in one 8.898-second script. The same       image was restored in 32.204 seconds and stable <code>239a:8029</code> USB returned       in 36.313 seconds; a final terminal check returned Binary mode cleanly.</li> <li>[x] The fixed application advertises live as <code>MeshCore-09848C15</code> at       <code>D1:A0:86:CD:BB:C6</code>. The obsolete Pi bond for the earlier temporary       identity was removed, and the exact address was paired again with the       qualification PIN. Paired, bonded, and trusted state, an encrypted BLEDfu       revision read, and the Nordic UART service all passed. The pre-run old       application enumerated but produced neither a terminal response nor a       live advertisement, so this run does not claim continuity of that       temporary identity or of application-owned settings across a combined       SoftDevice/bootloader recovery install.</li> <li>[x] Stable application identity <code>34A9141999729D5D</code> is recorded and is not       confused with the RAK3401 even though both currently enumerate with USB       product ID <code>239a:8029</code>. Application is <code>239a:8029</code>; the exercised       bootloader is <code>2886:0057</code>, with the same stable serial and exact       <code>T1000-E</code>/<code>T1KE_DFU</code> model/name gates.</li> <li>[x] A post-Pi-recovery, identity-gated, read-only USB Companion query returned       the exact T1000-E model, non-repeater Full Companion role, 22 dBm maximum,       and <code>910.525/62.5/SF7/CR5</code>. Its clock readback was within the query's       few-second host interval. No clock, radio, role, key, or settings write       was issued.</li> <li>[ ] Board, version, repeater role, bootloader status, and USA radio tuple are       correct after erase/install and after reboot. The live baseline and a       2,184 ms software reboot passed: <code>3caf9dcf</code>, <code>Seeed Tracker T1000-E</code>, 22 dBm,       <code>910.525/62.5/SF7/CR5</code>, OTA target <code>7B071FA0</code>, bootloader       <code>0.11.0-OTAFIX2.4.3</code>, and full OTA base hash       <code>3E92B157128B6963</code>. A real power-removal boot is still required.</li> <li>[ ] UF2 and serial DFU installation paths complete without host I/O errors.       On OTAFIX 2.4.3, an identity-gated root copy of the exact old UF2 returned       success in 112 ms, but the device disconnected before host writeback was       durable: <code>sync -f</code> failed with <code>EIO</code> after 17,695 ms and the kernel logged       lost asynchronous writes/FAT read errors. The old application happened to       boot and retained its settings, but this transport is a FAIL. Retest       with the corrected 2.4.4 candidate before qualifying T1000-E UF2.</li> <li>[x] The installed <code>t1000e_repeater_lora_ota_no_external_sensors</code> profile does       not compile the Companion BLE transport and did not advertise during a       post-reboot BlueZ scan; that is expected for this repeater image. BLE       Companion qualification belongs to the separate T1000-E Companion build.</li> <li>[x] The exact latency-disable bootloader candidate ZIP (SHA-256       <code>ebe9739ce40c2c7cc1f52076f9614194959fcf6df93d37666b69b7bd415fab68</code>)       installed through identity-gated serial DFU. The final output contained       exactly one terminal <code>Device programmed.</code> success line, the bootloader       returned as <code>2886:0057</code>, and its embedded manifest identifies       <code>T1KE_DFU</code>, S140 7.3/FWID <code>0x0123</code>, application base <code>0x27000</code>, and test       version <code>0x02040403</code>.</li> <li>[ ] The later connection-policy-reapply combined ZIP (SHA-256       <code>c2de1fb2704154b4abc371b6b4827c32ad09c4d15f3f6d97d0f4182bb51fff58</code>)       was identity-gated, transferred, validated, activated, and returned as       exact <code>2886:0057</code> recovery USB. <code>INFO_UF2.TXT</code> reported       <code>0.11.0-OTAFIX2.4.3-3-gffb1580-dirty-test-version-0x02040403</code>, S140       7.3.0, and the T1000-E board. The earlier and later candidates share the       same visible version string, however, so package sequencing and INFO_UF2       do not independently prove the installed bootloader bytes. Require an       identity-gated live bootloader-region readback or a uniquely versioned       rebuild before checking this item.</li> <li>[x] The combined-image BLE transport itself passed: 193,688 bytes at       3,331 B/s, target CRC validation, and target-initiated activation. The       package contains SoftDevice plus bootloader and <code>APP=0</code>, so remaining in       recovery USB was the correct postcondition. Its first supervisor record       is not accepted as run-level evidence: TERM inherited status zero and       wrote a false <code>PASS</code> at <code>STAGE=post_copy_usb</code>. A separate audit records       the transport result, and all later wrappers map INT/TERM to nonzero and       refuse <code>PASS</code> unless <code>STAGE=complete</code>.</li> <li>[x] A separate exact application recovery after that combined transfer       completed 404,468 bytes at 2,095 B/s, validated, activated, and returned       stable application USB in 225,899 ms. The lower rate is the expected       cold/unbonded class, not the bonded warm baseline.</li> <li>[x] A cold exact Full Companion application ZIP (SHA-256       <code>b3be000ab2391527a325cc868e2706dec291c167b6e6cd3495908addb8af6c65</code>)       completed all 404,468 DATA bytes over BLE at 1,572 B/s. The complete       workflow took 281,236 ms (about 1,438 B/s end to end, including setup,       validation, activation, and reboot). ATT MTU reached 247, but BlueZ's       independently cached maximum write size was still 20, so the       identity-gated helper correctly used 20-byte packets, adapted PRN       8 -&gt; 16 -&gt; 32, validated CRC, activated, observed the target-initiated       disconnect, and gated the exact USB application return.</li> <li>[x] The Full Companion application advertised as <code>MeshCore-F9AD7082</code> at the       expected address generation, paired with the qualification PIN, and       exposed its bonded, MITM-protected Legacy DFU service after connection.       That DFU service is intentionally absent from the advertisement, so an       advertisement-only check is insufficient. A 1200-baud USB touch instead       selects serial-only DFU and correctly produces no BLE advertisement;       use the bonded application control characteristic for a warm BLE handoff.</li> <li>[x] Exact same-address bonded warm buttonless DFU passed. The application       advertisement, Paired/Bonded state, connected BLEDfu service/control/       revision layout, encrypted notification/write gate, observed target       disconnect, <code>T1KE_DFU</code> advertisement, DIS model <code>T1000-E</code>, ATT MTU 247,       and 244-byte write capability were all checked. All 404,468 bytes were       confirmed in 121.081 seconds at 3,340 B/s; DFU through target disconnect       took 144.076 seconds and the full supervisor took 176.958 seconds. CRC,       activation, and exact <code>239a:8029</code>/<code>34A9141999729D5D</code> USB return passed.</li> <li>[x] Two accepted in-DATA 30 ms -&gt; 15 ms -&gt; 30 ms controller experiments       completed without corrupting either image, but were decisive negative       performance results. The first finished DATA in 425.398 seconds at       951 B/s; the later candidate finished DATA in 449.063 seconds at 901 B/s.       HCI capture found the cause: <code>hcitool lecup</code> silently encoded both       connection-event-length hints as <code>0x0001</code> (0.625 ms). The Pi's Broadcom       4.2 controller consequently scheduled about one ACL fragment per event:       roughly 64 fragments/s at 15 ms and 32 fragments/s after the 30 ms       \"rollback\", versus roughly 120--144 fragments/s on the untouched link.       The later pre-START controls prove that 15 ms itself is not slow; the       restrictive event-length hint and in-DATA update/rollback were unsafe.</li> <li>[x] Two exact 15 ms/latency-0, zero-event-length lab controls passed:       <code>t1000-ble-event-length-prestart-20260830-071549-QOeVuw</code> completed all       404,468 DATA bytes in 64.905 seconds at 6,232 B/s (95.635 seconds through       target disconnect; 112,639 ms full workflow), and       <code>t1000-ble-event-length-prestart-20260830-071825-VE9Re3</code> completed DATA in       62.070 seconds at 6,516 B/s (92.794 seconds through target disconnect;       106,807 ms full workflow). Both used exact <code>0/0</code> no-preference minimum and       maximum connection-event lengths. On each bootloader connection the HCI       trace contains exactly one successful update before START and none from       START through DATA, validation, activation, and the target disconnect;       Update Complete preceded START by 7.535 and 7.536 seconds. Completed-packet       clusters followed the 15 ms connection anchors, while the median full-size       DFU write gap was 29.997 ms in both traces. Exact package hash, CRC,       activation, and stable application USB return passed twice.</li> <li>[x] <code>t1000-ble-event-length-prestart-20260830-071358-ogzmRy</code> is the bounded       negative control. HCI accepted exact 15 ms/latency 0 with both event-length       hints set to 10 ms, then reported <code>Connection Timeout (0x08)</code> 6.810 seconds       after Update Complete during the 20-second pre-START pause. The run failed       closed at <code>STAGE=pre_start_update</code> in 44,227 ms; START and application DATA       were never sent. A 10 ms event-length hint is therefore rejected for this       adapter/target pair.</li> <li>[ ] Production BLE DFU keeps the controller-negotiated link and issues no raw       host connection update unless that exact adapter/target profile has been       separately graduated. The opt-in lab path may issue exactly one request on       the bootloader connection before START while sent/confirmed are zero: exact       interval and latency, <code>0/0</code> no-preference event-length hints, bounded pause,       and a matching HCI Update Complete are mandatory. Failure or mismatch       disconnects before START. Never update or roll back the link during DATA;       only the protocol PRN/window may adapt there. Compare complete repeated       control/candidate DFUs offline before graduating a production profile.</li> <li>[ ] Repeat the cold transfer with the host's bounded BlueZ readiness wait.       When ATT MTU is greater than 23 while the cached write capability remains       20, it polls the same connected DFU characteristic for at most three       seconds, aborts on disconnect, disappearance, or characteristic-handle       change, and otherwise falls back safely to 20. The four readiness unit       cases and all 81 strict helper tests pass; a physical 20 -&gt; 244-byte       promotion is still required.</li> <li>[ ] Restore the protected       <code>t1000e_repeater_lora_ota_no_external_sensors</code> application (target       <code>0x7B071FA0</code>, exact ZIP SHA-256       <code>9b9be2bee9ebb6644d22806d404fe02c415d037707713d206fa43a8c689cf632</code>)       through identity-gated application DFU while retaining the candidate       bootloader. Do not use the generic repeater image or the unqualified UF2       path. Verify the protected private/public identity without printing the       private key, plus exact name, latitude/longitude, build/body/OTA target,       USA radio, 22 dBm, GPS off, power saving on, RX gain on, RXPS on,       watchdog on, telemetry access <code>all</code>, no TempRadio/download, and a valid       admin login.</li> <li>[ ] LoRa radio reset/recovery is forced and normal receive/transmit resumes.       Normal post-reboot bidirectional LoRa is already proven: the V4 learned a       zero-hop path, received the exact message-specific ACK in 558 ms, and       received the T1000-E's exact <code>3caf9dcf</code> version reply. A deliberately       forced LR1110 recovery event is still required.</li> <li>[x] Direct V4 LoRa OTA receive, apply, reboot, and post-update verification       passed from exact <code>bf092b24</code> body <code>9443FB5E6F23FC1B</code> to exact <code>3caf9dcf</code>       body <code>3E92B157128B6963</code> on OTAFIX 2.4.3. The mandatory fixed three-minute       rehearsal passed at <code>909.950/250/SF5/CR5</code>, including natural expiry and       return to <code>910.525/62.5/SF7/CR5</code>. The 2,036-byte/two-block delta reached       ready in six seconds, the new body replied at the 50-second probe, and the       complete safety-wrapped runner took 519 seconds. V4 source RXPS and both       normal radio tuples were restored. The co-located T1000 was temporarily       reduced to 0 dBm and restored to 22 dBm using bounded retries across its       RXPS busy windows.</li> <li>[x] Independent post-LoRa-OTA USB verification matched the protected pre-run       private key, public key, name, latitude, and longitude without printing       private material. GPS remained off; device power saving, system watchdog,       RX gain, and RXPS remained on; telemetry access remained <code>all</code>; no       TempRadio lease or download remained. <code>blrc:B8</code> is the expected OTAFIX       application-apply success diagnostic. A subsequent software reboot reset       uptime and preserved the exact build/body, name, radio, 22 dBm, GPS,       power-saving, RXPS, watchdog, and no-TempRadio state. The CDC symlink did       not disappear during this warm reset, so uptime/readback\u2014not USB removal\u2014       is the required reboot proof on this board.</li> <li>[x] GPS was initially off, enabled successfully under device power saving,       reported active/no-fix/zero-satellites with its duty-cycle deadline, and       was restored to off. Device power saving reported on, RXPS reported       <code>on,18205,20423</code>, GPS advert policy <code>prefs</code>, and telemetry access <code>all</code>.</li> </ul>"},{"location":"hardware_validation_checklist/#rak3401","title":"RAK3401","text":"<ul> <li>[x] Stable USB identity and SWD FICR identity are independently matched.</li> <li>[x] Source-level WisBlock peripheral pins are complete and non-conflicting:       I2C SDA/SCL are P0.13/P0.14 through both <code>PIN_WIRE_*</code> and       <code>PIN_BOARD_*</code>; GPS-module RX crosses to MCU UART TX P0.16, GPS-module TX       crosses to MCU UART RX P0.15, and PPS is P0.17. A static contract test       prevents these aliases from silently disappearing or being uncrossed.</li> <li>[x] Ordinary/full-sensor RAK3401 profiles use the source-built Adafruit BME680       provider, not Bosch's precompiled BSEC archive, so upstream issue #3292's       soft-float/hard-float link mismatch is not reachable there. The reduced       LoRa-OTA profile deliberately omits BME680/BSEC and the other declared       optional environmental/ranging drivers. A static contract test requires       the hard-float path fix and BSEC dependency if BSEC is enabled in this       board or an inherited full-sensor recipe later.</li> <li>[ ] With the RAK13302 radio installed, detect a RAK12501/L76K UART GPS from a       complete checksum-valid NMEA sentence in sensor slot A. Confirm random       UART bytes, an incomplete sentence, and a bad checksum do not claim GPS.</li> <li>[ ] Detect RAK12500 I2C GPS alone at <code>0x42</code>; exercise GPS power saving and       confirm the shared 3V3_S rail, OLED, RTC, and other slots remain powered.</li> <li>[ ] Detect INA3221 alone at the firmware-configured <code>0x42</code> and prove the       discovery path does not send u-blox configuration traffic to it.</li> <li>[ ] Exercise RAK12500 at <code>0x42</code> and INA3221 at <code>0x43</code> together after strapping       INA3221 A0 to SCL and building with       <code>-DTELEM_INA3221_ADDRESS=0x43</code>; verify both retain independent telemetry.</li> <li>[ ] With a representative omitted environmental sensor attached, confirm the       reduced image leaves the generic I2C bus healthy but does not advertise a       driver that was intentionally removed.</li> <li>[x] Local USB terminal probes are terminated with carriage return (<code>\\r</code>).       This CLI echoes an LF-only command without executing it; an echoed       <code>ver</code> with no reply is therefore a bad probe, not evidence of a hung       application. Confirm any suspected hang with a CR-terminated command,       LoRa status, and SWD state before resetting the board.</li> <li>[x] Assert CDC DTR when probing the RAK terminal. With DTR deasserted, writes       reached the port but no CLI replies were returned; the same exact       stable-identity port returned the expected version immediately after DTR       was asserted. Keep 1200-baud bootloader touch separate from 115200-baud       application probes, and allow a full reply window so delayed responses       are not attributed to the following command.</li> <li>[x] Installed S140 6.1.1 FWID (<code>0x00B6</code>) and runtime application base       (<code>0x26000</code>) are independently verified.</li> <li>[x] Bootloader version and apply capabilities are independently reported.</li> <li>[x] UF2 application copy returns success; <code>sync -f</code> returns success; no USB       reset/timeout or offline-sector errors occur; SWD readback matches every       UF2 payload byte. Current 2.4.4-preview.2 result is PASS in both       current\u2192old and old\u2192current directions.</li> <li>[x] Board, repeater role, version, name, and USA radio tuple are verified       after serial recovery and again after a real cold boot.</li> <li>[x] Six consecutive authenticated <code>ota self</code> attempts leave the application       healthy. In the qualification run, two login/reply pairs were lost, one       login succeeded while its command reply was lost, and the next three       commands replied in about 2.5 seconds each. A CR-terminated local <code>ver</code>       probe passed after every attempt; packet loss did not become a node hang.</li> <li>[ ] An unchanged admin login does not rewrite the ACL flash file, while an       actually changed/newly learned persistent route schedules exactly one       delayed save and survives reboot. Cover delayed flood-path replies,       already-unknown paths, changed permissions/secrets, new/evicted clients,       and the intentionally non-persistent guest case. Do not rely on an       unrelated login write to capture a later PATH response.</li> <li>[ ] Location and private-key persistence are verified without exposing the       private key in logs.</li> <li>[x] Serial recovery rejects nrfutil's false exit-0 failure, requires the exact       success marker, and produces a byte-exact SWD application readback.</li> <li>[ ] UF2/serial recovery works with both the deployed older bootloader family       and the current backward-compatible application.</li> <li>[ ] Bluetooth advertisement and connection work when enabled. The tested       repeater profile does not advertise BLE during normal operation.</li> <li>[x] Direct LoRa OTA from the V4 passes with elapsed time, bounded retry       behavior, final hash/version verification, exact radio restoration, and       independent SWD readback. The qualified <code>bf092b24</code> base       <code>91CF4EC2882F23D6</code> reached <code>3caf9dcf</code>/<code>27A223DDFC3A8F47</code> using a       two-block, 2,132-byte delta: ready in six seconds, new body at the       60-second reboot probe, and 514 seconds for the complete safety-wrapped       run. Log:       <code>/home/mikec/hwtest/runs/rak3401-0dbm-final-9KWjey61/run.log</code>.</li> <li>[x] The current OTAFIX test version <code>0x02040403</code> independently passes a       74-block direct LoRa update from exact <code>3caf9dcf</code> body       <code>27A223DDFC3A8F47</code> to HEAD <code>9fd580c8</code> body <code>744BC4443891ED10</code>.       READY took 122 seconds and the complete three-minute-rehearsal,       transfer, install, reboot, recovery, and restore wrapper took 589.487       seconds. Lost read-only preflight and postboot replies were reconciled by       bounded exact retries. USB confirmed the target/hardware/body and       bootloader success result, and authenticated LoRa readback confirmed the       final 22 dBm restoration. Sanitized log:       <code>/home/mikec/hwtest/runs/rak3401-02040403-head-vzWOXVxT/qualification-redacted.log</code>.</li> <li>[ ] Add exact RF packet sent/confirmed counters to the device/host telemetry.       The qualified run records two payload blocks, all seeder reads, command       retries, and final success, but those are not equivalent to LoRa packet       counts and must not be presented as such.</li> <li>[ ] Repeat at each supported bandwidth and record 0-hop, 1-hop, and 2-hop       estimates from measured airtime rather than extrapolating only by file size.</li> </ul>"},{"location":"hardware_validation_checklist/#rak4631-reduced-profiles","title":"RAK4631 reduced profiles","text":"<ul> <li>[x] Serialized VM contracts distinguish the three application identities:       the plain and Serial2 reduced profiles retain the combined WisBlock GPS       provider and all four INA voltage/current drivers; the explicit legacy       Serial1 profile retains the INA drivers and omits GPS. This is build       evidence only, not physical peripheral qualification.</li> <li>[ ] On the plain reduced profile, detect and read RAK12500 I2C GPS, a       RAK12501/L76K UART GPS in a separate run, the SSD1306 OLED, a supported       autodiscovered RTC, and representative INA telemetry. Verify GPS sleep and       repeated discovery never lower the shared WB_IO2/3V3_S rail.</li> <li>[ ] With a UART RAK12501 installed and detected, confirm the Serial2 bridge       and GPS remain usable together. Select Serial1 and try to enable the       bridge with the GPS preference both on and off; verify each attempt is       refused before the bridge starts and does not change GPS transport,       acquisition, hold, or cached-fix state. The shared WB_IO2/3V3_S rail must       remain high and GPS must remain usable after each refusal.</li> <li>[ ] With only an I2C RAK12500 installed, and again with neither GPS installed,       select Serial1 on the merged image and confirm bridge enable is refused       without changing saved UART/runtime state. Silence or an I2C-only detection       must not defeat the fail-closed RAK12501 reservation. Confirm Serial2 starts       and I2C GPS telemetry remains usable.</li> <li>[ ] Exercise RAK12500 at <code>0x42</code> and INA3221 at <code>0x43</code> together with the       address-matched build. Separately place INA3221 alone at the configured       <code>0x42</code> and prove the identity guard prevents u-blox configuration writes.</li> <li>[ ] With a logic analyzer, hold SDA low and then SCL low before sensor       discovery. Confirm the validated board pins receive at most nine       open-drain recovery clocks and a STOP only after SCL rises; the firmware       must skip discovery if either line remains low. Repeat on ProMicro's       remapped SDA 8/SCL 7 and verify the user-button pin is never driven.</li> <li>[ ] Record the remaining core limitation: the pinned Adafruit nRF52 Wire       implementation has no transaction timeout. This preflight cannot protect       display/RTC calls made earlier in boot or interrupt a peripheral that       wedges after a transaction begins. Qualify those cases with a hard power       cut/watchdog fixture before claiming bus-hang recovery.</li> <li>[ ] Confirm the explicit legacy Serial1 image exposes neither UART RAK12501       nor I2C RAK12500. Record this as a combined-provider build limitation, not       an assertion that RAK12500 electrically conflicts with the UART.</li> </ul>"},{"location":"hardware_validation_checklist/#heltec-t096","title":"Heltec T096","text":"<ul> <li>[x] The cross-role <code>uf2reset</code> repair was hardware-qualified on the exact       no-footer Full Companion image. ZIP SHA-256 is       <code>0585bee1c0b278a68788f78af384bcbdb5633d57f9ea301fc14f1c80c4275489</code>;       embedded version is <code>v1.17.1-uf2reset-f2c15225-f2c15225</code>. Terminal entry       and help passed, the exact command disconnected application USB in       1.031 seconds, and stable boot USB returned in 2.026 seconds. The final       Full image installed over serial in 38.900 seconds and stable application       USB returned in 41.672 seconds. Final primary terminal/Binary switching,       dedicated logging interface, version, help entry, and live       <code>MeshCore-8E229D0A</code> advertisement at <code>CF:A8:18:36:DE:8B</code> all passed.</li> <li>[x] Stable USB serial <code>651F8E496197F882</code> distinguishes the application       (<code>239A:8029</code>) from the OTAFIX serial-DFU interface. Every flash followed       that identity across the host-assigned <code>COM9 -&gt; COM6 -&gt; COM9</code> transition;       the simultaneously connected MeshPocket on <code>COM20</code> was never selected.</li> <li>[x] Baseline bootloader <code>0.11.0-OTAFIX2.4.3</code> was installed at this checkpoint. The restored Repeater       reports application body hash <code>3B6D1A729C087243</code>, target <code>98411AC6</code>, apply       ABI 3, codec mask <code>0x5</code>, and stage address <code>0xED000</code>. The application ZIP       is 708,216 bytes with SHA-256       <code>abb00560cc5618ae155bf10252e9261127416a7a91b5f6565837384f0dec2390</code>.</li> <li>[x] A 48,229-byte in-place delta with SHA-256       <code>988bd2385e9c995d0ae04effb6bb5cd614227c7c764590d82bd1943da2f18e4d</code>       transferred over LoRa in 47/47 blocks from the MeshPocket seeder and       applied successfully. The first application boot reported bootloader       result <code>B8</code>; the running body hash matched the candidate exactly. No chat       message was sent for this transfer.</li> <li>[x] The generic delayed AGC/watchdog arming fix passes warm-reboot hardware       checks on both the T096 and MeshPocket. The restored T096 retained AGC       interval 8 and, after 215 seconds, was in RX with 100 packets received,       28 sent, zero core errors, and <code>err_flags=0</code>. The Pocket's quiet-channel       liveness recovery set only the expected radio-watchdog bit; temporarily       matching the USA channel then received 14 packets with zero receive       errors before its saved <code>869.618/62.5/SF8/CR5</code> profile was restored. At       498 seconds the T096 had one CAD-busy timeout after 37 busy-channel       samples, then returned to RX with no queue, watchdog, or start-RX fault.</li> <li>[x] Exact Full Companion ZIP SHA-256       <code>ee92856e5bfb7877b0d8bff6d6a5873d8037fc178ddb151202a9e6a6d9d59e73</code>       installed by serial DFU and passed the reversible dual-CDC test. Logging       off exposed only interface <code>00</code>; <code>set usb.logging on reboot</code> added       interface <code>02</code> as <code>COM21</code>. Opening <code>02</code> emitted both portable identity       lines, 980 captured bytes were entirely printable, and host input produced       no echo or command reply while Binary Companion on <code>00</code> returned the exact       model, key, and radio tuple.</li> <li>[x] With interface <code>02</code> deliberately unread, 11/11 text-terminal probes stayed       between 212 and 231 ms for 44.4 seconds. A longer 100-second hold buffered       8,636 entirely printable bytes while 60/60 hard-bounded Binary Companion       reconnects passed with no timeout; the final full identity query completed       in 739 ms. Neither USB interface disconnected. Logging off plus reboot       removed <code>02</code>, read back off on <code>00</code>, and the qualified Repeater was then       restored with its original name, public key, and USA radio tuple.</li> <li>[x] The descriptor/reconnect follow-up built a 482,271-byte Full Companion DFU       ZIP with SHA-256       <code>2a5a6bd0fd26031a2c2e047af6ead8f85f0d617da238d0cd6d816f7d5c41ec6f</code>.       On the physical T096, Windows read interface <code>02</code>'s bus-reported       description as <code>MeshCore Logging</code>. Two immediate open/close cycles each       delivered the complete 80-byte two-line identity marker with no NUL or       other invalid control byte, while Binary Companion on interface <code>00</code>       retained the exact key, model, and <code>910.525/62.5/SF7/CR5</code> tuple.</li> <li>[x] The final short-write/reconnect guard built a 482,271-byte Full Companion       DFU ZIP with SHA-256       <code>bbbc3459b2c032af23c6da05e41984cb0250398b57ba56ea99166456700ace6f</code>       and EndF body hash <code>41365E4DB0FF4AE5</code>. On the physical T096, interface       <code>02</code> again reported <code>MeshCore Logging</code>; 3/3 explicit DTR sessions each       delivered one complete 80-byte marker with no NUL or invalid control byte.       With that logging endpoint held open and unread, interface <code>00</code> completed       60/60 Binary Companion reconnect queries and retained public key       <code>8e229d0a9ace9bd6f768fc1237d9e3ebca340d1ff1c6087349983a07f305903a</code>       plus the exact <code>910.525/62.5/SF7/CR5</code> tuple.</li> <li>[x] The corrected Windows flasher identifies Binary-mode Full Companion and       links the same-radio <code>MI_02</code> inventory row to <code>MI_00</code>. An intentional       selection of <code>COM21/MI_02</code> was canonicalized to <code>COM9/MI_00</code> before any       1200-baud action; the exact USB serial then followed       <code>COM9 -&gt; COM6 -&gt; COM9</code>, never touched the logging endpoint or MeshPocket,       and produced both <code>Device programmed.</code> and <code>Flash completed.</code>. The VM was       suspended only across each touch/transfer and resumed immediately. After       restoring the qualified Repeater and performing a final warm reboot, the       58-second snapshot was in RX with 28 packets received, 9 sent, zero core       errors, an empty queue, and <code>err_flags=0</code>.</li> <li>[x] Final flasher review now revalidates the selected USB identity and exact       interface immediately before both the direct 1200-baud open and its Python       fallback, and balances every successfully written terminal START with a       STOP even when the banner is lost. Windows PowerShell 5.1 and PowerShell 7       regression suites pass. A second physical restore deliberately selected       <code>COM21/MI_02</code>; it was canonicalized to <code>COM9/MI_00</code>, followed the same       <code>COM9 -&gt; COM6 -&gt; COM9</code> transition, and completed without touching the       MeshPocket. At 112 seconds the restored Repeater retained its name, OTA       body hash <code>3B6D1A729C087243</code>, USA radio tuple, and AGC interval 8; it was in       RX with 20 packets received, 6 sent, zero core errors, an empty queue, and       <code>err_flags=0</code>. The VM was running again immediately after the flash.</li> <li>[x] The T096-only message profile defines <code>UI_MESSAGE_CHANNEL_FOOTER=0</code>;       every other profile retains the default footer. The exact incoming       <code>#testing</code> message <code>T096 footer test: wrapped text should reach the screen       bottom.</code> traversed the live channel receive/display path, and the temporary       empty <code>#testing</code> channel slots on both endpoints were restored byte-for-byte.       Static profile coverage passes 2/2. No framebuffer or camera capture was       available, so the evidence is the exact live UI path plus the compiled       board-specific flag rather than a pixel photograph.</li> <li>[x] The then-final Full Companion artifact at this checkpoint,       <code>v1.17.1-t096-head-fcd1f8cc-usbtask8-fcd1f8cc</code>, was installed. Its DFU ZIP       is 487,231 bytes with SHA-256       <code>CD267952F420294DF21CA96E3AA6D924C6EF7467C31C8D69B46F31E6719A1D67</code>;       the application is 486,428 bytes with a 486,372-byte EndF body and hash       <code>2E03B1C1166D4CC0</code>. The ELF exposes strong <code>T</code> definitions for both CDC       callbacks, mount/unmount, SOF, and the CDC0-only framework flush override.</li> <li>[x] Identity-gated BLE application DFU passed through the bonded address       <code>CF:A8:18:36:DE:8B</code>: encrypted application handoff from       <code>MeshCore-8E229D0A</code>, same-address <code>T096_DFU</code> Legacy service, and DIS model       <code>HT-n5262G</code> all matched. The target confirmed 486,428/486,428 bytes in       565.986 seconds at 859 payload B/s, validated, activated, and initiated       the expected disconnect; end-to-end time was 603.967 seconds. USB serial,       version, board, public key, radio tuple, EndF hash, and bootloader apply       ABI 3/codecs <code>0x5</code> returned exactly, and a fresh active scan observed the       application name again at the same address.</li> <li>[x] The real host <code>motatool</code> opened <code>COM9</code>, survived the intentional CDC       session-settle purge, attached an empty folder with <code>COUNT -&gt; 0</code> and       <code>OK folder attached</code>, then detached it and restored Binary mode. This       test sent no mesh messages. Three primary-port close/reopen cycles after       deliberately abandoned terminal output exposed zero stale bytes and each       returned a clean banner. Five logging-port reopen sessions each began       with the exact 80-byte identity marker and contained no NUL or invalid       control byte.</li> <li>[x] With both USB outputs deliberately unread for 65 seconds after a 10,000-byte       terminal input burst, the primary accumulated 16,886 printable bytes and       CDC1 accumulated 3,735 printable bytes beginning with its exact marker.       <code>ver</code> and Binary Companion remained responsive. A subsequent warm reboot       removed USB for 2.209 seconds, returned both interfaces in 2.409 seconds,       and CDC1 again emitted the exact marker. At 65 seconds the fresh boot had       <code>err_flags=0</code>, an empty outbound queue, 9 received floods, and zero CRC       errors. A Windows host-side composite       restart was attempted but denied by the non-elevated PnP API, so the       distinct host-driven BUS_RESET case remains a physical/privileged check;       it is not inferred from the warm-reboot result.</li> <li>[x] After the operator physically removed and restored T096 power (the off       interval was not measured), stable serial <code>651F8E496197F882</code> returned as       primary <code>MI_00</code>/<code>COM9</code> and logging <code>MI_02</code>/<code>COM21</code>. The cold terminal       reported exact version       <code>v1.17.1-t096-head-fcd1f8cc-usbtask8-fcd1f8cc</code>, Heltec T096 identity,       public key, USA radio tuple, BLE name, dedicated-CDC logging state, EndF       body hash <code>2E03B1C1166D4CC0</code>, and bootloader apply ABI 3/codecs <code>0x5</code> with       stage ceiling <code>0xD4000</code>; mOTA remained source-only with no folder attached,       and STOP restored Binary mode. CDC1's first read was the exact 80-byte       identity marker with no NUL. At 150 seconds, Binary stats reported 4,224       mV, <code>err_flags=0</code>, an empty outbound queue, 47 packets received, zero       packets sent, and zero TX airtime. A second core checkpoint advanced       monotonically to 315 seconds with 4,220 mV, <code>err_flags=0</code>, and an empty       queue, providing no evidence of a watchdog reboot. A fresh active BLE       scan observed <code>MeshCore-8E229D0A</code> at the same <code>CF:A8:18:36:DE:8B</code>       address; BlueZ still       reported paired, bonded, and trusted. No mesh message was sent. This proves       cold persistence, but not the distinct host-only USB <code>BUS_RESET</code> path.</li> <li>[x] The display auto-off wake failure was traced to the shared ST7735 power       lifecycle: <code>turnOff()</code> released SCK/MOSI as inputs, but the nRF52       <code>SPIClass::begin()</code> wake path was a no-op while the SPI object still       considered itself initialized. The shared driver now restores the bus-pin       directions and nRF52 high-drive configuration explicitly, waits through       reset release, and primes the retained frame after <code>DISPON</code>. Static wake       ordering and the T096 footer profile pass, and the exact Full Companion artifact       <code>v1.17.1-t096-head-fcd1f8cc-wake1-fcd1f8cc</code> compiled at 486,348 bytes.       Its 487,231-byte serial-DFU ZIP has SHA-256       <code>A091F6DC458177BB26B8384B2AAAC0A9FD550322179F96062CCD3F0F5BB0E585</code>;       the 486,428-byte OTA image reports a 486,372-byte EndF body with hash       <code>E9AB2A36E9F7091F</code>. Identity-gated <code>meshfirmware</code> selected <code>COM21/MI_02</code>,       canonicalized it to <code>COM9/MI_00</code>, followed <code>COM9 -&gt; COM6 -&gt; COM9</code>, and       emitted both <code>Device programmed.</code> and <code>Flash completed.</code> without touching       the MeshPocket. The VM was suspended only across touch/transfer and was       running again as soon as exact serial <code>651F8E496197F882</code> returned. Live       readback then matched the public key, Heltec T096 board, USA       <code>910.525/62.5/SF7/CR5</code> tuple, ABI 3/codecs <code>0x5</code>/stage <code>0xD4000</code>, and exact       80-byte CDC1 marker; core checkpoints advanced through 369 seconds with       <code>err_flags=0</code>, an empty queue, and zero TX. Follow-up physical testing       confirmed auto-off wake and single-click page navigation. Double-click,       triple-click, long-press, and simultaneous-button gestures remain deferred.</li> <li>[x] A signed bootloader mOTA package for OTAFIX HIL candidate <code>0x02040401</code>       transferred over LoRa in 40/40 blocks, passed the privileged-install gate,       installed with the watchdog enabled, and rebooted with unchanged node and       radio settings. The installed bootloader CRC changed to the package's       expected <code>381BAE6E</code>; the temporary HIL signer was removed afterwards.</li> <li>[x] A 486,796-byte Full Companion application completed bonded Legacy BLE DFU       at approximately 5.7-6.2 kbit/s payload throughput, then returned with the       same identity and USA radio tuple. The later CDC0 first-open fix preserved       immediate <code>APP_START</code> input across the eight-millisecond session gate:       first client after reboot passed with CDC1 logging active, followed by       10/10 immediate COM9 close/reopen queries. CDC1 continued to emit its exact       identity marker and printable packet/debug logs.</li> </ul>"},{"location":"hardware_validation_checklist/#heltec-meshtower-v2-with-sd","title":"Heltec MeshTower V2 with SD","text":"<ul> <li>[x] Stable serial <code>9352162A72082314</code> and physical downstream-hub path       <code>1-1.2</code> port 4 identify this board across application and bootloader       descriptors; no other attached nRF52 endpoint was selected. The older       2.4.3 bootloader's UF2/serial failure was rejected rather than treated as       a successful flash.</li> <li>[x] Exact <code>1.17.1.5-halo-keymind-cascade-marathon-hwtest-e26d48e4</code> SD       Repeater boots with hardware ID <code>Heltec_tower_v2</code>, target <code>0A9DBBF0</code>,       body hash <code>E9282D470AAC348B</code>, and USA radio       <code>910.525/62.5/SF7/CR5</code>. <code>ota self</code> reports SD apply ABI 3 with codec mask       <code>0x5</code>; <code>ota bootloader</code> reports board <code>239A0071</code>, target <code>1150F50E</code>, name       <code>TOWER_V2_OTA</code>, and capability byte <code>09</code>.</li> <li>[x] A post-Pi-recovery identity-gated serial audit reconfirmed the exact       Tower V2 model, Repeater role, build, <code>910.525/62.5/SF7/CR5</code>, target       <code>0A9DBBF0</code>, body <code>E9282D47</code>, SD ABI 3/codecs <code>0x5</code>, and installed       bootloader identity/capability <code>239A0071</code>/<code>09</code>. The card reported       959.6 MiB free and no active download. This profile exposes the local       text console but deliberately has no runtime <code>usb.logging</code> setting; the       unknown-setting reply is a capability result, not a transport failure.</li> <li>[x] Card detection and destructive maintenance pass. Normal format took       3,927 ms; an immediate repeat was rejected by the five-minute cooldown;       forced format took 3,933 ms; and raw erase plus format took 3,947 ms.       The card remounted empty with 16.0 KiB used and 959.6 MiB free, and both       completion ages were recorded. Automatic archive capture was then       disabled deterministically, leaving only <code>/mota/cache.off</code>.</li> <li>[ ] SD card detection, staging, hash validation, apply, cleanup, and recovery       from missing/corrupt media pass.</li> <li>[ ] Multi-page application and bootloader update paths pass across a cold boot.</li> <li>[ ] LoRa OTA receive/apply reports the expected target ID and installed version.</li> </ul>"},{"location":"hardware_validation_checklist/#heltec-v4","title":"Heltec V4","text":"<ul> <li>[x] Exact V4 hardware variant is reported (<code>Heltec V4.3 OLED</code>); OLED/TFT       variants are not merged.</li> <li>[x] Full Companion boots with USB logging off and Binary Companion selected.       The text terminal independently reports the complete build string;       protocol <code>ver</code> has a shorter fixed-width version field.</li> <li>[ ] USB logging changes take effect immediately on this single-TTY ESP32       profile, require no reboot, and return to Binary Companion only through       the explicit terminal-stop mode change.</li> <li>[x] Bluetooth pairing and Companion protocol operations pass. Qualification       required removing the Pi's stale pre-flash bond, pairing through a BlueZ       <code>KeyboardOnly</code> agent with the current displayed/reported PIN, then       reconnecting; BLE <code>infos</code> and <code>ver</code> returned the exact V4.3 OLED identity.</li> <li>[x] Saved Wi-Fi connects to <code>SlowFi</code>, returns at <code>192.168.1.51</code> after the test       host reboot, reports Wi-Fi power save <code>min</code>, and remains governed by the       configured-network behavior rather than the unconfigured 30-minute       shutdown policy.</li> <li>[x] TCP Binary Companion (<code>5000</code>), Wi-Fi OTA (<code>5001</code>), and text CLI (<code>5002</code>)       are each tested and cannot be confused with one another. Port 5000       returned the exact Companion identity; 5002 returned the full terminal,       version, Wi-Fi, logging, RXPS, and memory state; and a real <code>motatool       serve --tcp 192.168.1.51:5001 -v</code> session received <code>COUNT -&gt; 0</code> from an       intentionally empty folder. Disconnect then restored <code>folder:not       connected</code> while the 5001 listener stayed active.</li> <li>[ ] For a shared Full-Companion controller/seeder, bind the source identity       to the exact public key already read from Binary Companion port 5000.       Do not require <code>get public.key</code> from text port 5002: the hardware-tested       V4 Full CLI rejects that command. Port 5002 must still prove the local       TempRadio state/tuple, while keyed on-air destination replies prove the       physical LoRa handoff.</li> <li>[ ] V4 seeds direct and routed LoRa OTA; TempRadio preflight, apply, and       automatic normal-radio restoration all pass.</li> </ul>"},{"location":"hardware_validation_checklist/#seeed-sensecap-indicator-lora","title":"Seeed SenseCAP Indicator LoRa","text":"<ul> <li>[x] Flashing selects the ESP32-S3 CH340 endpoint, never the Indicator RP2040       ACM endpoint; esptool MAC probing succeeds before erase. The qualifying       merged write used 115200 baud and completed with flash hash verification.</li> <li>[x] A fresh merged install completes SPIFFS initialization and reports the       intended Full Companion version/role and <code>Seeed SenseCAP Indicator</code>       hardware identity. The exact qualifying artifact was       <code>SenseCapIndicator-LoRa_companion_radio_full-1.17.1.5-halo-keymind-cascade-marathon-e26d48e4-merged.bin</code>,       2,070,152 bytes, SHA-256       <code>df08b770313ca8776436456525681cf286cd9b5b40e05e7cf55f21ef097f338a</code>;       its ELF, map, manifest, and partition signature are archived beside it on       the Mercerwood Pi.</li> <li>[x] The current dark-layout Full Companion application was flashed app-only       with exact CH340/MAC/partition gates, preserving identity, Wi-Fi, and       settings. The 2,147,800-byte application has SHA-256       <code>81bebdc07b6a8349c1c975cb5a0e30c5f6019d35bcac641e5f3d4df951f7406b</code>;       esptool verified its flash hash in 134.2 seconds. USB Binary/terminal,       saved logging-off state, configured Wi-Fi, BLE, TCP ports 5000/5001/5002,       and an empty-folder Wi-Fi mOTA <code>COUNT -&gt; 0</code> exchange all pass afterward.</li> <li>[x] Keep one identity-gated CH340 descriptor open with DTR/RTS deasserted       through startup. On the valid-current-font path, the Indicator streams a       1,302,608-byte font from its RP2040 at 1 Mbps before registering the USB       terminal, so allow at least 30 seconds before the first command. A       missing/corrupt-font recovery instead runs in the background after the       interfaces start. Reopening short probes can reset the ESP32 repeatedly       and create a false UART-hang diagnosis; the controlled run returned       <code>ver</code> and <code>board</code> after the same apparent-silence condition.</li> <li>[x] Automatic font recovery starts from a physically corrupt RP asset. The       setup deliberately installed 64 all-zero bytes, CRC32 <code>758d6336</code>, in       place of <code>/meshcore/ui-font.vlw</code>; the ESP32 rejected that asset and kept       its built-in fallback font while recovery ran.</li> <li>[x] Every new HTTPS recovery attempt waits for a fresh SNTP callback and a       signed epoch at or after the compiled asset publication time before it       opens TLS. The forced-resume run observed fresh syncs in 3,700, 400, and       699 ms across three outer attempts, including two failed TLS handshakes;       the final normal run synced in 1,999 ms and only then logged the first       <code>api.github.com</code> connection. A retained merely plausible clock is not       accepted. CA validation and the compiled asset SHA-256 remain mandatory.</li> <li>[x] The release-source normal path downloaded all 1,302,608 bytes into PSRAM       in 13,205 ms, closed TLS, verified SHA-256       <code>61bce9662db314054e7bcfaa26147a28ad7b500b51baac4cae1caacce90b7421</code>,       staged receiver-paced 512-byte <code>MCFONT STAGEV2</code> chunks in 36,676 ms,       committed, and verified RP CRC32 <code>19f80d64</code> at 76.7 seconds from reset.       An independent <code>MCFONT GET</code> over RP USB then returned exactly 1,302,608       bytes with the same CRC and SHA in 15.273 seconds. The exact installed       application is       <code>SenseCapIndicator-LoRa_companion_radio_full-1.17.1.5-halo-keymind-cascade-marathon-font-recovery-e26d48e4.bin</code>;       its log is       <code>/home/mikec/hwtest/runs/indicator-release-recovery-lUZEmBHL/esp-serial.log</code>       on Mercerwood. The current RP service reports protocol 2 and completed       STAGEV2 accounting; its installed flash was not independently read back,       so no RP artifact hash is inferred from the archived candidates.</li> <li>[x] Strict Range recovery passed a forced hardware interruption. Exact test       application SHA-256       <code>cfd5aec497cb9919f87c0f82f5deaf8614d411582a709cea1c36275529c0bb68</code>       closed the initial response at verified offset 1,048,576. Its first       same-offset resume handshake failed; bounded retry 2/2 then accepted only       the remaining 254,032-byte <code>206</code> response under the original strong       ETag/<code>If-Range</code>, retained the same PSRAM buffer and SHA stream, completed       the download in 49,422 ms, staged in 36,702 ms, committed, and passed an       independent exact USB readback. The full log is       <code>/home/mikec/hwtest/runs/indicator-range-v2-xbKr09wI/esp-serial.log</code>.       An earlier forced 512 KiB run proved one correct resume at 524,288 but       later exhausted its second reconnect on a TLS failure; it is retained as       regression-trigger evidence rather than an end-to-end pass.</li> <li>[x] Rebooting the exact release-source application with the current valid       font performed no NTP query, TLS connection, or GitHub request. The       valid-font boot log is       <code>/home/mikec/hwtest/runs/indicator-release-valid-a84vd7Du/esp-serial.log</code>.</li> <li>[x] The post-qualification shared SNTP-coordinator source compiles in the       real Arduino-ESP32 2.x LoRa USB/WiFi profile (1,587,965 bytes, 60.6% of       its OTA slot), the dynamically generated ESP-NOW Full profile (2,093,465       bytes, 79.9%), and the matching RP2040 transactional service. After the       VM independently reported <code>NTPSynchronized=yes</code>, an       end-to-end request to the immutable GitHub asset returned HTTP 200,       exactly 1,302,608 bytes, and SHA-256       <code>61bce9662db314054e7bcfaa26147a28ad7b500b51baac4cae1caacce90b7421</code>.       A live <code>524288-1302607</code> continuation then returned HTTP 206, the same       strong ETag, an exact 778,320-byte <code>Content-Length</code>, and a byte-for-byte       hash match against the checked-in font tail; the pinned Sectigo E46 root       independently verified the current <code>api.github.com</code> chain.       The same coordinator also compiles in the real       <code>heltec_v4_repeater_observer_mqtt</code> profile: its 1,852,392-byte EndF image       has SHA-256       <code>fe8352654437f67488b412e1c1a690f2874e836abb5a5d209654bd030c713d7e</code>.       MQTT's three process-global <code>configTime()</code> paths are lease-protected,       and a busy asynchronous refresh uses a wrap-safe five-second retry       deadline instead of overwriting another service's SNTP callback or       recording a false successful refresh.       The exact final LoRa Full artifact gate then passed 11/11 linked-image       markers, including both <code>requesting fresh NTP time before download</code> and       the subsequent TLS-open marker. Its 2,146,312-byte application has       SHA-256       <code>f557088a5ef3f49f74ab01ca95fefc76911cca4073f01b77cee4882284fc5110</code>       and 475,128 bytes remain in its app slot; the matching 2,211,848-byte DIO       merged image has SHA-256       <code>52a4559774384b54dd7fb81da82c791e2c9564991fcf016bcad3b6ad756c1fb2</code>.       The exact ELF, map, capability manifest, and partition signature are       archived together under <code>/tmp/indicator-full-daily-ntp.WQ6ozM</code> on       the VM pending transfer to the hardware-run archive.       The ESP-NOW Full sibling passed the same 11/11 gate with a 2,093,928-byte       application (527,512 bytes free), SHA-256       <code>fcd9e0e8a37551a845a234fc10eaa4a9f420d54172039b9241f4696a12d4c65f</code>,       and matching DIO merged-image SHA-256       <code>f3637c23f58204f5b752b68a1bd494601cb68bee9c27b664832d40abd03cc186</code>;       its complete archive is <code>/tmp/indicator-espnow-full-ntp-gate.YN9T8l</code>.       Repeat the negative UDP/123-blocked hardware gate on this exact final       source before treating the coordinator refinement as hardware-qualified.</li> <li>[ ] Full Wi-Fi SSID, setup address, and related status text wrap without       clipping on the physical display. The new dark palette and exclusive       lower pairing block are installed; a fresh bond removal held the random       PIN request on-screen for 30 seconds and then an immediate second attempt       paired, trusted, and returned the exact Indicator identity over BLE. A       human physical-readability confirmation is still required; the automated       geometry tests prove the PIN block is centered at four-fifths height and       cannot overlap IP, inbox, or status text.</li> <li>[ ] Boot the exact current LoRa and ESP-NOW Full artifacts in both saved       secondary-transport modes and capture the <code>Indicator render</code> line. Require       LoRa + WiFi, LoRa + BLE, and ESP-NOW + infrastructure WiFi to retain       480x480, and ESP-NOW + BLE to select 320x320 scaled to the panel. A logged       emergency 320x320 fallback keeps the unit recoverable but does not pass a       native-480 gate.</li> <li>[ ] For all four boots, record free heap and largest internal block before       interfaces and after the selected interface is usable. In WiFi mode prove       BLE never starts; in BLE mode prove infrastructure WiFi, WebConfig, MQTT,       and TCP never start. Keep the primary LoRa or ESP-NOW radio exchanging       traffic throughout. For both BLE modes pair/encrypt, negotiate MTU,       subscribe, exchange repeated Companion requests, disconnect/reconnect,       and repeat after bond removal; exercise network/TCP traffic in both WiFi       modes and record the lowest heap/largest-block values.</li> <li>[x] With no saved SSID, setup Wi-Fi powers down after the absolute 30-minute       window even if queried or used.</li> <li>[x] A software reboot starts a fresh unconfigured setup window.</li> <li>[x] With a saved SSID, Wi-Fi reconnects to <code>SlowFi</code>, reports minimum modem       power save, and remains governed by normal configured-network behavior.</li> <li>[x] Bluetooth Companion pairing and protocol operations pass after saving a       deterministic qualification PIN, removing any stale host bond, pairing,       disconnecting the <code>bluetoothctl</code> client, and reconnecting with meshcli.       Binary <code>infos</code>/<code>ver</code> returned the exact Indicator identity and USA tuple.       A second connection after the USB-open reboot and logging-mode exercise       also returned the exact build; one initial scanner miss was resolved by       an explicit BlueZ discovery pass and was not a firmware advertisement       failure.</li> <li>[x] Wi-Fi/TCP Companion, CLI, and OTA endpoints pass at <code>192.168.1.54</code>:       port 5000 returned Binary Companion identity, port 5002 returned the full       text version/status, and motatool completed a port-5001 <code>COUNT -&gt; 0</code>       protocol exchange against an empty served folder.</li> <li>[x] Fresh Full starts with USB logging off. On this single-TTY ESP32 profile,       logging on/off applies and persists without a descriptor-changing reboot;       the same held-open ASCII terminal reported off -&gt; on -&gt; off correctly,       emitted live Wi-Fi/radio diagnostics while on, then accepted the explicit       terminal-stop token and returned a valid 85-byte Binary Companion device       info frame for <code>Seeed SenseCAP Indicator</code> without rebooting. Companion       remained independently usable over Bluetooth and Wi-Fi.</li> <li>[x] Normal-radio LoRa transmit and receive pass. At the installed 22 dBm,       a co-located discovery request overloaded the nearby receivers and found       zero nodes; temporarily reducing only the Indicator to 0 dBm produced       three repeater replies at RSSI -29 to -59 dBm, proving both directions.       The saved 22 dBm value was restored and independently read back after the       test; this near-field result is a lab-power gate, not a firmware failure.</li> <li>[ ] TempRadio sanity check, OTA seeding, and normal-radio restoration pass.</li> </ul>"},{"location":"hardware_validation_checklist/#cross-radio-lora-ota-acceptance","title":"Cross-radio LoRa OTA acceptance","text":"<ul> <li>[ ] Run a three-minute reachability preflight before staging or changing any       repeater radio settings.</li> <li>[ ] Test direct, fully controlled multi-hop, passive TempRadio hop, and mixed       controlled/passive paths independently.</li> <li>[ ] Record bytes, LoRa packets sent, packets confirmed, retries, useful       throughput, total elapsed time, and per-phase elapsed time.</li> <li>[ ] Confirm every controlled intermediate returns to its saved radio tuple.</li> <li>[ ] Verify target application and bootloader hashes after apply, not merely the       OTA tool's final status line.</li> <li>[ ] Exercise interruption/retry and confirm incomplete data cannot be approved       or booted.</li> </ul>"},{"location":"host_cli_service/","title":"LoRa CLI Host Service","text":"<p>The repeater <code>host &lt;text&gt;</code> command lets an authenticated LoRa administrator request a small, explicitly allowed operation from a USB-connected computer. The included Raspberry Pi endpoint supports these exact requests:</p> <pre><code>cmd host help\ncmd host cpu-temp\ncmd host hostname\ncmd host uptime\ncmd host load\ncmd host memory\ncmd host disk-free\ncmd host clock status\ncmd host clock sync\ncmd host clock set &lt;unix_epoch&gt;\ncmd host network restart\ncmd host reboot\ncmd host action status &lt;operation_id&gt;\ncmd host run &lt;alias&gt; [arguments]\n</code></pre> <p>The first seven actions after <code>help</code> are read-only. Clock changes, network restart, and reboot are opt-in actions and are disabled unless explicitly enabled. Text such as <code>reboot now</code>, <code>cpu-temp; reboot</code>, and embedded newlines is not a command: the endpoint accepts only an exact allowlist match.</p> <p>The bridge is included in normal repeater firmware except on Wio-E5. Its specialized RS232 bridge image omits the host service because the combined application exceeds the fixed 240 KiB partition; use the normal Wio-E5 repeater image when the USB/MQTT host service is needed.</p>"},{"location":"host_cli_service/#run-alongside-meshcoretomqtt","title":"Run alongside meshcoretomqtt","text":"<p><code>meshcoretomqtt</code> must remain the only process that opens the repeater USB serial port. The endpoint communicates with it through the same MQTT broker, which can be local to the Raspberry Pi:</p> <pre><code>LoRa -&gt; repeater -&gt; USB -&gt; meshcoretomqtt -&gt; MQTT -&gt; host endpoint\nLoRa &lt;- repeater &lt;- USB &lt;- meshcoretomqtt &lt;- MQTT &lt;- host endpoint\n</code></pre> <p>Clock-recovery deployments must run the loopback broker, <code>meshcoretomqtt</code>, and endpoint on the same Pi. A wrong Pi clock can prevent TLS validation against a remote broker, while split host clocks can reject the signed live claim before the correction arrives. Remote brokers remain suitable for ordinary commands when the connection and both clocks are already healthy.</p> <p>Launch <code>meshcoretomqtt</code> with its existing arguments plus <code>--debug</code>; its current debug-topic parser needs that flag to publish the repeater request record. Do not open the serial TTY from the host endpoint too.</p> <p>This feature does not compare the repeater wall clock with the Pi clock. Minutes of drift, an unset repeater clock, and later clock corrections are safe: request freshness comes from a live one-time challenge. The normal <code>meshcoretomqtt</code> <code>sync_time</code> setting may remain enabled for its other uses, but host-command authorization does not depend on it.</p> <p>Generate a dedicated service key using the Python environment installed by <code>meshcoretomqtt</code>:</p> <pre><code>sudo /opt/mctomqtt/venv/bin/python3 host_cli_service.py \\\n  --generate-key /etc/mctomqtt/host-cli-key.json\nsudo chown mctomqtt:mctomqtt /etc/mctomqtt/host-cli-key.json\nsudo chmod 600 /etc/mctomqtt/host-cli-key.json\n</code></pre> <p>Add the printed public key to the existing <code>meshcoretomqtt</code> configuration:</p> <pre><code>[remote_serial]\nenabled = true\nallowed_companions = [\n  \"SERVICE_PUBLIC_KEY_PRINTED_ABOVE\"\n]\nnonce_ttl = 120\ncommand_timeout = 10\n</code></pre> <p>Restart <code>meshcoretomqtt</code>, then run the endpoint. Replace <code>USA</code> with the exact three-character IATA namespace configured in the broker and supply the repeater's complete 64-character public key:</p> <pre><code>sudo -u mctomqtt /opt/mctomqtt/venv/bin/python3 host_cli_service.py \\\n  --broker 127.0.0.1 \\\n  --iata USA \\\n  --repeater-key REPEATER_PUBLIC_KEY \\\n  --service-key /etc/mctomqtt/host-cli-key.json\n</code></pre> <p>Add <code>--username NAME --password-file FILE</code> for broker authentication. Add <code>--tls</code>, and optionally <code>--ca-cert FILE</code>, for TLS. Custom installations can use <code>--request-topic</code> and <code>--command-topic</code> to match their broker namespace. The endpoint source and its systemd/configuration details are in <code>examples/host_cli_service</code>.</p>"},{"location":"host_cli_service/#allowlisted-programs-and-arguments","title":"Allowlisted programs and arguments","text":"<p>Add <code>--programs-file FILE</code> to expose locally selected programs as <code>host run &lt;alias&gt; [arguments]</code>. The example JSON file fixes each executable, fixed leading arguments, maximum 1-5 second runtime, and the exact remote argument schema. For example:</p> <pre><code>cmd host run fan on 15\n</code></pre> <p>The example maps that request to the fixed process argument vector:</p> <pre><code>/usr/local/bin/mesh-fan-control --source lora on 15\n</code></pre> <p>The supported argument rules are an explicit non-option <code>choice</code>, a bounded nonnegative <code>integer</code>, or a short <code>token</code> using a restricted ASCII character set. Alias lookup and every argument validation happen before process creation. Execution uses an absolute configured path, no stdin, <code>shell=False</code>, a minimal environment, and <code>/</code> as its working directory. Extra arguments, leading-option injection, shell syntax, control characters, and invalid quoting are rejected. The allowlist file and executable must not be group- or world-writable.</p> <p>Copy and edit <code>programs.example.json</code>, then give the service account only the operating-system permissions needed by those trusted programs.</p>"},{"location":"host_cli_service/#opt-in-network-and-reboot-recovery","title":"Opt-in network and reboot recovery","text":"<p>These actions use their own socket-activated root broker, independently of the clock-control broker. Installing or enabling clock control does not grant host recovery actions. Install the following as root-owned files:</p> <pre><code>sudo install -o root -g root -m 0755 meshcore_host_actions.py \\\n  /usr/local/sbin/meshcore-host-actions\nsudo install -o root -g root -m 0644 meshcore-host-actions.socket \\\n  /etc/systemd/system/meshcore-host-actions.socket\nsudo install -o root -g root -m 0644 meshcore-host-actions.service \\\n  /etc/systemd/system/meshcore-host-actions.service\nsudo install -o root -g root -m 0644 meshcore-networkmanager-restart.service \\\n  /etc/systemd/system/meshcore-networkmanager-restart.service\nsudo install -o root -g root -m 0644 meshcore-host-reboot.timer \\\n  /etc/systemd/system/meshcore-host-reboot.timer\nsudo install -o root -g root -m 0644 meshcore-host-reboot.service \\\n  /etc/systemd/system/meshcore-host-reboot.service\n</code></pre> <p>The root-owned broker policy enables nothing by default. Create a systemd drop-in and select <code>network-restart</code>, <code>reboot</code>, or both as an exact comma-separated list:</p> <pre><code>sudo systemctl edit meshcore-host-actions.service\n</code></pre> <pre><code>[Service]\nEnvironment=MESHCORE_HOST_ACTIONS=network-restart,reboot\n</code></pre> <p>Reload systemd and enable only the broker socket:</p> <pre><code>sudo systemctl daemon-reload\nsudo systemctl enable --now meshcore-host-actions.socket\n</code></pre> <p>After changing the policy on an already active installation, restart <code>meshcore-host-actions.service</code> so the broker reads the new value.</p> <p>Finally add <code>--allow-network-restart</code>, <code>--allow-reboot</code>, or both to the unprivileged endpoint. An action must pass both gates: the endpoint flag and the root-owned broker policy. The endpoint never invokes <code>sudo</code>; remove legacy <code>wifi-restart</code> program aliases and host-action sudoers entries because sudo aliases are not a fallback for this hardened service. Use the exact <code>host network restart</code> action instead.</p> <p>Systemd creates <code>/run/meshcore-host-actions.sock</code> as <code>root:mctomqtt</code> mode <code>0660</code>. The root broker authenticates both the endpoint UID and primary GID with <code>SO_PEERCRED</code>, while the endpoint authenticates the root-created listener. The protocol is one bounded ASCII line. Neither the caller nor request text can choose an executable, unit, path, or argument. The broker can start only the fixed static NetworkManager restart service or the fixed reboot timer; the broker and action units have empty capability sets and systemd sandboxing. The configured <code>mctomqtt</code> UID and its effective primary GID are the delegated local trust boundary; supplementary group membership alone is rejected.</p> <p>Side effects follow a fail-closed two-phase sequence. The endpoint reserves a canonical 128-bit operation ID with <code>PREPARE</code>, publishes its reply with MQTT QoS 1, and requires <code>wait_for_publish</code> plus <code>is_published</code> confirmation before sending one <code>COMMIT</code>. It does not block the Paho network callback while waiting. No confirmation means no commit. Reboot uses a fixed approximately 10-second timer that starts only after commit. The MQTT confirmation proves acceptance by the local broker, not delivery over USB and LoRa; there is no correlated serial delivery acknowledgement, so the physical reply is best effort.</p> <p><code>network restart</code> deliberately drops Wi-Fi and Tailscale management while NetworkManager restarts. Use a loopback MQTT broker and keep the broker, <code>meshcoretomqtt</code>, host endpoint, and USB device services independent of NetworkManager: they must not have <code>Requires=</code>, <code>BindsTo=</code>, or ordering dependencies on it. This preserves the local reply/commit path while remote management temporarily disappears.</p> <p>The operation ID is derived from the authenticated repeater key, request ID, and nonce. The reply displays it, and its state can be queried later:</p> <pre><code>cmd host action status 0123456789ABCDEF0123456789ABCDEF\n</code></pre> <p>The root broker retains at most 64 records for the current boot. It persists <code>prepared</code> before replying and <code>in-progress</code> before scheduling, schedules a committed operation at most once, and never automatically retries an ambiguous outcome. A broker restart converts recovered <code>in-progress</code> to <code>ambiguous</code>. Only an old uncommitted <code>prepared</code> record may be evicted; otherwise a full store rejects new work. Reusing an operation ID for a different action is rejected. <code>scheduled</code> means PID 1 accepted the fixed unit job; it does not claim that the subsequent network restart or reboot completed successfully.</p> <p>A distinct reboot is rejected while another reboot is committed or ambiguous, so a second request cannot falsely promise a fresh 10-second timer while the first timer is already running. A new reboot reservation may supersede only an older, uncommitted reboot reservation; the superseded operation can no longer be committed.</p>"},{"location":"host_cli_service/#opt-in-clock-recovery","title":"Opt-in clock recovery","text":"<p><code>clock status</code> reports the Pi epoch and NTP synchronization state without root access. To enable the exact <code>clock sync</code> and <code>clock set &lt;unix_epoch&gt;</code> actions, install <code>meshcore_clock_control.py</code> as <code>/usr/local/sbin/meshcore-clock-control</code>, owned by root and mode <code>0755</code>, then install the accompanying <code>meshcore-clock-control.socket</code> and <code>meshcore-clock-control.service</code> and static <code>meshcore-chrony-step.service</code> files in <code>/etc/systemd/system</code> as root-owned mode-<code>0644</code> files:</p> <pre><code>sudo install -o root -g root -m 0755 meshcore_clock_control.py \\\n  /usr/local/sbin/meshcore-clock-control\nsudo install -o root -g root -m 0644 meshcore-clock-control.socket \\\n  /etc/systemd/system/meshcore-clock-control.socket\nsudo install -o root -g root -m 0644 meshcore-clock-control.service \\\n  /etc/systemd/system/meshcore-clock-control.service\nsudo install -o root -g root -m 0644 meshcore-chrony-step.service \\\n  /etc/systemd/system/meshcore-chrony-step.service\nsudo systemctl daemon-reload\nsudo systemctl enable --now meshcore-clock-control.socket\n</code></pre> <p>The socket is fixed at <code>/run/meshcore-clock-control.sock</code>; systemd creates it as <code>root:mctomqtt</code> with mode <code>0660</code>. Run the endpoint as user and primary group <code>mctomqtt</code>, then add <code>--allow-clock-control</code>. The endpoint validates the socket metadata and authenticates the connected server as root with Linux <code>SO_PEERCRED</code>. The root service independently requires the peer's UID and primary GID to match <code>mctomqtt:mctomqtt</code> before it reads or executes a request. No clock-control sudo rule is used; remove old clock-helper sudoers lines when upgrading.</p> <p>Both layers require one canonical unsigned decimal argument with no sign, leading zero, whitespace, or trailing text. The accepted epoch range is 2020 through 2099. The private protocol accepts only the complete bounded ASCII lines <code>sync</code> and <code>set &lt;epoch&gt;</code>. Every child process uses a fixed absolute argv, <code>shell=False</code>, and a timeout no longer than 1.5 seconds.</p> <p><code>clock set</code> changes <code>CLOCK_REALTIME</code> without disabling NTP, then requests an NTP step. If the NTP request fails, the response honestly reports that the clock changed and which synchronization step remains incomplete. If <code>clock sync</code> enables NTP but the explicit step/restart fails, that partial outcome is also reported. When chrony is available, the root broker starts only the fixed static <code>meshcore-chrony-step.service</code>. That hardened one-shot runs <code>/usr/bin/chronyc -a makestep</code> as <code>_chrony:_chrony</code>, with no capabilities, <code>AF_UNIX</code> only, and a one-second start timeout; it can therefore reach chrony's private runtime socket without broadening the root broker. The <code>_chrony</code> account comes from the Debian/Raspberry Pi chrony package. Without chrony, the broker restarts systemd-timesyncd. Clock drift cannot authorize a captured command: the signed request still needs the repeater's live one-time claim, whose deadline is monotonic rather than wall-clock based.</p>"},{"location":"host_cli_service/#trust-and-injection-controls","title":"Trust and injection controls","text":"<p>The MQTT broker transports records but does not establish their authenticity. The endpoint checks the configured repeater identity and verifies its Ed25519 signature over the complete request ID, random nonce, and Base64URL request. It also validates framing, UTF-8, and byte limits. It does not execute that first record.</p> <p>Instead, the endpoint stores the request in memory, creates a random 64-bit challenge, and sends <code>@claim=&lt;random&gt;</code> through <code>meshcoretomqtt</code>'s signed serial channel. The repeater accepts it only from physical USB while the exact ID and nonce are pending, then signs a <code>CLAIMED</code> proof containing the challenge. Only a matching live proof lets the endpoint perform allowlist matching and execute the action. It consumes the proof before execution, so MQTT redelivery cannot execute an action twice.</p> <p>A captured request only causes a new challenge that an idle repeater refuses. A captured proof does not match a new challenge, and restarting the endpoint forgets pending challenges. Repeater/Pi clock drift therefore cannot turn an old <code>reboot</code> or <code>run</code> record into a valid action. The reply and claim commands still use short-lived JWTs; <code>meshcoretomqtt</code> checks their signer allowlist, target, expiration, signature, and separate replay nonce. Wall-clock expiry and its in-memory nonce cache are not sufficient across a backward clock jump plus restart; the firmware's live one-time claim is what protects these host actions. Keep recovery-mode <code>allowed_companions</code> limited to the dedicated service key, with the endpoint and <code>meshcoretomqtt</code> on the same Pi.</p> <p>Newlines and other reply control characters are converted to spaces and are also independently rejected by the firmware parser.</p> <p>Protect the service private key and use broker ACLs that allow it to subscribe only to the selected repeater debug topic and publish only to that repeater serial-command topic. A private key listed in <code>allowed_companions</code> is trusted to sign serial requests.</p>"},{"location":"host_cli_service/#limits","title":"Limits","text":"<ul> <li>The request is at most 155 UTF-8 bytes after <code>host</code>, or 152 bytes with the   legacy three-byte companion correlation prefix.</li> <li>The complete LoRa reply is at most 162 UTF-8 bytes.</li> <li>Only one host request can be pending per repeater.</li> <li>Only one privileged action or action-status query can be active; overlapping   work is rejected before reservation.</li> <li>The live claim must complete within 4 seconds. Allowlisted programs have a   configured 1-5 second child-process timeout. Privileged actions and status   queries share one 5-second broker/reply-confirmation deadline.</li> <li><code>host.reply</code> is accepted only through physical USB, not LoRa or Ethernet.</li> </ul> <p>Use <code>cmd get host</code> to report the bridge state and limits.</p>"},{"location":"kiss_modem_protocol/","title":"MeshCore KISS Modem Protocol","text":"<p>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.</p>"},{"location":"kiss_modem_protocol/#serial-configuration","title":"Serial Configuration","text":"<p>115200 baud, 8N1, no flow control.</p>"},{"location":"kiss_modem_protocol/#frame-format","title":"Frame Format","text":"<p>Standard KISS framing per the KA9Q/K3MC specification.</p> Byte Name Description <code>0xC0</code> FEND Frame delimiter <code>0xDB</code> FESC Escape character <code>0xDC</code> TFEND Escaped FEND (FESC + TFEND = 0xC0) <code>0xDD</code> TFESC Escaped FESC (FESC + TFESC = 0xDB) <pre><code>+------+-----------+--------------+------+\n| FEND | Type Byte | Data (escaped)| FEND |\n| 0xC0 |  1 byte   | 0-510 bytes  | 0xC0 |\n+------+-----------+--------------+------+\n</code></pre>"},{"location":"kiss_modem_protocol/#type-byte","title":"Type Byte","text":"<p>The type byte is split into two nibbles:</p> Bits Field Description 7-4 Port Port number (0 for single-port TNC) 3-0 Command Command number <p>Maximum unescaped frame size: 512 bytes.</p>"},{"location":"kiss_modem_protocol/#standard-kiss-commands","title":"Standard KISS Commands","text":""},{"location":"kiss_modem_protocol/#host-to-tnc","title":"Host to TNC","text":"Command Value Data Description Data <code>0x00</code> Raw packet Queue packet for transmission (one pending at a time) TXDELAY <code>0x01</code> Delay (1 byte) Transmitter keyup delay in 10ms units (default: 50 = 500ms) Persistence <code>0x02</code> P (1 byte) CSMA persistence parameter 0-255 (default: 63) SlotTime <code>0x03</code> Interval (1 byte) CSMA slot interval in 10ms units (default: 10 = 100ms) TXtail <code>0x04</code> Delay (1 byte) Post-TX hold time in 10ms units (default: 0) FullDuplex <code>0x05</code> Mode (1 byte) 0 = half duplex, nonzero = full duplex (default: 0) SetHardware <code>0x06</code> Sub-command + data MeshCore extensions (see below) Return <code>0xFF</code> - Exit KISS mode (no-op)"},{"location":"kiss_modem_protocol/#tnc-to-host","title":"TNC to Host","text":"Type Value Data Description Data <code>0x00</code> Raw packet Received packet from radio <p>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.</p> <p>Only one packet may be pending for radio transmission at a time. If the host sends a second Data frame before the first has completed, the modem responds with Error (0xF1) and TxBusy (0x07).</p>"},{"location":"kiss_modem_protocol/#host-output-backpressure","title":"Host Output Backpressure","text":"<p>Outbound frames are encoded into a 2-slot queue and flushed when serial output space is available; <code>loop()</code> never blocks on writes. Radio TX state advances independently of host read speed. TxDone is retained until it can be queued. If the outbound queue is full, the modem responds with Error (0xF1) and TxBusy (0x07). Hosts should read serial promptly to avoid delayed responses.</p>"},{"location":"kiss_modem_protocol/#csma-behavior","title":"CSMA Behavior","text":"<p>The TNC implements p-persistent CSMA for half-duplex operation:</p> <ol> <li>When a packet is queued, monitor carrier detect</li> <li>When the channel clears, generate a random value 0-255</li> <li>If the value is less than or equal to P (Persistence), wait TXDELAY then transmit</li> <li>Otherwise, wait SlotTime and repeat from step 1</li> </ol> <p>In full-duplex mode, CSMA is bypassed and packets transmit after TXDELAY.</p>"},{"location":"kiss_modem_protocol/#sethardware-extensions-0x06","title":"SetHardware Extensions (0x06)","text":"<p>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.</p>"},{"location":"kiss_modem_protocol/#frame-format_1","title":"Frame Format","text":"<pre><code>+------+------+-------------+--------------+------+\n| FEND | 0x06 | Sub-command | Data (escaped)| FEND |\n| 0xC0 |      |   1 byte    |   variable   | 0xC0 |\n+------+------+-------------+--------------+------+\n</code></pre>"},{"location":"kiss_modem_protocol/#request-sub-commands-host-to-tnc","title":"Request Sub-commands (Host to TNC)","text":"Sub-command Value Data GetIdentity <code>0x01</code> - GetRandom <code>0x02</code> Length (1 byte, 1-64) VerifySignature <code>0x03</code> PubKey (32) + Signature (64) + Data SignData <code>0x04</code> Data to sign EncryptData <code>0x05</code> Key (32) + Plaintext DecryptData <code>0x06</code> Key (32) + MAC (2) + Ciphertext KeyExchange <code>0x07</code> Remote PubKey (32) Hash <code>0x08</code> Data to hash SetRadio <code>0x09</code> Freq (4) + BW (4) + SF (1) + CR (1) SetTxPower <code>0x0A</code> Power dBm (1) GetRadio <code>0x0B</code> - GetTxPower <code>0x0C</code> - GetCurrentRssi <code>0x0D</code> - IsChannelBusy <code>0x0E</code> - GetAirtime <code>0x0F</code> Packet length (1) GetNoiseFloor <code>0x10</code> - GetVersion <code>0x11</code> - GetStats <code>0x12</code> - GetBattery <code>0x13</code> - GetMCUTemp <code>0x14</code> - GetSensors <code>0x15</code> Permissions (1) GetDeviceName <code>0x16</code> - Ping <code>0x17</code> - Reboot <code>0x18</code> - SetSignalReport <code>0x19</code> Enable (1): 0x00=disable, nonzero=enable GetSignalReport <code>0x1A</code> -"},{"location":"kiss_modem_protocol/#response-sub-commands-tnc-to-host","title":"Response Sub-commands (TNC to Host)","text":"<p>Response codes use the high-bit convention: <code>response = command | 0x80</code>. Generic and unsolicited responses use the <code>0xF0</code>+ range.</p> Sub-command Value Data Identity <code>0x81</code> PubKey (32) Random <code>0x82</code> Random bytes (1-64) Verify <code>0x83</code> Result (1): 0x00=invalid, 0x01=valid Signature <code>0x84</code> Signature (64) Encrypted <code>0x85</code> MAC (2) + Ciphertext Decrypted <code>0x86</code> Plaintext SharedSecret <code>0x87</code> Shared secret (32) Hash <code>0x88</code> SHA-256 hash (32) Radio <code>0x8B</code> Freq (4) + BW (4) + SF (1) + CR (1) TxPower <code>0x8C</code> Power dBm (1) CurrentRssi <code>0x8D</code> RSSI dBm (1, signed) ChannelBusy <code>0x8E</code> Result (1): 0x00=clear, 0x01=busy Airtime <code>0x8F</code> Milliseconds (4) NoiseFloor <code>0x90</code> dBm (2, signed) Version <code>0x91</code> Version (1) + Reserved (1) Stats <code>0x92</code> RX (4) + TX (4) + Errors (4) Battery <code>0x93</code> Millivolts (2) MCUTemp <code>0x94</code> Temperature (2, signed) Sensors <code>0x95</code> CayenneLPP payload DeviceName <code>0x96</code> Name (variable, UTF-8) Pong <code>0x97</code> - SignalReport <code>0x9A</code> Status (1): 0x00=disabled, 0x01=enabled OK <code>0xF0</code> - Error <code>0xF1</code> Error code (1) TxDone <code>0xF8</code> Result (1): 0x00=failed, 0x01=success RxMeta <code>0xF9</code> SNR (1) + RSSI (1)"},{"location":"kiss_modem_protocol/#error-codes","title":"Error Codes","text":"Code Value Description InvalidLength <code>0x01</code> Request data too short InvalidParam <code>0x02</code> Invalid parameter value NoCallback <code>0x03</code> Feature not available MacFailed <code>0x04</code> MAC verification failed UnknownCmd <code>0x05</code> Unknown sub-command EncryptFailed <code>0x06</code> Encryption failed TxBusy <code>0x07</code> Radio TX busy, or host output queue full"},{"location":"kiss_modem_protocol/#unsolicited-events","title":"Unsolicited Events","text":"<p>The TNC sends these SetHardware frames without a preceding request:</p> <p>TxDone (0xF8): Sent after radio transmission completes. Contains a single byte: 0x01 for success, 0x00 for failure. Delivery to the host may be delayed under serial backpressure but is not dropped.</p> <p>RxMeta (0xF9): Sent after each standard data frame (type 0x00) with SNR (1 byte, signed, value x4) and RSSI (1 byte, signed, dBm). Queued with the data frame; omitted if the data frame cannot be queued. Enabled by default; toggle with SetSignalReport. Standard KISS clients ignore this frame.</p>"},{"location":"kiss_modem_protocol/#data-formats","title":"Data Formats","text":""},{"location":"kiss_modem_protocol/#radio-parameters-setradio-radio-response","title":"Radio Parameters (SetRadio / Radio response)","text":"<p>All values little-endian.</p> Field Size Description Frequency 4 bytes Hz (e.g., 869618000) Bandwidth 4 bytes Hz (e.g., 62500) SF 1 byte Spreading factor (5-12) CR 1 byte Coding rate (5-8)"},{"location":"kiss_modem_protocol/#version-version-response","title":"Version (Version response)","text":"Field Size Description Version 1 byte Firmware version Reserved 1 byte Always 0"},{"location":"kiss_modem_protocol/#encrypted-encrypted-response","title":"Encrypted (Encrypted response)","text":"Field Size Description MAC 2 bytes HMAC-SHA256 truncated to 2 bytes Ciphertext variable AES-128 block-encrypted data with zero padding"},{"location":"kiss_modem_protocol/#airtime-airtime-response","title":"Airtime (Airtime response)","text":"<p>All values little-endian.</p> Field Size Description Airtime 4 bytes uint32_t, estimated air time in milliseconds"},{"location":"kiss_modem_protocol/#noise-floor-noisefloor-response","title":"Noise Floor (NoiseFloor response)","text":"<p>All values little-endian.</p> Field Size Description Noise floor 2 bytes int16_t, dBm (signed) <p>The modem recalibrates the noise floor every 2 seconds with an AGC reset every 30 seconds.</p>"},{"location":"kiss_modem_protocol/#stats-stats-response","title":"Stats (Stats response)","text":"<p>All values little-endian.</p> Field Size Description RX 4 bytes Packets received TX 4 bytes Packets transmitted Errors 4 bytes Receive errors"},{"location":"kiss_modem_protocol/#battery-battery-response","title":"Battery (Battery response)","text":"<p>All values little-endian.</p> Field Size Description Millivolts 2 bytes uint16_t, battery voltage in mV"},{"location":"kiss_modem_protocol/#mcu-temperature-mcutemp-response","title":"MCU Temperature (MCUTemp response)","text":"<p>All values little-endian.</p> Field Size Description Temperature 2 bytes int16_t, tenths of degC (e.g., 253 = 25.3degC) <p>Returns <code>NoCallback</code> error if the board does not support temperature readings.</p>"},{"location":"kiss_modem_protocol/#device-name-devicename-response","title":"Device Name (DeviceName response)","text":"Field Size Description Name variable UTF-8 string, no null terminator"},{"location":"kiss_modem_protocol/#reboot","title":"Reboot","text":"<p>Sends an <code>OK</code> response, flushes serial, then reboots the device. The host should expect the connection to drop.</p>"},{"location":"kiss_modem_protocol/#sensor-permissions-getsensors","title":"Sensor Permissions (GetSensors)","text":"Bit Value Description 0 <code>0x01</code> Base (battery) 1 <code>0x02</code> Location (GPS) 2 <code>0x04</code> Environment (temp, humidity, pressure) <p>Use <code>0x07</code> for all permissions.</p>"},{"location":"kiss_modem_protocol/#sensor-data-sensors-response","title":"Sensor Data (Sensors response)","text":"<p>Data returned in CayenneLPP format. See CayenneLPP documentation for parsing.</p>"},{"location":"kiss_modem_protocol/#cryptographic-algorithms","title":"Cryptographic Algorithms","text":"Operation Algorithm Identity / Signing / Verification Ed25519 Key Exchange X25519 (ECDH) Encryption AES-128 block encryption with zero padding + HMAC-SHA256 (MAC truncated to 2 bytes) Hashing SHA-256"},{"location":"kiss_modem_protocol/#notes","title":"Notes","text":"<ul> <li>Data payload limit (255 bytes) matches MeshCore MAX_TRANS_UNIT; no change needed for KISS \"1024+ recommended\" (that applies to general TNCs, not MeshCore)</li> <li>Modem generates identity on first boot (stored in flash)</li> <li>All multi-byte values are little-endian unless stated otherwise</li> <li>SNR values in RxMeta are multiplied by 4 for 0.25 dB precision</li> <li>TxDone is sent as a SetHardware event after each transmission</li> <li>Standard KISS clients receive only type 0x00 data frames and can safely ignore all SetHardware (0x06) frames</li> <li>See packet_format.md for packet format</li> </ul>"},{"location":"lora_ota_automation/","title":"Scripted LoRa OTA from start to finish","text":"<p>The dedicated RAK3401 chain report records the physical failures of withdrawn migrations and the physically qualified compact nine-step replacement. Its runner blocks the withdrawn chains and pins every accepted bridge image by SHA-256.</p> <p><code>tools/lora_ota/lora_ota.sh</code> and <code>tools/lora_ota/lora_ota.ps1</code> automate a MeshCore LoRa firmware update from a release <code>.zip</code> or ready <code>.mota</code>. They identify the destination, validate the hardware and running firmware, prepare the right container, move the participating nodes to a temporary radio channel, serve and monitor the download, request installation, restore the controller, and check the rebooted node.</p> <p>The script cannot install the destination's first OTA-capable firmware. It is also deliberately application-only: it rejects both v3 bootloader containers and a v2 container carrying the bootloader flag, and it never sends the privileged install command. Do the first nRF52 bootloader installation over USB. An already-capable, explicitly supported internal-flash, XIAO QSPI, or exact MeshTower V2 microSD repeater may later use the separate manual <code>ota bootloader install</code> workflow.</p>"},{"location":"lora_ota_automation/#required-topology","title":"Required topology","text":"<p>The reliable serial topology uses two local radios:</p> <pre><code>                                      authenticated admin commands\ncomputer -- MeshCore binary API --&gt; controller Companion -------------------+\n   |                                                                         |\n   +-- raw text CLI + mOTA seeder --&gt; OTA source ---- LoRa OTA blocks ----&gt; target\n                                                        |                    ^\n                                                        +-- relay(s) --------+\n</code></pre> <ul> <li>Controller: a Companion connected through serial, TCP, or BLE. The   script uses <code>meshcli</code> to send remote admin commands to the target and changes   the controller's live radio parameters during the transfer. A serial   Companion stays in its normal Binary USB mode at 115200 baud.</li> <li>OTA source: an OTA-enabled repeater/FULL node whose USB port is a raw   text CLI, an ESP32 <code>companion_radio_full</code> using WiFi ports 5001 and 5002, or   an nRF52 <code>companion_radio_full</code> whose USB port switches between Binary,   terminal control, and exclusive mOTA seeding.</li> <li>Target: an OTA-enabled ESP32 or nRF52 node present in the controller's   contact list. Its admin password is required.</li> <li>Relays: optional. They do not need to install OTA themselves, but every   relay on the path must be running current firmware and have an overlapping   TempRadio window.</li> </ul> <p>One serial port cannot serve both controller roles: <code>meshcli</code> must keep reopening the controller while <code>motatool</code> owns the source port. The script rejects an attempt to use the same port for both.</p> <p>The USB ASCII switch (<code>+++MESHCORE-TERM-START</code>) is the local control path, not the mOTA data framing. On an nRF52 dual-CDC Full Companion, the script uses that mode briefly for <code>ota status</code> and TempRadio commands. It then closes the CLI and starts <code>motatool</code>; the exact <code>ota folder on</code> preamble switches the same USB interface <code>00</code> into exclusive mOTA mode from either startup ASCII or Binary Companion mode. If USB logging was enabled and the Full Companion rebooted, its separate interface <code>02</code> continues to provide plaintext logging and is not a controller or source port. With default logging off, interface <code>02</code> is not enumerated. BLE remains available.</p> <p>ESP32 Full Companion normally uses its dedicated TCP seeder on port 5001. ESP32 builds that also retain serial folder support use the same exclusive USB mOTA ownership state as nRF52. The exact <code>ota folder on</code> line transfers the USB port from startup ASCII or idle Binary Companion mode before binary mOTA frames begin; neither console mode shares that port until the folder detaches.</p>"},{"location":"lora_ota_automation/#destination-requirements","title":"Destination requirements","text":"Destination Package installed One-time prerequisite Raw ZIP handling ESP32 Full application image OTA-enabled image with an A/B partition table Builds a full mOTA from the matching non-merged application <code>.bin</code> nRF52, internal flash In-place delta Exact-board OTAFIX bootloader with mOTA apply support Requires <code>--base</code> with the exact image currently running nRF52 repeater, external QSPI Full image or in-place delta QSPI-aware exact-board OTAFIX bootloader and matched repeater build Builds a full mOTA; adding <code>--base</code> requests a delta MeshTower V2 nRF52, microSD Full image or in-place delta SD-aware exact-board OTAFIX bootloader and compatible card Builds a full mOTA; adding <code>--base</code> requests a delta <p>MeshTower V2 microSD application and bootloader containers require an Ed25519 signature from a key in the device allowlist. Supply <code>--sign-key</code> when the runner must build a container, and install the BLM2-capable SD-aware bootloader locally before attempting application or bootloader OTA. Preview.12 requires USB/BLE DFU or SWD; see MeshTower V2 microSD LoRa OTA.</p> <p>The firmware inside a raw ZIP must have a valid MeshCore <code>EndF</code> trailer. An ESP32 merged/factory image is not an application image and is rejected. A generic vendor DFU ZIP may also be unusable if it does not contain the raw EndF-bearing <code>.hex</code> or <code>.bin</code>.</p> <p>For an internal-staging nRF52, the exact base image is irreducible information. The node reports its eight-byte body hash, but that hash cannot reconstruct the firmware bytes needed to create a delta. Keep the <code>.pio/build/ENV/firmware.hex</code> that was actually flashed. A matching filename or version alone is not enough.</p>"},{"location":"lora_ota_automation/#1-install-the-host-tools","title":"1. Install the host tools","text":"<p>Install Python 3.10 or newer, Rust, Git, the official <code>meshcore-cli</code>, and the official <code>motatool</code>.</p> <p>On Bash:</p> <pre><code>python3 -m pip install --user pipx\npython3 -m pipx ensurepath\npipx install meshcore-cli\n\ngit clone https://github.com/vk496/motatool.git\ncargo install --path ./motatool\n\nmeshcli -v\nmotatool --version\n</code></pre> <p>On PowerShell:</p> <pre><code>py -m pip install --user pipx\npy -m pipx ensurepath\npipx install meshcore-cli\n\ngit clone https://github.com/vk496/motatool.git\ncargo install --path .\\motatool\n\nmeshcli -v\nmotatool --version\n</code></pre> <p>Restart the shell if <code>pipx</code> or Cargo reports that it changed <code>PATH</code>.</p>"},{"location":"lora_ota_automation/#2-identify-and-test-both-local-links","title":"2. Identify and test both local links","text":"<p>List serial devices:</p> <pre><code>meshcli -l\n</code></pre> <p>The examples below assume <code>/dev/ttyACM0</code> is the controller and <code>/dev/ttyACM1</code> is the OTA source. On Windows they might be <code>COM7</code> and <code>COM8</code>. Close picocom, a serial monitor, the phone app, and any other program holding either link.</p> <p>Test the controller's binary API:</p> <pre><code>meshcli -s /dev/ttyACM0 -b 115200 ver\n</code></pre> <p>For an ordinary raw-text source, test its OTA support:</p> <pre><code>meshcli -r -s /dev/ttyACM1 -b 115200 \"ota status\"\n</code></pre> <p>The command must print an <code>OTA | ... target:XXXXXXXX</code> status.</p> <p>For an nRF52 full Companion, open the source port with terminal mode selected automatically:</p> <pre><code>picocom -b 115200 \\\n  --imap spchex \\\n  --initstring $'+++MESHCORE-TERM-START\\r' \\\n  /dev/ttyACM1\n</code></pre> <p>Run <code>ota status</code>. It must report <code>OTA seeder</code>, <code>install:disabled</code>, and target <code>00000000</code>; send <code>+++MESHCORE-TERM-STOP</code> before closing the terminal. The automation detects and performs this token-wrapped preflight itself, so no extra command-line option is needed.</p> <p>For an ESP32 full Companion, test its separate WiFi control console instead:</p> <pre><code>printf 'ota status\\r\\n' | nc 192.168.1.50 5002\n</code></pre> <p>It must report <code>OTA seeder</code>, <code>install:disabled</code>, and target <code>00000000</code>.</p> <p>Changing a terminal to 57600 baud does not select ASCII mode. USB Companion builds and the normal raw management CLI use 115200 unless a particular build was explicitly configured otherwise.</p>"},{"location":"lora_ota_automation/#3-check-the-destination-once","title":"3. Check the destination once","text":"<p>The destination must be in the controller's contacts and remotely reachable on the normal channel. The script runs these authenticated checks itself:</p> <pre><code>ota status\nget bootloader.ver\nota self\nota stats\n</code></pre> <p>The script uses <code>get bootloader.ver</code> to distinguish ESP32 from nRF52 and, for nRF52, report the installed bootloader version. It then requires <code>ota self</code> to report <code>bootloader: apply OK</code>, <code>bootloader: QSPI apply OK</code>, or <code>bootloader: SD apply OK</code> and checks the reported bootloader ABI and codec mask against the selected package. If the version command is unavailable on older firmware, the script warns and falls back to the legacy <code>ota self</code> platform marker. If an nRF52 bootloader lacks the required capabilities, install the exact-board OTAFIX bootloader first. Current firmware also reports <code>maxblk:2048</code> near the front of both OTA replies. The runner treats a missing marker as the deployed 1 KiB receive limit, rejects a ready 2 KiB package for such a target before transfer, and passes the live limit to <code>motatool --block-size</code> when it builds from raw firmware. Thus updating an older target from a release ZIP produces a compatible 1 KiB package while a current target retains the 2 KiB application default. <code>ota stats</code> is only an optional EndF version probe. It uses one bounded retry cycle; unsupported firmware or a lost reply falls back directly to the required <code>ver</code> command instead of entering an operator continuation loop.</p> <p>The default TempRadio tuple is:</p> <pre><code>909.950,250,5,5,120\n</code></pre> <p>The test default is 250 kHz bandwidth, SF5, and CR5. The frequency is only a North American example: choose a legal frequency supported by every participating radio and appropriate to your location. Older radios that do not support SF5 require a complete replacement tuple passed with <code>--temp-radio</code>.</p> <p>Before that long window is allowed, the live runner performs a mandatory independent three-minute rehearsal. Its exact normal-channel <code>ota status</code> and <code>ota self</code> identity proof gets one shared four-minute, read-only budget before any schedule, radio override, seeder, or transfer is armed; this tolerates a marginal link without consuming or extending a live lease. It advances a stale managed controller with exact readback and treats a source terminal's whole-minute display as an uncertainty window, never as an exact epoch. A source minute overlapping the host is preserved; a completely stale minute is pinned to a guarded future value and read back once. Neither clock is moved backward, and the runner stops if a managed clock cannot be proven within the ten-minute limit. Each remote participant must expose an empty <code>tempradioat</code> schedule. The runner projects one fixed start/end interval into each participant's independently sampled RTC, sends each mutation once, proves every exact identity on the temporary tuple, waits for natural expiry, and proves the complete normal path again. A lost schedule reply is resolved by those on-air proofs; it is never blindly replayed with a fresh duration.</p> <p>The published RAK3401 <code>v1.16.7-c1caa5ad</code> LoRa-OTA image includes <code>get/set/del tempradioat</code> and can take this safe first step. A truly older or reduced build without fixed TempRadio scheduling is rejected before mutation; bootstrap it locally or with another explicitly controlled maintenance path. The automation does not substitute an immediate <code>tempradio</code> command whose first delivery could remain queued after cleanup.</p>"},{"location":"lora_ota_automation/#rxps-handling-during-tempradio","title":"RXPS handling during TempRadio","text":"<p>RXPS improves receive performance per unit of radio-on time, so the runner keeps the destination's saved RXPS preference enabled whenever the selected fast tuple has a qualified timing window. Before changing any radio, it reads <code>ver</code> from the destination, controller, source, and every named relay. It treats v1.17.1.5 as the first forward contract in which every SF5-SF8 transmission, including a retry, uses the same tuple-selected physical preamble: normally 32 symbols, 64 only when 32 cannot enable RXPS, and 128 only when neither 32 nor 64 can. A saved RXPS level is also safely retuned after a radio change. An older or unparseable destination version fails closed: the runner temporarily sends <code>set radio.rxps off</code> instead of assuming an ad-hoc build contains the timing fixes. Automation deliberately treats the version as a wire-format contract.</p> <p>For the default SF5/BW250 tuple, the runner keeps destination RXPS on only when the destination and every possible sender are v1.17.1.5 or newer. It does not overwrite an existing level-based preference. Current firmware retunes that preference against the tuple-selected 64-symbol wire preamble; the qualified boundary is effective level 8, preamble 64 (<code>1252 / 6424 us</code>). A manually configured node may save <code>set radio.rxps level 8 preamble 32</code> before entering TempRadio: when 32 symbols cannot cover the TCXO transition, firmware safely selects the real 64-symbol preamble. If the saved setting uses fixed manual timings, or even one participant is older or unknown, RXPS is temporarily off. This avoids the receive gap that a 32-symbol sender or an unretuned manual window would create.</p> <p>The complete qualified SX1262+TCXO policy is:</p> TempRadio SF/BW Saved reference setting Qualified boundary Automation SF7/BW500 <code>level 7 preamble 32</code> 7 / 32 RXPS on for a current destination SF6/BW250 <code>level 7 preamble 32</code> 7 / 32 RXPS on for a current destination SF5/BW125 <code>level 7 preamble 32</code> 7 / 32 RXPS on for a current destination SF5/BW250 <code>level 8 preamble 32</code> 8 / 64 RXPS on only when every participant follows the 64-symbol contract SF6/BW500 <code>level 8 preamble 32</code> 8 / 64 RXPS on only when every participant follows the adaptive-preamble contract SF5/BW500 <code>level 8 preamble 32</code> 8 / 128 RXPS on only when every participant follows the adaptive-preamble contract SF5/BW62.5 <code>level 10 preamble 16</code> 10 / 16 RXPS on for a current destination Unqualified tuple none continuous RX RXPS temporarily off <p>If RXPS was already off, the runner leaves it off. Otherwise it writes the original level, preamble assumption, receive/sleep periods, and temporary decision to protected <code>target-rxps-settings.json</code> in the run's working directory, verifies the temporary state, and restores the exact original setting after the target is back on its normal radio. Current firmware exposes this complete state through <code>get radio.rxps.config</code>; a legacy reply has only on/off and periods, so the runner can restore those periods but cannot reconstruct an unreported saved level. A radio change later recalculates from a preserved saved minimum, so moving back to a slower tuple returns to the operator's saved level.</p> <p>The OTA source has a stricter policy than the destination. For every source with a managed serial or TCP CLI, the runner reads and retains its exact RXPS preference, using the legacy fixed-period query only when the detailed query is unavailable. It builds and verifies the package, completes the read-only target checks, and obtains confirmation while that preference remains unchanged. Immediately before the first radio mutation, it reads the source RXPS state again, disables RXPS, and verifies the readback. Source RXPS stays off through catalog serving, download, installation, and post-install identity verification. Cleanup first proves that the source has returned to its normal radio, then restores and verifies the exact saved level/preamble or fixed-period state once. A source whose RXPS state cannot be read, disabled, or restored safely fails closed. If current firmware explicitly rejects an RXPS disable or restore with <code>radio busy; retry</code>, the runner retries that idempotent mutation at staggered 210\u2013378 ms intervals. All 32 delays are distinct and contribute about 9.4 seconds of waits; source-CLI command round-trip time is additional. This avoids repeatedly sampling one radio phase while retaining a strict attempt cap. Other rejections are not replayed.</p>"},{"location":"lora_ota_automation/#4-run-an-esp32-update","title":"4. Run an ESP32 update","text":"<p>The ZIP can contain a compatible ready <code>.mota</code> or the exact board-and-role non-merged application <code>.bin</code>:</p> <pre><code>export MESHCORE_ADMIN_PASSWORD='target-admin-password'\n\n./tools/lora_ota/lora_ota.sh ./release.zip \"Roof ESP32\" \\\n  --controller-serial /dev/ttyACM0 \\\n  --source-serial /dev/ttyACM1\n</code></pre> <p>The script shows the detected target, hardware, running hash, chosen package, version, manifest ID, and action before asking for confirmation. For an unattended job, add <code>--yes</code>:</p> <pre><code>./tools/lora_ota/lora_ota.sh ./release.mota \"Roof ESP32\" \\\n  --controller-serial /dev/ttyACM0 \\\n  --source-serial /dev/ttyACM1 \\\n  --yes\n</code></pre> <p>PowerShell equivalents:</p> <pre><code>$env:MESHCORE_ADMIN_PASSWORD = 'target-admin-password'\n\n&amp; .\\tools\\lora_ota\\lora_ota.ps1 '.\\release.zip' 'Roof ESP32' `\n  --controller-serial COM7 `\n  --source-serial COM8\n\n&amp; .\\tools\\lora_ota\\lora_ota.ps1 '.\\release.mota' 'Roof ESP32' `\n  --controller-serial COM7 `\n  --source-serial COM8 `\n  --yes\n</code></pre> <p>Prefer the environment variable or the interactive password prompt. Passing <code>--password</code> works, but the wrapper's own command line may be visible to other local processes. The runner keeps the password out of child <code>meshcli</code> command lines and removes its protected temporary command file after each call.</p>"},{"location":"lora_ota_automation/#5-run-an-nrf52-update","title":"5. Run an nRF52 update","text":"<p>If the input ZIP already contains a compatible in-place delta <code>.mota</code>, no base argument is needed: its embedded base hash is compared with the live node. If the ZIP contains raw new firmware, supply the exact running image:</p> <pre><code>./tools/lora_ota/lora_ota.sh ./nrf52-new-release.zip \"Hill nRF52\" \\\n  --base ./firmware-that-is-running.hex \\\n  --controller-serial /dev/ttyACM0 \\\n  --source-serial /dev/ttyACM1\n</code></pre> <pre><code>&amp; .\\tools\\lora_ota\\lora_ota.ps1 '.\\nrf52-new-release.zip' 'Hill nRF52' `\n  --base '.\\firmware-that-is-running.hex' `\n  --controller-serial COM7 `\n  --source-serial COM8\n</code></pre> <p>Before building a delta, the runner proves that the base's target ID, hardware identity, firmware version when available, and <code>EndF</code> body hash match the live destination. It then asks <code>motatool</code> for codec 2, the nRF52 in-place format. The normal workspace is <code>0x98000</code>.</p> <p>For a QSPI-backed repeater or the SD-backed MeshTower V2 target, a raw ZIP becomes a full image without <code>--base</code>. Supplying an exact base requests a smaller in-place delta and automatically selects the conservative external workspace <code>0xC6000</code>, which is safe for S140 v6 and v7 application layouts. An explicit <code>--inplace-memory</code> overrides the automatic value.</p> <p>The live runner detects QSPI from <code>ota self</code> (<code>QSPI apply OK</code>) or <code>ota status</code> (<code>bl:QSPI</code>) and refuses an explicit <code>QSPI store:ERR 0K</code> report even when the bootloader itself advertises QSPI apply support. Offline <code>--prepare-only</code> runs must supply <code>--nrf-qspi</code>; do not use that switch for a board that only exposes QSPI pins or uses the chip as a Companion filesystem. The application and bootloader must both be from the matched repeater list in the nRF52 QSPI guide.</p>"},{"location":"lora_ota_automation/#6-add-intermediate-relays","title":"6. Add intermediate relays","text":"<p>List relays from farthest to nearest so each command is sent before its route moves to TempRadio. A bare relay name uses the destination password; use <code>NAME=PASSWORD</code> when it differs:</p> <pre><code>./tools/lora_ota/lora_ota.sh ./release.mota \"Remote Target\" \\\n  --controller-serial /dev/ttyACM0 \\\n  --source-serial /dev/ttyACM1 \\\n  --relay \"Far Relay=far-password\" \\\n  --relay \"Near Relay=near-password\"\n</code></pre> <p>PowerShell uses the same arguments:</p> <pre><code>&amp; .\\tools\\lora_ota\\lora_ota.ps1 '.\\release.mota' 'Remote Target' `\n  --controller-serial COM7 `\n  --source-serial COM8 `\n  --relay 'Far Relay=far-password' `\n  --relay 'Near Relay=near-password'\n</code></pre>"},{"location":"lora_ota_automation/#other-connection-choices","title":"Other connection choices","text":"<p>The controller can use any one of:</p> <pre><code>--controller-serial PORT\n--controller-tcp HOST[:PORT]       # default port 5000\n--controller-ble ADDRESS_OR_NAME\n</code></pre> <p>An ESP32 FULL/repeater source can serve over its dedicated WiFi seeder port while its raw USB CLI is used to start TempRadio:</p> <pre><code>./tools/lora_ota/lora_ota.sh ./release.mota \"Remote Target\" \\\n  --controller-serial /dev/ttyACM0 \\\n  --source-tcp 192.168.1.50:5001 \\\n  --source-cli-serial /dev/ttyACM1\n</code></pre> <p>An ESP32 <code>companion_radio_full</code> uses WiFi for both dedicated source links:</p> <pre><code>./tools/lora_ota/lora_ota.sh ./release.mota \"Remote Target\" \\\n  --controller-serial /dev/ttyACM0 \\\n  --source-tcp 192.168.1.50:5001 \\\n  --source-cli-tcp 192.168.1.50:5002\n</code></pre> <p>Port 5002 defaults automatically when it is omitted from <code>--source-cli-tcp</code>. Current Full Companion firmware exposes its complete role-specific text terminal there; the runner uses only <code>ota</code>, <code>tempradio</code>, and <code>normalradio</code>, and remains compatible with older bounded port-5002 consoles. The source-only Companion never stages or installs the image itself; it streams the host folder to other nodes over LoRa. See the full Companion guide for manual operation and interface details.</p> <p>An nRF52 <code>companion_radio_full</code> uses one USB source port sequentially. The runner automatically wraps local control commands in the terminal tokens, and unmodified <code>motatool</code> switches that port into mOTA mode when seeding starts:</p> <p>The wrapper sends STOP, then START, before each command. This makes fallback independent of whether a prior raw probe left an unobservable USB-UART connection in ASCII or Binary mode. Seeder startup is reported only after the verbose device log contains its <code>COUNT</code> acknowledgement; an immediate device <code>ERR</code> or a missing acknowledgement fails during startup instead of surfacing later as a catalog timeout.</p> <pre><code>./tools/lora_ota/lora_ota.sh ./release.mota \"Remote Target\" \\\n  --controller-serial /dev/ttyACM0 \\\n  --source-serial /dev/ttyACM1\n</code></pre> <p>If the source is already on the exact TempRadio tuple through a scheduled or manual operation, <code>--source-already-temp</code> lets a TCP source run without a raw CLI link. The script cannot verify, extend, or shorten that source window, so leave a comfortable time margin. It also cannot inspect or change that unmanaged source's RXPS state; disable source RXPS yourself before starting the run and restore it only after returning the source to its normal radio.</p> <p>Use <code>--controller-baud</code> or <code>--source-baud</code> only for a build whose corresponding interface is genuinely configured to another speed.</p>"},{"location":"lora_ota_automation/#package-selection-and-safety-gates","title":"Package selection and safety gates","text":"<p>For a ZIP, the runner first examines every <code>.mota</code> without extracting paths. It keeps only packages matching the live target, hardware, base, platform, codec, and bootloader capabilities. It chooses the newest compatible version and prefers a delta over a full image at the same version. If equally suitable files differ, select one explicitly:</p> <pre><code>--zip-member path/inside/archive/update.mota\n</code></pre> <p>If no ready mOTA is usable, it searches <code>.bin</code> and <code>.hex</code> members for a valid, matching <code>EndF</code>, then builds the platform-appropriate container. Every result is structurally checked by the runner and independently passed through <code>motatool verify</code> before any radio changes. Direct firmware and mOTA inputs, as well as individual ZIP members, are rejected above 64 MiB before being loaded.</p> <p>Useful controls:</p> <ul> <li><code>--public-key signer.key.pub</code> requires a particular Ed25519 signer during   verification.</li> <li><code>--sign-key signer.key</code> signs a newly built container.</li> <li><code>--no-install</code> downloads and verifies the image but leaves it staged. By   default the runner then schedules the target, relays, and a script-configured   source back to their normal radios. Combining it with   <code>--leave-controller-radio</code> deliberately preserves the destination, relays,   and separate controller on the TempRadio topology; a managed source is still   returned to normal so its exact RXPS setting can be restored.   If the version gate required RXPS off, it stays off while that topology is   preserved; use <code>target-rxps-settings.json</code> to restore it only after sending   <code>normalradio</code>.</li> <li><code>--allow-non-upgrade</code> deliberately permits the same or an older version.</li> <li><code>--replace-active-download</code> deliberately discards a different update already   downloading or staged on the target. Without it, that update is preserved.</li> <li><code>--source-shares-controller</code> is for a Full Companion whose USB Binary API is   the controller while its TCP port <code>5001</code> is the source. It verifies that the   source's port-<code>5000</code> public key equals the controller key, then binds the   fresh port-<code>5002</code> Full Terminal banner's complete public key to that Binary   identity and challenges it with the supported <code>ver</code> command. It does not   assume the Full Terminal implements repeater-only <code>get public.key</code>. Port   <code>5002</code> uses a bounded local <code>tempradio</code> override to move the shared physical   radio without overwriting its saved normal tuple; the Binary API remains the   authenticated transport. Cleanup sends local <code>normalradio</code>, proves that   override inactive, and then reasserts the saved Binary tuple. It cannot be   combined with   <code>--leave-controller-radio</code>,   because exact source RXPS restoration requires that shared physical radio to   be back on its verified normal tuple.</li> <li><code>--require-system-watchdog-off</code> checks <code>get system.watchdog</code> immediately   before every <code>ota install</code> transmission and refuses installation unless the   destination reports <code>&gt; off</code>. Use it for nRF52 chains whose bootloader cannot   service an application watchdog inherited across reset.</li> <li>Managed <code>--relay</code> nodes have their original <code>rxdelay</code> and <code>txdelay</code> captured   in the work directory. During transfer the runner verifies <code>rxdelay 0</code> and   an airtime-scaled <code>txdelay 0.3</code> (override with <code>--relay-txdelay</code>), then   restores both values before the relay leaves TempRadio.</li> <li><code>--work-dir PATH</code> chooses a new, non-existent work directory.</li> <li><code>--meshcli PATH</code> and <code>--motatool PATH</code> select binaries not on <code>PATH</code>.</li> <li><code>--package-build-timeout SECONDS</code> bounds local mOTA generation. It defaults   to 3600 seconds. Run detools, delta/compression, and raw-firmware package   generation on a workstation or build VM, then transfer the completed,   hash-verified <code>.mota</code> to a Pi-class radio host. The Pi should perform only   lightweight identity-gated hardware I/O and serve that finished artifact;   preparation still occurs before any radio state changes.</li> <li><code>--debug</code> prints redacted child commands, timeouts, process status, stdout,   and stderr. Admin passwords are never printed, but node names, addresses,   paths, and command replies can still be sensitive; share the log carefully.</li> </ul> <p>For offline package preparation only:</p> <pre><code>./tools/lora_ota/lora_ota.sh ./release.zip offline \\\n  --prepare-only \\\n  --platform nrf52 \\\n  --target-id 1234ABCD \\\n  --target-base-hash 0011223344556677 \\\n  --target-hw Heltec_T114 \\\n  --base ./firmware-that-is-running.hex\n</code></pre> <p>Live operation is safer because the script obtains these values directly from the destination.</p>"},{"location":"lora_ota_automation/#what-happens-during-a-run","title":"What happens during a run","text":"<ol> <li>Validate the input paths and host tools, then prove the source is either an    OTA-enabled raw CLI or a source-only full Companion control interface. Read    and durably save a managed source's exact RXPS preference without changing    it.</li> <li>Before sending any remote packet, prove the managed source has no active,    pending, or fixed TempRadio work, then gate the source and controller    clocks. Advance a stale exact clock to host time; for a minute-resolution    source, preserve an overlapping minute or use one guarded forward value    with readback. Preserve a small future lead and fail closed above the    ten-minute drift limit. Then    authenticate to the target, query its target ID, hardware, running body    hash, firmware version, bootloader version, and nRF52 bootloader    capabilities, and save the controller's normal radio tuple.</li> <li>Select or build one compatible v2 application mOTA and verify all block    hashes, Merkle root, full-image hash where applicable, identity fields,    signature, codec, base, and the live firmware's reported maximum block size    (1 KiB for legacy replies without <code>maxblk</code>, currently 2 KiB otherwise).    Version-3 bootloader packages are refused before any target state changes.</li> <li>Read every participant's version, save the destination's RXPS state,    select the qualified destination policy, and show the confirmation prompt.</li> <li>Run the fixed-window three-minute rehearsal described above. This phase    does not disable RXPS, start a seeder, request a pull, or install anything;    the long transfer remains completely unarmed until temporary and normal    reachability both pass.</li> <li>Fresh-read, disable, and verify source RXPS; apply and verify the    destination RXPS policy; then start TempRadio on the    target, far-to-near relays, and source. A separate controller is moved and    read back through Binary; a shared Full Companion instead schedules its    bounded local override while Binary remains the transport. The runner    rejects a TempRadio window that cannot cover setup, seeder startup,    discovery, the transfer timeout, final polling, and install checks.</li> <li>Start <code>motatool serve</code>, discover the exact eight-hex manifest ID, request    <code>ota pull &lt;id&gt; flash</code>, and poll until that same ID reports ready. A seeder    process exit stops the run immediately. For <code>--no-install</code>, schedule all    script-controlled nodes back to their normal radios before restoring the    controller, unless <code>--leave-controller-radio</code> was requested.</li> <li>Recheck that exact ID, give the target a short final TempRadio safety window,    and request <code>ota install</code>. Then shorten each relay's TempRadio window so the    normal multi-hop route returns, stop the seeder, shorten the source window,    restore the controller, and probe <code>ota self</code> every 10 seconds through the    configured readiness window (five minutes by default). The exact new body    hash is the readiness signal;    only then does the runner require the exact package version. A relayed run    continues the 10-second probes through the mandatory relay-return window. A    source supplied with <code>--source-already-temp</code> is never modified.    <code>--leave-controller-radio</code> moves the controller back to TempRadio only after    this normal-channel verification. Restore the destination's exact original    RXPS setting after normal-channel identity is proven. A managed source stays    RXPS-off through that verification and its exact setting is restored only    after its own TempRadio state is proven inactive.</li> </ol> <p>Remote replies are matched only after queued messages have been drained and only when they come from the intended contact and fit the command. A ready status for another manifest ID is an error, never permission to install it.</p>"},{"location":"lora_ota_automation/#transmission-loss-and-retries","title":"Transmission loss and retries","text":"<p>Read-only and replay-safe transmissions retry up to three times. Three retries or 90 seconds, whichever comes first, opens a 10-second stop-or-continue prompt when stdin is an interactive terminal. Continue remains the default on timeout or Enter, so an operator can persist through a temporary outage; enter <code>s</code> or <code>stop</code> to end the run, and Ctrl-C remains immediate. With non-interactive stdin, the runner stops after that finite automatic retry cycle instead of silently starting another cycle forever. Optional participant-version probes always use a bounded cycle and degrade to <code>unknown</code>; optional destination <code>ota stats</code> falls back directly to <code>ver</code>. The mandatory normal-channel destination baseline is the narrow exception: it may make nine total read-only attempts but is stopped by one hard four-minute deadline before any TempRadio lease or OTA mutation exists. Proofs inside the live rehearsal retain the smaller four-attempt limit.</p> <p>Commands that change OTA state are reconciled before replay:</p> <ul> <li>After a lost <code>ota pull</code> reply, <code>ota status</code> must show the requested manifest   ID before the runner treats the pull as started. Otherwise the safe retry   policy applies.</li> <li>A lost <code>ota install</code> reply is not blindly resent. After a short wait, it is   sent again only if the target replies that the same manifest is still ready.   If the target has stopped replying because it may be rebooting, the runner   restores the normal path and lets post-reboot identity resolve the outcome.   The target's final three-minute safety window also returns a non-rebooting   target to the normal channel promptly.</li> </ul> <p>Retries and operator-selected continuation can outlast the original TempRadio budget. If a bounded window expires, rerun the same package after the nodes return to their normal channel; the manifest-ID check resumes its partial download without replacing it.</p> <p>The working directory is created before a managed source can be changed, then retained and printed at exit. It contains the exact served mOTA, <code>motatool-serve.log</code>, extracted build inputs when needed, and <code>controller-radio.txt</code>. A managed source also gets a protected <code>source-rxps-settings.json</code> containing its exact original preference and idempotent restore command. Its contents and directory entry are flushed before RXPS is disabled. When the destination started with RXPS enabled, protected <code>target-rxps-settings.json</code> records its manual recovery state. The RAK3401 chain points every nested step at one chain-root source record, so a rerun after host power loss does not adopt the temporary RXPS-off state as the original. A retained record is accepted only for the same managed CLI endpoint. These files contain no saved admin password. After exact source restoration, a standalone run atomically retires its record; the chain retains its shared record between steps and retires it only after the verified endpoint restoration completes.</p>"},{"location":"lora_ota_automation/#interruption-and-recovery","title":"Interruption and recovery","text":"<p>Ctrl-C stops the seeder, detaches its serial folder, makes a bounded attempt to shorten a source TempRadio window started by the script, and attempts to restore the controller. For a managed source it leaves RXPS off until the source is proven back on its normal radio, then restores and verifies the saved source preference. A transient success-path restore failure remains armed for one more idempotent cleanup attempt. The target and relays remain on TempRadio only until their bounded windows end; rebooting also restores their saved radio settings. A normal cleanup restores the destination's exact RXPS periods. If that remote restore cannot be confirmed, use <code>target-rxps-settings.json</code> after the target returns to its normal channel. A partial download remains safe. Once the target is reachable again (after its TempRadio window ends, or after putting the controller back on that tuple), rerunning the same package recognizes its manifest ID and resumes the existing session instead of clearing it.</p> <p>When a chained run has already proved the newly running body hash, its retained previous package can briefly report <code>verifying staged blocks</code> after TempRadio reactivates the OTA manager. The runner waits only through the configured discovery timeout, keeps checking source liveness, and accepts only the same manifest becoming <code>ready to install</code> or the manager becoming idle. A changed ID, failed or incomplete state, or timeout stops the chain. It then proves the exact installed body again. If that same session is still attached and ready, the runner detaches it with <code>ota cancel</code>; if the manager has become idle, it sends no cancel. An ordinary-channel <code>no download</code> status proves only that the manager is idle, not that persistent staging was erased. The runner therefore does not issue or describe an IDLE cancel as durable cleanup. The next chain transition explicitly re-adopts and proves the expected previous MID before detaching it; after the final install OTAFIX has consumed the approval word, so any retained container is inert and is replaced by the next valid pull.</p> <p>A hard process kill or host power loss cannot run cleanup. Recover a serial controller using the tuple saved in the printed work directory:</p> <pre><code>radio=$(tr -d '\\r\\n' &lt; ./meshcore-lora-ota-20260807-123456-1234/controller-radio.txt)\nmeshcli -s /dev/ttyACM0 set radio \"$radio\"\n</code></pre> <pre><code>$radio = (Get-Content '.\\meshcore-lora-ota-...\\controller-radio.txt' -Raw).Trim()\nmeshcli -s COM7 set radio $radio\n</code></pre> <p>For a managed source, first return it to its ordinary radio, then inspect <code>source-rxps-settings.json</code> and issue its exact <code>restore_command</code> through the same serial or TCP-console endpoint recorded in that file. The command is idempotent; confirm the full setting with <code>get radio.rxps.config</code> before resuming an update.</p> <p>If you stop during final confirmation, reconnect on the node's normal channel and run <code>ota self</code> and <code>ver</code>. A completed run returns success only when <code>ota self</code> reports a valid new body hash and <code>ver</code> exactly matches the package; an unverified install returns status 2. Do not immediately replace a staged image: the default active-download guard preserves it until you explicitly use <code>--replace-active-download</code> or run <code>ota cancel</code>.</p> <p>Exit status is <code>0</code> for success, <code>2</code> for a validation or operational error, and <code>130</code> for Ctrl-C.</p>"},{"location":"mbedtls-tls-footprint/","title":"Shrinking the per-connection TLS footprint on non-PSRAM observers","text":""},{"location":"mbedtls-tls-footprint/#why","title":"Why","text":"<p>On a non-PSRAM Heltec V3 running two WSS/JWT broker slots, the largest allocatable block in internal DRAM walks down in ~16 KiB steps at every TLS reconnect while total free heap stays flat. Measured on hardware over 50 reconnect cycles: 62,452 -&gt; 16,372 bytes, permanently.</p> <p>The step size is not a coincidence. <code>framework-arduinoespressif32 3.20017</code> (Arduino 2.0.17, IDF 4.4) builds mbedTLS with the symmetric buffer configuration:</p> <pre><code>CONFIG_MBEDTLS_SSL_MAX_CONTENT_LEN 16384      # sizes BOTH the in and out record buffers\nCONFIG_MBEDTLS_SSL_KEEP_PEER_CERTIFICATE 1\n# CONFIG_MBEDTLS_ASYMMETRIC_CONTENT_LEN       -- not defined\n# CONFIG_MBEDTLS_DYNAMIC_BUFFER               -- not defined\n# CONFIG_MBEDTLS_SSL_VARIABLE_BUFFER_LENGTH   -- not defined\n</code></pre> <p>Read from <code>packages/framework-arduinoespressif32/tools/sdk/esp32s3/qio_qspi/include/sdkconfig.h</code>. Note the separate <code>framework-arduinoespressif32-libs</code> package in <code>~/.platformio</code> belongs to the esp32c6 env (pioarduino, IDF 5.3) and is not what this env links against -- though it happens to carry identical mbedTLS values.</p> <p>So each broker slot costs 2 x 16 KiB = 32 KiB of contiguous internal DRAM in record buffers alone, and two slots cost 64 KiB on a board with roughly 80 KiB free. Every reconnect frees and re-allocates those buffers, and anything that lands in the vacated hole in between prevents them from going back, which is the ratchet.</p> <p>Confirmed by two independent observations: losing a whole TLS session returned exactly 16,384 bytes of contiguity on one device and exactly 32,768 on another, and per-connection teardown frees ~41.6-44.7 KB total.</p>"},{"location":"mbedtls-tls-footprint/#what-the-firmware-could-already-do-and-its-limit","title":"What the firmware could already do, and its limit","text":"<p><code>softDisconnect()</code> (branch <code>perf/mqtt-renewal-no-stop</code>, commit <code>6c51e468</code>) stops the JWT renewal bounce from destroying and recreating the esp-mqtt task, keeping its 6 KiB stack out of the hole. Measured: the staircase arrests after 2 steps at 36,852 through cycle 16, where the baseline took 4 steps and settled at 16,372 by cycle 11 -- about 20 KB better.</p> <p>That is as far as the application layer reaches. MQTT 3.1.1 has no re-authentication packet, so presenting a fresh JWT requires a transport reconnect; mbedTLS's internal allocation order during the handshake is not controllable from the application. The remaining cost is the record buffers themselves.</p>"},{"location":"mbedtls-tls-footprint/#the-changes","title":"The changes","text":"<p>All three are compile-time in mbedTLS, and the Arduino framework ships precompiled <code>.a</code> archives (<code>tools/sdk/esp32s3/lib/libmbedtls.a</code>), so a project-level <code>-D</code> cannot change them. A custom framework build is required.</p> Setting From To Saving per connection <code>CONFIG_MBEDTLS_ASYMMETRIC_CONTENT_LEN</code> unset <code>y</code> enables the two below <code>CONFIG_MBEDTLS_SSL_IN_CONTENT_LEN</code> 16384 (implied) 16384 none -- keep it <code>CONFIG_MBEDTLS_SSL_OUT_CONTENT_LEN</code> 16384 (implied) 4096 ~12 KiB <code>CONFIG_MBEDTLS_SSL_KEEP_PEER_CERTIFICATE</code> <code>1</code> <code>n</code> ~4 KiB <p>Roughly 16 KiB per connection, 32 KiB across two slots.</p>"},{"location":"mbedtls-tls-footprint/#why-inbound-stays-at-16-kib","title":"Why inbound stays at 16 KiB","text":"<p>A peer may legitimately send a 16 KiB TLS record. Lowering the inbound limit only works if both brokers negotiate the max-fragment-length extension or provably never send larger, and getting it wrong produces invalid-record and handshake failures rather than a clean error. Outbound is ours to choose: this firmware's MQTT and WebSocket frames are far below 4 KiB (<code>MAX_TRANS_UNIT</code>-bounded packets plus small JSON), so 4 KiB is comfortable.</p>"},{"location":"mbedtls-tls-footprint/#risk-on-the-peer-certificate","title":"Risk on the peer certificate","text":"<p>Dropping <code>KEEP_PEER_CERTIFICATE</code> means <code>mbedtls_ssl_get_peer_cert()</code> returns NULL after the handshake. Chain validation still happens -- only retention of the parsed leaf changes. This firmware verifies against a CA (<code>GTS_ROOT_R4</code> / the bundle) and never inspects the peer certificate or a fingerprint, so it should be safe. It does change <code>mbedtls_ssl_session</code> layout, which is exactly why the whole framework must be rebuilt together rather than swapping a single archive in.</p>"},{"location":"mbedtls-tls-footprint/#build-procedure","title":"Build procedure","text":""},{"location":"mbedtls-tls-footprint/#do-not-use-esp32-arduino-lib-builder-for-this","title":"Do not use esp32-arduino-lib-builder for this","text":"<p><code>release/v4.4</code> is the branch matching Arduino 2.0.x, but its <code>update-components.sh</code> clones every dependency at master, so it no longer resolves. Five successive failures, each a different repo: the arduino branch name it passes to <code>-A</code> does not exist; <code>jq</code> is absent from the IDF image and its absence makes <code>build.sh</code>'s target loop a silent no-op that still exits 0; <code>esp_littlefs</code> and <code>esp32-camera</code> master require IDF &gt;=5.0/&gt;=5.1; <code>esp32-camera</code> later needs an <code>esp_jpeg</code> version the 4.4 registry cannot satisfy; and tinyusb's source layout no longer matches <code>arduino_tinyusb/CMakeLists.txt</code>. Pinning each one in turn just surfaces the next.</p>"},{"location":"mbedtls-tls-footprint/#rebuild-only-the-mbedtls-archives","title":"Rebuild only the mbedTLS archives","text":"<p>More rigorous anyway, because it reuses the shipped <code>sdkconfig</code> verbatim -- so the archives differ from stock only by the intended change, with no arduino-version or <code>DYNAMIC_BUFFER</code> drift.</p> <p>This is ABI-safe for the content-length change specifically: <code>ssl.h</code> declares <code>in_buf</code> and <code>out_buf</code> as <code>unsigned char *</code>, allocated in <code>ssl_setup()</code>, and no public struct embeds a CONTENT_LEN-sized array. The other precompiled archives (esp-tls, esp_http_client, esp-mqtt) therefore remain compatible. It is not safe for <code>CONFIG_MBEDTLS_SSL_KEEP_PEER_CERTIFICATE</code>, which changes <code>mbedtls_ssl_session</code> layout -- that one needs everything rebuilt together, so it is excluded here.</p> <ol> <li>Minimal IDF project whose only component requirement is <code>mbedtls</code>.</li> <li><code>sdkconfig.defaults</code> = the shipped    <code>packages/framework-arduinoespressif32/tools/sdk/esp32s3/sdkconfig</code>, with    <code>CONFIG_MBEDTLS_SSL_MAX_CONTENT_LEN=16384</code> replaced by the three asymmetric lines.    Verify the diff is exactly 5 lines before building.</li> <li><code>docker run --rm -v $PWD:/project -w /project espressif/idf:v4.4.7 idf.py -DIDF_TARGET=esp32s3 build</code></li> <li>Confirm <code>build/config/sdkconfig.h</code> carries <code>OUT_CONTENT_LEN 4096</code>.</li> <li>Stage the four archives under the framework's names -- note the rename:</li> </ol> built framework name stock size rebuilt <code>esp-idf/mbedtls/libmbedtls.a</code> <code>libmbedtls.a</code> 113,914 113,338 <code>esp-idf/mbedtls/mbedtls/library/libmbedtls.a</code> <code>libmbedtls_2.a</code> 1,252,150 1,245,718 <code>.../libmbedcrypto.a</code> <code>libmbedcrypto.a</code> 4,302,698 4,259,458 <code>.../libmbedx509.a</code> <code>libmbedx509.a</code> 676,590 673,318 <p>All within ~1% of stock, which is a good check that only the config differs.</p>"},{"location":"mbedtls-tls-footprint/#wire-it-in-with-l-never-platform_packages","title":"Wire it in with -L, never platform_packages","text":"<pre><code>PLATFORMIO_BUILD_FLAGS=\"-L/path/to/staged/archives\" pio run -e Heltec_v3_repeater_observer_mqtt\n</code></pre> <p>Verify with <code>grep -oE \"[^ ]*libmbed[a-z0-9_]*\\.a\" .pio/build/&lt;env&gt;/firmware.map | sort -u</code> -- every path must be the staged directory.</p> <p>Do not point <code>platform_packages</code> at a <code>file://</code> copy of the framework. PlatformIO installs it over the shared <code>~/.platformio/packages/framework-arduinoespressif32</code>, silently changing mbedTLS for every other ESP32 env and project on the machine. It does this even when the copy's <code>package.json</code> version differs -- verified twice here, and both times the fix was <code>rm -rf</code> the package and <code>pio pkg install</code> to re-download stock. A prepended library search path keeps the change scoped to one env, because the linker takes each archive member from the first archive that satisfies an undefined symbol.</p>"},{"location":"mbedtls-tls-footprint/#how-to-verify-it-worked","title":"How to verify it worked","text":"<ol> <li><code>strings</code>/<code>grep</code> the new <code>sdkconfig.h</code> for the four settings.</li> <li>Build and check the RAM figure; static usage should be unchanged (these are heap buffers).</li> <li>On hardware, <code>get mqtt.stats</code> at boot with two slots connected: the largest free block    should start roughly 24-32 KiB higher than the current 62-67 KiB.</li> <li>Soak across reconnect cycles and compare the floor against the two recorded runs:    baseline settled 16,372 (cycle 11); <code>softDisconnect</code> holds 36,852 (cycle 16).</li> </ol>"},{"location":"mbedtls-tls-footprint/#prior-art-in-this-investigation","title":"Prior art in this investigation","text":"<p><code>.scratch/mqtt-non-psram-heap-staircase-analysis-2026-08-05.md</code> (untracked -- <code>.scratch/</code> is globally gitignored) holds the full allocation inventory. <code>~/mqtt-soak/STATE.md</code> holds the soak evidence, including two retracted hypotheses worth not repeating: the perf commits were not the cause, and waev does not cap connections per IP.</p>"},{"location":"nrf52_companion_storage_recovery/","title":"nRF52 Companion automatic ExtraFS recovery","text":"<p>Companion builds using internal ExtraFS reserve 100 KiB at <code>0xD4000..0xED000</code>. Identity and preferences remain in the separate 28 KiB primary store at <code>0xED000..0xF4000</code>. This applies to internal-ExtraFS Companion builds, including Full, not repeaters or external QSPI storage.</p> <p>At startup the firmware:</p> <ol> <li>Mounts primary storage without erasing nonblank media. Only proven-blank    primary storage may be initialized automatically.</li> <li>Checks the exact ExtraFS address, size, block geometry, and application    linker reservation, then attempts a non-formatting secondary mount.</li> <li>Validates primary filesystem metadata before any destructive secondary    recovery. An unavailable primary store blocks recovery and identity replacement.</li> <li>Keeps an already mounted, metadata-valid ExtraFS unchanged. If its initial    mount or validation failed, unmounts and retries once without formatting.</li> <li>If the retry remains unusable, automatically formats only the reserved    100 KiB region, then remounts and validates it. There is one format attempt    per boot; failure keeps the contact/channel write quarantine active.</li> <li>Runs the existing verified migration from primary into ExtraFS. Primary    contact/channel sources are retired only after every destination is copied,    read back, and the migration transaction is committed. Identity and    preferences stay on primary.</li> </ol> <p>No terminal repair command, phone intervention, or bootloader update is needed for this recovery path when a compatible application/layout is already used. After successful recovery, the Companion storage API reports 100 KiB total rather than the 28 KiB primary fallback.</p>"},{"location":"nrf52_companion_storage_recovery/#data-loss-boundary","title":"Data-loss boundary","text":"<p>Automatic rebuilding prioritizes a usable contact/channel store over retaining an unreadable secondary filesystem. Data stored only in that damaged region can be lost. Surviving primary files are migrated, but may not contain the latest secondary-only changes. An API backup remains advisable before flashing. Primary storage is never formatted by this recovery path.</p> <p>This is mount/metadata recovery, not forensic file recovery. An invalid migration journal, unreadable individual contact page, primary-source error, full filesystem, or failed migration cleanup does not on its own trigger a format of a mountable, metadata-valid secondary store. Those cases retain the existing validation, retry, and incomplete-load protections.</p>"},{"location":"nrf52_companion_storage_recovery/#regression-coverage","title":"Regression coverage","text":"<p><code>test/test_internal_secondary_fs_repair</code> exercises healthy/no-format startup, successful remount, failed remount/traversal followed by one repair, and format/remount/validation failure. <code>test/test_nrf52_extrafs_contract.py</code> checks primary-first ordering, internal-only geometry guards, quarantine handling, and the separation between migration failures and destructive recovery.</p>"},{"location":"nrf52_companion_storage_recovery/#t1000-e-hardware-qualification-2026-09-03","title":"T1000-E hardware qualification (2026-09-03)","text":"<p>A device reporting 25/28 KiB primary fallback and contact enumeration error 5 was flashed with the recovery build. With no explicit repair command, startup activated 100 KiB ExtraFS and loaded all 125 contacts and 40 channel slots. Identity, preferences, radio settings, and channels matched the pre-update API snapshot. Add, edit, and delete of an owned temporary contact each survived a separate normal reboot; the device ended with the original 125 contacts and 27/100 KiB usage. The 161 offline/native regression tests and target build passed.</p> <p>This was not lossless recovery of every historical RAM value: 21 contacts had older advertisement/local-modification timestamps, including one older advertised location. No contact was missing, and no computer-backup restoration was used. A subsequent read-only scan found no readable cached advert for any of the 125 contacts. Without a surviving newer copy, firmware cannot infer those earlier values; receiving new verified advertisements can refresh them normally.</p>"},{"location":"nrf52_power_management/","title":"nRF52 Power Management","text":""},{"location":"nrf52_power_management/#overview","title":"Overview","text":"<p>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.</p>"},{"location":"nrf52_power_management/#features","title":"Features","text":""},{"location":"nrf52_power_management/#boot-voltage-protection","title":"Boot Voltage Protection","text":"<ul> <li>Checks battery voltage immediately after boot and before mesh operations commence</li> <li>If voltage is below a configurable threshold (e.g., 3300mV), the device configures voltage wake (LPCOMP + VBUS) and enters protective shutdown (SYSTEMOFF)</li> <li>Prevents boot loops when battery is critically low</li> <li>Skipped when external power (USB VBUS) is detected</li> </ul>"},{"location":"nrf52_power_management/#voltage-wake-lpcomp-vbus","title":"Voltage Wake (LPCOMP + VBUS)","text":"<ul> <li>Configures the nRF52's Low Power Comparator (LPCOMP) before entering SYSTEMOFF</li> <li>Enables USB VBUS detection so external power can wake the device</li> <li>Device automatically wakes when battery voltage rises above recovery threshold or when VBUS is detected</li> <li>Uses no LPCOMP hysteresis; on divided battery inputs the additional 50 mV   comparator hysteresis can move the effective battery wake point by several   hundred millivolts and strand an otherwise charged node</li> </ul>"},{"location":"nrf52_power_management/#early-boot-register-capture","title":"Early Boot Register Capture","text":"<ul> <li>Captures RESETREAS (reset reason) and GPREGRET2 (shutdown reason) before SystemInit() clears them</li> <li>Allows firmware to determine why it booted (cold boot, watchdog, LPCOMP wake, etc.)</li> <li>Allows firmware to determine why it last shut down (user request, low voltage, boot protection)</li> </ul>"},{"location":"nrf52_power_management/#shutdown-reason-tracking","title":"Shutdown Reason Tracking","text":"<p>Shutdown reason codes (stored in GPREGRET2):</p> 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"},{"location":"nrf52_power_management/#supported-boards","title":"Supported Boards","text":"Board family Implemented LPCOMP wake VBUS wake Seeed Studio XIAO nRF52840 (<code>xiao_nrf52</code>) Yes Yes Yes SenseCAP Solar Yes Yes Yes RAK4631 / RAK3401 Yes Yes Yes GAT562 30S / EVB Pro / Tracker Pro / Watch13 Yes Yes Yes Heltec T096 / T114 / T1 / Tower V2 Yes Yes Yes Muzi Works R1 Neo Partial Inactive Inactive Promicro nRF52840 No No No RAK WisMesh Tag No No No Heltec Mesh Solar No No No LilyGo T-Echo / T-Echo Lite / T-Impulse Plus No No No WIO Tracker L1 / L1 E-Ink / WM1110 No No No Mesh Pocket / Meshtiny / Nano G2 Ultra No No No ThinkNode M1 / M3 / M6 No No No T1000-E No No No Ikoka Nano / Stick / Handheld (nRF) No No No Keepteen LT1 / Minewsemi ME25LS01 No No No <p>Notes: - \"Implemented\" reflects Phase 1 (boot lockout + shutdown reason capture). - R1 Neo has the integration compiled, but its board configuration deliberately   sets <code>PWRMGT_VOLTAGE_BOOTLOCK</code> to <code>0</code>; automatic protective shutdown and its   voltage/VBUS recovery wake are therefore inactive. - User power-off does not enable LPCOMP wake; voltage recovery is armed only   for boot protection and automated low-voltage shutdown. - 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.</p>"},{"location":"nrf52_power_management/#technical-details","title":"Technical Details","text":""},{"location":"nrf52_power_management/#architecture","title":"Architecture","text":"<p>The power management functionality is integrated into the <code>NRF52Board</code> base class in <code>src/helpers/NRF52Board.cpp</code>. Board variants provide hardware-specific configuration via a <code>PowerMgtConfig</code> struct and override <code>initiateShutdown(uint8_t reason)</code> to perform board-specific power-down work and conditionally enable voltage wake (LPCOMP + VBUS).</p>"},{"location":"nrf52_power_management/#early-boot-capture","title":"Early Boot Capture","text":"<p>A static constructor with priority 101 in <code>NRF52Board.cpp</code> captures the RESETREAS and GPREGRET2 registers before: - SystemInit() (priority 102) - which clears RESETREAS - Static C++ constructors (default priority 65535)</p> <p>This ensures we capture the true reset reason before any initialisation code runs.</p>"},{"location":"nrf52_power_management/#board-implementation","title":"Board Implementation","text":"<p>To enable power management on a board variant:</p> <ol> <li> <p>Enable in platformio.ini:    <code>ini    -D NRF52_POWER_MANAGEMENT</code></p> </li> <li> <p>Define configuration in variant.h:    <code>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)</code></p> </li> <li> <p>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    };</p> </li> </ol> <p>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);</p> <pre><code> if (enable_lpcomp) {\n   configureVoltageWake(power_config.lpcomp_ain_channel, power_config.lpcomp_refsel);\n }\n\n enterSystemOff(reason);\n</code></pre> <p>}    #endif</p> <p>void MyBoard::begin() {      NRF52Board::begin();  // or NRF52BoardDCDC::begin()      // ... board setup ...</p> <p>#ifdef NRF52_POWER_MANAGEMENT      checkBootVoltage(&amp;power_config);    #endif    }    ```</p> <p>For user-initiated shutdowns, <code>powerOff()</code> remains board-specific. Power management only arms LPCOMP for automated shutdown reasons (boot protection/low voltage).</p> <ol> <li>Declare override in board .h file:    <code>cpp    #ifdef NRF52_POWER_MANAGEMENT      void initiateShutdown(uint8_t reason) override;    #endif</code></li> </ol>"},{"location":"nrf52_power_management/#voltage-wake-configuration","title":"Voltage Wake Configuration","text":"<p>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 no hysteresis so the configured recovery threshold is not widened by the battery divider - Wake the device from SYSTEMOFF when triggered</p> <p>VBUS wake is enabled via the POWER peripheral USBDETECTED event whenever <code>configureVoltageWake()</code> is used. This requires USB VBUS to be routed to the nRF52 (typical on nRF52840 boards with native USB).</p> <p>LPCOMP Reference Selection (PWRMGT_LPCOMP_REFSEL):</p> 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 <p>Important: For boards with a voltage divider on the battery sense pin, LPCOMP measures the divided voltage. Use: <code>VBAT_threshold ~ (VDD * fraction) * divider_scale</code>, where <code>divider_scale = (Rtop + Rbottom) / Rbottom</code> (e.g., 2.0 for 1M/1M, 2.5 for 1.5M/1M, 3.0 for XIAO).</p>"},{"location":"nrf52_power_management/#softdevice-compatibility","title":"SoftDevice Compatibility","text":"<p>The power management code checks whether SoftDevice is enabled and uses the appropriate API: - When SD enabled: <code>sd_power_*</code> functions - When SD disabled: Direct register access (NRF_POWER-&gt;*)</p> <p>This ensures compatibility regardless of BLE stack state.</p>"},{"location":"nrf52_power_management/#cli-commands","title":"CLI Commands","text":"<p>Power management status can be queried via the CLI:</p> Command Description <code>get pwrmgt.support</code> Returns \"supported\" or \"unsupported\" <code>get pwrmgt.source</code> Returns current power source - \"battery\" or \"external\" (5V/USB power) <code>get pwrmgt.bootreason</code> Returns reset and shutdown reason strings <code>get pwrmgt.bootmv</code> Returns boot voltage in millivolts <p>On boards without power management enabled, all commands except <code>get pwrmgt.support</code> return:</p> <pre><code>ERROR: Power management not supported\n</code></pre>"},{"location":"nrf52_power_management/#debug-output","title":"Debug Output","text":"<p>When <code>MESH_DEBUG=1</code> is enabled, the power management module outputs:</p> <pre><code>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</code></pre>"},{"location":"nrf52_power_management/#phase-2-planned","title":"Phase 2 (Planned)","text":"<ul> <li>Runtime voltage monitoring</li> <li>Voltage state machine (Normal -&gt; Warning -&gt; Critical -&gt; Shutdown)</li> <li>Configurable thresholds</li> <li>Load shedding callbacks for power reduction</li> <li>Deep sleep integration</li> <li>Scheduled wake-up</li> <li>Extended sleep with periodic monitoring</li> </ul>"},{"location":"nrf52_power_management/#references","title":"References","text":"<ul> <li>nRF52840 Product Specification - POWER</li> <li>nRF52840 Product Specification - LPCOMP</li> <li>SoftDevice S140 API - Power Management</li> </ul>"},{"location":"number_allocations/","title":"Number Allocations","text":"<p>This document lists unique numbers/identifiers used in various MeshCore protocol payloads.</p>"},{"location":"number_allocations/#group-data-types","title":"Group Data Types","text":"<p>The <code>PAYLOAD_TYPE_GRP_DATA</code> payloads have a 16-bit data-type field, which identifies which application the packet is for.</p> <p>To make sure multiple applications can function without interfering with each other, the table below is for reserving various ranges of data-type values. Just modify this table, adding a row, then submit a PR to have it authorised/merged.</p> <p>NOTE: the range FF00 - FFFF is for use while you're developing, doing POC, and for these you don't need to request to use/allocate.</p> <p>Once you have a working app/project, you need to be able to demonstrate it exists/works, and THEN request type IDs. So, just use the testing/dev range while developing, then request IDs before you transition to publishing your project.</p> Data-Type range App name Contact 0000 - 00FF -reserved for internal use- 0100 MeshCore Open zsylvester@monitormx.com - https://github.com/zjs81/meshcore-open 0110 - 011F Ripple ripple_biz@protonmail.com - https://buymeacoffee.com/ripplebiz 0120 MCO Advanced most.original.address@gmail.com - https://github.com/HDDen/meshcore-open/tree/rename-mco-advanced FF00 - FFFF -reserved for testing/dev- <p>(add rows, inside the range 0100 - FEFF for custom apps)</p>"},{"location":"ota_easy/","title":"Easy firmware updates over LoRa","text":"<p>This guide shows the shortest manual path for sending firmware from a computer to a MeshCore node over LoRa. Choose the package type for the destination node:</p> <p>For an end-to-end controller that accepts a release ZIP or ready mOTA, see Scripted LoRa OTA from start to finish.</p> Destination Update type Files needed to build the <code>.mota</code> Installer ESP32 Full firmware New non-merged application <code>.bin</code> ESP32 A/B firmware slots nRF52, internal staging In-place delta Exact running <code>firmware.hex</code> and new <code>firmware.hex</code> Exact-board OTAFIX bootloader Supported nRF52 QSPI repeater Full firmware or in-place delta New <code>firmware.hex</code>; a delta also needs the exact running <code>firmware.hex</code> Matching QSPI-aware OTAFIX bootloader MeshTower V2 SD target Full firmware or in-place delta New <code>firmware.hex</code>; a delta also needs the exact running <code>firmware.hex</code> Matching SD-aware OTAFIX bootloader <p>An internal-staging nRF52 target accepts only an in-place delta built against its exact running firmware. Matched QSPI repeater targets and the MeshTower V2 microSD target can also install a full image because the complete container stays off-chip. See nRF52 repeater OTA with external QSPI and MeshTower V2 microSD LoRa OTA.</p> <p>MeshTower V2 microSD application and bootloader containers must be Ed25519-signed by a key in the device allowlist; pass <code>--sign</code> to <code>motatool build</code> (or <code>--sign-key</code> to the end-to-end runner) when building one. Its BLM2-capable SD-aware bootloader is also required before ordinary application or bootloader OTA can use the reset-retained authorization record. Upgrade preview.12 locally over USB/BLE DFU or SWD first; there is no raw-card compatibility handoff.</p>"},{"location":"ota_easy/#temporary-ota-channel-used-in-this-guide","title":"Temporary OTA channel used in this guide","text":"Setting Value Center frequency 909.950 MHz Bandwidth 250 kHz Spreading factor SF5 Coding rate used in this guide CR5 Example window 120 minutes <p>The copy/paste command is:</p> <pre><code>tempradio 909.950,250,5,5,120\n</code></pre> <p>The fourth value is the transmit coding rate. This guide uses CR5, but the participating nodes' coding rates do not need to match.</p> <p><code>tempradio</code> is not saved and the node returns to its normal radio settings when the window ends or the node reboots. Current full-parser firmware also accepts <code>normalradio</code>, which cancels the temporary window and restores the saved tuple after replying on the current channel. This frequency is intended for North American configurations. Confirm that it is permitted in your location and change it when necessary.</p> <p>At SF5/BW250, an SX1262+TCXO destination can keep RXPS enabled only when it and every sender that can reach it (controller, source, and relays) follow the v1.17.1.5-or-newer adaptive-preamble contract. The qualified destination boundary is effective level 8, preamble 64 and <code>1252 / 6424 us</code>. For manual setup, save <code>set radio.rxps level 8 preamble 32</code> before entering TempRadio; the <code>32</code> is a conservative saved timing assumption and current firmware selects the real 64-symbol wire preamble when it retunes the temporary radio. For an older, unknown, or mixed-version path, use <code>set radio.rxps off</code> for the maintenance window. First record <code>get radio.rxps.config</code>; after <code>normalradio</code>, restore a reported level with <code>set radio.rxps level N preamble P</code> (omit <code>preamble P</code> when <code>P</code> is <code>0</code>). A legacy node returns only on/off and periods, which can be restored with <code>set radio.rxps RX_US SLEEP_US</code>. The scripted runner performs the version checks, temporary change, verification, and restoration automatically while preserving automatic retuning. SF5/BW500 is too fast for RXPS even with a 64-symbol preamble, so current firmware selects 128 and uses the qualified level-8 <code>626 / 6398 us</code> timing when every participant supports the adaptive contract.</p>"},{"location":"ota_easy/#before-you-start","title":"Before you start","text":"<p>Both paths require:</p> <ul> <li>A destination artifact explicitly identified by its release table as install-capable. Some lean internal   nRF52 builds carry <code>lora_ota_no_external_sensors</code> in the filename, while matched QSPI boards enable install   support in the normal full-sensor repeater artifact, so filename text alone is not authoritative. Confirm   support with <code>ota self</code> and <code>ota status</code>. Intermediate repeaters do not need an install-capable build:   current repeater firmware relays OTA packets opaquely without storing or installing them.</li> <li>An OTA-enabled MeshCore source connected to the computer by USB serial, or   an ESP32 WiFi companion/FULL source connected over WiFi as described below.</li> <li>Overlapping <code>tempradio</code> windows on the source, destination, and every repeater needed between them.</li> </ul> <p>LoRa OTA packets are generated, consumed, and relayed only while <code>tempradio</code> is active. Intermediate repeaters apply their normal forwarding filters, duplicate checks, and flood limits; they do not interpret the OTA payload. If any required window closes, the transfer stops making progress and can resume during a later overlapping window.</p> <p><code>build.sh</code> provides a <code>*_repeater_lora_ota_no_external_sensors</code> build for standalone ESP32 and nRF52 repeater targets that need a smaller internal update workspace. Those siblings omit selected optional environmental and ranging drivers while retaining board-native features such as displays, buttons, battery monitoring, and GPS where the target uses the GPS-preserving lean profile. RAK3401 and RAK4631 reduced builds also retain INA219, INA226, INA260, and INA3221 I2C voltage/current monitors; together these drivers cost less than 5 KiB in the measured profile. Those four monitor drivers are not the only retained I2C support: the board's SSD1306 OLED, supported autodiscovered RTCs, and the RAK12500 GPS remain separate I2C peripherals in GPS-compatible RAK recipes. RAK12501/L76K GPS instead uses UART Serial1. The RAK3401 OTA repeater supports either GPS module in sensor slot A; slot D conflicts with the RAK13302 radio's BUSY/DIO1 lines. The RAK4631 OTA repeater defaults its runtime RS-232 bridge to Serial2 so the UART RAK12501 can retain Serial1. The runtime guard always reserves Serial1 because a bounded silent probe cannot prove a cold RAK12501 is absent; the shared WB_IO2/3V3_S rail keeps a fitted module powered and driving the UART. Use Serial2. Serial1 requires an explicit no-GPS/dedicated image. The merged image remains fail-closed even when it detects an I2C RAK12500. The explicit legacy Serial1 bridge omits the combined GPS provider, including the otherwise non-UART RAK12500 path.</p> <p>The firmware-configured INA3221 address and the RAK12500 address are both <code>0x42</code>; they cannot coexist on one bus at those addresses. Keep RAK12500 at <code>0x42</code>, strap INA3221 A0 to SCL for <code>0x43</code>, and use a build with <code>-DTELEM_INA3221_ADDRESS=0x43</code> when both are installed.</p> <p>Selected nRF52 boards with matched external QSPI application and bootloader support can instead make the normal full-sensor repeater install-capable; those targets do not need to reserve internal flash for the downloaded container. SolarXiao 30S and 33S use this matched external-QSPI path and therefore do not emit redundant no-external-sensors siblings. A RAK19007 can use the same separately wired W25Q16 with either RAK4631 or RAK3401 + RAK13302: the flash consumes no WisBlock slot and GPS remains supported in slot A. This is not the RAK15001 arrangement; RAK15001 and RAK13302 share a chip-select and cannot be used together. Other normal repeaters can still serve as intermediate relays but cannot necessarily install an update themselves. ESP32 <code>-ota-</code> siblings also retain the lightweight browser WiFi uploader (<code>start ota</code>), the complete CLI, and a 254-entry neighbor table. RP2040 and STM32 repeaters do not currently have a safe self-apply path, but current repeater firmware can still relay OTA packets opaquely during TempRadio.</p> <p>For one explicitly selected internal-flash nRF52 repeater, the default <code>--build-profile auto</code> run emits two install-capable choices. The <code>*-full-ota-*</code> artifact retains external sensors, while the <code>*_lora_ota_no_external_sensors-reduced-ota-*</code> artifact trades only those optional drivers not explicitly retained by the board profile for more delta-staging space. They retain the same OTA target identity so update tooling does not confuse the optimization choice with a different board. QSPI- and SD-backed repeaters emit only the complete choice unless a measured size failure requires a fallback.</p> <p>nRF52 <code>-ota-</code> siblings are compiled with size optimization instead of the Adafruit platform's default speed optimization. This prevents the retained software Ed25519 fallback from expanding beyond the fixed in-place workspace; CC310 hardware crypto, hardware RNG mixing, telemetry history, and board-native features remain enabled.</p> <p>ESP32 <code>*-full-usb-wifi-ota-*</code> artifacts retain all compiled features and enable LoRa OTA for every FULL role, including room servers, sensors, observers, and bridges. A FULL image requires its expanded partition table: install the matching merged image over USB once before installing later non-merged FULL updates over LoRa. ESP32 MQTT observers and ESP-NOW bridges are always emitted as FULL artifacts; compact-CLI variants are no longer built. The <code>*-full-usb-wifi-ota-*</code> profile compiles USB packet logging and direct WiFi MQTT into one image. Use <code>set logging.output off|usb|wifi|both</code> to persist the desired path. A <code>*-full-logging-ota-*</code> artifact is now only a fallback for a hardware/role combination without a WiFi MQTT target and can produce substantial serial output.</p>"},{"location":"ota_easy/#choose-the-source-radio","title":"Choose the source radio","text":"<p>Use an OTA-enabled MeshCore node as the source. It receives the update folder from the computer, then advertises it over LoRa. ESP32 USB/WiFi companions and FULL ESP32 roles include the required transport. A <code>*_companion_radio_full</code> target keeps only the source half of LoRa OTA: it serves host images but cannot stage or install one for itself. ESP32 full combines USB, BLE, and WiFi; nRF52 full combines USB and BLE because nRF52840 has no WiFi. A small set of high-capacity, non-PSRAM classic ESP32 companions keep their normal image and provide a separate <code>-full-logging-ota-</code> fallback with 100 contacts, 8 group channels, a 16-frame offline queue, and persistent USB output selection. Install that variant's merged image over USB once before using it. Connect the source by USB serial or, when supported, by WiFi. For an ordinary raw-text USB source, confirm that its USB CLI accepts:</p> <pre><code>ota folder on\n</code></pre> <p>If an older build reports that <code>OTA_FOLDER_SERIAL</code> is not compiled in, install a current <code>-ota-</code>, <code>-full-usb-wifi-ota-</code>, or applicable <code>-full-logging-ota-</code> build first. Do not use a KISS modem: KISS firmware is a TNC/KISS frame interface and does not provide the MeshCore CLI or the OTA-folder transport that <code>motatool serve</code> requires.</p> <p>An nRF52 <code>companion_radio_full</code> starts in its USB ASCII terminal and automatically changes to Binary Companion when it receives a complete <code>&lt;</code> frame. It also recognizes <code>motatool</code>'s exact initial <code>ota folder on</code> line and enters exclusive mOTA mode directly, so <code>motatool serve --serial</code> can be the first client after boot. No terminal token or preliminary disconnect is required. Stopping the tool or disconnecting resets USB to Binary. BLE remains available throughout. See the Full Companion USB switcher guide for the complete ownership transitions. Protocol v14 can instead take the catalog from a paired phone or Linux host over a separate encrypted BLE mOTA service while Binary Companion remains active. USB and BLE catalog sources are mutually exclusive. See the Full Companion Bluetooth source guide.</p> <p>For an ESP32 WiFi companion or FULL ESP32 source with active WiFi, use its dedicated OTA seeder:</p> <pre><code>motatool serve --dir ./motas --tcp &lt;source-host&gt;:5001 -v\n</code></pre> <p>Port <code>5001</code> is separate from the companion application port (<code>5000</code>) and the HTTP configuration/browser-OTA port (<code>80</code>, depending on the role). An ESP32 <code>companion_radio_full</code> also has its complete role-specific text terminal on port <code>5002</code>; OTA automation uses its <code>ota</code> and TempRadio subset. See the full Companion guide. On a FULL repeater or room server, <code>start webconfig</code> can bring up the saved WiFi connection. Other FULL roles with browser OTA support can raise <code>MeshCore-OTA</code> with <code>start ota</code> and use <code>192.168.4.1:5001</code>. The TCP seeder auto-attaches; do not also run <code>ota folder on</code> for USB serial.</p>"},{"location":"ota_easy/#install-motatool","title":"Install <code>motatool</code>","text":"<p>Install Rust if necessary, then install the standalone packaging and serving tool:</p> <pre><code>git clone https://github.com/vk496/motatool\ncargo install --path ./motatool\n</code></pre>"},{"location":"ota_easy/#esp32-package-a-full-firmware-image","title":"ESP32: package a full firmware image","text":"<p>The destination must be an OTA-capable ESP32 with an A/B partition table. Download or build the new non-merged <code>.bin</code> application for the destination's exact board and role. Do not use an ESP32 <code>-merged.bin</code> factory image.</p> <p>Put the application firmware in a working directory, then build a full <code>.mota</code> container. For example:</p> <pre><code>mkdir -p ./motas\nmotatool build --fw ./Heltec_v3_repeater-ota-v1.16.05.bin --out-dir ./motas\nmotatool verify ./motas/*.mota\n</code></pre> <p>Replace the example filename with the firmware for the destination's exact target. With no <code>--base</code> argument, <code>motatool build</code> creates a full-image update. The firmware must contain its MeshCore <code>EndF</code> identity trailer so <code>motatool</code> and the destination can verify the target, hardware, and version.</p> <p>Do not continue if <code>motatool verify</code> reports a failure.</p>"},{"location":"ota_easy/#nrf52-package-a-full-image-or-in-place-delta","title":"nRF52: package a full image or in-place delta","text":""},{"location":"ota_easy/#1-install-and-check-the-otafix-bootloader","title":"1. Install and check the OTAFIX bootloader","text":"<p>This is a one-time prerequisite. Install the OTAFIX bootloader built for the destination's exact board from the OTAFIX nRF52 bootloader releases. Internal-staging delta updates require OTAFIX 2.4 or newer. External QSPI and SD staging require OTAFIX 2.4.1 or newer and release notes that explicitly list the exact board and storage mode. Follow the release's board-specific installation and erase instructions. If it does not contain the destination's exact board, this LoRa install path is not yet available for that board; never substitute a similar board's bootloader.</p> <p>Before preparing or downloading a LoRa update, run this on the destination:</p> <pre><code>get bootloader.ver\nota self\n</code></pre> <p>The first command identifies the installed nRF52 bootloader. Continue only if the <code>ota self</code> reply includes the apply mode required by this target:</p> <pre><code>bootloader: apply OK\nbootloader: QSPI apply OK\nbootloader: SD apply OK\n</code></pre> <p>The reply also contains the running firmware's <code>base_hash</code>. Save it for the package check below. A stock, legacy, or older OTAFIX bootloader without <code>.mota</code> in-place-apply support will report that apply support is missing, and <code>ota install</code> will refuse to reboot into it.</p>"},{"location":"ota_easy/#2-choose-full-or-delta-packaging","title":"2. Choose full or delta packaging","text":"<p>For a QSPI- or SD-backed target, a full update needs only the new raw <code>firmware.hex</code>:</p> <pre><code>mkdir -p ./motas\nmotatool build --fw ./LilyGo_T-Echo_repeater-new.hex --out-dir ./motas\nmotatool verify ./motas/*.mota\n</code></pre> <p>Use a full package when an exact base image is unavailable. Use the delta path below when reducing airtime is worth retaining the exact running image.</p>"},{"location":"ota_easy/#3-keep-the-exact-current-and-new-application-images-for-a-delta","title":"3. Keep the exact current and new application images for a delta","text":"<p>You need the raw <code>.pio/build/&lt;environment&gt;/firmware.hex</code> from the build that is actually running, plus the corresponding <code>firmware.hex</code> from the new build. Save the current file before building the new version, because PlatformIO reuses that path. For example:</p> <pre><code># Save this immediately after building/flashing the version now running on the node.\ncp .pio/build/Heltec_t114_repeater_lora_ota_no_external_sensors/firmware.hex \\\n  ./Heltec_t114_repeater_lora_ota_no_external_sensors-running.hex\n\n# After checking out and building the new version, save its image separately.\ncp .pio/build/Heltec_t114_repeater_lora_ota_no_external_sensors/firmware.hex \\\n  ./Heltec_t114_repeater_lora_ota_no_external_sensors-new.hex\n</code></pre> <p>Replace <code>Heltec_t114_repeater_lora_ota_no_external_sensors</code> with the destination's exact PlatformIO environment. The two images must be for the same board and role, and both must contain their <code>EndF</code> trailers. Do not pass a release <code>.uf2</code> or BLE-DFU <code>.zip</code> to <code>motatool</code>; those are installation containers rather than raw application images.</p> <p>Keeping a file with the same version label is not enough: the base must be byte-for-byte identical to the running application. The hash check in the next step proves that it is the right file.</p> <p>On RAK4631 repeaters, use the <code>RAK_4631_repeater_lora_ota_no_external_sensors</code> environment. It retains built-in battery monitoring but omits selected optional environmental/ranging drivers so the delta fits the safe in-place workspace. INA219, INA226, INA260, and INA3221 I2C voltage/current monitors remain supported despite the legacy target name. That trim does not remove the SSD1306 OLED, autodiscovered I2C RTCs, or GPS-compatible RAK12500 I2C path. The <code>0x42</code> RAK12500/INA3221 addressing rule above still applies. If the device has a RAK15001 installed in sensor slot C and the matching RAK15001 OTAFIX bootloader, use <code>RAK_4631_repeater_rak15001_slot_c_lora_ota</code> instead. That target retains the full sensor/GPS set and can install either a full image or a delta from the external 2 MiB store.</p> <p>With the separately wired Winbond breakout, use <code>RAK_4631_repeater_w25q16_lora_ota</code> for RAK4631 or <code>RAK_3401_repeater_rak13302_w25q16_lora_ota</code> for RAK3401 + RAK13302. Both require an <code>EF4015</code> 2 MiB device. As a one-time prerequisite, install <code>wiscore_rak4631_w25q16</code> for RAK4631 or <code>wiscore_rak3401_rak13302_w25q16</code> for RAK3401 + RAK13302. Wire CLK/MISO/MOSI to the RAK19007 IO connector pins 26/27/28, CS to J11 AIN1, and VCC/GND to J12 VDD/GND. Fit an approximately 10 kOhm CS-to-VDD pull-up; never use VBAT. The SPI pins require underside taps or an interposer, but no sensor slot is occupied. See the nRF52 QSPI guide before installing either image.</p>"},{"location":"ota_easy/#4-build-and-check-the-in-place-delta","title":"4. Build and check the in-place delta","text":"<pre><code>mkdir -p ./motas\nmotatool build \\\n  --base ./Heltec_t114_repeater_lora_ota_no_external_sensors-running.hex \\\n  --fw ./Heltec_t114_repeater_lora_ota_no_external_sensors-new.hex \\\n  --patch-type in-place \\\n  --out-dir ./motas\nmotatool verify ./motas/*.mota\n</code></pre> <p><code>motatool</code> prints the generated filename. Inspect that file:</p> <pre><code>motatool inspect ./motas/GENERATED_FILENAME.mota\n</code></pre> <p>Check all three of these before serving it:</p> <ul> <li><code>codec_id</code> is <code>2 (detools-in-place)</code>.</li> <li><code>base_hash</code> is the same 8-byte value reported by the destination's <code>ota self</code> command.</li> <li>The numeric <code>target_id</code> exactly matches <code>target:</code> in the destination's <code>ota status</code>, and the hardware and   firmware version identify the intended board and role. If <code>inspect</code> shows <code>N/A</code> for the human-readable   target name, the tool's name table is older than that environment; the numeric IDs still must match.</li> </ul> <p>Current layout-aware <code>motatool</code> derives the safe workspace from the new firmware's authenticated EndF layout record, so the normal recipe deliberately omits <code>--inplace-memory</code>. If older tooling requires an explicit override, use <code>0xC6000</code> only for matched external SD/QSPI staging and <code>0x98000</code> for an internal-staging nRF52 such as the RAK4631 lean OTA build. Do not substitute the external value on an internal target, and do not override either value unless you have verified the exact app base, bootloader, and package geometry. Do not continue if verification or any identity check fails.</p>"},{"location":"ota_easy/#transfer-and-install-either-package","title":"Transfer and install either package","text":""},{"location":"ota_easy/#1-start-the-temporary-ota-channel","title":"1. Start the temporary OTA channel","text":"<p>First save the current <code>ota config</code> output. For a direct source-to-destination link, set both OTA-enabled endpoints to direct-only mode before starting the transfer:</p> <pre><code>ota config hops 0\n</code></pre> <p>Do not use <code>hops 1</code> as extra margin on a direct link. It tells a receiving repeater to retransmit each direct DATA/PROOF packet; that unnecessary half-duplex transmission can make it miss the source's next fragment, especially with older single-block receivers. Use <code>hops 1</code> only when one real intermediate relay is required, <code>hops 2</code> for two, and so on. This setting is saved, so restore the original value after the maintenance window.</p> <p>On the source node, destination node, and every intermediate repeater, then run:</p> <pre><code>tempradio 909.950,250,5,5,120\n</code></pre> <p>All participating nodes must use the same frequency, bandwidth, and spreading factor. Their time windows must overlap. Start with the farthest hop (the destination) and work back toward the source when using <code>tempradio</code>.</p> <p>If you administer the destination over LoRa, the controller used to send later <code>ota</code> commands must also be able to communicate on this temporary channel. For unattended nodes, use synchronized <code>tempradioat</code> entries instead of manually starting the windows. Ensure the nodes' clocks are set before using <code>tempradioat</code>.</p>"},{"location":"ota_easy/#2-serve-the-update-from-the-computer","title":"2. Serve the update from the computer","text":"<p>Close any serial terminal using the source node's USB port, find its device name, and start the server:</p> <pre><code>motatool serve --dir ./motas --serial /dev/ttyACM0 -v\n</code></pre> <p>Replace <code>/dev/ttyACM0</code> with the USB serial device of the source companion selected above. <code>motatool</code> attaches the folder to the source, which advertises the update over LoRa while its temporary-radio window is active. KISS modem serial ports cannot be used here.</p> <p>For an nRF52 Full Companion and a Bluetooth-capable host, the equivalent cable-free source is:</p> <pre><code>python3 tools/ble_mota/ble_mota_seeder.py \\\n  --device MeshCore-MyCompanion \\\n  --dir ./motas \\\n  --local 'tempradio 909.950,250,5,5,120'\n</code></pre> <p>Leave this command running until the destination finishes downloading.</p>"},{"location":"ota_easy/#3-find-and-download-the-update","title":"3. Find and download the update","text":"<p>On the destination node, check its state and ask for nearby updates:</p> <pre><code>ota status\nota ls\n</code></pre> <p>Discovery is asynchronous. <code>ota ls</code> says <code>refreshing</code>; wait a few seconds and run it again even if it first shows an older row. Select <code>[same target]</code>: it can say <code>full</code> for ESP32 and external SD/QSPI nRF52 targets, or <code>delta</code> for any supported nRF52 target. Do not select <code>[unsupported]</code> (for example, a source's self-served full image on an internal-staging nRF52). Rows labelled <code>bootloader</code> are also outside this ordinary application flow: they are never automatic and <code>ota install</code> refuses them. Only an already-capable, allowlisted internal-flash, XIAO-QSPI, or exact MeshTower V2 microSD nRF52 target can use the separate explicit bootloader workflow. Use the row's stable eight-hex manifest ID rather than its changing list position:</p> <pre><code>ota pull 838B8169 flash\n</code></pre> <p>If a legacy internal-flash nRF52 reports <code>no EndF</code>, only a row marked <code>[rescue]</code> is eligible. Current rescue-capable firmware requires <code>ota pull &lt;mid8&gt; flash rescue</code>, followed after completion by <code>ota rescue install &lt;base_hash16&gt;</code>. Older running firmware without those commands must be recovered over USB. Shared-internal bootloader-update builds are stricter: without a valid live <code>EndF</code>, every internal pull is refused before erase because the normal application may extend through <code>0xED000</code>. Recover those builds over USB/BLE DFU or SWD instead of relying on the older 608 KiB rescue estimate.</p> <p>Monitor the transfer:</p> <pre><code>ota status\n</code></pre> <p>For a powered bench update where restart-resume is not needed, <code>ota config checkpoint 0</code> on the destination removes periodic progress writes. It is a smaller optimization than selecting the correct hop count and it trades away persisted mid-download resume; restore the previous checkpoint cadence afterward.</p> <p>Current repeater firmware automatically uses the full transmit budget during a bounded TempRadio window. Older receivers do not: if <code>get af</code> reports a nonzero value on such a node, record it, use <code>set af 0</code> for the maintenance window, and restore it afterward. This affects how promptly the legacy receiver can send its next block/proof request; it does not increase LoRa transmit power. Use a full duty budget only where the selected frequency and local rules permit it.</p> <p>The update is ready when the status says <code>ready to install</code>. Discovery is background traffic, while an active OTA download is primary mesh traffic. At the temporary-radio settings in this guide, allow roughly one hour for a typical ESP32 full image over a quiet, direct link. That is a planning estimate, not an upper bound: repeaters, retries, weak links, and normal mesh traffic can extend it well past an hour. The 120-minute example window is intentional. If necessary, start another overlapping <code>tempradio</code> window; the download resumes rather than starting over.</p>"},{"location":"ota_easy/#4-verify-and-install","title":"4. Verify and install","text":"<p>Once the destination reports <code>ready to install</code>, run:</p> <pre><code>ota install\n</code></pre> <p>The destination verifies the complete package again before approving it. ESP32 installs the full image into its inactive A/B slot. nRF52 checks the bootloader and storage capabilities and, for a delta, the base hash, then reboots into OTAFIX. The bootloader independently rechecks the package, installs the external full image or applies the delta in place, and verifies the resulting image. Pre-install failures leave the running firmware unchanged and report the reason. If power is lost after an nRF52 in-place apply has begun, OTAFIX will not boot a partial image; it enters recovery DFU so a known-good application can be restored.</p> <p>After the node returns, reconnect on its normal radio channel and confirm:</p> <pre><code>ota status\n</code></pre>"},{"location":"ota_easy/#quick-troubleshooting","title":"Quick troubleshooting","text":"<ul> <li>Nothing appears in <code>ota ls</code>: confirm that <code>motatool serve</code> is still running and every required node   has an active <code>tempradio 909.950,250,5,5,120</code> window.</li> <li>The CLI says LoRa OTA is not included: that firmware does not contain the LoRa OTA feature.   If it is the source or destination, install a supported <code>-ota-</code> build over WiFi or USB first. An intermediate   repeater does not need the OTA CLI and can relay opaquely while its matching <code>tempradio</code> window is active.</li> <li>The update shows another environment or a raw <code>[hw XXXXXXXX]</code>: it is for a different board or firmware   role. Do not install it.</li> <li>An internal-flash nRF52 marks a full update <code>[unsupported]</code>: it can install only an in-place delta.   A matched QSPI repeater or MeshTower V2 microSD target accepts full images with its corresponding bootloader.</li> <li>A QSPI nRF52 reports <code>QSPI store:ERR 0K</code> or <code>bl:NO-QSPI</code>: do not download an install package. Install   the exact QSPI-aware bootloader and check that the selected application matches the board's flash wiring.   A RAK W25Q16 target must identify exactly <code>EF4015</code> and 2048K; also check its physical CS pull-up.</li> <li>nRF52 reports no bootloader apply support: install the exact-board in-place-delta OTAFIX bootloader   before trying LoRa OTA.</li> <li>nRF52 reports a base mismatch: the file passed to <code>--base</code> is not the exact application running on   the destination. Rebuild the delta from the correct saved <code>firmware.hex</code>.</li> <li>The download stalls: check the source, destination, and intermediate repeaters. Restart matching,   overlapping temporary-radio windows if one expired. On a direct link, also require <code>ota config hops 0</code>;   a larger reach makes a repeater destination unnecessarily echo source packets.</li> <li>The serial port is busy: close the serial terminal before starting <code>motatool serve</code>.</li> <li>The destination rejects the package: verify the source files, their <code>EndF</code> trailers, the package's   target/hardware identity, and the result of <code>motatool verify</code>.</li> </ul> <p>For additional commands and safety details, see the full OTA user guide. For protocol and container internals, see the OTA protocol specification.</p>"},{"location":"ota_meshtower_v2_sdcard/","title":"MeshTower V2 microSD LoRa OTA","text":"<p>The <code>Heltec_tower_v2_sdcard_repeater_lora_ota_no_external_sensors</code> target uses the MeshTower V2 onboard microSD socket as persistent storage for its own LoRa OTA downloads. It accepts full application images, in-place application deltas, and explicitly selected signed v3 bootloader packages. After verification, the matching SD-aware OTAFIX bootloader reads the staged file from the card and programs the selected nRF52840 application or bootloader region.</p> <p>The pin assignment follows the Heltec MeshTower V2 partial reference circuit:</p> Signal nRF52840 pin Arduino pin number SD CS P1.00 32 SD MOSI P1.01 33 SD SCK P0.06 6 SD MISO P0.26 26 <p>The SD socket uses its own SPI peripheral, so card traffic does not change the LoRa radio pinout.</p>"},{"location":"ota_meshtower_v2_sdcard/#card-requirements","title":"Card requirements","text":"<p>Use a FAT16, FAT32, or exFAT card accepted by the bundled SdFat version. The normal update path imposes no additional MBR/sector-1 layout requirement; filesystem layouts SdFat cannot mount are still rejected. MeshCore creates <code>/meshcore-ota.mota</code> as a contiguous file and passes its exact sector range to OTAFIX in reset-retained MCU RAM.</p> <p>MeshCore never reads or writes raw sector 1 and does not infer ownership from blank card sectors. Both application and bootloader OTA require a locally provisioned BLM2-capable bootloader that understands the retained-RAM record. Preview.12 must first be upgraded over USB/BLE DFU or SWD.</p>"},{"location":"ota_meshtower_v2_sdcard/#capacity-and-update-types","title":"Capacity and update types","text":"<p>The card removes the internal-flash staging limit. The <code>.mota</code> container may be much larger than the old internal staging gap, and either a full image or an in-place delta may be downloaded. The installed firmware itself must still fit the nRF52840 application region below InternalFS (ending at <code>0xED000</code>); SD storage does not increase the MCU's executable flash.</p> <p>For this S140 v6 target, the maximum application image including its <code>EndF</code> trailer is <code>0xC7000</code> bytes (815,104 bytes). To package a full self-update:</p> <pre><code>motatool build --fw ./Heltec_tower_v2_sdcard-new.hex \\\n  --sign ./trusted-signer.key --out-dir ./motas\nmotatool verify ./motas/*.mota\n</code></pre> <p>A delta uses the exact installed image as its base. The normal <code>0x98000</code> workspace remains compatible. If either image is larger than that legacy limit, build the patch with the SD target's larger workspace:</p> <pre><code>motatool build \\\n  --base ./Heltec_tower_v2_sdcard-running.hex \\\n  --fw ./Heltec_tower_v2_sdcard-new.hex \\\n  --patch-type in-place \\\n  --inplace-memory 0xC7000 \\\n  --sign ./trusted-signer.key \\\n  --out-dir ./motas\nmotatool verify ./motas/*.mota\n</code></pre> <p>The download is resumable because the partial <code>.mota</code> stays on the card. Once it reaches <code>ready</code>, <code>ota install</code> performs the final verification, publishes a one-reset authorization record, and reboots. SD application installation requires a valid signature from a key in the node's allowlist. Keep the card inserted through the reboot and installation.</p> <p>The BLM2 retained-auth SD-aware bootloader is mandatory for application OTA. <code>ota install</code> refuses to reboot if its continuity metadata does not match the running S140 family/FWID/application layout or if its capability marker does not advertise SD staging and the selected codec. Existing <code>Heltec_tower_v2_repeater</code> firmware continues to use the internal-flash delta path and is unchanged.</p>"},{"location":"ota_meshtower_v2_sdcard/#signed-bootloader-update","title":"Signed bootloader update","text":"<p>Only this exact SD build exposes the privileged LoRa bootloader-update command. It requires an already installed exact-board ABI-3 OTAFIX bootloader whose one unambiguous capability marker is exactly <code>0x09</code> (<code>SD|BOOT_UPDATE</code>) and whose codec mask is <code>0x0005</code> (<code>FULL|INPLACE</code>). Requiring both application codecs prevents a bootloader self-update from disabling either normal SD application path. A stock bootloader still requires USB/BLE DFU or SWD. The sole remote bootstrap is intentionally absent: preview.12 and any other legacy-v1 image must be upgraded locally before either SD application or bootloader OTA.</p> <p>The signed v3 container is exactly 41,330 bytes and carries a 40 KiB candidate for the installed <code>239A0071 / TOWER_V2_OTA</code> identity (boot target <code>1150F50E</code>). It uses the same contiguous <code>/meshcore-ota.mota</code> file as an application update. GPREGRET <code>0x6B</code> plus the distinct SD source marker <code>0x53</code> selects the bootloader path; LoRa transport remains payload type <code>0x0C</code>.</p> <p>The application linker still ends at <code>0xED000</code>, but OTAFIX needs <code>0xE0000..0xEA000</code> as temporary scratch while replacing itself. Before a boot package can be downloaded or approved, MeshCore requires a hash-valid live <code>EndF</code> proving the complete running image ends by <code>0xE0000</code>; OTAFIX repeats that no-overlap check before its first erase. An application extending above that boundary can still receive normal FULL or delta application updates from SD, but its bootloader must be updated locally.</p> <p>MeshCore also checks the live boot settings before touching that scratch page. Erased settings and a valid-app record with CRC disabled are allowed. When a nonzero bank CRC is active, its recorded <code>bank_0_size</code> must cover the complete EndF-inclusive running image and must end by <code>0xE0000</code>; an undersized or oversized record refuses the operation and requires local DFU/SWD.</p> <p>Because the card is removable, approval is bound to the exact bytes that were authenticated. For both fmt2 application and fmt3 bootloader packages, MeshCore authenticates one exact signed manifest, requires every streamed manifest byte to match it, and verifies the leaves, payload, and image. During that same pass it hashes the entire container with only the mutable four-byte <code>APRV</code> field normalized to zero. After writing and syncing <code>APRV</code>, MeshCore publishes a 72-byte <code>MOTASDA2</code> record at reset-retained RAM address <code>0x20006008</code>. The record binds package purpose/format, exact LBA range, card size, container length, and that normalized SHA-256. OTAFIX consumes and clears the record before reading the card; changing the card or file can only fail. A power loss erases the authorization and also fails closed.</p> <p>For fmt3, MeshCore additionally writes and readback-verifies the temporary 64-byte <code>MOTASDBL</code> token at <code>0xE0000</code>, binding the exact total and signed manifest <code>image_hash</code>. OTAFIX requires the parsed manifest, streamed payload, and final scratch image to match it. The token page becomes scratch during a successful boot update and is not permanently reserved.</p> <p>Every new candidate also carries a backward-compatible <code>BLM2</code>/<code>SOFT</code> continuity extension next to its legacy embedded manifest. The complete 76-byte envelope is fixed at final raw-image offset <code>0x9FB4</code>; a relocated copy is not a valid candidate. Its embedded bootloader version must equal the outer package version, match the runtime SoftDevice family/FWID, application base, and layout ABI, and be strictly newer than an installed BLM2 version. Preview values use low bytes <code>1..254</code> and a stable release uses <code>0xFF</code>; zero-preview and all-ones versions are invalid. Remote bootloader rollback is not supported; use local DFU/SWD when rollback or migration is intentional.</p> <p>Bootloader packages are never autofetched or autoinstalled. Select and confirm one exact package manually:</p> <pre><code>ota ls\nota pull &lt;MID8&gt; flash\n# wait for ota status to report the bootloader download ready\nota bootloader\nota bootloader install &lt;MID8&gt; &lt;HASH16&gt;\n</code></pre> <p>Copy the MID and first 16 image-hash hex digits from <code>ota bootloader</code>. Ordinary <code>ota install</code> rejects this package, and the bootloader command rejects an application package. Keep the SD card inserted through the reboot. A later <code>ota status</code> value of <code>blup:C8</code> reports a successful bootloader replacement.</p>"},{"location":"ota_meshtower_v2_sdcard/#sd-card-cli","title":"SD card CLI","text":"<p>The SD-backed target provides these CLI commands:</p> <pre><code>set sdcard format [--force]\nset sdcard erase [--force]\nget sdcard\nget sdcard *\nget sdcard format\nget sdcard erase\nget sdcard free\nget sdcard ls\nget sdcard ls 2\nget sdcard dir 3\n</code></pre> <p><code>format</code> creates a new FAT16, FAT32, or exFAT filesystem according to card size. <code>erase</code> first uses the card's raw media erase command and then formats it, so a successful erase finishes with a usable filesystem. Both operations destroy all data on the card and cancel any staged OTA download.</p> <p>The firmware records successful format and erase completion times in RAM. Repeating the same operation within five minutes is rejected unless <code>--force</code> is present. Format and erase have independent cooldowns. Because erase also formats the card, a successful erase updates both timestamps. The timestamps reset when the device reboots. The <code>get sdcard</code> age queries report how long ago each operation completed. <code>get sdcard free</code> reports used and free filesystem space in human-readable binary units.</p> <p><code>get sdcard ls</code> and <code>get sdcard dir</code> recursively list files on the card, two files per page. A bare command shows page 1; append a positive page number to move through the remaining results. Each row includes the path and a compact file size. The header reports the selected page, total pages, and total files.</p>"},{"location":"ota_meshtower_v2_sdcard/#persistent-ota-archive-and-seeder","title":"Persistent OTA archive and seeder","text":"<p>On the SD-backed target, automatic OTA archiving is on by default. While the temporary OTA radio is active, the node requests full catalogs from seeders and saves every complete mOTA it discovers, including firmware for other hardware targets and codecs that this node cannot install. Archive downloads use the same per-block Merkle proof checks as an install download, but archived images are never selected for local installation.</p> <p>Completed containers are stored as <code>/mota/&lt;manifest-id&gt;.mota</code>. An interrupted download remains <code>/mota/&lt;manifest-id&gt;.part</code> and resumes when that mOTA is seen again. Completed files survive reboot, are enumerated on the first archive access or TempRadio window, and are advertised and served directly from SD. The SD target supports the protocol maximum served set: its own running firmware plus up to 254 archived mOTAs.</p> <p>Automatic capture preserves an 8 MiB free-space reserve for manual <code>/meshcore-ota.mota</code> installation staging. It stops starting new archive files when the next file would cross that reserve. Archive allocation first tries the fast contiguous path and then falls back to an ordinary fragmented FAT file; only the bootloader staging file requires contiguous sectors.</p>"},{"location":"ota_meshtower_v2_sdcard/#preload-many-motas-from-a-computer","title":"Preload many mOTAs from a computer","text":"<p>You can populate the archive much faster on a computer than over LoRa. Use only complete, verified <code>.mota</code> containers. Do not copy firmware <code>.bin</code>, <code>.hex</code>, <code>.zip</code>, or <code>.part</code> files into the archive.</p> <p>Install the standalone <code>motatool</code> first if it is not already available:</p> <pre><code>git clone https://github.com/vk496/motatool.git\ncargo install --path ./motatool\n</code></pre> <p>The on-card filename is part of the archive index and has a strict format:</p> <pre><code>/mota/&lt;merkle_root&gt;.mota\n</code></pre> <p><code>&lt;merkle_root&gt;</code> is the eight-hex-digit value printed by <code>motatool inspect</code>. It is also the mOTA's four-byte manifest ID. The extension must be lowercase, the file must be directly inside <code>/mota</code>, and descriptive release filenames are not indexed. For example, if inspection reports:</p> <pre><code>merkle_root    : ABCD1234\n</code></pre> <p>copy that container to:</p> <pre><code>/mota/abcd1234.mota\n</code></pre> <p>If two containers have the same Merkle root, they have the same protocol ID and cannot both be present. Keep only the intended one. The current SD seeder can index up to 254 archived files. A served file must use a logical block size of at most 1024 bytes and contain at most 2048 blocks; check <code>block_size</code> and <code>block_count</code> in <code>motatool inspect</code> when importing unusually large images. Files outside that serve geometry are not counted or advertised. If a malformed <code>/mota/&lt;id&gt;.mota</code> conflicts with a newly discovered valid image, the repeater preserves the malformed file as <code>&lt;id&gt;.bad</code> through <code>&lt;id&gt;.bad9</code> and downloads a clean replacement instead of treating path existence as a valid cache hit.</p> <p>To prepare and load the card:</p> <ol> <li>Format it as described under Card requirements. The    easiest route is to insert it in the repeater, run <code>set sdcard format</code>, power    the repeater off, and then move the card to the computer. Formatting destroys    the existing card contents.</li> <li>Mount the card on the computer and create a directory named <code>mota</code> at the    filesystem root. Do not use a nested directory such as <code>/firmware/mota</code>.</li> <li>Run <code>motatool verify FILE.mota</code> for every source file. Do not copy a file    that reports <code>FAIL</code>.</li> <li>Run <code>motatool inspect FILE.mota</code>, read its <code>merkle_root</code>, and copy the file    to <code>/mota/&lt;lowercase-merkle-root&gt;.mota</code> on the card.</li> <li>Flush pending writes, safely eject the card, power the repeater off, insert    the card, and boot    <code>Heltec_tower_v2_sdcard_repeater_lora_ota_no_external_sensors</code>.</li> </ol> <p>On Linux or macOS, this Bash example verifies and imports every <code>.mota</code> from <code>./motas</code>. Replace the example mount path before running it:</p> <pre><code>card_mount=/media/YOU/MESHCORE\nmkdir -p \"$card_mount/mota\"\n\nshopt -s nullglob\nfor image in ./motas/*.mota; do\n  motatool verify \"$image\" || exit 1\n  mid=$(motatool inspect \"$image\" |\n    awk '$1 == \"merkle_root\" { print tolower($3) }')\n  if [[ ! $mid =~ ^[0-9a-f]{8}$ ]]; then\n    echo \"Could not read the Merkle root from: $image\" &gt;&amp;2\n    exit 1\n  fi\n\n  destination=\"$card_mount/mota/$mid.mota\"\n  if [[ -e $destination ]]; then\n    cmp -s \"$image\" \"$destination\" || {\n      echo \"Different containers have the same ID: $mid\" &gt;&amp;2\n      exit 1\n    }\n  else\n    cp \"$image\" \"$destination\"\n  fi\ndone\nsync\n</code></pre> <p>On Windows, create <code>E:\\mota</code>, inspect each source with <code>motatool inspect</code>, and rename it to the reported lowercase root in the same way. Safely eject the drive after all copies finish.</p> <p>After boot, scan the archive and confirm the card contents from the repeater console:</p> <pre><code>get sdcard ls\nget sdcard ls 2\nota cache\nota folder\n</code></pre> <p><code>ota cache</code> should report the imported count. <code>ota folder</code> reports the current served count; once OTA serving starts in TempRadio, that set also includes the repeater's running firmware. If the files appear in <code>get sdcard ls</code> but not in the served count, check their exact names, run <code>motatool verify</code> again, and inspect their block geometry. It is fine to run <code>ota cache off</code> for a curated, read-mostly archive: that disables capture of new mOTAs but continues serving every valid file already on the card.</p>"},{"location":"ota_meshtower_v2_sdcard/#serve-the-preloaded-archive-over-tempradio","title":"Serve the preloaded archive over TempRadio","text":"<p>LoRa OTA traffic exists only during an active temporary-radio window. The SD repeater, each receiving node, and every intermediate repeater in the path need overlapping windows on the same temporary channel. Use a frequency permitted for the node's configured region. This North American example uses the recommended fast OTA settings and a 120-minute window:</p> <pre><code>tempradio 909.950,250,5,5,120\n</code></pre> <p>Start the farthest receiving node first, then intermediate repeaters, and the SD source last so their windows overlap for as long as possible. Before or during the source window, <code>ota cache</code> makes the source scan and attach the SD archive. Entry into TempRadio automatically triggers an OTA advertisement burst; <code>ota announce</code> can send another advertisement immediately.</p> <p>On a receiving OTA-capable node, allow a few seconds for catalog exchange, then run:</p> <pre><code>ota ls\nota ls 2\nota get &lt;mid8&gt; flash\nota status\n</code></pre> <p>Use <code>ota ls 2</code>, <code>ota ls 3</code>, and so on when the source advertises more than the two rows that fit in one remote CLI reply. Each row includes a stable eight-hex-digit manifest ID. Use that ID instead of a list number, because asynchronous catalog refreshes can reorder rows between the list and pull commands. A receiver retains the complete protocol catalog and verifies every transferred block. It still applies its normal target, hardware, codec, signature, and installation checks. The SD repeater may advertise images for many hardware families; it never installs those archive files merely because it serves them.</p> <p>When a temporary window expires or a node reboots, it returns to its saved radio settings and OTA transfer stops. The archive remains on the card. Start another set of overlapping <code>tempradio</code> windows to resume an interrupted download, or use synchronized <code>tempradioat</code> entries for a scheduled window.</p> <p>Archive capture is lower priority than operator work. An explicit <code>ota pull</code> to install storage or a host folder immediately takes the single receive slot; the archive partial is checkpointed and resumes later. Existing cached files can still answer peer requests while another archive file is downloading.</p> <p>Use these commands to inspect or control automatic capture:</p> <pre><code>ota cache\nota cache on\nota cache off\nota config cache on\nota config cache off\n</code></pre> <p>The on/off choice is saved on the SD card. Turning capture off stops new downloads but keeps serving files already cached. Formatting or erasing the card removes both the archive and its off marker, so a newly formatted card returns to the default-on setting. <code>ota config sdseed on|off</code> is also accepted as an alias.</p>"},{"location":"ota_nrf52_bootloader_update/","title":"nRF52 bootloader updates over LoRa","text":"<p>Selected nRF52840 repeater LoRa-OTA builds can replace their matching OTAFIX bootloader without replacing the running application. This is a privileged maintenance path, not a normal firmware update. A stock bootloader must first be replaced with the exact ABI-3 self-update-capable OTAFIX build over USB/BLE DFU or SWD. MeshTower SD also requires the BLM2 retained-auth version to be provisioned locally before either application or bootloader OTA.</p>"},{"location":"ota_nrf52_bootloader_update/#storage-layouts","title":"Storage layouts","text":"Layout Application limit Staged boot package Work area Handoff / capability XIAO-module raw QSPI below <code>0xE0000</code> external QSPI offset 0 dedicated internal <code>0xE0000..0xEA000</code> scratch source <code>0x51</code>, flags <code>0x0E</code> Qualified internal-flash target normal <code>0xED000</code> limit shared internal slot, exact start <code>0xE2000</code> the same eleven-page slot; no second reservation source <code>0xED</code>, flags <code>0x0A</code> MeshTower V2 microSD normal <code>0xED000</code> limit contiguous <code>/meshcore-ota.mota</code> dynamic internal <code>0xE0000..0xEA000</code> scratch; live image must end by <code>0xE0000</code> source <code>0x53</code>, flags <code>0x09</code> <p>The exact SD target is <code>Heltec_tower_v2_sdcard_repeater_lora_ota_no_external_sensors</code>. Its normal application FULL and delta updates continue to use the SD file without the bootloader-update scratch restriction. For a bootloader package only, both MeshCore and OTAFIX require a hash-valid live <code>EndF</code> proving the complete running image ends at or below <code>0xE0000</code>. If boot settings carry a nonzero app bank CRC, the recorded bank size must also cover that full EndF-inclusive image and stop by <code>0xE0000</code>; erased or explicitly CRC-disabled settings remain valid. OTAFIX then copies the verified 40 KiB payload from SD into <code>0xE0000..0xEA000</code> and uses the MBR copy operation to replace <code>0xF4000..0xFE000</code>. The application linker remains at <code>0xED000</code>; a future application extending above <code>0xE0000</code> can still use application mOTA but must update its bootloader through local DFU/SWD.</p> <p>The removable SD authorization is fail-closed for both application and bootloader packages. MeshCore directly authenticates one exact signed manifest, requires the streamed copy to remain byte-identical, verifies all leaves/payload/image bytes, and computes a normalized full-container SHA-256 in that same pass (<code>APRV</code> bytes are treated as zero). After syncing <code>APRV</code>, it publishes a 72-byte <code>MOTASDA2</code> record in reset-retained RAM at <code>0x20006008</code>. That record binds purpose/format, first LBA, sector count, total length, card sector count, and the normalized digest. OTAFIX copies, validates, and clears the record before SD access. A card swap/mutation or a power cycle therefore fails closed; there is no general sector-1 ownership inference.</p> <p>For fmt3, MeshCore also writes and readback-verifies a 64-byte <code>MOTASDBL</code> token at <code>0xE0000</code>. That token contains the exact container length and the exact authenticated signed manifest <code>image_hash</code>. OTAFIX requires the same hash in the parsed manifest, streamed payload, and final scratch image. The page is consumed as scratch during success and is not permanently reserved.</p> <p>The first BLM2-capable MeshTower bootloader cannot be delivered to preview.12 through the retained-RAM protocol that preview.12 predates. MeshCore does not write a raw-sector compatibility record because a blank sector is not proof of ownership. Upgrade preview.12 through USB/BLE DFU or SWD. Both fmt2 application and fmt3 bootloader OTA then require the installed BLM2 metadata to match the live SoftDevice/application layout; neither MeshCore nor OTAFIX uses sector 1.</p> <p>The internal path does not change the application linker or permanently set aside separate app-OTA, boot-package, and scratch regions. The ordinary bottom-aligned internal store holds one container at a time: either an application delta or a bootloader package.</p> <p>The exact bootloader container is 41,330 bytes: 365 bytes of signed mOTA metadata, a 40 KiB payload, and the five-byte trailer. Below the normal <code>0xED000</code> store ceiling it bottom-aligns at <code>0xE2000</code>. Admission requires a hash-valid live <code>EndF</code> proving the current application, including its trailer, ends at or before <code>0xE2000</code>. OTAFIX then reads each source window before erasing and compacts the payload forward in place to the page-aligned raw range <code>0xE2000..0xEC000</code>; it verifies every page and the whole image before asking the MBR to copy that image over <code>0xF4000..0xFE000</code>.</p> <p>An ordinary application delta can be smaller or larger than this eleven-page shape. It bottom-aligns dynamically below <code>0xED000</code> and may begin below <code>0xE2000</code>; its detools workspace must stop at its actual container start, while the reconstructed application must stop below <code>0xED000</code>. The two package kinds are mutually exclusive because they use the same store.</p> <p>For internal-self-update builds, an absent or corrupt live <code>EndF</code> disables all internal staging before the first erase. The older 608 KiB rescue estimate is unsafe when a normally linked application may extend to <code>0xED000</code>. Builds without this feature retain the legacy rescue behavior.</p>"},{"location":"ota_nrf52_bootloader_update/#internal-flash-target-inventory","title":"Internal-flash target inventory","text":"<p>The release builder consumes the allowlist in <code>tools/mota/nrf52_internal_bootloader_targets.txt</code>. Ten names are also literal PlatformIO environments and are enabled automatically when built directly. The other eleven are release aliases assembled from a base environment plus the lean OTA overlay; build them through <code>build.sh</code>, which passes the same allowlist decision to the common pre-build guard. These lean repeater/bridge targets have no OTA-owned SD/QSPI store and have an exact curated OTAFIX manifest identity:</p> Build target(s) Installed OTAFIX identity Boot target ID <code>Heltec_tower_v2_repeater_lora_ota_no_external_sensors</code> <code>239A0071 / TOWER_V2_OTA</code> <code>1150F50E</code> T096 lean repeater and RS232 bridge <code>239A0071 / T096_DFU</code> <code>42354C85</code> <code>Heltec_t1_repeater_lora_ota_no_external_sensors</code> <code>239A0071 / T1_DFU</code> <code>FC556FFC</code> T114 display and without-display lean repeaters <code>239A0071 / T114_DFU</code> <code>0C3F2902</code> <code>Mesh_pocket_repeater_lora_ota_no_external_sensors</code> <code>239A0071 / MESH_POCKET_OTA</code> <code>059277F4</code> <code>KeepteenLT1_repeater_lora_ota_no_external_sensors</code> <code>239A00B3 / KeepteenLT1_OTA</code> <code>DB2E7B51</code> <code>Minewsemi_me25ls01_repeater_lora_ota_no_external_sensors</code> <code>239A0029 / MX25_DFU</code> <code>026AA982</code> <code>ProMicro_repeater_lora_ota_no_external_sensors</code> <code>239A00B3 / PROM_DFU</code> <code>AF79E8CC</code> <code>t1000e_repeater_lora_ota_no_external_sensors</code> <code>28860057 / T1KE_DFU</code> <code>E6F5F03F</code> <code>ThinkNode_M3_repeater_lora_ota_no_external_sensors</code> <code>239A00DA / TNM3_DFU</code> <code>0CA41DB2</code> <code>RAK_3401_repeater_lora_ota_no_external_sensors</code> <code>239A0029 / 3401_DFU</code> <code>23818A80</code> RAK4631 lean repeater and both lean RS232 bridges <code>239A0029 / 4631_DFU</code> <code>2D0DF000</code> GAT562 30S/Tracker Pro/EVB Pro lean targets <code>239A0029 / GAT562_DFU</code> <code>D50D2D44</code> <code>R1Neo_repeater_lora_ota_no_external_sensors</code> <code>239A0029 / 4631_DFU</code> <code>2D0DF000</code> <code>RAK_WisMesh_Tag_repeater_lora_ota_no_external_sensors</code> <code>239A0029 / RTAG_DFU</code> <code>C72E9C9C</code> <p>Board IDs are not globally unique. For generic targets, the signed hardware ID is the exact NUL-padded 32-byte value <code>NRF_BL_&lt;BOARD_ID&gt;_&lt;DEVICE_NAME&gt;</code>. The wire target is the little-endian first four SHA-256 bytes of all 32 padded bytes. The installed and candidate embedded manifest pairs must match exactly. XIAO retains its deployed <code>XIAO_BL_28860044</code> / <code>XIAO_BL_28860045</code> identity and raw board-ID target.</p> <p>The Python reference builder and release tooling audit these boot targets for duplicates and collisions with application target IDs. Generic image parsing can inspect a future canonical identity, but signing/building a package fails until that exact identity is in the qualified inventory.</p> <p>Earlier GAT562 installations may report the RAK-compatible <code>4631_DFU</code> identity. The installed and candidate identity pair must match exactly, so a remote bootloader update cannot migrate one of those devices to <code>GAT562_DFU</code>. Provision the GAT562-specific OTAFIX bootloader once through USB/BLE DFU or SWD; subsequent signed bootloader mOTA updates use target <code>D50D2D44</code>.</p>"},{"location":"ota_nrf52_bootloader_update/#embedded-continuity-and-version-policy","title":"Embedded continuity and version policy","text":"<p>Every remotely supplied successor retains the legacy 44-byte CRC-valid <code>BLMF</code> v1 record for identity continuity and diagnostics. Immediately after that record is a 32-byte <code>BLM2</code>/<code>SOFT</code> extension. The complete 76-byte envelope is fixed at the final raw-image offset <code>0x9FB4</code>; relocated candidates are refused, while installed legacy-v1 discovery remains a generic diagnostic scan. The extension carries the actual packed bootloader version, SoftDevice family and FWID, application base, layout ABI, and zero compatibility/reserved fields; the legacy whole-image CRC covers the extension too. Scanners first count CRC-valid 44-byte base manifests, then interpret continuity only after one base identity remains. A malformed claimed extension therefore cannot make a duplicate identity disappear, and a sole half-present extension is rejected rather than treated as legacy.</p> <p>MeshCore requires the candidate extension, exact equality between its embedded version and the signed outer mOTA version, and exact agreement with the running SoftDevice family/FWID/application layout. Qualified internal/QSPI paths may bootstrap a CRC-valid installed legacy-v1 image once; the SD path never does and requires local BLM2 provisioning. Once the installed bootloader has BLM2 metadata, the candidate version must be strictly greater. Preview low bytes are <code>1..254</code>, a stable release uses <code>0xFF</code>, and low-byte zero or all-ones values are rejected. There is no remote rollback/migration override; intentional rollback uses USB/BLE DFU or SWD.</p> <p>The legacy <code>no_external_sensors</code> profiles trim selected optional environmental and ranging drivers to preserve flash headroom; they do not generally disable the I2C bus. Reduced RAK3401 and RAK4631 recipes retain INA219, INA226, INA260, and INA3221 voltage/current monitors. Those are entries in the optional sensor table, not the complete set of I2C consumers: the SSD1306 OLED, supported autodiscovered RTCs, and RAK12500 GPS remain separate I2C peripherals where the exact board recipe enables them. RAK3401 retains its compatible RAK12500 I2C and RAK12501/L76K UART GPS paths in sensor slot A. The plain RAK4631 repeater and Serial2 bridge retain GPS. Its RAK12501 path uses Serial1; the explicitly compiled Serial1 RS232 bridge therefore omits the combined GPS provider, including RAK12500, even though RAK12500 itself is I2C rather than UART.</p> <p>The firmware-configured INA3221 and RAK12500 addresses are both <code>0x42</code>. They cannot coexist on the same bus at those addresses. Leave RAK12500 at <code>0x42</code>, strap INA3221 A0 to SCL for <code>0x43</code>, and use firmware built with <code>-DTELEM_INA3221_ADDRESS=0x43</code> when both modules are installed.</p> <p>Boards with onboard external flash are not silently redirected to internal staging. Mesh Solar, Nano G2 Ultra, T-Impulse Plus, ThinkNode M8, T-Echo Lite/Card, MeshTracker X1, and Wio WM1110 have board-specific QSPI hardware and need a separately matched QSPI path where available. Full Companions, other SD/QSPI/ExtraFS roles, Ethernet roles, source-only roles, and unqualified full-sensor roles are excluded from the internal-flash inventory. The exact MeshTower V2 SD role above is separately qualified for its SD path.</p> <p>This internal layout is limited to nRF52840 devices with 1 MiB internal flash, the exact S140 v6/v7 map, and the 40 KiB boot region at <code>0xF4000..0xFE000</code>. nRF52833 and smaller nRF52 parts cannot provide that map plus a non-overlapping 41,330-byte live staging slot, so configuration fails closed instead of selecting smaller or overlapping geometry.</p>"},{"location":"ota_nrf52_bootloader_update/#explicit-install-workflow","title":"Explicit install workflow","text":"<p>Check the installed identity and capability marker:</p> <pre><code>ota bootloader\n</code></pre> <p>The response must show a CRC-valid exact identity, ABI 3 or newer, both FULL and INPLACE application codecs (<code>codecs=0x5</code>), and exact flags <code>0x09</code> for MeshTower V2 SD, <code>0x0A</code> for internal shared storage, or <code>0x0E</code> for XIAO QSPI. A bootloader row is visible in <code>ota ls</code>, but it is never autofetched or autoinstalled. Fetch its exact MID, then explicitly arm it:</p> <pre><code>ota pull &lt;MID8&gt; flash\n# wait for ota status to report the download ready\nota bootloader\nota bootloader install &lt;MID8&gt; &lt;HASH16&gt;\n</code></pre> <p>Copy both confirmation values from the second <code>ota bootloader</code> response. Ordinary <code>ota install</code> rejects a bootloader package; the bootloader command rejects an application package. The FULL-codec exception exists only for that manual bootloader MID. Ordinary application FULL remains disabled on an internal single-slot node, bootloader autofetch remains off, and a partial bootloader package is not automatically resumed after an application reboot.</p> <p>Before writing <code>APRV</code>, the application authenticates and authorizes the package: exact v3 geometry, trusted Ed25519 signer, signed/embedded identity, one unambiguous capability marker, embedded CRC, sane vectors, complete Merkle/payload/image hashes, storage-specific safe live placement, and the typed MID/hash confirmation. The manifest root and target inside the received manifest must also equal the MID/target that opened the fetch before any store is allocated. On SD, <code>APRV</code>, the retained geometry/container authorization, and the internal signed-image-hash token are published in that order before the reset trigger. OTAFIX consumes that application-written authorization and then independently rechecks the safety/integrity subset: strict v3 structure, canonical identity/capabilities, vectors, full payload SHA, embedded manifest CRC, the applicable live <code>EndF</code>/bank-settings no-overlap geometry, the SD token binding where applicable, scratch readback, and final copy hash. It does not re-run Ed25519, the signer allowlist, Merkle leaves/root, or the typed operator confirmation. Success is reported as <code>blup:C8</code>.</p>"},{"location":"ota_nrf52_bootloader_update/#failure-behavior","title":"Failure behavior","text":"<p>The feature fails closed when the MCU/map is wrong, required valid <code>EndF</code> headroom is insufficient, an unsupported external/ExtraFS role owns the target, the exact installed capability marker is absent or ambiguous, identity cannot be derived unambiguously, or any package check fails. Before the storage-specific scratch/copy step, the application and bootloader are unchanged. OTAFIX consumes the trigger and authorization before its first destructive action, so an interrupted operation cannot automatically retry a partly consumed package. On SD, the retained-RAM authorization is zero-consumed before media access; <code>APRV</code> and the fmt3 flash token may persist but are inert without a new explicit authenticated re-arm and reset trigger. No SD raw-sector handoff is created or consumed. Use USB/BLE DFU or SWD for initial provisioning and local recovery.</p> <p>For XIAO and ordinary external-QSPI details, see nRF52 repeater LoRa OTA with external QSPI.</p>"},{"location":"ota_nrf52_qspi/","title":"nRF52 repeater LoRa OTA with external QSPI","text":"<p>Selected nRF52840 repeater builds use their dedicated external QSPI NOR flash as a raw LoRa OTA staging device. This removes the internal-flash staging conflict: the complete <code>.mota</code> stays off-chip, and the bootloader can use the entire internal application region while it installs either a full image or an in-place delta.</p> <p>This is a matched application-and-bootloader feature. A board merely having an nRF52840, free RAM, or pins named QSPI is not enough. Both halves must use the exact flash wiring, and <code>ota self</code> must confirm the store and bootloader before an update is downloaded.</p>"},{"location":"ota_nrf52_qspi/#supported-repeater-families","title":"Supported repeater families","text":"<p>QSPI staging is enabled only for explicitly matched repeater-role environments (and RS232 bridge variants that directly inherit one of those repeater targets) on these currently matched families:</p> <ul> <li>Seeed XIAO nRF52840 and XIAO nRF52840 Sense modules, including the   <code>Xiao_nrf52</code>, SolarXiao 30S/33S, and XIAO-module Ikoka handheld, Nano, and   Stick repeaters</li> <li>original LilyGo T-Echo</li> <li>Elecrow ThinkNode M1 and M6</li> <li>Seeed Wio Tracker L1</li> <li>Seeed SenseCAP Solar Node P1</li> <li>RAK4631 with a RAK15001 in WisBlock sensor slot C, using the dedicated   <code>RAK_4631_repeater_rak15001_slot_c_lora_ota</code> application and matching   <code>wiscore_rak4631_board_rak15001_slot_c</code> OTAFIX bootloader</li> <li>RAK4631 with an externally wired Winbond W25Q16JV breakout on RAK19007,   using <code>RAK_4631_repeater_w25q16_lora_ota</code></li> <li>RAK3401 with its RAK13302 1 W radio and the same externally wired W25Q16JV   breakout on RAK19007, using   <code>RAK_3401_repeater_rak13302_w25q16_lora_ota</code></li> </ul> <p>Heltec T114 is intentionally not in this list. Its public V1, V2.0, and V2.1 schematics show U9 (MX25R1635F) as an optional QSPI footprint, so standard T114 application and bootloader targets do not assume that external NOR is populated.</p> <p>The XIAO-module derivatives use the matching XIAO or XIAO Sense OTAFIX bootloader shown by the module's <code>INFO_UF2.TXT</code>. Do not substitute a similar bootloader for a board with different QSPI pins. For example, the T-Echo Card and T-Echo Lite have different flash wiring and are not enabled by the original T-Echo target.</p> <p>Companion builds are intentionally excluded. Some companion targets use the same external QSPI as a LittleFS message/data store, where raw OTA staging would corrupt the filesystem; other companions simply do not assign that chip to OTA. Room-server, sensor, and KISS roles are unchanged. Raw QSPI OTA is scoped to the explicitly matched repeater-derived environments.</p>"},{"location":"ota_nrf52_qspi/#rak15001-placement-and-module-conflicts","title":"RAK15001 placement and module conflicts","text":"<p>RAK15001 is a 2 MiB GD25Q16C standard SPI module, not a quad-I/O flash. The dedicated RAK4631 target uses the nRF52840 QSPI peripheral in its single-data-line FAST_READ/page-program modes at 8 MHz and accepts only the module's exact <code>C8 40 15</code> JEDEC ID. <code>ota self</code> reports <code>QSPI store:2048K</code> only when the expected module responds. An empty slot or a different SPI device reports <code>QSPI store:ERR 0K</code>, and install is refused.</p> <p>The module is electrically usable in sensor slot A-D because those slots share the SPI signals and RAK15001 has onboard 10 kOhm pull-ups on WP# and HOLD#. The supported MeshCore/OTAFIX combination nevertheless requires slot C. It is the placement that remains safe when a RAK12501 GNSS is fitted in either of its supported slots, A or D: slot C avoids the GNSS PPS/reset nets on IO1/IO2 and IO5/IO6. In particular, GPS in A plus flash in B would share IO1/IO2 through the modules' auxiliary pins.</p> <p>Only one device that uses the shared WisBlock SPI chip-select may be fitted. Do not combine this target with RAK13800 Ethernet, RAK15002 SD, or another SPI module. RAK13800 and RAK15001 cannot coexist because they use the same SPI chip-select. Update a RAK13800 Ethernet build locally over USB using the release's Manual UF2 or Serial DFU (.zip) download; it cannot use this RAK15001 LoRa-OTA staging target.</p> <p>RAK3401 with RAK13302 remains incompatible with RAK15001. The 1 W radio uses the same WisBlock SPI clock/data pins and the same chip-select as RAK15001. Firmware cannot independently select or detect those two chips, so a stock RAK3401 + RAK15001 assembly cannot provide reliable OTA staging without a hardware chip-select rework. This restriction does not apply to the separate-CS W25Q16 wiring below.</p>"},{"location":"ota_nrf52_qspi/#one-w25q16-wiring-for-rak4631-or-rak3401-rak13302","title":"One W25Q16 wiring for RAK4631 or RAK3401 + RAK13302","text":"<p>An external Winbond W25Q16JV breakout can remain attached to a RAK19007 while the core is changed between RAK4631 and RAK3401 + RAK13302. It shares only the WisBlock SPI clock/data nets and has its own chip-select on AIN1:</p> W25Q16 breakout RAK19007 connection nRF52840 / Arduino pin <code>CLK</code> IO connector pin 26, <code>SPI_CLK</code> P0.03 / <code>3</code> <code>DO</code> / MISO IO connector pin 27, <code>SPI_MISO</code> P0.29 / <code>29</code> <code>DI</code> / MOSI IO connector pin 28, <code>SPI_MOSI</code> P0.30 / <code>30</code> <code>CS</code> J11 <code>AIN1</code> P0.31 / <code>31</code> <code>VCC</code> J12 <code>VDD</code> regulated 3.3 V <code>GND</code> J12 <code>GND</code> ground <p>Fit a physical approximately 10 kOhm pull-up from <code>CS</code> to J12 <code>VDD</code>. That keeps the flash deselected during reset, bootloader entry, and a core-module swap. Power the breakout only from J12 <code>VDD</code>; never use J11 <code>VBAT</code>, which can exceed the flash's supply rating. The six-pin breakout does not expose WP#/IO2 or HOLD#/IO3; do not add nRF IO2/IO3 wiring. A breakout with an onboard power LED works, but that LED draws continuously and is undesirable for low-power or solar operation.</p> <p>This arrangement consumes no WisBlock sensor slot. However, <code>SPI_CLK</code>, <code>SPI_MISO</code>, and <code>SPI_MOSI</code> are not available on the easy 2.54 mm J10/J11/J12 headers. Those three signals require a short underside-pad tap or a suitable IO-connector interposer at pins 26-28. J11 and J12 alone are not sufficient.</p> <p>GPS remains supported in sensor slot A. RAK12500 uses I2C, while RAK12501/L76K uses UART plus its auxiliary control signals; neither uses the shared SPI clock/data bus. On RAK4631 the built-in SX1262 has a separate private SPI bus. On RAK3401 the RAK13302 and flash share clock/data, but have independent chip-selects: RAK13302 NSS is P0.26 and flash CS is P0.31. The matched firmware holds the radio NSS high while it temporarily hands the bus to the flash, then restores the radio SPI interface.</p> <p>The breakout target accepts only a 2 MiB W25Q16 with JEDEC ID <code>EF 40 15</code> and runs it at 8 MHz in standard single-data-line SPI mode. A substituted W25Q32, W25Q64, or W25Q128 fails closed instead of being treated as the OTA store. Use the complete application/bootloader identity row that matches the fitted core:</p> Core and radio PlatformIO environment MOTA hardware identity OTAFIX board / DFU device name RAK4631 built-in SX1262 <code>RAK_4631_repeater_w25q16_lora_ota</code> <code>RAK4631_W25Q16</code> <code>wiscore_rak4631_w25q16</code> / <code>4631_W25Q16_DFU</code> RAK3401 + RAK13302 1 W <code>RAK_3401_repeater_rak13302_w25q16_lora_ota</code> <code>RAK3401_RAK13302_W25Q16</code> <code>wiscore_rak3401_rak13302_w25q16</code> / <code>3401_W25Q16_DFU</code> <p>The physical flash wiring is identical, but the two application and bootloader pairs are not interchangeable.</p>"},{"location":"ota_nrf52_qspi/#one-time-prerequisite","title":"One-time prerequisite","text":"<p>Install a QSPI-capable OTAFIX 2.4.1 preview.9 or newer bootloader for the exact board from the OTAFIX releases before using LoRa OTA. The release notes must explicitly list that board's QSPI mode. Also install the SoftDevice version expected by that target. The application refuses the install handoff when the bootloader does not advertise QSPI support.</p> <p>For the external W25Q16 option, install the corresponding bootloader once before installing its MeshCore application: <code>wiscore_rak4631_w25q16</code> (<code>DEVICE_NAME=4631_W25Q16_DFU</code>) for RAK4631, or <code>wiscore_rak3401_rak13302_w25q16</code> (<code>DEVICE_NAME=3401_W25Q16_DFU</code>) for RAK3401 plus RAK13302. Use only a release that explicitly names that exact pairing. Do not substitute the RAK15001 bootloader or swap the two W25Q16 bootloaders merely because the base-board wiring is the same.</p> <p>For the first migration from the ordinary <code>wiscore_rak4631_board</code> bootloader to <code>wiscore_rak4631_board_rak15001_slot_c</code>, use Nordic serial DFU or a compatible BLE DFU client with the exact slot-C OTAFIX combined bootloader + SoftDevice DFU package (or use SWD), then reinstall the slot-C MeshCore application. The release filename has this form:</p> <pre><code>wiscore_rak4631_board_rak15001_slot_c_bootloader-&lt;OTAFIX-version&gt;_s140_6.1.1.zip\n</code></pre> <p>Do not copy the slot-C bootloader-update UF2 onto the stock UF2 drive. The stock loader is bound to <code>DEVICE_NAME=4631_DFU</code>, while the slot-C image is bound to <code>4631_15001C_DFU</code>, so that UF2 is intentionally rejected. After the one-time DFU/SWD migration, later canonical slot-C bootloader UF2 files work normally. The combined OTAFIX package above is not the MeshCore application's Serial DFU <code>.zip</code>; an application package does not migrate the bootloader.</p> <p>After installing the repeater application, check:</p> <pre><code>get bootloader.ver\nota self\nota status\nota qspi\n</code></pre> <p>A ready RAK15001 target reports all of the following:</p> <pre><code>QSPI store:2048K\nbootloader: QSPI apply OK\nbl:QSPI\nQSPI jedec=C84015 size=2048K sr1=00 stage=jedec\n</code></pre> <p>A ready external W25Q16 target instead identifies the Winbond part:</p> <pre><code>QSPI store:2048K\nbootloader: QSPI apply OK\nbl:QSPI\nQSPI jedec=EF4015 size=2048K sr1=00 stage=jedec\n</code></pre> <p>Other supported boards can report a capacity different from 2048K; the RAK15001 and W25Q16 targets must report exactly 2048K and their respective exact JEDEC IDs. <code>QSPI store:ERR 0K</code>, <code>NO QSPI</code>, or <code>bl:NO-QSPI</code> means the flash wiring, flash power, chip-select pull-up, application, or bootloader does not match. Do not start an install in that state.</p> <p><code>ota qspi</code> is a read-only diagnostic probe available on QSPI OTA builds. It reports the exact JEDEC ID, status-register byte, last store stage, and the first latched storage error. Run it after an immediate <code>storage error</code> before starting another pull; later capacity probes preserve that failure detail.</p>"},{"location":"ota_nrf52_qspi/#capacity-and-package-types","title":"Capacity and package types","text":"<p>The store reads the JEDEC capacity at runtime and accepts supported 1 MiB through 16 MiB devices using 24-bit addressing. QSPI capacity is not the final firmware limit. The reconstructed application, including its 56-byte <code>EndF</code> trailer, must fit its build's linked application region:</p> SoftDevice layout Application region Maximum image S140 v7, boot-update-capable XIAO module <code>0x27000..0xE0000</code> <code>0xB9000</code> (757,760 bytes) S140 v7, app base <code>0x27000</code> <code>0x27000..0xED000</code> <code>0xC6000</code> (811,008 bytes) S140 v6, app base <code>0x26000</code> <code>0x26000..0xED000</code> <code>0xC7000</code> (815,104 bytes) <p>The XIAO limit is deliberately 52 KiB smaller. Its linker and post-link record cap every ordinary application at <code>0xE0000</code>; OTAFIX reserves <code>0xE0000..0xEA000</code> as a 40 KiB self-update scratch bank, with the remaining gap left unused before InternalFS. Full and delta application packages for these targets derive their effective application end from that <code>0xE0000</code> record and are rejected if their reconstructed image or detools geometry crosses it.</p> <p>A full package needs only the new raw <code>firmware.hex</code> or non-merged application image. An in-place delta still needs the exact image currently running. The automation uses a conservative <code>0xC6000</code> detools workspace for external nRF52 staging so one package setting is safe for both layouts.</p> <p>For online automation, QSPI is detected from <code>ota self</code> or <code>ota status</code>. For offline preparation, identify it explicitly:</p> <pre><code>./tools/lora_ota/lora_ota.sh ./release.zip target-name \\\n  --prepare-only \\\n  --platform nrf52 \\\n  --nrf-qspi \\\n  --target-id 12345678 \\\n  --target-hw Xiao_nrf52\n</code></pre> <p>Use the real target ID and hardware identity from the destination. A ready full <code>.mota</code> normally uses that target ID for discovery and routing. An operator can deliberately override the routing target for a role change, so <code>target_id</code> is not an apply-time safety assertion; the destination still enforces the package's hardware identity before approval.</p>"},{"location":"ota_nrf52_qspi/#explicit-xiao-bootloader-updates-over-lora","title":"Explicit XIAO bootloader updates over LoRa","text":"<p>This section documents the deployed XIAO raw-QSPI layout. Curated nRF52840 targets without external staging use a separate internal-flash layout with the same explicit operator safety model; see nRF52 bootloader updates over LoRa.</p> <p>Bootloader delivery is available only when all of these are already true:</p> <ul> <li>the application is an <code>OTA_QSPI_BOOTLOADER_UPDATE</code> XIAO-module repeater build   linked below <code>0xE0000</code>;</li> <li><code>ota bootloader</code> shows a CRC-valid installed <code>XIAO_DFU</code> embedded identity for   board ID <code>28860044</code> (base) or <code>28860045</code> (Sense);</li> <li>the installed OTAFIX marker reports ABI 3 or newer and both QSPI (<code>0x04</code>) and   boot-update (<code>0x08</code>) capability bits;</li> <li>the package is the exact signed v3/40-KiB/1-KiB-block profile for that board,   and its signer is already in <code>ota key</code>'s trusted allowlist.</li> </ul> <p>This is not part of normal automation. Bootloader catalog rows are labelled <code>bootloader</code>; even a capable node never autofetches or autoinstalls them, and ordinary <code>ota install</code> rejects them in every application backend. The <code>tools/lora_ota</code> deployment runner also refuses v3 packages. Fetch and arm one only with the explicit flow:</p> <pre><code>ota ls\nota pull &lt;MID8&gt; flash\n# wait for ota status to report the same bootloader download as ready\nota bootloader\n# copy the exact mid= and hash= values printed above\nota bootloader install &lt;MID8&gt; &lt;HASH16&gt;\n</code></pre> <p>The pull command is only transport intent; it does not authorize an install. The final command must reproduce both the complete staged manifest ID and the first eight bytes of its signed image hash. Before approval the application again checks package/root/payload/image hashes, Ed25519 signature and trusted allowlist, exact signed <code>XIAO_BL_...</code> ID, installed and incoming embedded   manifest/CRC/name/board identity, vector table, ABI-3 QSPI+boot-update marker,   and the adjacent CRC-covered <code>BLM2</code>/<code>SOFT</code> continuity extension at the exact   final-image offset <code>0x9FB4</code>. The embedded   boot version must equal the signed outer package version, the SoftDevice   family/FWID/application base/layout ABI must match the running platform, and   a successor to installed BLM2 must be strictly newer. Low-byte-zero and   all-ones versions are invalid. Remote rollback is refused; use local DFU/SWD.</p> <p>After the reply drains, GPREGRET <code>0x6B</code> and GPREGRET2 <code>0x51</code> enter the special OTAFIX path. <code>APRV</code> carries the app's signature/allowlist and explicit operator authorization decision. OTAFIX independently rechecks the strict structure, identity/capabilities, vectors, payload SHA, embedded CRC, and copy hashes before using the reserved scratch bank to replace its own <code>0xF4000..0xFE000</code> region. The running application remains preserved; a rejected candidate returns to it unchanged. Post-reboot <code>ota status</code> reports bootloader-update diagnostics as <code>blup:C0</code> to <code>blup:CF</code> (<code>blup:C8</code> is success), separately from ordinary application <code>blrc</code>.</p> <p>This feature cannot update a stock or old bootloader that lacks the capability marker: perform the first exact-board combined bootloader+SoftDevice migration over USB/BLE DFU or SWD. Do not attempt to bootstrap it with a v3 package.</p>"},{"location":"ota_nrf52_qspi/#storage-ownership-and-recovery","title":"Storage ownership and recovery","text":"<p>The QSPI store is raw, not a file inside LittleFS. It owns the flash from offset zero, erases 4 KiB sectors as blocks arrive, writes data before progress metadata, and verifies every programmed page. A previously interrupted download is reopened only when its header and trailer are valid; every claimed block is re-hashed before it is trusted. Between a probe, transfer operation, or checkpoint, firmware puts the NOR into deep power-down, deactivates the nRF QSPI peripheral, and turns off a board-provided flash power-enable pin. The next operation powers the chip, shifts the NOR's <code>0xAB</code> wake command over GPIO, then activates the nRF QSPI peripheral and identifies the flash. Waking it before peripheral activation is required because a flash in deep power-down ignores the activation traffic itself. Merely running <code>ota self</code> therefore does not leave QSPI drawing active-mode current or prevent the following operation from reactivating it.</p> <p>Installing a QSPI repeater build over a former companion build therefore repurposes the external flash and destroys companion filesystem data as OTA sectors are written. Back up anything important first. Returning to a companion build may require formatting its external data store.</p> <p>Before changing internal application flash, the application verifies package integrity, hardware identity, signature policy, and bootloader capabilities. The target ID selects discovery/fetch routing and can be deliberately overridden; it is not a second hardware gate. The bootloader then verifies a full payload before its first application erase. For a delta, the application rejects invalid detools geometry before approval and the bootloader independently repeats the base and geometry checks before applying it. It clears the one-shot approval marker before invalidating the running image. If power is lost after application writes begin, the bank remains invalid and OTAFIX enters USB/BLE recovery rather than booting a partial image.</p> <p>See Easy firmware updates over LoRa for the transfer commands and the OTA protocol for the container and handoff details.</p>"},{"location":"ota_protocol/","title":"MeshCore OTA - <code>.mota</code> container &amp; LoRa protocol","text":"<p>This is the single source of truth for MeshCore's over-the-air firmware update system (\"mOTA\"). It is written for developers who want to implement an interoperable peer (server, fetcher, relay, or host tool) in another codebase or project. Everything below is implemented in this repository and covered by host, simulation, build, or hardware tests as noted in the relevant section. Hardware qualification is target- and chain-specific; do not infer it from implementation alone. Where a section names a source file, that file is the authoritative reference for byte-level details.</p> <p>Just want to update your node? See the plain-language OTA user guide - this document is the technical/wire specification.</p> <p>Design goals</p> <ul> <li>Distribute firmware over LoRa as a self-verifying, resumable, single-source block transfer that   survives reboots and never auto-applies without explicit consent.</li> <li>Trustless mesh relay: repeaters may forward packets while the source alone serves firmware data;   integrity is content-addressed   against a signed merkle root, so a relay need not be trusted and never needs the signing keys.</li> <li>Primary while transferring: periodic discovery stays at background priority, but manifest, block,   data, and proof packets for an active fetch use primary queue priority at every relay hop.</li> <li>Portable: the engine (<code>src/helpers/ota/OtaManager</code>) is Arduino/radio/crypto-free and host-testable,   so the same logic drives a device, a simulation, or a third-party implementation.</li> </ul> <p>Source map (all under <code>src/helpers/ota/</code> unless noted)</p> Concern File Constants, enums, flags <code>OtaFormat.h</code> Container/manifest parse <code>MotaContainer.{h,cpp}</code> Merkle tree + proofs <code>MerkleTree.{h,cpp}</code> EndF self-identity <code>FirmwareInfo.{h,cpp}</code> Wire message codec <code>OtaProtocol.{h,cpp}</code> Session engine (serve+fetch+discovery) <code>OtaManager.{h,cpp}</code> Multi-mota / folder relay <code>OtaSource.h</code>, <code>MotaSourceSerial.{h,cpp}</code>, <code>MotaSeederProto.h</code> Staging stores <code>OtaStore.h</code>, <code>OtaStoreFlashNrf52.*</code>, <code>OtaStoreFlashEsp32.*</code> Apply <code>OtaApply.*</code>, bootloader <code>Adafruit_nRF52_Bootloader_OTAFIX</code> Device glue (CLI/context) <code>OtaCli.cpp</code>, <code>OtaContext.h</code> Host tooling <code>motatool</code> (standalone Rust CLI: build/verify/inspect/serve); <code>tools/mota/</code> (Python reference lib <code>motalib.py</code> + build/test glue)"},{"location":"ota_protocol/#1-conventions","title":"1. Conventions","text":"<ul> <li>Endianness: all multi-byte integers are little-endian unless stated.</li> <li>Hashes (multihash): the hash family is declared once per manifest via <code>hash_algo</code> =   <code>0x12</code> = SHA-256 (the multihash code for sha2-256).   Truncations used:</li> <li><code>sha2-256:4</code> - first 4 bytes of the SHA-256 digest. Merkle leaves, internal nodes, root, proofs,     <code>manifest_id</code>, and the discovery <code>set_digest</code>.</li> <li><code>sha2-256:8</code> - first 8 bytes. Base-firmware identity (<code>base_hash</code>, <code>EndF.body_hash</code>).</li> <li><code>sha2-256:32</code> - full digest. The image security anchor (<code>image_hash</code>).   Digests are stored bare (just the truncated bytes); the family is implied by <code>hash_algo</code>.</li> <li>Signatures: Ed25519 (RFC 8032), 64-byte detached signature, 32-byte public key.</li> </ul> <p>Reference constants (<code>OtaFormat.h</code>):</p> Name Value ASCII / note Container <code>MAGIC</code> <code>6D 4F 54 41</code> <code>mOTA</code> Container <code>TRAILER</code> <code>76 6B 34 39 36</code> <code>vk496</code> <code>EndF</code> marker <code>45 6E 64 46</code> <code>EndF</code> <code>hash_algo</code> (sha2-256) <code>0x12</code> multihash code application <code>format_ver</code> <code>0x02</code> ordinary full/delta application package bootloader <code>format_ver</code> <code>0x03</code> privileged exact-identity nRF52 bootloader package only <code>approval</code> = not approved <code>FF FF FF FF</code> erased NOR word <code>approval</code> = approved <code>41 50 52 56</code> <code>APRV</code> <code>MFLAG_FULL</code> <code>0x01</code> flags bit0 <code>MFLAG_SIGNED</code> <code>0x02</code> flags bit1 <code>MFLAG_BOOTLOADER</code> <code>0x04</code> flags bit2; valid only in the exact v3 bootloader profile <code>CODEC_FULL</code> / <code>_SEQUENTIAL</code> / <code>_INPLACE</code> <code>0</code> / <code>1</code> / <code>2</code> Section 5 <code>PAYLOAD_TYPE_OTA</code> <code>0x0C</code> MeshCore packet type (<code>src/Packet.h</code>) <code>MAX_PACKET_PAYLOAD</code> <code>184</code> usable bytes per packet (<code>src/MeshCore.h</code>) Default application block size <code>2048</code> <code>block_size_log2 = 0x0B</code>; deployed 1 KiB application packages remain accepted Bootloader-package block size <code>1024</code> fixed <code>block_size_log2 = 0x0A</code> for format 3 OTA discovery TX priority <code>250</code> background (<code>OTA_TX_PRIORITY</code>, <code>src/Mesh.h</code>) OTA active-transfer TX priority <code>0</code> primary (<code>OTA_TRANSFER_TX_PRIORITY</code>, <code>src/Mesh.h</code>) <p>Current application firmware publishes its receive/reassembly ceiling as the compact <code>maxblk:2048</code> field near the front of both <code>ota status</code> and <code>ota self</code>. Keeping the field ahead of variable diagnostics ensures it survives the 160-byte remote-admin reply limit. Host updaters must treat an absent field as the deployed legacy capability (<code>1024</code>), reject a ready package whose manifest block size exceeds that capability, and use the reported size when turning a raw firmware image into a new application package. This capability does not change the format-3 bootloader package's fixed 1 KiB geometry.</p>"},{"location":"ota_protocol/#2-firmware-image-the-endf-trailer","title":"2. Firmware image &amp; the <code>EndF</code> trailer","text":"<p>Every OTA-capable build appends a fixed 56-byte <code>EndF</code> trailer to its flashed image so a running node can discover its own size and self-describing identity on any MCU (no linker symbols needed). Every field is always present at a constant offset. Implemented by <code>FirmwareInfo.cpp</code>; appended at build time by <code>tools/mota/pio_endf.py</code> (post-build hook).</p> <pre><code>flashed image = BODY (image bytes) || EndF trailer\nEndF trailer (fixed 56 bytes):\n  off 0   4   \"EndF\"        45 6E 64 46\n  off 4   4   body_len      uint32 LE - length of BODY (excludes the whole trailer)\n  off 8   8   body_hash     sha2-256:8 of BODY\n  off 16  4   fw_version    uint32 LE, packed MAJOR&lt;&lt;24|MINOR&lt;&lt;16|PATCH&lt;&lt;8|pre  (0 = unknown)\n  off 20  4   target_id     uint32 LE - sha2-256:4(pio_env): hardware + role + partition (fetch routing)\n  off 24  32  hw_id         NUL-padded ASCII hardware tag (brick-safety), e.g. \"RAK4631\" (\"\" = unknown)\n</code></pre> <ul> <li>Self-describing identity. <code>pio_endf.py</code> uses <code>build.sh</code>'s <code>MOTA_TARGET_ID</code> when present (required for   virtual LoRa-OTA build names), otherwise it computes <code>target_id</code> from the PlatformIO env name. It reads   <code>hw_id</code> from <code>MOTA_HW_ID</code> and <code>fw_version</code>   from <code>FIRMWARE_VERSION</code>. The device reads them back (<code>ota_self_firmware()</code>), so a node's advertised   identity is correct regardless of how it was built - and the packaging tool reads them straight from a raw   <code>.bin</code> (no <code>--target-env</code>/<code>--fw-version</code> flags, no reliance on filenames; Section 9, Section 13). A dev build with no   dotted version simply carries <code>fw_version = 0</code> / empty <code>hw_id</code> (= unknown) - still a full 56-byte trailer.</li> <li>Size discovery: scan flash from the partition top downward for the <code>EndF</code> marker; the byte before it   is the last BODY byte (the trailer is always 56 bytes). See <code>ota_self_firmware()</code>.</li> <li>Delta base matching: a node's <code>body_hash</code> is read directly from its own <code>EndF</code>; a delta's <code>base_hash</code>   (Section 5) must equal it. <code>body_hash</code> is over BODY only.</li> <li>No circularity: <code>EndF</code> hashes only the BODY, never itself.</li> </ul> <p>The \"reconstructed image\" referenced by the manifest is the full <code>BODY || EndF</code> (what gets flashed).</p>"},{"location":"ota_protocol/#esp32-application-slot-profiles","title":"ESP32 application-slot profiles","text":"<p>ESP32 Companion firmware is exempt from the portable-slot limit. When an exact Full recipe exists, one expanded-partition image supplies USB, BLE, WiFi, source-only LoRa OTA, and persistent USB logging instead of separate transport artifacts. A small set of high-capacity, non-PSRAM classic ESP32 companions use 100 contacts, 8 group channels, and a 16-frame offline queue in that combined image to preserve internal-DRAM headroom. MQTT observers and ESP-NOW bridges always use FULL builds because fitting them into the legacy slot would require removing CLI and role features. Except for those FULL roles and the ESP32-C6 case below, non-companion ESP32 artifacts, including room, sensor, and repeater roles, must fit the legacy slot from <code>0x10000</code> up to <code>0x150000</code> (<code>0x140000</code>, 1,310,720 bytes), including the 56-byte <code>EndF</code> trailer. The build checks both that limit and the target's actual app partition. The ESP32-C6 <code>no_external_sensors</code> OTA siblings are the narrow exception: the Arduino 3.x WiFi runtime cannot fit that cross-family ceiling, so those images retain their established target-specific 1920 KiB or larger A/B app layout and are checked against the actual app partition. For standalone ESP32 and nRF52 repeaters that need a lean staging profile, <code>build.sh</code> also exposes an explicit <code>*_lora_ota_no_external_sensors</code> artifact: the ordinary repeater remains sensor-enabled, while that sibling trims selected optional environmental/ranging drivers for LoRa distribution. SolarXiao 30S and 33S use matched external QSPI staging, so their ordinary full-sensor repeater is already install-capable and no redundant lean sibling is generated. Integrated GPS and other board-native telemetry remain enabled where the target selects the GPS-preserving lean profile. The legacy suffix describes a driver trim, not removal of the generic I2C bus. Reduced RAK3401 and RAK4631 profiles retain INA219, INA226, INA260, and INA3221 voltage/current monitors. These are retained optional-sensor-table drivers, not the only I2C consumers: SSD1306 display, supported autodiscovered RTCs, and RAK12500 GPS remain separate I2C peripherals where selected by the board recipe. The RAK3401 OTA repeater also retains RAK12500 I2C and RAK12501/L76K UART GPS support; install either GPS module in sensor slot A because slot D conflicts with the RAK13302 radio's BUSY/DIO1 lines. The plain RAK4631 OTA repeater and its Serial2 bridge retain GPS. RAK12501 uses Serial1. Its explicitly compiled Serial1 bridge therefore omits the combined GPS provider, including RAK12500, even though RAK12500 itself does not use the UART.</p> <p>The firmware-configured INA3221 address and RAK12500 address are both <code>0x42</code>, so those devices cannot share one bus at those addresses. Keep RAK12500 at <code>0x42</code>, strap INA3221 A0 to SCL for <code>0x43</code>, and use firmware built with <code>-DTELEM_INA3221_ADDRESS=0x43</code> when both are installed.</p> <p>ESP32 siblings retain the compact browser WiFi updater and use the full 254-entry neighbor table. RP2040 and STM32 targets are not offered because those platforms do not yet have a safe bootloader/apply path.</p> <p>nRF52 LoRa-OTA siblings use size optimization rather than the Adafruit platform's default <code>-Ofast</code>. This keeps the runtime software Ed25519 fallback from being expanded into tens of kilobytes of repeated curve arithmetic while retaining CC310 hardware crypto, hardware RNG mixing, telemetry history, and board-native features.</p> <p>WiFi-heavy non-companion roles are not reduced to fit the legacy application slot. <code>build.sh</code> automatically promotes every ESP32 MQTT observer and ESP-NOW bridge to the expanded FULL partition profile. These artifacts retain the complete role CLI, WebConfig where supported, display and optional sensor support, full timezone and TLS behavior, and the board's normal power-management implementation. The compact CLI is not compiled into any build. Ordinary repeater builds remain sensor-enabled; only explicitly named <code>*_lora_ota_no_external_sensors</code> siblings trim selected optional environmental/ranging drivers for LoRa distribution, and those siblings retain the complete CLI and target-declared I2C peripherals.</p> <p>MQTT observer radio and bridge preferences use verified temporary files plus a recoverable backup. A reset during a settings save restores the last committed common preference image or publishes the completed new image; it does not leave a partially written <code>/com_prefs</code> file to fail on the next boot. A truncated legacy image is rejected before any partial radio or string fields are applied, then rewritten from safe defaults.</p> <p>Option 3 in <code>build.sh</code> emits one <code>*-full-usb-wifi-ota-*</code> ESP32 artifact for each FULL-capable non-companion hardware/role that has a matching MQTT environment. It compiles USB packet logging and direct WiFi MQTT together. A <code>*-full-logging-ota-*</code> fallback is emitted only when there is no MQTT sibling; ordinary non-OTA roles compile runtime USB logging into their canonical image, so separate standard-logging artifacts are not emitted. Non-MQTT FULL twins are also skipped for covered ESP32 roles. MQTT observers and ESP-NOW bridges are emitted only with expanded FULL partitions. Menu option 8, or <code>build-full-esp32-firmwares</code>, builds the unified profiles plus necessary fallbacks. Menu option 9, or <code>build-full-esp32-logging-firmwares</code>, builds only those fallbacks. FULL builds restore WebConfig, display support, optional external sensors, and the full role CLI and feature set, full ElegantOTA where that target declares the required library, and LoRa OTA for every included role, including room servers, sensors, observers, and bridges. They use expanded A/B partition tables: 1984 KiB application slots on 4 MiB boards and the framework's larger dual-OTA tables on 8 MiB and 16 MiB boards. Explicit <code>*_lora_ota_no_external_sensors</code> targets are not duplicated; their ordinary repeater build is the FULL, sensor-enabled counterpart. The <code>*-full-usb-wifi-ota-*</code> profile enables USB packet logging and MQTT, with a persistent <code>logging.output</code> selector; its verbose internal debug remains off. The fallback <code>*-full-logging-ota-*</code> profile enables USB debug and packet logging and has no MQTT target. Install a matching <code>*-full-usb-wifi-ota-*-merged.bin</code> or <code>*-full-logging-ota-*-merged.bin</code> over USB once to write the expanded partition table. After that, its matching non-merged FULL application image can be installed through USB, WiFi OTA, or LoRa OTA. Do not install a non-merged FULL image onto a node that still has its old partition table.</p> <p>Implementer note: the bootloader (and any non-Arduino consumer) MUST locate the body extent by scanning for <code>EndF</code>, never by trusting a stored size - see the bootloader contract in Section 12.</p>"},{"location":"ota_protocol/#3-the-mota-container","title":"3. The <code>.mota</code> container","text":"<p>The distributed form (host-built, wire-transferred). Parsed by <code>mota_parse()</code> in <code>MotaContainer.cpp</code>.</p> <pre><code>off            size   field\n0              4      MAGIC = 6D 4F 54 41\n4              4      MOTA_TOTAL_SIZE  uint32 LE - total container bytes (incl. manifest, leaves[],\n                                       payload, trailer). Lets a node pre-reserve staging and compute\n                                       write_start = staging_region_end - MOTA_TOTAL_SIZE.\n8              M      MANIFEST         (Section 4; M = 197 fixed + leaves[], 4*BC; no length field - BC from payload_size)\n8 + M          P      PAYLOAD          (payload_size bytes; delta or full image)\n8 + M + P      5      TRAILER = 76 6B 34 39 36\n</code></pre> <p><code>MOTA_TOTAL_SIZE = 4 + 4 + M + P + 5</code>. The manifest <code>M</code> includes <code>leaves[]</code>; the manifest-minus-leaves prefix (<code>mfl</code>, sent over the wire as <code>OTA_MANIFEST</code>) is <code>[8, leaves_off)</code>.</p> <p>Staged (in-flash) form. Written bottom-aligned so <code>TRAILER</code> ends at <code>staging_region_end</code>. Identical bytes, except the device mutates two regions in place (both NOR-safe, no re-erase): the <code>leaves[]</code> slots (filled as blocks arrive - Section 7) and the 4-byte <code>approval</code> field (on owner consent - Section 4.2). Everything else is immutable.</p>"},{"location":"ota_protocol/#4-the-manifest","title":"4. The manifest","text":"<p>Fixed layout. Every field sits at a constant offset and is always present - <code>base_hash</code>, <code>signer_pubkey</code> and <code>signature</code> are zero-filled when not applicable (a full image / an unsigned container). Only <code>leaves[]</code> is variable (one 4-byte hash per block). So the manifest-minus-leaves (<code>mfl</code>) is always 197 bytes and the parser is plain offset reads - no conditionals. Parsed by <code>mota_parse_manifest()</code>.</p> <pre><code>off  size   field            notes\n0    1      format_ver       = 0x02 application, or 0x03 privileged bootloader package\n1    1      flags            bit0 FULL; bit1 SIGNED; bit2 BOOTLOADER; bits3-7 reserved 0\n2    1      hash_algo        0x12 = sha2-256\n3    4      target_id        device/arch/role discriminator (Section 9)\n7    4      fw_version       MAJOR&lt;&lt;24 | MINOR&lt;&lt;16 | PATCH&lt;&lt;8 | pre   (comparable uint32)\n11   4      image_size       size of the reconstructed image (BODY||EndF)\n15   4      payload_size     PAYLOAD bytes in this container\n19   1      block_size_log2  e.g. 0x0B = 2048 (new application default); 0x0A = deployed 1024\n20   4      merkle_root      sha2-256:4 over PAYLOAD blocks (Section 6) - also the manifest_id\n24   32     image_hash       sha2-256:32 of the reconstructed image - SECURITY anchor\n56   1      codec_id         0=full/raw, 1=detools-sequential, 2=detools-in-place\n57   32     hw_id            NUL-padded ASCII hardware tag (e.g. \"RAK4631\"); same tag =&gt; bootable-compatible.\n                             SIGNED. Applier refuses a mismatch (brick-safety); empty on either side = skip.\n89   8      base_hash        sha2-256:8 of the BASE image's BODY (== that build's EndF.body_hash). 0 if FULL.\n97   32     signer_pubkey    Ed25519 public key. 0 if not SIGNED.\n129  64     signature        Ed25519 over manifest[0, 129). 0 if not SIGNED.\n193  4      approval         FF FF FF FF = not approved; 41 50 52 56 (\"APRV\") = approved\n--- end of manifest-minus-leaves: mfl = 197 (constant); leaves_off = 8 + 197 = 205 in the container ---\n197  4*BC   leaves[]         BC = ceil(payload_size / 2^block_size_log2). sha2-256:4 each (the only variable field)\n</code></pre> <p>The signature always covers <code>manifest[0, 129)</code> (the head + <code>base_hash</code> + <code>signer_pubkey</code>). <code>approval</code> is outside the signed region so it can be flipped in place on consent without breaking the signature.</p> <p>Manifest-minus-leaves size (<code>mfl</code>) is a constant 197 bytes for every container (full or delta, signed or unsigned). At 197 bytes the manifest exceeds one packet, so <code>OTA_MANIFEST</code> is always sent multi-fragment (Section 8.4, 2 fragments) and reassembled by the fetcher.</p> <p>The two versions are deliberately disjoint. Version 2 accepts application packages only and rejects the BOOTLOADER bit. Version 3 accepts only flags exactly <code>FULL|SIGNED|BOOTLOADER</code>; a non-bootloader v3 package is invalid. Consequently, deployed v2-only application parsers reject a bootloader package before they can mistake its raw 40 KiB payload for an application image.</p>"},{"location":"ota_protocol/#41-signed-region","title":"4.1 Signed region","text":"<p><code>signature</code> covers manifest bytes <code>[0, 129)</code> - the head + <code>base_hash</code> + <code>signer_pubkey</code>. It does not cover <code>approval</code> or <code>leaves[]</code>:</p> <ul> <li><code>leaves[]</code> are verified against the signed <code>merkle_root</code> (Section 6), so they need no separate signature.</li> <li><code>approval</code> is device-local consent (Section 4.2), deliberately outside the signature.</li> </ul>"},{"location":"ota_protocol/#42-the-approval-field","title":"4.2 The <code>approval</code> field","text":"<ul> <li>Distributed and forced on ingest to <code>FF FF FF FF</code> (a peer can never pre-approve).</li> <li>The local owner's <code>ota applydelta</code> writes <code>41 50 52 56</code> (<code>\"APRV\"</code>) - a single NOR-safe write (only clears   bits from the erased word). Any partial/other value reads as not-approved (fail-safe).</li> <li>Bound to this image (lives in this <code>.mota</code>'s manifest, re-erased when a new <code>.mota</code> is staged).</li> <li>A consent marker, not a security primitive. Authenticity = <code>signature</code> + <code>image_hash</code> + <code>hw_id</code>.</li> </ul>"},{"location":"ota_protocol/#43-privileged-nrf52-bootloader-package-profile","title":"4.3 Privileged nRF52 bootloader package profile","text":"<p>A v3 bootloader package has a deliberately narrow, non-extensible profile:</p> <ul> <li>flags exactly <code>FULL|SIGNED|BOOTLOADER</code>, <code>CODEC_FULL</code>, nonzero <code>fw_version</code>, zero <code>base_hash</code>;</li> <li>a raw payload and <code>image_size</code> of exactly <code>0xA000</code> (40 KiB), split into exactly forty 1024-byte blocks;</li> <li>a target derived from the installed CRC-valid embedded manifest identity. Deployed XIAO identities keep   raw board IDs <code>0x28860044</code>/<code>0x28860045</code>; generic identities use LE32(SHA-256(canonical padded hw32));</li> <li>signed <code>hw_id</code> exactly <code>XIAO_BL_28860044</code>/<code>XIAO_BL_28860045</code> for deployed XIAO, or the zero-padded   32-byte <code>NRF_BL_&lt;BOARD_ID&gt;_&lt;DEVICE_NAME&gt;</code> for a generic target;</li> <li>a sane nRF52840 vector table, exactly one CRC-valid embedded manifest v1 with the exact board/name pair,   followed by the required CRC-covered <code>BLM2</code>/<code>SOFT</code> continuity extension (embedded boot version,   SoftDevice family/FWID, application base, and layout ABI), with that complete 76-byte envelope at the   canonical final-image offset <code>0x9FB4</code>,   and exactly one <code>MOTABLDR</code> marker advertising ABI &gt;= 3, both application codecs (<code>FULL|INPLACE</code>, mask   <code>0x0005</code>), boot-update continuity, and the exact storage flags for the application layout (<code>0x09</code>   MeshTower V2 SD, <code>0x0E</code> XIAO QSPI, or <code>0x0A</code> shared internal staging).</li> </ul> <p>The incoming embedded identity must exactly match the installed CRC-valid bootloader identity. Both scans consider every aligned structurally valid candidate so magic bytes in a literal pool cannot shadow the real manifest. Duplicate accounting counts each CRC-valid 44-byte base record before interpreting adjacent continuity metadata, so a corrupt or half-present <code>BLM2</code> extension cannot hide a second identity; after exactly one base record is selected, malformed claimed continuity fails closed. A package must be signed by a key already in the device's trusted allowlist; unlike ordinary application packages, there is no unsigned manual-install exception. The signed outer <code>fw_version</code> must equal the embedded boot version. Qualified internal/QSPI targets may bootstrap a CRC-valid legacy-v1 installed bootloader once; MeshTower SD instead requires local BLM2 provisioning because it has no safe legacy media handoff. After bootstrap every remote successor must be strictly newer and match the live SoftDevice/application layout. Low-byte zero and all-ones boot versions are invalid. Remote rollback has no override and must use local DFU/SWD.</p>"},{"location":"ota_protocol/#5-payload-codecs-delta-base","title":"5. Payload, codecs &amp; delta base","text":"<p><code>PAYLOAD</code> is either the full reconstructed image (<code>FULL</code>) or a delta (<code>!FULL</code>).</p> <code>codec_id</code> Meaning Used by 0 full / raw PAYLOAD = reconstructed image (<code>BODY||EndF</code>). ESP32 A/B or an external SD/QSPI nRF52 target. 1 detools sequential random read of base + sequential write of result -&gt; ESP32 A-&gt;B inactive slot. 2 detools in-place bounded scratch; rewrites the app region in place -&gt; nRF52 single-slot. <p>For deltas, <code>base_hash</code> = the base build's <code>EndF.body_hash</code> (sha2-256:8 of its BODY). A node applies a delta only if <code>base_hash</code> matches its own <code>EndF.body_hash</code>. After applying, the result MUST hash (sha2-256:32) to <code>image_hash</code> before it is booted - the hard security gate.</p> <p>A fetcher only requests firmware it can apply. Each node declares the codec(s) it can apply (<code>set_apply_codec</code>/<code>set_apply_codec2</code>): ESP32 accepts <code>full</code> + <code>sequential</code> (+ <code>in-place</code>). Internal-staging nRF52 targets accept only <code>in-place</code> because internal flash cannot hold a second full application image. Matched SD and raw-QSPI nRF52 targets accept <code>full</code> + <code>in-place</code> because external media holds the container. A <code>.mota</code> with an unsupported codec is rejected at discovery time, before any blocks are requested. A manual pull to an external folder may accept other codecs because that path captures bytes and never installs them.</p> <p>Compression is internal to the detools patch and must be supported by the applier. Patches are produced by detools 0.53.0 (<code>tools/mota</code> -&gt; <code>detools.create_patch</code>) and decoded on-device by detools' embeddable C decoder, vendored verbatim at <code>src/helpers/ota/detools/</code> (see its <code>README.meshcore.txt</code>). That build enables only the self-contained <code>NONE</code> + <code>CRLE</code> compressions (no malloc/liblzma/heatshrink), so MeshCore deltas use <code>--compression crle</code>. Do not reimplement the codec - use the vendored decoder.</p>"},{"location":"ota_protocol/#6-merkle-tree-sha2-2564","title":"6. Merkle tree (sha2-256:4)","text":"<p>Verifies each PAYLOAD block against the signed <code>merkle_root</code> before the whole payload exists, so corruption/forgery is localized to a block. Implemented in <code>MerkleTree.cpp</code>.</p> <ul> <li>Blocks: PAYLOAD splits into <code>BC = ceil(payload_size / B)</code> blocks, <code>B = 2^block_size_log2</code> (new   application default 2048; deployed 1024-byte application packages remain valid). The last block is its   real length (no zero padding). Format-3 bootloader packages remain fixed at 1024 bytes.</li> <li>Leaf: <code>leaves[i] = sha2-256:4( block_i_bytes )</code>.</li> <li>Internal node: <code>node = sha2-256:4( left || right )</code> (4+4 input bytes).</li> <li>Odd level: an odd count promotes the last node unchanged to the next level (no duplication).</li> <li>Root: reduce until one node remains. <code>BC == 1</code> -&gt; root = <code>leaves[0]</code>. <code>BC == 0</code> is invalid.</li> </ul>"},{"location":"ota_protocol/#61-proofs","title":"6.1 Proofs","text":"<p>A proof for block <code>i</code> is the ordered list of sibling digests from leaf to root. Promoted levels contribute no element. Verification (needs <code>BC</code> to know the tree shape):</p> <pre><code>h = leaf_i ; idx = i ; n = BC ; p = 0\nwhile n &gt; 1:\n    if (n is odd) and (idx == n-1):        # this node was promoted\n        pass\n    else:\n        sib, side = proof[p] ; p += 1\n        h = sha2-256:4( sib || h ) if side==left else sha2-256:4( h || sib )\n    idx //= 2 ; n = (n + 1) // 2\naccept iff h == merkle_root and p == len(proof)\n</code></pre> <p>Over LoRa, <code>leaves[]</code> are omitted from the manifest transfer. A serving node computes a block's proof on demand from its stored <code>leaves[]</code> and normally sends <code>OTA_PROOF</code> immediately after that block's paced <code>OTA_DATA</code>. <code>OTA_REQ_PROOF</code> remains the fallback for an older source or a lost proactive proof. The fetcher fills its own <code>leaves[i]</code> as each verified block lands.</p>"},{"location":"ota_protocol/#7-block-availability-staging-resume","title":"7. Block availability, staging &amp; resume","text":"<p>There is no separate availability structure. Block <code>i</code> is present &lt;=&gt; <code>leaves[i]</code> is non-erased (<code>!= FF FF FF FF</code>). Because <code>leaves[]</code> live in the staged flash region, availability survives reboot.</p> <p>Commit order per block (crash-safe): (1) verify proof, (2) write block payload to its offset, (3) write <code>leaves[i]</code> last. A power loss before step 3 leaves the slot erased -&gt; the block is simply re-fetched (idempotent). On boot a node rebuilds an in-RAM present-bitmap by scanning <code>leaves[]</code>.</p> <p>Resume (<code>OtaManager::resumeStaged</code> + <code>OtaStore::checkpoint</code>/<code>reopen</code>): an interrupted fetch resumes from the staged container after a reboot - re-parse the stored manifest, recompute geometry, count present blocks, continue fetching the holes (or jump straight to COMPLETE). The checkpoint cadence (persist progress every N committed blocks) is runtime-tunable (<code>ota config checkpoint &lt;N&gt;</code>, 0 = only finalized containers resume). Boot-time adoption is an automatic fetch decision: current <code>autofetch</code> must be enabled, the stored target must equal the node target, policy <code>signed</code> requires the signed bit, and an enabled running-version floor requires a strictly newer manifest. An explicit MID pull may deliberately resume an older or unsigned package and keeps target <code>0</code> as a MID-only wildcard. Stores keep <code>leaves[]</code> in RAM until flush and never auto-GC, preserving resumable progress. The debug/operator equivalent is <code>ota dev resume &lt;MID8&gt;</code>; after a reboot the MID is mandatory, while a no-argument form may only reuse a still-active session MID. It never uses the <code>nullptr</code> automatic-adoption path, so a malformed MID or no active MID fails closed.</p> <p>Flash-store note (RX-safe writes): a flash page-erase halts the CPU (~85 ms on nRF52) and starves LoRa RX, so the flash stores (<code>OtaStoreFlashNrf52</code>/<code>OtaStoreFlashEsp32</code>) coalesce writes to the erase unit (4 KB page / sector) and commit each once off the per-packet path - RAM stays O(one page), not O(image). A small delta that fits page 0 does zero flash I/O until COMPLETE.</p>"},{"location":"ota_protocol/#8-lora-ota-protocol","title":"8. LoRa OTA protocol","text":"<p>Carried in MeshCore packets with <code>PAYLOAD_TYPE_OTA = 0x0C</code>. Every OTA packet payload is:</p> <pre><code>[0]    ota_msg_type      (OtaMsgType, OtaFormat.h)\n[1..]  body              (fixed per type; encode/decode in OtaProtocol.cpp)\n</code></pre> <p>Message types:</p> <code>ota_msg_type</code> val routing purpose <code>OTA_ADV</code> 0x01 discovery tiny per-node beacon (discovery tier 1) <code>OTA_QUERY</code> 0x02 discovery ask a source for its catalog (discovery tier 2) <code>OTA_HAVE</code> 0x03 discovery the catalog reply (fragmented, digest-tagged) <code>OTA_GET_MANIFEST</code> 0x04 transfer request a manifest's fragments (<code>want_mask</code>) by <code>manifest_id</code> <code>OTA_MANIFEST</code> 0x05 transfer the manifest-minus-leaves, fragmented <code>OTA_REQ</code> 0x06 transfer request fragments from an adaptive flight of 1-4 blocks (<code>want_mask</code> per block) <code>OTA_DATA</code> 0x07 transfer one self-describing fragment of a block's data <code>OTA_REQ_PROOF</code> 0x08 transfer request/re-request a missing proof <code>OTA_PROOF</code> 0x09 transfer the merkle proof for one block <code>OTA_GET_LEAVES</code> 0x0A transfer request the target's <code>leaves[]</code> fragments (<code>want_mask</code>) - warm-start only <code>OTA_LEAVES</code> 0x0B transfer a fragment of the <code>leaves[]</code> array (for host-side seed leaf-diff) <ul> <li><code>manifest_id</code> = the manifest's <code>merkle_root</code> (4 bytes) - a compact content id present in every   transfer message, so a multi-mota server dispatches each request to the right image.</li> <li>Priority: <code>OTA_ADV</code>, <code>OTA_QUERY</code>, and <code>OTA_HAVE</code> enqueue at background priority 250. Once a fetch is   active, manifest, block request, data, and proof messages enqueue at primary priority 0. Relay-only   nodes classify the wire message identically, so a transfer stays primary across the complete path.</li> <li>Reliability is eventual: the fetcher re-requests only missing fragments after an adaptive deadline   derived from packet airtime, outstanding response packets, duty pacing, and path length. The manager may   still run a one-second maintenance tick, but that tick is not itself a retry timer. No hard ACKs or global   ordering are required.</li> <li>Relay envelope: OTA still uses a bounded flood-shaped mesh header so the same packets can cross the   configured number of hops without first discovering an addressed return path. During TempRadio each node   forwards one copy; active OTA packets do not use the generic flood-retry subsystem. The fetcher verifies   every block against the signed root, and a repeater without <code>ENABLE_OTA</code> can transport   <code>PAYLOAD_TYPE_OTA</code> opaquely without the manager, staging store, installer, or destination bootloader.</li> <li>Hop limit + duty cycle: OTA floods accumulate one path-hash per relay (the mesh's flood routing). A   node with the OTA manager accepts a packet only if it arrived within <code>ota config hops</code> hops (default 3;   <code>0</code> = direct only) and relays it only while still under that limit, appending its own hash. Relay-only   repeaters instead use their ordinary flood limits and forwarding filters. Discovery relays remain   lowest-priority and may be skipped when the packet pool runs low. Active-transfer relays bypass that   background pool gate and use priority 0; operators should therefore treat TempRadio as a dedicated OTA   maintenance window because the transfer can delay unrelated mesh traffic.</li> </ul>"},{"location":"ota_protocol/#81-two-tier-discovery","title":"8.1 Two-tier discovery","text":"<p>Because a node may serve many mOTAs (its own firmware plus an external folder - Section 10), discovery is split so the periodic beacon stays tiny regardless of catalog size:</p> <p>Tier 1 - <code>OTA_ADV</code> beacon (10 bytes, constant). Flooded as a short burst at boot, then every <code>advert_mins</code> minutes (default 24h; runtime-tunable via <code>ota config advert</code>, <code>0</code> disables the periodic re-advertise). It is also emitted immediately whenever the served set changes (e.g. a <code>motatool</code> folder is attached/detached), so peers learn about newly-available firmware without waiting for the next interval:</p> <pre><code>seeder_id[4]    advertiser node id = pubkey[0:4]; the QUERY address + distinct-source id\nn_motas         uint8 - count of complete servable mOTAs (saturates at 255)\nset_digest[4]   sha2-256:4 over the SORTED set of served manifest_ids (see below)\n</code></pre> <p><code>set_digest</code> is a content hash of the offering, not a counter: canonical across nodes, and it changes iff the set of served mids changes. A peer that has already catalogued this <code>{seeder, set_digest}</code> ignores the beacon (steady state is query-free). For a single served mota, <code>set_digest = sha2-256:4(mid)</code>.</p> <p>Tier 2 - <code>OTA_QUERY</code> -&gt; <code>OTA_HAVE</code> (on interest only):</p> <pre><code>OTA_QUERY  (flood):  seeder_id[4]  set_digest[4]  filter_target(uint32) want_fragments(uint32)\n                     # filter_target 0 = everything; want_fragments 0 = every fragment\nOTA_HAVE   (flood):  seeder_id[4]  set_digest[4]  frag_idx(1) frag_total(1) n_rows(1)  rows[]\n  HaveRow (16 bytes, OTA_HAVE_ROW_BYTES): mid[4] target_id(4) fw_version(4) codec_id(1) flags(1) have_count(2)\n</code></pre> <p><code>have_count</code> is the number of blocks the source holds (<code>== block_count</code> for a complete offered image). Receivers do not advertise partial or completed downloads as new sources.</p> <p>A node interested in a source's offering schedules a QUERY; the source replies with its full catalog as <code>OTA_HAVE</code> rows (fragmented if they exceed one packet - 10 rows per fragment). A receiver marks the catalog complete only after all <code>frag_total</code> fragments arrive. If any are missing after the recovery timeout, it sends another QUERY whose <code>want_fragments</code> bitmap names only the holes. <code>want_fragments</code> is an append-only extension: an original 13-byte QUERY is still accepted and means \"send every fragment.\" The heavy manifest is fetched per-mid only on commit (Section 8.3).</p> <p>Fragment numbers are canonical pages of the complete catalog sorted by <code>manifest_id</code>. <code>filter_target</code> may remove rows from a requested page (and can therefore produce an empty fragment), but it never renumbers pages or changes <code>frag_total</code>. This keeps missing-fragment recovery unambiguous when filtered and unfiltered queries for the same <code>{seeder, set_digest}</code> are overheard together.</p>"},{"location":"ota_protocol/#82-anti-storm-mandatory-at-mesh-scale","title":"8.2 Anti-storm (mandatory at mesh scale)","text":"<p>If 50 neighbours all queried a new beacon at once, the mesh would collapse. Mitigations (gossip/mDNS pattern), all in <code>OtaManager</code>:</p> <ul> <li><code>OTA_HAVE</code> is flooded and digest-tagged. EVERY node that overhears it caches the rows passively   (keyed by <code>{seeder, set_digest}</code>) - no query of its own needed.</li> <li>Jittered query: a peer needing a catalog schedules its <code>OTA_QUERY</code> after a random delay   <code>OTA_QUERY_MIN_MS (300) + rand(OTA_QUERY_SPREAD_MS (4000))</code>, derived from <code>id +/ digest +/ self</code>.</li> <li>Overhear suppression: during the jitter window, overhearing another QUERY that covers the same scope,   or completing the HAVE fragment set for the same <code>{seeder, set_digest}</code>, cancels the pending query.</li> <li>Per-source recovery: each seeder has independent query/retry state. One source cannot overwrite another   source's timer, and a partial reply requests only missing fragments after 15 seconds (five bounded retries,   then another source ADV or explicit <code>ota ls</code> can start a fresh series).</li> </ul> <p>Net effect: a digest change costs ~1 query + ~1 HAVE flood mesh-wide; a stable mesh is query-free.</p>"},{"location":"ota_protocol/#83-fetch-handshake","title":"8.3 Fetch handshake","text":"<pre><code>fetcher                                   server (any node that has the mid)\n  OTA_GET_MANIFEST(mid, want_mask)  &gt;     (want_mask=0xFFFF first; only missing fragments on retry)\n                               &lt;-------   OTA_MANIFEST(mid, frag_idx, frag_total, bytes)   x requested frags\n  (reassemble manifest, verify, compute geometry: BC, block_size, payload_size)\n  for each adaptive flight of missing blocks (starts at 1, grows on clean flights):\n    OTA_REQ(mid, {block_idx, want_mask}[]) &gt;  (one packet; all fragments first, only holes on recovery)\n                               &lt;-------   OTA_DATA(mid, block_idx, frag_off, data) x requested frags/block\n                               &lt;-------   OTA_PROOF(mid, block_idx, n_proof, proof) x requested blocks\n    (independently reassemble + verify each block, but remain RX-silent until the flight drains)\n    [after adaptive deadline: recover one block's holes, or OTA_REQ_PROOF for a missing proof]\n    (clean flight grows by one block; recovered flight halves the next width)\n  when all blocks present: verify full merkle_root + image_hash -&gt; COMPLETE\n</code></pre> <p>Before allocating or writing the selected store, the receiver parses the reassembled manifest and requires its <code>merkle_root</code> to equal the requested/wire <code>manifest_id</code> and its <code>target_id</code> to equal the catalog or explicit-pull target that opened the receive slot. The wire envelope and HAVE row are advisory; they cannot label and stage a different manifest.</p>"},{"location":"ota_protocol/#84-message-bodies-transfer","title":"8.4 Message bodies (transfer)","text":"<p>All offsets after the 1-byte type. Encoders/decoders in <code>OtaProtocol.cpp</code>; constants in <code>OtaManager.h</code>.</p> <pre><code>OTA_GET_MANIFEST:  manifest_id[4]  want_mask(uint16)   # bit k = send manifest fragment k; 0xFFFF = all\nOTA_MANIFEST:      manifest_id[4]  frag_idx(1)  frag_total(1)  bytes[]     # up to OTA_MF_FRAG=176 B/frag\nOTA_REQ:           manifest_id[4]  { block_idx(uint16)  want_mask(uint16) }[1..4]\n                   # legacy: bit k requests its 160-byte fragment\n                   # v2: bit15=marker, bit14=allow transport DEFLATE,\n                   #     bit13=2 KiB descriptor, bits0..12=fragment bitmap;\n                   #     bit12 must be zero when bit13 is set (0xFFFF stays legacy)\nOTA_DATA legacy:   manifest_id[4]  block_idx(uint16)  frag_off(uint16)  data[&lt;=160]\nOTA_DATA v2:       manifest_id[4]  block_idx(uint16)  descriptor(uint16)\n                   stream_id[4]  data[&lt;=171]\n                   # deployed 1 KiB descriptor: bit15=marker, bit14=DEFLATE,\n                   #   bits13..10=fragment, bits9..0=complete encoded length minus one\n                   # negotiated 2 KiB descriptor: bit15=marker, bits14..11=fragment,\n                   #   bits10..0=complete encoded length minus one; DEFLATE iff that\n                   #   length is strictly less than the manifest-derived raw block length\nOTA_REQ_PROOF:     manifest_id[4]  block_idx(uint16)\nOTA_PROOF:         manifest_id[4]  block_idx(uint16)  n_proof(1)  proof[]   # n_proof x 4 bytes\nOTA_GET_LEAVES:    manifest_id[4]  want_mask(uint16)   # bit k = send leaves fragment k; 0xFFFF = all\nOTA_LEAVES:        manifest_id[4]  frag_idx(1)  frag_total(1)  bytes[]      # up to OTA_LEAVES_FRAG=176 leaf bytes\n</code></pre> <ul> <li> <p>Warm-start / leaf-diff (<code>OTA_GET_LEAVES</code>/<code>OTA_LEAVES</code>) - motatool folder-capture only. Capturing a   device's firmware into a <code>motatool serve</code> folder is slow (a full image is hundreds of blocks). Because   builds here are non-deterministic, you cannot reproduce the exact target on the host - but a similar   build (e.g. a fresh recompile) is ~99% identical. So <code>motatool serve --seed &lt;similar.mota&gt;</code> stages that   build's payload into the destination <code>.part</code>, and <code>ota pull &lt;mid8&gt; folder validate</code> makes the fetcher (1) bulk-   fetch the target's <code>leaves[]</code> via <code>OTA_GET_LEAVES</code>/<code>OTA_LEAVES</code> (bitmap-fragmented with a <code>want_mask</code>, same   anti-burst rule as <code>OTA_MANIFEST</code>), (2) recompute the merkle root from them and check it equals the   manifest root (authenticate), then (3) keep every seeded block whose leaf matches and pull full <code>OTA_DATA</code>   only for the blocks that differ. The <code>want_mask</code> is a fixed uint16, so <code>leaves[]</code> is capped at   <code>OTA_LEAVES_MAXFRAG=16</code> fragments (<code>OTA_DIFF_MAX_BLOCKS=704</code> blocks); larger images just fall back to a full   fetch. Normal P2P nodes never use this - they target only the blocks they want; the only always-on part   is answering <code>OTA_GET_LEAVES</code> with leaves the node already holds, so any node's firmware can be captured.</p> </li> <li> <p>Negotiated 171-byte fragments: the deployed profile remains unchanged: <code>frag_off</code> is a byte offset and   <code>data[]</code> carries at most 160 bytes. A new fetcher marks an <code>OTA_REQ</code> row as v2. For a deployed 1 KiB block,   its first request also includes every fragment bit needed by the legacy representation, so an old source can   answer it completely. The extended 2 KiB profile reserves bit 12 as zero; this both fits its twelve v2   fragments and ensures the deployed <code>0xFFFF</code> legacy all-fragments request is never misclassified. Receipt of   untagged <code>OTA_DATA</code> switches the fetch session to the old geometry. If no v2 data appears by the first   adaptive deadline, the fetcher retries with an ordinary legacy mask. New sources answer v2 with a packed descriptor, a repeated 4-byte representation   ID, and exactly 171 data bytes except the final fragment. A raw 1 KiB block falls from seven data packets to   six; a raw 2 KiB block falls from thirteen to twelve. Message type IDs do not change, so multi-hop relays   continue to forward request/data/proof packets opaquely with the same priority.</p> </li> <li>Transport-only DEFLATE: a fetcher sets the v2 DEFLATE-permission bit only when its application includes   and configures the decoder. A source may encode each logical block as an independent raw RFC 1951 stream   with full stored, fixed-Huffman, and dynamic-Huffman support (<code>BTYPE=0/1/2</code>). Compression is used only when   strictly smaller, otherwise the source returns raw v2 data. The   receiver inflates to the manifest-derived block length, then performs the unchanged Merkle proof and writes   the original bytes to staging. Thus staging and bootloader apply remain uncompressed. Deployed 1 KiB   <code>.mota</code> containers remain compatible; new 2 KiB containers require a receiver advertising the extended   descriptor. Format-3 bootloader packages retain their strict 1 KiB geometry. The 4-byte <code>stream_id</code> is   SHA-256:4 of the complete raw or compressed   representation and appears in every fragment. A receiver locks <code>{encoding, encoded length, stream_id}</code> for   a block, preventing fragments from independently encoded seeders from being mixed. After one sparse retry,   a second stalled interval clears the full in-flight window and switches the session to legacy geometry, so   a vanished v2 seeder cannot prevent an older source from taking over; proof verification remains unchanged.   Every <code>ENABLE_OTA</code> MeshCore application registers the vendored tinf 1.2.1 full raw decoder; its wrapper   bounds output to the exact logical block length and rejects truncation, malformed streams, and trailing   whole bytes. Builds without OTA do not link the decoder. This application capability is independent of the   bootloader because transport data is inflated before the unchanged staged container is written.</li> <li>Adaptive flight size is not signed block size. Each slot holds one manifest-defined block: 1 KiB for   deployed application containers or 2 KiB for new ones. A clean link changes how many complete blocks one   <code>OTA_REQ</code> names: 1, then 2, then 3, then the compiled cap. It never changes block geometry. Two KiB halves   the leaf, block-request, and proof count for a payload while giving each independent DEFLATE stream a larger   history window.</li> <li>Append-only request-window compatibility: the first four-byte request row is exactly the original   <code>block_idx + want_mask</code> body. Old sources decode that row and ignore appended bytes. New sources queue all   rows. If a new fetcher meets an old source, the unserved tail rows eventually time out and are recovered as   ordinary single-row requests; the dirty flight then contracts. Old fetchers continue sending nine-byte   single-row requests, which new sources accept normally.</li> <li>Fragment-level requests (anti-deadlock + anti-congestion): <code>OTA_REQ</code>, <code>OTA_GET_MANIFEST</code>, and <code>OTA_QUERY</code>   carry fragment masks. For catalog discovery, <code>want_fragments</code> is a 32-bit bitmap and covers the protocol   maximum 255-row catalog (26 fragments at the current packet size). For block and manifest transfer, the   <code>want_mask</code> is 16 bits. A fetcher requests the full set on the first ask   (<code>(1&lt;&lt;nf)-1</code>, or <code>0xFFFF</code> before <code>frag_total</code> is known) and only the still-missing bits on any retry,   so recovering one lost fragment re-sends one fragment, not the whole block/manifest. This is essential on   half-duplex radios: re-requesting a whole multi-fragment burst let the periodic retry (a transmit) collide   with the tail of the in-flight burst and drop the same fragment forever - a hang. Requesting only the hole   removes the burst, so there is nothing to collide with. The block/manifest mask matches the 16-bit   reassembly bitmap (&lt;=16 fragments/block; 1 KiB is 7 legacy or 6 raw-v2 fragments; 2 KiB is 13 legacy or 12   raw-v2 fragments). <code>OTA_PROOF</code> is a single packet and needs no mask.</li> <li>Data and proof remain separate packets, without a normal extra round trip. A server retains requested   blocks in a bounded descriptor queue, admits at most one response per main-loop pass, and sends one   <code>OTA_PROOF</code> after each block's requested fragments. Before admitting that proactive proof, the source leaves   an airtime/duty-aware 100-3000 ms RX turnaround gap. It accounts for one active transmission plus the two   paced-response queue credits. A legacy receiver uses the gap to send its immediate   <code>OTA_REQ_PROOF</code>; receiving that explicit request bypasses the remaining gap, avoiding a proof/request   collision and an otherwise multi-second legacy retry. A newer receiver uses an airtime/path-aware proof   grace (never less than 500 ms) and defers <code>OTA_REQ_PROOF</code> while any flight slot still expects DATA. Thus a   missing early proof cannot make the receiver transmit into the rest of a legitimate half-duplex response   train. After the complete-flight deadline, only one slot's missing fragments/proof is requested at a time.</li> </ul>"},{"location":"ota_protocol/#85-sizing-against-max_packet_payload-184","title":"8.5 Sizing against <code>MAX_PACKET_PAYLOAD = 184</code>","text":"message fixed overhead payload/packet <code>OTA_DATA</code> legacy 9 B (type+mid4+idx2+off2) <code>OTA_FRAG_DATA = 160</code> -&gt; 7 raw frags/1 KiB or 13/2 KiB <code>OTA_DATA</code> v2 13 B (legacy header + stream ID) <code>OTA_FRAG_DATA_V2 = 171</code> -&gt; 6 raw frags/1 KiB or 12/2 KiB; fewer when compressed <code>OTA_MANIFEST</code> 7 B <code>OTA_MF_FRAG = 176</code> -&gt; signed manifest ~ 2 frags <code>OTA_HAVE</code> 12 B 10 rows x 16 B per fragment <code>OTA_PROOF</code> 8 B up to ~44 sibling digests (&gt;&gt; any real tree) <p>A served mota supports up to 1024 leaves in the default 4 KiB proof scratch (about 2 MiB of payload at the new 2 KiB default, or 1 MiB for a deployed 1 KiB container); larger self-images pass a bigger scratch buffer.</p>"},{"location":"ota_protocol/#86-temporary-radio-and-transfer-boundary","title":"8.6 Temporary-radio and transfer boundary","text":"<p>OTA packets may cross normal mesh relay hops, but each participating node processes or relays them only while its <code>tempradio</code> window is actually running. A receiver selects missing blocks in serial order into a bounded request flight. Every session starts with one block. A clean completed flight increases the next request by one block; a flight requiring fragment/proof recovery halves the next width (<code>4 -&gt; 2</code>, <code>3 -&gt; 2</code>, <code>2 -&gt; 1</code>). The default compiled cap is two blocks; the RAK3401 LoRa-OTA target caps at four, so it probes <code>1 -&gt; 2 -&gt; 3 -&gt; 4</code>. All rows are sent in one backward-compatible <code>OTA_REQ</code>, and no freed slot is refilled until the current flight is finished. It never serves partial blocks. A normal install receiver never re-advertises its completed download. An SD archive node is the deliberate exception: after a fully proof-verified container is published to its persistent archive, it registers that complete file as a MotaSource and advertises it as a new seeder. This keeps each active transfer as one transmitter and one receiver while still allowing active temporary-radio repeaters between them and persistent archive nodes to improve future availability.</p> <p>TempRadio is treated as a private maintenance network. Active transfer packets use priority 0, bypass the public-flood receive holdoff, use the full transmit budget without overwriting the saved normal-radio airtime factor, retain the relay role's airtime-scaled transmit collision window, and do not schedule generic flood retries. Deployed firmware predating that TempRadio budget override can be accelerated manually with a saved <code>get af</code> / temporary <code>set af 0</code> / restore sequence. The bounded serving queue admits at most two DATA/PROOF packets ahead of the radio while preserving at least four free packet-pool entries. CAD remains enabled to arbitrate the half-duplex channel, but its busy retry is scaled to one-quarter of a packet airtime and clamped to 5-50 ms instead of the ordinary 120-360 ms cadence. Discovery traffic keeps collision jitter and background priority. The fetch deadline uses the active radio's measured maximum-packet airtime, remaining DATA/PROOF packet count, dispatcher airtime factor, and longest observed path (falling back to the configured hop horizon before one is observed), with bounded guard time. Faster SF/BW settings therefore recover loss sooner; slower or multi-hop settings do not spuriously re-request a response still on air. These changes remove software waits and duplicate bursts; they do not remove the one required forwarding transmission per hop.</p>"},{"location":"ota_protocol/#9-identity-trust-versioning","title":"9. Identity, trust &amp; versioning","text":"<ul> <li><code>target_id</code> (4 B): <code>sha2-256:4(pio_env_name)</code> (little-endian uint32). The env name uniquely captures   hardware and role/partition, so a node auto-fetches only matching firmware (a companion image is not   fetched onto a repeater even though it shares <code>hw_id</code>). It is self-described in the firmware's EndF   (Section 2, written by <code>pio_endf.py</code>) and read via <code>ota_self_firmware()</code>, so it is correct on any build;   <code>-D MOTA_TARGET_ID</code> / <code>MainBoard::getOtaTargetId()</code> is the fallback when no EndF identity is present.   <code>tools/mota</code> reads it from the firmware's EndF (or <code>--target-env</code>). A manual <code>ota pull</code>/<code>want</code> can override   target (deliberate role switch); the <code>hw_id</code> brick-safety gate (Section 4) still applies at apply time.</li> <li><code>target_id</code> vs <code>hw_id</code> - complementary, not redundant: <code>target_id</code> is the fetch-routing key   (hw + role + partition); <code>hw_id</code> is the human-readable brick-safety key (hardware only). Same board, two   roles =&gt; same <code>hw_id</code>, different <code>target_id</code>.</li> <li>Naming a <code>target_id</code> locally: only the 4-byte <code>target_id</code> ever travels on the wire. To show which   board/role a target is, a node (and <code>motatool</code>) reverse-looks-it-up in <code>src/helpers/ota/OtaTargets.h</code> -   a generated <code>target_id -&gt; env-name</code> table covering every <code>ENABLE_OTA</code> env (<code>tools/mota/gen_targets.py</code>,   resolved from <code>pio project config</code>). So <code>ota ls</code> can render <code>[Heltec_v3_repeater]</code> for a neighbour's   beacon without the string being transmitted. Unknown IDs show as raw <code>hw XXXXXXXX</code> / <code>N/A</code> values.</li> <li><code>fw_version</code>: packed comparable uint32 (<code>MAJOR&lt;&lt;24 | MINOR&lt;&lt;16 | PATCH&lt;&lt;8 | pre</code>); also self-described   in EndF. <code>ota ls</code> prints the stable eight-hex manifest ID and uses <code>[same target]</code>, <code>[unsupported]</code>, or   <code>[rescue]</code> after combining target equality with the local codec, bootloader, and EndF preflight. A known   different target is rendered by environment name; an unknown/unset target remains raw or <code>?</code>. Target   equality is routing information, not by itself an assertion that an image is safe to install.</li> <li><code>hw_id</code>: 32-byte NUL-padded ASCII hardware tag inside the signed head. The applier refuses a <code>.mota</code>   whose <code>hw_id</code> differs from the device's own tag (empty on either side = permissive). Brick-safety   independent of signature.</li> <li>Signing &amp; allowlist: a node keeps a runtime allowlist of trusted Ed25519 signer pubkeys (none embedded   in firmware; <code>ota key add/list/rm</code>). A <code>.mota</code> is eligible for auto-install only if signed by an   allowlisted key, the signature verifies, <code>image_hash</code> matches, and its nonzero signed <code>fw_version</code> is   strictly greater than the running hash-valid EndF version. Both catalog admission and final automatic   apply enforce the version floor, so a lying HAVE row cannot bypass it. Manual <code>ota install</code> is the explicit   equal-version/rollback override and generally permits unsigned packages,   but a package that claims to be signed must have a valid signature from an allowlisted key or it is rejected.   The removable-SD target is stricter: every application install needs a valid allowlisted signature because   the app mints an authenticated one-reset media authorization for OTAFIX.   Transfer needs no trust - blocks are content-addressed against the manifest's merkle root.</li> <li>Policies (persisted): <code>autofetch</code> in {off, any, signed} (default off) gates automatic block fetching of   own-target adverts; <code>autoinstall</code> in {off, trusted} (default off) gates auto-apply of a COMPLETE signed +   allowlisted fetch. Conservative defaults: a fresh node discovers + announces but never fetches/installs   without operator intent.</li> <li>Supersession: a newer version announced mid-download does not abort the in-progress transfer   (finish-current).</li> </ul>"},{"location":"ota_protocol/#10-multi-mota-serve-the-external-folder-relay","title":"10. Multi-mota serve &amp; the external \"folder\" relay","text":"<p>A node serves a set of mOTAs: its own firmware plus, optionally, an external folder of <code>.mota</code> files it relays without holding them in flash. To peers it simply \"has N mOTAs\"; the relay is trustless (fetchers verify everything). The serve side (<code>OtaManager</code>) keeps a lightweight registry of what it advertises and two resident \"views\": <code>view0</code> (its own firmware) and one on-demand view loaded from a source when a request targets an external mota. Every fetch message carries <code>manifest_id</code>, so dispatch is a registry lookup.</p> <p>The USB/TCP host-folder link can also be a pull destination (the reverse direction): <code>ota pull &lt;mid8&gt; folder</code> fetches a <code>.mota</code> off the mesh and streams it onto the host as <code>&lt;mid&gt;.mota</code> via the seeder STORAGE ops (<code>OP_STAT/BEGIN/WRITE/SREAD/FIN</code>, see <code>MotaSeederProto.h</code>), using a <code>FolderMotaStore</code> as the fetch's <code>OtaStore</code> instead of RAM/flash. This captures an exact copy of a device's firmware - e.g. to build a delta against firmware you don't have. Resume is bookkeeping-free: <code>BEGIN</code> 0xFF-fills the file and, on reconnect after a link drop (the fetch PAUSES, holding progress on the host - no RAM/flash fallback), <code>STAT</code>+<code>SREAD</code> let the fetcher recompute and refill only the missing blocks. The phone-oriented BLE link is deliberately source-only and does not register a folder destination.</p>"},{"location":"ota_protocol/#101-the-motasource-abstraction-otasourceh","title":"10.1 The <code>MotaSource</code> abstraction (<code>OtaSource.h</code>)","text":"<p>Transport-agnostic provider of one or more complete <code>.mota</code> as random-access bytes. The same serve code drives USB-serial, BLE, a WiFi URL list, an NFS/samba mount, etc. - only <code>read()</code> differs.</p> <pre><code>struct MotaDesc {                      // catalog metadata + region offsets (no whole image in RAM)\n  uint8_t mid[4]; uint32_t target_id, fw_version; uint8_t codec_id, flags;\n  uint8_t block_size_log2, source_caps;\n  uint32_t total_size, leaves_off, block_count, payload_off, payload_size;\n};\nclass MotaSource {\n  virtual uint8_t count();                                  // # mOTAs offered\n  virtual bool    describe(uint8_t idx, MotaDesc&amp; out);     // metadata + offsets\n  virtual bool    read(uint8_t idx, uint32_t off, uint8_t* buf, uint32_t len);   // random-access bytes\n  virtual bool    read_deflated_block(uint8_t idx, uint16_t block,\n                                      uint8_t* buf, uint16_t cap, uint16_t* len); // optional raw RFC 1951\n};\n</code></pre> <p>To serve an external mota the node reads its manifest-minus-leaves + <code>leaves[]</code> into RAM (&lt;=4 KiB for &lt;=1024 blocks) and streams payload blocks from the source on demand; proofs are generated from the read leaves.</p>"},{"location":"ota_protocol/#102-the-mota-seeder-transport-motaseederprotoh","title":"10.2 The <code>mota-seeder</code> transport (<code>MotaSeederProto.h</code>)","text":"<p>A <code>MotaSource</code> is fed by a host that serves a folder over the device's USB serial (the same console the CLI uses - no extra hardware), on an ESP32 WiFi companion or FULL ESP32 role over WiFi (TCP), or on an nRF52 Full Companion over an encrypted BLE GATT service. The host is the standalone Rust tool <code>motatool</code> (<code>motatool serve --serial &lt;port&gt;</code> / <code>--tcp &lt;host[:port]&gt;</code>, which also builds + verifies + inspects <code>.mota</code>). The device only emits request frames while actively serving a fetch, and reads the reply synchronously, so over the shared USB console binary frames coexist with the text CLI/logs (resync on magic + checksum). Little-endian, XOR-checksummed:</p> <pre><code>request  (device -&gt; host):  'M' 'S'  op(1)  args...                 xsum(1 = XOR of op+args)\nresponse (host -&gt; device):  'm' 's'  op(1)  status(1)  payload...    xsum(1 = XOR of all prior)\n\nOP_COUNT     0x01   args: -            -&gt; payload: count(1)\nOP_DESCRIBE  0x02   args: idx(1)       -&gt; payload: MotaDesc wire (38 B)\nOP_READ      0x03   args: idx(1) off(4) len(2)  -&gt; payload: len bytes\nOP_DEFLATE_BLOCK 0x09 args: idx(1) block(2) off(2) len(2)\n                         -&gt; payload: total_encoded_len(2) + requested bytes\nMotaDesc wire (38 B): mid[4] target_id(4) fw_version(4) codec(1) flags(1)\n                      total_size(4) leaves_off(4) block_count(4) payload_off(4) payload_size(4)\n                      block_size_log2(1) source_caps(1) reserved(2)\nstatus: 0 = OK, non-zero = error (out of range / past EOF).\n</code></pre> <p><code>SerialMotaSource</code> splits logical reads into replies of at most 192 payload bytes. A manifest's leaf table can exceed 256 bytes and new payload blocks are normally 2 KiB; requesting either in one transaction can overrun common USB CDC/UART receive rings even though the host successfully wrote the complete reply. Chunking is internal to the transport and does not change <code>OP_READ</code> or the <code>MotaSource</code> random-access contract.</p> <p><code>OP_DEFLATE_BLOCK</code> lets a host-folder source perform the optional transport compression without linking an encoder into the embedded seeder. <code>len=0, off=0</code> queries the exact encoded length; subsequent chunks are at most 190 bytes, keeping the total response payload at 192 bytes. The host independently encodes each manifest payload block as ordinary raw RFC 1951 at level 9. It returns an error for an invalid range, an unsupported operation, or a result that is not smaller than the raw block; <code>SerialMotaSource</code> then serves the ordinary raw v2 representation. A supporting host sets <code>source_caps bit 0</code> in every descriptor. Older hosts leave that formerly-reserved byte zero, so upgraded firmware skips the optional request instead of waiting for an old daemon that silently ignores unknown operations.</p> <p>Manifest fragments are retained as bounded response jobs and admitted one at a time. Their source-side gap follows the active maximum packet airtime and dispatcher duty spacing, clamped to 100-1000 ms. The 100 ms floor protects fast radios' TX-to-RX turnaround; the cap keeps the receiver's one-second manifest progress/retry observation responsive. The source uses the same radio-aware 100-3000 ms drain/turnaround gap before an unsolicited block proof, but immediately serves a legacy receiver's explicit <code>OTA_REQ_PROOF</code>. Relay collision delay is a separate setting: active OTA floods honor the relay role's configured <code>txdelay</code>, and the deployment runner temporarily uses <code>0.3</code> on managed relays.</p> <p>What to plug into <code>--serial</code>. Use the USB serial console of an OTA-enabled MeshCore node built with <code>OTA_FOLDER_SERIAL</code>. The node must have a working LoRa radio plus an <code>ota folder on</code> command; that command confirms it can host and advertise the folder. A KISS modem will not work: KISS firmware exposes a TNC/KISS frame interface, not the MeshCore CLI and <code>mota-seeder</code> request/response transport. An ESP32 WiFi companion or FULL ESP32 role with active WiFi is the alternative source connection: use its dedicated seeder port with <code>motatool serve --tcp &lt;host&gt;:5001</code>. An nRF52 Full Companion can instead pair with a phone or Linux host, subscribe to its mOTA request characteristic, and use protocol-v14 <code>CMD_BLE_MOTA_SOURCE</code>. That BLE path is source-only; it does not expose the reverse <code>FolderMotaStore</code> capture operations.</p> <p>Device CLI: <code>ota folder on</code> (attach + announce), <code>ota folder</code> (list), <code>ota folder off</code>. Build flag <code>OTA_FOLDER_SERIAL</code> (default stream = console <code>Serial</code>; override <code>OTA_FOLDER_SERIAL_STREAM</code> + define <code>OTA_FOLDER_SERIAL_BEGIN</code> for a dedicated UART). ESP32 WiFi companions and FULL ESP32 roles run a <code>WiFiServer</code> on the dedicated seeder port (<code>OTA_SEEDER_TCP_PORT</code>, default <code>5001</code>) while WiFi is usable. On a companion it is separate from the app port (<code>TCP_PORT</code>, default <code>5000</code>); on infrastructure roles it is separate from WebConfig and browser OTA on port 80. The node auto-attaches the source when a seeder client connects and detaches when it closes (no <code>ota folder on</code> needed over TCP). An already-active serial folder causes a TCP client to be rejected instead of silently replacing it. Verified on hardware: a RAK4631 relays a host folder to a Heltec V3 over one USB cable, and a host feeds a Heltec V3 over WiFi (<code>:5001</code>) while the companion serves a phone on <code>:5000</code> - every block merkle-checked.</p> <p>The attach reply and bare <code>ota folder</code> report <code>host=advertised/offered</code>. The registry is RAM-bounded (<code>OTA_MAX_SERVE</code>, with the node's own firmware consuming one slot), so a host may correctly index more valid files than this particular firmware can advertise. Omitted entries are now reported instead of silently disappearing. Operators should split a large chain or use a higher-capacity/SD seeder when the two counts differ.</p> <p>Transport-agnostic by design. The request/response semantics (<code>COUNT</code> / <code>DESCRIBE(idx)</code> / <code>READ(idx, off, len)</code> over a folder catalog) are independent of the link. The 2-byte magic + XOR checksum + resync framing above exists for the shared USB-UART (an unframed byte stream); it is harmless over a reliable stream and the WiFi (TCP) transport reuses it as-is - both ends just treat the socket as a byte stream (on-device, <code>SerialMotaSource</code> runs verbatim over an Arduino <code>Stream</code>-compatible <code>WiFiClient</code>; <code>motatool</code>'s <code>TcpTransport</code> mirrors its <code>SerialTransport</code>). The nRF52 Full Companion's BLE GATT path also reuses the exact frame and checksum. Device requests are notifications on a dedicated characteristic and host responses are ordered write-with-response fragments on a second characteristic. Keeping the same framing makes retries and corruption handling identical across USB, TCP, and GATT. The Linux reference implementation is <code>tools/ble_mota/ble_mota_seeder.py</code>; a phone app can implement the same transport-free catalog operations.</p>"},{"location":"ota_protocol/#11-cli-surface-otaclicpp","title":"11. CLI surface (<code>OtaCli.cpp</code>)","text":"<p>User-facing OTA data should travel via <code>CMD_OTA_*</code> companion binary frames; the text CLI below is debug/operator oriented and replies are <code>snprintf</code>-bounded into a 160-byte buffer.</p> <p>Commands take intuitive aliases (matched by the first word; see <code>is_cmd</code> in <code>OtaCli.cpp</code>) so they're easy to type and read - <code>status</code>/<code>neighbors</code>/<code>pull</code>/<code>drop</code>/<code>applydelta</code> are the canonical names, the aliases are the recommended user-facing forms. Output is plain-language (a user-facing guide lives at ota_user_guide.md).</p> <pre><code>ota help | ? | h                   list the commands\nota status | st  (or bare `ota`)   plain-language: running fw, the one fetch session (state/%/id), serving, keys\nota ls | neighbors | nbrs | updates | n [page]   paged updates (queries sources; rows arrive async via OTA_HAVE)\nota get | pull | download &lt;mid8|#index&gt; flash [rescue] | folder [validate]\n                                      fetch by stable mid8 (preferred) or current page index\nota install | apply | applydelta   verify + approve + (ESP32) apply / (nRF52) reboot-to-bootloader\nota rescue install &lt;base_hash16&gt;  internal-flash nRF52 only: recover from failed app-side EndF validation\nota bootloader [status]           capable allowlisted nRF52 repeater: installed BL identity/caps + staged confirmation\nota bootloader install &lt;MID8&gt; &lt;HASH16&gt;\n                                      explicitly verify/arm one complete trusted v3 package; never automatic\nota cancel | drop | stop           drop the fetch; durably invalidate device staging, or retain a folder partial for resume\nota announce | adv                 serve self + send a beacon now\nota self | id                      print this firmware's EndF (body/image size, base_hash)\nota qspi | storage                 QSPI nRF52 only: JEDEC/SR1/stage/latched storage error (read-only)\nota folder | fold [on|off]         attach/detach an external .mota folder (host daemon) ; bare = list\nota config | cfg | set [autofetch|autoinstall|checkpoint] ...   show/set persisted policy\nota key | keys [add|rm &lt;hex&gt;]      trusted signer allowlist ; bare = list\nota dev ...                        bring-up helpers (stage/recv/serve/resume &lt;MID8&gt;/verify)\n</code></pre> <p>For a device-backed pull, current firmware returns success only after the persistent store can no longer be reopened; flash/SD/QSPI I/O or readback failure is reported as an error even though the in-memory manager session was dropped. For a <code>folder</code> pull, cancellation detaches the live transfer but deliberately leaves the host <code>.part</code> file available for a later resume. If the shared receive engine is currently performing the MeshTower SD auto-archive capture, cancellation likewise detaches that archive transfer and retains its <code>.part</code> file; it does not erase the unrelated manual-install store.</p> <p></p>"},{"location":"ota_protocol/#12-apply-bootloader-contract","title":"12. Apply &amp; bootloader contract","text":"<ul> <li>ESP32 (A/B): applied in-firmware via the detools decoder into the inactive OTA slot   (<code>OtaApply.cpp::ota_apply_detools_mota</code> + <code>OtaStoreFlashEsp32</code>), then set-boot + reboot (power-safe,   rollback-capable). No bootloader changes. Erase ranges must be sector-aligned (4096).</li> <li>nRF52 (single-slot): the running firmware never flashes the app. <code>ota install</code> verifies the   container fully (<code>image_hash</code>, codec, signature/allowlist, <code>hw_id</code>, and <code>base_hash</code> for a delta), writes   <code>approval = \"APRV\"</code>, then reboots into the modified bootloader   (<code>Adafruit_nRF52_Bootloader_OTAFIX</code>). The bootloader:</li> <li>locates the staged <code>.mota</code> in the approved internal, raw-SD, or raw-QSPI store without trusting an      unchecked stored size,</li> <li>re-checks <code>TRAILER</code>, <code>image_hash</code>, and <code>approval == \"APRV\"</code>; for a delta it also checks that      <code>base_hash</code> equals the running firmware's <code>EndF.body_hash</code> (recomputed by scanning for <code>EndF</code> - never      trust <code>bank_0_size</code>),</li> <li>writes a full external-media payload or applies the in-place codec over the app region, then boots only      if the result hashes to <code>image_hash</code>.</li> <li>nRF52 internal staging ceiling: an internal-store application derives the ceiling from facts available   in every build, not a board-name list. A companion that actually links the internal ExtraFS datastore stays   below <code>0xD4000</code>; a default linker region or a role that does not mount ExtraFS can reclaim the unused   100 KiB through <code>0xED000</code>. An internal bootloader-self-update target keeps that normal linker and ceiling;   it does not reserve a second boot-package or scratch region. The application uses a larger-than-legacy   window only when the   installed bootloader advertises the GPREGRET2 ceiling-handoff capability. The bootloader treats every   unknown/legacy handoff value as   <code>0xD4000</code>, and accepts a container only at the bottom-aligned position for the selected ceiling.</li> <li>nRF52 dynamic apply window: the post-build hook records the resolved app base, linked app end,   internal-ExtraFS/SD/QSPI storage flags, and desired staging ceiling immediately before <code>EndF</code>. <code>motatool</code> reads that authenticated   firmware record and chooses <code>memory_size</code> from the actual patch size and bottom-aligned stage address;   firmware without the record retains the conservative <code>0x98000</code> default. Before writing <code>APRV</code>, an   internal-store app validates the staged-address bound; an external SD/QSPI app validates the full detools   geometry against the application workspace. The bootloader independently parses and validates the same   geometry before its first application write. Expanded auto-sized packages require a bootloader   with the ceiling-handoff capability; use <code>--inplace-memory 0x98000</code> when intentionally targeting an older   bootloader and the images still fit that window.</li> <li>nRF52 EndF rescue: <code>ota rescue install &lt;base_hash16&gt;</code> is a pre-provisioned recovery path for an   internal-flash nRF52 application that still runs but cannot validate its own EndF identity. It refuses   when normal EndF validation succeeds, requires the operator hash to exactly equal the staged delta's   <code>base_hash</code>, requires the package <code>target_id</code> to match and its <code>hw_id</code> to pass the normal hardware gate,   and retains the normal payload and signature/allowlist gates. Approval only delegates the base decision:   OTAFIX independently   locates the physical EndF, hashes the running app, and compares that value with the package before its   first app write. A physically absent/corrupt EndF or wrong base therefore returns to the unchanged app;   it still requires USB recovery if that app does not already contain this command.   A chain intended to cross historical firmware must introduce this command in its first bridge and retain   it in every later bridge. Manual pulls still use the build-provided target ID when app-side EndF parsing   fails, so a rescue-capable bridge can fetch its exact successor before invoking the guarded command. Such   a node must acknowledge the condition up front with <code>ota pull &lt;mid8&gt; flash rescue</code>; an ordinary flash pull   refuses before altering staged data. Firmware that predates both rescue commands still requires USB recovery.   Internal-bootloader-self-update builds are a stricter exception: because their ordinary linker may extend   through <code>0xED000</code>, an absent/corrupt live <code>EndF</code> disables every internal staging pull before erase instead   of trusting the legacy 608 KiB estimate.</li> <li>MeshTower V2 SD nRF52: the application stores a contiguous <code>/meshcore-ota.mota</code> on microSD. After   authenticating one exact signed manifest and verifying the leaves/payload/image, it hashes the exact full   container with only <code>APRV</code> normalized to zero and publishes a 72-byte reset-retained <code>MOTASDA2</code> record.   That record binds app-vs-boot purpose, format, raw sector range, total/card geometry, and normalized digest;   OTAFIX consumes and clears it before reading the card. There is no normal sector-1 handoff or additional   OTA-specific partition-layout requirement beyond what the bundled SdFat can mount. The matching   bootloader reads the authorized sectors without mounting FAT, supports either a full image or an in-place delta,   verifies the staged/full result hash, and never writes through <code>0xED000</code> where InternalFS begins. The   exact SD repeater also accepts a manually selected, signed v3 bootloader package when installed and   candidate markers are exactly <code>0x09</code> (<code>SD|BOOT_UPDATE</code>). MeshCore streams the same strict identity,   CRC, vector, signature, MID/hash-confirmation, and complete-image checks from the SD file. GPREGRET   <code>0x6B</code> plus GPREGRET2 <code>0x53</code> selects this privileged path. Both MeshCore and OTAFIX require a hash-valid   live <code>EndF</code> ending by <code>0xE0000</code>; when a nonzero boot-settings bank CRC is active, its recorded size must   also cover that complete live image and stop by <code>0xE0000</code>. For fmt3 MeshCore additionally writes a readback-checked   <code>MOTASDBL</code> token at <code>0xE0000</code> containing the exact total and signed <code>image_hash</code>. OTAFIX binds the parsed manifest,   streamed payload, and final scratch image to that   token, so a removable-media change can only fail closed. OTAFIX then uses <code>0xE0000..0xEA000</code> as temporary scratch; the normal   application linker remains at <code>0xED000</code> and ordinary application updates do not inherit this scratch   headroom restriction. Both fmt2 application apply and fmt3 bootloader apply require installed BLM2   continuity matching the live S140 FWID/application layout. Preview.12 must be upgraded locally over   USB/BLE DFU or SWD. MeshCore never writes a raw sector-1 handoff.</li> <li>Matched external-QSPI nRF52 repeaters: the application reserves the board's dedicated QSPI NOR as a   raw store beginning at offset zero. It obtains a 1-16 MiB capacity from JEDEC, checkpoints payload before   leaf metadata, and verifies each erased/programmed page. GPREGRET2 <code>0x51</code> selects QSPI only when the   matching bootloader advertises the QSPI storage bit; legacy markers retain the internal scan path. The   bootloader pre-hashes a full payload before invalidating the app, or applies an in-place delta with the   complete internal application region as workspace. Companion builds never enable this raw store: some use   QSPI as a filesystem, while others simply leave that chip outside OTA ownership. See   the nRF52 QSPI guide.</li> <li>XIAO bootloader self-update (explicit only): selected XIAO-module QSPI repeater builds link the   ordinary application below <code>0xE0000</code>, reserving <code>0xE0000..0xEA000</code> as a 40 KiB internal scratch bank.   They accept a v3 bootloader package only through an exact manual MID pull. Ordinary <code>ota install</code>,   autofetch, autoinstall, and every application apply backend reject it. The operator then copies the   staged package's exact values from <code>ota bootloader</code> into   <code>ota bootloader install &lt;MID8&gt; &lt;HASH16&gt;</code>. The app repeats the strict v3 geometry, installed/candidate   identity, vectors, embedded CRC/capabilities, complete payload/image hashes, signature, and trusted-key   gates before writing <code>APRV</code>. GPREGRET <code>0x6B</code> plus GPREGRET2 <code>0x51</code> hands the QSPI package to OTAFIX.   <code>APRV</code> carries the app's authenticated and explicitly confirmed authorization decision; OTAFIX does not   repeat Ed25519/allowlist, Merkle, or typed operator confirmation. It independently rechecks the strict v3   structure, canonical identity/capabilities, vectors, payload SHA, embedded CRC, and scratch/copy hashes,   uses the scratch bank to preserve the running application while replacing <code>0xF4000..0xFE000</code>, and reports   boot-update results in GPREGRET2 <code>0xC0..0xCF</code>   (<code>0xC8</code> success). This mechanism cannot bootstrap a stock/older bootloader; install an ABI-3,   boot-update-capable exact-board OTAFIX over USB/BLE DFU or SWD once first.</li> <li>Internal-flash bootloader self-update (explicit only): curated nRF52840 lean repeater/bridge targets   without an OTA-owned SD/QSPI store share the normal bottom-aligned internal store below <code>0xED000</code>.   It holds either an ordinary app delta or the exact 41,330-byte v3 container, never both. The boot package   bottom-aligns at <code>0xE2000</code>; a hash-valid live <code>EndF</code> must prove the complete running image ends at or below   that address before the first erase. OTAFIX reads each source window before erasing and compacts the   payload forward in the same eleven pages to raw <code>0xE2000..0xEC000</code>; no separate scratch bank or special   application linker exists. GPREGRET <code>0x6B</code> plus GPREGRET2 <code>0xED</code> selects boot update, while ordinary app   apply uses GPREGRET <code>0x6A</code> plus the same storage source. Exact installed/candidate capability flags are   <code>0x0A</code> (<code>STAGE_CEILING|BOOT_UPDATE</code>). Ordinary deltas remain dynamically sized, may start below   <code>0xE2000</code>, and reconstruct only below the normal <code>0xED000</code> app ceiling. The same signature, explicit   confirmation, exact identity, vector, CRC, and single-marker rules as the XIAO path apply. Bootloader FULL   admission is isolated from ordinary application FULL policy, and privileged partials are never resumed   automatically after an application reboot. See   the nRF52 bootloader-update guide for the exact target inventory.</li> </ul> <p>A signature, when present, proves author authenticity and must pass the device allowlist. Unsigned v2 application packages remain installable when local policy permits them. A v3 bootloader package is always signed and trusted. The one-shot <code>approval</code> marker records local consent before the bootloader may apply it.</p> <p>Bootloader testing note: always test apply with a real different image (base != target). A same-image (X-&gt;X) \"delta\" trivially reproduces the target and gives a false positive.</p>"},{"location":"ota_protocol/#13-versioning-of-this-spec","title":"13. Versioning of this spec","text":"<p>The fixed byte layout has two intentionally disjoint profiles: <code>format_ver = 2</code> for ordinary application packages and <code>format_ver = 3</code> only for the exact privileged bootloader profile in Section 4.3. A parser must reject v2+BOOTLOADER, v3 without exact <code>FULL|SIGNED|BOOTLOADER</code>, and every other version. The multihash <code>hash_algo</code> separately allows swapping the digest family without a format bump. Unknown <code>codec_id</code> / <code>ota_msg_type</code> values are ignored (a node simply will not fetch what it cannot apply).</p>"},{"location":"ota_user_guide/","title":"Updating your node over the air (OTA) - user guide","text":"<p>This guide is for node operators: how to update your MeshCore device's firmware over the radio, in plain language. No cables, no programmer - your node can download a new firmware from a neighbour and install it. (For the technical wire format, see the OTA protocol spec.)</p> <p>LoRa OTA download and installation are present only in supported Keymind destination artifacts; the receiver must already be running one of those install-capable builds. Some internal-staging nRF52 targets use a lean <code>lora_ota_no_external_sensors</code> target, while matched external-QSPI boards can retain their normal full-sensor repeater features. Release filenames include an OTA marker, but capability must still be confirmed on the running device. A source can be an OTA-enabled infrastructure node or a source-only Full Companion backed by <code>motatool</code>. Intermediate repeaters do not need OTA-enabled firmware: current repeater builds transport OTA floods opaquely, subject to their normal forwarding filters, duplicate checks, and flood limits. OTA radio traffic is accepted, generated, and relayed only while <code>tempradio</code> is actually running on that node. Every source, receiver, and intermediate repeater must therefore have an overlapping temporary-radio window.</p> <p>The recommended temporary OTA settings use 250 kHz bandwidth, SF5, CR5, and a 120-minute window. For a North American node currently configured for 909.950 MHz, run this on every participating node:</p> <pre><code>tempradio 909.950,250,5,5,120\n</code></pre> <p>Use the node's current permitted regional frequency in place of <code>909.950</code> when necessary.</p> <p>The scripted updater checks the firmware version of the receiver and every sender before deciding whether RX power saving can remain active. At SF5/BW250, an all-v1.17.1.5-or-newer path can use effective RXPS level 8 with the tuple-selected 64-symbol physical preamble. SF5/BW500 can use level 8 with 128 symbols. Other fast tuples remain at the shortest viable preamble, normally 32. A mixed, older, or unknown long-preamble path is put in continuous receive for the update, then the receiver's exact saved RXPS setting is restored. This preserves the RX benefit without risking missed packets from a legacy 32-symbol sender.</p> <p>Can my node install the update? Choose a release-table artifact explicitly labelled LoRa-OTA capable, then confirm <code>ota self</code> and <code>ota status</code> expose install support; do not infer support from the filename alone. LoRa OTA firmware is available for supported ESP32 boards and nRF52 repeater targets. Every nRF52 installation also requires the OTAFIX bootloader built for that exact board; having an OTA-capable application image alone is not enough. An intermediate repeater only relays packets and needs neither an install-capable image nor OTAFIX. Check the bootloader release for an exact board match before attempting an update.</p> <p>The following nRF52 repeater families gained firmware-side LoRa OTA targets in this release. Their ordinary repeater keeps its complete declared sensor recipe; the install-capable <code>lora_ota_no_external_sensors</code> sibling is smaller:</p> <ul> <li>Heltec Mesh Solar, T1, and Tower V2</li> <li>Keepteen LT1, LilyGo T-Impulse Plus, Mesh Pocket, and Nano G2 Ultra</li> <li>Minewsemi ME25LS01, RAK3401, SenseCAP Solar, and Wio WM1110</li> </ul> <p>The RAK3401 <code>RAK_3401_repeater_lora_ota_no_external_sensors</code> image trims selected optional environmental/ranging drivers but does not disable I2C. It retains the INA219, INA226, INA260, and INA3221 voltage/current monitors, board display and RTC support, and both RAK12500 I2C and RAK12501/L76K UART GPS paths. The four INA drivers are only the retained voltage/current entries in the optional environmental-sensor table; they are not the only I2C users. The SSD1306 OLED, autodiscovered DS3231/RV3028/PCF8563/RX8130CE RTCs, and RAK12500 GPS use I2C as separate board peripherals. Install one GPS module in sensor slot A. Slot D's reset/PPS lines conflict with the RAK13302 radio's BUSY/DIO1 lines.</p> <p>The firmware-configured INA3221 address and the RAK12500 address are both <code>0x42</code>, so those devices cannot share one bus at those addresses. To install both, leave the RAK12500 at <code>0x42</code>, strap INA3221 A0 to SCL for <code>0x43</code>, and use a firmware build with <code>-DTELEM_INA3221_ADDRESS=0x43</code>.</p> <p>The reduced RAK4631 profiles likewise retain the four INA monitors. The plain repeater and Serial2 bridge retain GPS: a RAK12501 can use sensor slot A or D, and a RAK12500 can use slot A or C. The runtime RS-232 bridge defaults to Serial2 so the UART RAK12501 can retain Serial1. The merged runtime image always reserves Serial1: a bounded silent probe cannot prove that a cold RAK12501 is absent, and turning the GPS setting off cannot stop a fitted module from driving the shared UART while WB_IO2/3V3_S remains powered. Use Serial2. Serial1 requires an explicit no-GPS/dedicated image. The reservation remains fail-closed even when an I2C RAK12500 is detected. The explicitly compiled <code>RAK_4631_repeater_bridge_rs232_serial1_lora_ota_no_external_sensors</code> target omits the combined GPS provider because its bridge owns the UART used by RAK12501; consequently that legacy image does not expose the I2C RAK12500 path either, even though RAK12500 itself does not use the UART.</p> <p>Selected nRF52 repeaters with dedicated external QSPI can now stage the complete package off-chip, so their normal full-sensor repeater build can install a full image or an in-place delta. The current matched families are XIAO nRF52840 and its XIAO-module derivatives, original LilyGo T-Echo, ThinkNode M1/M6, Wio Tracker L1, SenseCAP Solar, and the dedicated RAK4631 + RAK15001 slot-C target. The list also includes a separately wired W25Q16JV on RAK19007 with either RAK4631 or RAK3401 + RAK13302. These require the corresponding exact QSPI-aware OTAFIX bootloader; see the nRF52 QSPI guide.</p> <p>The W25Q16 option uses one permanent RAK19007 wiring for either core: CLK/MISO/ MOSI tap IO-connector pins 26/27/28, flash CS uses J11 AIN1, and power uses J12 VDD (3.3 V) and GND. Add an approximately 10 kOhm CS-to-VDD pull-up and never power the flash from VBAT. The three SPI signals require underside pads or an IO-connector interposer; the easy J10/J11/J12 headers do not expose them. The flash consumes no WisBlock slot, so a supported GPS can remain in slot A.</p> <p>The ordinary full-sensor <code>RAK_4631_repeater</code> image remains too large for the safe internal in-place update limit. Without external flash, use <code>RAK_4631_repeater_lora_ota_no_external_sensors</code>; it trims selected optional environmental/ranging drivers while retaining generic I2C, battery monitoring, the four INA monitors, and target-compatible GPS. A RAK4631 fitted with RAK15001 in sensor slot C can instead use <code>RAK_4631_repeater_rak15001_slot_c_lora_ota</code> to retain the full sensor/GPS set and stage full images or deltas off-chip.</p> <p>For the external Winbond breakout, use <code>RAK_4631_repeater_w25q16_lora_ota</code> on RAK4631 or <code>RAK_3401_repeater_rak13302_w25q16_lora_ota</code> on RAK3401 + RAK13302. They retain the full sensor/GPS recipe and require exactly a 2 MiB <code>EF4015</code> W25Q16 plus the bootloader for that same core/radio/flash combination. Install <code>wiscore_rak4631_w25q16</code> for RAK4631 or <code>wiscore_rak3401_rak13302_w25q16</code> for RAK3401 + RAK13302 as a one-time prerequisite. The physical wiring is shared, but the two firmware identities are deliberately different and cannot be substituted for one another.</p>"},{"location":"ota_user_guide/#the-important-part-first-its-safe","title":"The important part first: it's safe","text":"<ul> <li>Nothing installs by itself. Your node can discover and download an update, but   it only installs when you say so (unless you deliberately turn on auto-install - see below).</li> <li>Bad downloads can't sneak in. Every piece of the firmware is checked against a cryptographic   fingerprint as it arrives, and the whole image is verified again before install. A corrupt or tampered   download is rejected, not installed.</li> <li>You choose who to trust. Updates can be signed by their author. You can tell your node to only   auto-install firmware signed by keys you've added.</li> <li>Discovery stays quiet; a transfer is deliberate. Periodic update discovery uses background priority.   Once a download starts, its transfer packets are primary traffic across every relay hop, so use   TempRadio as an OTA maintenance window when delaying unrelated mesh traffic would matter.</li> <li>It can recover. If an install ever fails, the node falls back to a safe recovery mode (you can   re-flash a known-good firmware over USB) - it won't be left bricked.</li> </ul>"},{"location":"ota_user_guide/#how-to-talk-to-your-node","title":"How to talk to your node","text":"<p>Connect to your node's console - usually a USB serial terminal at 115200 baud (or whatever tool you already use to manage the node). You type <code>ota ...</code> commands and the node replies in plain words.</p> <p>The commands have short, friendly names (and most accept aliases, so you don't have to remember exact spelling): type <code>ota help</code> any time to see the list, or just <code>ota</code> for a status summary.</p>"},{"location":"ota_user_guide/#common-tasks","title":"Common tasks","text":""},{"location":"ota_user_guide/#1-see-what-im-running-and-whether-anything-is-going-on","title":"1. See what I'm running and whether anything is going on","text":"<pre><code>ota status\n</code></pre> <p>Shows your current firmware version, your node's update \"target\" (its hardware/role id), and whether a download is in progress.</p> <p>For a denser admin view - your firmware's content id (<code>mid</code>) and its body hash, the fingerprint of the set you're serving, live download progress, and the current policy - use:</p> <pre><code>ota stats\n</code></pre> <p>On a remote node this is admin-only (the remote command console requires the admin password) - send it from the app's repeater command screen, or the WiFi/serial OTA console.</p>"},{"location":"ota_user_guide/#2-find-updates-available-near-me","title":"2. Find updates available near me","text":"<pre><code>ota ls\nota ls 2                 # page 2 when more than two updates are available\n</code></pre> <p>Your node asks around and lists the firmware updates other nodes nearby are offering, in plain words - each with a temporary number, a stable eight-hex manifest ID, its version, whether it's a full image or a small delta, how many nodes have it, and how recently it was seen. For example:</p> <pre><code>Updates 1/1 (2 src; refreshing):\n 1) 838B8169 v1.2.3 delta [same target] 3n 5s\n 2) BF0AB0C4 v1.2.0 full [unsupported] 1n 12s\n</code></pre> <p>Each row shows the version, full-vs-delta, whether it fits your node, how many nodes have it, and how long ago it was seen. The fit marker:</p> <ul> <li>[same target] - the advertised target ID matches this hardware-and-role build. Download and apply   still enforce codec, bootloader, signed hardware tag, base hash, and integrity checks.</li> <li>[unsupported] - the target may match, but this build or its bootloader cannot apply that codec. A common   example is the source node's self-served full image on an internal-staging nRF52, which needs an   in-place delta. A matched external-QSPI nRF52 can accept that full codec.</li> <li>[rescue] - an installable in-place nRF52 delta for the same target, but this running firmware has no   valid app-side EndF. It requires the explicit rescue download and install flow below.</li> <li>[name] - a different known board or role (for example <code>[ProMicro_companion_radio_usb]</code>). Don't install it.</li> <li>[?] - can't tell (a build with no target id set, e.g. a bare IDE build rather than a release build).</li> </ul> <p>Run it again after a few seconds - discovery happens in the background, so the list fills in. Nothing is downloaded yet; this is just looking around. <code>refreshing</code> means the command has just sent asynchronous catalog queries, so run it again even when an older row is already visible. Two updates fit in each remote CLI reply; use <code>ota ls 2</code>, <code>ota ls 3</code>, and so on for later pages. Catalog rows can change while replies arrive, so use the displayed manifest ID for scripts and important operations rather than a numeric position. (<code>ota neighbors</code> / <code>ota updates</code> also work.)</p>"},{"location":"ota_user_guide/#3-download-an-update","title":"3. Download an update","text":"<p>Pick one from the list by its stable manifest ID (a number also works for interactive use), and say where to put it:</p> <pre><code>ota pull 838B8169 flash            # stage it in this node's flash, to install here\nota pull 838B8169 folder           # capture it onto a connected motatool folder as &lt;id&gt;.mota\nota pull 838B8169 folder validate  # warm-start capture from a motatool --seed build (much faster; below)\n</code></pre> <p>The destination is required - <code>ota pull 838B8169</code> on its own just shows the choices. <code>flash</code> is always available (stage here, then <code>ota install</code>). <code>folder</code> appears only while a <code>motatool serve</code> link is attached (it shows the link, e.g. <code>folder: tcp 192.168.4.5</code>); it streams the firmware straight onto the host folder - nothing is staged on this node. That's how you grab an exact copy of another device's firmware off the mesh (to a <code>.mota</code> file) so you can later build a delta against firmware you don't otherwise have. (<code>ota get</code> is an alias.)</p> <p><code>validate</code> (warm-start, advanced). Capturing a full image over the radio is slow. If you have a similar build on the computer (e.g. a fresh recompile of the same firmware), run motatool with <code>--seed &lt;that.mota&gt;</code> and add <code>validate</code>: the node fetches just the target's block fingerprints, keeps every block your seed already matches, and pulls over the radio only the handful that actually differ - turning a ~30-minute capture into seconds. The result is still a byte-exact, verified copy of the target.</p> <p>Where the seed comes from: it is the <code>--seed &lt;file&gt;</code> you pass to <code>motatool serve</code> - not a file you drop into the capture (<code>--dir</code>) folder, which is only the destination and starts empty. There is exactly one configured seed. When you run <code>... folder validate</code>, the node asks motatool to begin the capture and motatool stamps that seed's payload into the fresh <code>.part</code> in the same step - so it is always the file you named, with no guessing. <code>validate</code> is the switch: a plain <code>folder</code> pull ignores any seed and fetches from scratch; re-running a <code>validate</code> pull re-begins fresh (it never resumes a stale partial). Nothing about the seed is trusted - every kept block is checked against the target's own fingerprints, so a mismatched or missing seed just means those blocks are fetched over the radio (correct result, only slower).</p> <p>The node fetches from one source as primary traffic, with bounded adaptive request flights. Every session probes with one manifest block, then clean flights grow <code>1 -&gt; 2 -&gt; 3 -&gt; 4</code> blocks on RAK3401 OTA builds. New application packages use 2 KiB blocks; deployed 1 KiB packages remain supported. All blocks in a flight share one request packet, and the receiver stays silent until the source/relays finish returning them. A recovery halves the next flight. Retry timing follows the active SF/BW airtime, duty budget, and path length, so faster settings recover sooner without a fixed one-second request colliding with a valid multi-hop response. Mesh repeaters carry the packets only while their temporary-radio windows are active. Check progress with <code>ota status</code>.</p> <p>If a <code>folder</code> pull loses its link mid-transfer, <code>ota status</code> shows paused - the host keeps the partial and the pull resumes (filling only what's missing) the moment you reconnect motatool; it never falls back to flash. To stop a download you no longer want:</p> <pre><code>ota cancel\n</code></pre> <p>For a download staged on the node, success means current firmware also invalidated the persistent flash/SD/QSPI copy; it reports an error if that media operation cannot be verified. For a <code>folder</code> capture, cancel only detaches the live session and retains the host partial so it can be resumed or removed on the host deliberately. On a MeshTower SD auto-archive capture, cancel also detaches the live archive session and retains its card partial for the archive service to resume later; use <code>ota cache off</code> to stop new archive captures.</p>"},{"location":"ota_user_guide/#4-install-a-downloaded-update","title":"4. Install a downloaded update","text":"<p>Once <code>ota status</code> shows the download is ready to install:</p> <pre><code>ota install\n</code></pre> <p>The node verifies the firmware one last time, and if everything checks out it installs it and reboots into the new version. If the check fails, it tells you why and does not install. Unsigned images normally install only through this explicit command. The MeshTower V2 SD target is stricter and requires an allowlisted signature even for a manual application install, because it authorizes removable-media bytes for the bootloader. A signed image whose signer is not in the device allowlist is rejected; trusted signed images can auto-install only when that policy is enabled and the signed version is strictly newer than the running hash-valid EndF version. Manual <code>ota install</code> remains the deliberate equal-version/rollback override.</p> <p>After it reboots, run <code>ota status</code> to confirm the new version.</p>"},{"location":"ota_user_guide/#updating-an-nrf52-bootloader-advanced-explicit-only","title":"Updating an nRF52 bootloader (advanced, explicit only)","text":"<p>This is available on specially marked no-external-flash nRF52840 lean repeater/bridge builds, on the legacy XIAO nRF52840/Sense raw-QSPI builds, and on the exact <code>Heltec_tower_v2_sdcard_repeater_lora_ota_no_external_sensors</code> microSD build, after a one-time exact-board ABI-3 OTAFIX installation over USB/BLE DFU or SWD. It is not the normal firmware update path. Check support first:</p> <pre><code>ota bootloader\n</code></pre> <p>The reply must show a CRC-valid installed identity plus ABI 3 and the exact storage/boot-update capability bits for that build (<code>0x09</code> for MeshTower V2 microSD, <code>0x0A</code> for the shared internal store, or <code>0x0E</code> for XIAO raw QSPI). A bootloader package appears as <code>bootloader</code> in <code>ota ls</code>. It is never downloaded or installed automatically, even if both OTA automation settings are enabled. Use its stable ID explicitly:</p> <pre><code>ota pull &lt;MID8&gt; flash\n# wait until ota status says this bootloader download is ready\nota bootloader\nota bootloader install &lt;MID8&gt; &lt;HASH16&gt;\n</code></pre> <p>Copy both confirmation values exactly from the second <code>ota bootloader</code> reply. Ordinary <code>ota install</code> deliberately refuses this package. The privileged command requires an exact 40 KiB candidate payload in the fixed 41,330-byte container, a valid exact embedded identity/CRC and vector table, continued boot-update support, required <code>BLM2</code>/<code>SOFT</code> continuity metadata at canonical raw-image offset <code>0x9FB4</code>, a boot version that exactly matches the package and is newer than installed BLM2, and a valid signature from a key already in <code>ota key</code>'s trusted allowlist. It preserves the running application while OTAFIX replaces itself; <code>blup:C8</code> in post-reboot <code>ota status</code> means success. Remote rollback is refused. Any node lacking this command or those capabilities must update its bootloader locally instead.</p> <p>On an internal-flash target, the package shares the ordinary store below <code>0xED000</code> and bottom-aligns at <code>0xE2000</code>; there is no separate reserved scratch bank. A valid live <code>EndF</code> must prove the current image ends at or below that address before any page is erased. If <code>EndF</code> is missing/corrupt or the app is too large, the pull is refused and local DFU/SWD is required. On the MeshTower V2 SD target, the application linker remains at <code>0xED000</code>, but bootloader replacement needs temporary scratch beginning at <code>0xE0000</code>. A hash-valid live <code>EndF</code> must therefore prove the complete current image ends by <code>0xE0000</code>. A CRC-bound boot-settings bank must cover that complete image while also ending by <code>0xE0000</code>. MeshCore binds both application and bootloader SD approval to purpose, exact raw geometry, and a normalized SHA-256 in a reset-retained <code>MOTASDA2</code> record. Boot updates also bind the exact authenticated signed image hash in the E0000 token. OTAFIX consumes the retained record before media access, so a later card change or power cycle fails instead of authorizing different bytes. MeshCore never claims or writes raw sector 1. Both application and bootloader OTA wait until a matching BLM2 bootloader has been provisioned locally; preview.12 requires USB/BLE DFU or SWD first. Larger applications can continue to use normal application mOTA; only bootloader self-update is refused. See the nRF52 bootloader-update guide for the complete target inventory, storage layouts, and safety contract.</p>"},{"location":"ota_user_guide/#5-if-something-goes-wrong","title":"5. If something goes wrong","text":"<ul> <li>A download that stalls or gets interrupted just resumes later. Use   <code>ota cancel</code> to durably discard device staging; a folder capture keeps its   host partial for a later resume.</li> <li>A legacy app-only internal-flash nRF52 that still runs but reports <code>no EndF</code> can use the pre-provisioned rescue path   if its physical EndF is intact and only app-side validation is failing. Fetch the exact <code>[rescue]</code>   in-place delta with an explicit acknowledgement, obtain its 16-hex-digit <code>base_hash</code> from the package   metadata, then run:</li> </ul> <p><code>text   ota pull &lt;mid8&gt; flash rescue   # wait for ota status to say ready to install   ota rescue install &lt;base_hash16&gt;</code></p> <p>This is not a force option. It refuses a normally valid EndF, a different package hash, hardware or   target mismatch, corrupt payload, and invalid/untrusted signatures. The bootloader independently hashes   the running app and rejects a wrong base before writing the app. If the physical EndF is absent or the   rescue commands were not already in the running firmware, recover over USB.   Release chains should put this command in their first bridge and keep it in every bridge after that.   The shared-internal bootloader-update builds are intentionally excluded:   without valid live <code>EndF</code>, they refuse every internal pull before erase   because their normal application can extend through <code>0xED000</code>. Recover one   of those builds over USB/BLE DFU or SWD. - If an install fails, the node won't boot a broken image - it lands in recovery mode:   - nRF52: it appears as a USB drive; drag a known-good firmware <code>.uf2</code> for that exact board onto it     to recover.   - ESP32: it keeps the previous firmware in the other slot and rolls back. - When in doubt, you can always re-flash over USB the normal way.</p>"},{"location":"ota_user_guide/#optional-let-it-update-automatically","title":"Optional: let it update automatically","text":"<p>By default your node only discovers updates - it won't download or install on its own. If you want more automation (e.g. for a remote node you can't easily reach), you can opt in. These settings are saved.</p> <pre><code>ota config autofetch any        # auto-DOWNLOAD any compatible update for this node (still won't install)\nota config autofetch signed     # auto-download only signed updates\nota config autofetch off        # back to manual (default)\n\nota config autoinstall trusted  # auto-INSTALL only a trusted signed version newer than the running EndF\nota config autoinstall off      # never auto-install (default)\n\nota config advert 1440          # re-advertise every N minutes while temp radio is running\nota config advert 0             # only advertise when a temp-radio window starts\n\nota config hops 3               # how far OTA travels: accept from / relay up to N repeater hops (default 3)\nota config hops 0               # only exchange OTA with directly-connected nodes (never relay)\n\nota config                      # show the current settings\n</code></pre> <p>These policies also govern automatic adoption of an interrupted staged download after reboot. <code>off</code> leaves it untouched, <code>signed</code> requires the stored manifest's signed flag, and automatic resume requires the stored target to match this node and its version to be newer than the running valid EndF. Reissuing an explicit <code>ota pull &lt;MID8&gt;</code> remains the deliberate override for an older or unsigned partial. For bring-up/debugging, <code>ota dev resume &lt;MID8&gt;</code> performs the same explicit MID-bound re-adoption without starting a new network fetch. After reboot it requires the MID; bare <code>ota dev resume</code> is accepted only while an active/requested session MID still exists, and malformed or missing identifiers are rejected.</p> <p>Recommended for most people: leave both off and update by hand. Use <code>autoinstall trusted</code> only once you've added the signer's key (next section) and you trust them to push updates unattended. Automatic admission and final apply both reject zero, equal, or older signed versions; a dishonest catalog version cannot bypass the manifest check. Use manual <code>ota pull</code> plus <code>ota install</code> for an intentional rollback.</p> <p>The MeshTower V2 SD OTA target has a separate, default-on archive policy. It saves all mOTAs it sees to the SD card so the repeater can seed them later; this does not install them and does not change the install-oriented <code>autofetch</code> default above. Use <code>ota cache</code> for status and <code>ota cache off</code> or <code>ota config cache off</code> to stop new archive captures. Already cached files remain available to peers. Manual <code>ota pull</code> commands take priority and an interrupted archive capture resumes later. See Preload many mOTAs from a computer for the required <code>/mota/&lt;manifest-id&gt;.mota</code> filenames and the complete TempRadio seeding workflow.</p>"},{"location":"ota_user_guide/#optional-only-trust-updates-from-specific-people","title":"Optional: only trust updates from specific people","text":"<p>If you'll use auto-install, tell your node which signing keys to trust. The firmware author shares their public key (a hex string); you add it:</p> <pre><code>ota key add &lt;public-key-hex&gt;    # trust this signer\nota key list                    # show trusted signers\nota key rm &lt;public-key-hex&gt;     # stop trusting one\n</code></pre> <p>Only strictly newer updates signed by a trusted key are eligible for auto-install. Manual <code>ota install</code> permits an unsigned package after all integrity, hardware, base, and bootloader checks pass, except on the MeshTower V2 removable-SD path where all application installs must be signed and allowlisted. A signed package whose signer is not in the device allowlist is rejected rather than silently treated as unsigned.</p>"},{"location":"ota_user_guide/#sharing-updates-with-others-advanced","title":"Sharing updates with others (advanced)","text":""},{"location":"ota_user_guide/#relay-a-folder-of-firmware-from-a-computer","title":"Relay a folder of firmware from a computer","text":"<p>If your node is connected to a computer (e.g. a gateway on a Raspberry Pi), it can hand out a whole folder of firmware files to the mesh - without storing them itself. Useful for seeding a new release to a remote area.</p> <ol> <li>Put the firmware files (<code>.mota</code> files - see below) in a folder on the computer.</li> <li>Install the helper tool once - the standalone <code>motatool</code> CLI (https://github.com/vk496/motatool) -    then point it at your node and the folder - over the node's USB serial, over WiFi if it is    an ESP32 WiFi companion or FULL ESP32 node, or over encrypted Bluetooth if it is an nRF52 Full Companion:    <code>git clone https://github.com/vk496/motatool &amp;&amp; cargo install --path ./motatool    # over USB serial:    motatool serve --dir ./my_firmware/ --serial /dev/ttyACM0 -v    # ...or over WiFi: the seeder is on dedicated TCP port 5001:    motatool serve --dir ./my_firmware/ --tcp 192.168.1.50:5001 -v    # ...or over paired BLE to an nRF52 Full Companion (protocol v14):    python3 tools/ble_mota/ble_mota_seeder.py \\      --device MeshCore-MyCompanion --dir ./my_firmware/</code>    It answers the node's requests; your node then advertises those updates to neighbours, who can    <code>ota get</code> them like any other. (A WiFi node prints its IP + seeder port to the serial log on connect.    Details: https://github.com/vk496/motatool.)</li> </ol> <p>Check the device's attach reply or run <code>ota folder</code>: <code>host=X/Y</code> means the firmware is advertising <code>X</code> of the <code>Y</code> valid entries reported by the host. Serve registries are deliberately RAM-bounded on smaller builds, and the node's own firmware also consumes a slot. If <code>X &lt; Y</code>, split the chain across seeders/folders or use a higher-capacity seeder; <code>motatool</code> saying that every file is valid does not mean every file fit on-device.</p> <p>To stop, just stop the daemon - over WiFi the node auto-detaches when the connection closes; over USB you can also run <code>ota folder off</code> on the node. <code>ota folder</code> on its own lists what your node is offering. On a FULL repeater or room server, run <code>start webconfig</code> first if WiFi is not already active. Other FULL roles with browser OTA support can use the <code>MeshCore-OTA</code> access point from <code>start ota</code> and connect to <code>192.168.4.1:5001</code>. Every LoRa participant still needs an overlapping <code>tempradio</code> window.</p>"},{"location":"ota_user_guide/#everyone-helps-share","title":"Everyone helps share","text":"<p>You don't have to be a gateway to help. Once any node finishes downloading an update, it automatically offers it to its neighbours too. So a new firmware spreads outward node-to-node, instead of everyone hammering the one node that had it first. Discovery remains background traffic; an actual transfer is primary traffic for the duration of its TempRadio maintenance window.</p>"},{"location":"ota_user_guide/#where-firmware-files-come-from","title":"Where firmware files come from","text":"<p>OTA distributes <code>.mota</code> files - a packaged, verifiable firmware image (full image or a small \"delta\" that only contains what changed). You get them by:</p> <ul> <li>Downloading a build. This fork publishes a rolling <code>dev-latest</code> release on GitHub with the   current firmware for many boards, each accompanied by a <code>.full.mota</code> and a tiny <code>.delta.mota</code>. Grab the   one for your board to test.</li> <li>Building your own with the <code>mota</code> packaging tool - see tools/mota/README.md   (this is for people distributing updates, not everyday operators).</li> </ul>"},{"location":"ota_user_guide/#quick-reference","title":"Quick reference","text":"I want to... Command List all commands <code>ota help</code> See my firmware + any download <code>ota status</code> (or just <code>ota</code>) Admin: ids/hashes + serving + policy <code>ota stats</code> (admin-only remotely) Find updates nearby <code>ota ls</code> Download a listed update for installation <code>ota get &lt;mid8&gt; flash</code> Cancel a download <code>ota cancel</code> Install a finished download <code>ota install</code> Recover app-side <code>no EndF</code> on a legacy app-only internal nRF52 <code>ota rescue install &lt;base_hash16&gt;</code> Turn on auto-download <code>ota config autofetch any</code> Turn on auto-install (trusted only) <code>ota config autoinstall trusted</code> Trust a signer <code>ota key add &lt;hex&gt;</code> Relay a folder (gateway) <code>ota folder on</code> + the seeder daemon List what I'm offering <code>ota folder</code> <p>(Older names still work too: <code>neighbors</code>/<code>updates</code> = <code>ls</code>, <code>pull</code> = <code>get</code>, <code>applydelta</code>/<code>apply</code> = <code>install</code>, <code>drop</code>/<code>stop</code> = <code>cancel</code>.)</p>"},{"location":"ota_user_guide/#a-few-terms","title":"A few terms","text":"<ul> <li>Firmware - the software running your node. Updating it can add features or fix bugs.</li> <li><code>.mota</code> - a packaged firmware update file, with built-in integrity checks.</li> <li>Target - your node's hardware + role identity. Your node only auto-fetches updates built for the   same target, so it won't grab firmware meant for a different board.</li> <li>Delta - a small update containing only the changes from your current firmware (faster to send than a   full image). Your node rebuilds the complete firmware from it and verifies the result before installing.</li> <li>Signed - the update carries the author's cryptographic signature, so you can verify who made it.</li> </ul> <p>For the full technical details (the file format and the radio protocol), see the OTA protocol spec.</p>"},{"location":"packet_format/","title":"Packet Format","text":"<p>This document describes the MeshCore packet format.</p> <ul> <li><code>0xYY</code> indicates <code>YY</code> in hex notation.</li> <li><code>0bYY</code> indicates <code>YY</code> in binary notation.</li> <li>Bit 0 indicates the bit furthest to the right: <code>0000000X</code></li> <li>Bit 7 indicates the bit furthest to the left: <code>X0000000</code></li> </ul>"},{"location":"packet_format/#version-1-packet-format","title":"Version 1 Packet Format","text":"<p>This is the current version-1 MeshCore wire packet structure. Older firmware may support only a subset of the path encodings and payload types described here.</p> <pre><code>[header][transport_codes(optional)][path_length][path][payload]\n</code></pre> <ul> <li>header - 1 byte<ul> <li>8-bit Format: <code>0bVVPPPPRR</code> - <code>V=Version</code> - <code>P=PayloadType</code> - <code>R=RouteType</code></li> <li>Bits 0-1 - 2-bits - Route Type<ul> <li><code>0x00</code>/<code>0b00</code> - <code>ROUTE_TYPE_TRANSPORT_FLOOD</code> - Flood Routing + Transport Codes</li> <li><code>0x01</code>/<code>0b01</code> - <code>ROUTE_TYPE_FLOOD</code> - Flood Routing</li> <li><code>0x02</code>/<code>0b10</code> - <code>ROUTE_TYPE_DIRECT</code> - Direct Routing</li> <li><code>0x03</code>/<code>0b11</code> - <code>ROUTE_TYPE_TRANSPORT_DIRECT</code> - Direct Routing + Transport Codes</li> </ul> </li> <li>Bits 2-5 - 4-bits - Payload Type<ul> <li><code>0x00</code>/<code>0b0000</code> - <code>PAYLOAD_TYPE_REQ</code> - Request (destination/source hashes + MAC)</li> <li><code>0x01</code>/<code>0b0001</code> - <code>PAYLOAD_TYPE_RESPONSE</code> - Response to <code>REQ</code> or <code>ANON_REQ</code></li> <li><code>0x02</code>/<code>0b0010</code> - <code>PAYLOAD_TYPE_TXT_MSG</code> - Plain text message</li> <li><code>0x03</code>/<code>0b0011</code> - <code>PAYLOAD_TYPE_ACK</code> - Acknowledgment</li> <li><code>0x04</code>/<code>0b0100</code> - <code>PAYLOAD_TYPE_ADVERT</code> - Node advertisement</li> <li><code>0x05</code>/<code>0b0101</code> - <code>PAYLOAD_TYPE_GRP_TXT</code> - Group text message (unverified)</li> <li><code>0x06</code>/<code>0b0110</code> - <code>PAYLOAD_TYPE_GRP_DATA</code> - Group datagram (unverified)</li> <li><code>0x07</code>/<code>0b0111</code> - <code>PAYLOAD_TYPE_ANON_REQ</code> - Anonymous request</li> <li><code>0x08</code>/<code>0b1000</code> - <code>PAYLOAD_TYPE_PATH</code> - Returned path</li> <li><code>0x09</code>/<code>0b1001</code> - <code>PAYLOAD_TYPE_TRACE</code> - Trace a path, collecting SNR for each hop</li> <li><code>0x0A</code>/<code>0b1010</code> - <code>PAYLOAD_TYPE_MULTIPART</code> - Packet is part of a sequence of packets</li> <li><code>0x0B</code>/<code>0b1011</code> - <code>PAYLOAD_TYPE_CONTROL</code> - Control packet data (unencrypted)</li> <li><code>0x0C</code>/<code>0b1100</code> - <code>PAYLOAD_TYPE_OTA</code> - OTA-over-LoRa firmware distribution</li> <li><code>0x0D</code>/<code>0b1101</code> - reserved</li> <li><code>0x0E</code>/<code>0b1110</code> - reserved</li> <li><code>0x0F</code>/<code>0b1111</code> - <code>PAYLOAD_TYPE_RAW_CUSTOM</code> - Custom packet (raw bytes, custom encryption)</li> </ul> </li> <li>Bits 6-7 - 2-bits - Payload Version<ul> <li><code>0x00</code>/<code>0b00</code> - v1 - 1-byte src/dest hashes, 2-byte MAC</li> <li><code>0x01</code>/<code>0b01</code> - v2 - Future version (e.g., 2-byte hashes, 4-byte MAC)</li> <li><code>0x02</code>/<code>0b10</code> - v3 - Future version</li> <li><code>0x03</code>/<code>0b11</code> - v4 - Future version</li> </ul> </li> </ul> </li> <li><code>transport_codes</code> - 4 bytes (optional)<ul> <li>Only present for <code>ROUTE_TYPE_TRANSPORT_FLOOD</code> and <code>ROUTE_TYPE_TRANSPORT_DIRECT</code></li> <li><code>transport_code_1</code> - 2 bytes - <code>uint16_t</code> - calculated from region scope</li> <li><code>transport_code_2</code> - 2 bytes - <code>uint16_t</code> - reserved</li> </ul> </li> <li><code>path_length</code> - 1 byte - Encoded path metadata<ul> <li>Bits 0-5 store path hash count / hop count (<code>0-63</code>)</li> <li>Bits 6-7 store path hash size minus 1<ul> <li><code>0b00</code>: 1-byte path hashes</li> <li><code>0b01</code>: 2-byte path hashes</li> <li><code>0b10</code>: 3-byte path hashes</li> <li><code>0b11</code>: reserved / unsupported</li> </ul> </li> </ul> </li> <li><code>path</code> - <code>hop_count * hash_size</code> bytes - Path to use for Direct Routing or flood path tracking<ul> <li>Up to a maximum of 64 bytes, defined by <code>MAX_PATH_SIZE</code></li> <li>Effective byte length is calculated from the encoded hop count and hash size, not taken directly from <code>path_length</code></li> <li>v1.12.0 firmware and older only handled legacy 1-byte path hashes and dropped packets whose path bytes exceeded 64 bytes</li> </ul> </li> <li><code>payload</code> - variable length - Payload Data<ul> <li>Up to a maximum 184 bytes, defined by <code>MAX_PACKET_PAYLOAD</code></li> <li>Generally this is the remainder of the raw packet data</li> <li>The firmware parses this data based on the provided Payload Type</li> <li>v1.12.0 firmware and older drops packets with <code>payload</code> sizes larger than 184</li> </ul> </li> </ul>"},{"location":"packet_format/#packet-format_1","title":"Packet Format","text":"Field Size (bytes) Description header 1 Contains routing type, payload type, and payload version transport_codes 4 (optional) 2x 16-bit transport codes (if ROUTE_TYPE_TRANSPORT_*) path_length 1 Encodes path hash size in bits 6-7 and hop count in bits 0-5 path up to 64 (<code>MAX_PATH_SIZE</code>) Stores <code>hop_count * hash_size</code> bytes of path data if applicable payload up to 184 (<code>MAX_PACKET_PAYLOAD</code>) Data for the provided Payload Type <p>NOTE: see the Payloads documentation for more information about the content of specific payload types.</p>"},{"location":"packet_format/#header-format","title":"Header Format","text":"<p>Bit 0 means the lowest bit (1s place)</p> Bits Mask Field Description 0-1 <code>0x03</code> Route Type Flood, Direct, etc 2-5 <code>0x3C</code> Payload Type Request, Response, ACK, etc 6-7 <code>0xC0</code> Payload Version Versioning of the payload format"},{"location":"packet_format/#route-types","title":"Route Types","text":"Value Name Description <code>0x00</code> <code>ROUTE_TYPE_TRANSPORT_FLOOD</code> Flood Routing + Transport Codes <code>0x01</code> <code>ROUTE_TYPE_FLOOD</code> Flood Routing <code>0x02</code> <code>ROUTE_TYPE_DIRECT</code> Direct Routing <code>0x03</code> <code>ROUTE_TYPE_TRANSPORT_DIRECT</code> Direct Routing + Transport Codes"},{"location":"packet_format/#path-length-encoding","title":"Path Length Encoding","text":"<p><code>path_length</code> is not a raw byte count. It packs both hash size and hop count:</p> Bits Field Meaning 0-5 Hop Count Number of path hashes (<code>0-63</code>) 6-7 Hash Size Code Stored as <code>hash_size - 1</code> <p>Hash size codes:</p> Bits 6-7 Hash Size Notes <code>0b00</code> 1 byte Legacy / default mode <code>0b01</code> 2 bytes Supported in current firmware <code>0b10</code> 3 bytes Supported in current firmware <code>0b11</code> 4 bytes Reserved / invalid <p>Examples:</p> <ul> <li><code>0x00</code>: zero-hop packet, no path bytes</li> <li><code>0x05</code>: 5 hops using 1-byte hashes, so path is 5 bytes</li> <li><code>0x45</code>: 5 hops using 2-byte hashes, so path is 10 bytes</li> <li><code>0x8A</code>: 10 hops using 3-byte hashes, so path is 30 bytes</li> </ul>"},{"location":"packet_format/#payload-types","title":"Payload Types","text":"Value Name Description <code>0x00</code> <code>PAYLOAD_TYPE_REQ</code> Request (destination/source hashes + MAC) <code>0x01</code> <code>PAYLOAD_TYPE_RESPONSE</code> Response to <code>REQ</code> or <code>ANON_REQ</code> <code>0x02</code> <code>PAYLOAD_TYPE_TXT_MSG</code> Plain text message <code>0x03</code> <code>PAYLOAD_TYPE_ACK</code> Acknowledgment <code>0x04</code> <code>PAYLOAD_TYPE_ADVERT</code> Node advertisement <code>0x05</code> <code>PAYLOAD_TYPE_GRP_TXT</code> Group text message (unverified) <code>0x06</code> <code>PAYLOAD_TYPE_GRP_DATA</code> Group datagram (unverified) <code>0x07</code> <code>PAYLOAD_TYPE_ANON_REQ</code> Anonymous request <code>0x08</code> <code>PAYLOAD_TYPE_PATH</code> Returned path <code>0x09</code> <code>PAYLOAD_TYPE_TRACE</code> Trace a path, collecting SNR for each hop <code>0x0A</code> <code>PAYLOAD_TYPE_MULTIPART</code> Packet is part of a sequence of packets <code>0x0B</code> <code>PAYLOAD_TYPE_CONTROL</code> Control packet data (unencrypted) <code>0x0C</code> <code>PAYLOAD_TYPE_OTA</code> OTA-over-LoRa firmware distribution <code>0x0D</code> reserved reserved <code>0x0E</code> reserved reserved <code>0x0F</code> <code>PAYLOAD_TYPE_RAW_CUSTOM</code> Custom packet (raw bytes, custom encryption)"},{"location":"packet_format/#payload-versions","title":"Payload Versions","text":"Value Version Description <code>0x00</code> 1 1-byte src/dest hashes, 2-byte MAC <code>0x01</code> 2 Future version (e.g., 2-byte hashes, 4-byte MAC) <code>0x02</code> 3 Future version <code>0x03</code> 4 Future version"},{"location":"payloads/","title":"Payload Format","text":"<p>Inside each MeshCore Packet is a payload, identified by the payload type in the packet header. The types of payloads are:</p> <ul> <li>Request, response, and plain text (<code>0x00</code>-<code>0x02</code>).</li> <li>Acknowledgment and node advertisement (<code>0x03</code>-<code>0x04</code>).</li> <li>Group text and group datagram (<code>0x05</code>-<code>0x06</code>).</li> <li>Anonymous request and returned path (<code>0x07</code>-<code>0x08</code>).</li> <li>Trace, multipart, control, and OTA (<code>0x09</code>-<code>0x0C</code>).</li> <li>Custom raw data (<code>0x0F</code>).</li> </ul> <p>This document describes the shared payload envelopes implemented by the core. Application-specific request, response, control, and custom bodies can add their own formats.</p> <p>NOTE: all 16 and 32-bit integer fields are Little Endian.</p>"},{"location":"payloads/#important-concepts","title":"Important concepts:","text":"<ul> <li>Node hash: the first byte of the node's public key</li> </ul>"},{"location":"payloads/#node-advertisement","title":"Node advertisement","text":"<p>This kind of payload notifies receivers that a node exists, and gives information about the node</p> Field Size (bytes) Description public key 32 Ed25519 public key of the node timestamp 4 unix timestamp of advertisement signature 64 Ed25519 signature of public key, timestamp, and app data appdata rest of payload optional, see below <p>Appdata</p> Field Size (bytes) Description flags 1 specifies which of the fields are present, see below latitude 4 (optional) decimal latitude multiplied by 1000000, integer longitude 4 (optional) decimal longitude multiplied by 1000000, integer feature 1 2  (optional) reserved for future use feature 2 2  (optional) reserved for future use name rest of appdata name of the node <p>Appdata Flags</p> Value Name Description <code>0x01</code> is chat node advert is for a chat node <code>0x02</code> is repeater advert is for a repeater <code>0x03</code> is room server advert is for a room server <code>0x04</code> is sensor advert is for a sensor server <code>0x10</code> has location appdata contains lat/long information <code>0x20</code> has feature 1 Reserved for future use. <code>0x40</code> has feature 2 Reserved for future use. <code>0x80</code> has name appdata contains a node name"},{"location":"payloads/#acknowledgement","title":"Acknowledgement","text":"<p>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 acknowledgement packet. Current <code>CLI_DATA</code> commands do not cause acknowledgement responses, neither discrete nor extra; their text reply is the application-level result. Repeaters still ACK the legacy plain-text form before processing it.</p> <p>Repeater remote CLI keeps one volatile copy of the most recently completed reply, keyed by the authenticated sender, request timestamp, and command text. Repeating that same logical request re-sends the text reply without executing the command again. A retry must therefore preserve the original timestamp and command text. The cache is cleared by reboot and replaced by the next completed remote command; commands that intentionally produce no text reply remain silent.</p> Field Size (bytes) Description checksum 4 CRC checksum of message timestamp, text, and sender pubkey"},{"location":"payloads/#returned-path-request-response-and-plain-text-message","title":"Returned path, request, response, and plain text message","text":"<p>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.</p> Field Size (bytes) Description destination hash 1 first byte of destination node public key source hash 1 first byte of source node public key cipher MAC 2 MAC for encrypted data in next field ciphertext rest of payload encrypted message, see subsections below for details"},{"location":"payloads/#returned-path","title":"Returned path","text":"<p>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.</p> Field Size (bytes) Description path descriptor 1 low 6 bits are the hash count; high 2 bits encode hash size minus one path count \u00d7 size encoded node-hash prefixes, each 1-3 bytes; the four-byte code is reserved extra type 1 low nibble is the bundled payload type, such as acknowledgment or response; high nibble is reserved extra rest of data extra, bundled payload content, follows same format as main content defined by this document"},{"location":"payloads/#request","title":"Request","text":"Field Size (bytes) Description timestamp 4 sender time (unix timestamp) request data rest of payload application-defined request payload body <p>For the common chat/server helpers in <code>BaseChatMesh</code>, the current request type values are:</p> Value Name Description <code>0x01</code> get stats get stats of repeater or room server <code>0x02</code> keepalive keep-alive request used for maintained connections"},{"location":"payloads/#get-stats","title":"Get stats","text":"<p>Gets information about the node, possibly including the following:</p> <ul> <li>Battery level (millivolts)</li> <li>Current transmit queue length</li> <li>Current free queue length</li> <li>Last RSSI value</li> <li>Number of received packets</li> <li>Number of sent packets</li> <li>Total airtime (seconds)</li> <li>Total uptime (seconds)</li> <li>Number of packets sent as flood</li> <li>Number of packets sent directly</li> <li>Number of packets received as flood</li> <li>Number of packets received directly</li> <li>Error flags</li> <li>Last SNR value</li> <li>Number of direct route duplicates</li> <li>Number of flood route duplicates</li> <li>Number posted (?)</li> <li>Number of post pushes (?)</li> </ul>"},{"location":"payloads/#get-telemetry-data","title":"Get telemetry data","text":"<p>Not defined in <code>BaseChatMesh</code>. Sensor- and application-specific request payloads may be implemented by higher-level firmware.</p>"},{"location":"payloads/#get-telemetry","title":"Get Telemetry","text":"<p>Not defined in <code>BaseChatMesh</code>.</p>"},{"location":"payloads/#get-minmaxave-sensor-nodes","title":"Get Min/Max/Ave  (Sensor nodes)","text":"<p>Not defined in <code>BaseChatMesh</code>.</p>"},{"location":"payloads/#get-access-list","title":"Get Access List","text":"<p>Not defined in <code>BaseChatMesh</code>.</p>"},{"location":"payloads/#get-neighbors","title":"Get Neighbors","text":"<p>Not defined in <code>BaseChatMesh</code>.</p>"},{"location":"payloads/#get-owner-info","title":"Get Owner Info","text":"<p>Not defined in <code>BaseChatMesh</code>.</p>"},{"location":"payloads/#response","title":"Response","text":"Field Size (bytes) Description content rest of payload application-defined response body <p>Response contents are opaque application data. There is no single generic response envelope beyond the encrypted payload wrapper shown above.</p>"},{"location":"payloads/#plain-text-message","title":"Plain text message","text":"Field Size (bytes) Description timestamp 4 send time (unix timestamp) txt_type + attempt 1 upper six bits are txt_type (see below), lower two bits are attempt number (0..3) message rest of payload the message content, see next table <p>txt_type</p> Value Description Message content <code>0x00</code> plain text message the plain text of the message <code>0x01</code> CLI data CLI command OR reply text <code>0x02</code> signed plain text message first four bytes is sender pubkey prefix, followed by plain text message <code>0x03</code> CLI command (since v1.18+) CLI command text (explicit) <p>For a room post, companion firmware uses its own monotonic clock for the on-air timestamp and preserves that timestamp across application retries. Room servers track post timestamps separately from login, request, and CLI traffic. They also remember recent accepted posts by sender, timestamp, and text: an exact retry is ACKed again without storing a duplicate, while stale or same-timestamp mismatches are rejected.</p>"},{"location":"payloads/#anonymous-request","title":"Anonymous request","text":"Field Size (bytes) Description destination hash 1 first byte of destination node public key public key 32 sender's Ed25519 public key cipher MAC 2 MAC for encrypted data in next field ciphertext rest of payload encrypted message, see below for details"},{"location":"payloads/#room-server-login","title":"Room server login","text":"Field Size (bytes) Description timestamp 4 sender time (unix timestamp) sync timestamp 4 sender's \"sync messages SINCE x\" timestamp password rest of message password for room"},{"location":"payloads/#repeatersensor-login","title":"Repeater/Sensor login","text":"Field Size (bytes) Description timestamp 4 sender time (unix timestamp) password rest of message password for repeater/sensor"},{"location":"payloads/#repeater-regions-request","title":"Repeater - Regions request","text":"Field Size (bytes) Description timestamp 4 sender time (unix timestamp) req type 1 0x01 (request sub type) reply path len 1 path len for reply reply path (variable) reply path"},{"location":"payloads/#repeater-owner-info-request","title":"Repeater - Owner info request","text":"Field Size (bytes) Description timestamp 4 sender time (unix timestamp) req type 1 0x02 (request sub type) reply path len 1 path len for reply reply path (variable) reply path"},{"location":"payloads/#repeater-clock-and-status-request","title":"Repeater - Clock and status request","text":"Field Size (bytes) Description timestamp 4 sender time (unix timestamp) req type 1 0x03 (request sub type) reply path len 1 path len for reply reply path (variable) reply path"},{"location":"payloads/#group-text-message","title":"Group text message","text":"Field Size (bytes) Description channel hash 1 first byte of SHA256 of channel's shared key cipher MAC 2 MAC for encrypted data in next field ciphertext rest of payload encrypted message, see below for details <p>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 <code>0x00</code> because it is a \"plain text message\". The message will be of the form <code>&lt;sender name&gt;: &lt;message body&gt;</code> (eg., <code>user123: I'm on my way</code>).</p> <p>The sender name is unverified message text. Group messages contain no sender signature, so any channel-key holder can choose any sender name.</p>"},{"location":"payloads/#group-datagram","title":"Group datagram","text":"Field Size (bytes) Description channel hash 1 first byte of SHA256 of channel's shared key cipher MAC 2 MAC for encrypted data in next field ciphertext rest of payload encrypted data, see below for details <p>The data contained in the ciphertext uses the format below:</p> Field Size (bytes) Description data type 2 Identifier for type of data. (See number_allocations.md) data len 1 byte length of data data rest of payload (depends on data type)"},{"location":"payloads/#control-data","title":"Control data","text":"Field Size (bytes) Description flags 1 upper 4 bits is sub_type data rest of payload typically unencrypted data"},{"location":"payloads/#discover_req-sub_type","title":"DISCOVER_REQ (sub_type)","text":"Field Size (bytes) Description flags 1 0x8 (upper 4 bits), prefix_only (lowest bit) type_filter 1 bit for each ADV_TYPE_* tag 4 randomly generate by sender since 4 (optional) epoch timestamp (0 by default)"},{"location":"payloads/#discover_resp-sub_type","title":"DISCOVER_RESP (sub_type)","text":"Field Size (bytes) Description flags 1 0x9 (upper 4 bits), node_type (lower 4) snr 1 signed, SNR*4 tag 4 reflected back from DISCOVER_REQ pubkey 8 or 32 node's ID (or prefix)"},{"location":"payloads/#trace","title":"Trace","text":"<p>Trace packets use direct routing. Their normal direct-path header is empty; instead, the intended route follows a fixed nine-byte trace header in the payload. Each forwarding node appends its received SNR multiplied by four to the packet's route-accumulator field.</p> Field Size (bytes) Description tag 4 Sender-selected trace identifier. auth code 4 Application-defined authentication/correlation value. flags 1 Low two bits encode the route hash size. Current senders use the legacy <code>1 &lt;&lt; value</code> interpretation (1, 2, 4, or 8 bytes); receivers also accept the packed 1-4-byte interpretation where it is unambiguous. route rest Concatenated node-hash prefixes for the requested direct route. <p>At the destination, the application receives the tag, auth code, flags, accumulated SNR bytes, and original route bytes. Trace therefore differs from a normal direct packet whose path is carried entirely in the packet route field.</p>"},{"location":"payloads/#multipart","title":"Multipart","text":"<p>The first payload byte identifies the inner payload and how many packets remain:</p> Field Size (bytes) Description remaining + type 1 Upper nibble is the remaining-packet count; lower nibble is the inner payload type. inner data rest Data for the inner payload type. <p>The core currently creates and consumes multipart acknowledgments. For that form, the low nibble is <code>0x03</code> and the next four bytes are the acknowledgment CRC. Other multipart inner types are reserved for application or future use.</p>"},{"location":"payloads/#ota","title":"OTA","text":"<p>An OTA payload contains one OTA protocol message and is normally sent by flood. Its message types, integrity fields, and transfer state are defined in the OTA-over-LoRa protocol. Builds without OTA support can still relay an opaque OTA packet when their routing policy permits it.</p>"},{"location":"payloads/#custom-packet","title":"Custom packet","text":"<p>Custom packets have no defined format.</p>"},{"location":"qr_codes/","title":"QR Codes","text":"<p>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.</p>"},{"location":"qr_codes/#add-channel","title":"Add Channel","text":"<p>Example URL:</p> <pre><code>meshcore://channel/add?name=Public&amp;secret=8b3387e9c5cdea6ac9e5edbaa115cd72\n</code></pre> <p>Parameters:</p> <ul> <li><code>name</code>: Channel name (URL-encoded)</li> <li><code>secret</code>: 16-byte secret represented as 32 hex characters</li> <li><code>region_scope</code>: Region Scope (optional, URL-encoded if provided)<ul> <li>Supported by MeshCore App v1.47.0+</li> </ul> </li> </ul>"},{"location":"qr_codes/#add-contact","title":"Add Contact","text":"<p>Example URL:</p> <pre><code>meshcore://contact/add?name=Example+Contact&amp;public_key=9cd8fcf22a47333b591d96a2b848b73f457b1bb1a3ea2453a885f9e5787765b1&amp;type=1\n</code></pre> <p>Parameters:</p> <ul> <li><code>name</code>: Contact name (URL-encoded if needed)</li> <li><code>public_key</code>: 32-byte public key represented as 64 hex characters</li> <li><code>type</code>: numeric contact type<ul> <li><code>1</code>: Companion</li> <li><code>2</code>: Repeater</li> <li><code>3</code>: Room Server</li> <li><code>4</code>: Sensor</li> </ul> </li> </ul>"},{"location":"rak3401_mota_chain/","title":"RAK3401 1W repeater compact LoRa update chain","text":"<p>Status: published prerelease for controlled, recoverable lab use. On 29-Aug-2026 steps 1-9 completed on the target RAK3401 and are byte-for-byte identical to the corresponding transitions in the physically passed <code>fd98bc90</code> chain. The replacement step 10 installs the current <code>3f6eddd5</code> endpoint. That replacement package and the hardened current runner have passed offline reconstruction plus the exact deployed bootloader simulator, but have not had a new physical end-to-end run. Use the lab gate and keep local DFU/SWD recovery available. Multi-hop and alternate-bandwidth estimates remain planning data, not physical qualification.</p> <p>The prerelease is <code>rak3401-mota-v1.16.07-c1caa5ad-to-v1.17.1.6-3f6eddd5</code>. Use this asset:</p> <pre><code>RAK3401-update-chain-v1.16.7-c1caa5ad-to-v1.17.1.6-3f6eddd5.zip\n</code></pre> <ul> <li>prerelease ZIP SHA-256: <code>135783dd8777490db2422a7543f7d80e3cf03f621d5ac362da930abbc1850dc4</code></li> <li>inner <code>SHA256SUMS.txt</code> SHA-256: <code>93835ed497c579be0a2322292e7f15ab095e7c8ab7892833fe7df3130dbdaba4</code></li> <li>endpoint image SHA-256: <code>cd1e9b819f9e918f9f2ceaf37b8a74bf242e2be78f319af2cf02a42d7729d0f4</code></li> <li>endpoint EndF body hash: <code>9BD7CF682EE065AE</code></li> </ul> <p><code>--verify-only</code> remains the safe default. Live preflight and installation of this prerelease require <code>--accept-test-candidate</code>. That switch bypasses only the prerelease-status gate; it does not bypass the archive, identity, bootloader, route, watchdog, reachability, or post-boot checks.</p>"},{"location":"rak3401_mota_chain/#exact-destination","title":"Exact destination","text":"<p>This chain is intentionally specific to one firmware lineage and hardware target:</p> <ul> <li>target ID: <code>2FA509C1</code></li> <li>hardware: <code>RAK_3401</code></li> <li>role: <code>RAK_3401_repeater_lora_ota_no_external_sensors</code></li> <li>start: <code>v1.16.7.0-c1caa5ad</code>, EndF <code>71F4026CBE4B8B74</code></li> <li>endpoint source: MeshCore <code>3f6eddd5c20f1fa3df6ba1cc208efbe3e2fffb43</code></li> <li>endpoint label: <code>v1.17.1.6-halo-keymind-cascade-dev-3f6eddd5</code></li> <li>endpoint packed version: <code>0x01110106</code></li> <li>deployment target key: <code>63d8df6387eaffd2e25db7d2a8ad967a65202182a48d681d7e7a9260f917280d</code></li> </ul> <p>The exact starting application is the <code>lora-ota-v1.16.07-halo-keymind-cascade-dev-3a6af3bf</code> RAK3401 asset. Its outer ZIP SHA-256 is <code>58ead2ea18efafda186bc9d983fe08cdf65f69b0e5a3a1c72c18fe35948a254c</code>; its 566,912-byte <code>firmware.bin</code> SHA-256 is <code>4301fc63ebd661c70f9bc40e7eca44d3cb8a358cb3c0075e700d9676a57478cb</code>. The endpoint build ZIP SHA-256 is <code>a9fca9be145a96feb650b57c43b5ed173d74d2f3194da12e31b1c54352635b56</code>.</p>"},{"location":"rak3401_mota_chain/#retained-and-omitted-hardware-support","title":"Retained and omitted hardware support","text":"<p>Despite the legacy <code>no_external_sensors</code> target name, the endpoint retains the RAK12501 GPS provider and the common INA3221, INA219, INA226, and INA260 I2C voltage/current monitors. Install RAK12501 in sensor slot A. Do not use slot D with the RAK13302 1 W radio because the GPS reset/PPS signals overlap the radio's BUSY/DIO1 wiring.</p> <p>The reduced profile omits optional external environmental and ranging devices: AHTX0, BME280, BMP280, SHTC3, SHT4x, LPS22HB, MLX90614, VL53L0X, BME680, BMP085, RAK12035, and BME680 BSEC. Board radio, display, buttons, battery telemetry, GPS, and the INA monitor family remain. No additional \u201cremove I2C temperature\u201d image is needed: the optional I2C temperature/environment drivers are already in the omitted set, while removing the remaining I2C/INA support would discard desired voltage/current monitoring and create another firmware identity without helping this route.</p> <p>Do not use the chain on another target ID, hardware family, starting image, or firmware body hash. The runner checks all four.</p>"},{"location":"rak3401_mota_chain/#why-the-deployed-otafix24-and-old-staging-ceiling-work","title":"Why the deployed OTAFIX2.4 and old staging ceiling work","text":"<p>The deployed bootloader is not changed and no package uses the newer expanded <code>0xED000</code> ceiling. Each package remains bottom-aligned below the old bootloader's <code>0xD4000</code> scan ceiling. Its detools workspace is page-aligned and must satisfy:</p> <pre><code>0x26000 + inplace_memory &lt;= staged_package_start &lt; 0xD4000\n</code></pre> <p>The old bootloader already reads and validates that encoded detools geometry before its first destructive write. The previous application receiver was the limiting part: it reserved a fixed <code>0x98000</code> workspace before accepting a download. Step 1 therefore remains byte-for-byte identical to the physically passed 89,844-byte package. Step 2 is a 46,364-byte fixed-workspace package that installs the compatibility receiver. Later receivers stage above the real EndF image extent and let the bootloader enforce each package's selected workspace.</p> <p>Every package in this candidate is an ordinary application container using format ABI 2 and in-place codec 2. The historical bridge applications scan the bootloader capability marker byte-by-byte, so they recognize the released <code>0.9.2-OTAFIX2.4</code> marker at absolute address <code>0xFCD16</code>. That immutable marker advertises ABI 2, codec mask <code>0x0004</code>, and internal storage profile 0. The <code>3f6eddd5</code> endpoint retains the matching legacy application-update fallback. Its separately compiled internal bootloader-update feature remains unavailable because privileged self-update requires a current ABI 3 marker with the exact storage profile. Installing this chain therefore does not replace the bootloader, and the final application can still accept a future valid ABI-2/codec-2 application update.</p> <p>The exact installed bootloader is the <code>0.9.2-OTAFIX2.4</code> RAK4631 asset. Its outer ZIP SHA-256 is <code>5e29e7a8982cc2ed5f8868435556eb09387250fe5b9a7e8443bac325247dfed1</code>; its 191,040-byte <code>sd_bl.bin</code> SHA-256 is <code>a97f834388db0f1da6c29f6d8f458ff6d3e6a26034709044566384838919bb23</code>. The exact simulator was compiled from release commit <code>d73de8372e89b8ef352747c8bc7a1aaeab80fbfe</code>; its executable SHA-256 is <code>9dacf24b1023fe2f4c620419417649ccc9538dd4a611b47bc19b7fedb97ceba6</code>.</p> <p>The schema-2 exhaustive search checked 1,799 candidate geometries and found 12 feasible forward edges in the declared exact 12-node inventory. It found one shortest ten-package route and selected the smallest total container bytes as the secondary objective. This minimum applies only to that declared inventory and geometry table, not every conceivable new bridge image. The selected route is:</p> Step From To Workspace Package Margin 1 1.16.7.0 1.16.7.9 <code>0x98000</code> 89,844 0 2 1.16.7.9 1.16.7.10 <code>0x98000</code> 46,364 40,960 3 1.16.7.10 1.16.8.7 <code>0x91000</code> 106,029 12,288 4 1.16.8.7 1.16.9.105 <code>0x89000</code> 149,927 0 5 1.16.9.105 1.16.9.110 <code>0x8E000</code> 111,312 16,384 6 1.16.9.110 1.16.9.113 <code>0x8F000</code> 120,624 4,096 7 1.16.9.113 1.16.9.117 <code>0x8B000</code> 139,637 0 8 1.16.9.117 1.16.10.0 <code>0x7E000</code> 174,202 20,480 9 1.16.10.0 1.17.1.3 <code>0x6B000</code> 271,569 0 10 1.17.1.3 1.17.1.6 <code>0x76000</code> 197,825 28,672 <p>Total mOTA transfer data is 1,407,333 bytes. <code>ROUTE.json</code>, <code>CHAIN.csv</code>, and <code>validation-results.json</code> in the bundle pin the exact geometry and image hash for every transition.</p> <p>Steps 1-9 are byte-for-byte identical to the transitions that passed on the physical RAK3401. The replacement step 10, from the physically reached <code>FE65A6135A1E7B3F</code> v1.17.1.3 body to <code>9BD7CF682EE065AE</code>, has offline qualification only. All ten packages passed independent container checks, zero-filled and erased-workspace reconstruction, and the exact deployed <code>0.9.2-OTAFIX2.4</code> simulator. Those results prove the package bytes and apply geometry; they are not a physical claim for the replacement step 10 or the hardened runner.</p> <p>The 171-byte transport DEFLATE support lands only in the final <code>3f6eddd5</code> application. The starting receiver and every receiver that accepts steps 1-10 lack that inflate path, so all ten legacy-chain transfers remain raw and the 1,407,333-byte total above is not automatically reduced over LoRa. A later update can negotiate transport compression after this endpoint is running; the application inflates before staging, and the immutable bootloader still applies an ordinary ABI-2/codec-2 container.</p>"},{"location":"rak3401_mota_chain/#host-requirements","title":"Host requirements","text":"<p>Install Python 3.9 or newer, <code>meshcli</code> 1.6.0 or newer, the current <code>motatool</code>, and an OTA-enabled Full Companion or repeater that can seed mOTA files.</p>"},{"location":"rak3401_mota_chain/#verify-offline","title":"Verify offline","text":"<p>No password or device is needed:</p> <pre><code>python3 tools/lora_ota/rak3401_mota_chain.py \\\n  --bundle /path/to/RAK3401-update-chain-v1.16.7-c1caa5ad-to-v1.17.1.6-3f6eddd5.zip \\\n  --work-dir ./rak3401-mota-chain-work \\\n  --motatool /path/to/motatool \\\n  --verify-only\n</code></pre> <p>When given the ZIP, the runner checks its pinned outer hash and binds the extraction cache to that exact archive. An explicitly supplied extracted root starts at the pinned inner checksum list. In either case it checks complete inner coverage, all ten manifests, continuity, image anchors, both recovery images, and every container with <code>motatool</code>. Passing this command means offline and simulator qualification only; it does not unlock live use.</p>"},{"location":"rak3401_mota_chain/#guarded-prerelease-lab-command","title":"Guarded prerelease lab command","text":"<p>These direct-link arguments match the physical transition setup, but the current package replaces step 10 and the current host runner contains later cleanup and recovery fixes. Neither has been cleanly rerun through the whole chain. Keep local USB/SWD recovery available. The candidate switch bypasses only the prerelease-status block; all identity, checksum, bootloader, route, watchdog, reachability, and post-boot gates still run.</p> <p>Restore the test start locally with <code>recovery/test-start/RAK3401-test-start-v1.16.7-c1caa5ad.uf2</code>, then run:</p> <pre><code>export MESHCORE_ADMIN_PASSWORD='password'\n\npython3 tools/lora_ota/rak3401_mota_chain.py \\\n  --bundle /path/to/RAK3401-update-chain-v1.16.7-c1caa5ad-to-v1.17.1.6-3f6eddd5.zip \\\n  --work-dir ./rak3401-mota-chain-work \\\n  --controller-serial /dev/ttyACM0 \\\n  --source-tcp 192.168.1.51:5001 \\\n  --source-cli-tcp 192.168.1.51:5002 \\\n  --source-shares-controller \\\n  --target-key 63d8df63 \\\n  --temp-radio 909.950,500,5,5,120 \\\n  --ota-hops 0 \\\n  --legacy-full-airtime \\\n  --motatool /path/to/motatool \\\n  --accept-test-candidate \\\n  --yes\n</code></pre> <p>Keep the work directory. Rerunning the same command resumes only when the live EndF body hash matches an exact chain node. Never manually skip a package. <code>--legacy-full-airtime</code> temporarily sets the destination airtime factor to zero and restores it at the endpoint. Use that option only where the selected frequency and local duty-cycle rules permit a full transmit budget; omit it otherwise.</p>"},{"location":"rak3401_mota_chain/#superseded-b40d2e6c-prerelease","title":"Superseded <code>b40d2e6c</code> prerelease","text":"<p>The immediately preceding prerelease remains pinned for offline provenance:</p> <ul> <li>release: <code>rak3401-mota-v1.16.07-c1caa5ad-to-v1.17.1.5-b40d2e6c</code></li> <li>asset: <code>RAK3401-update-chain-v1.16.7-c1caa5ad-to-v1.17.1.5-b40d2e6c.zip</code></li> <li>outer ZIP SHA-256: <code>8e7f0c2565f37d4372fa51dc3ba72b591e7f38b74be09303e48641623f99bce4</code></li> <li>inner <code>SHA256SUMS.txt</code> SHA-256: <code>29a02a6c4c83eafa80168a80562b0ded5d8432e6cc02cfaca289cb2ed426681a</code></li> <li>endpoint image SHA-256: <code>a7761da8af1f2447d7f01d72e2b1456b99c0e874a165d6483f48ab1f58e8d905</code></li> <li>endpoint EndF body hash: <code>1FA6AAA3C28D8BD8</code></li> </ul> <p>Its first nine packages are byte-for-byte identical to the current release and the physical <code>fd98bc90</code> evidence. Its different step 10 had offline qualification only. The runner recognizes this exact archive separately and keeps live use gated; it is not interchangeable with the current <code>3f6eddd5</code> asset.</p>"},{"location":"rak3401_mota_chain/#legacy-fd98bc90-physical-and-swd-qualification","title":"Legacy <code>fd98bc90</code> physical and SWD qualification","text":"<p>The earlier local candidate remains the exact physical evidence source for this route:</p> <pre><code>RAK3401-update-chain-v1.16.7-c1caa5ad-to-v1.17.1.5-fd98bc90.zip\n</code></pre> <ul> <li>candidate ZIP SHA-256: <code>c0b33f4568985e8b2b8dc99411295907212cf2bad21764b6333d5e0ba298fd61</code></li> <li>inner <code>SHA256SUMS.txt</code> SHA-256: <code>3f8c4af8096b96a4aa6506825c387cc8a06f74d5213a29c9387bd11689546881</code></li> <li>endpoint image SHA-256: <code>31c182c888ceb1135e5afb2376610d93cee2e807b556c838e07fd4486c79d095</code></li> <li>endpoint EndF body hash: <code>9179B98432895924</code></li> </ul> <p>All ten exact <code>fd98bc90</code> transitions completed on the RAK3401 with its deployed <code>0.9.2-OTAFIX2.4</code> bootloader and a Heltec V4 source at 909.950 MHz / 500 kHz / SF5 / CR5. Every intermediate EndF hash matched. Independent SWD readback then matched the endpoint application, original bootloader, SoftDevice/MBR, and UICR byte-for-byte. Steps 1-9 are also the exact first nine packages in the <code>b40d2e6c</code> and <code>3f6eddd5</code> prereleases. All three candidates have different step 10 packages or endpoints, so the physical result and step-10 timing must not be attributed to either later prerelease.</p>"},{"location":"rak3401_mota_chain/#measured-direct-link-timing-for-fd98bc90","title":"Measured direct-link timing for <code>fd98bc90</code>","text":"<p>The first <code>ready to install</code> transfer ages were:</p> Step Blocks Transfer 1 88 598 s 2 45 42 s 3 103 81 s 4 146 105 s 5 109 76 s 6 118 94 s 7 136 102 s 8 170 127 s 9 264 187 s 10 169 193 s <p>The physically observed bulk-transfer total for those exact legacy packages is 1,605 seconds (26m45s). The log came from the pre-cleanup-fix runner revision. Step 1 was measured before the host began forcing source RXPS off and is therefore a conservative outlier. A new complete run with that fix is projected at roughly 18\u201319 minutes of bulk transfer, but that projection is not a substitute for the measured total. Allow about 70\u201375 minutes direct at BW500 for validation, ten transfers, installs/reboots, retained-store checks, and final restoration.</p> <p>The legacy step 10's longer per-block time was not a V4 TempRadio delay: the source RXPS readback was off. Its v1.17.1.3 requester uses non-overlapping adaptive flights and a five-second recovery floor and logged more block reloads than step 8. The V4 itself intentionally schedules its local radio handoff after 1.5 seconds so the normal-channel command reply can drain; the host waits three seconds and then checks the live TempRadio state.</p>"},{"location":"rak3401_mota_chain/#live-progress-and-speed-sanity-checks","title":"Live progress and speed sanity checks","text":"<p>The runner watches <code>motatool serve -v</code> locally, so its quarter-progress reports do not consume LoRa airtime. At BW500 direct, physically measured steps 2\u20139 averaged about 1.1\u20131.4 newly requested payload blocks per second; the legacy step 10 averaged about 0.88 blocks/s, and step 1's 0.15 blocks/s was the known pre-RXPS-fix outlier. Use those only as bench sanity ranges, not guarantees. Relays, narrower bandwidths, interference, and recovery reads lower the rate.</p> <p>Healthy output keeps advancing from <code>[download] passive source progress x/y</code> to <code>source read all y payload blocks</code>, followed by destination status <code>ready to install y/y (100%)</code> for the same manifest ID. Aggregate reads above the unique block count indicate recovery/retry traffic. A radio-scaled no-progress window causes one destination status check; the transfer timeout leaves the partial download staged for an exact-package resume. Stop and diagnose instead of installing if the manifest changes, progress remains flat through those checks, the final receiver count is not <code>y/y</code>, or the measured rate is far below the matching bandwidth/hop estimate without an understood RF cause.</p> <p>For planning only, scale the conservative measured <code>fd98bc90</code> 26m45s bulk baseline by the qualified adaptive-preamble airtime and by each additional relay transmission:</p> Bandwidth, SF5/CR5 Direct / 0 relays 1 relay 2 relays 500 kHz 26m45s 53m30s 1h20m15s 250 kHz 46m51s 1h33m42s 2h20m33s 125 kHz 1h27m03s 2h54m07s 4h21m11s 62.5 kHz 2h54m07s 5h48m15s 8h42m23s <p>These are transfer-only estimates, not measured alternate-bandwidth or relay results. Packet loss, relay contention, discovery, administrative commands, staged verification, and ten reboot cycles add time. The bandwidth factors are not simple powers of two because the adaptive wire preamble is 128 symbols at 500 kHz, 64 at 250 kHz, and 32 at 125/62.5 kHz.</p>"},{"location":"rak3401_mota_chain/#manual-operation","title":"Manual operation","text":"<p>The automated runner is preferred because it binds every transition to the expected MID and body hash. The manual details below document the checks used during qualification and recovery; they are not permission to skip the runner's candidate gate. Keep a written copy of each original setting and never skip a step even when a later package appears in <code>ota ls</code>.</p>"},{"location":"rak3401_mota_chain/#1-verify-and-extract-the-asset","title":"1. Verify and extract the asset","text":"<pre><code>sha256sum RAK3401-update-chain-v1.16.7-c1caa5ad-to-v1.17.1.6-3f6eddd5.zip\nunzip RAK3401-update-chain-v1.16.7-c1caa5ad-to-v1.17.1.6-3f6eddd5.zip\ncd RAK3401-update-chain-v1.16.7-c1caa5ad-to-v1.17.1.6-3f6eddd5\nsha256sum -c SHA256SUMS.txt\nfor package in motas/*.mota; do motatool verify \"$package\" || exit 1; done\n</code></pre> <p>The outer hash must be <code>135783dd8777490db2422a7543f7d80e3cf03f621d5ac362da930abbc1850dc4</code>, and the SHA-256 of the extracted <code>SHA256SUMS.txt</code> must be <code>93835ed497c579be0a2322292e7f15ab095e7c8ab7892833fe7df3130dbdaba4</code>. Do not continue after any checksum or verification error.</p>"},{"location":"rak3401_mota_chain/#2-record-and-prepare-the-destination","title":"2. Record and prepare the destination","text":"<p>Before changing anything, save the complete replies from:</p> <pre><code>ver\nota self\nget bootloader.ver\nget system.watchdog\nget radio.rxps\npowersaving\nget rxdelay\nget af\nota config\n</code></pre> <p>The starting <code>ota self</code> hash must be <code>71F4026CBE4B8B74</code>, the target must be <code>2FA509C1</code>, and the hardware must be <code>RAK_3401</code>. Disable the nRF52 system watchdog before the chain:</p> <pre><code>set system.watchdog off\n</code></pre> <p>The hardware watchdog cannot stop immediately. The RAK will reset once within about 60 seconds. Reconnect, wait at least 90 seconds from the command, and require <code>get system.watchdog</code> to report <code>&gt; off</code> before continuing.</p> <p>For a direct bench link, apply these temporary transfer guardrails to the RAK after every bridge reboot:</p> <pre><code>powersaving off\nset radio.rxps off\nset rxdelay 0\nota config hops 0\ntempradio 909.950,500,5,5,120\n</code></pre> <p>Where local duty-cycle rules permit it, <code>set af 0</code> can also remove the legacy firmware's saved airtime wait during this bounded maintenance window. Record <code>get af</code> first and restore that exact value after the final step. Current firmware grants the bounded TempRadio transfer budget without overwriting the saved airtime factor.</p> <p><code>powersaving off</code> is an isolation guardrail, not the fix for the observed failure. The actual source failure was an oversized USB CDC reply; current firmware splits those reads. Some historical bridge builds may report RXPS as unsupported while already operating continuously. Verify the reported state and do not substitute a normal reboot for the one-time watchdog reset. Direct tests use <code>hops 0</code>: <code>hops 1</code> makes the target echo each source response despite there being no intermediate relay, increasing half-duplex loss and legacy three-second retries.</p> <p>The exact candidate cannot use fast RXPS throughout because its historical bridge applications predate the v1.17.1.5 adaptive-preamble contract. Keep RXPS off for all ten steps whether using SF5/BW250 or the faster direct-bench SF5/BW500 tuple. After the final endpoint is proven, a later update whose target, controller, source, and relays are all v1.17.1.5 or newer can use the generic LoRa OTA runner and its qualified adaptive-preamble boundaries.</p> <p>Put the source on the identical TempRadio tuple. A current ASCII-first Full Companion recognizes <code>motatool</code>'s initial <code>ota folder on</code> line directly:</p> <pre><code>motatool serve \\\n  --dir ./motas \\\n  --serial /dev/ttyACM1 \\\n  --baud 115200 \\\n  -v\n</code></pre> <p>The same command also works with older Full Companion firmware in binary mode, where the idle parser recognizes the identical preamble. Restart <code>motatool</code> for every step so the source emits a fresh catalog advert. Leave it running during the download and stop it with Ctrl-C only after the destination reports <code>ready to install</code>.</p>"},{"location":"rak3401_mota_chain/#3-install-all-ten-packages-in-order","title":"3. Install all ten packages in order","text":"Step Manifest ID Before hash Expected version After hash 1 <code>C147BCEF</code> <code>71F4026CBE4B8B74</code> <code>1.16.7.9</code> <code>42BC53A64288E845</code> 2 <code>BEB578FC</code> <code>42BC53A64288E845</code> <code>1.16.7.10</code> <code>1AD2AA8B6C478DA6</code> 3 <code>6D8EF814</code> <code>1AD2AA8B6C478DA6</code> <code>1.16.8.7</code> <code>D709A25308BC1831</code> 4 <code>40AC4CEB</code> <code>D709A25308BC1831</code> <code>1.16.9.105</code> <code>457BEDA5E6406C81</code> 5 <code>F6C8890B</code> <code>457BEDA5E6406C81</code> <code>1.16.9.110</code> <code>E76BFA205634CAB8</code> 6 <code>82405E89</code> <code>E76BFA205634CAB8</code> <code>1.16.9.113</code> <code>65328FC8A1FBED2D</code> 7 <code>80F40DB6</code> <code>65328FC8A1FBED2D</code> <code>1.16.9.117</code> <code>AF7532E13337FADD</code> 8 <code>DBF6310D</code> <code>AF7532E13337FADD</code> <code>1.16.10.0</code> <code>22002359BBDFA76E</code> 9 <code>C2979E08</code> <code>22002359BBDFA76E</code> <code>1.17.1.3</code> <code>FE65A6135A1E7B3F</code> 10 <code>B5011420</code> <code>FE65A6135A1E7B3F</code> <code>1.17.1.5</code> <code>1FA6AAA3C28D8BD8</code> <p>For each row, first prove that <code>ota self</code> exactly matches its Before hash, then inspect the manager before changing it:</p> <pre><code>ota status\n</code></pre> <p>Proceed to discovery only after that status is reconciled. When the manager is idle, run:</p> <pre><code>ota ls\nota pull MANIFEST_ID flash\nota status\n</code></pre> <p>If the first status reports this row's MID as partial, use <code>ota pull</code> with that same MID to resume it. If this row's MID is already ready, do not pull or cancel it; continue with the install checks below. If status reports the immediately previous row's MID as <code>verifying staged blocks</code>, wait through the bounded discovery window; require either that exact MID to become <code>ready to install</code> or the manager to become <code>no download</code>, and re-prove the current Before hash. Cancel only the same previous MID while it is visibly attached and ready. If it has become idle, send no cancel. Stop on any other MID, failed or incomplete state, ambiguous reply, or timeout. Never issue a blind <code>ota cancel</code>: it can discard a resumable or unrelated session.</p> <p>Repeat <code>ota status</code> at a restrained interval until it says <code>ready to install</code>. If the manifest is initially absent, wait for a fresh source advert, run <code>ota ls</code> again, or restart <code>motatool</code>; do not pull a different ID. Stop the seeder and install:</p> <pre><code>get system.watchdog\nota install\n</code></pre> <p>The watchdog reply must still be <code>&gt; off</code>. Allow the current default five-minute readiness window for the USB/LoRa identity to return; automation probes every 10 seconds and returns early as soon as the exact body is visible. Then run <code>ver</code>, <code>ota self</code>, and <code>ota help</code>. Require the row's exact After hash, require <code>bootloader: apply OK</code>, and require <code>rescue install &lt;hash16&gt;</code> in the help before exposing that bridge to the next package. This rescue-help gate applies to steps 1-9; step 10 is the endpoint and is not exposed to another package in this chain. A normal-radio <code>ota status</code> response of <code>no download</code> proves only that the manager is idle; legacy internal-flash firmware does not durably erase a retained container by accepting an IDLE <code>ota cancel</code>. Do not claim otherwise. When the same expected manifest reports <code>verifying staged blocks</code> after the next TempRadio starts, wait only for the bounded discovery window and require that it become <code>ready to install</code> or <code>no download</code>; stop on a changed ID, failed/incomplete state, or timeout. Prove the exact running body before cancelling an attached completed session. OTAFIX consumes the approval word during a successful install, so a retained endpoint container is inert and a later valid pull replaces it. Reapply the transfer guardrails and TempRadio tuple, restart <code>motatool</code>, and continue with the next row.</p> <p>If the board boots but <code>ota self</code> says the EndF is invalid, stop. Only when <code>ota status</code> still identifies that row's complete staged package may the guarded <code>ota rescue install BEFORE_HASH</code> command be used. It is not a force option and must use that row's exact Before hash. If the board does not boot, recover the documented start/recovery UF2 locally over USB. Step 10 is the endpoint and has no successor package in this chain. If its EndF is invalid, use local DFU/SWD rather than attempting an unqualified LoRa package.</p>"},{"location":"rak3401_mota_chain/#4-intermediate-relays-and-restoration","title":"4. Intermediate relays and restoration","text":"<p>On every managed intermediate relay, save <code>get rxdelay</code> and <code>get txdelay</code>, then use the airtime-scaled collision window during the maintenance session:</p> <pre><code>set rxdelay 0\nset txdelay 0.3\n</code></pre> <p>Current OTA transfer packets honor that configured relay <code>txdelay</code>; setting <code>0.3</code> gives competing relays a small randomized, airtime-scaled forwarding window. The source's manifest-fragment gap independently follows active packet airtime and duty spacing, clamped to 100-1000 ms. These two delays solve different problems.</p> <p>After step 10 is proven, restore each saved destination and relay value exactly, including <code>rxdelay</code>, RXPS, CPU power saving, <code>af</code>, <code>ota config hops</code>, and relay timing. Current full-parser repeater firmware accepts <code>normalradio</code> and restores the saved tuple after replying on the temporary channel:</p> <pre><code>normalradio\n</code></pre> <p>The <code>b40d2e6c</code> endpoint supports that command. If a recovery build unexpectedly replies <code>Unknown command</code>, shorten its lease to one minute with the same tuple:</p> <pre><code>tempradio 909.950,500,5,5,1\n</code></pre> <p>Wait for the lease to expire, return the controller and ordinary source to their saved normal channels, and then re-enable the RAK system watchdog:</p> <pre><code>set system.watchdog on\nget system.watchdog\n</code></pre> <p>A Full Companion source is the exception: its local TCP console supports <code>normalradio</code> and the automated runner uses it before restoring the shared Binary API radio tuple.</p> <p>Final lab success requires version <code>v1.17.1.5-halo-keymind-cascade-dev-b40d2e6c</code>, body hash <code>1FA6AAA3C28D8BD8</code>, target <code>2FA509C1</code>, hardware <code>RAK_3401</code>, and <code>get system.watchdog</code> reporting <code>&gt; on</code>. If a relay cannot be restored before its TempRadio lease ends, wait for it to return to the normal channel and restore its saved <code>rxdelay</code> and <code>txdelay</code> there.</p>"},{"location":"rak3401_mota_chain/#two-relay-deployment","title":"Two-relay deployment","text":"<p>The first nine direct package transitions above were physically observed as the byte-identical first nine transitions of the legacy chain. Replacement step 10, this hardened host-runner revision, and multi-hop operation are not cleanly end-to-end physically qualified. A controlled, recoverable multi-hop lab can exercise two intermediate relays by listing them farthest-to-nearest and using three OTA hops. Run a non-mutating preflight first; even preflight requires the prerelease candidate override because the command connects to live devices:</p> <pre><code>python3 tools/lora_ota/rak3401_mota_chain.py \\\n  --bundle /path/to/RAK3401-update-chain-v1.16.7-c1caa5ad-to-v1.17.1.5-b40d2e6c.zip \\\n  --work-dir ./rak3401-mota-chain-work \\\n  --controller-serial /dev/ttyACM0 \\\n  --source-tcp SOURCE_IP:5001 \\\n  --source-cli-tcp SOURCE_IP:5002 \\\n  --source-shares-controller \\\n  --target-key 63d8df63 \\\n  --relay 'Far Repeater' \\\n  --relay 'Near Repeater' \\\n  --temp-radio 909.950,250,5,5,120 \\\n  --ota-hops 3 \\\n  --motatool /path/to/motatool \\\n  --accept-test-candidate \\\n  --preflight-only\n</code></pre> <p>After preflight succeeds, rerun with <code>--yes</code> in place of <code>--preflight-only</code>. Confirm that the selected frequency and bandwidth are legal at the deployment location.</p>"},{"location":"rak3401_mota_chain/#rescue-and-completion","title":"Rescue and completion","text":"<p>The guarded <code>ota rescue install &lt;base_body_hash&gt;</code> command is present after step 1 and remains available through the step-9 bridge. It is not a force command: it refuses a valid normal EndF, a base mismatch, wrong target/hardware, or invalid payload. A failure before step 1 completes still requires local USB recovery because the deployed start image predates the rescue command. The final <code>b40d2e6c</code> endpoint uses the stricter shared-slot profile; its invalid-EndF recovery is local DFU/SWD, not the rescue command.</p> <p>Before the first mutation, the runner saves the destination's RXPS periods, CPU power-saving state, RX flood delay, airtime factor, and OTA hop reach in the persistent work directory, flushing both the file and its directory entry before changing a guardrail. It also saves the managed source's exact RXPS preference in the chain-root <code>source-rxps-settings.json</code> before disabling it. Every step reuses that protected record, so a rerun after a killed host process restores the chain-start preference instead of treating the temporary off state as original. The record is accepted only for the same CLI endpoint. The runner retires that chain-root record only after it has proved the source is back on its normal radio and restored the exact preference at the verified endpoint. The runner reads the destination, controller, source, and relay versions before applying the same RXPS policy as the generic runner. The mixed historical chain therefore verifies <code>radio.rxps off</code> after every bridge reboot; a future all-v1.17.1.5-or-newer SF5/BW250 chain would instead keep RXPS on under the qualified level-8/preamble-64 boundary. It also verifies <code>powersaving off</code> and <code>rxdelay 0</code>, plus <code>af 0</code> when <code>--legacy-full-airtime</code> was explicitly selected. It restores every original value only after the exact endpoint is proven. An interrupted run deliberately leaves those transfer guardrails active; rerun the same command with the same work directory to resume and restore them. CPU power saving was not the cause of the observed folder-source failure: that was a USB CDC receive-ring overrun fixed by bounded serial reads. The runtime settings remain conservative isolation and fast-link reliability guardrails.</p> <p>For every named <code>--relay</code>, the per-step runner also captures <code>rxdelay</code> and <code>txdelay</code>, writes them to <code>relay-timing-settings.json</code>, applies <code>rxdelay 0</code> and <code>txdelay 0.3</code> during transfer, verifies the readback, and restores both before the relay leaves TempRadio.</p> <p>The runner also keeps the watchdog off across the chain, rechecks identity and OTA reach before every package, requires the exact post-boot EndF hash, and only re-enables the watchdog after step 10. Lab success requires endpoint body hash <code>1FA6AAA3C28D8BD8</code>, target <code>2FA509C1</code>, hardware <code>RAK_3401</code>, normal radio <code>910.525 MHz / 62.5 kHz / SF7 / CR5</code>, and the watchdog verified on.</p>"},{"location":"rak3401_mota_chain/#external-radio-startup-and-manual-usb-recovery","title":"External-radio startup and manual USB recovery","text":"<p>RAK3401 is a distinct target from RAK4631. Its RAK13300/RAK13302 radio is on the WisBlock SPI bus (<code>SPI1</code> in the Adafruit nRF52 core), with BUSY and DIO1 on P0.09/P0.10. Current builds explicitly enable those NFC-capable pads as GPIO and do not advertise the radio bus as an on-board QSPI flash device.</p> <p>The RAK13302's FEM and boost supply use switched <code>3V3_S</code>, but the SX1262 core uses unswitched 3V3. An MCU reset, a 1200-baud DFU touch, or disconnecting only USB may therefore leave a battery-powered SX1262 in its previous state. At startup, current firmware quiesces the FEM, reinitializes the dedicated SPI instance, asserts NRESET, and, if BUSY remains high, sends the Semtech NSS/GET_STATUS wake sequence without waiting on RadioLib first. The one-time board startup cold-starts <code>3V3_S</code>; later radio retries leave that shared rail enabled so they do not reset GPS or sensor modules.</p> <p>If BUSY still cannot be released, firmware must not enter a reset loop:</p> <ul> <li>Companion starts its USB/BLE management services after three bounded probes,   uses nRF52 hardware entropy if it needs a first-boot identity, and retries the   radio every 60 seconds. Radio statistics remain zero until recovery.</li> <li>Repeater keeps the same USB CDC session open and prints   <code>Radio unavailable; retrying in 60 seconds</code>. It repeats the board-level probe   in place. The normal repeater CLI and mesh transport cannot start until the   radio responds.</li> </ul> <p>A permanently high BUSY after NRESET and the direct wake transaction indicates an electrically unavailable radio, loose module, or power-domain fault; an MCU reboot cannot manufacture a response. If local access is possible, disconnect the battery as well as USB and reseat the WisBlock module. Remote firmware will continue retrying without requiring that physical intervention or churning the USB device.</p> <p>For an existing deployed tower using Preview 5, do not change the bootloader as part of this application chain. Its exact local recovery package is the Preview 5 RAK4631 ZIP. For a new RAK3401 installation or local recovery, use the OTAFIX 2.4.3 RAK3401 ZIP from the OTAFIX 2.4.3 release. These are local DFU/SWD recovery assets, not mOTA chain steps.</p> <p>For a local Serial DFU recovery with the repository helper:</p> <pre><code>cd /path/to/meshfirmware\nMCFIRMWARE_NO_SUDO=1 ./mcfirmware.sh\n</code></pre> <p>Select the serial entry whose USB identity is <code>WisCore RAK3401 Board</code>, then choose Custom, nrf52, and the exact RAK3401 <code>.zip</code>. Use flash-update to preserve InternalFS preferences and identity. Use flash-wipe + flash only when erasing application data is intentional. The helper follows the same USB device into bootloader mode, so do not substitute another <code>/dev/ttyACM*</code> merely because its number appears first.</p>"},{"location":"spiffs_regular_file_reads/","title":"SPIFFS regular-file reads and login replay state","text":"<p>Arduino-ESP32 SPIFFS can return a truthy directory handle from a read-open of a nonexistent filename. <code>File::operator bool()</code> alone does not prove that a regular file exists. A directory's <code>size()</code> and <code>read()</code> are zero.</p> <p>The first privileged login on an upgraded G2 encountered this in <code>ClientACL::writeClientLoginReplayCeiling()</code>: opening the not-yet-created <code>/s_login_replay</code> appeared successful, then subtracting the eight-byte trailer from size zero underflowed. Copying the supposed records failed and login was rejected. Waiting or changing the repeater clock cannot fix that file-open bug.</p>"},{"location":"spiffs_regular_file_reads/#fix","title":"Fix","text":"<p>Use <code>mesh::openFileRead()</code> for regular-file reads. It checks existence and rejects directory handles, while preserving real empty files. Replay record counts also validate the minimum trailer size, record alignment, and maximum count before subtraction. An existing replay file that becomes unreadable is not treated as a new store.</p> <p>No replay records are cleared and authentication is not weakened. Invalid or unwritable replay state still fails closed. The first successful privileged login creates a 44-byte file: one 36-byte identity/ceiling record plus its eight-byte integrity trailer.</p> <p>Setting the repeater clock must not clear this file. Admission compares the sender's timestamp with that sender's saved boundary, not with the repeater's current time. Clearing the boundary could make captured requests reusable. A sender clock rollback is a separate condition and remains subject to the saved boundary after this fix.</p> <p>Companion directory enumeration uses the separate <code>openDirectory()</code> API, which deliberately permits SPIFFS virtual directories. Regular-file reads are also enforced for companion data, repeater/room logs, flood-rule verification, and HTTP packet-log downloads (missing logs return 404; real empty logs 200).</p>"},{"location":"spiffs_regular_file_reads/#audit-boundary","title":"Audit boundary","text":"<p>The audit covered file opens and size arithmetic in <code>src</code> and <code>examples</code>. Identity, region, clock, and common preference loaders already gate reads with filesystem existence checks; SPIFFS's <code>exists()</code> explicitly excludes directory handles. Relevant MQTT length subtraction follows validated headers and exact reads. ESP32 OTA staging uses partition APIs, not these SPIFFS file handles. Intentional directory enumeration must not be changed to a regular-file read.</p>"},{"location":"spiffs_regular_file_reads/#regression-checks","title":"Regression checks","text":"<ul> <li><code>test/test_client_acl_spiffs.py</code> compiles the actual <code>ClientACL.cpp</code> against   a filesystem that reproduces the misleading missing-file directory handle.   It covers first creation, fresh/stale login, reboot ceilings, corrupt and   unreadable state, short writes, failed publication, and truncated sources.</li> <li><code>test/test_regular_file_reads.py</code> executes production companion readers,   flood-file verification, and HTTP log delivery with the same filesystem   behavior, including platform-specific file API differences.</li> <li><code>test/test_esp32_tinyusb_cooperative_output.py</code> exercises both real role log   pumps, including missing logs and bounded output.</li> <li>Native ACL transaction, login persistence, and client-path persistence suites   retain the existing security and recovery coverage.</li> </ul> <p>The pre-fix actual ACL code was reproduced as <code>first_login=rejected</code>, one missing read-open, and no replay file. The fixed code accepted that identical scenario without a missing read-open and created the valid 44-byte record. Host simulations do not replace a post-flash LoRa login test on the G2.</p>"},{"location":"stats_binary_frames/","title":"Stats Binary Frame Structures","text":"<p>Binary frame structures for companion radio stats commands. All multi-byte integers use little-endian byte order.</p>"},{"location":"stats_binary_frames/#command-codes","title":"Command Codes","text":"Command Code Description <code>CMD_GET_STATS</code> 56 Get statistics (2-byte command: code + sub-type)"},{"location":"stats_binary_frames/#stats-sub-types","title":"Stats Sub-Types","text":"<p>The <code>CMD_GET_STATS</code> command uses a 2-byte frame structure: - Byte 0: <code>CMD_GET_STATS</code> (56) - Byte 1: Stats sub-type:   - <code>STATS_TYPE_CORE</code> (0) - Get core device statistics   - <code>STATS_TYPE_RADIO</code> (1) - Get radio statistics   - <code>STATS_TYPE_PACKETS</code> (2) - Get packet statistics</p>"},{"location":"stats_binary_frames/#response-codes","title":"Response Codes","text":"Response Code Description <code>RESP_CODE_STATS</code> 24 Statistics response (2-byte response: code + sub-type)"},{"location":"stats_binary_frames/#stats-response-sub-types","title":"Stats Response Sub-Types","text":"<p>The <code>RESP_CODE_STATS</code> response uses a 2-byte header structure: - Byte 0: <code>RESP_CODE_STATS</code> (24) - Byte 1: Stats sub-type (matches command sub-type):   - <code>STATS_TYPE_CORE</code> (0) - Core device statistics response   - <code>STATS_TYPE_RADIO</code> (1) - Radio statistics response   - <code>STATS_TYPE_PACKETS</code> (2) - Packet statistics response</p>"},{"location":"stats_binary_frames/#resp_code_stats-stats_type_core-24-0","title":"RESP_CODE_STATS + STATS_TYPE_CORE (24, 0)","text":"<p>Total Frame Size: 11 bytes</p> Offset Size Type Field Name Description Range/Notes 0 1 uint8_t response_code Always <code>0x18</code> (24) - 1 1 uint8_t stats_type Always <code>0x00</code> (STATS_TYPE_CORE) - 2 2 uint16_t battery_mv Battery voltage in millivolts 0 - 65,535 4 4 uint32_t uptime_secs Device uptime in seconds 0 - 4,294,967,295 8 2 uint16_t errors Error flags bitmask - 10 1 uint8_t queue_len Outbound packet queue length 0 - 255"},{"location":"stats_binary_frames/#example-structure-cc","title":"Example Structure (C/C++)","text":"<pre><code>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</code></pre>"},{"location":"stats_binary_frames/#resp_code_stats-stats_type_radio-24-1","title":"RESP_CODE_STATS + STATS_TYPE_RADIO (24, 1)","text":"<p>Total Frame Size: 14 bytes</p> Offset Size Type Field Name Description Range/Notes 0 1 uint8_t response_code Always <code>0x18</code> (24) - 1 1 uint8_t stats_type Always <code>0x01</code> (STATS_TYPE_RADIO) - 2 2 int16_t noise_floor Radio noise floor in dBm -140 to +10 4 1 int8_t last_rssi Last received signal strength in dBm -128 to +127 5 1 int8_t last_snr SNR scaled by 4 Divide by 4.0 for dB 6 4 uint32_t tx_air_secs Cumulative transmit airtime in seconds 0 - 4,294,967,295 10 4 uint32_t rx_air_secs Cumulative receive airtime in seconds 0 - 4,294,967,295"},{"location":"stats_binary_frames/#example-structure-cc_1","title":"Example Structure (C/C++)","text":"<pre><code>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</code></pre>"},{"location":"stats_binary_frames/#resp_code_stats-stats_type_packets-24-2","title":"RESP_CODE_STATS + STATS_TYPE_PACKETS (24, 2)","text":"<p>Total Frame Size: 26 bytes (legacy) or 30 bytes (includes <code>recv_errors</code>)</p> Offset Size Type Field Name Description Range/Notes 0 1 uint8_t response_code Always <code>0x18</code> (24) - 1 1 uint8_t stats_type Always <code>0x02</code> (STATS_TYPE_PACKETS) - 2 4 uint32_t recv Total packets received 0 - 4,294,967,295 6 4 uint32_t sent Total packets sent 0 - 4,294,967,295 10 4 uint32_t flood_tx Packets sent via flood routing 0 - 4,294,967,295 14 4 uint32_t direct_tx Packets sent via direct routing 0 - 4,294,967,295 18 4 uint32_t flood_rx Packets received via flood routing 0 - 4,294,967,295 22 4 uint32_t direct_rx Packets received via direct routing 0 - 4,294,967,295 26 4 uint32_t recv_errors Receive/CRC errors (RadioLib); present only in 30-byte frame 0 - 4,294,967,295"},{"location":"stats_binary_frames/#notes","title":"Notes","text":"<ul> <li>Counters are cumulative from boot and may wrap.</li> <li><code>recv = flood_rx + direct_rx</code></li> <li><code>sent = flood_tx + direct_tx</code></li> <li>Clients should accept frame length &gt;= 26; if length &gt;= 30, parse <code>recv_errors</code> at offset 26.</li> </ul>"},{"location":"stats_binary_frames/#example-structure-cc_2","title":"Example Structure (C/C++)","text":"<pre><code>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</code></pre>"},{"location":"stats_binary_frames/#command-usage-example-python","title":"Command Usage Example (Python)","text":"<pre><code># 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</code></pre>"},{"location":"stats_binary_frames/#response-parsing-example-python","title":"Response Parsing Example (Python)","text":"<pre><code>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('&lt;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('&lt;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) &gt;= 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('&lt;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) &gt;= 30:\n        (recv_errors,) = struct.unpack('&lt;I', frame[26:30])\n        result['recv_errors'] = recv_errors\n    return result\n</code></pre>"},{"location":"stats_binary_frames/#command-usage-example-javascripttypescript","title":"Command Usage Example (JavaScript/TypeScript)","text":"<pre><code>// 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</code></pre>"},{"location":"stats_binary_frames/#response-parsing-example-javascripttypescript","title":"Response Parsing Example (JavaScript/TypeScript)","text":"<pre><code>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 &lt; 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 &gt;= 30) {\n        result.recv_errors = view.getUint32(26, true);\n    }\n    return result;\n}\n</code></pre>"},{"location":"stats_binary_frames/#field-size-considerations","title":"Field Size Considerations","text":"<ul> <li>Packet counters (uint32_t): May wrap after extended high-traffic operation.</li> <li>Time fields (uint32_t): Max ~136 years.</li> <li>SNR (int8_t, scaled by 4): Range -32 to +31.75 dB, 0.25 dB precision.</li> </ul>"},{"location":"telemetry_decoder/","title":"Telemetry decoder","text":"<p>Paste raw hexadecimal packet data copied from the Let's Mesh packet analyzer to decode a repeater's scheduled temperature, battery-voltage, or external I2C-voltage snapshot. The decoder also accepts the payload hex without its MeshCore packet header and the Base64 pages returned by repeater or room-server CLI commands. Decoding happens entirely in this browser; pasted data is not uploaded or sent anywhere.</p> <p>The Source ID in a raw-packet result is the first eight bytes of the sending repeater's public key. Match that 16-character hex value against the public-key prefix recorded for your repeaters. It comes from the telemetry payload itself, so it is available even when only the payload was copied.</p>"},{"location":"telemetry_decoder/#send-raw-telemetry-packets","title":"Send raw telemetry packets","text":"<p>From an administrator CLI session, first configure a direct route to the MQTT observer that will receive and upload the raw packets. Use <code>direct</code> when the observer is a zero-hop neighbor:</p> <pre><code>set telemetry.tx direct\nsend telemetry.tx now\n</code></pre> <p>For a routed observer, provide its comma-separated hop hashes instead:</p> <pre><code>set telemetry.tx A1B2,C3D4\nsend telemetry.tx now\n</code></pre> <p>Configuring the route also enables the default two-day schedule. To keep the route but use it only for manual tests, turn off the schedule before sending:</p> <pre><code>set telemetry.tx schedule off\nsend telemetry.tx now\n</code></pre> <p>The <code>send telemetry.tx now</code> command queues one <code>TTB1</code> temperature packet, one <code>TVB1</code> battery-voltage packet, and <code>IVB1</code> chunks for every connected I2C voltage channel. <code>TTB1</code> and <code>TVB1</code> carry up to 165 samples. Each <code>IVB1</code> carries 64, so a full 192-point/four-day channel takes three packets. Channels whose retained history is entirely zero are treated as disconnected and are not sent. The command requires at least one collected base sample and works even when the automatic schedule is off.</p>"},{"location":"telemetry_decoder/#decode-a-packet","title":"Decode a packetDecoded telemetry","text":"Try an analyzer example: Temperature packet Voltage packet I2C voltage packet I2C voltage CLI page Raw packet or payload hex <p>     Spaces, line breaks, colons, dashes, a leading <code>0x</code>, and a quoted     JSON field are accepted. CLI Base64 replies are also auto-detected. Paste     multiple compatible packet or reply lines together to merge them by     timestamp before downloading one CSV. Press Ctrl/Command+Enter to decode.   </p> Decode telemetry Clear        Show browser-local time      Download CSV Decode notes"},{"location":"telemetry_decoder/#analyzer-hex-examples","title":"Analyzer hex examples","text":"<p>The buttons load synthetic, protocol-valid zero-hop RAW_CUSTOM packets. A real scheduled snapshot normally has 165 samples and is much longer. Routed packets also contain path bytes before the <code>TTB1</code> or <code>TVB1</code> payload magic; the decoder finds and validates the payload automatically.</p>"},{"location":"telemetry_decoder/#temperature","title":"Temperature","text":"<pre><code>3E00545442311122334455667788800092651E0008000102354A4E5082\n</code></pre>"},{"location":"telemetry_decoder/#battery-voltage","title":"Battery voltage","text":"<pre><code>3E00545642311122334455667788800092651E000800010264C8FEFFDC\n</code></pre>"},{"location":"telemetry_decoder/#external-i2c-voltage","title":"External I2C voltage","text":"<pre><code>3E00495642311122334455667788800092651E00020800000004019026927109C427107FFF\n</code></pre> <p>All three examples identify the source as <code>1122334455667788</code>.</p>"},{"location":"telemetry_decoder/#cli-history-pages","title":"CLI history pages","text":"<p>The same page continues to decode the padded Base64 returned by these administrator commands:</p> Data Newest page Older-page example Samples per page MCU temperature <code>get telemetry.temp</code> <code>get telemetry.temp 2</code> 48 (24 hours) Battery voltage <code>get telemetry.volt</code> <code>get telemetry.volt 3</code> 48 (24 hours) I2C voltage <code>get telemetry.volt.i2c 2</code> <code>get telemetry.volt.i2c 2 4</code> 48 (24 hours) GPS position <code>get telemetry.gps</code> <code>get telemetry.gps 2</code> 24 (12 hours) <p>Paste either the complete reply beginning with <code>&gt;</code> or Base64 alone. For example:</p> <pre><code>get telemetry.volt 1\n&gt; EkDUcWoeMAAB5+bl5eTj4uLh4ODf3t7d3Nvb2tnZ2NfX1tXU1NPS0tHQ0M/Ozc3My8vKycnI/w==\n</code></pre> <p>Run <code>get telemetry.volt.i2c</code> without a channel first to list connected channels. For each channel, collect pages <code>1</code> through <code>4</code>. Paste all four reply lines into the decoder at once; it merges their timestamps into one 192-point, four-day table and downloads them as one CSV. The same merging works for the three <code>IVB1</code> analyzer packets from a full channel. Inputs must have the same telemetry type, source, LPP channel, and sample interval.</p> <p>An INA3221 exposes its three enabled hardware inputs as three consecutive LPP channels. When it is the only external sensor these are normally <code>2</code>, <code>3</code>, and <code>4</code>, in hardware-input order. Other sensors can shift the numbers, so copy the IDs reported by <code>get telemetry.volt.i2c</code> rather than assuming them.</p>"},{"location":"telemetry_decoder/#reading-the-table","title":"Reading the table","text":"<ul> <li>Timestamps default to UTC. Select Show browser-local time to convert   them for display and CSV export.</li> <li><code>TTB1</code> means a raw temperature snapshot, <code>TVB1</code> a raw battery-voltage   snapshot, and <code>IVB1</code> a packed external I2C-voltage chunk. The input summary   also reports the MeshCore route and path-hop count when a complete packet was   pasted.</li> <li>Temperature preserves exact whole degrees from <code>-50 C</code> through <code>+77 C</code>, plus   missing, below-range, and above-range states.</li> <li>Voltage preserves hundredths of a volt from <code>1.88 V</code> through <code>4.40 V</code>, plus   missing and out-of-range states.</li> <li>External I2C voltage uses a 15-bit code at <code>0.02 V</code> resolution. Code <code>0</code> is   missing/disconnected; codes <code>1</code> through <code>32767</code> cover <code>0.02 V</code> through   <code>655.34 V</code>. The LPP channel remains part of every page and raw chunk so   multiple monitor inputs cannot be mixed accidentally.</li> <li>GPS positions are reconstructed from signed 10-meter differentials. A zero   differential after the page origin is inherently ambiguous: it can represent   an unchanged fix, movement below the encoded resolution, or no fix. The table   labels those rows rather than inventing a coordinate.</li> <li>A GPS clipping warning means at least one movement exceeded the differential   range, so positions after that point can be less accurate.</li> </ul> <p>GPS history remains available through the administrator CLI, but <code>telemetry.tx</code> never puts GPS in RAW_CUSTOM packets. Location data therefore must come from a CLI Base64 page rather than analyzer hex.</p> <p>For the byte-level layouts, see Read repeater telemetry history.</p>"},{"location":"terminal_chat_cli/","title":"Terminal Chat CLI","text":"<p>Below are the commands you can enter into the Terminal Chat clients:</p>"},{"location":"terminal_chat_cli/#companion-usb-mode","title":"Companion USB mode","text":"<p>An ordinary Companion USB build starts in the normal binary Companion protocol at 115200 baud. Use this command to switch the same USB connection into terminal mode as soon as <code>picocom</code> opens it:</p> <pre><code>picocom --baud 115200 \\\n  --imap spchex \\\n  --initstring $'+++MESHCORE-TERM-START\\r' \\\n  /dev/ttyACM0\n</code></pre> <p><code>--initstring</code> sends this exact terminal-start line automatically:</p> <pre><code>+++MESHCORE-TERM-START\n</code></pre> <p>The carriage return is required in Binary mode. Control tokens are recognized only as complete CR/LF-delimited lines, so the same text embedded in unrelated unframed input cannot switch modes accidentally.</p> <p>Binary Companion frames can contain terminal control bytes. The <code>spchex</code> input map renders those bytes as bracketed hexadecimal during the short transition instead of allowing them to change the local terminal's character set or display state. It leaves high-bit bytes unchanged so a UTF-8 terminal displays emoji and non-ASCII text normally. Do not add <code>8bithex</code> unless you explicitly want UTF-8 bytes displayed as sequences such as <code>[f0][9f][91][8b]</code>. Once the terminal banner appears, the start sequence has already succeeded; do not enter it again as a terminal command.</p> <p>Send the following exact sequence to return to the binary protocol:</p> <pre><code>+++MESHCORE-TERM-STOP\n</code></pre> <p>Closing the serial connection also returns native-USB devices to binary mode. Boards whose USB connector is implemented by a USB-to-UART bridge cannot observe the host closing the port; on those boards, use the stop sequence or reboot the device.</p> <p>Both modes use the same port at 115200. Selecting 57600 is not a portable mode switch: native USB CDC devices ignore the requested baud, while USB-to-UART devices really change the UART timing and receive corrupt data. Binary mode is the framed Companion API used by apps and <code>meshcli</code>; close the terminal before opening that port from an app.</p> <p>Full Companion differs: its primary USB interface starts in ASCII after boot and automatically switches when it sees a complete <code>&lt;</code>-prefixed Companion frame at an empty prompt. The explicit start/stop tokens remain available. See Full Companion USB CLI and binary switcher for the state machine and limitations.</p>"},{"location":"terminal_chat_cli/#commands","title":"Commands","text":"<pre><code>set freq {frequency}\n</code></pre> <p>Set the LoRa frequency. Example:  set freq 915.8</p> <pre><code>set tx {tx-power-dbm}\n</code></pre> <p>Sets LoRa-chip transmit power in dBm. The firmware rejects values outside the radio/board limit; external-PA boards can have a lower input-power ceiling than the radio chip itself.</p> <pre><code>set name {name}\n</code></pre> <p>Sets your advertisement name.</p> <pre><code>get bluetooth.name\nset bluetooth.name {name|default}\n</code></pre> <p>Shows or changes the complete Bluetooth device name without changing the mesh advertisement identity. A custom name may contain spaces and is limited to 31 valid UTF-8 bytes. <code>default</code> restores <code>MeshCore-&lt;node name&gt;</code>. The saved change takes effect after reboot. <code>get ble.name</code> and <code>set ble.name</code> are short aliases.</p> <pre><code>set lat {latitude}\n</code></pre> <p>Sets your advertisement map latitude. (decimal degrees)</p> <pre><code>set lon {longitude}\n</code></pre> <p>Sets your advertisement map longitude. (decimal degrees)</p> <pre><code>set dutycycle {percent}\n</code></pre> <p>Sets the transmit duty cycle limit (1-100%). Example: <code>set dutycycle 10</code> for 10%.</p> <pre><code>set af {air-time-factor}\n</code></pre> <p>Sets the transmit air-time-factor. Deprecated - use <code>set dutycycle</code> instead.</p> <pre><code>powersaving\npowersaving {on|off}\nset powersaving {on|off}\n</code></pre> <p>Shows or changes Companion device power saving. On ESP32 this controls CPU and GPS idle behavior; it does not change LoRa RXPS or WiFi modem sleep.</p> <pre><code>get usb.logging\nset usb.logging {on|off} [reboot]\n</code></pre> <p>Shows or changes persistent live USB debug and packet output in an ordinary USB-loggable Companion or Full Companion. USB Companion and Full start off on a fresh install with logging disabled to protect framed traffic. nRF52 Full changes its interface count after a reboot and keeps Companion on interface <code>00</code>. Every ESP32 Full Companion has one TTY and needs no reboot: logging uses the active text terminal, disables framed Binary Companion on USB, and continues accepting <code>set usb.logging off</code>. Turning logging off leaves the port in the normal ASCII terminal, matching fresh firmware. Send <code>+++MESHCORE-TERM-STOP</code>, or let a Companion app send a valid framed probe, to switch it to Binary Companion afterward.</p> <pre><code>reboot\n</code></pre> <p>Sends an acknowledgement, then reboots the Companion one second later. The delay gives either the USB terminal or the Full Companion TCP terminal on port 5002 time to deliver the reply before its transport disappears.</p> <pre><code>get radio.rxps\nget radio.rxps.config\nset radio.rxps {off|on|level 1-10 [preamble 16|32]|rx_us sleep_us}\n</code></pre> <p>Shows or changes LoRa receive duty cycling on supported radios. <code>get radio.rxps.config</code> also reports the saved level and preamble assumption so automation can restore a level-based preference exactly. Fresh Cascade builds select level 8 with a 16-symbol timing assumption. The <code>preamble</code> argument controls the RXPS calculation; it does not change the physical wire preamble. A configured level is the minimum: when faster SF/BW settings shorten the timing window, firmware raises the effective level only as far as needed, up to level 10. Starting with v1.17.1.5, SF5-SF8 packets normally use a 32-symbol physical preamble. Firmware selects 64, then 128, only when every shorter choice fails to enable RXPS at any level. The configured values remain unchanged, so every radio change recalculates from the saved minimum. A slower tuple returns to that exact level and the shortest viable wire preamble.</p> <p>If neither adjustment leaves enough time for the radio to wake, RXPS stays logically enabled but receives continuously instead of rejecting the radio setting or starting an invalid duty cycle. The Companion terminal's <code>get radio.rxps</code> reports this as <code>mode=continuous-fast</code> and reports any <code>effective-level</code> or <code>effective-preamble</code> adjustment; <code>get radio.rxps.config</code> reports the persisted preference. A later compatible SF/BW change resumes duty cycling without another RXPS command.</p> <p>For the SX1262+TCXO boards tested here, these fast combinations are the useful RXPS boundary profiles (CR does not change the RXPS preamble timing):</p> SF BW (kHz) Wire preamble Effective preamble Minimum effective level RX / sleep 7 500 32 32 7 2731 / 6101 us 6 250 32 32 7 2731 / 6101 us 5 125 32 32 7 2731 / 6101 us 5 250 64 64 8 1252 / 6424 us 6 500 64 64 8 1252 / 6424 us 5 500 128 128 8 626 / 6398 us 5 62.5 32 16 10 4096 / 6272 us <p>The 64- and 128-symbol rows require the v1.17.1.5-or-newer adaptive-preamble contract on every sender that may reach the RXPS receiver. Cascade/USA builds on a Heltec V4 and WisMesh Tag (RAK4631 target) passed 16/16 packets in each direction at both SF5/BW250/64 and SF5/BW500/128, CR5, 909.950 MHz. An older sender makes a long-preamble timing window unsafe, so use continuous RX for a mixed deployment. Retry packets use the same physical preamble as other packets.</p> <pre><code>get wifi.powersave\nset wifi.powersave {none|min|max}\n</code></pre> <p>Shows or changes the persisted WiFi modem-sleep policy on ESP32 WiFi Companion builds. Full Companion requires at least <code>min</code> while BLE is present and rejects <code>none</code>. The WebConfig WiFi card and the normal binary Companion protocol expose the same setting; binary clients do not need the terminal-start token. On an ESP32 Full Companion whose primary mesh radio is ESP-NOW, <code>max</code> is also unavailable because maximum modem sleep can make the station miss ESP-NOW broadcasts, which the access point does not buffer. A previously saved <code>max</code> value is capped to and reported as <code>min</code>, and a new <code>max</code> selection is rejected. Such a WiFi/BLE/primary-ESP-NOW build therefore uses <code>min</code>.</p> <pre><code>get espnow.channel\nset espnow.channel &lt;1-13&gt;\n</code></pre> <p>On builds whose primary mesh radio is ESP-NOW, this shows or saves the primary radio's channel. The default is channel 1. Use only a channel permitted in your region, and restart or power-cycle the node after changing it. Every primary ESP-NOW peer must use the same channel.</p> <p>On Full Companion, the setup AP and infrastructure-WiFi station also share that channel, so the router's 2.4 GHz radio must remain fixed to it. Power saving does not permit separate channels. <code>wifi.powersave max</code> is unavailable on these ESP32 Full builds and <code>min</code> is the coexistence setting. This channel setting is also distinct from <code>bridge.channel</code>, which controls the optional ESP-NOW bridge transport. An updated LoRa-primary ESP-NOW bridge can join this raw primary transport by selecting the same channel and running <code>set bridge.format raw</code>; its default <code>wrapped</code> format remains the bridge-to-bridge protocol.</p> <pre><code>get radio.rxgain\nset radio.rxgain {on|off}\nget radio.fem.rxgain\nset radio.fem.rxgain {on|off}\nget radio.fem.txgain\nset radio.fem.txgain {on|off}\n</code></pre> <p><code>radio.rxgain</code> changes the radio chip's boosted receive-gain mode. The FEM settings control the external receive-path LNA or transmit-path gain on supported boards. Changes are applied immediately and saved across reboots; changing either receive-gain path also recalibrates the radio noise floor. Boards without the respective control report it as unsupported.</p> <pre><code>time {epoch-secs}\n</code></pre> <p>Set the device clock using UNIX epoch seconds. Example:  time 1738242833</p> <pre><code>advert\n</code></pre> <p>Sends an advertisement packet</p> <pre><code>clock\n</code></pre> <p>Displays current time per device's clock.</p> <pre><code>ver\n</code></pre> <p>Shows the device version and firmware build date.</p> <pre><code>card\n</code></pre> <p>Displays your 'business card', for others to manually import</p> <pre><code>import {card}\n</code></pre> <p>Imports the given card to your contacts.</p> <pre><code>list {n}\n</code></pre> <p>Lists favorite contacts first, then all remaining contacts. Each group is ordered by the most recent advertisement. Optional <code>{n}</code> limits the displayed contacts after applying that order.</p> <pre><code>show\nshow adverts {on|off}\nshow channels {on|off}\nshow emergency {on|off}\n</code></pre> <p>Controls unsolicited receive output in the USB terminal. Plain <code>show</code> reports the current settings, and <code>show {category}</code> reports one category. At boot, advertisements and ordinary channel messages are hidden while <code>#emergency</code> messages are shown. The three controls are independent, so <code>show channels on</code> does not override <code>show emergency off</code>.</p> <p>These filters affect terminal printing only. Messages still enter the offline queue and are delivered through the binary Companion protocol. Changes remain active when switching between terminal and binary mode and reset to their defaults after reboot.</p> <pre><code>to\n</code></pre> <p>Shows the name of current recipient contact. (for subsequent 'send' commands)</p> <pre><code>to {name-prefix}\n</code></pre> <p>Sets the recipient to the first matching contact (in 'list') by the name prefix. (ie. you don't have to type whole name)</p> <pre><code>path\n</code></pre> <p>Shows the saved outgoing path for the current <code>to</code> recipient. This command and all path changes require a recipient to be selected first.</p> <pre><code>path direct\npath clear\npath {hop-hash...}\n</code></pre> <p>Sets the outgoing path used by subsequent <code>login</code>, <code>send</code>, and <code>cmd</code> commands. <code>direct</code> selects a zero-hop route. <code>clear</code> forgets the saved route, causing the next operation to use flood routing and allowing normal path discovery to learn a replacement.</p> <p>Explicit paths use spaces, commas, or a mixture of both between hop hashes. Each hop must contain exactly 2, 4, or 6 hexadecimal digits, and every hop in one path must use the same width. Whitespace and hexadecimal letter case do not matter. The setting is saved with the selected contact.</p> <p>For example:</p> <pre><code>to Hilltop Repeater\npath A1B2C3,D4E5F6\npath 7773D0 7E7662\npath\nlogin my-admin-password\n</code></pre> <pre><code>login {admin-password}\n</code></pre> <p>Sends a remote login request to the current recipient. Select a repeater, room, or other remotely managed node with <code>to {name-prefix}</code> first. The password is masked with <code>*</code> while it is entered and must be 1-15 UTF-8 bytes; longer passwords are rejected instead of truncated. Login uses the route shown by <code>path</code>: a known or explicitly set route is direct, while an unknown route is flooded.</p> <p>Login results arrive asynchronously. A successful modern response displays the remote ACL permissions byte and server protocol level. A wrong password, an unreachable target, or a server that does not support remote login normally produces a timeout because those nodes do not send a rejection packet.</p> <pre><code>cmd {remote-command}\n</code></pre> <p>Sends CLI data to the current recipient. Wait for the login result before sending the first command. The remote node applies its own ACL permissions, and any reply appears asynchronously as <code>CLI -&gt; from {name}</code>. The response window is 300% of the route estimate. A routed send is displayed as <code>DIRECT via path {hop,...}</code> with the exact prefixes copied into the packet; in MeshCore, <code>DIRECT</code> is the route class for an explicit path, not a synonym for zero hops. A matched reply also shows its local round-trip time, measured from queueing the command through receiving the result. This includes both radio directions and remote execution; it is not execution-only CPU time. Only one terminal <code>cmd</code> can be pending at a time.</p> <p>For example:</p> <pre><code>to Hilltop Repeater\nlogin my-admin-password\nLOGIN -&gt; Hilltop Repeater accepted (ACL permissions 0x03, server v13)\ncmd ver\ncmd get radio\n</code></pre> <p>The exact commands and permissions depend on the target firmware. <code>cmd</code> does not run a command on the local Companion; it sends the text over LoRa to the selected node.</p> <p>Incoming direct-route messages are labeled <code>ROUTED</code>, not <code>DIRECT</code>. Forwarders consume direct-route prefixes as the packet travels, so the destination cannot recover the reply's actual hop history from the received packet. Use <code>trace</code> when the return route itself must be verified.</p> <pre><code>send {text}\n</code></pre> <p>Sends the text message (as DM) to current recipient.</p> <pre><code>trace\n</code></pre> <p>Traces the saved round-trip route to the current recipient and displays the SNR at each hop. Select the recipient first with <code>to {name-prefix}</code>.</p> <pre><code>trace {name-prefix}\n</code></pre> <p>Traces a recipient directly without changing the current <code>to</code> selection. A trace requires a known direct path; use normal messaging or path discovery first if the terminal reports that no valid path is available. Only one terminal trace can be pending at a time, and a missing response is reported as a timeout.</p> <p>For example:</p> <pre><code>to Hilltop Repeater\ntrace\ntrace Downtown\n</code></pre> <p>The displayed route uses one- or two-byte node hashes and per-hop SNR values. Saved three-byte paths are traced with two-byte prefixes because the trace packet format has no three-byte hash-size mode.</p> <p>To trace an explicit route instead of a saved contact path, provide the prefix size followed by the complete ordered route:</p> <pre><code>trace path 1 12 34 56 34 12\ntrace path 2 1234,ABCD,5678,ABCD,1234\ntrace path 4 12345678, ABCDEF01 89ABCDEF, ABCDEF01,12345678\n</code></pre> <p>Prefix separators may be spaces, commas, or any mixture of them. Each prefix must contain exactly 2, 4, or 8 hexadecimal digits for a 1-, 2-, or 4-byte trace respectively. Three-byte traces are not supported.</p> <p>The prefixes are used exactly in the order entered. To receive the trace result, enter the complete outward route followed by its return route, as in the mirrored examples above. A route that does not return to this node will eventually report a timeout.</p> <pre><code>reset path\n</code></pre> <p>Resets the path to current recipient, for new path discovery. This is retained as an alias for <code>path clear</code>.</p> <pre><code>public {text}\n</code></pre> <p>Sends the text message to the built-in <code>Public</code> group channel.</p> <pre><code>channels\n</code></pre> <p>Lists the configured channel slots and names without exposing their secrets.</p> <pre><code>channel {name-or-slot} {text}\n</code></pre> <p>Sends a message to any configured channel by its exact name or numeric slot. Use the slot shown by <code>channels</code> when a channel name contains spaces.</p> <p>For example:</p> <pre><code>channels\nchannel #rgdata Hello from Eugene\nchannel 2 Another message\nshow channels on\n</code></pre> <p>Messages are UTF-8. Emoji use multiple bytes toward the available message length, which also includes the sender-name prefix added over the air.</p>"},{"location":"usb_serial_backpressure/","title":"Native USB backpressure and radio liveness","text":"<p>ESP32-S2/S3 builds using native TinyUSB CDC (<code>ARDUINO_USB_MODE=0</code> and CDC-on-boot) must not wait for a computer to read USB output. In the bundled Arduino-ESP32 2.0.17 core, <code>USBCDC::write()</code> can wait indefinitely for transmit space; its configured timeout bounds a mutex, not that wait. This can stop the same loop that services LoRa, even while the USB connection still appears open.</p>"},{"location":"usb_serial_backpressure/#firmware-behavior","title":"Firmware behavior","text":"<ul> <li>Native CDC output uses a single FIFO attempt, not Arduino's wait-for-space   write or flush. TinyUSB's internal short mutex operations still apply; this   is a no-host-progress-wait guarantee, not a lock-free driver replacement.</li> <li>Functional text and diagnostics share one ordered 4 KiB queue. Diagnostics   leave 3 KiB reserved for commands. A diagnostic backlog alone does not prevent   command input. A stalled host may lose diagnostic records; radio work continues.</li> <li>A connected terminal that exceeds its bounded output capacity gets an explicit   dropped-byte notice when transmission resumes. Large local file dumps and   recent-repeater listings advance between radio service passes instead.</li> <li>File dumps stop at their initial file size and emit <code>-&gt; EOF</code> only after the   final accepted record. Corrupt stored lines exceeding 640 bytes are omitted   with a visible notice. Recent-repeater output is a live, bounded-cursor view;   incoming packets can change its ordering while it is being printed.</li> <li>Disconnects discard pending old-session text and reset the role's partial   command/listing state. Binary/mOTA transitions suppress pending text notices.   Bytes already transmitted cannot be recalled.</li> <li>Companion frames retain and retry short writes. An mOTA request is admitted   only when its complete, at-most-11-byte record fits.</li> <li>nRF52, UART, and USB-Serial-JTAG behavior is not changed by this native-CDC path.</li> </ul> <p>Host software must also keep reading independently of command writes. A serial relay should start its reader before the first command, use finite write and response deadlines, avoid discarding received packet logs, and cancel I/O during shutdown. A response timeout must not allow a late reply to satisfy another command: the CLI has no transaction identifiers. Updating firmware alone does not correct an indefinite host-side serial write.</p>"},{"location":"usb_serial_backpressure/#regression-checks","title":"Regression checks","text":"<p>Run only one PlatformIO process in the checkout at a time.</p> <pre><code>python test/test_esp32_tinyusb_nonblocking.py\npython test/test_esp32_tinyusb_role_hygiene.py\npython test/test_esp32_tinyusb_cooperative_output.py\npython test/test_esp32_usb_serial_hygiene.py\npython test/test_nrf52_usb_logging_contract.py\npio test -e native -f test_nrf52_debug_output -f test_serial_packet_log -f test_serial_mode_switch -f test_mesh_tables\n</code></pre> <p>The first test compiles the real USB facade against a simulated 64-byte FIFO, including stopped readers, reconnects, protocol transitions, and other-platform fallbacks. Host simulations cannot establish that every real USB driver or endpoint failure has recovered.</p> <p>A Full Station G2 validation build with USA Cascadia radio settings and the Cascade profile can be made using the normal build entry point. The portable <code>standard</code> recipe preserves the deployed partition layout but omits LoRa OTA; it still has the browser firmware uploader. The <code>auto</code>/<code>full</code> recipe instead enables the expanded feature set and partition layout: its merged image is not an app-only update for a device with the legacy layout.</p> <pre><code>MESHDEBUG_OVERRIDE=on PACKET_LOGGING_OVERRIDE=on \\\n  bash build.sh build-firmware Station_G2_repeater --build-profile full \\\n  --radio-preset usa-cascadia --profile cascade\n</code></pre> <p>Before installing on hardware, preserve the device identity, preferences, and existing partition layout. Then verify USB command responses and repeated LoRa logins with the relay running, paused, and stopped, including a host that leaves USB open without reading. Check LoRa recovery separately from USB OUT recovery; fixing transmit backpressure does not prove an unrelated OUT endpoint fault is resolved. Do not erase or repartition the radio as part of this test.</p>"}]}
\ No newline at end of file