#160 CLOSED -- the cab's RIO axis dropouts + frozen boots were the FTDI adapter's BUFFER SIZE set too high (Nick, on the cab). An oversized receive buffer batches incoming serial instead of delivering it promptly: analog samples arrive late and in clumps (the field 'encoder dropouts') and the boot handshake can miss its window entirely (the wedge). NO port code was ever at fault -- every software hypothesis in the pod-hardware RIO section (power-rail sag under mission load, board-side wedge, print deadlock) is superseded; what survives from those notes is the diagnostic procedure, not the theories. Recorded in context/pod-hardware.md 9a with the setting path (Device Manager -> COM port -> Port Settings -> Advanced -> lower Receive (Bytes); Latency Timer flagged [T4] as the adjacent standard knob, not confirmed part of the fix) and as an operator-facing troubleshooting row in docs/OPERATOR_GUIDE.md, because a fresh FTDI install on any future cab build comes up with defaults that reproduce it. Ledger lesson: a fault that reproduces on ONE machine and survives every code change is a DRIVER/CONFIG suspect before it is a code suspect.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

context/pod-hardware.md

@@ -541,6 +541,20 @@ test); (3) swap in one of the spare Prolific adapters as cheap elimination; (4)
 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).
+**✅ RESOLVED 2026-08-15 (#160) — it was the FTDI adapter's BUFFER SIZE, set too high [T2,
+Nick on the cab].** Lowering it fixed BOTH halves: the mid-play axis dropouts and the frozen
+boots. An oversized receive buffer makes the driver BATCH incoming serial data instead of
+delivering it promptly, so RIO analog samples arrive late and in clumps (the "encoder dropouts")
+and the boot-time handshake can miss its window outright (the wedge). **No port code was ever at
+fault** — every software theory in this section (power rail sag, board-side wedge, print
+deadlock) is superseded; the surviving value of those notes is the diagnostic procedure, not the
+hypotheses. Set on every future cab build or driver reinstall, since a fresh FTDI install comes
+up with defaults that reproduce it: Device Manager → the COM port → Properties → Port Settings →
+**Advanced** → lower **Receive (Bytes)**; check **Latency Timer** in the same panel at the same
+time (1 ms is the usual value for responsive serial devices) [T4 — the adjacent standard knob,
+not confirmed as part of Nick's fix]. Lesson for the ledger: a fault that reproduces on ONE
+machine and survives every code change is a DRIVER/CONFIG suspect before it is a code suspect.
+
 **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)

docs/OPERATOR_GUIDE.md

@@ -223,6 +223,7 @@ raise the seat count if you're simply out of seats.
 | A player gets **ROSTER FULL** | no free seat in the current round | Re-arm between rounds so the roster re-opens, then let them join |
 | Console window stops responding | the relay stalled on a dead connection | Stop Session, Start Session; please keep the log (below) |
 | A player says they cannot connect at all | ports, or wrong address | confirm 1500/1501 TCP + 1501 UDP reach this machine |
+| **Pod cab only:** stick/throttle/pedals go dead mid-round, or the cab freezes during boot | the USB-serial (FTDI) adapter's **buffer size is too high**, so cockpit data arrives in late clumps | Device Manager → the RIO's COM port → Properties → **Port Settings → Advanced** → lower **Receive (Bytes)**. Re-check after any driver reinstall or new cab build — FTDI defaults bring it back. |
 
 ### The one thing to do before restarting a session