deploy: bd3a94bddb

_javascript/firmware_picker.js

@@ -403,9 +403,14 @@
     ].includes(target);
   }
 
-  function omitTransportsReplacedByDualCdcFull(profiles) {
+  function isFullCompanion(profile) {
+    return Boolean(profile && profile.role === "companion" &&
+      profile.mode === "full");
+  }
+
+  function omitTransportsReplacedByFull(profiles) {
     const fullKeys = new Set((profiles || []).filter(function (profile) {
-      return isDualCdcFullCompanion(profile);
+      return isFullCompanion(profile);
     }).map(function (profile) {
       return profile.hardware + "\n" + profile.variant;
     }));
@@ -419,16 +424,18 @@
     });
   }
 
-  function applyDualCdcFullCompanionCapabilities(profiles) {
+  function applyFullCompanionCapabilities(profiles) {
     return (profiles || []).map(function (profile) {
-      if (!isDualCdcFullCompanion(profile)) return profile;
+      if (!isFullCompanion(profile)) return profile;
 
-      // Supported Full Companion images always expose framed Companion traffic
-      // on interface 00. Logging defaults off; enabling it and rebooting adds
-      // the independent plaintext CDC interface 02.
+      // Every Full Companion has a runtime USB logging mode. Dual-CDC targets
+      // add an independent plaintext interface after reboot; single-TTY
+      // targets switch their existing port between framed and plaintext modes.
       profile.logging = "usb-runtime";
       profile.loggingModes = ["none", "usb"];
-      profile.dedicatedUsbLogging = true;
+      if (isDualCdcFullCompanion(profile)) {
+        profile.dedicatedUsbLogging = true;
+      }
       return profile;
     });
   }
@@ -532,8 +539,8 @@
     }).filter(function (profile) {
       return !isHiddenLegacyProfile(profile);
     });
-    const profiles = omitTransportsReplacedByDualCdcFull(
-      applyDualCdcFullCompanionCapabilities(visibleProfiles)
+    const profiles = omitTransportsReplacedByFull(
+      applyFullCompanionCapabilities(visibleProfiles)
     ).sort(function (a, b) {
       return a.target.localeCompare(b.target, undefined, {
         numeric: true,
@@ -731,13 +738,17 @@
         "With no saved SSID, the setup AP stays available for 30 minutes after each boot, then Wi-Fi powers off automatically until reboot or an explicit start webconfig command. A configured Wi-Fi mode keeps reconnecting instead."
       );
     } else if (profile.logging === "usb-runtime") {
-      extra.push(
-        "Full Companion starts with USB logging off and only interface 00. Use get usb.logging, or set usb.logging on reboot to save logging on and reboot when needed; set usb.logging off reboot removes interface 02 again."
-      );
       if (profile.dedicatedUsbLogging) {
+        extra.push(
+          "Full Companion starts with USB logging off and only interface 00. Use get usb.logging, or set usb.logging on reboot to add interface 02; set usb.logging off reboot removes it again."
+        );
         extra.push(
           "Interface 00 always carries Companion/terminal/mOTA traffic. After logging is enabled and the node reboots, interface 02 carries plaintext logs. Match services by USB interface number instead of assuming tty or COM numbering."
         );
+      } else {
+        extra.push(
+          "Full Companion starts with USB logging off and Binary Companion on its single TTY. Enter the text terminal and use set usb.logging on for plaintext logs; that TTY still accepts set usb.logging off and automatically returns to Binary Companion after the reply."
+        );
       }
     }
     return common.concat(byKind[kind] || [], extra);
@@ -1106,15 +1117,16 @@
     flattenReleaseAssets: flattenReleaseAssets,
     parseFirmwareAsset: parseFirmwareAsset,
     parseTargetProfile: parseTargetProfile,
-    applyDualCdcFullCompanionCapabilities:
-      applyDualCdcFullCompanionCapabilities,
+    applyFullCompanionCapabilities: applyFullCompanionCapabilities,
+    applyDualCdcFullCompanionCapabilities: applyFullCompanionCapabilities,
     applyNrf52FullCompanionCapabilities:
-      applyDualCdcFullCompanionCapabilities,
+      applyFullCompanionCapabilities,
     canonicalHardware: canonicalHardware,
+    omitTransportsReplacedByFull: omitTransportsReplacedByFull,
     omitTransportsReplacedByDualCdcFull:
-      omitTransportsReplacedByDualCdcFull,
+      omitTransportsReplacedByFull,
     omitNrf52TransportsReplacedByFull:
-      omitTransportsReplacedByDualCdcFull,
+      omitTransportsReplacedByFull,
     hardwareFamilyFor: hardwareFamilyFor,
     humanizeHardwareVariant: humanizeHardwareVariant,
     buildCatalog: buildCatalog,

cli_build_matrix/index.html

@@ -1503,7 +1503,7 @@ retain 50 because their MQTT discovery tables are constrained by internal DRAM.<
 </tr>
 <tr>
 <td>Standard logging</td>
-<td>Logging does not remove commands by itself. It has the same CLI as the selected role/profile and adds compiled logging behavior. CommonCLI roles persist <code>get/set usb.logging</code>. ESP32 roles covered by unified FULL and nRF52 Companions covered by dual-CDC Full Companion are not duplicated here.</td>
+<td>Logging does not remove commands by itself. It has the same CLI as the selected role/profile and adds compiled logging behavior. CommonCLI roles persist <code>get/set usb.logging</code>. Roles covered by a Full image with runtime logging are not duplicated here.</td>
 </tr>
 <tr>
 <td>LoRa-OTA (<code>-ota-</code>)</td>
@@ -1530,6 +1530,10 @@ retain 50 because their MQTT discovery tables are constrained by internal DRAM.<
 <td>nRF52 and qualified native-USB ESP32-S3 Full images use one physical USB connection. Fresh installs expose only interface <code>00</code> for framed Companion/terminal/mOTA traffic. Enabling logging and rebooting adds interface <code>02</code> for plaintext logs. They also provide BLE and source-only LoRa OTA; ESP32 additionally provides WiFi. <code>get/set usb.logging</code> persistently controls whether the logging interface is present.</td>
 </tr>
 <tr>
+<td>Single-TTY Full Companion</td>
+<td>ESP32 Full images without dual CDC start with framed Companion on their one TTY. <code>set usb.logging on</code> switches it to an input-capable plaintext logging terminal; <code>set usb.logging off</code> replies and then restores framed Companion automatically. BLE, WiFi, and source-only LoRa OTA remain available.</td>
+</tr>
+<tr>
 <td><code>no_external_sensors</code></td>
 <td>Removes optional external-sensor drivers and their settings; it does not remove core repeater discovery or routing commands. RAK3401 and RAK4631 profiles retain the four common INA I2C voltage/current monitors. GPS-preserving RAK nRF52 OTA profiles also retain their GPS commands and provider. The RAK4631 Serial1 RS232 bridge remains GPS-off because both features require Serial1. The legacy target suffix is retained for OTA identity compatibility.</td>
 </tr>
@@ -1550,16 +1554,13 @@ available from a canonical image:</p>
   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>When a board has a dual-CDC Full Companion, that one artifact replaces its
+<li>When a board has a Full Companion, that one artifact replaces its
   separate USB, BLE, ordinary WiFi, and USB packet-logging Companion artifacts.
-  Current support includes nRF52 Full Companion plus qualified native-USB
-  ESP32-S3 Full targets: Heltec V4, T-Beam 1W, Station G2/G3, XIAO S3 WIO,
-  Heltec Tracker V2, Meshnology W12, and Nibble Screen/Zero Connect. RAK3112
-  and Heltec RC32 keep separate transport and logging artifacts pending live
-  hardware validation.
-  It provides BLE plus an always-present interface <code>00</code> for framed
-  Companion/terminal/mOTA traffic. Enabling logging and rebooting adds
-  interface <code>02</code> for plaintext logs.
+  It provides BLE and source-only LoRa OTA; ESP32 also provides ordinary WiFi.
+  Dual-CDC builds keep framed traffic on interface <code>00</code> and add logging on
+  interface <code>02</code> after a reboot. Single-TTY builds switch interface <code>00</code> into
+  an input-capable logging terminal and restore Binary Companion when that
+  terminal session ends.
   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
@@ -1571,9 +1572,10 @@ available from a canonical image:</p>
 <p>The old aliases still work with <code>build-firmware</code> and
 <code>build-matching-firmwares</code>. Dedicated repeater LoRa OTA receiver images are not
 collapsed; they retain their exact storage, bootloader, role, and target
-identity contracts. ESP32 boards without the tested dual-CDC Full profile keep
-USB, BLE, WiFi, and Full Companion images separate because Full changes
-partitions, RAM use, active transports, and power behavior.</p>
+identity contracts. Companion boards keep transport-specific canonical images
+only when no exact Full recipe has passed the combined flash/RAM qualification.
+Dual CDC is not required: a qualified single-TTY Full image safely makes Binary
+Companion and plaintext USB logging mutually exclusive.</p>
 <h2 id="complete-cli-policy">Complete CLI policy</h2>
 <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

cli_command_availability/index.html

@@ -1868,7 +1868,7 @@ fix, no WiFi connection, an inactive bridge, or an nRF52 bootloader without
 <tr>
 <td>Logging</td>
 <td><a href="../cli_commands/#control-live-usb-logging"><code>get/set usb.logging</code>; unified FULL <code>get/set logging.output</code></a></td>
-<td>Logging artifacts; CommonCLI USB gate is persistent; unified ESP32 FULL selects off/USB/WiFi/both; dual-CDC Full Companion adds/removes its second USB port after reboot</td>
+<td>Logging artifacts; CommonCLI USB gate is persistent; unified ESP32 FULL selects off/USB/WiFi/both; Full Companion uses either a reboot-controlled second CDC or an input-capable single-TTY logging terminal</td>
 <td>No</td>
 <td>Yes</td>
 <td>No</td>
@@ -3207,7 +3207,7 @@ fix, no WiFi connection, an inactive bridge, or an nRF52 bootloader without
 <tr>
 <td>Logging</td>
 <td><a href="../cli_commands/#control-live-usb-logging"><code>get/set usb.logging</code>; unified FULL <code>get/set logging.output</code></a></td>
-<td>Logging artifacts; CommonCLI USB gate is persistent; unified ESP32 FULL selects off/USB/WiFi/both; dual-CDC Full Companion adds/removes its second USB port after reboot</td>
+<td>Logging artifacts; CommonCLI USB gate is persistent; unified ESP32 FULL selects off/USB/WiFi/both; Full Companion uses either a reboot-controlled second CDC or an input-capable single-TTY logging terminal</td>
 <td>No</td>
 <td>Yes</td>
 <td>No</td>

cli_commands/index.html

@@ -5630,9 +5630,10 @@ set usb.logging off
 set usb.logging on reboot
 set usb.logging off reboot
 </code></pre>
-<p>These commands are compiled into logging artifacts and control their 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.</p>
+<p>These commands are compiled into logging 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 starts off on a fresh installation.</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
@@ -5646,10 +5647,16 @@ without the optional <code>reboot</code> argument saves the choice and reports t
 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. This
-behavior includes nRF52 and qualified native-USB ESP32-S3 Full images.</p>
-<p>Turning USB logging off does not disable CLI replies or Companion protocol
-frames. It also does not change the node-storage capture controlled by <code>log
-start</code> and <code>log stop</code>.</p>
+behavior includes nRF52 and dual-CDC native-USB ESP32-S3 Full images.</p>
+<p>On a single-TTY 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. It remains an input-capable CLI, so <code>set usb.logging off</code> works on the
+same TTY and automatically restores Binary Companion after its reply. No
+reboot is needed because the USB interface count does not change.</p>
+<p>Turning USB logging off does not disable CLI replies. Dual-CDC builds keep
+Companion frames active on interface <code>00</code>; single-TTY builds resume frames when
+their terminal session ends. This setting does not change the node-storage
+capture controlled by <code>log start</code> and <code>log stop</code>.</p>
 <p>Unified ESP32 FULL builds add one saved selector for both output paths:</p>
 <pre><code class="language-text">get logging.output
 set logging.output off

companion_offline_queue/index.html

@@ -1324,6 +1324,10 @@ A reboot clears it.</p>
 <td style="text-align: right;">128</td>
 </tr>
 <tr>
+<td>Meshadventurer Full Companion</td>
+<td style="text-align: right;">64</td>
+</tr>
+<tr>
 <td>Constrained Full ESP32 fallback</td>
 <td style="text-align: right;">16</td>
 </tr>
@@ -1332,7 +1336,10 @@ A reboot clears it.</p>
 <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.
-Standard, logging, MQTT, and Cascade build overlays retain the selected target
+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

companion_radio_full/index.html

@@ -514,6 +514,17 @@
     <nav class="md-nav" aria-label="USB Binary and text terminal modes">
       <ul class="md-nav__list">
         
+          <li class="md-nav__item">
+  <a href="#single-usb-serial-port" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        Single USB serial port
+      
+    </span>
+  </a>
+  
+</li>
+        
           <li class="md-nav__item">
   <a href="#dual-usb-serial-ports" class="md-nav__link">
     <span class="md-ellipsis">
@@ -1361,6 +1372,17 @@
     <nav class="md-nav" aria-label="USB Binary and text terminal modes">
       <ul class="md-nav__list">
         
+          <li class="md-nav__item">
+  <a href="#single-usb-serial-port" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        Single USB serial port
+      
+    </span>
+  </a>
+  
+</li>
+        
           <li class="md-nav__item">
   <a href="#dual-usb-serial-ports" class="md-nav__link">
     <span class="md-ellipsis">
@@ -1516,12 +1538,22 @@ firmware as an mOTA image.</p>
 </tbody>
 </table>
 <h2 id="build-and-install">Build and install</h2>
-<p>The target is synthesized by <code>build.sh</code> only when matching transport recipes
-exist for the exact board variant:</p>
+<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>ESP32 requires matching WiFi, USB, and BLE Companion environments.</li>
-<li>nRF52 requires matching USB and BLE Companion environments.</li>
+<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, Heltec Wireless Tracker,
+Wireless Paper, E213, and CT62; LilyGo T3S3 SX1262/SX1276, T-Deck, TETH Elite,
+classic T-Beam SX1262/SX1276, and T-Beam S3 Supreme; Ebyte EoRa-S3;
+Meshadventurer SX1262/SX1268; and XIAO S3. 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>List the available targets:</p>
 <pre><code class="language-bash">bash build.sh list | grep companion_radio_full
 </code></pre>
@@ -1540,12 +1572,10 @@ interactive menu item or run:</p>
 <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. Dual-CDC Full Companion replaces separate USB, BLE,
-ordinary WiFi, and USB-only packet-logging release artifacts whenever the
-exact board supports the combined profile. This includes nRF52 Full Companion
-and the qualified native-USB ESP32-S3 profiles listed below. One physical USB
-connection can enumerate separate Companion and logging serial ports, so
-plaintext logs cannot corrupt binary frames. In WebConfig, use the
+for compatibility. Full Companion replaces separate USB, BLE, ordinary WiFi,
+and USB-only packet-logging release artifacts whenever the exact board supports
+the combined profile. Dual-CDC builds separate framed traffic and logs;
+single-TTY builds make those modes mutually exclusive. In WebConfig, use the
 <strong>FEM RX boost</strong> switch. From the text terminal (USB, or TCP 5002 on ESP32), use:</p>
 <pre><code class="language-text">get radio.rxgain
 set radio.rxgain off
@@ -1644,7 +1674,11 @@ 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.</p>
+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
@@ -1755,11 +1789,19 @@ is active; do not enter the start token again after it appears.</p>
 <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. ESP32 builds also provide local
-WiFi credential, status, WebConfig, CLI-tab, and power-save controls. Logging
-artifacts additionally provide <code>get/set usb.logging</code>; turning it off
-suppresses live USB diagnostics without disabling Companion frames or terminal
-replies. Dual-CDC Full Companion saves this setting and applies it only to its
-dedicated logging port. It starts off on a fresh installation.</p>
+WiFi credential, status, WebConfig, CLI-tab, 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>
+<h3 id="single-usb-serial-port">Single USB serial port</h3>
+<p>On an ESP32 Full Companion without dual CDC, interface <code>00</code> has two exclusive
+modes. It starts as framed Binary Companion. 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>. Turning it off sends the command reply and then returns
+that TTY to Binary Companion automatically, including on USB-UART bridges that
+cannot detect a cable disconnect. A saved logging-on preference boots directly
+into this input-capable logging terminal. BLE and Wi-Fi Companion remain
+available while USB is logging.</p>
 <h3 id="dual-usb-serial-ports">Dual USB serial ports</h3>
 <p>Current nRF52 Full Companion and qualified native-USB ESP32-S3 Full Companion
 firmware can expose two CDC ACM serial interfaces on one physical USB cable:</p>
@@ -1789,14 +1831,13 @@ 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. Qualified S3 boards
 temporarily expose the ESP32-S3 ROM USB-JTAG serial port during a wired flash.</p>
-<p>Qualified ESP32-S3 targets are Heltec V4, T-Beam 1W, Station G2/G3, XIAO S3
+<p>Dual-CDC ESP32-S3 targets are Heltec V4, T-Beam 1W, Station G2/G3, XIAO S3
 WIO, Heltec Tracker V2, Meshnology W12, and Nibble Screen/Zero Connect. The
 base Heltec V4 profile has completed live two-interface, ROM-flashing, and
-logging-off one-interface validation. RAK3112 and Heltec RC32 retain separate
-transport and logging images pending hardware validation. Boards whose
-connector terminates at an external USB-UART bridge also keep their
-transport-specific images: firmware cannot add a second USB interface to that
-bridge chip.</p>
+logging-off one-interface validation. Full recipes with only one usable TTY
+still replace separate transport images; they use the exclusive terminal/log
+mode above because firmware cannot add a second interface to a USB-UART bridge
+or a single-port USB peripheral.</p>
 <p>Every ESP32-S3 Full Companion image uses DIO flash mode, including the RAK3112
 and RC32 profiles that do not expose dual CDC. The S3 ROM supports DIO while
 loading the software bootloader, and some flash configurations fail before the

faq/index.html

@@ -1373,7 +1373,7 @@
   <a href="#67-q-my-rakt1000-exiao_nrf52-device-seems-to-be-corrupted-how-do-i-wipe-it-clean-to-start-fresh" class="md-nav__link">
     <span class="md-ellipsis">
       
-        6.7. Q: My RAK/T1000-E/xiao_nRF52 device seems to be corrupted, how do I wipe it clean to start fresh?
+        6.7. Q: My RAK/T1000-E/xiao_nRF52/... device seems to be corrupted, how do I wipe it clean to start fresh?
       
     </span>
   </a>
@@ -3039,7 +3039,7 @@
   <a href="#67-q-my-rakt1000-exiao_nrf52-device-seems-to-be-corrupted-how-do-i-wipe-it-clean-to-start-fresh" class="md-nav__link">
     <span class="md-ellipsis">
       
-        6.7. Q: My RAK/T1000-E/xiao_nRF52 device seems to be corrupted, how do I wipe it clean to start fresh?
+        6.7. Q: My RAK/T1000-E/xiao_nRF52/... device seems to be corrupted, how do I wipe it clean to start fresh?
       
     </span>
   </a>
@@ -3874,34 +3874,33 @@ 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>
 <h3 id="66-q-my-heltec-v3-keeps-disconnecting-from-my-smartphone-it-cant-hold-a-solid-bluetooth-connection">6.6. Q: My Heltec V3 keeps disconnecting from my smartphone. It can't hold a solid Bluetooth connection.</h3>
 <p><strong>A:</strong> 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>
-<h3 id="67-q-my-rakt1000-exiao_nrf52-device-seems-to-be-corrupted-how-do-i-wipe-it-clean-to-start-fresh">6.7. Q: My RAK/T1000-E/xiao_nRF52 device seems to be corrupted, how do I wipe it clean to start fresh?</h3>
-<p><strong>A:</strong></p>
-<ol>
-<li>Connect USB-C cable to your device, per your device's instruction, get it to flash mode:<ul>
-<li>For RAK, click the reset button <strong>TWICE</strong></li>
-<li>For T1000-e, quickly disconnect and reconnect the magnetic side of the cable from the device <strong>TWICE</strong></li>
-<li>For Heltec T114, click the reset button <strong>TWICE</strong> (the bottom button)</li>
-<li>For Xiao nRF52, click the reset button once. If that doesn't work, quickly double-click the reset button twice. If that doesn't work, disconnect the board from your PC and reconnect again (<a href="https://wiki.seeedstudio.com/XIAO_BLE/#access-the-swd-pins-for-debugging-and-reflashing-bootloader">seeed studio wiki</a>)</li>
-</ul>
-</li>
-<li>A new folder will appear on your computer's desktop</li>
-<li>Download the <code>flash_erase*.uf2</code> file for your device on <a href="https://flasher.meshcore.io">https://flasher.meshcore.io</a><ul>
-<li>RAK WisBlock and Heltec T114: <code>Flash_erase-nRF32_softdevice_v6.uf2</code></li>
-<li>Seeed Studio Xiao nRF52 WIO: <code>Flash_erase-nRF52_softdevice_v7.uf2</code></li>
-</ul>
-</li>
-<li>drag and drop the uf2 file for your device to the root of the new folder</li>
-<li>Wait for the copy to complete. You might get an error dialog, you can ignore it</li>
-<li>Go to <a href="https://flasher.meshcore.io">https://flasher.meshcore.io</a>, click <code>Console</code> and select the serial port for your connected device</li>
-<li>In the console, press enter. Your flash should now be erased</li>
-<li>You may now flash the latest MeshCore firmware onto your device</li>
-</ol>
+<h3 id="67-q-my-rakt1000-exiao_nrf52-device-seems-to-be-corrupted-how-do-i-wipe-it-clean-to-start-fresh">6.7. Q: My RAK/T1000-E/xiao_nRF52/... device seems to be corrupted, how do I wipe it clean to start fresh?</h3>
+<p><strong>A: If you're able to connect to the device from your MeshCore app</strong>
+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><strong>B: You're not able to connect to the App</strong>
+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>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 <a href="https://flasher.meshcore.io">https://flasher.meshcore.io</a></p>
 <h3 id="68-q-webflasher-fails-on-linux-with-failed-to-open">6.8. Q: WebFlasher fails on Linux with failed to open</h3>
 <p><strong>A:</strong> 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 the browser user on it:</p>
-<p><code># setfacl -m u:YOUR_USER_HERE:rw /dev/ttyUSB0</code></p>
+<p>Allow user access on your USB port:</p>
+<p><code>sudo setfacl -m u:$USER:rw /dev/ttyUSB0</code></p>
 <hr />
 <h2 id="7-other-questions">7. Other Questions:</h2>
 <h3 id="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">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?</h3>

firmware_picker/index.html

@@ -1552,21 +1552,24 @@ 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>Current dual-CDC Full Companion profiles also use one binary for normal
-attached Companion use and USB packet logging. This includes nRF52 and
-qualified native-USB ESP32-S3 Full images. Fresh installs default to logging off and expose only
-interface <code>00</code> for Binary Companion, terminal, and mOTA source traffic. Enabling
-logging and rebooting adds interface <code>02</code> for plaintext logs. The picker
-therefore omits older separate USB, BLE, ordinary WiFi, and USB-logging
-Companion choices when the matching Full artifact exists. Use
-<code>set usb.logging on reboot</code> or <code>set usb.logging off reboot</code> to persist the
-choice and apply the corresponding USB interface count.</p>
-<p>Qualified ESP32-S3 hardware currently includes Heltec V4, T-Beam 1W, Station
-G2/G3, XIAO S3 WIO, Heltec Tracker V2, Meshnology W12, and Nibble Screen/Zero
-Connect layouts. The base Heltec V4 profile has completed live two-interface,
-ROM-flashing, and logging-off one-interface validation. RAK3112 and Heltec RC32
-retain separate transport and logging images pending hardware validation, as do
-Heltec V3/WSL3, ThinkNode M2/M5/M7/M9, classic ESP32, and ESP32-C3 targets.</p>
+<p>Full Companion profiles use one binary for USB, BLE, ordinary Wi-Fi on ESP32,
+source-only LoRa OTA, and optional USB packet logging. The picker therefore
+omits separate attached-transport and USB-logging choices whenever the exact
+Full recipe exists. Fresh installs default to logging off.</p>
+<p>Dual-CDC nRF52 and qualified native-USB ESP32-S3 builds keep Binary Companion
+on interface <code>00</code>; <code>set usb.logging on reboot</code> adds plaintext interface <code>02</code>.
+Single-TTY ESP32 builds instead use <code>set usb.logging on</code> to switch that TTY to
+an input-capable plaintext logging terminal. <code>set usb.logging off</code> stops the
+logs and returns the TTY to Binary Companion after its reply. BLE and Wi-Fi
+remain usable while the USB TTY is logging.</p>
+<p>The dual-CDC ESP32-S3 subset includes Heltec V4, T-Beam 1W, Station G2/G3,
+XIAO S3 WIO, Heltec Tracker V2, Meshnology W12, and Nibble Screen/Zero Connect
+layouts. Existing single-TTY Full recipes include RAK3112, Heltec RC32,
+Heltec V3/WSL3, ThinkNode M2/M5/M7/M9, Heltec V2, LilyGo T-LoRa V2.1.1.6,
+and XIAO C3. Additional qualified single-TTY ESP32 profiles include M5Stack
+Unit C6L, Heltec Wireless Tracker/Paper/E213/CT62, LilyGo T3S3
+SX1262/SX1276, T-Deck, TETH Elite, classic T-Beam SX1262/SX1276, T-Beam S3
+Supreme, Ebyte EoRa-S3, Meshadventurer SX1262/SX1268, and XIAO S3.</p>
 <h2 id="installation-methods">Installation methods</h2>
 <table>
 <thead>

ota_protocol/index.html

@@ -2093,13 +2093,12 @@ EndF trailer (fixed 56 bytes):
 </ul>
 <p>The "reconstructed image" referenced by the manifest is the full <code>BODY || EndF</code> (what gets flashed).</p>
 <h3 id="esp32-application-slot-profiles">ESP32 application-slot profiles</h3>
-<p>ESP32 companion firmware is exempt from the portable-slot limit. USB and WiFi companion artifacts retain
-LoRa OTA and carry <code>-ota-</code> in their filenames so they can seed a host folder over serial or TCP; they keep
-their target partition table rather than using the FULL profile. A small set of high-capacity, non-PSRAM classic ESP32
-companions cannot combine their configured contact, group-channel, and offline-queue capacities with LoRa
-OTA in internal DRAM. Their normal artifacts remain unchanged, and option 3 emits a
-<code>-full-logging-ota-</code> fallback with 100 contacts, 8 group channels, a 16-frame offline queue, and a saved
-USB-logging on/off gate. MQTT
+<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

terminal_chat_cli/index.html

@@ -1357,11 +1357,12 @@ GPS idle behavior; it does not change LoRa RXPS or WiFi modem sleep.</p>
 <pre><code>get usb.logging
 set usb.logging {on|off} [reboot]
 </code></pre>
-<p>Shows or changes live USB debug and packet output in a Companion logging
-artifact. The setting is persistent. Dual-CDC Full Companion defaults off;
-changing its USB interface count requires a reboot, and the optional exact
-<code>reboot</code> argument performs that reboot after sending the reply. Companion
-protocol frames and terminal replies remain enabled on interface <code>00</code>.</p>
+<p>Shows or changes persistent live USB debug and packet output in a Companion
+logging artifact or Full Companion. Full starts off on a fresh install.
+Dual-CDC Full changes its interface count after a reboot and keeps Companion on
+interface <code>00</code>. Single-TTY Full needs no reboot: logging uses the active text
+terminal, which continues accepting <code>set usb.logging off</code> and automatically
+restores Binary Companion after that reply.</p>
 <pre><code>get radio.rxps
 get radio.rxps.config
 set radio.rxps {off|on|level 1-10 [preamble 16|32]|rx_us sleep_us}