new run

docs/pt2-protocol-summary.md

@@ -409,6 +409,29 @@ Current caution:
     maintained session class
 - Interleaving heartbeat beside these startup-family maintenance frames also did
   not help.
+- The first DIP-switch single-bit sweep then showed that board configuration
+  also affects the startup-family layer:
+  - one setting (`S3-1`) shifted the `A0 -> 90` branch from `64 40 30` to
+    `E4 40 30`
+  - another (`S2-3`) suppressed the `90` branch in the first pass
+  - another (`S2-1`) appeared to disturb the `AF` branch and briefly changed the
+    LCD behavior
+- So the startup-beacon families are not only protocol-state-sensitive, but
+  also likely **DIP/personality-sensitive**.
+- A later broad direct sweep using host `state/value = 20 D0` added one more
+  important clue:
+  - command `0x01` produced a new `0x40`-family response:
+    `07 80 40 24 DD 64`
+  - and the panel reportedly stayed out of `CONNECT NOT ACT` longer during that
+    sustained sweep than in the simpler baseline sweeps
+- The baseline broad direct sweep at `state/value = 00 80` was also real and
+  rich, not flat:
+  - the completed `0x00-0xFF` pass logged `112` anomalies
+  - so the special thing about `20 D0` is **not** merely that it produced
+    responses, but that it shifted both the `0x40` family and the timeout-like
+    LCD behavior
+- That suggests `20 D0` may be a more session-like or status-like host payload
+  pair than `00 80`, even though it still does not by itself wake the panel.
 
 ## What We Do Not Know
 
@@ -421,7 +444,45 @@ Current caution:
 - How camera/CCU identity, camera model, or capability negotiation is encoded.
 - Whether the one-shot discovery latch is intentional protocol behavior or a
   side effect of an incomplete session.
-- Whether video/composite pins carry any status needed for full operation.
+- Whether the documented `VBS (X) IN` / `VBS (G) IN` inputs carry required
+  status/reference signals needed for full operation.
+
+## Manual Implications For The Live Session
+
+The operating manuals add a few important clues that line up well with the
+bench work so far:
+
+- The RCP is described as capable of **high-precision and high-speed control**.
+  That fits the observed serial behavior better as a structured parameter/status
+  channel than as a tiny button-only protocol.
+- The RCP can be connected:
+  - through a `CCU-TX7/TX7P` and `CA-TX7/TX7P`
+  - or directly to a `DXC-D30/D30P` via `CA-537/537P` or a `VCR`
+- The manuals explicitly say the LCD can display:
+  - filter value / filter position
+  - lens extender status
+  - camera self-diagnosis results
+
+What that implies for the protocol model:
+
+- the panel almost certainly expects a **richer upstream status stream** than
+  just heartbeat or simple ACKs
+- some of that upstream information must encode camera state, not merely panel
+  presence:
+  - optical filter position
+  - lens extender status
+  - active values / readouts
+  - self-diagnosis data when requested
+- this makes the observed one-shot `A0/B0/B5`-style readable blocks and the
+  selector-family pages (`E8/E9/EC`) feel more like **status/query surfaces**
+  than the complete live session
+
+Current best read:
+
+- the "missing wake condition" may not be one magic handshake frame
+- it may instead be the absence of a sustained, camera-originated information
+  stream that would normally feed the LCD, indicators, and value displays once
+  the session is established
 
 ## Restoration Strategy