Sony-rcp/docs/discovery-notes.md

Discovery Notes

This file records hands-on observations separately from manual-derived facts. Treat these as bench notes: useful and current, but still worth rechecking with photos, continuity tests, and instrument captures.

2026-05-13 - RCP-TX7 10-Pin Power and Cable

Observed on the RCP-TX7 10-pin remote connector/cable during restoration work:

• Pin 9 confirmed as ground / DC return.
• Pin 10 confirmed as power input.
• Cable color for pin 9 / ground: brown.
• Cable color for pin 10 / +12 V power: brown-white.
• Cable colors for pins 1-8 have been continuity-mapped; see the working cable map below.
• Yellow and yellow-white conductors are present in the cable but did not map to connector pins during continuity testing.
• Multimeter reading from pin 9 ground to pin 4 serial data: about -9 V.
• Multimeter reading from pin 9 ground to pin 7 serial data: about +0.037 V.
• Pins 4 and 7 were the only serial-related combinations that produced a meaningful multimeter result during this check.
• With power present on pins 9 and 10, the panel shows a green PANEL ACTIVE light.
• The inside of the 10-pin cable contains 12 wires total.
• Three of those wire groups are twisted pairs.

Immediate implications:

• The bench result agrees with the RCP-TX7 and CCU-TX7 manual pinout for pins 9 and 10.
• The 12-conductor cable construction suggests not every conductor maps one-to-one to the 10 connector pins; shielding/drain, duplicated grounds, or paired signal returns may be present.
• The three twisted pairs are likely important candidates for serial data, composite video, and/or power/ground pairing, but this should be confirmed by continuity testing rather than color or twist assumptions.
• Pin 4 measuring around -9 V relative to pin 9 strongly suggests true RS-232 level idle on at least the RCP-to-CCU/camera data line.
• Pin 7 near 0 V may be inactive/floating until a CCU or camera drives the return data line.

Working Cable Map

This table combines the manual-derived pin purpose with hands-on color mapping. Rows marked confirmed have been checked on the current cable/panel under test.

Pin	Purpose	Cable color	Status	Notes
1	Spare / unused	red	confirmed	No function shown in service manual.
2	VBS / composite video X	black	confirmed	1.0 Vp-p composite video input to RCP.
3	VBS / composite video ground	green	confirmed	Video reference/ground.
4	Serial data, RCP to CCU/camera	orange	confirmed	RS-232C-based data direction.
5	Serial/data ground	blue	confirmed	One of two serial/data grounds.
6	Serial/data ground	grey	confirmed	One of two serial/data grounds.
7	Serial data, CCU/camera to RCP	purple	confirmed	RS-232C-based data direction.
8	Spare / unused	purple-white	confirmed	No function shown in service manual.
9	DC return / ground	brown	confirmed	Confirmed as ground on current cable.
10	+12 V remote power input	brown-white	confirmed	Confirmed as power input on current cable.

Unmapped Cable Conductors

The cable contains two additional conductors that did not show continuity to the 10 connector pins during the current test:

Conductor color	Current status	Notes
yellow	unmapped	May be shield/drain-related, spare, broken, or connected only at one end.
yellow-white	unmapped	May be shield/drain-related, spare, broken, or connected only at one end.

Recheck these against connector shells, shield braid/drain, cable strain relief hardware, and both ends of the cable if accessible.

Suggested next observations to capture:

1. Connector orientation photo showing pin numbering reference.
2. Wire color list, including which colors form each twisted pair.
3. Confirm whether yellow and yellow-white connect to shield, shell, or one end only.
4. Resistance between pins 5, 6, and 9 with the cable disconnected.
5. Scope idle voltage and activity on pins 4 and 7 relative to pins 5/6 and pin 9 while pressing panel controls and, later, while connected to a CCU or camera.

Serial Capture Setup

Initial USB serial adapter wiring for passive listening:

Adapter terminal	RCP-TX7 cable pin	Cable color	Purpose
GND	9	brown	Shared reference / DC return
RXD	4	orange	Listen to RCP-to-CCU/camera serial data

Do not connect adapter TXD during the first capture pass. Pin 4 measured about -9 V relative to pin 9, so use the adapter's RS-232 side, not TTL UART mode.

Capture helper:

python -m pip install pyserial
python scripts/serial_sniff.py --list
python scripts/serial_sniff.py --port COM3 --baud 38400 --ascii
python scripts/serial_sniff.py --port COM3 --baud 38400 --frame-size 6 --log captures/rcp-pin4.txt

Replace COM3 with the adapter port shown by --list or Windows Device Manager. While the script is running, press simple RCP controls and watch for new hex bytes.

2026-05-13 Initial Pin 4 Capture

With the adapter in RS-232 mode, adapter RXD connected to RCP pin 4, and adapter GND connected to pin 9, the stream produced repeating 6-byte patterns:

00 00 00 00 80 DA
00 00 07 80 00 DD

Observed behavior:

• Frames repeat roughly every 200 ms during the sample.
• The stream sometimes appeared split as 00 followed by five bytes, which is likely a read-timeout/chunking artifact rather than a protocol feature.
• Button presses did not obviously correlate with a visible byte change in the first capture.

Current interpretation:

• This looks like a regular RCP-origin heartbeat/status transmission on pin 4, not random noise.
• Because only pin 4 is connected, this may be the panel repeatedly trying to announce itself or poll a missing CCU/camera.
• Pin 7 measured near 0 V and is probably quiet until a CCU/camera drives the return channel.

Next capture passes:

1. Use --frame-size 6 to avoid misleading 1 + 5 packet splits.
2. Capture a quiet baseline for 30 seconds.
3. Capture separate files while pressing one control repeatedly, naming the action in the filename.
4. Later, capture pin 7 when connected to a real CCU/camera or a controlled test transmitter.

2026-05-13 Baseline vs CAM POWER Capture

Capture files:

• captures/rcp-pin4-baseline.txt
• captures/rcp-pin4-cam-power.txt
• captures/rcp-pin4-call.txt

Frame counts from the available logs:

Capture	Frame	Count	Current label
baseline	00 00 00 00 80 DA	67	idle heartbeat
CAM POWER	00 00 00 00 80 DA	23	idle heartbeat
CAM POWER	00 00 07 80 00 DD	4	CAM POWER candidate
CALL	00 00 00 00 80 DA	17	idle heartbeat
CALL	00 00 15 80 00 CF	4	CALL candidate, state/high bit set
CALL	00 00 15 00 00 4F	4	CALL candidate, state/high bit clear

Current interpretation:

• The baseline capture contains only 00 00 00 00 80 DA.
• Pressing CAM POWER introduces 00 00 07 80 00 DD.
• Pressing CALL introduces 00 00 15 80 00 CF and 00 00 15 00 00 4F.
• Other tested buttons did not obviously produce unique frames while the panel was not connected to a CCU/camera.
• CAM POWER and CALL may be among the few controls the panel transmits even without a completed host/CCU session.
• The CALL frames differ by byte 4 (80 vs 00) and final byte (CF vs 4F), suggesting a state bit plus checksum or complement-style trailing byte.
• Current checksum hypothesis: byte 6 is XOR checksum with seed 0x5A over the first five bytes. Examples:
  • 5A xor 00 xor 00 xor 00 xor 00 xor 80 = DA
  • 5A xor 00 xor 00 xor 07 xor 80 xor 00 = DD
  • 5A xor 00 xor 00 xor 15 xor 80 xor 00 = CF
  • 5A xor 00 xor 00 xor 15 xor 00 xor 00 = 4F

Helper for future captures:

python scripts/analyze_capture.py captures/rcp-pin4-baseline.txt captures/rcp-pin4-cam-power.txt captures/rcp-pin4-call.txt

Host Response Experiments

The RCP currently appears to be in an offline heartbeat state. With no CCU/camera response present, only CAM POWER and CALL have been observed to send unique frames beyond the heartbeat. The next protocol step is to learn what the RCP expects on pin 7 (CCU/camera -> RCP).

Important wiring for host-response tests:

Adapter terminal	RCP-TX7 cable pin	Cable color	Purpose
GND	9	brown	Shared reference / DC return
TXD	7	purple	Candidate host-to-RCP transmit line

Suggested safety precautions:

• Use the adapter's RS-232 side, not TTL UART.
• Keep adapter RXD on pin 4 if possible so the RCP output is still logged.
• Add a series resistor, for example 1 k to 4.7 k, between adapter TXD and pin 7 for early experiments.
• Send one candidate frame at a time or repeat at a slow cadence. Avoid brute forcing unknown byte ranges.
• Watch for changes in heartbeat, LCD state, panel lock state, or new frames on pin 4.

Frame sender:

python scripts/serial_send_frame.py --port COM3 --dry-run
python scripts/serial_send_frame.py --port COM3 --frame "00 00 00 00 80 DA" --repeat 5 --interval 0.2

On Windows, a COM port is usually exclusive, so the sniffer and sender cannot open the same adapter at the same time. Use the combined probe script when RXD is connected to pin 4 and TXD is connected to pin 7:

python scripts/serial_probe_response.py --port COM3 --tx-frame "00 00 00 00 80 DA" --repeat 5 --interval 0.2 --log captures/rcp-response-test.txt

This listens first, sends the candidate response from the same serial session, then keeps listening for changes on pin 4.

Candidate first response:

• 00 00 00 00 80 DA - mirror the observed heartbeat as a possible no-op/ack.

If mirroring the heartbeat changes nothing, the next low-risk approach is to capture a real CCU/camera response rather than guessing. If no host is available, try only checksum-valid, documented-frame-shape candidates and record every attempt in a separate capture log.

2026-05-13 Heartbeat Mirror Response Result

Experiment:

• Adapter TXD connected to RCP pin 7.
• Sent 00 00 00 00 80 DA on the host-to-RCP line as a mirrored heartbeat / possible no-op acknowledgement.
• Capture file: captures/rcp-response-heartbeat-mirror.txt.

Observed result:

• The RCP screen changed to CONNECT: NOT ACT.
• During this capture, pin 4 still transmitted only 00 00 00 00 80 DA.
• Frame count: 59 received heartbeat frames, 10 transmitted mirrored heartbeat frames.
• Pin 4 heartbeat timing became more frequent during the response window, then returned to the slower baseline cadence afterward.

Current interpretation:

• The RCP is detecting return-channel traffic on pin 7.
• Mirroring the heartbeat is enough to move the panel out of the simple offline state, but it does not complete active host/CCU negotiation.
• NOT ACT likely means connected/not active, connected/not activated, or a similar state where the link is electrically/protocol-visible but no valid control session has been established.
• The RCP did not emit a new command/status frame on pin 4 in response to the mirrored heartbeat, so the next handshake step is probably not simply an echo of its heartbeat.

Additional checksum-valid response tests:

Capture	TX frame	RX result on pin 4	Screen result
captures/rcp-response-zero-state.txt	00 00 00 00 00 5A	heartbeat only	CONNECT: NOT ACT
captures/rcp-response-state-byte4.txt	00 00 00 80 00 DA	heartbeat only	CONNECT: NOT ACT
captures/rcp-response-invalid-checksum.txt	00 00 00 00 80 00	heartbeat only	CONNECT: NOT ACT
TXD connected, no transmitted bytes	RS-232 idle only	heartbeat only	no CONNECT: NOT ACT
Single-byte test	00	heartbeat only	no CONNECT: NOT ACT
Single-byte test	FF	heartbeat only	no CONNECT: NOT ACT
Short-frame test	00 00 00	heartbeat only	no CONNECT: NOT ACT
Frame-length test	00 00 00 00	heartbeat only	no CONNECT: NOT ACT
Frame-length test	00 00 00 00 80	heartbeat only	no CONNECT: NOT ACT
Frame-length test	00 00 00 00 80 DA 00	heartbeat only	CONNECT: NOT ACT

Updated interpretation:

• CONNECT: NOT ACT is probably a link-present state, not proof of a correct CCU handshake.
• The RCP reacts to several checksum-valid 6-byte frames on pin 7, but continues sending only the pin 4 heartbeat.
• An intentionally invalid checksum frame also produced CONNECT: NOT ACT, so that display state does not prove checksum acceptance.
• The response needed to enter an active control session likely needs a specific status/identity/activation frame, not just a valid no-op frame shape.
• TXD connected at idle without transmitted bytes did not produce CONNECT: NOT ACT, so the display state appears to require received byte activity on pin 7, not merely a driven RS-232 idle level.
• Single-byte and three-byte transmissions did not produce CONNECT: NOT ACT, so the RCP is likely recognizing a minimum frame length or parser shape rather than arbitrary serial bytes.
• Four-byte and five-byte transmissions did not produce CONNECT: NOT ACT, but a seven-byte transmission beginning with the known six-byte heartbeat did. This suggests the first six bytes are enough to trigger the parser/link state, and the seventh byte may be ignored, buffered for a later frame, or treated as extra data after the recognized packet.
• None of the tested host frames have caused the RCP to emit anything on pin 4 except the heartbeat.

Command-field response tests, using frame shape 00 00 CMD 00 80 CHECKSUM:

Capture	TX frame	Checksum	Screen result	Notes
captures/rcp-response-cmd01.txt	00 00 01 00 80 DB	valid	CONNECT: NOT ACT	6-byte command-shaped frame accepted enough to change display.
captures/rcp-response-cmd02.txt	00 00 02 00 80 DB	invalid	CONNECT: NOT ACT	Bad checksum still changed display.
captures/rcp-response-cmd02.txt	00 00 02 00 80 D8	valid	CONNECT: NOT ACT	Valid checksum also changed display.
captures/rcp-response-cmd03.txt	00 00 03 00 80 D9	valid	CONNECT: NOT ACT	6-byte command-shaped frame accepted enough to change display.
captures/rcp-response-cmd04.txt	00 00 7F 00 80 A5	valid	no screen change	First observed checksum-valid 6-byte frame that does not trigger CONNECT: NOT ACT.
captures/rcp-response-cmd05.txt	00 00 80 00 80 5A	valid	CONNECT: NOT ACT	6-byte command-shaped frame accepted enough to change display.

Implications from command-field tests:

• Screen change is not simply based on frame length or checksum validity.
• The command/status byte matters: 0x7F appears ignored or treated as non-link-establishing, despite a valid checksum.
• Tested commands 0x00, 0x01, 0x02, 0x03, and 0x80 can trigger CONNECT: NOT ACT; 0x7F did not.
• The RCP operating manual notes that CAM POWER, MASTER/SLAVE, and some monitor functions are available only when connected to a CCU, so active state may depend on CCU identity/status bits.

Next low-risk response experiments:

1. Repeat the same test with logging enabled so the pin 4 output before, during, and after CONNECT: NOT ACT is captured.
2. Try sending the mirrored heartbeat continuously at a cadence close to the RCP heartbeat, for example every 0.6 seconds, and watch whether the display state changes.
3. Probe semantic fields within the six-byte frame shape, changing one byte at a time and logging both screen state and pin 4 output. Prioritize small command values and avoid broad brute-force sweeps.
4. Prefer capturing a real CCU/camera pin 7 response before broad guessing.

Command Sweep Helper

A cautious command-byte sweep helper is available at scripts/serial_sweep_commands.py. It sends only checksum-valid six-byte frames using the current frame/checksum hypothesis and marks any RCP output that is not the known heartbeat.

Recommended first sweep:

python scripts/serial_sweep_commands.py --port COM5 --start 0x00 --end 0x20 --after-each 1.0 --log captures/rcp-sweep-cmd-00-20.txt

Optional dry run:

python scripts/serial_sweep_commands.py --port COM5 --start 0x00 --end 0x20 --dry-run

Use small ranges and keep watching the RCP screen while the sweep runs. The log captures TX/RX bytes, but it cannot record screen messages unless they are noted manually afterward.

The 0x00-0x20 sweep produced CONNECT: NOT ACT roughly halfway through the run, but the exact command was not recorded in the log. Rerun a narrower range with manual screen prompts:

python scripts/serial_sweep_commands.py --port COM5 --start 0x0C --end 0x14 --after-each 1.2 --prompt-screen --log captures/rcp-sweep-cmd-0c-14-screen.txt

At each prompt, press Enter for no screen change, type CONNECT: NOT ACT when that appears, or type q to stop.

Prompted sweep result:

• Capture: captures/rcp-sweep-cmd-0c-14-screen.txt.
• The RCP was reset after each screen trigger to clear its state, so recorded triggers should be treated as independent fresh observations.
• First recorded screen marker: after command 0x0C, frame 00 00 0C 00 80 D6, screen CONNECT: NOT ACT.
• Later manual screen markers were recorded after 0x0D, 0x10, 0x11, 0x12, 0x13, and 0x14.
• No manual screen markers were recorded after 0x0E or 0x0F.
• Pin 4 output remained the heartbeat 00 00 00 00 80 DA throughout.

Interpretation:

• Commands 0x0C, 0x0D, 0x10, 0x11, 0x12, 0x13, and 0x14 have independent evidence of triggering CONNECT: NOT ACT in this sweep.
• Commands 0x0E and 0x0F did not have a screen marker recorded in this sweep and are current non-trigger candidates.
• Because pin 4 stayed heartbeat-only, this state change is visible on the LCD but does not yet produce a new RCP-to-host serial response.

Second prompted sweep result:

• Capture: captures/rcp-sweep-cmd-15-30-screen.txt.
• The log includes one partial/restarted pass at the beginning, then a fuller prompted sweep through 0x30.
• Pin 4 output remained the heartbeat 00 00 00 00 80 DA throughout.

Commands with recorded CONNECT: NOT ACT screen markers:

Command	TX frame
0x15	00 00 15 00 80 CF
0x16	00 00 16 00 80 CC
0x17	00 00 17 00 80 CD
0x18	00 00 18 00 80 C2
0x19	00 00 19 00 80 C3
0x1A	00 00 1A 00 80 C0
0x1B	00 00 1B 00 80 C1
0x1C	00 00 1C 00 80 C6
0x1D	00 00 1D 00 80 C7
0x28	00 00 28 00 80 F2
0x29	00 00 29 00 80 F3
0x2C	00 00 2C 00 80 F6
0x2D	00 00 2D 00 80 F7
0x30	00 00 30 00 80 EA

Commands with no recorded screen marker in this sweep:

0x1E 0x1F 0x20 0x21 0x22 0x23 0x24 0x25
0x26 0x27 0x2A 0x2B 0x2E 0x2F

Emerging pattern:

• Some command byte ranges trigger CONNECT: NOT ACT while nearby checksum-valid commands do not.
• Triggering still does not make the RCP transmit anything except the heartbeat.
• CONNECT: NOT ACT appears to be a parser-recognized but not session-active state. It may indicate the RCP recognizes the command class as CCU-like, but the remaining status/identity/activation fields are wrong or incomplete.