mirror of
https://github.com/mikecarper/MeshCore.git
synced 2026-10-27 17:42:24 +00:00
deploy: f1feed086b
This commit is contained in:
mikecarper committed
1 parent
66c526a9b4
commit
e4432b0364
5 files changed
+206
-1
No files matched your search
@@ -2183,6 +2183,17 @@
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#full-firmware-raw-radio2-kiss-modem" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
|
||||
Full firmware raw radio2 KISS modem
|
||||
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
@@ -5368,6 +5379,17 @@
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#full-firmware-raw-radio2-kiss-modem" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
|
||||
Full firmware raw radio2 KISS modem
|
||||
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
@@ -8710,6 +8732,32 @@ Supported ESP32 Full SX1262/SX1276 builds expose trusted-LAN KISS-over-TCP on
|
||||
station port 5003. It does not add an SSH server, use <code>tx.ssh</code> tags, or bridge
|
||||
Ethernet into MeshCore. Conflicting radio2 owners are not overwritten.
|
||||
See <a href="../radio_profiles/#esp32-companion-ethernet-over-lora-kiss">Ethernet setup, host commands and limits</a>.</p>
|
||||
<h2 id="full-firmware-raw-radio2-kiss-modem">Full firmware raw radio2 KISS modem</h2>
|
||||
<pre><code class="language-text">get kiss
|
||||
set kiss.transport usb
|
||||
set kiss on
|
||||
set kiss off
|
||||
</code></pre>
|
||||
<p>Full ESP32 and nRF52 LoRa images can keep their normal MeshCore role on
|
||||
radio1 while a connected computer sends and receives raw packets on radio2.
|
||||
The setting is saved and defaults to <strong>off</strong>. First configure an explicit
|
||||
saved <code>radio2</code> tuple in <code>rxtx</code> mode. <code>get kiss</code> reports the transport, state,
|
||||
packet counters and any radio2 conflict. Setting changes require a local
|
||||
USB, BLE or network management connection.</p>
|
||||
<p>With USB selected, the normal CLI stays available until the computer sends
|
||||
a KISS frame delimiter (<code>0xC0</code>). That session then owns USB; functional text
|
||||
and debug logging are suppressed without changing their saved preferences.
|
||||
KISS RETURN (<code>C0 FF C0</code>) or a detected USB disconnect returns to the CLI.</p>
|
||||
<p>On ESP32, <code>set kiss.transport tcp</code> selects a separate KISS listener on the
|
||||
station WiFi address, port <strong>5004</strong>. It does not start WiFi or listen on the
|
||||
setup AP. One computer can connect at a time. This is an unauthenticated raw
|
||||
modem endpoint for a trusted LAN, like the existing Ethernet KISS service.</p>
|
||||
<p>KISS port 0 DATA maps only to radio2. Packets are 1-255 bytes, unchanged over
|
||||
the air, using the normal private LoRa sync word, explicit headers, CRC and
|
||||
normal IQ. The host must honor transmit pacing. This interface does not add
|
||||
RNode framing, fragmentation or Reticulum routing; those remain host tasks.
|
||||
See <a href="../kiss_modem_protocol/#full-firmware-host-kiss">Full host KISS framing and limits</a>
|
||||
for the wire protocol and session rules.</p>
|
||||
<h2 id="set-repeater-room-server-and-sensor-reply-profiles">Set repeater, room-server, and sensor reply profiles</h2>
|
||||
<pre><code class="language-text">get tx.reply
|
||||
set tx.reply both
|
||||
|
||||
@@ -1914,6 +1914,34 @@
|
||||
</span>
|
||||
</a>
|
||||
|
||||
<nav class="md-nav" aria-label="Serial Configuration">
|
||||
<ul class="md-nav__list">
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#full-firmware-host-kiss" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
|
||||
Full firmware host KISS
|
||||
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#dedicated-modem-serial-configuration" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
|
||||
Dedicated modem serial configuration
|
||||
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
</nav>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
@@ -2862,6 +2890,34 @@
|
||||
</span>
|
||||
</a>
|
||||
|
||||
<nav class="md-nav" aria-label="Serial Configuration">
|
||||
<ul class="md-nav__list">
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#full-firmware-host-kiss" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
|
||||
Full firmware host KISS
|
||||
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#dedicated-modem-serial-configuration" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
|
||||
Dedicated modem serial configuration
|
||||
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
</nav>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
@@ -3286,6 +3342,91 @@
|
||||
time-shared LoRa profile. It is still one physical transceiver: the firmware
|
||||
fast-switches between <code>radio</code> and <code>radio2</code>; it does not create a second radio.</p>
|
||||
<h2 id="serial-configuration">Serial Configuration</h2>
|
||||
<h3 id="full-firmware-host-kiss">Full firmware host KISS</h3>
|
||||
<p>Full ESP32 and nRF52 LoRa firmware includes a separate, default-off raw
|
||||
radio2 host service. It preserves the device's normal Companion, Repeater,
|
||||
Room Server or Sensor role on radio1. It is enabled in the Full sensor/OTA
|
||||
profile on nRF52; reduced infrastructure images omit the service.</p>
|
||||
<p>Configure the desired saved radio2 RF tuple in <code>rxtx</code> mode, then use:</p>
|
||||
<pre><code class="language-text">set kiss.transport usb
|
||||
set kiss on
|
||||
get kiss
|
||||
</code></pre>
|
||||
<p>Both choices are saved. <code>set kiss off</code> stops the service and releases its
|
||||
runtime radio2 protocol lease without changing the saved radio2 tuple.
|
||||
Temporary radio settings and Meshtext/Ethernet radio2 owners block admission.
|
||||
The service never chooses a frequency, takes another service's radio2 lease,
|
||||
crosses raw packets onto radio1, or feeds them into MeshCore parsing/bridges.
|
||||
If the initial radio2 change is still pending, the connection waits and sends
|
||||
READY when radio2 becomes available; no reconnect is needed. DATA received
|
||||
while waiting is discarded, so hosts should wait for the initial READY.</p>
|
||||
<p>USB remains the normal CLI until an initial KISS FEND (<code>C0</code>). A delimiter
|
||||
inside an unfinished Companion frame or an active mOTA session keeps its
|
||||
original protocol ownership. During the raw
|
||||
session, USB Companion framing and text/debug output are parked. Send the
|
||||
standard KISS RETURN frame (<code>C0 FF C0</code>) to leave the session, then issue CLI
|
||||
commands normally. A detected USB disconnect/reset also ends the session.
|
||||
UART-to-USB adapters without a disconnect signal may require RETURN.
|
||||
If the radio2 settings change mid-session, USB stays quarantined until RETURN
|
||||
or disconnect, so leftover binary bytes cannot become CLI commands.
|
||||
For Espressif USB-Serial/JTAG (<code>303A:1001</code>), open the host port with DTR and
|
||||
RTS deasserted; those lines control boot/reset selection. Other USB CDC
|
||||
devices, including nRF52/TinyUSB, retain their normal DTR handling.</p>
|
||||
<p>ESP32 also supports <code>set kiss.transport tcp</code>. Enable station WiFi separately
|
||||
and connect to its address on TCP <strong>5004</strong>. The service accepts one client,
|
||||
does not bind the setup AP, and has no authentication. Use a trusted LAN.
|
||||
WiFi loss, RETURN, setting changes and invalidated radio2 generations close
|
||||
the connection and discard queued host work. A second client cannot displace
|
||||
an existing owner. USB remains available for management in TCP mode.</p>
|
||||
<p>The Full service uses standard KISS escaping and the following frames:</p>
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Type</th>
|
||||
<th>Direction</th>
|
||||
<th>Payload and meaning</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><code>00</code></td>
|
||||
<td>Both</td>
|
||||
<td>Raw DATA, 1-255 bytes, exclusively radio2</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>0F</code></td>
|
||||
<td>Device to host</td>
|
||||
<td><code>01</code>: READY, initially and after each completed TX</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>06</code></td>
|
||||
<td>Device to host</td>
|
||||
<td><code>F8 01</code>: TX succeeded; <code>F8 00</code>: TX failed</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>FF</code></td>
|
||||
<td>Host to device</td>
|
||||
<td>Empty payload: RETURN to CLI/close TCP</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>Other ports and parameter/control commands are ignored. RF parameters are
|
||||
configured through the ordinary saved radio2 CLI, not RNode control commands.
|
||||
Wait for READY before sending the next packet. The device retains at most
|
||||
two queued host frames plus one in-flight transmission, uses bounded I/O,
|
||||
and preserves normal CAD, duty budget and MeshCore transmit fairness.
|
||||
<code>get kiss</code> includes RX/TX/failure/drop/malformed counters. A drop counter can
|
||||
include received packets that could not fit in the bounded host output queue.</p>
|
||||
<p>The raw RF payload has no additional header. It uses the ordinary private
|
||||
LoRa sync word (<code>0x12</code>, represented as <code>0x1424</code> by SX126x), explicit headers,
|
||||
CRC and normal IQ. Peers must match RF parameters, including preamble timing
|
||||
appropriate for the time-shared receiver. Only one physical radio is present.</p>
|
||||
<p>This is a generic host modem. Reticulum/RNode interoperability requires host
|
||||
adaptation for RNode's one-byte RF header, fragmentation/reassembly of larger
|
||||
packets and transmit pacing. The Full image runs no Reticulum router and
|
||||
imports no RNode firmware code. The separate dedicated KISS firmware below
|
||||
retains its original two-port interface and binary configuration extensions.</p>
|
||||
<h3 id="dedicated-modem-serial-configuration">Dedicated modem serial configuration</h3>
|
||||
<p>115200 baud, 8N1, no flow control.</p>
|
||||
<h2 id="frame-format">Frame Format</h2>
|
||||
<p>Standard KISS framing per the KA9Q/K3MC specification.</p>
|
||||
|
||||
@@ -3088,6 +3088,13 @@ devices reject LoRa profile commands. KISS is a raw host-controlled modem: it
|
||||
exposes equivalent RAM-only binary <code>SetRadio2</code>/<code>SetTempRadio2</code> commands and
|
||||
logical KISS Data ports, documented in <a href="../kiss_modem_protocol/">the KISS modem protocol</a>.
|
||||
It does not use the Mesh CLI's persistent profile file or Mesh retry queues.</p>
|
||||
<p>Full ESP32 and nRF52 LoRa images also offer an optional
|
||||
<a href="../kiss_modem_protocol/#full-firmware-host-kiss">raw host KISS service</a>.
|
||||
<code>set kiss on</code> enables it, default off, while radio1 retains its normal role.
|
||||
It borrows an explicitly configured saved <code>radio2</code> profile for the host's
|
||||
session. Meshtext, Ethernet and temporary radio2 owners cannot share that
|
||||
lease. This service is a raw modem; the connected computer handles its own
|
||||
network protocol and routing.</p>
|
||||
<h2 id="quick-setup">Quick setup</h2>
|
||||
<p>Keep the primary channel configured with <code>radio</code>, then add the second:</p>
|
||||
<pre><code class="language-text">set radio2 910.5,500,8,5,rx
|
||||
|
||||
@@ -2676,6 +2676,15 @@ with that color framebuffer must have at least 72 KiB available before startup a
|
||||
Headless and OLED devices use their own smaller totals. The JSON lists each
|
||||
component and checks the largest available region against the largest planned
|
||||
single allocation.</p>
|
||||
<p>Enabled Full host KISS images reserve a separate 2,048-byte
|
||||
<code>host_kiss_codec</code> allocation on ESP32 and nRF52, including while KISS is saved
|
||||
off. Turning the service on allocates its two host-TX and two encoded-output
|
||||
frames plus parser state. The source assertion bounds the complete Codec and
|
||||
allocator headroom to this allowance. WiFi/TCP retains its existing network
|
||||
allowance; the independent transient margin and all normal-role capacities
|
||||
remain additive. Explicit feature-off and ESP-NOW-only images omit this
|
||||
allocation. A passing report proves linked capacity, not physical session or
|
||||
maximum network-load qualification.</p>
|
||||
<h3 id="mqtt-startup-minimum-and-runtime-qualification">MQTT startup minimum and runtime qualification</h3>
|
||||
<p>The <code>mqtt_startup_allowance</code> component keeps a 24,576-byte internal startup
|
||||
minimum for the default 8,192-byte MQTTBridge worker stack and two active
|
||||
|
||||
@@ -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":"Home","text":"<p>View this page on MeshCore Docs.</p>"},{"location":"#meshcore-documentation","title":"MeshCore documentation","text":""},{"location":"#start-here","title":"Start here","text":"<p>Current stable release: 1.18.0.1 USA Cascade. Read what changed, which boards benefit and the known limitations in one place.</p> I want to... Start here See what is new or fixed 1.18.0.1 release notes Download firmware for my board Firmware picker Install an update Update guide Turn a feature on or off Feature controls by role Find a command CLI reference Troubleshoot a device FAQ"},{"location":"#detailed-guides","title":"Detailed guides","text":"<ul> <li> <p>SolarXiao Base/Advanced/MPPT detection and battery controls</p> </li> <li> <p>Feature switches by role and Full Companion features</p> </li> <li>Firmware update guide, easy LoRa OTA, and scripted LoRa OTA</li> <li>CLI commands, availability by build, and radio profiles</li> <li>Private fleet management: signed filtering and secondary-radio commands for a fleet or one node</li> <li>Room history, moderation, and information board: optional persistent chat and local Wi-Fi room access</li> <li>Companion protocol, packet format, and QR codes</li> </ul> <p>The navigation groups the remaining guides under Documentation, including board-specific updates, networking, power, and protocol references.</p>"},{"location":"#tools","title":"Tools","text":"<ul> <li>Firmware picker and USB web console</li> <li>Notification builder and temporary radio test builder</li> <li>Filter policy playground, telemetry decoder, and management report decoder</li> </ul>"},{"location":"#engineering-records","title":"Engineering records","text":"<ul> <li>Test Results - hardware and build evidence, with the tested versions</li> <li>Research - design notes, diagnostics, and historical update-chain studies</li> <li>Old Releases - historical release notes and supporting files</li> </ul> <p>Found a mistake or missing information? Edit the documentation.</p>"},{"location":"WiFi/","title":"WiFi","text":"<p>View this page on MeshCore Docs.</p>"},{"location":"WiFi/#wifi-and-mqtt-by-firmware-type","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. USB logging does not itself provide MQTT. MQTT-capable Full Companions include that feature without <code>mqtt</code> in their filename; check the artifact capability manifest. See feature switches by role for the different Companion and infrastructure controls and the USB web console.</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 <code>*_companion_radio_full*</code> ESP32, subject to board/transport selection Where compiled on ESP32 Includes supported USB/wireless transports; configure MQTT through WebConfig Dedicated USB, BLE, or serial companion (not Full) 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-dependenLine truncated
|
||||
{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"],"fields":{"title":{"boost":1000.0},"text":{"boost":1.0},"tags":{"boost":1000000.0}}},"docs":[{"location":"","title":"Home","text":"<p>View this page on MeshCore Docs.</p>"},{"location":"#meshcore-documentation","title":"MeshCore documentation","text":""},{"location":"#start-here","title":"Start here","text":"<p>Current stable release: 1.18.0.1 USA Cascade. Read what changed, which boards benefit and the known limitations in one place.</p> I want to... Start here See what is new or fixed 1.18.0.1 release notes Download firmware for my board Firmware picker Install an update Update guide Turn a feature on or off Feature controls by role Find a command CLI reference Troubleshoot a device FAQ"},{"location":"#detailed-guides","title":"Detailed guides","text":"<ul> <li> <p>SolarXiao Base/Advanced/MPPT detection and battery controls</p> </li> <li> <p>Feature switches by role and Full Companion features</p> </li> <li>Firmware update guide, easy LoRa OTA, and scripted LoRa OTA</li> <li>CLI commands, availability by build, and radio profiles</li> <li>Private fleet management: signed filtering and secondary-radio commands for a fleet or one node</li> <li>Room history, moderation, and information board: optional persistent chat and local Wi-Fi room access</li> <li>Companion protocol, packet format, and QR codes</li> </ul> <p>The navigation groups the remaining guides under Documentation, including board-specific updates, networking, power, and protocol references.</p>"},{"location":"#tools","title":"Tools","text":"<ul> <li>Firmware picker and USB web console</li> <li>Notification builder and temporary radio test builder</li> <li>Filter policy playground, telemetry decoder, and management report decoder</li> </ul>"},{"location":"#engineering-records","title":"Engineering records","text":"<ul> <li>Test Results - hardware and build evidence, with the tested versions</li> <li>Research - design notes, diagnostics, and historical update-chain studies</li> <li>Old Releases - historical release notes and supporting files</li> </ul> <p>Found a mistake or missing information? Edit the documentation.</p>"},{"location":"WiFi/","title":"WiFi","text":"<p>View this page on MeshCore Docs.</p>"},{"location":"WiFi/#wifi-and-mqtt-by-firmware-type","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. USB logging does not itself provide MQTT. MQTT-capable Full Companions include that feature without <code>mqtt</code> in their filename; check the artifact capability manifest. See feature switches by role for the different Companion and infrastructure controls and the USB web console.</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 <code>*_companion_radio_full*</code> ESP32, subject to board/transport selection Where compiled on ESP32 Includes supported USB/wireless transports; configure MQTT through WebConfig Dedicated USB, BLE, or serial companion (not Full) 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-dependenLine truncated
|
||||
Reference in new issue
Block a user