deploy: 7916f144f2

_javascript/firmware_picker.js

@@ -658,6 +658,42 @@
     });
   }
 
+  function stationG3SharedSlotProfile(profile) {
+    const controls = profile && profile.controls;
+    return Boolean(controls && controls.platform === "ESP32_PLATFORM" &&
+      controls.radioSlotAuto === true && controls.radioSlotFamily === "sx1262" &&
+      /^[0-9a-f]{40}$/.test(controls.radioSlotSource || "") &&
+      Array.isArray(profile.files) && profile.files.length > 0 &&
+      profile.files.every(function (file) {
+        const hash = String(file.name || "").match(/-([0-9a-f]{8,40})(?:-merged)?\.(?:bin|hex|uf2|zip)$/i);
+        return hash && controls.radioSlotSource.startsWith(hash[1].toLowerCase());
+      }));
+  }
+
+  function hardwareChoiceLabel(field, value, profiles, family) {
+    const matches = (profiles || []).filter(function (profile) {
+      return profile[field] === value;
+    });
+    if (value === "Station_G3_ESP32" && matches.length > 0 &&
+        matches.every(function (profile) {
+          return profile.hardware === "Station_G3_ESP32" && stationG3SharedSlotProfile(profile);
+        })) {
+      return "Station G3 ESP32 (automatic slot detection)";
+    }
+    return field === "hardware" && family
+      ? humanizeHardwareVariant(value, family) : humanizeHardware(value);
+  }
+
+  function omitStationG3SlotDuplicates(profiles) {
+    const successors = new Set((profiles || []).filter(stationG3SharedSlotProfile)
+      .map(function (profile) { return profile.target; }));
+    return (profiles || []).filter(function (profile) {
+      const target = String(profile.target || "");
+      const match = /^Station_G3_ESP32_r2_(repeater(?:_observer_mqtt)?|room_server(?:_observer_mqtt)?|sensor)((?:-(?:full|reduced|usb|wifi|logging|ota))*)$/.exec(target);
+      return !match || !successors.has("Station_G3_ESP32_" + match[1] + match[2]);
+    });
+  }
+
   function omitRakStorageProfilesWhenUnified(profiles) {
     const targets = new Set((profiles || []).map(function (profile) {
       return String(profile && profile.target || "").toLowerCase();
@@ -972,7 +1008,9 @@
     return {
       releaseSet: releaseSet,
       rows: firmwareRows,
-      profiles: profiles,
+      // Old releases have no shared-slot proof and retain both choices. Raw
+      // assets remain searchable even when a new exact successor replaces R2.
+      profiles: omitStationG3SlotDuplicates(profiles),
     };
   }
 
@@ -1285,6 +1323,18 @@
     FACET_FIELDS.forEach(function (field) {
       requested[field] = params.get(field) || "";
     });
+    if (!profiles.some(function (profile) {
+          return profile.hardware === "Station_G3_ESP32_r2" &&
+            (!requested.role || profile.role === requested.role);
+        }) &&
+        profiles.some(function (profile) {
+          return profile.hardware === "Station_G3_ESP32" && stationG3SharedSlotProfile(profile) &&
+            (!requested.role || profile.role === requested.role);
+        })) {
+      ["hardware", "hardwareFamily"].forEach(function (field) {
+        if (requested[field] === "Station_G3_ESP32_r2") requested[field] = "Station_G3_ESP32";
+      });
+    }
     // Handwritten links may specify just the exact hardware variant.
     if (requested.hardware && !requested.hardwareFamily) {
       const profile = profiles.find(function (item) {
@@ -1511,6 +1561,9 @@
     const target = profile.target;
     const info = profile.controls || {};
     const notes = [];
+    if (identity.hardware === "Station_G3_ESP32" && stationG3SharedSlotProfile(profile)) {
+      notes.push("Automatically selects physical radio slot 1 or 2. Use this same image for either slot.");
+    }
     const rak = /^RAK_(3401|4631)_repeater_unified_lora_ota(?:-(?:full|reduced)(?:-ota)?)?$/i.exec(target);
     const lora = info.updateRequirements && info.updateRequirements.lora;
     if (rak && info.platform === "NRF52_PLATFORM" && profile.ota === "lora-receiver" &&
@@ -1976,7 +2029,7 @@
     card.className = "firmware-picker-card";
     card.appendChild(createElement(
       "h3",
-      humanizeHardware(profile.hardware) + " - " +
+      hardwareChoiceLabel("hardware", profile.hardware, [profile]) + " - " +
         (ROLE_LABELS[profile.role] || profile.role)
     ));
 
@@ -2140,6 +2193,8 @@
 
     function setSelectOptions(select, field, values, selected) {
       select.replaceChildren();
+      const hardwareProfiles = field === "hardware" || field === "hardwareFamily"
+        ? matchingProfiles(field) : [];
       const placeholders = {
         chipFamily: "Any chip family - skip this filter",
         hardwareFamily: "Any hardware",
@@ -2153,8 +2208,8 @@
       values.slice().sort(function (a, b) {
         return optionSort(field, a, b);
       }).forEach(function (value) {
-        const label = field === "hardware"
-          ? humanizeHardwareVariant(value, filters.hardwareFamily)
+        const label = field === "hardware" || field === "hardwareFamily"
+          ? hardwareChoiceLabel(field, value, hardwareProfiles, filters.hardwareFamily)
           : labelFor(field, value, filters.hardware || filters.hardwareFamily);
         const option = createElement("option", label);
         option.value = value;
@@ -2165,12 +2220,14 @@
     }
 
     function setRadioOptions(container, field, values, selected) {
+      const hardwareProfiles = field === "hardware" || field === "hardwareFamily"
+        ? matchingProfiles(field) : [];
       const options = [{ value: "", label: "Any" }].concat(
         values.slice().sort(function (a, b) {
           return optionSort(field, a, b);
         }).map(function (value) {
-          return { value: value, label: field === "hardware"
-            ? humanizeHardwareVariant(value, filters.hardwareFamily)
+          return { value: value, label: field === "hardware" || field === "hardwareFamily"
+            ? hardwareChoiceLabel(field, value, hardwareProfiles, filters.hardwareFamily)
             : labelFor(field, value, filters.hardware || filters.hardwareFamily) };
         })
       );
@@ -2627,6 +2684,7 @@
     omitTransportsReplacedByFull: omitTransportsReplacedByFull,
     omitLegacyObserverCompatibilityProfiles:
       omitLegacyObserverCompatibilityProfiles,
+    omitStationG3SlotDuplicates: omitStationG3SlotDuplicates,
     omitTransportsReplacedByDualCdcFull:
       omitTransportsReplacedByFull,
     omitNrf52TransportsReplacedByFull:
@@ -2663,6 +2721,7 @@
     migrationAssetForProfile: migrationAssetForProfile,
     migrationLink: migrationLink,
     humanizeHardware: humanizeHardware,
+    hardwareChoiceLabel: hardwareChoiceLabel,
     humanizeVariant: humanizeVariant,
     labelFor: labelFor,
     formatBytes: formatBytes,

cli_commands/index.html

@@ -2360,6 +2360,17 @@
     </span>
   </a>
   
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#select-the-station-g3-physical-radio-slot" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        Select the Station G3 physical radio slot
+      
+    </span>
+  </a>
+  
 </li>
         
       </ul>
@@ -5286,6 +5297,17 @@
     </span>
   </a>
   
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#select-the-station-g3-physical-radio-slot" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        Select the Station G3 physical radio slot
+      
+    </span>
+  </a>
+  
 </li>
         
       </ul>
@@ -6879,7 +6901,9 @@ RX-only mode, cross-transmission policy, and optional radio preambles.</p>
 for <code>mt-</code> channels and the explicit <code>send mt.nodeinfo &lt;channel slot&gt;</code> command.
 Chat remains plain text. A separate GPS-free NodeInfo is sent after the first
 successful chat transmission per used channel/identity per boot; the explicit
-command can also request one. MT heard-repeat retries use the Companion's
+command can also request one. Automatic metadata waits for a 250 ms gap after
+the latest successful MT transmission; explicit requests bypass that gap.
+MT heard-repeat retries use the Companion's
 <code>flood.retry.count</code>, with the metadata cap and <code>flood.retry.advert</code> gate for
 NodeInfo.</p>
 <p>See <a href="../carrier_wave/">carrier-wave RF checks</a> for <code>cw on [seconds]</code>,
@@ -8603,6 +8627,30 @@ Station G2/G3 targets default to <code>off</code>.</p>
 - 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>
 <hr />
+<h4 id="select-the-station-g3-physical-radio-slot">Select the Station G3 physical radio slot</h4>
+<pre><code class="language-text">get radio.slot
+set radio.slot auto
+set radio.slot 1
+set radio.slot 2
+reboot
+</code></pre>
+<p>Station G3 SX1262 builds support both physical RF sockets in the same image.
+The default, <code>auto</code>, probes both sockets at boot without transmitting. If both
+work, it prefers the last successfully used socket; on a fresh installation,
+it prefers socket 1. A forced <code>1</code> or <code>2</code> never silently uses the other socket.</p>
+<p><code>get radio.slot</code> reports the saved selection, active socket, detected sockets,
+and whether a reboot is needed. Changes are saved immediately but applied only
+after reboot, never during a transmission. The selector does not change keys,
+node settings, or the time-shared <code>radio2</code> profile. The legacy <code>_r2</code> build name
+means physical socket 2, not a motherboard revision; both build names now
+support this selector.</p>
+<p>If no usable socket is found, startup waits with both LNAs disabled instead of
+reboot-looping. A limited USB recovery console accepts <code>!g3 get radio.slot</code>,
+<code>!g3 set radio.slot auto|1|2</code>, <code>!g3 reboot</code>, and <code>!g3 help</code>. The <code>!g3</code> prefix is
+required in this recovery console; it is not the normal running CLI. KISS
+firmware uses binary slot commands during normal operation, documented in the
+<a href="../kiss_modem_protocol/">KISS protocol</a>.</p>
+<hr />
 <h3 id="system">System</h3>
 <h4 id="view-or-change-this-nodes-name">View or change this node's name</h4>
 <p><strong>Usage:</strong>
@@ -9219,6 +9267,16 @@ the BLE/WiFi drivers, ESP-NOW, GPS UART, logging, and USB host sessions are
 inactive and no work is pending. Compiling those transports into Full does not
 itself prevent sleep. Turning off BLE advertising alone leaves its controller
 running and therefore retains idle behavior rather than manual light sleep.</p>
+<p>An active radio2 requires continuous software scanning. With power saving on,
+ESP32 Companion, Repeater, Room and Sensor builds do not insert the ordinary
+1 ms idle delay while dual-radio scanning is active. This avoids delaying
+sub-millisecond scan visits; it does not make active dual-radio scanning a sleep mode.</p>
+<p>The verified Meshnology W12 layout enables the LR2021 radio's DC-DC regulator
+after LoRa and Morse receive initialization, including recovery. This setting
+is independent of <code>powersaving</code> and does not remove radio features. Other
+LR2021 layouts retain their existing regulator behavior unless their recipe
+explicitly enables <code>LR2021_USE_DCDC</code> after confirming the required inductor;
+the X1 is not opted in without that hardware confirmation.</p>
 <hr />
 <h4 id="view-or-set-the-reboot-interval-repeater-and-room-server">View or set the reboot interval (Repeater and room server)</h4>
 <p><strong>Usage:</strong>

kiss_modem_protocol/index.html

@@ -1958,6 +1958,17 @@
     </span>
   </a>
   
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#station-g3-physical-radio-slot" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        Station G3 physical radio slot
+      
+    </span>
+  </a>
+  
 </li>
         
           <li class="md-nav__item">
@@ -2867,6 +2878,17 @@
     </span>
   </a>
   
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#station-g3-physical-radio-slot" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        Station G3 physical radio slot
+      
+    </span>
+  </a>
+  
 </li>
         
           <li class="md-nav__item">
@@ -3483,6 +3505,16 @@ Clients that need temporary-lease state can poll <code>GetTempRadio2</code>.</p>
 <td><code>0x20</code></td>
 <td>-</td>
 </tr>
+<tr>
+<td>GetRadioSlot</td>
+<td><code>0x22</code></td>
+<td>- (Station G3 only)</td>
+</tr>
+<tr>
+<td>SetRadioSlot</td>
+<td><code>0x23</code></td>
+<td>Mode (1): 0=auto, 1=slot 1, 2=slot 2 (Station G3 only)</td>
+</tr>
 </tbody>
 </table>
 <h3 id="response-sub-commands-tnc-to-host">Response Sub-commands (TNC to Host)</h3>
@@ -3622,6 +3654,11 @@ Clients that need temporary-lease state can poll <code>GetTempRadio2</code>.</p>
 <td>Saved radio2 parameters + protocol (14)</td>
 </tr>
 <tr>
+<td>RadioSlot</td>
+<td><code>0xA2</code></td>
+<td>Saved mode, active slot, detected mask, reboot needed (4 bytes)</td>
+</tr>
+<tr>
 <td>OK</td>
 <td><code>0xF0</code></td>
 <td>-</td>
@@ -3688,8 +3725,27 @@ Clients that need temporary-lease state can poll <code>GetTempRadio2</code>.</p>
 <td><code>0x07</code></td>
 <td>Radio TX busy, or host output queue full</td>
 </tr>
+<tr>
+<td>SaveFailed</td>
+<td><code>0x08</code></td>
+<td>Setting could not be saved; running slot unchanged</td>
+</tr>
 </tbody>
 </table>
+<h3 id="station-g3-physical-radio-slot">Station G3 physical radio slot</h3>
+<p><code>GetRadioSlot</code> takes no data and replies with four bytes: saved mode (<code>0</code> auto,
+<code>1</code> or <code>2</code> forced socket), active socket (<code>0</code> unavailable, <code>1</code> or <code>2</code>), detected
+socket mask (bit 0 = socket 1, bit 1 = socket 2), and reboot-needed flag (<code>0</code> or
+<code>1</code>). This selects the physical SX1262 daughterboard socket, not the logical
+<code>radio2</code> PHY profile. Other boards return <code>UnknownCmd</code>.</p>
+<p><code>SetRadioSlot</code> requires exactly one mode byte (<code>0</code>–<code>2</code>). An <code>OK</code> means the mode
+was saved; the running socket stays unchanged until a separate <code>Reboot</code> command
+or power cycle. Radio settings and identity are untouched. A failed save returns
+<code>SaveFailed</code>, with no change to the running socket.</p>
+<p>If no usable socket is found during boot, the normal KISS modem has not started.
+Use the separate USB recovery console: <code>!g3 get radio.slot</code>,
+<code>!g3 set radio.slot auto</code>, then <code>!g3 reboot</code>. Recovery accepts only these
+prefixed management commands (and <code>!g3 help</code>), never KISS packet payloads.</p>
 <h3 id="unsolicited-events">Unsolicited Events</h3>
 <p>The TNC sends these SetHardware frames without a preceding request:</p>
 <p><strong>TxDone (0xF8)</strong>: 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>

nrf52_power_management/index.html

@@ -1665,6 +1665,28 @@
     <nav class="md-nav" aria-label="Technical Details">
       <ul class="md-nav__list">
         
+          <li class="md-nav__item">
+  <a href="#rak-peripheral-shutdown" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        RAK peripheral shutdown
+      
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#xiao-battery-divider-safety" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        XIAO battery-divider safety
+      
+    </span>
+  </a>
+  
+</li>
+        
           <li class="md-nav__item">
   <a href="#architecture" class="md-nav__link">
     <span class="md-ellipsis">
@@ -2609,6 +2631,28 @@
     <nav class="md-nav" aria-label="Technical Details">
       <ul class="md-nav__list">
         
+          <li class="md-nav__item">
+  <a href="#rak-peripheral-shutdown" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        RAK peripheral shutdown
+      
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#xiao-battery-divider-safety" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        XIAO battery-divider safety
+      
+    </span>
+  </a>
+  
+</li>
+        
           <li class="md-nav__item">
   <a href="#architecture" class="md-nav__link">
     <span class="md-ellipsis">
@@ -2919,6 +2963,39 @@
   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>
 <h2 id="technical-details">Technical Details</h2>
+<h3 id="rak-peripheral-shutdown">RAK peripheral shutdown</h3>
+<p>Explicit power-off and timed deep sleep on RAK4631 and RAK3401 stop peripheral
+owners before switching off the shared <code>3V3_S</code> supply. On RAK4631, Ethernet
+must quiesce first; if its worker cannot stop within the bounded shutdown
+interval, keep its rail and bus intact instead of removing power during an SPI
+operation. Detected external-storage holds also retain the supply, including
+after an unresolved flash-operation timeout. Before storage discovery and
+configuration finish, rail removal is refused. Shutdown does not probe again,
+cancel a staged update, or float a storage owner's select pin.
+This does not change ordinary interrupt-idle sleep, boot/low-voltage
+protection, or the configured WisBlock GPS/shared-rail policy during normal
+operation.</p>
+<p>The <a href="https://images.docs.rakwireless.com/wisblock/rak19007/datasheet/power-schematic.png">RAK19007 power schematic</a>
+and <a href="https://images.docs.rakwireless.com/wisblock/rak13800/datasheet/image-20211116120503808.png">RAK13800 connector schematic</a>
+show that IO2 switches <code>3V3_S</code>, not the separate upstream PoE <code>VCC_IN</code> supply.
+Merely compiling Ethernet support therefore does not require this rail to
+stay on after terminal shutdown. The RAK4631 radio-enable GPIO controls the
+RF-switch supply, not the SX1262 core supply.</p>
+<p>RAK3401's external RAK13302 radio and RAK13800 Ethernet use the same IO slot,
+SPI signals, select pin and IO3 control. Their simultaneous operation is not
+supported; Ethernet owner registration on RAK3401 is rejected rather than
+allowing those electrically conflicting controls to run together.</p>
+<p>Software shutdown cannot remove every hardware leakage path. The baseboard
+has I2C pull-ups to unswitched VDD. RAK13302 VD's boost enable follows IO2, but
+the legacy VC default resistor configuration connects it directly to VBAT;
+that boost cannot be switched off by firmware alone.</p>
+<h3 id="xiao-battery-divider-safety">XIAO battery-divider safety</h3>
+<p>XIAO and XIAO-based Ikoka startup preload <code>READ_BAT_ENABLE</code> LOW before enabling
+its output. XIAO protective and user shutdown also keep it LOW. Seeed warns
+that HIGH can overvoltage the ADC input during charging, so this is not a
+safe pin to switch HIGH as a power optimization. The schematic's 1 MOhm +
+510 kOhm divider draws about 3 microamps at 4.2 V, not 3 milliamps. Charging
+current settings are unchanged. See <a href="https://wiki.seeedstudio.com/XIAO_BLE/#q3-what-are-the-considerations-when-using-xiao-nrf52840-sense-for-battery-charging">Seeed's battery guidance</a>.</p>
 <h3 id="architecture">Architecture</h3>
 <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>
 <h3 id="early-boot-capture">Early Boot Capture</h3>

radio_profiles/index.html

@@ -3321,10 +3321,15 @@ hexadecimal digits of the effective MT node ID. This does not change the
 MeshCore node name, add a label to chat text or transmit anything.</p>
 <p>After the first chat packet actually finishes transmitting on a configured MT
 channel, the Companion queues a separate, GPS-free <code>NODEINFO_APP</code> broadcast.
+Automatic metadata waits for a 250 ms gap after the most recent successful MT
+transmission, including retries, so a stock peer can re-arm its receiver.
+Explicit <code>send mt.nodeinfo</code> does not wait for this automatic-metadata gap.
 This happens once per used channel and sender identity per boot, not for every
 chat message. A rejected or failed chat send does not trigger it. There is no
 NodeInfo transmission just from booting, receiving traffic, changing settings
-or joining a channel, and there is no periodic NodeInfo timer.</p>
+or joining a channel, and there is no periodic NodeInfo timer.
+Changing the node name cancels old-name metadata retries; the next new
+successful chat announces the updated name without sending from the rename.</p>
 <p><code>send mt.nodeinfo &lt;channel slot&gt;</code> still explicitly queues <strong>one</strong> standard
 <code>NODEINFO_APP</code> broadcast on the selected configured MT channel. The slot is
 the Companion channel index, not <code>mt.slot</code> (the frequency slot). The packet

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

terminal_chat_cli/index.html

@@ -2544,6 +2544,7 @@ channel 0 Hello
 <p>Use a configured <code>mt-</code> channel slot. Chat carries only the entered text. After
 the first successful over-air chat transmission per used channel/identity per
 boot, the firmware queues a separate standard name/ID NodeInfo advertisement.
+Automatic metadata waits for a 250 ms quiet TX gap so the peer can resume RX.
 <code>send mt.nodeinfo</code> can also request one explicitly. Neither contains GPS or
 coordinates. No NodeInfo is sent just from booting, configuration, receiving
 traffic or a timer. The long name comes from the existing node name;