Sony-rcp/docs/pt2-protocol-summary.md

# Sony PT2 Camera Control Protocol Working Summary

This is a working model for restoring the Sony RCP-TX7 style PT2 camera control
link. It is based on bench captures and manuals gathered in this repo, not on an
official Sony protocol specification.

## Scope

- Target device: Sony RCP-TX7 camera control panel from the 1990s.
- Likely protocol family: Sony PT2-era camera/RCP control.
- Evidence: newer Sony RCP manuals describe a `PT2`/`PT7` mode switch, and `PT2`
  is documented for the same camera line that the TX7 controls.
- Current goal: identify enough of the host/CCU side protocol to restore useful
  panel operation.

## Electrical Layer

Confirmed wiring and levels:

| RCP 10-pin pin | Cable color | Current identification |
| ---: | --- | --- |
| 1 | red | spare/unknown |
| 2 | black | VBS/composite video |
| 3 | green | VBS/composite video ground |
| 4 | orange | serial data RCP -> CCU/camera |
| 5 | blue | serial/data ground |
| 6 | grey | serial/data ground |
| 7 | purple | serial data CCU/camera -> RCP |
| 8 | white/purple | spare/unknown |
| 9 | brown | ground/DC return |
| 10 | brown-white | +12 V power |

Observed idle measurements:

- Pin 4 relative to pin 9: about `-9 V`.
- Pin 7 relative to pin 9: about `+0.037 V` until driven by the adapter.
- This strongly indicates true RS-232 signaling, not TTL UART.

Bench adapter setup:

- Adapter RS-232 `RXD` to RCP pin 4.
- Adapter RS-232 `TXD` to RCP pin 7.
- Adapter `GND` to RCP pin 9.
- Serial settings used throughout: `38400 8N1`.

## Frame Shape

Most useful traffic is six bytes:

```text
prefix1 prefix2 command state value checksum
```

Current checksum hypothesis:

```text
checksum = 0x5A XOR prefix1 XOR prefix2 XOR command XOR state XOR value
```

Examples:

| Frame | Meaning in current model |
| --- | --- |
| `00 00 00 00 80 DA` | RCP heartbeat/status while not active |
| `00 00 07 80 00 DD` | RCP CAM POWER event |
| `00 00 15 80 00 CF` | CALL high/on state |
| `00 00 15 00 00 4F` | CALL low/off state |
| `07 80 45 20 D0 68` | RCP response to host-sent CALL high/low pair |
| `07 80 45 30 D0 78` | sibling CALL-response-family frame, seen once |

The RCP-origin non-heartbeat responses discovered so far usually begin with
`07 80`. Host frames tested so far usually use `00 00`.

## Baseline RCP Behavior

With power and no valid host session, the RCP repeatedly sends:

```text
00 00 00 00 80 DA
```

Only a few front-panel actions have produced unique frames while disconnected:

| Control | RCP-origin frame |
| --- | --- |
| CAM POWER | `00 00 07 80 00 DD` |
| CALL high/on | `00 00 15 80 00 CF` |
| CALL low/off | `00 00 15 00 00 4F` |

Most other controls have not yet emitted unique frames in the disconnected or
`CONNECT NOT ACT` state.

## Display State

Many checksum-valid and even some invalid host-side frames make the RCP display
`CONNECT NOT ACT`.

Known interpretation:

- `CONNECT NOT ACT` means the panel sees activity that looks connection-related.
- It does not mean the panel is active.
- It does not prove checksum validity.
- It can remain on screen while serial behavior changes underneath.

Unknown:

- The host sequence that changes the panel from `CONNECT NOT ACT` to an active
  control state.

## Discovery / Status Query Surface

The strongest discovery/status pattern is:

```text
Host primer: 00 00 00 00 80 DA
Host query:  00 00 XX 00 80 checksum
RCP reply:   07 80 ... ... ... checksum
```

Selected confirmed examples:

| Host sequence | RCP response |
| --- | --- |
| `00 -> B0` | `07 80 6C 40 30 C1` |
| `00 -> B2` | `07 80 36 10 0C F7` |
| `00 -> B3` | `07 80 36 10 2C D7` |
| `00 -> B4` | `07 80 6D 40 30 C0` |
| `00 -> B5` | `07 80 6D 20 D8 48` |

Other A/B/C region queries also return structured responses. The response set
looks like a readable status/capability surface, not random noise.

Important latch behavior:

- Many discovery/status responses are one-shot after power-up.
- Repeating the same query without a power cycle often returns only heartbeat.
- Re-sending the primer does not always clear this state.
- Broad unlatch sweeps after `B5` and `A0` did not find a reset/unlatch command.

Working interpretation:

- The host/CCU probably performs a discovery or capability read early in the
  session.
- The panel then enters a state where repeated discovery reads are suppressed.
- A missing session-advance or keepalive step probably follows.

## CALL Event Path

This is the most reproducible event-response path found so far.

The host can send the same frames the RCP uses for CALL state:

```text
CALL high: 00 00 15 80 00 CF
CALL low:  00 00 15 00 00 4F
```

If the host sends CALL high then CALL low with a small inter-frame gap, the RCP
responds:

```text
07 80 45 20 D0 68
```

Confirmed details:

- The physical CALL button is not required.
- Cold no-button startup injection works with both 50 ms and 80 ms gaps.
- CALL high alone does not trigger the response.
- CALL low alone does not trigger the response.
- Sending high and low back-to-back is less reliable than adding a gap.

Known sibling response:

```text
07 80 45 30 D0 78
```

This was observed once during timing tests. It shares the `07 80 45` response
family, but the exact state meaning is unknown.

What does not work:

- Answering `07 80 45 20 D0 68` with `00 00 45 00 80 9F`,
  `00 00 45 20 D0 EF`, or exact echo did not change the serial state.
- Triggering the CALL `0x45` path and then sending `00 -> B5` did not produce
  the known `B5` discovery response.
- The CALL path is real and useful for probing, but is not currently the
  activation handshake.

## Heartbeat / Cadence Behavior

Plain host heartbeat traffic has turned out to matter, but not in the simple
"session OK" way we first hoped.

Confirmed behavior:

- Repeating `00 00 00 00 80 DA` can keep the panel out of `CONNECT NOT ACT`
  while the traffic continues.
- When that traffic stops, the panel typically falls into `CONNECT NOT ACT`
  after a short timeout.
- Once the panel is already in `CONNECT NOT ACT`, resuming heartbeat alone does
  not immediately make it active again.
- Keeping heartbeat running does not by itself make one-shot reads like
  `00 -> A0` or `00 -> B0` reusable.

Heartbeat-only or heartbeat-heavy runs can also provoke transient structured
responses:

- `07 80 40 40 30 ED`
- `07 80 40 60 30 CD`
- `07 80 C0 40 30 6D`

Best current interpretation:

- Some host traffic satisfies a "host present" or link-alive condition.
- That is still separate from whatever camera/session information makes the
  panel truly active.
- The `0x40` / `0xC0` heartbeat-family responses look cadence- or
  context-sensitive rather than like a generic `ACK`.

## Known Response Families

These are the response frames that are stable enough to treat as known working
observations. "Meaning" here is still an engineering interpretation, not a
confirmed Sony definition.

| Frame / family | Trigger | Confidence | Best current meaning |
| --- | --- | --- | --- |
| `07 80 68 40 30 C5` | `00 -> A0` | high | readable query/status block, not a generic ACK |
| `07 80 6C 40 30 C1` | `00 -> B0` | high | readable query/status block, not a generic ACK |
| `07 80 6D 20 D8 48` | `00 -> B5` | high | readable discovery/status block |
| `07 80 45 20 D0 68` | synthetic CALL high/low pair | high | CALL event-path response |
| `07 80 45 30 D0 78` | CALL timing test, seen once | low | sibling CALL-response-family frame |
| `07 80 50 40 30 FD` | `00 -> 40` | medium-high | explicit readable/query family outside the main B/A/C map |
| `07 80 40 40 30 ED` | some heartbeat-only cadence runs | medium | transient heartbeat/context response family |
| `07 80 40 60 30 CD` | some heartbeat-only cadence runs | low-medium | transient heartbeat/context response family |
| `07 80 C0 40 30 6D` | some heartbeat-only cadence runs | medium | transient heartbeat/context response family |
| `07 80 E8 40 30 45` | context-sensitive `A0` path in some runs | medium | variant readable/query family, likely selector- or timing-sensitive |
| `07 80 FA 50 26 51` | host-shaped mirror of `07 80 E8 40 30 45`, seen once | low-medium | new structured response family on the `E8` branch; follow-up echo did not advance state |
| `07 C0 7A 50 A6 11` | exact echo of `07 80 E8 40 30 45`, seen once | low | new structured response family on the `E8` branch; not yet repeated |
| `07 80 7A 50 26 D1` | host-shaped `E8` branch, reproduced across HE8-HE11 group 1 | medium-high | reproducible downstream response family in the `E8` / `FA` / `7A` branch |
| `07 80 7A 28 D3 5C` | host-shaped `E9` neighbor, group 1 | low-medium | nearby distinct `7A`-family response; suggests an `E8`/`E9` selector neighborhood |
| `07 80 7B 50 26 D0` | host-shaped `EC` neighbor, group 1 | low-medium | new sibling family suggesting the `Ex` region is a selector-like strip |
| `07 C0 2F 95 09 2E` | exact echo of `07 80 7B 50 26 D0`, group 1 | low-medium | possible second-stage family on the `EC -> 7B` branch |
| `07 80 FB 50 26 50` | `EC` branch during later `2F` follow-up tests, group 1 | low-medium | sibling downstream family on the `EC` branch; reinforces selector/family behavior |

Current caution:

- No response family is yet confirmed as a true session-advance `ACK` or `OK`
  frame.
- The `68` / `6C` / `6D` families behave more like readable blocks than simple
  acknowledgements.
- The `45` family behaves like an event response, not a generic accept.
- The `40` / `C0` family currently looks state- or cadence-sensitive.
- Exact and host-shaped echoes of the `40` / `C0` / `50` heartbeat-adjacent
  families did not advance the session.
- The first echo experiments that produced genuinely new structured output were
  on the `E8` branch, not the `40` / `C0` branch.
- Directly echoing or host-mirroring `07 80 FA 50 26 51` did not produce a
  clean second-stage response; both follow-up tests instead repeated the
  `07 80 7A 50 26 D1` branch after the host-shaped `E8` step and then went
  back to heartbeat.
- Directly echoing or host-mirroring `07 80 7A 50 26 D1` also did not advance
  the exchange; the active trigger still appears to be the host-shaped
  `00 00 E8 40 30 C2` step.
- Nearby host-shaped neighbors are mixed rather than uniform:
  `E9` produced a distinct `7A`-family response, while `E7` and `EA` steered
  back toward known heartbeat-family transients.
- The `E9` sibling behaves like `E8` structurally:
  exact and host-shaped handling of `07 80 7A 28 D3 5C` did not advance the
  exchange, so the active control point still appears to be the `Ex` selector
  step rather than the downstream `7A` reply.
- Extending outward reinforced the selector-strip model:
  `E6` and `EB` fall into the `07 80 40 40 30 ED` transient family, while `EC`
  opens a new `07 80 7B 50 26 D0` sibling response.
- `EC` is now the first branch where the exact downstream echo looks more
  meaningful than the host-shaped mirror: exact `07 80 7B 50 26 D0` produced
  `07 C0 2F 95 09 2E`, while host-shaped `00 00 7B 50 26 57` did not.
- Follow-up `2F` mirror tests did not extend that into a stable chained
  exchange; instead, the `EC` selector response itself drifted into the sibling
  family `07 80 FB 50 26 50`.
- Additional `EC` timing/context tests suggest the leading `A0` is part of the
  branch context: with `A0` present, `EC` tends toward `07 80 7B 50 26 D0`; without
  `A0`, `EC` fell back to `07 80 C0 40 30 6D`.
- Exact and host-shaped handling of `07 80 FB 50 26 50` did not yield a stable
  next-stage response.
- Follow-up context tests suggest `A0` matters beyond `EC`:
  without `A0`, both `E8` and `E9` fell back to `07 80 40 40 30 ED` instead of
  opening their known `7A` branches.
- At the same time, `A0` is not sufficient to make every branch deterministic:
  a later `A0 -> E9` control repeat returned heartbeat only.
- A broader non-`A0` context ladder showed that `A0` is not the only opener:
  `90` opened `E8`, `E9`, and `EC`; `AF` opened `E9` and `EC`, and shifted
  `E8` into the sibling `07 80 FA 50 26 51` family; bare heartbeat opened `E8`
  and `E9` but not `EC`.
- Downstream-behavior follow-ups suggest opener choice changes the selector
  result more than the reply ladder:
  `90 -> E8` yielded sibling `07 80 7A 58 26 D9`, `90 -> EC` yielded sibling
  `07 80 FB 50 26 50`, but the downstream exact echoes still collapsed to
  heartbeat.
- Even when we answered the actually observed `90`-shifted family directly, the
  branch still collapsed to heartbeat instead of advancing to a stable next
  stage.
- A larger state/value ladder strongly suggests the hidden rule lives in those
  payload bytes too:
  with fixed command bytes, changing opener or selector `state/value` fields
  systematically shifted the returned families and payloads, especially on the
  `E8`, `E9`, and `EC` branches.
- An off-grid pair ladder weakened the strict "only known legal pairs work"
  model: mixed combinations like `00 30`, `20 30`, and `40 D0` still produced
  structured sibling responses, so the payload bytes now look more like a small
  parameter space than a tiny whitelist of accepted pair tokens.

## What We Know

- The link is RS-232-like, not TTL.
- The baud rate is `38400 8N1`.
- The six-byte frame shape and XOR checksum hypothesis explain observed frames.
- The RCP sends heartbeat continuously when not active.
- The RCP can parse host traffic and produce structured, checksum-valid
  responses.
- The B/A/C command regions expose the cleanest currently mapped one-shot
  readable response blocks.
- Commands outside B/A/C have also been tested; most were heartbeat-only,
  `CONNECT NOT ACT` parser-visible, CALL-path related, or context-sensitive
  rather than part of the stable mapped response table.
- The CALL event path can be synthesized by the host without pressing the
  physical button.
- The panel can remain visibly at `CONNECT NOT ACT` while still responding in
  protocol-specific ways.
- Heartbeat maintenance can hold the panel out of `CONNECT NOT ACT`, but that
  still does not create a fully active session.
- The heartbeat-induced `0x40` / `0xC0` families are real, but they usually act
  more like transient state/context responses than like camera-data streaming.
- The most promising new echo-derived lead is now the `E8` / `7A` / `FA`
  response branch.
- `E8` is not completely isolated: nearby `E9` can also open a `7A`-family
  response, but with different payload bytes.
- The emerging pattern is that `E8` and `E9` may be sibling selector-like host
  entries into related status/response families, while `E7` and `EA` bias back
  toward heartbeat-family transients.
- The wider `Ex` region now looks like a mixed selector surface:
  some values collapse into heartbeat-family transients, while others open
  related `7A` / `7B` downstream families.
- The `EC -> 7B` path is currently the strongest sign that some downstream
  exact echoes may matter, even though most earlier `7A`-family echoes did not.
- Overall, the evidence is getting stronger for selector-like host entries that
  open related response families, but weaker for a fully reproducible multi-turn
  "conversation" state.
- There appears to be a small family of context openers rather than a single
  magic gate byte; `EC` is stricter than `E8/E9`, and heartbeat alone was not
  enough to open it.
- At the moment, opener bytes look more like family/page selectors than like
  things that enable a stable multi-turn conversation after the first response.
- The protocol surface now looks parameterized rather than flat:
  command bytes pick broad regions, and `state/value` bytes appear to choose
  page, subtype, or class within those regions.
- Sustained "camera-info-like" fan-out streams have now also been tested:
  repeated discovery carousels, selector carousels, direct host-shaped family
  feeds, hybrid select-then-feed streams, and heartbeat-family base-status
  feeds.
- None of those sustained streams visibly activated the panel or cleared the
  broader inactive state.
- Two of those host-fed fan-out branches still produced new structured
  responses:
  host `00 00 7A 50 26 56` produced `07 80 2F 95 C9 AE`, and host
  `00 00 40 40 30 6A` produced `07 80 D0 50 26 7B`.
- Those are best treated as meaningful one-shot host-stimulated branches, not
  yet as proof of a stable live camera-info or session stream.
- Follow-up HE30 tests strengthened that further:
  these do not look like isolated one-off branches, but like two small
  parameterized family surfaces:
  - host `7A ...` -> RCP `2F ...`
  - host `40/50 ...` -> RCP `50 ...` / `D4 ...`
- Examples observed so far include:
  - `7A 50 26` -> `2F 95 C9`
  - `7A 58 26` -> `2F 65 F2`
  - `7A 50 3A` -> `2F 95 52`
  - `40 40 30` -> `50 78 26` or `50 50 26`
  - `50 40 30` -> `D4 50 26`
  - `40 60 30` -> `50 58 26`
- Exact and host-shaped answers to these second-stage families still did not
  produce a stable next turn, and cold-start direct tests fell back toward
  `40`/`C0` transient families instead.
- HE32 then tested the strongest remaining startup/handshake orders:
  discovery-first, stacked openers, beacon-first then page, and
  set-once-then-maintain models.
- None of those woke the panel, but they did expose additional startup-shaped
  families:
  - `A0 -> 90` and `AF -> 90` -> `07 80 64 40 30 C9`
  - repeated `90` -> `07 80 64 40 30 C9` or `07 80 E4 40 30 49`
  - `A0 -> AF` -> `07 80 0D 04 AB 7F`
  - repeated `AF` -> `07 80 0D 04 EB 3F`
- That makes `90` and `AF` look increasingly like startup beacons or mode/class
  selectors, but still not sufficient to activate the panel or make later page
  feeds become live.
- HE33 followed that clue directly by maintaining the startup-family classes
  themselves instead of switching immediately to `E8` / `EC` page traffic.
- That still did not wake the panel.
- The `90` side remained the cleaner startup surface:
  - repeated `90` or `A0 -> 90` reliably opened `07 80 64 40 30 C9`
  - host maintenance of `64 40 30` then fell back to heartbeat-compatible
    traffic
- The `AF` side remained sloppier:
  - `A0 -> AF` cleanly opened `07 80 0D 04 AB 7F`
  - repeated `AF` sometimes preferred `AB` rather than the earlier `EB` family
  - host maintenance of `0D 04 AB` or `0D 04 EB` still did not create a live
    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.
- A later targeted follow-up refined that further:
  - `cmd=0x01 @ 20 D0` repeatedly opened `07 80 40 24 DD 64`
  - `cmd=0x01 @ 00 80` repeatedly opened `07 80 40 20 D8 65`
  - `cmd=0x03 @ 20 D0` also opened a second distinct family:
    `07 80 20 12 97 78`
  - in both repeated-`cmd=0x01` tests, the panel reportedly stayed out of
    `CONNECT NOT ACT` until the script ended
- So the clearest difference between `20 D0` and `00 80` is currently the
  **family selected** by repeated `cmd=0x01`, while the timeout-holding effect
  may be a broader property of sustained repeated `cmd=0x01` traffic.
- A broader HE35 follow-up then showed that the early `0x00-0x03` command
  region under `20 D0` is itself structured:
  - `0x00` -> `07 80 40 48 3A EF`
  - `0x01` -> `07 80 40 24 DD 64`
  - `0x02` -> `07 80 20 12 87 68`
  - `0x03` -> `07 80 20 12 97 78`
- All of those still looked one-shot on the serial side, but the user reported
  the LCD stayed in the same clear/non-`CONNECT NOT ACT` state while the repeat
  scripts were active.
- That makes the low `0x00-0x03 @ 20 D0` area look less like a single magic
  wake frame and more like a small session-presence/status surface.
- A broader HE36 pass strengthened that further:
  - the active pattern extends at least through `0x1D @ 20 D0`
  - and it is mostly the odd commands that answer
  - examples:
    - `0x05` -> `07 80 41 24 DD 65`
    - `0x09` -> `07 80 42 24 DD 66`
    - `0x0D` -> `07 80 43 24 DD 67`
    - `0x11` -> `07 80 44 24 DD 60`
    - `0x15` -> `07 80 45 24 DD 61`
    - `0x19` -> `07 80 46 24 DD 62`
    - `0x1D` -> `07 80 47 24 DD 63`
    - interleaved siblings also appear in `0x10 0x09 D7 ..` and
      `0x20 0x12 .. ..` families
- So `20 D0` now looks like a broader low-command maintained surface, not just
  a four-command curiosity.
- A later ordered-cycle test pass (`HE37`) did **not** show strong evidence
  that one exact ascending page order wakes the panel.
- What it did suggest instead:
  - broad low-band scans are a bit fragile
  - narrower active subsets hold the panel clearer more reliably
  - both the `0x40`-leaning subset and the `0x20/0x10`-leaning subset can act
    like maintained background traffic
- So the current "1990s Sony" model is less "one magic page order" and more:
  - startup/beacon pages
  - then a small recurring maintained scan set
  - then additional camera-state detail pages we still have not identified
- A later no-pause HE38 pass broadened the same idea:
  - `0x21 @ 20 D0` -> `07 80 48 24 DD 6C`
  - `0x41-0x43 @ 20 D0` -> `07 80 50 24 DD 74`
  - while the baseline control in the same `0x20-0x3F` region stayed on the
    older `20 D8` style (`07 80 4A 20 D8 6F`)
- That suggests `20 D0` is not just shifting one command or one small pocket;
  it may be selecting a broader `.. 24 DD ..` maintained-background surface
  across multiple command bands.
- The paused HE38 runs strengthened that structure further:
  - `0x20-0x3F @ 20 D0` maps cleanly through `48/49/4A/.../4F 24 DD`
  - `0x20-0x3F @ 00 80` maps the same area through `4A/4B/4C/.../4F 20 D8`
  - `0x20-0x3F @ 40 30` maps it again through `48/49/4A/.../4F 28 D3`
- So the best current model is a parallel set of response surfaces selected in
  part by the host payload pair, with the remaining question being which surface
  behaves like the true maintained background layer for an active panel.
- A tighter HE39 pass on the `0x50`-band showed:
  - `0x41 @ 20 D0` -> `07 80 50 24 DD 74`
  - `0x45 @ 20 D0` -> `07 80 51 24 DD 75`
  - `0x49 @ 20 D0` -> `07 80 52 24 DD 76`
  - all of those can keep the panel in the clear / semi-awake state while the
    script is active
  - but serially they still behave as one-shot branch openings followed by
    heartbeat-compatible maintenance, not as a richer multi-turn wake sequence
- 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.

## What We Do Not Know

- The complete PT2 session startup handshake.
- The frame or cadence that moves the RCP into an active state.
- The meaning of most response fields.
- Whether `07 80` is always the RCP-origin response prefix.
- Whether host frames always use `00 00`, or if other prefixes are needed for
  active mode.
- 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 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

Near-term practical strategy:

1. Treat PT2 as the target personality.
2. Keep using RS-232 at `38400 8N1`.
3. Use `00 -> Bx/Ax/Cx` style queries to map readable status blocks.
4. Use the cold CALL high/low pair as a known host stimulus to verify the RCP is
   still parsing traffic.
5. Search for the missing session-advance or keepalive command after discovery,
   not inside the CALL path.
6. If possible, capture a working PT2 CCU/RCP exchange; that would collapse a
   lot of the search space.

Most promising unknown:

- A host-side session cadence or identity/status frame after discovery that
  makes `CONNECT NOT ACT` become active.