Files
Sony-rcp/docs/pt2-protocol-summary.md
2026-05-13 20:24:40 +10:00

379 lines
16 KiB
Markdown

# 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.
## 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.
## 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 video/composite pins carry any status needed for full operation.
## 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.