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.

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.