deploy: bd09019ada

power_saving_diagnostics/index.html

@@ -2280,6 +2280,17 @@
     </span>
   </a>
   
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#noise-floor-sampling-and-sleep" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        Noise-floor sampling and sleep
+      
+    </span>
+  </a>
+  
 </li>
       
     </ul>
@@ -2337,7 +2348,9 @@ after off starts a fresh window. Collection defaults off at every boot.</p>
 <li><code>bridge</code>, <code>bridge.cleanup</code>, <code>bridge.wake</code>: active UART/network bridge,
   shutdown work or an overdue standby wake. A suspended RS232 owner is not
   diagnosed as running just because its saved enabled flag is on.</li>
-<li><code>calibration</code>, <code>radio.watchdog</code>: radio observation/calibration work.</li>
+<li><code>calibration</code>: noise-floor work is due now. The CPU can idle between sample
+  deadlines even while the radio remains in continuous RX for calibration.</li>
+<li><code>radio.watchdog</code>: radio observation/recovery work.</li>
 <li><code>queue</code>, <code>retry</code>, <code>scheduled</code>, <code>mesh</code>, <code>ota</code>, <code>radio2</code>: pending role work.</li>
 <li><code>wireless</code>, <code>network</code>, <code>serial</code>, <code>button</code>, <code>tracker</code>, <code>morse</code>: a matching
   existing service guard is active.</li>
@@ -2363,6 +2376,23 @@ most 256 bytes of collector state. Each wait-call interval must be shorter
 than the 32-bit <code>micros()</code> wrap (about 71 minutes); the normal wait paths here
 are much shorter. Keep gaps between policy observations below the <code>millis()</code>
 wrap (about 49 days).</p>
+<h2 id="noise-floor-sampling-and-sleep">Noise-floor sampling and sleep</h2>
+<p>Startup still collects a complete baseline promptly: 64 accepted samples,
+at least 50 ms apart, after the radio frontend has settled. Collection keeps
+the radio in continuous RX when needed, but the CPU may sleep between reads.
+Pending packet interrupts retain their normal receive owner. Rejected readings
+retry at 50 ms intervals, and the existing 30-second collection timeout bounds
+an attempt on a busy channel.</p>
+<p>After a successful baseline, ordinary single-profile refresh waits five
+minutes. A rejected rise or failed attempt retains the last usable floor and
+retries after one minute. Gain, tuning and AGC changes still request immediate
+recalibration, so a configured short AGC interval can refresh more frequently.
+Dual-profile scanning keeps its existing timing and calibration policy.</p>
+<p>ESP32 timed sleep uses a millisecond timer capped at the next sample deadline.
+nRF52, RP2040 and STM32 retain their interrupt-idle wake paths. Other sleep
+guards, including USB/logging, packet queues and bridges, still apply.
+These changes have host scheduling tests and firmware build coverage; their
+power benefit requires a new matched hardware/current measurement.</p>
 <p>See the <a href="../cli_commands/#diagnose-what-prevents-power-saving">CLI reference</a>
 for all page names and commands.</p>
 <p>The <a href="../nrf52_sleep_event_validation/">nRF52 idle-sleep investigation</a> describes

research/companion_contact_cache/index.html

@@ -2374,8 +2374,10 @@ qualification; it is not a runtime feature switch.</p>
 48,964 bytes available against 59,968 required. Enabling the existing cache
 for high-contact nRF52 profiles recovered 30,200 bytes: the linked build has
 79,164 bytes available and a 19,196-byte margin against the unchanged budget.
-Its 350 contacts, 40 channels and configured 256-frame offline/held-DM pool
-are retained. This is a linked-capacity result, not a physical load/soak test.</p>
+It keeps 350 contacts, 40 channels and 256 normal offline frames. As on the
+cached RAK profiles, up to 15 held one-key DMs temporarily use queue slots;
+their storage is shared instead of reserving a second pool. This is a
+linked-capacity result, not a physical load/soak test.</p>
 <h2 id="paths-and-persistence">Paths and persistence</h2>
 <p>The 16 resident paths use least-recently-used replacement. Contact records
 keep small handles to their saved paths, including 1-, 2-, and 3-byte hop

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