run 3

docs/pt2-protocol-summary.md

@@ -505,6 +505,23 @@ Current caution:
 - So the `0x50`-band currently looks like another valid maintained-background
   surface inside the broader `20 D0` class, not yet a uniquely privileged
   "real wake" surface.
+- A later HE40 completion pass extended that picture much farther upward:
+  - `0x61 @ 20 D0` -> `07 80 58 24 DD 7C`
+  - `0x81 @ 20 D0` -> `07 80 60 24 DD 44`
+  - `0xC1 @ 20 D0` -> `07 80 70 24 DD 54`
+  - `0xE1 @ 20 D0` -> `07 80 78 24 DD 5C`
+- That means the `20 D0` surface now looks like a broad upper command lattice,
+  not just a low-band or mid-band pocket.
+- HE40 also reinforced that `40 30` is a true aligned parallel surface:
+  - `0x01 @ 40 30` -> `07 80 40 28 D3 66`
+  - `0x41 @ 40 30` -> `07 80 50 28 D3 76`
+  - `0x61 @ 40 30` -> `07 80 58 28 D3 7E`
+- Small prefix-completion sweeps on `cmd=0x21 @ 20 D0` showed that nonzero
+  prefixes are not inert:
+  - `p2=0x01` opened `07 40 24 12 9D B6`
+  - `p1=0x01` opened `07 80 48 24 9D 2C`
+- So prefixes probably do **not** define the main lattice by themselves, but
+  they can perturb a known-live slot into variant families.
 
 ## What We Do Not Know
 
@@ -557,6 +574,163 @@ Current best read:
   stream that would normally feed the LCD, indicators, and value displays once
   the session is established
 
+## Probable CCU <-> RCP Traffic Model
+
+This is an inferred working model, not yet a proof. It is the best current
+attempt to explain both the manuals and the bench behavior using the same
+mental picture.
+
+### High-level picture
+
+Current best read:
+
+- the **CCU** probably holds the richer master state for the camera system
+- the **RCP** behaves more like a smart terminal:
+  - it sends operator events upstream
+  - it receives recurring camera/session state downstream
+  - it renders that state onto the LCD, lamps, and numeric readouts
+
+That would fit:
+
+- the manuals describing filter, extender, self-diagnosis, and other camera
+  state on the RCP display
+- the broad structured lattices now observed in the host-to-RCP direction
+- the way repeated valid-looking traffic can keep the panel semi-awake without
+  fully activating it
+
+### Likely traffic layers
+
+#### 1. Startup / identity / mode layer
+
+Probable job:
+
+- establish PT2/TX7 personality
+- announce CCU or camera-side mode/class
+- select a broad session context before live status traffic begins
+
+Best candidate families so far:
+
+- `90` startup-beacon surface:
+  - `07 80 64 40 30 C9`
+  - `07 80 E4 40 30 49`
+- `AF` startup-beacon surface:
+  - `07 80 0D 04 AB 7F`
+  - `07 80 0D 04 EB 3F`
+- `A0` appears to act as an opener or primer in several selector contexts
+
+Current interpretation:
+
+- these look more like startup or class beacons than maintained live camera
+  state by themselves
+
+#### 2. Maintained background status layer
+
+Probable job:
+
+- keep the panel in a live or semi-live session state
+- refresh recurring camera/control pages
+- provide the "boring background scan" a 1990s CCU would likely send
+
+Best candidate surfaces so far:
+
+- `20 D0` lattice:
+  - `0x01 -> 07 80 40 24 DD 64`
+  - `0x21 -> 07 80 48 24 DD 6C`
+  - `0x41 -> 07 80 50 24 DD 74`
+  - `0x61 -> 07 80 58 24 DD 7C`
+  - `0x81 -> 07 80 60 24 DD 44`
+  - `0xC1 -> 07 80 70 24 DD 54`
+  - `0xE1 -> 07 80 78 24 DD 5C`
+- parallel `40 30` lattice:
+  - `0x01 -> 07 80 40 28 D3 66`
+  - `0x41 -> 07 80 50 28 D3 76`
+  - `0x61 -> 07 80 58 28 D3 7E`
+- baseline `00 80` lattice:
+  - similar command slots but through `.. 20 D8 ..` surfaces
+
+Current interpretation:
+
+- these look like page/slot/status surfaces more than isolated commands
+- a real CCU may repeatedly scan a small subset of these, not the whole space
+- the panel's semi-awake behavior strongly suggests that at least part of this
+  layer is real maintained traffic
+
+#### 3. Detail / page / selector layer
+
+Probable job:
+
+- select which family or page of data is being discussed
+- open branches corresponding to different camera/status domains
+
+Best candidate families so far:
+
+- `E8`, `E9`, `EC` selector-like branches
+- opener/context family around `A0`, `90`, `AF`
+- downstream siblings:
+  - `7A`
+  - `7B`
+  - `FB`
+  - `FA`
+  - `E4`
+
+Current interpretation:
+
+- these may represent internal page classes or selector families
+- they probably help choose *which* maintained or readable surface is live
+- they do not yet look like the final always-on camera-state stream by
+  themselves
+
+#### 4. Operator event layer
+
+Probable job:
+
+- carry human actions from the RCP to the CCU/camera side
+
+Best candidate families so far:
+
+- CALL path:
+  - host synthetic high/low pair can provoke `07 80 45 20 D0 68`
+- CAM POWER and some other buttons:
+  - visible as outbound panel-origin activity
+  - but not yet shown to wake the panel or advance a session on their own
+
+Current interpretation:
+
+- this layer is probably mostly upstream: RCP telling the CCU what the operator
+  just did
+- the event path alone is not enough to create an active session
+
+### Most likely division of responsibility
+
+If this model is right, then:
+
+- the **CCU** likely maintains the richer camera-state lattice internally
+- the **RCP** likely maintains a smaller local cache:
+  - current screen/page
+  - local control state
+  - most recently received camera values
+  - active indicator/lamp state
+
+That would explain why:
+
+- broad command sweeps find orderly families
+- many repeated frames keep the panel semi-awake
+- but the panel still refuses to fully wake without the right overall stream
+
+### What this suggests for bench work
+
+The main practical implication is:
+
+- stop thinking only in terms of a single hidden wake frame
+- keep thinking in terms of:
+  - startup beacon/context
+  - then a believable recurring maintained subset
+  - then additional detail pages layered on top
+
+So the most likely missing ingredient is not just "more valid bytes." It is
+probably a **specific recurring traffic mix** that a real CCU would send once
+it had already identified the panel and camera path.
+
 ## Restoration Strategy
 
 Near-term practical strategy: