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:

prefix1 prefix2 command state value checksum

Current checksum hypothesis:

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:

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:

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:

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:

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:

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.

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.

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.