new run

docs/discovery-notes.md

@@ -8033,3 +8033,462 @@ Best current read:
 - `CAM POWER` still looks much more like an **outbound panel-origin operator
   event** than a wake/session negotiation hook.
 - `CALL` remains the more protocol-interesting operator event family.
+
+### DIP Switch Experiment Ladder
+
+Current known baseline:
+
+- all 8 DIP positions are currently **off**
+- switches are grouped as:
+  - `S2` = 4 positions
+  - `S3` = 4 positions
+- together they likely feed MCU pins `43-50`
+
+Goal:
+
+- determine whether the DIP switches change the panel's startup personality,
+  serial behavior, or wake/session behavior
+
+### Safety / Method
+
+Use this method for every DIP test:
+
+1. Photograph the current DIP positions before changing anything.
+2. Change **one switch only**.
+3. Reassemble only as much as needed for safe power-on.
+4. Power up the panel.
+5. Observe behavior **before connecting serial**.
+6. Then run the normal serial baseline checks.
+7. Power down fully before changing the next switch.
+8. Return to the all-off baseline between non-adjacent tests.
+
+Record for each run:
+
+- exact DIP pattern
+- LCD startup text
+- whether the active light changes
+- whether `CONNECT NOT ACT` appears, and when
+- whether idle heartbeat is still `00 00 00 00 80 DA`
+- whether known probes still behave the same:
+  - `A0`
+  - `A0 -> 90`
+  - `A0 -> AF`
+- any new button behavior in idle state
+- any complete silence / obvious baud or protocol change
+
+### Naming Convention
+
+Use a simple notation in notes/logs:
+
+- baseline = `S2=0000 S3=0000`
+- example single change:
+  - `S2=1000 S3=0000`
+
+If physical numbering is unclear, first pick one fixed convention and stick to
+it:
+
+- `S2-1` .. `S2-4`
+- `S3-1` .. `S3-4`
+
+### Phase 1: Single-Bit Sweep
+
+Goal:
+
+- find out whether any single DIP bit has an obvious effect on startup,
+  protocol, or front-panel behavior
+
+Run these eight tests, always starting from all-off baseline:
+
+1. `S2-1` on, all others off
+2. `S2-2` on, all others off
+3. `S2-3` on, all others off
+4. `S2-4` on, all others off
+5. `S3-1` on, all others off
+6. `S3-2` on, all others off
+7. `S3-3` on, all others off
+8. `S3-4` on, all others off
+
+For each test:
+
+- power-cycle
+- watch LCD/startup state
+- check for idle heartbeat
+- try one minimal probe set:
+  - idle listen
+  - `A0`
+  - `A0 -> 90`
+  - `A0 -> AF`
+
+What would count as a hit:
+
+- panel boots into a different visible mode
+- panel no longer shows `CONNECT NOT ACT`
+- heartbeat changes or disappears
+- known startup families change:
+  - `64 40 30`
+  - `0D 04 AB`
+  - `0D 04 EB`
+  - `E4 40 30`
+- buttons become active in idle
+
+### Phase 2: Group Identity Test
+
+Only do this after Phase 1.
+
+Goal:
+
+- see whether one whole DIP bank behaves like an address nibble or mode nibble
+
+Run these four tests:
+
+1. all `S2` on, `S3` all off
+2. all `S2` off, all `S3` on
+3. all `S2` on, all `S3` on
+4. return to all-off baseline and confirm behavior is restored
+
+What this can reveal:
+
+- one bank may control personality while the other controls address
+- one bank may do nothing while the other changes the panel sharply
+- all-on may expose service/test behavior that single-bit changes do not
+
+### Phase 3: Follow-Up Only If A Bit Matters
+
+If Phase 1 reveals a promising bit, branch carefully:
+
+1. repeat that same switch setting twice to confirm reproducibility
+2. test neighboring bits in the same bank
+3. test that bit plus one neighboring bit
+4. compare:
+   - startup text
+   - heartbeat
+   - `A0 -> 90`
+   - `A0 -> AF`
+   - `E8` / `EC` selector behavior
+
+### Good First Serial Checks Per DIP Setting
+
+Keep the serial side small at first.
+
+Recommended order:
+
+1. idle listen only
+2. repeating heartbeat only
+3. `A0`
+4. `A0 -> 90`
+5. `A0 -> AF`
+
+Only if something changes meaningfully, then test:
+
+- `E8`
+- `E9`
+- `EC`
+- CALL synthetic trigger
+
+### Strong Cautions
+
+- Do not change multiple unknown DIP bits at once in the first pass.
+- Do not assume `ON` means logic high; it may actually pull the line low.
+- Some switches may only be sampled at cold boot, not warm reset.
+- A strange setting may stop normal serial output entirely; that is still a
+  useful result.
+- If one setting produces a dramatically different boot state, stop and record
+  it before going wider.
+
+### DIP Phase 1 Results
+
+Practical visible result:
+
+- Most single-bit DIP settings looked the same on the panel.
+- User-reported visible exception:
+  - the **first DIP-switch setting** briefly showed a small cursor on the LCD
+    for a few seconds
+- Otherwise, no single-bit setting visibly woke the panel or cleared
+  `CONNECT NOT ACT`.
+
+Serial result:
+
+- The DIP switches are **not** inert.
+- They do not appear to change the basic heartbeat personality dramatically, but
+  they **do** affect which startup-beacon family opens.
+
+Stable observations across most tested single-bit settings:
+
+- idle heartbeat remained present
+- plain `A0` remained heartbeat-compatible only
+- `A0 -> AF` usually still opened:
+  - `07 80 0D 04 AB 7F`
+- `A0 -> 90` usually still opened:
+  - `07 80 64 40 30 C9`
+
+Important exceptions:
+
+#### `S2-1`
+
+- user saw a temporary small LCD cursor
+- `A0 -> 90` still opened:
+  - `07 80 64 40 30 C9`
+- but `A0 -> AF` went flat:
+  - no RX in the recorded run
+- heartbeat-only stimulus produced:
+  - `07 80 C0 40 30 6D`
+
+Read:
+
+- `S2-1` appears to change startup/UI behavior and may suppress or disturb the
+  `AF`-family startup branch.
+
+#### `S2-3`
+
+- `A0 -> 90` collapsed to heartbeat-only
+- `A0 -> AF` still opened:
+  - `07 80 0D 04 AB 7F`
+- heartbeat-only stimulus produced:
+  - `07 80 40 40 30 ED`
+
+Read:
+
+- `S2-3` appears to suppress the `90`/`64` startup-beacon branch while leaving
+  the `AF`/`AB` side alive.
+
+#### `S3-1`
+
+- `A0 -> 90` opened a **different** startup family:
+  - `07 80 E4 40 30 49`
+  instead of the more common:
+  - `07 80 64 40 30 C9`
+- `A0 -> AF` still opened:
+  - `07 80 0D 04 AB 7F`
+- heartbeat-only stimulus produced:
+  - `07 80 40 40 30 ED`
+
+Read:
+
+- `S3-1` is the clearest proof so far that the DIP bank can steer the panel
+  into a different startup-family page rather than merely changing noise or
+  timing.
+
+#### Other tested single-bit positions
+
+Settings that still looked broadly "normal" in the first pass:
+
+- `S2-2`
+- `S2-4`
+- `S3-3`
+- `S3-4`
+
+These generally preserved:
+
+- `A0 -> 90` -> `07 80 64 40 30 C9`
+- `A0 -> AF` -> `07 80 0D 04 AB 7F`
+
+Heartbeat-only transients varied by setting:
+
+- `S2-2`, `S2-3`, `S2-4`, `S3-1`, `S3-3` tended toward:
+  - `07 80 40 40 30 ED`
+- `S2-1`, `S3-2`, `S3-4` tended toward:
+  - `07 80 C0 40 30 6D`
+
+Missing / not-found logs:
+
+- `captures/dip-s3-1-a0.txt`
+- `captures/dip-s3-2-a0-90.txt`
+
+So the current first-pass read should stay slightly cautious around those two
+cases.
+
+### DIP Phase 1 Read
+
+Best current interpretation:
+
+- the DIP switches likely do participate in **panel personality / startup mode
+  selection**
+- they do **not** appear to erase or obviously reconfigure the panel in a
+  catastrophic way during normal testing
+- they can bias:
+  - whether the `90` startup branch opens
+  - which `90` family appears (`64` vs `E4`)
+  - whether the `AF` branch survives cleanly
+
+Most important next follow-ups:
+
+1. repeat `S3-1` to confirm the `E4` startup-family shift
+2. repeat `S2-3` to confirm suppression of the `90` branch
+3. repeat `S2-1` to confirm suppression/instability of the `AF` branch and the
+   brief LCD cursor
+
+### HE34: Broad "Dot The I's" Command Sweep
+
+Goal:
+
+- run a broad automated sweep of many checksum-valid commands
+- log any response that is not explainable as ordinary heartbeat traffic
+- do one "clean conscience" pass so we can say we really checked the space
+
+Why this is worth doing:
+
+- we now know the startup-family surface is real and DIP-sensitive
+- but we still have not done one final broad, automation-first pass with the
+  current tools and classifier
+
+Recommended order:
+
+1. all-off DIP baseline
+2. optional repeat under `S3-1` because it opens the `E4` startup family
+3. optional repeat under `S2-3` because it suppresses the `90` branch
+
+#### HE34a: Cold direct sweep, all-off baseline
+
+This tests all command bytes `0x00-0xFF` in the observed host frame shape:
+
+- prefix: `00 00`
+- state/value: `00 80`
+
+The script:
+
+- logs heartbeat-compatible windows quietly
+- logs any anomaly explicitly
+- pauses on anomaly so you can power-cycle and continue
+
+```powershell
+python scripts/serial_direct_response_sweep.py --port COM5 --prefix1s 0x00 --prefix2s 0x00 --commands 0x00-0xFF --states 0x00 --values 0x80 --settle 3.0 --after-each 0.8 --after 2.0 --pause-on-anomaly --log captures/he34-direct-alloff-00-80.txt
+```
+
+#### HE34b: Cold direct sweep, `S3-1` active
+
+Same sweep, but under the DIP setting that shifted the startup-family page from
+`64` to `E4`.
+
+```powershell
+python scripts/serial_direct_response_sweep.py --port COM5 --prefix1s 0x00 --prefix2s 0x00 --commands 0x00-0xFF --states 0x00 --values 0x80 --settle 3.0 --after-each 0.8 --after 2.0 --pause-on-anomaly --log captures/he34-direct-s3-1-00-80.txt
+```
+
+#### HE34c: Cold direct sweep, `S2-3` active
+
+Same sweep, but under the DIP setting that suppressed the `90` branch in the
+first pass.
+
+```powershell
+python scripts/serial_direct_response_sweep.py --port COM5 --prefix1s 0x00 --prefix2s 0x00 --commands 0x00-0xFF --states 0x00 --values 0x80 --settle 3.0 --after-each 0.8 --after 2.0 --pause-on-anomaly --log captures/he34-direct-s2-3-00-80.txt
+```
+
+#### Optional HE34d: Smaller second pass with alternate state/value
+
+If the first pass looks too flat, do a smaller alternate parameter pass:
+
+- commands: `0x00-0xFF`
+- state/value: `20 D0`
+
+```powershell
+python scripts/serial_direct_response_sweep.py --port COM5 --prefix1s 0x00 --prefix2s 0x00 --commands 0x00-0xFF --states 0x20 --values 0xD0 --settle 3.0 --after-each 0.8 --after 2.0 --pause-on-anomaly --log captures/he34-direct-alloff-20-d0.txt
+```
+
+Read:
+
+- a broad sweep like this is not expected to magically wake the panel
+- what it *can* do is reveal:
+  - overlooked command families
+  - DIP-sensitive outliers
+  - whether the current known families are really the whole visible surface
+
+### HE34 Initial Result: Broad `20 D0` Sweep
+
+Run observed:
+
+- capture file present:
+  - `captures/he34-direct-alloff-20-d0-no-pwr.txt`
+
+Important panel-side observation:
+
+- unlike the more ordinary broad sweeps, `CONNECT NOT ACT` reportedly **did not
+  appear after the first anomaly**
+- instead, the panel stayed out of that state until much later in the run
+- on the latest run, the user interrupted with `Ctrl+C` when
+  `CONNECT NOT ACT` finally came on screen near the end
+
+That makes this run interesting even before looking at the anomaly bytes:
+
+- the sustained `state/value = 20 D0` traffic appears to hold the panel out of
+  the inactive timeout state longer than the simpler baseline sweeps
+
+#### Serial anomaly found so far
+
+The first repeatable anomaly in the `20 D0` sweep occurred at:
+
+- command `0x01`
+
+Observed family:
+
+- `07 80 40 24 DD 64`
+
+Example raw window:
+
+- `00 00 00 80 DA 07 80 40 24 DD 64 07 80 40 24 DD 64 07 80 40 24 DD 64 07 80 40 24 DD 64`
+
+Repeated later as:
+
+- `07 80 40 24 DD 64`
+  repeated four times without the leading heartbeat fragment
+
+Read:
+
+- this is a **new `0x40`-family sibling**
+- it is not the older fallback/transient:
+  - `07 80 40 40 30 ED`
+- and it is not the `C0 40 30 6D` branch either
+
+Best current interpretation:
+
+- `20 D0` is not just "another payload pair"
+- under a broad sustained sweep, it appears to:
+  - expose at least one new structured `0x40`-family page
+  - and also change the panel's timeout / inactive-screen behavior
+
+This does **not** prove wake-up or active session, but it does make `20 D0`
+look more session-like than the simpler `00 80` broad sweeps.
+
+Best next follow-up from this result:
+
+1. confirm `cmd=0x01, state/value=20 D0` directly in a short targeted test
+2. compare `cmd=0x00`, `0x01`, `0x02`, `0x03` under `20 D0`
+3. compare whether repeating only `00 00 01 20 D0 AB` delays `CONNECT NOT ACT`
+   the same way the broader sweep did
+
+### HE34 Completion Cross-Check
+
+For completion's sake, the three HE34 captures do **not** all carry the same
+weight:
+
+- `captures/he34-direct-alloff-00-80.txt`
+  - this is the **completed** baseline sweep
+  - it ran through the full `0x00-0xFF` command range
+  - it ended cleanly with:
+    - `FINAL heartbeat-compatible RX: 18 bytes, offset 0, 3 frames + 0 bytes`
+    - `Anomalies: 112`
+- `captures/he34-direct-alloff-00-80-no-pwr.txt`
+  - this is an **interrupted partial rerun**
+  - it reproduced the first known baseline anomaly at `cmd=0x01`:
+    - `07 80 40 20 D8 65`
+  - but it should not be treated as the authoritative baseline map
+- `captures/he34-direct-alloff-20-d0-no-pwr.txt`
+  - this is also an **interrupted** run
+  - but it is still important because it reproduced a distinct first anomaly:
+    - `07 80 40 24 DD 64`
+  - and the panel-side timeout behavior was observably different
+
+That gives the HE34 branch a cleaner interpretation:
+
+- `00 80` already yields a **broad structured response map**, not just a couple
+  of isolated hits
+- so `20 D0` is interesting **not because it is the only state/value pair that
+  produces anomalies**
+- it is interesting because:
+  - its first mapped `0x40`-family response differs from the baseline
+  - and the panel reportedly stayed out of `CONNECT NOT ACT` much longer during
+    the run
+
+So the right next question is:
+
+- not "does `20 D0` produce any anomalies at all?"
+- but "does `20 D0` represent a more session-like variant of the same broad
+  command surface?"

docs/pcb-notes.md

@@ -118,6 +118,99 @@ Useful implication:
 - `CN1` is now the strongest candidate for the board-side harness/IO connector
   that should be traced against the external 10-pin cable assembly
 
+### `CN1` Continuity Mapping
+
+Based on your continuity tracing and the board silkscreen numbering:
+
+| `CN1` pin | Observed function | Internal wire color | External 10-pin |
+| --- | --- | --- | --- |
+| `1` | `VBS (X) IN` | white | pin `2` |
+| `2` | `VBS (G) IN` | blue | pin `3` |
+| `3` | data ground | grey | pin `5` |
+| `4` | data `RCP -> CCU` | yellow | pin `4` |
+| `5` | data `CCU -> RCP` | orange | pin `7` |
+| `6` | data ground | brown | pin `6` |
+| `7` | ground | black | pin `9` |
+| `8` | `DC+` | red | pin `10` |
+
+Important observations:
+
+- `CN1` pin `7` is the main ground path and maps to external pin `9`
+- `CN1` pin `8` is DC power and maps to external pin `10`
+- the serial pair is now clearly confirmed at the board level:
+  - `CN1` pin `4` / external pin `4` = `RCP -> CCU`
+  - `CN1` pin `5` / external pin `7` = `CCU -> RCP`
+- there are **two additional non-serial signal inputs** on external pins `2`
+  and `3`
+- there are **two separate data-ground/return lines** on external pins `5` and
+  `6`
+
+Very important electrical note from tracing:
+
+- the two data-ground lines (`CN1` pins `3` and `6`) were observed as **not
+  connected to common ground**
+
+That strongly suggests the connector is not just:
+
+- power
+- one TX line
+- one RX line
+
+Instead, it likely carries a mixed signal set with at least:
+
+- analog/video-related inputs
+- serial/control
+- separate signal returns
+- power/common ground
+
+Refined grounding observation:
+
+- the separate data grounds appear to connect to common ground **through small
+  ceramic capacitors** near the connector
+- the relevant parts are labeled:
+  - `C55`
+  - `C56`
+
+This changes the interpretation from "totally isolated grounds" to something
+more like:
+
+- DC-isolated or not directly hard-tied
+- but AC-coupled / noise-referenced to common ground
+
+That is a very plausible arrangement for:
+
+- signal-return noise control
+- EMI filtering
+- keeping the data pair referenced without fully hard-bonding the return paths
+
+### Manual Cross-Check: External Connector Signals
+
+The manual fragment for the external connector aligns very strongly with the
+continuity map we traced:
+
+| External pin | Manual signal | Notes |
+| --- | --- | --- |
+| `1` | `(SPARE)` | matches the fact that it has not appeared on `CN1` |
+| `2` | `VBS (X) IN` | manual notes `1.0 Vp-p, sync negative` |
+| `3` | `VBS (G) IN` | confirms a second VBS input line |
+| `4` | `S. DATA (RCP -> CCU)` | matches traced serial-out line |
+| `5` | `S. DATA GND` | matches traced separate data ground |
+| `6` | `S. DATA GND` | matches traced separate data ground |
+| `7` | `S. DATA (CCU -> RCP)` | matches traced serial-in line |
+
+This is a strong confirmation that the harness tracing is fundamentally right.
+
+Big implication:
+
+- `VBS (X) IN` and `VBS (G) IN` are not mystery wires anymore
+- they are documented inputs and are likely meaningful to normal panel
+  operation
+- the wake/session problem may therefore depend on more than serial traffic,
+  although board-level routing now suggests that may vary by revision/options
+
+The manual wording also strengthens the idea that these are likely
+video/reference-style inputs rather than general-purpose logic lines.
+
 ### H8 / DIP Area
 
 - the H8 marking is now clearly readable in-package as:
@@ -163,6 +256,117 @@ Working interpretation:
 - nearby resistor-network and option-footprint areas also fit the picture of a
   configurable CPU/control board with variant population options
 
+### Serial Interface Confirmation
+
+Tracing from the connector into the board:
+
+- external pin `4` / `CN1` pin `4` goes to a `MAX202` device at package pad
+  `14`
+- external pin `7` / `CN1` pin `5` goes to the same `MAX202` device at package
+  pad `13`
+- no other `CN1` pins were observed going to that `MAX202`
+
+Observed marking on the interface chip:
+
+- `MAX202`
+- `CSE 0107`
+
+Interpretation:
+
+- this is a very strong confirmation that the PT2 serial path is carried as a
+  real RS-232-style interface through a dedicated line transceiver
+- it also strongly implies the other connector lines (`1`, `2`, `3`, `6`) are
+  **not** just extra serial handshake pins to the same interface chip
+- the wake/session problem may therefore involve:
+  - analog/video sense inputs
+  - separate return/reference behavior
+  - or higher-level protocol/state expectations beyond the RS-232 channel alone
+
+Refined serial-ground read:
+
+- because the two `S. DATA GND` lines are capacitor-coupled to common ground,
+  the serial interface likely expects a somewhat cleaner/dedicated return
+  structure than a naive "everything tied straight together" hookup
+- this does **not** by itself explain the missing wake/session behavior
+- but it does support the idea that Sony treated the remote link as a proper
+  interface with controlled grounding rather than as a casual single-ground
+  wiring bundle
+
+### Important Open Electrical Discrepancy
+
+The manual fragment for external pin `7` appears to describe:
+
+- `Zi >= 10 kohm`
+- high/open state around `4.5 +/- 0.5 V`
+- low state around `0 +/- 0.5 V`
+
+That does **not** read like a classic bipolar RS-232-level description.
+
+But the board tracing currently shows external pin `7` going into the `MAX202`
+at pad `13` (`R1IN` on a standard MAX202 pinout), while external pin `4` goes
+to pad `14` (`T1OUT`).
+
+So there is now a real discrepancy to resolve:
+
+1. the manual signal description for pin `7` looks logic/open style
+2. the board tracing looks like an RS-232 transceiver path
+
+Possible explanations to keep open for now:
+
+- the manual fragment may describe behavior at a different system boundary or
+  for a slightly different revision/context
+- the Sony interface may be electrically unusual despite using a `MAX202`
+- there may be surrounding circuitry affecting how the line behaves at the
+  connector
+
+For now, the safest conclusion is:
+
+- the signal names are strongly confirmed
+- the exact electrical behavior still needs reconciliation
+
+### Board Construction / Routing Note
+
+- The board appears to be a **2-layer PCB**
+- Components are populated on only **one side**
+- With transmitted light, traces appear visible on the opposite side, with no
+  obvious evidence of hidden inner layers
+
+This matters because it makes visual trace-following more trustworthy and makes
+the connector routing conclusions stronger.
+
+### VBS Routing Observation
+
+New tracing observation:
+
+- `VBS (X) IN` and `VBS (G) IN` do **not** appear to run into the CPU/serial
+  section directly
+- instead, they route to the side of the board toward an **empty connector
+  position labeled `CN5`**
+- the only other obvious trace associated with that area appears to be ground
+
+Working interpretation:
+
+- the VBS lines may be routed primarily to an **unpopulated optional connector
+  or daughterboard position**
+- this could mean:
+  - the TX7 PCB was designed for a variant that used the VBS signals more
+    directly
+  - this particular board revision does not currently use them in the populated
+    build
+  - or the signals are simply passed through / made available without deep
+    local processing
+
+Why this matters:
+
+- this weakens the earlier "VBS is definitely the missing wake input" theory
+- it does **not** eliminate it completely
+- but it does suggest the most immediate wake/session logic is still more likely
+  to live in:
+  - the serial path
+  - the DIP/boot configuration
+  - optional/unpopulated variant circuitry
+  - or retained configuration in NVRAM/firmware
+
 ## Additional Silkscreen / Board Markings
 
 Observed so far:
@@ -571,3 +775,36 @@ Only if something changes meaningfully, then test:
   useful result.
 - If one setting produces a dramatically different boot state, stop and record
   it before going wider.
+
+## DIP Switch First-Pass Results
+
+The first single-bit sweep produced a useful answer:
+
+- the DIP switches are **not** inert
+- but they do **not** seem to act like a blunt "service mode on/off" in the
+  simplest sense
+
+What changed visibly:
+
+- user reported that the first tested DIP setting briefly showed a **small
+  cursor on the LCD**
+- the other single-bit settings looked the same visually
+
+What changed serially:
+
+- `S3-1` shifted the `A0 -> 90` startup family from:
+  - `07 80 64 40 30 C9`
+  to:
+  - `07 80 E4 40 30 49`
+- `S2-3` suppressed the `A0 -> 90` branch entirely in the first pass
+- `S2-1` left `A0 -> 90` alive but appears to have flattened `A0 -> AF`
+
+Best current hardware interpretation:
+
+- the DIP banks very likely participate in **startup personality / mode
+  selection**
+- they may not directly control "active vs inactive panel"
+- but they clearly can steer which startup-family surface the firmware exposes
+
+This is consistent with the earlier suspicion that `S2` + `S3` form a boot-time
+configuration byte rather than casual front-panel options.

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