deploy: ad34fd3a0d

faq/index.html

@@ -4720,6 +4720,14 @@ path. Both supplies are disabled before the selected one is enabled. Temporary
 radio settings preserve the saved TX power and safely clamp only the active
 band; returning to the saved settings restores its applicable power. A
 permanent frequency change clamps the saved TX power to the new band's limit.</p>
+<p>The W12 RF-switch update from <a href="https://github.com/meshcore-dev/MeshCore/pull/3579">upstream #3579</a>
+keeps the sub-GHz amplifier biased in standby. Before changing FEM supplies,
+firmware lowers its control pins; high-band standby and shutdown keep the
+unpowered sub-GHz amplifier's controls low. The existing LF/HF rail isolation
+is retained. The <a href="https://github.com/meshcore-dev/MeshCore/pull/3512">LR2021 receive fix in #3512</a>
+is covered by checked FIFO reads, interrupt acknowledgement and automatic RX
+rearming. Physical W12 packet-start power and current measurements are still
+required to qualify the RF result.</p>
 <p>The external SX1262, SX1268, LLCC68, LR1110, and LR2021 drivers also bound the
 post-SetTx BUSY wait. A failed PA ramp therefore returns an error and can enter
 the physical-reset recovery path instead of hanging the node indefinitely.</p>

power_saving_diagnostics/index.html

@@ -2892,20 +2892,34 @@ initializers for the same reason. The MeshTracker X1's LR2021 regulator likewise
 remains unchanged. Do not turn on a switching regulator without its required
 inductor/capacitor network. The MCU and LoRa regulator choices are independent.</p>
 <h2 id="meshnology-w12-transmit-preparation">Meshnology W12 transmit preparation</h2>
-<p>The W12 adopts the GC1109 TX preparation from
-<a href="https://github.com/meshcore-dev/MeshCore/pull/3579">upstream PR #3579</a>, but keeps
-the PA shut down in ordinary standby rather than permanently selecting TX mode.
-Before sub-GHz packet or Morse CW transmission, it temporarily enables the LF
-PA in standby, waits 1 ms, starts TX, then restores the normal standby mask.
-The TX mask stays unchanged during that restoration. Failure paths restore all
-affected DIOs and request radio recovery if the PA state cannot be confirmed.
-The 2.4 GHz path and other LR2021 boards do not use this LF prearm policy.</p>
-<p>LF/HF FEM rail changes now settle for 1 ms instead of 100 ms. Packet-wake deep
-sleep retains only the selected FEM rail; terminal shutdown retains both rails
-off. This is separate from the W12's existing circuit-verified DC/DC setting.</p>
-<p>Native fault-injection tests cover the mask transitions and power retention;
-RF envelope and battery-current measurements on a physical W12 are still needed
-to validate the TX improvement and quantify power use.</p>
+<p>The W12 uses the RF-switch table from
+<a href="https://github.com/meshcore-dev/MeshCore/pull/3579">upstream PR #3579</a>, head
+<code>7457cff43c22697119e06ad7d192a37de0990403</code>. Low-band standby keeps GC1109 CTX,
+CPS and CSD high; LF receive keeps CTX low and CPS/CSD high. This replaces the earlier
+1 ms temporary prearm as the fix for the weak opening of a transmitted packet.
+The PR author reported a roughly 36 ms power step before the table change and
+no idle-current increase in their power-saving setup. Those measurements are
+upstream evidence, not measurements of this fork.</p>
+<p>The 1 ms pre-TX settle guard and TX failure recovery remain. With the warm
+W12 table they do not rewrite the standby masks or remove its retained bias.
+Other LR2021 tables can still opt into temporary prearming with full cleanup.
+The upstream table needs one adaptation for this fork's exclusive FEM rails.
+The <a href="https://www.geochipinc.com/uploads/23940615_1756826539.pdf">GC1109 datasheet</a>
+requires controls not to exceed VBAT. Before changing supplies, firmware
+checks a cold standby with all control outputs low; after the selected supply
+settles for 1 ms it restores warm standby only for LF. High-band standby and
+2.4 GHz RX/TX keep the GC1109 controls low. A failed routing change is retried
+on the next request, including one for the same band.</p>
+<p>Packet-wake deep sleep retains only the selected FEM rail. Terminal shutdown
+checks cold controls after stopping the radio, then retains both rails off.
+If that final SPI check fails, the transceiver is held in reset before its FEM
+supplies are removed. Boot asserts reset before dropping retained FEM rails,
+including after an MCU-only reset, and releases it after selecting the initial
+supply. Hard recovery pulses reset before checked routing so a prior SPI fault
+cannot prevent recovery. The W12's existing circuit-verified DC/DC setting is independent of this routing.</p>
+<p>Native fault-injection tests cover the actual W12 table, temporary-mask
+cleanup on a cold-standby table, and power retention. RF envelope and battery
+current measurements on this fork's physical W12 remain hardware checks.</p>
 
 
 

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":""},{"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