aiden/Sony-rcp
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

run 3 and 4 and 5

Browse Source
This commit is contained in:
Aiden
2026-05-13 16:15:22 +10:00
parent 659ad33c48
commit 7f0ec19798
12 changed files with 2102 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

340
docs/discovery-notes.md
View File

@@ -2391,3 +2391,343 @@ Next useful tests:
`B8 -> B9`, `BC -> BD`, and `BD -> BE`.
3. Sweep the `D0-DF` region with the same primer-pair method to see whether the
structured discovery table continues after `CF`.
## Unlatch / State-Advance Sweep
Goal: intentionally put the RCP into the known one-response latched state, send
a wide set of possible reset/ack/state-advance commands, then verify whether a
known query can respond again without a power cycle.
Use `scripts/serial_unlatch_sweep.py`. For each candidate it performs:
```text
latch primer -> latch query -> candidate unlatch command -> verify primer -> verify query
```
Default latch and verify sequence:
```text
00 -> B5 produces known response: 07 80 6D 20 D8 48
candidate possible unlatch / state advance command
00 -> B5 verify whether the known response can happen again
```
Interpretation:
- If the verify query returns heartbeat only, the candidate did not unlatch the
one-response state.
- If the verify query returns `07 80 6D 20 D8 48` again, the candidate likely
cleared or advanced the latch.
- If the candidate itself changes the LCD or produces a new serial response,
log it as a possible state-advance command even if the verify query does not
respond.
First wide assortment, focused on known response command families, boundaries,
and current no-response gaps:
```powershell
python scripts/serial_unlatch_sweep.py --port COM5 --candidates "0x00 0x01 0x03 0x07 0x0A 0x0C 0x0D 0x0E 0x0F 0x10 0x1A 0x1B 0x1C 0x20 0x30 0x36 0x38 0x39 0x40 0x4F 0x50 0x5B 0x68 0x6C 0x6D 0x6E 0x6F 0x70 0x7F 0x80 0x8F 0x90 0x9F 0xA0 0xAF 0xB0 0xB5 0xB8 0xBC 0xBE 0xBF 0xC0 0xCF 0xD0 0xDF 0xE0 0xEF 0xF0 0xFF" --expected-verify-response "07 80 6D 20 D8 48" --prompt-power-cycle --prompt-screen --log captures/rcp-unlatch-wide-after-b5.txt
```
Power-cycle before each prompt. For the screen prompt:
- Press Enter if the screen stayed the same.
- Type the exact screen text if it changes.
- Type `q` to stop.
If this finds no verify responses, try the same idea after a different latch
query page:
```powershell
python scripts/serial_unlatch_sweep.py --port COM5 --latch-query-command 0xA0 --verify-query-command 0xA0 --candidates "0x00 0x01 0x0F 0x10 0x1A 0x1B 0x40 0x4F 0x68 0x6C 0x80 0x8F 0x90 0x9F 0xA0 0xB0 0xB8 0xBC 0xC0 0xCF 0xE0 0xEF 0xFF" --expected-verify-response "07 80 68 40 30 C5" --prompt-power-cycle --prompt-screen --log captures/rcp-unlatch-wide-after-a0.txt
```
For a fast dry run without touching the serial port:
```powershell
python scripts/serial_unlatch_sweep.py --port COM5 --candidates "0x00 0x01 0x90" --dry-run
```
### 2026-05-13 Unlatch Sweep Result
Captures:
- `captures/rcp-unlatch-wide-after-b5.txt`
- `captures/rcp-unlatch-wide-after-a0.txt`
User observation:
- No visible RCP state change was seen during the tests.
- The only screen note recorded in the logs was `CONNECT NOT ACT` after
candidate `0x00`, which matches the already-known non-active connected state.
Serial result:
| Latch/verify query | Candidates tested | Expected verify response | Result |
| --- | ---: | --- | --- |
| `B5` | 49 | `07 80 6D 20 D8 48` | no confirmed unlatch |
| `A0` | 23 | `07 80 68 40 30 C5` | no confirmed unlatch |
Notes:
- Candidate `0xBF` in the `B5` unlatch sweep produced a verify-query anomaly,
but the raw bytes were `00 00 00 00 00 00 80 DA`, not the expected
`07 80 6D 20 D8 48`. Treat this as a heartbeat/chunking/classifier artifact,
not a successful unlatch.
- No candidate-stage serial response clearly indicated a state advance.
- The broad command-byte assortment did not find a reset/ack/unlatch command in
the tested six-byte frame shape.
Tooling update:
- `scripts/serial_unlatch_sweep.py` now accepts `--expected-verify-response`.
- Future unlatch sweeps should use this option so only the desired repeated
query response counts as a hit.
## PT2/PT7 Compatibility Clue
Manual-derived note from a newer Sony RCP:
- A newer Sony RCP has a mode switch with `PT2` and `PT7` positions.
- `PT2` is documented for controlling the same camera line that the RCP-TX7 is
associated with.
Working implication:
- The TX7 may be a fixed/PT2-era protocol personality rather than a generic
Sony RCP protocol endpoint.
- If the CCU/RCP protocol family later split into PT2 and PT7 modes, then our
current frame shape may be electrically correct but still missing a
personality/mode/session assumption.
- The command bytes that look like "page selectors" may be table reads within
the PT2 personality rather than an activation handshake.
Next direction from this clue:
1. Treat PT2 compatibility as the default target for TX7 restoration tests.
2. Search newer-RCP manuals for whether PT2/PT7 is only a physical switch or
whether either mode has visible initialization, connect, or model-detect
behavior.
3. Prefer tests that emulate a CCU already speaking the TX7/PT2 personality,
rather than trying PT7-style/high-range activation guesses.
## Button Behavior While Latched
Open questions:
1. Does the one-response latched state suppress the RCP-origin button frames
that are known to appear while disconnected?
2. If the RCP sends `CAM POWER`, does an immediate host-side response using the
same or a similar command shape change the RCP state?
Known RCP-origin button frames:
| Button/action | RCP frame |
| --- | --- |
| Idle heartbeat | `00 00 00 00 80 DA` |
| `CAM POWER` | `00 00 07 80 00 DD` |
| `CALL` on/state high | `00 00 15 80 00 CF` |
| `CALL` off/state low | `00 00 15 00 00 4F` |
Use `scripts/serial_button_response_test.py` for these tests. It keeps RX and
TX in the same serial session, so it works around Windows COM-port exclusivity.
### Test BTN1: Offline Button Control
Purpose: establish a fresh control capture where the RCP is not intentionally
latched. During the listen window, press `CAM POWER` a few times and press/release
`CALL`.
```powershell
python scripts/serial_button_response_test.py --port COM5 --duration 30 --prompt --log captures/rcp-buttons-offline-control.txt
```
Expected:
- `CAM POWER` should produce `00 00 07 80 00 DD`.
- `CALL` should produce one or both `00 00 15 80 00 CF` and
`00 00 15 00 00 4F`.
### Test BTN2: Latched Button Emission
Purpose: put the RCP into the known `00 -> B5` latched state, then see whether
`CAM POWER` and `CALL` still produce RCP-origin frames. During the listen
window, press the same buttons as BTN1.
```powershell
python scripts/serial_button_response_test.py --port COM5 --latch --latch-query-command 0xB5 --duration 30 --prompt --log captures/rcp-buttons-latched-after-b5.txt
```
Interpretation:
- If `CAM POWER`/`CALL` frames still appear, the latch suppresses selected query
responses but does not suppress basic panel-origin button events.
- If button frames disappear, the latch may be closer to a protocol/session
hold state that blocks some panel event transmission.
### Test BTN3: Respond to `CAM POWER` With Exact Echo
Purpose: when the RCP sends the `CAM POWER` frame, immediately send the same
six-byte frame back on the host-to-RCP line. Watch the screen for any visible
change.
```powershell
python scripts/serial_button_response_test.py --port COM5 --duration 30 --prompt --respond-to-cam-power --respond-once --response-frame "00 00 07 80 00 DD" --log captures/rcp-buttons-cam-power-exact-echo.txt
```
At the prompt, press `CAM POWER` once. If the screen changes, note the exact
display text after the run.
### Test BTN4: Respond to `CAM POWER` With Host-Shaped Variant
Purpose: test a related command-shaped host frame where command `0x07` is kept
but the `0x80` bit is in the value field, matching the host-query shape used in
many discovery tests.
```powershell
python scripts/serial_button_response_test.py --port COM5 --duration 30 --prompt --respond-to-cam-power --respond-once --response-frame "00 00 07 00 80 DD" --log captures/rcp-buttons-cam-power-host-shaped.txt
```
Interpretation:
- If exact echo changes nothing but the host-shaped variant changes the screen
or serial stream, the RCP may expect host responses in the same command class
but with host-side state/value layout.
- If neither changes anything, `CAM POWER` may be an outbound event requiring a
larger CCU state/session response rather than a direct ACK.
Optional latched version of BTN3:
```powershell
python scripts/serial_button_response_test.py --port COM5 --latch --latch-query-command 0xB5 --duration 30 --prompt --respond-to-cam-power --respond-once --response-frame "00 00 07 80 00 DD" --log captures/rcp-buttons-latched-cam-power-exact-echo.txt
```
### 2026-05-13 Button Test Result
Captures:
- `captures/rcp-buttons-offline-control.txt`
- `captures/rcp-buttons-latched-after-b5.txt`
- `captures/rcp-buttons-cam-power-exact-echo.txt`
- `captures/rcp-buttons-cam-power-host-shaped.txt`
Offline control:
- `CALL` produced `00 00 15 80 00 CF` and `00 00 15 00 00 4F`.
- `CAM POWER` produced `00 00 07 80 00 DD`.
- This matches the original offline button observations.
Latched after `00 -> B5`:
- The latch setup produced the known `B5` response
`07 80 6D 20 D8 48`.
- While in this state, `CALL` still produced both known call frames.
- While in this state, `CAM POWER` still produced `00 00 07 80 00 DD`.
Interpretation:
- The one-response latch suppresses additional selected-query responses, but it
does not suppress basic RCP-origin button/event frames.
- The panel is still actively reporting front-panel events after the discovery
response/latch state.
`CAM POWER` response tests:
| Test | Host response sent after `CAM POWER` | Screen result | Serial result |
| --- | --- | --- | --- |
| BTN3 exact echo | `00 00 07 80 00 DD` | `CONNECT NOT ACT` | heartbeat/button-event only |
| BTN4 host-shaped | `00 00 07 00 80 DD` | `CONNECT NOT ACT` | heartbeat only after response |
Interpretation:
- Both `CAM POWER` response shapes are recognized enough to produce the familiar
`CONNECT NOT ACT` display state.
- Neither response advanced the RCP into an active state or caused a new serial
status stream.
- `CAM POWER` is likely an outbound event that requires broader CCU/session
context, not a simple one-frame ACK.
Next useful button-side tests:
1. Repeat BTN3/BTN4 while already latched after `00 -> B5`; this checks whether
the same `CAM POWER` response has different meaning after the RCP has already
returned a discovery block.
2. Try responding to `CALL` with exact echo and host-shaped command `0x15`
variants, since earlier `0x15` matrix tests changed the screen but did not
activate the panel.
3. If a future session/keepalive candidate is found, rerun BTN1/BTN2 to see
whether more front-panel controls begin emitting serial events in an active
context.
### CALL Echo / Response Tests
Goal: test whether the RCP treats `CALL` differently from `CAM POWER` when the
host immediately echoes or acknowledges the outbound button event.
Known RCP-origin `CALL` frames:
```text
CALL high/on: 00 00 15 80 00 CF
CALL low/off: 00 00 15 00 00 4F
```
Test BTN5: exact echo of both known `CALL` shapes.
```powershell
python scripts/serial_button_response_test.py --port COM5 --duration 30 --prompt --respond-to-call --respond-once --response-frame "00 00 15 80 00 CF" --response-frame "00 00 15 00 00 4F" --log captures/rcp-buttons-call-exact-echo.txt
```
Test BTN6: host-shaped `CALL` response, with command `0x15` and value `0x80`.
```powershell
python scripts/serial_button_response_test.py --port COM5 --duration 30 --prompt --respond-to-call --respond-once --response-frame "00 00 15 00 80 CF" --log captures/rcp-buttons-call-host-shaped.txt
```
Test BTN7: host-shaped `CALL` response after the known `00 -> B5` latch.
```powershell
python scripts/serial_button_response_test.py --port COM5 --latch --latch-query-command 0xB5 --duration 30 --prompt --respond-to-call --respond-once --response-frame "00 00 15 00 80 CF" --log captures/rcp-buttons-latched-call-host-shaped.txt
```
During each test, press and release `CALL` once or twice. Record any screen
change after the run.
### 2026-05-13 CALL Echo Result
Captures:
- `captures/rcp-buttons-call-exact-echo.txt`
- `captures/rcp-buttons-call-host-shaped.txt`
- `captures/rcp-buttons-latched-call-host-shaped.txt`
User observation:
- All three CALL response tests ended with the RCP screen at `CONNECT NOT ACT`.
Serial result:
| Test | Host response after `CALL` | Serial result |
| --- | --- | --- |
| BTN5 exact echo | `00 00 15 80 00 CF` then `00 00 15 00 00 4F` | RCP sent `07 80 45 20 D0 68` once, then returned to heartbeat/CALL events |
| BTN6 host-shaped | `00 00 15 00 80 CF` | heartbeat/CALL events only |
| BTN7 latched host-shaped | `00 00 15 00 80 CF` after latch setup | heartbeat/CALL events only |
Interpretation:
- Exact CALL echo is more interesting than CAM POWER echo: it produced a new
checksum-valid RCP response frame, `07 80 45 20 D0 68`.
- The new frame did not visibly activate the RCP; the panel still ended at
`CONNECT NOT ACT`.
- The host-shaped `CALL` response did not reproduce the new frame, either
offline or after the `B5` latch setup.
- This suggests the RCP has at least one event-response path for CALL exact
echo, but that response is still not the missing active-session handshake.
Next CALL-focused checks:
1. Retest exact CALL echo three times with clean power cycles to see whether
`07 80 45 20 D0 68` is repeatable.
2. Test echoing only `CALL high/on` and only `CALL low/off` separately to see
which of the two echoed frames causes `07 80 45 20 D0 68`.
3. Try using `07 80 45 20 D0 68` as a follow-up host frame after CALL exact
echo, only after confirming repeatability.