Mercerwood Companion diagnosis follow-up, 2026-10-19

Overall status: FAIL, incomplete. Across the selected measured sources, 1/2 Companions PASS, 1 FAIL. RAK 4631 passed USB, BLE and two-way LoRa at f807. T1000-E passed normal Full USB and BLE on battery, wall power and suspended Pi USB, but active Pi USB reproduced its BLE failure. It remains FAIL pending resolution of that operating condition. XIAO nRF52 remains a carried-forward failure.

Both selected boards first returned to Full f80751354ffc530461e87109ced4f575d3950a52. T1000 subsequently received normal Full 42f7df082fc4c7362ecd5c18c8644ab25b51b9e9, version v1.18.0.1-halo-keymind-cascade-dev-42f7df08, after the corrected bootloader. Its ZIP SHA-256 is 7fac141e40183ada315f70b296583eaf854fd819c76fbd896a1f0f2e4a405e5b. Checks ran on October 20 UTC across October 19-20 local time. Normal Full 72a74c784c38af72518bec7517e691ce9abccaa3 is now restored, with unchanged identity, zero core errors and MCU auto/DCDC. Its restoration smoke passed three USB opens/closes and 19 responses with clean framing. This is not new BLE, RF or full feature qualification; the earlier Full 42 results retain their original source binding.

Companion	Source	USB	BLE	LoRa	Overall
RAK 4631	f8075135	PASS	PASS	PASS	PASS
Seeed T1000-E	42f7df08	PASS	battery/wall power/suspended USB PASS; active Pi USB FAIL	not requalified; f807 passed	FAIL
Seeed XIAO nRF52	prior failure retained	FAIL	not qualified	not qualified	FAIL retained

This is a selected-board follow-up, not a 13-radio fleet qualification. Repeaters were outside scope. Earlier mixed-source results remain in the previous follow-up.

Before the bootloader comparison, each f807 USB run passed 100 query cycles, 10 reopens, radio2 checks, owned-contact CRUD, persistence through warm reboot and contact cleanup. Each closed 18/18 ports with clean final core flags and zero stable binary prefix discards or invalid lengths. ASCII setup and intentional reboot recovery remain separate transition evidence.

RAK BLE passed three 30-second sessions with USB-bound identity, board, full version, NUS services and getters verified. Uptime advanced, flags stayed clean and each session disconnected. LoRa passed an exact zero-hop DEV datagram in each direction between RAK and T1000, with packet-counter checks, owned-channel cleanup and restored radio leases. These finite checks do not establish phone interoperability, range or text delivery.

T1000's original f807 BLE run failed current-advertisement identity binding with zero sessions. A later 90-second Pi follow-up also completed none despite Bluetooth enabled, stealth off and clean USB core flags. The unpaired BlueZ cache retained T1000-BLE-PROBE while USB verified normal f807 and its configured MeshCore name. Cached naming may affect filtering without a current scan response; it proves neither the BLE cause nor a duplicate address or working connection.

Minimal BLE-only, payload/timing, clock-request, transmit-power and LFRC images were diagnostic probes, not Full acceptance. The LFRC probe used an explicit RC configuration and valid vectors; this does not establish a defective crystal or justify changing production clocks. Advertising/HFXO readbacks do not measure RF accuracy or prove over-air packets.

The official upstream companion-v1.18.0 T1000 BLE reference had matching ZIP/UF2 application bytes, base 0x27000 and SoftDevice requirement 0x0123. Its bounded Pi scan did not find the required current advertisement. Phone visibility was insufficiently bound to name/time. This application-only experiment retained the same bootloader/SoftDevice and cannot isolate them. Normal Full was restored. Reference ZIP SHA-256: 79e53c2ce13521ccda5db3621a68f79728d2f241c3a8345e4107b7ae6b5a374d.

Installed S140 7.3.0 readback CRC 733639BD matched the package bytes, also identical to Seeed's recovery package SoftDevice. That checks the covered image, not RF operation. C2 installation preceded a historical secured diagnostic link that never completed full BLE qualification.

A separate DFU defect was corrected in bootloader c0c421184a3cf1ca66b40b055101f20b8c587e26: active-high P0.06 had been configured pull-up/active-low, with RESET/P0.18 treated as another button. The correction adds qualified three-second hold/USB-first recovery while retaining explicit-request latency and other boards' two-button behavior. Eleven actual-function host tests, 13 DFU-entry checks and T1000/T096/T114 cross-builds passed. See candidate PR #1 and button-polarity evidence.

The reviewed combined bootloader transfer returned 0, but its installer stopped when the MSC disk was unavailable. That failed workflow remains failed. Later exact-device public INFO verified model Seeed T1000-E for Meshtastic, Board-ID nRF52840-T1000-E-v1 and version TEST_0x02040C01. Package CRC 6BA4D206 was validated offline; installed CRC was not exposed. Combined ZIP SHA-256: 8db09e6b7f253b1e54aae754220f0d1053d369c07bff299a26b384233de6e234.

Separate f807 application programming and its adapter command both returned 0. An independent USB check passed 15 queries/two reopens, closed 5/5 ports and verified normal f807, the same public identity, clean framing and zero core errors. With the corrected bootloader and same f807, an explicit-address 90-second BLE attempt still failed advertisement binding with zero sessions. No BLE fix or bootloader cause is established.

Final normal Full 42f7df08 installation succeeded. Its fresh USB run passed 100 queries, 10 reopens, owned-contact CRUD/cleanup, warm reboot and radio2 checks, with 18/18 ports closed, zero stable framing rejects and clean core flags. Its normal 25-second BLE discovery still failed with zero sessions. LoRa was not requalified at 42f7df08; the earlier f807 RF pass remains source-bound.

Combined serial delivery avoided legacy UF2 scratch 0xE0000..0xEA000, which overlaps internal ExtraFS. Its staging and f807 restore remain below ExtraFS. No filesystem-preservation claim replaces runtime checks.

A subsequent 90-second scan by the independently verified Bluetooth address also failed to reach a connection on normal Full 42f7df08.

After the user reported a reset, USB was present at preflight. Fresh USB passed 15 queries/two reopens on the same normal Full image. A 90-second Pi scan completed zero BLE sessions and captured zero target advertisements among 643 advertising event blocks. A separate 30-second passive scan captured one target advertisement among 3,375 blocks; direct public-service discovery timed out. A temporary saved random address produced two primary advertisements but no usable connection. Factory-default addressing was restored and verified over USB; Bluetooth remained enabled with clean core flags. No host bonds were removed. These are post-reported-reset observations, not a verified cold or battery-only test.

Fresh normal RAK and T096 USB/BLE controls passed on the Pi. An independent RAK nRF52 central diagnostic, version v4.1, then passed a single public ATT/NUS metadata comparison against the USB-bound T096. It read the expected public GAP name, recorded no security activity, and disconnected cleanly. The unchanged T1000 Full image then supplied a current primary advertisement at -63 dBm, but its one attempted connection ended with 0x3E before any NUS metadata or public read succeeded. The observer's uptime and watchdog counters advanced, with no late connections or security events; scanning and connections stopped cleanly. A central connected event does not prove the peer received its connection request; Nordic describes this initial-exchange failure.

This comparison strengthens a T1000-specific link finding across two central implementations. It does not identify a faulty component or establish a bootloader cause. That comparison did not reach pairing or password exchange. The temporary central is not Companion qualification. Its initial v4 scan-unit error was corrected before either trial; live v4.1 status verified a 3,000-unit, 30-second scan configuration. The RAK was restored to the exact normal Full f807 ZIP and passed fresh 15-query/two-reopen USB and one 10-second BLE session with the same public identity. T1000 remains FAIL. Its pin assignments match Seeed's T1000-E hardware list; no further pin change is justified by this evidence.

A later controlled Bluetooth off/on test kept USB management open and had the Pi client scanning before enable. Unlike the earlier fixed-duration discovery, this client attempted pairing 49 ms after its first current target advertisement, which arrived 84.331 seconds after the on request. This time the trace proves bidirectional SMP and ATT exchanges and a passkey request. The supplied PIN matched the active USB-reported PIN and the user's expected PIN. The link then ended with HCI Connection Timeout 0x08; BlueZ reported Authentication Canceled. No completed bond or Companion session, explicit PIN rejection, or stable-link pass is established. The parent evidence exporter subsequently failed to parse a traceback as JSON; that workflow failure remains recorded, separate from the independently analyzed radio trace. A further exact-address ATT connection was requested while Bluetooth was off, with its kernel scan already pending before enable. It failed initial establishment with 0x3E and read no NUS service. Bluetooth was restored on, with the same factory-address policy, stealth off, monotonic uptime and clean core flags. Firmware and host bonds were unchanged. These tests refine the failure to an unstable link that can sometimes reach pairing; T1000 remains FAIL.

A subsequent application-only isolation test installed two small public-NUS echo diagnostics built against source context 56b4d72e6. They omit Companion, LoRa, GNSS-driver and sensor processing, retain the board/framework/SoftDevice/bootloader, and feed every active watchdog channel. Both builds passed memory/vector/package checks and exact-device serial DFU/runtime verification.

Diagnostic	Observation	Result
Minimal external LF crystal, 20 ppm	No target advertisement in 60 seconds; uptime advanced 62.215 seconds with watchdog feeds advancing	No connection or echo
Same minimal app, internal LF RC, 250 ppm	One target advertisement after 42.138 seconds at -60 dBm; connection attempt timed out; uptime advanced 59.209 seconds with watchdog feeds advancing	No connection or echo
Normal Full with four-second initial supervision timeout from RAK central v4.2	Current target advertisement at -62 dBm; initial connection establishment failed with `0x3E` before public GATT reads or security activity	FAIL
T096 control with the same central parameters	Public NUS service/characteristics and expected GAP name read successfully	Diagnostic control PASS

The controller reported the configured 48.75 ms interval, zero latency and four-second initial timeout for both central trials. A central connected callback does not prove T1000 receipt of its connection request; the failed initial exchange does not test pairing on an established four-second link. The Pi's earlier attempt to extend a live connection saw no target advertisement in 90 seconds, so no update was applied. A host-only HCI-filter padding error was corrected before that valid trial and remains recorded separately.

These results make it less likely that the Companion workload or the external low-frequency crystal alone explains the failure. They do not distinguish common framework/SoftDevice behavior, the high-frequency radio clock, power or RF hardware. Both minimal images were removed. Normal T1000 Full 42f7df08 was restored and passed 15 USB query cycles/two reopens with the same public identity. The test RAK returned to its exact normal Full f807 image and passed 15 USB query cycles/two reopens and one 10-second secure BLE Companion session with the same identity. The four-second comparison had T1000 USB present before and after; it was not a battery-only test.

Physical battery-only testing subsequently passed on the unchanged normal Full image. The user confirmed unplugging USB, and the Pi verified the exact T1000 USB identity remained absent throughout each run. The first run completed fresh PIN pairing, authenticated bonding, encryption and a 30-second Companion session. Three subsequent one-minute sessions passed normal discovery by name and saved-bond reconnects. All four verified the same USB-bound identity, complete firmware version and Companion getters, negotiated MTU 247, advanced uptime with zero core error flags, and disconnected cleanly. The optional four-second timeout helper aborted at its live-handle guard before sending any command; it did not cause this success. The first connection negotiated normally from 420 ms to two-second supervision, and the reconnects used two-second supervision.

The user then reconnected USB after being asked to keep the radio in place without resetting it. The exact runtime endpoint remained present throughout both comparison trials, which opened no USB serial port, changed no firmware/preferences and retained the same bond.

USB-connected comparison	Observation	Result
Normal name discovery, 25 seconds	Zero target advertisements among 202 advertising event blocks	Zero Companion sessions
Immediate connection by independently verified address	Ten target advertising event blocks, no target name scan response; one BlueZ Connect operation produced nine controller attempts, seven ending with `0x3E` and two with `0x08`; no successful encryption	Zero Companion sessions
Read-only USB check after BLE trials	Same normal Full version and public identity, uptime 2,903 seconds without a decrease from the battery test, Bluetooth on, stealth off and zero core error flags	Runtime check PASS

The USB comparison used the same normal two-second supervision parameters that worked on battery. After the user unplugged the hub end, with instructions to leave the magnetic end attached and the radio in place, three further 30-second sessions passed normal name discovery, encryption and Companion queries. Uptime advanced from the USB check, all sessions disconnected cleanly, and the Pi verified USB absence throughout. That makes seven successful battery sessions in total, with no firmware change, reset request or bond removal during this comparison.

The user then connected the same cable to wall power only. Three further 30-second sessions passed normal name discovery, saved-bond encryption, the same Companion identity/version/getters and clean disconnects. Pi USB remained absent throughout. Charging from that supply alone did not reproduce the failure. Supply voltage was not instrument-measured.

The battery/Pi USB/battery/wall-power sequence associates the failure with the Pi/hub connection; it does not identify cable/ground/RF effects, USB software activity or a particular faulty component. Position and cable attachment were requested but not independently measured. The MQTT gateway remained active before and after the comparison trials.

On the next Pi reconnection, a guarded Linux USB device authorization test deconfigured only the exact T1000, then restored its configuration. The physical cable remained connected as requested; no hub or port-power command was sent. Before and after deauthorization, 25-second scans captured no target advertisement. While deauthorized, the Pi captured three target advertising event blocks and briefly encrypted a link, but it ended with 0x08 before any Companion session completed. This did not restore stable BLE. Deconfiguration does not physically disconnect USB or establish that bus signalling and the peripheral USB block have stopped.

USB authorization returned to its original state. The first USB runtime read failed before opening a port because the recreated device node was not yet accessible to the normal user; this failed workflow is retained separately from the BLE results. After normal user access returned without a permission change, a separate readback passed on unchanged Full firmware with the same public identity, Bluetooth on, zero core errors and uptime 3,987 seconds. The gateway remained active.

The user moved the T1000 to another powered-hub port. The Pi verified the same USB serial identity at a different physical USB path, continuously present during both BLE trials. Normal 25-second discovery captured zero target advertisements among 358 advertising event blocks. A 90-second address-based scan captured zero among 580 and timed out before a connection attempt. Moving ports did not restore BLE. A read-only USB check between these trials passed seven queries with the same firmware/identity, Bluetooth enabled, zero core errors and uptime 4,635 seconds.

A guarded per-device USB runtime suspend comparison then changed only this T1000's idle policy. Linux reported the device suspended while its hub port remained active with port power-off prohibited. Authorization, configuration and device number stayed unchanged. No serial port was opened during either BLE phase, and no firmware, bond or reset change was requested.

USB runtime state	BLE observation	Result
Suspended, cable still connected as requested	Three normal-name, saved-bond sessions; same Full identity/version/getters, MTU 247, advancing uptime and clean core flags; three encrypted links and clean local disconnects	3/3 thirty-second Companion sessions PASS
Resumed to original active policy	Three target advertising event blocks; two controller attempts, one ending with `0x3E`, the other briefly encrypted before `0x08`	Zero completed Companion sessions

The original USB policy and idle delay were restored and verified, and the gateway remained active. This comparison makes active USB operation a stronger discriminator than charging alone or the individual hub socket. It does not distinguish USB software/peripheral behavior from electrical or RF effects of active signalling, and no waveform or supply-voltage measurement was made. Firmware remains unchanged.

Three subsequent handoff cycles temporarily allowed this device to autosuspend after two seconds idle. Each serial open woke USB and passed seven read-only queries. After serial close, Linux reported USB suspended, and a normal-name, saved-bond 30-second Companion session passed with the same identity/version, MTU 247 and clean core flags. All three cycles passed. Together with the direct suspend trial, six secure sessions passed with USB suspended.

The original active USB policy was restored again. A final seven-query USB readback passed, with uptime 5,259 seconds, Bluetooth on, unchanged identity/firmware and zero core errors. No persistent host configuration was installed. Automatic idle suspend is a tested candidate workaround for sequential USB/BLE use; it does not qualify simultaneous active-USB/BLE operation or establish a production firmware fix. A second computer with USB data active is the next comparison needed to separate the Pi/hub path from behavior common to the T1000's USB connection.

Further firmware isolation did not establish a reliable simultaneous active-USB/BLE fix. All native SDK runs below are public DIS/NUS nonce-echo diagnostics, not secure Companion qualification; they add zero qualified secure sessions. Results remain bound to their runtime builds and safe evidence digests.

Probe	Source or build	Completed observation	Assessment
MCU LDO, active USB	Normal Full 42f7df08	Zero of three BLE sessions; MCU auto/DCDC restored, same identity and clean core flags	FAIL
Minimal USB IRQ 2/6/2	T1000-USBIRQ-v1	Zero echoes in each corrected trial; IRQ count-rate upper bounds 0.866/0.744/0.728 Hz including probe traffic	No reliable fix; interrupt durations not validated
Explicit HFCLK claim	T1000-USBIRQ-v2	Ten echoes, then GATT protocol failure	FAIL
Modified Full clock prototype	Base 72a74c78	Zero of three Companion sessions; current-advertisement identity gate failed	FAIL; not retained as a production fix
Active USB / suspended USB / active USB	Native SDK v1	Zero echoes / three sessions with 90 nonce echoes / zero echoes	Only suspended phase PASS
Advertising channels 37/38/39	Native SDK v2	Target discovered on each channel; zero echoes in every trial	No reliable fix
Default/constant-latency power; LF RC/SYNTH	Native SDK v3/v4/v5	Zero echoes in all four trials	No reliable fix
PHY and link policies	Native SDK v6	Two isolated 30-echo harness passes, including an explicit 1M PHY request and default policy with longer connect allowance; both matching HCI traces recorded LL Response Timeout 0x22. Repeat and other policy trials failed	No clean, repeatable fix
TX +8 dBm and regulator selection	Native SDK v7	Baseline and TX8/LDO: zero echoes. TX8/DCDC: one 30-echo PASS with clean HCI local-host close, then repeat FAIL after two echoes; ten-second echo-deadline retry FAIL after nine echoes with HCI/peripheral timeout 0x08	Intermittent success; not a solution
CPU sleep versus busy idle	Native SDK v8	Sleep: zero echoes and HCI timeout 0x08. Busy: one 30-echo PASS with HCI local-host close; busy repeat: FAIL after twelve echoes with HCI/peripheral timeout 0x08 despite a ten-second echo deadline	Intermittent success; not a reliable fix
Short actual connection interval, TX8/DCDC/sleep idle	Native SDK v9	Channel37: 30 echoes and clean local close after update to 7.5 ms. All advertising channels: three sessions/90 echoes at actual 7.5 ms, but HCI recorded two teardown completions 0x22 about four seconds after host Disconnect commands, two failed-establishment attempts 0x3E and one local close. USB queries remained functional	Diagnostic candidate; not three clean reconnect passes
Same-image slow-interval control	Native SDK v9	Actual interval updated to 75 ms before service-discovery failure; zero echoes. HCI: four initial failures 0x3E and one 0x08; final SDK readback still connected	FAIL; controller/SDK observations retained separately
TX 0 dBm recovery with fast interval	Native SDK v9	Three payload sessions/90 echoes, but strict lifecycle: eight initial failures 0x3E, one 0x08, two 0x22 and one local close	Strict lifecycle FAIL
Quiet GATT initiation with fast interval	Native SDK v10	Three payload sessions/90 echoes; data_exchange_passed=true, passed=false. Strict lifecycle: five initial failures 0x3E, two 0x22 and one local close	Strict lifecycle FAIL; no reliable fix

A final native SDK v11 active/suspended/active comparison retained the same image and RAM phone-interval policy [12,12,0,400] (15 ms, zero latency, four-second supervision), TX +8 dBm, MCU REG1 DCDC, sleep idle and low-power mode, with advancing uptime and no reset observed. HCI verified actual 15 ms operation for all 270 nonce notifications. This is a connection-interval diagnostic, not phone interoperability testing.

V11 USB condition	Nonce echoes	Strict HCI lifecycle	Median echo RTT
Active, with application USB serial queries	90 across three payload sessions	FAIL: two initial failures 0x3E, two 0x22, one local close 0x16	452.8 ms
Runtime suspended, same image/policy	90 across three sessions	PASS: three clean local closes 0x16	33.7 ms
Active, no application USB serial I/O during BLE	90 across three payload sessions	FAIL: two initial failures 0x3E, one 0x22, two local closes 0x16	394.0 ms

The active phase recorded 344 USB telemetry query replies, including 154 link replies reporting BLE connected at actual 15 ms. The suspended and active-idle phases performed no application USB serial I/O during BLE; configuration readbacks bracketed those trials. Active-idle failure strengthens active USB as the discriminator even without application serial payloads. It does not establish an electrical, RF, peripheral or host implementation cause. The exact harness source 19703941... is preserved and digest-matched for all three runs.

Across the v9 runs, 168 USB link-query replies explicitly reported BLE connected at actual parameters [6,6,0,400] (7.5 ms interval, zero latency, four-second supervision): 41 replies over 39.576 seconds in the first run and 127 across the three repeat-session windows. The complete runs recorded 196 and 334 USB rssi/link query replies respectively, including discovery and disconnect periods. Linux samples reported active USB throughout, with configuration retained before and after. These are concurrent diagnostic command-response checks, not Full USB or secure Companion acceptance. The 0x22 events occurred after explicit host Disconnect commands; payload completion and clean teardown remain separate results. The same-image slow control subsequently observed actual 75 ms before failing with zero echoes; production verification remains pending.

Controller and SDK counters remain distinct. TX0 recorded twelve controller connection-complete events versus SDK connection/disconnect deltas 5/5; quiet v10 recorded eight versus SDK deltas 3/3. No cause is assigned to those differences. The exact original v9 and slow-control harness snapshots were recovered with matching SHA-256 values 83be8cf2... and 3295d776..., and retained as reproducibility evidence. The completed v11 comparison is reported above.

The two-echo repeat ended in a harness timeout without a captured HCI disconnect, so that failure alone does not prove link loss. The separate nine-echo trial did record link timeout despite its longer deadline. Early missing-characteristic and D-Bus failures remain host-workflow evidence and are excluded from clean BLE comparisons. T1000 remains FAIL for simultaneous active USB and reliable BLE. Normal Full 72a74c78 was subsequently restored from unmodified source using application-only ZIP SHA-256 ba092c8e29b5b752a3d1667a0980910d4bec5815dfd0f07277b2ba3b8ce4e25a. Restoration and two additional USB opens returned 19 responses across three ports, all closed, with unchanged identity, advancing post-restoration uptime, zero framing rejects/core errors and MCU auto/DCDC with zero recorded crashes. The gateway remained active. These are restoration and USB runtime smoke results; historical Full 42 qualification remains source-bound, and BLE/RF were not requalified at Full 72.

Cold boot, battery-only restart, complete phone/feature testing and fleet qualification remain untested. Unplugging USB alone does not prove a restart. Safe JSON retains source bindings, workflow distinctions and evidence digests without device secrets or raw addresses.

Later accepted measurements are recorded in the 2026-10-20 fleet qualification. Results and failures above retain their original firmware sources.