This commit is contained in:
mikecarper committed 2026-10-06 07:06:59 +00:00
1 parent c8cc4f75ef
commit d11b6ab702
5 files changed
+252 -12

No files matched your search

+6 -2
View File
@@ -2366,8 +2366,12 @@ off, and 600 seconds open with USB logging. See the <a href="../../test-results/
qualification</a>
for deadlines, host preparation and retained failed attempts. USB remained
attached, so these checks do not measure CPU sleep or button wake. The subsequent
V4 button-wake correction and its software validation are separate; physical
button wake was not tested here.</p>
<code>ebf2f082</code> V4 button-wake profile correction passed host tests and linked-image
checks, followed by another unchanged native GUI fresh-flash connection and
180-second open/closed console checks with power saving on and USB logging.
Original settings, identity and ACL response were restored. Physical button
wake, CPU sleep and current draw were not tested here; the new source's GitHub
unit workflow remains in progress.</p>
<p>Build qualification does not establish physical compatibility on every board.
Hardware CDC has finite buffers, and closing a Linux TTY does not necessarily
produce a hardware session reset. Saturated diagnostic output is not lossless.
+1 -1
View File
@@ -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":"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>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 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 Lean LoRa-OTA repeater image; ESP32 builds retain the compact <code>start ota</code> browser uploader <p>Direct on-device WiFi and MQTT are currently ESP32 features. nRF52, STM32, and the currently enabled RP2040 targets do not run this MQTT bridge. An nRF52 connected to a Raspberry Pi can still be logged or uplinked by software on the Pi, but that is a separate host-side bridge rather than MQTT running in the radio firmware.</p>"},{"Line truncated
{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"],"fields":{"title":{"boost":1000.0},"text":{"boost":1.0},"tags":{"boost":1000000.0}}},"docs":[{"location":"","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>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 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 Lean LoRa-OTA repeater image; ESP32 builds retain the compact <code>start ota</code> browser uploader <p>Direct on-device WiFi and MQTT are currently ESP32 features. nRF52, STM32, and the currently enabled RP2040 targets do not run this MQTT bridge. An nRF52 connected to a Raspberry Pi can still be logged or uplinked by software on the Pi, but that is a separate host-side bridge rather than MQTT running in the radio firmware.</p>"},{"Line truncated
@@ -2269,8 +2269,10 @@ deadline, and measured fresh-flash and power-saving console idle results. The
older source and boundaries above remain historical evidence. Neither report
qualifies every host OS, physical USB adapter, cold power cycle, ESP32 board,
firmware profile, or radio traffic load. USB-attached console checks do not
establish CPU sleep, measured current or button wake; the subsequent V4
button-wake correction needs separate qualification.</p>
establish CPU sleep, measured current or button wake. The subsequent V4
button-wake profile correction passed host/build validation and another native
GUI fresh-flash plus 180-second open/closed console check, as recorded in that
linked report; physical button wake remains untested.</p>
@@ -90,7 +90,7 @@
"Failed flasher preparations remain failed and did not exercise the GUI five-second command timer.",
"Merged artifact is audited; actual browser tests flashed only the protected active application slot.",
"No measured sleep current, factory erase/cold-cycle, heavy logging or RF traffic-soak claim.",
"USB-attached CPU sleep guard means no physical light-sleep/button-wake or current-draw qualification; V4 momentary-button wake profile correction needs new-source qualification.",
"USB-attached CPU sleep guard means no physical light-sleep/button-wake or current-draw qualification; Updated profile host/build and native USB console checks are recorded separately; physical button wake remains untested.",
"Original host service states restored; MQTT packet delivery was not measured."
],
"qualified_trials": [
@@ -235,6 +235,141 @@
"current_draw_measured": false,
"physical_button_wake_tested": false,
"c888_V4_momentary_button_wake_profile_flag_present": false,
"new_button_fix_qualification": "pending"
"new_button_fix_qualification": "Host/build and updated-source native USB console180s qualified; physical button/CPU sleep/current untested."
},
"updated_source_checkpoint": {
"source_commit": "ebf2f0823ef8413987d31ccb2d044a2090e88469",
"firmware_version": "v1.17.1.9-halo-keymind-cascade-dev-ebf2f082 (Build: 06-Oct-2026)",
"status": "host_build_and_native_console_180s_passed_operator_restored",
"build": {
"target": "heltec_v4_repeater",
"profile": "full",
"platformio_feature_base": "heltec_v4_repeater_observer_mqtt",
"app_sha256": "aebfd06f5e35ad636f52f329bd051deb9dfeb633361dc77396c0ee9d4456e7c1",
"app_bytes": 2097560,
"merged_sha256": "08750bd38f9f71ea37b8739a8b3c26befa91829df6d5754ad9cffbf61a796a90",
"merged_bytes": 2163096,
"elf_sha256": "c2ec6d54c32c4b3cb331f9216607480e851933cf4865cc399be9409fdf587467",
"partition_table_4096_sha256": "9af3af2b74e944337ba85f2b0027ee80df160579a1ab746ba0f95853f618cd60",
"slot_bytes": 6553600,
"RAM_capability_and_file_hash_gates_passed": true,
"heap_margin_bytes": 20880,
"linked_HWCDC_PHY_handoff_and_startup_hook": true,
"linked_GPIO0_active_low_button_wake_and_pending_press_cleanup": true,
"linked_radio_IRQ14_wake_retained": true,
"linked_role_gesture_polling_guard": true,
"independent_build_audit_sha256": "826089a49402a4cc23f648f4d642c7547f33f05520333877373a2a134af0c2d4"
},
"host_validation": {
"ESP32_USB_sleep_tests_passed": 7,
"display_power_tests_passed": 2,
"profile_flag_assertions": 71,
"standalone_migrator_exclusions": 4,
"actual_family_role_CXX_cases": 6,
"required_failure_controls": 3,
"scope": "Real Board.sleep/USB methods, MomentaryButton, role polling and UITask button fragments with DisplayPowerPolicy; simulated GPIO/sleep."
},
"native_browser": {
"version": "154.0.8037.92",
"same_pinned_stock_GUI_and_flasher": true,
"native_command_deadline_ms": 5000,
"extra_post_flash_reset_replug_settle_retry": false,
"report_sha256": "ba7d9f415a1cd27fd5fe4070d47306f2cd67e4ce08baee684f07c83eb364cef3",
"independent_report_review_sha256": "be8eed53f8ec012f4c217c52e55fbdab3b29aad972fda933c4fb18fbe75c5f43",
"first_plain_time_ms": 2036.3999999985099,
"first_plain_time_clock_set_acknowledged": true,
"power_saving": "on",
"logging_output": "usb",
"quiet_intervals": [
{
"kind": "open",
"requested_seconds": 180,
"actual_seconds": 180.0605071799946,
"native_writes_during_idle": 0,
"uptime_before": 17,
"serial_open": true,
"uptime_after": 198,
"uptime_delta": 181,
"uptime_continuity_verified": true,
"ok": true
},
{
"kind": "closed",
"requested_seconds": 180,
"actual_seconds": 180.10022866498912,
"native_writes_during_idle": 0,
"uptime_before": 205,
"serial_open": false,
"uptime_after": 391,
"uptime_delta": 186,
"uptime_continuity_verified": true,
"ok": true
}
],
"first_post_open_idle_core_ms": 39.70000000111759,
"post_open_idle_DOM_clock_reply_ms": 45,
"post_open_idle_DOM_clock_set_acknowledged": true,
"post_closed_idle_DOM_clock_reply_ms": 26.700000001117587,
"post_closed_idle_DOM_clock_set_acknowledged": false,
"post_closed_idle_response": "recognized framed clock-cannot-go-backwards rejection",
"full_GUI_rereads_passed": true,
"native_command_errors": 0,
"GUI_modem_signal_calls": 0,
"original_reference_and_final_restoration_verified": true,
"checked_preferences_count": 15,
"original_power_saving": "off",
"original_logging_output": "usb",
"streams_closed": true
},
"host_preparation": {
"tty_before": {
"VMIN": 0,
"VTIME": 0
},
"tty_after": {
"VMIN": 1,
"VTIME": 0
},
"explicit_modem_signal_calls": 0,
"safe_start_report_sha256": "7129af121900b598d02ec3e33702bb87dec988ae3a8d3f2eaf9550cb73ddd3d3"
},
"radio": {
"initial_core_error_flags": 0,
"final_core_error_flags": 8,
"all_observations_active_RX": true,
"physical_rx_errors_max": 0,
"final_recv": 0,
"final_sent": 1,
"scope": "Known CAD/receive-silence flags are warnings; no zero-error RF or traffic-soak claim."
},
"operator_cleanup": {
"ok": true,
"exact_runtime_version_and_reference_digests_verified": true,
"uptime_seconds": 448,
"core_error_flags": 8,
"serial_closed_and_no_owner": true,
"owned_browser_profile_closed": true,
"owned_tunnel_closed": "parent independently verified",
"original_services_restored": {
"ModemManager": "active",
"mctomqtt": "active",
"mesh-logger": "inactive"
},
"network_configuration_changed": false,
"operator_report_sha256": "c79f570fa7d5b4599d4538527aa9edefeb8d5173a47dc5689c44cfdb632d33fd",
"services_report_sha256": "bc98de9e3753d736de35a45d4cfda1c7380a7c2eff66891c3a3f4444e1d74425",
"browser_cleanup_report_sha256": "c848c50e4ae1ab73fee92f5381dc60e0b9cd23b04a672ad9a5df60dd0fb3b3dc",
"independent_cleanup_audit_sha256": "f96f14695beafba898cb2361b41540614026bda3316764a0421a93158de3ce38"
},
"CI": {
"run_id": 37426156162,
"status": "in_progress_at_checkpoint"
},
"limitations": [
"Updated-source180s intervals are separate from historical c888600s trials.",
"USB cable remained attached; no physical button wake, measured CPU sleep or current draw.",
"Host services restored; no MQTT delivery or loaded-RF qualification.",
"Release held and unpublished."
]
}
}
@@ -2145,6 +2145,17 @@
</span>
</a>
</li>
<li class="md-nav__item">
<a href="#updated-button-profile-checkpoint-ebf2f082" class="md-nav__link">
<span class="md-ellipsis">
Updated button-profile checkpoint: ebf2f082
</span>
</a>
</li>
</ul>
@@ -2182,6 +2193,10 @@ open-console trial also passed with USB logging on. Both trials restored the
original settings and closed their streams. Final operator readback and owned
browser/host-service cleanup also passed. Release 1.17.1.9 remains held and
unpublished.</p>
<p>The subsequent button-profile correction at <code>ebf2f082</code> passed host/build checks
and another native fresh-flash GUI connection with 180-second open/closed
console intervals. That updated-source checkpoint is recorded separately below;
it does not extend the older source's 600-second measurements to the new image.</p>
<p>These results extend the <a href="../hardware_validation_esp32_web_console_startup_2026-10-05/">earlier startup investigation</a>
to the current normal Full image and native hardware CDC. They are physical
console stability checks, not a measurement of sleep current, radio traffic
@@ -2192,7 +2207,7 @@ capacity, or every ESP32/host combination.</p>
update identity. Runtime readback had to match the complete version
<code>v1.17.1.9-halo-keymind-cascade-dev-c88885a3 (Build: 06-Oct-2026)</code>.
The source includes the OTA upload correction in <code>d2983762</code> and WiFi ownership
correction in <code>95913c53</code>. The GitHub unit workflow for the current source passed;
correction in <code>95913c53</code>. The GitHub unit workflow for <code>c88885a3</code> passed;
this does not replace the physical checks below or the final release matrix.</p>
<table>
<thead>
@@ -2356,10 +2371,9 @@ qualified results.</p>
guard keeps CPU command service available while the USB host is connected,
including when its serial port is closed. Power saving on is therefore not
proof of CPU light-sleep entry, measured current, or physical button wake.
At this source, V4 lacks the momentary-button wake profile flag. The later
profile correction is outside this image and needs separate software/build
and console validation. No physical button access is available in this setup,
so physical button wake remains unqualified.</p>
At this source, V4 lacks the momentary-button wake profile flag. Its subsequent
software/build and console validation is recorded below. No physical button
access is available in this setup, so physical button wake remains unqualified.</p>
<p>These checks qualify this historical <code>c88885a3</code> Full application, native Pi Chromium setup,
protected active-slot application flash, and measured intervals. They do not
qualify every host OS, board/role, adapter, cold power cycle, factory erase,
@@ -2367,6 +2381,91 @@ heavy logging volume, measured power consumption, or RF traffic load. GPIO/reset
behavior outside the unchanged stock flasher's reset sequence was not separately
qualified. The release remains unpublished; the final same-source all-board
build and release packaging are separate gates.</p>
<h2 id="updated-button-profile-checkpoint-ebf2f082">Updated button-profile checkpoint: <code>ebf2f082</code></h2>
<p>Source <code>ebf2f0823ef8413987d31ccb2d044a2090e88469</code> enables the existing
momentary-button wake flag in the shared V4 and V4-R8 profiles. Seven ESP32
USB/sleep tests and two display-power tests passed. Configuration assertions
cover 71 firmware profiles, excluding four deliberately standalone partition
migrators. Six host cases execute actual board sleep/USB methods, real family
button constructors and implementation, role polling guards, UITask button
fragments and DisplayPowerPolicy. Three controls must fail if the profile flag,
gesture polling guard or display wake is removed. These are synthetic GPIO/sleep
results, not a physical button press.</p>
<table>
<thead>
<tr>
<th>Updated artifact</th>
<th style="text-align: right;">Bytes</th>
<th>SHA-256</th>
</tr>
</thead>
<tbody>
<tr>
<td>Full application</td>
<td style="text-align: right;">2,097,560</td>
<td><code>aebfd06f5e35ad636f52f329bd051deb9dfeb633361dc77396c0ee9d4456e7c1</code></td>
</tr>
<tr>
<td>Merged image</td>
<td style="text-align: right;">2,163,096</td>
<td><code>08750bd38f9f71ea37b8739a8b3c26befa91829df6d5754ad9cffbf61a796a90</code></td>
</tr>
<tr>
<td>Matching ELF</td>
<td style="text-align: right;">-</td>
<td><code>c2ec6d54c32c4b3cb331f9216607480e851933cf4865cc399be9409fdf587467</code></td>
</tr>
</tbody>
</table>
<p>The normal Full target, table, two slots, capabilities and RAM gates passed,
with the same 20,880-byte required-heap margin. Linked instructions now contain
the GPIO0 pending-press check, active-low wake and button cleanup, plus the
gesture polling guard, while retaining radio IRQ14 wake. The HWCDC PHY handoff
and startup hook remain linked; no TinyUSB USBCDC class is linked. This confirms
the profile flag reached the application rather than only its source recipe.</p>
<p>The same pinned stock native GUI/flasher and unchanged 5,000 ms deadline were
used. Before this flash, host-only TTY preparation again changed VMIN/VTIME from
0/0 to 1/0 with zero explicit modem-signal calls. The app-only ROM preflight
again selected the protected active slot. Exact runtime readback was
<code>v1.17.1.9-halo-keymind-cascade-dev-ebf2f082 (Build: 06-Oct-2026)</code>.</p>
<table>
<thead>
<tr>
<th>Updated-source check</th>
<th>Result</th>
</tr>
</thead>
<tbody>
<tr>
<td>First stock DOM GUI Connect after fresh flash</td>
<td>PASS. Plain time clock-set acknowledgement in 2,036.4 ms; full GUI bootstrap, exact version and original reference checks passed. No extra reset, replug, settle or retry.</td>
</tr>
<tr>
<td>Power saving on, USB logging, console open</td>
<td>PASS. 180.061 seconds with zero native writes or keepalives; uptime 17 -&gt; 198 seconds. First post-idle core reply took 39.7 ms; full DOM reconnect time acknowledgement took 45.0 ms.</td>
</tr>
<tr>
<td>Power saving on, USB logging, console closed</td>
<td>PASS. 180.100 seconds with streams closed and zero writes; uptime 205 -&gt; 391 seconds. First DOM reconnect time response took 26.7 ms and was the recognized clock-cannot-go-backwards rejection, not an acknowledgement. Full GUI bootstrap passed.</td>
</tr>
<tr>
<td>Cleanup and operator readback</td>
<td>PASS. Original power saving off, USB logging, all 15 checked preferences, public identity and ACL response were restored. Streams closed; independent operator readback again matched the exact updated version and original digests at uptime 448 seconds.</td>
</tr>
</tbody>
</table>
<p>There were no native command errors or GUI modem-signal calls. Radio remained
in active RX with zero physical RX errors; flags changed 0 -&gt; 8, received
packets stayed zero and one packet was sent. This remains a receive-silence
watchdog warning, not a CPU crash or loaded-radio qualification. The owned
browser and tunnel were closed, the serial port had no owner, original host
service states were restored, and no Pi network configuration changed.</p>
<p>The compact safe audit records this as <code>updated_source_checkpoint</code>, separate
from the older 600-second trials. The updated source qualifies these
180-second console intervals; physical button wake, CPU sleep and current draw
remain untested with USB attached. GitHub unit run <code>37426156162</code> for this new
source is still in progress at this checkpoint. Release 1.17.1.9 remains held
and unpublished.</p>