# 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:

```powershell
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:

```text
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:

```powershell
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:

```powershell
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:

```powershell
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:

```powershell
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:

```powershell
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:

```powershell
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:

```text
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.