aiden/Sony-rcp
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
1d66f3baaf5751c2b6b29c5a33d31e0d1956eae7
Sony-rcp/docs/pt2-protocol-summary.md
Aiden 1d66f3baaf run 2
2026-05-14 01:19:50 +10:00

24 KiB
Raw Blame History

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
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.
Reference in New Issue View Git Blame Copy Permalink