run 13

docs/pt2-protocol-summary.md

@@ -0,0 +1,235 @@
+# 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.
+
+## 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 one-shot readable response blocks.
+- 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.