387 lines
16 KiB
Markdown
387 lines
16 KiB
Markdown
# 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.
|
|
|
|
## 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.
|
|
|
|
## 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.
|