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