pod RIO investigation day-end: board mutes ~13s after each start (render-load/power-rail hypothesis for tomorrow); USB re-enum does NOT revive it; keep tools/probe_rio.ps1 (raw COM1 hand-poll); note the stall-detector keying fix needed

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

context/pod-hardware.md

@@ -525,6 +525,22 @@ USB **selective suspend disabled** system-wide on the cab the same day (powercfg
 for the random-period idle dropouts. Hardware to-do: FTDI adapter into a REAR motherboard USB
 port, reseat its USB end. ⚠ A first "print-deadlock" diagnosis of the boot wedge was WRONG
 (confounded A/B) and is retracted — the dump is the authority.
+**Day-end state (2026-08-10 evening) + the pick-up plan.** The 881 soak measured the fault
+precisely: the board answers for **~13 s after each fresh game start** (254 replies at 20 Hz),
+then goes MUTE on analog for minutes while host→board writes keep completing (`req=3846 rep=254
+age=240s`, txTO frozen at 1, abandon=0). Direct hand-poll (`tools/probe_rio.ps1`, also at
+`C:\bt411\probe_rio.ps1` — raw COM1 CHECK/VERSION/ANALOG with correct [cmd][sum&0x7F] framing,
+DTR/RTS raised): **zero bytes**. USB re-enumeration of BOTH FTDI converters + immediate re-poll:
+**still zero** — which argues AGAINST the adapter (a wedged adapter RX clears on re-enum) and AT
+the board. ⚠ [T4 hypothesis for tomorrow]: 13 s ≈ when the mission render load lights up — a
+**power rail sagging under the cab's full load** would also explain the original mid-combat
+dropouts (explosion/load transients) and the button "revival" (load dips + harness jostle).
+Tomorrow, with hands: (1) loopback plug on the FTDI (TX→RX jumper, probe echoes = adapter fully
+exonerated); (2) 5 V/12 V at the RIO board while a mission loads (the 13 s correlation is the
+test); (3) swap in one of the spare Prolific adapters as cheap elimination; (4) rear-mobo USB
+port + ghost-COM cleanup regardless. ⚠ My STALL/RECOVER edge detector in 881 keys on
+request-age, which the 50 ms poll keeps resetting — it never fires; the `age=` field carries the
+real signal (fix the keying to reply-age at the next build).
 **Remote minidump procedure (worked over SSH, no tools install):** 32-bit dump of the wedged pid
 via `C:\Windows\SysWOW64\rundll32.exe C:\Windows\SysWOW64\comsvcs.dll, MiniDump <pid>
 C:\bt411\w.dmp full` → scp home → local x86 cdb (`where.exe cdb` resolves the bt411-tools copy)

tools/probe_rio.ps1

@@ -0,0 +1,26 @@
+# Hand-poll the RIO board over COM1 -- no game involved.  Wire format per
+# PCSerialPacket::SendPacket: [cmd][checksum = sum & 0x7F].
+$p = New-Object System.IO.Ports.SerialPort COM1,9600,None,8,One
+$p.DtrEnable = $true
+$p.RtsEnable = $true
+$p.ReadTimeout = 200
+$p.Open()
+'PORT OPEN  CTS=' + $p.CtsHolding + ' DSR=' + $p.DsrHolding
+
+function Send-Cmd([byte[]]$bytes, [string]$name) {
+    $p.DiscardInBuffer()
+    $p.Write($bytes, 0, $bytes.Length)
+    Start-Sleep -Milliseconds 700
+    $got = @()
+    while ($p.BytesToRead -gt 0) { $got += [byte]$p.ReadByte() }
+    $hex = ($got | ForEach-Object { $_.ToString('X2') }) -join ' '
+    "$name -> $($got.Count) byte(s): $hex"
+}
+
+Send-Cmd @([byte]0x80, [byte]0x00) 'CHECK   0x80'
+Send-Cmd @([byte]0x81, [byte]0x01) 'VERSION 0x81'
+Send-Cmd @([byte]0x82, [byte]0x02) 'ANALOG  0x82'
+Start-Sleep -Seconds 2
+Send-Cmd @([byte]0x82, [byte]0x02) 'ANALOG  again'
+$p.Close()
+'DONE'