deploy: 58724c9100

payloads/index.html

@@ -4031,7 +4031,7 @@ signature, so any channel-key holder can choose any sender name.</p>
 <tr>
 <td>flags</td>
 <td>1</td>
-<td>0x8 (upper 4 bits), prefix_only (lowest bit)</td>
+<td>0x8 (upper 4 bits), prefix_only (bit 0), request radio2 profile (bit 1)</td>
 </tr>
 <tr>
 <td>type_filter</td>
@@ -4082,6 +4082,9 @@ signature, so any channel-key holder can choose any sender name.</p>
 </tr>
 </tbody>
 </table>
+<p>Repeaters append an optional <a href="../radio_profiles/#discover-the-local-radio2-profile">radio2 profile trailer</a>
+when request bit 1 is set. Without that bit, the response is unchanged. Legacy
+responders omit the trailer even when requested.</p>
 <h2 id="trace">Trace</h2>
 <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

radio_profiles/index.html

@@ -1311,6 +1311,17 @@
     </span>
   </a>
   
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#discover-the-local-radio2-profile" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        Discover the local radio2 profile
+      
+    </span>
+  </a>
+  
 </li>
         
           <li class="md-nav__item">
@@ -2608,6 +2619,17 @@
     </span>
   </a>
   
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#discover-the-local-radio2-profile" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        Discover the local radio2 profile
+      
+    </span>
+  </a>
+  
 </li>
         
           <li class="md-nav__item">
@@ -2934,6 +2956,70 @@ Apps do not need to set <code>tx.media</code>. Ordinary traffic keeps its existi
 If the second profile cannot transmit MeshCore, media uses the normal
 channel/global route; <code>set tx.media radio2</code> instead requires radio2 with no
 primary fallback. See <a href="#companion-media-and-ssh-tx-routing">application TX routing</a>.</p>
+<h3 id="discover-the-local-radio2-profile">Discover the local radio2 profile</h3>
+<p>Clients can request a repeater's current MeshCore radio2 profile through public,
+zero-hop discovery. Set bit 1 (<code>0x02</code>) of the <code>DISCOVER_REQ</code> flags byte: <code>0x82</code>
+for the full public key, or <code>0x83</code> with the prefix-only bit also set. The type
+filter, tag and optional <code>since</code> fields keep their existing meanings. Omit
+<code>since</code> or send zero when requesting current settings; radio changes do not
+update the discovery timestamp.</p>
+<p>The requested <code>DISCOVER_RESP</code> appends this version-1 trailer immediately after
+the public key, at payload offset 38 (full key) or 14 (8-byte prefix):</p>
+<table>
+<thead>
+<tr>
+<th>Field</th>
+<th>Bytes</th>
+<th>Meaning</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>version</td>
+<td>1</td>
+<td><code>1</code></td>
+</tr>
+<tr>
+<td>flags</td>
+<td>1</td>
+<td>Bit 0: configured; bits 1–2: mode (<code>0</code> off, <code>1</code> rx, <code>2</code> rxtx); bit 3: temporary; other bits zero</td>
+</tr>
+<tr>
+<td>frequency</td>
+<td>4</td>
+<td>Little-endian unsigned integer, MHz × 1000, rounded</td>
+</tr>
+<tr>
+<td>bandwidth</td>
+<td>4</td>
+<td>Little-endian unsigned integer, kHz × 1000, rounded</td>
+</tr>
+<tr>
+<td>SF</td>
+<td>1</td>
+<td>Spreading factor</td>
+</tr>
+<tr>
+<td>CR</td>
+<td>1</td>
+<td>Coding-rate denominator (<code>5</code> means 4/5)</td>
+</tr>
+</tbody>
+</table>
+<p>For example, the MediaMesh preset reports frequency <code>911150</code>, bandwidth
+<code>250000</code>, SF <code>7</code>, CR <code>5</code> and flags <code>0x05</code>. An active <code>tempradio2</code> reports its
+current settings with bit 3 set. Clients use automatic preamble; the trailer
+does not carry a preamble value.</p>
+<p>When radio2 is off, unsupported, or using a foreign protocol, the trailer is
+only <code>[1][0]</code>. Full responses are therefore 50 bytes with a profile or 40 bytes
+without one; prefix-only responses are 26 or 16 bytes. Without the request bit,
+responses remain 38 or 14 bytes. A legacy responder's missing trailer means
+unsupported, not disabled. Clients should ignore unknown versions and
+incomplete trailers.</p>
+<p>Replies remain on the main radio with zero hops and share the existing limit
+of four replies per two minutes. Existing visibility controls still apply.
+Discovery is public and unauthenticated. See <a href="../payloads/#control-data">control data</a>
+for the base packet fields.</p>
 <h3 id="channel-spacing">Channel spacing</h3>
 <p>When setting a saved, temporary or scheduled second profile, the response warns
 if its occupied bandwidth overlaps the primary channel or comes within <strong>6 kHz

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":"Home","text":"<p>View this page on MeshCore Docs.</p>"},{"location":"#meshcore-documentation","title":"MeshCore documentation","text":"<p>Choose firmware with the firmware picker. For help with a device already in service, start with the FAQ.</p>"},{"location":"#current-release","title":"Current release","text":"<ul> <li>1.17.1.8 USA Cascade release notes</li> <li>Test Results \u2014 validation archive and 1.17.1.8 Preview 1 qualification evidence</li> </ul>"},{"location":"#documentation","title":"Documentation","text":"<ul> <li>Feature switches by role and Full Companion features</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>Research \u2014 design notes, diagnostics, and historical update-chain studies</li> <li>Old Releases \u2014 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-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 LeaLine 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":"<p>Choose firmware with the firmware picker. For help with a device already in service, start with the FAQ.</p>"},{"location":"#current-release","title":"Current release","text":"<ul> <li>1.17.1.8 USA Cascade release notes</li> <li>Test Results \u2014 validation archive and 1.17.1.8 Preview 1 qualification evidence</li> </ul>"},{"location":"#documentation","title":"Documentation","text":"<ul> <li>Feature switches by role and Full Companion features</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>Research \u2014 design notes, diagnostics, and historical update-chain studies</li> <li>Old Releases \u2014 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-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 LeaLine truncated