# 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.

## 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.
