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