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

run 34

Browse Source
This commit is contained in:
Aiden
2026-05-13 21:43:18 +10:00
parent 3e7b8ac50d
commit 94b5bff01c
10 changed files with 1692 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

535
docs/discovery-notes.md
View File

@@ -7067,3 +7067,538 @@ Best next move after HE30:
- the host `40/50 ...` -> RCP `50/D4 ...` surface
- Those now look more promising than continuing to brute-force entirely new
top-level selectors.
### HE31: Wake-The-Panel Pass
Goal:
- Go back to the practical question:
can we make the RCP behave more "awake" on the front panel, even if we still
do not know the full PT2 conversation?
- Specifically watch for:
- leaving `CONNECT NOT ACT`
- any lamp change
- any numeric readout change
- selector/query branches becoming reusable while the run is active
Why this pass is different:
- We now know a lot of the protocol is structured, but broad mixed streams did
not wake the panel.
- That suggests the wake condition may depend more on:
- **boot timing**
- **consistent page identity**
- **slower realistic cadence**
- or a **background base-status layer plus a single active page**
than on throwing many valid-looking families at it at once.
What we are testing here:
1. very early boot-window traffic
2. one stable page repeated instead of carousels
3. base-status background plus one stable page
4. CALL event path while a stable session-like stream is present
#### HE31a: Early-boot `90 -> E8` repeated page
Hypothesis:
- The panel may only accept wake/session framing very early after power-on.
- `90 -> E8` is one of the cleanest structured selectors we have, so treat it
like a plausible "current camera page" and present it immediately.
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --prompt-screen --pre-read 0.2 --delay 0.0 --frame "00 00 90 00 80 4A" --frame "00 00 E8 40 30 C2" --frame "00 00 7A 50 26 56" --repeat 12 --frame-interval 0.15 --read-after-frame 0.08 --repeat-interval 0.35 --read-after-group 0.20 --log captures/rcp-he31-boot-e8-page.txt
```
#### HE31b: Early-boot base-status plus `E8` page
Hypothesis:
- The panel may want a base status layer before it treats a page feed as live.
- Use the strongest current base-status candidates together with the clean `E8`
page family.
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --prompt-screen --pre-read 0.2 --delay 0.0 --frame "00 00 40 40 30 6A" --frame "00 00 00 00 80 DA" --frame "00 00 90 00 80 4A" --frame "00 00 E8 40 30 C2" --frame "00 00 7A 50 26 56" --repeat 10 --frame-interval 0.15 --read-after-frame 0.08 --repeat-interval 0.35 --read-after-group 0.20 --log captures/rcp-he31-boot-base-plus-e8.txt
```
#### HE31c: Slow realistic `E8` page cadence
Hypothesis:
- Our earlier fan-outs may have been too dense or too "computer-ish."
- Try a slower, more boring, repeated page cadence as if a CCU is refreshing one
visible control page.
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --prompt-screen --pre-read 1.0 --frame "00 00 90 00 80 4A" --frame "00 00 E8 40 30 C2" --frame "00 00 7A 50 26 56" --repeat 20 --frame-interval 0.25 --read-after-frame 0.10 --repeat-interval 0.80 --read-after-group 0.20 --log captures/rcp-he31-slow-e8-page.txt
```
#### HE31d: Slow realistic base-status only cadence
Hypothesis:
- If the wake condition is mostly "camera is alive and reporting status", the
base-status side may matter more than the selector side at first.
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --prompt-screen --pre-read 1.0 --frame "00 00 40 40 30 6A" --frame "00 00 00 00 80 DA" --frame "00 00 50 40 30 7A" --repeat 20 --frame-interval 0.25 --read-after-frame 0.10 --repeat-interval 0.80 --read-after-group 0.20 --log captures/rcp-he31-slow-base-status.txt
```
#### HE31e: Base-status background plus stable `EC` page
Hypothesis:
- `EC` is stricter than `E8/E9` and may correspond to a more central "connected"
page.
- Feed a background base-status layer and then one stable `EC` page only.
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --prompt-screen --pre-read 1.0 --frame "00 00 40 40 30 6A" --frame "00 00 00 00 80 DA" --frame "00 00 90 00 80 4A" --frame "00 00 EC 40 30 C6" --frame "00 00 7B 50 26 57" --repeat 15 --frame-interval 0.20 --read-after-frame 0.10 --repeat-interval 0.60 --read-after-group 0.20 --log captures/rcp-he31-base-plus-ec.txt
```
#### HE31f: CALL while stable `E8` page is present
Hypothesis:
- The panel may only treat operator events as meaningful when it sees a stable
enough background page/session context.
- Keep a simple `E8` page stream running, then inject the known synthetic CALL
pair into the same group.
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --prompt-screen --pre-read 1.0 --frame "00 00 90 00 80 4A" --frame "00 00 E8 40 30 C2" --frame "00 00 7A 50 26 56" --frame "00 00 15 80 00 CF" --frame "00 00 15 00 00 4F" --repeat 10 --frame-interval 0.20 --read-after-frame 0.12 --repeat-interval 0.60 --read-after-group 0.25 --log captures/rcp-he31-e8-plus-call.txt
```
#### HE31g: CALL while base-status background is present
Hypothesis:
- Same idea as above, but maybe the event path wants base-status presence more
than selector-page presence.
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --prompt-screen --pre-read 1.0 --frame "00 00 40 40 30 6A" --frame "00 00 00 00 80 DA" --frame "00 00 15 80 00 CF" --frame "00 00 15 00 00 4F" --repeat 10 --frame-interval 0.20 --read-after-frame 0.12 --repeat-interval 0.60 --read-after-group 0.25 --log captures/rcp-he31-base-plus-call.txt
```
Recommended order:
1. `HE31a` early-boot `E8` page
2. `HE31b` early-boot base-status plus `E8`
3. `HE31c` slow `E8` page cadence
4. `HE31e` base-status plus `EC`
5. `HE31f` `E8` plus CALL
6. `HE31d` slow base-status only
7. `HE31g` base-status plus CALL
Reasoning:
- The most likely miss so far is timing and stability, not absence of valid
bytes.
- So this pass biases toward:
- early boot
- one stable page
- one stable background layer
- and one meaningful operator event
### 2026-05-13 HE31 Results
Front-panel result:
- No HE31 run visibly woke the panel.
- No useful LCD, lamp, or numeric-display change was recorded.
Note on the `PANEL` lines in some logs:
- A few captures contain the next command line pasted into the `--prompt-screen`
prompt.
- Those lines are not treated as evidence of panel state.
#### HE31a: Early-boot `E8` page
Log:
- `captures/rcp-he31-boot-e8-page.txt`
Result:
- Group 1 did produce the expected early structured branch:
- `07 80 FA 50 26 51`
- Groups 2-12 then stayed heartbeat-compatible only.
Read:
- Starting very early after boot did **not** turn the `E8` page stream into a
reusable or session-like wake path.
- It still behaved like a one-shot branch that immediately collapsed.
#### HE31b: Early-boot base-status plus `E8`
Log:
- `captures/rcp-he31-boot-base-plus-e8.txt`
Result:
- Group 1 briefly produced:
- `07 80 40 40 30 ED`
- After that, the whole run stayed heartbeat-compatible.
- No later `E8` page family reopened.
Read:
- Adding a base-status layer at boot did **not** help `E8`; it actually biased
the run toward the known fallback/transient family.
#### HE31c: Slow realistic `E8` page cadence
Log:
- `captures/rcp-he31-slow-e8-page.txt`
Result:
- Group 1 produced the familiar:
- `07 80 7A 50 26 D1`
- Groups 2-20 then stayed heartbeat-compatible only.
Read:
- A slower, more boring cadence did not make the `E8` page stream feel more
alive to the panel.
- So the earlier dense fan-outs likely were **not** failing just because they
were too fast or too "computer-ish."
#### HE31d: Slow base-status only cadence
Log:
- `captures/rcp-he31-slow-base-status.txt`
Result:
- Group 1 produced:
- `07 80 40 40 30 ED`
- Groups 2-20 then stayed heartbeat-compatible only.
Read:
- Repeating only the base-status side also failed to wake the panel.
- It behaved like a fallback-presence layer, not a true active-session layer.
#### HE31e: Base-status plus stable `EC`
Log:
- `captures/rcp-he31-base-plus-ec.txt`
Result:
- Group 1 produced:
- `07 80 40 60 30 CD`
- After that, the full run stayed heartbeat-compatible.
- `EC` did **not** reopen a stable `7B` page under this background.
Read:
- Even the stricter `EC` branch did not become more useful under a stable
base-status background.
- This argues against "just add one richer page on top of base status" as the
missing wake condition.
#### HE31f: `E8` page plus CALL
Log:
- `captures/rcp-he31-e8-plus-call.txt`
Result:
- Group 1 again showed the early `E8` branch:
- `07 80 FA 50 26 51`
- The following synthetic CALL pair:
- `00 00 15 80 00 CF`
- `00 00 15 00 00 4F`
produced only heartbeat-compatible traffic.
- No `0x45` CALL-family reply appeared.
Read:
- A stable `E8` page context does **not** make the CALL synthetic event path
become richer or more session-like.
- In this context, CALL actually looks less interesting than in the earlier
dedicated CALL work.
#### HE31g: Base-status plus CALL
Log:
- `captures/rcp-he31-base-plus-call.txt`
Result:
- Group 1 produced:
- `07 80 40 40 30 ED`
- The synthetic CALL pair after that stayed heartbeat-compatible only.
- No `0x45` CALL-family reply appeared.
Read:
- Base-status presence also does **not** make CALL act like a wake/session
trigger.
### HE31 Overall Read
The wake-oriented pass answers a few important questions pretty cleanly:
- Early boot timing alone is **not** enough.
- One stable repeated page alone is **not** enough.
- Base-status background plus one page is **not** enough.
- CALL injected into those contexts is **not** enough.
Most important practical conclusion:
- The panel still does not look like it is waiting for merely:
- a believable page stream
- a believable base-status stream
- or an operator event inside those streams
So the missing wake condition is probably something more specific, such as:
- a CCU identity/mode declaration we still have not found
- a different class of background page entirely
- or a stricter startup sequence/order than our current page-first models
### HE32: Best-Shot Startup / Handshake Ladder
Goal:
- Try the **most plausible remaining startup shapes** rather than broad
exploration.
- Bias toward sequences that feel more like a real CCU boot:
- declare identity or capability once
- select a page once
- then maintain a simpler background/value stream
Why these are the best next options:
- HE31 suggests the panel is **not** waking on:
- simple early boot timing
- one stable repeated page
- base-status plus one page
- CALL inside those contexts
- So the stronger remaining hypothesis is that we are missing a more
**structured startup order**, not just more valid traffic.
Current best candidate building blocks:
- possible identity / discovery:
- `00 00 A0 00 80 7A`
- `00 00 B0 00 80 6A`
- `00 00 B5 00 80 6F`
- possible opener / page-class:
- `00 00 90 00 80 4A`
- `00 00 AF 00 80 75`
- possible maintained page feed:
- `00 00 E8 40 30 C2`
- `00 00 7A 50 26 56`
- possible maintained background:
- `00 00 00 00 80 DA`
- `00 00 40 40 30 6A`
- `00 00 50 40 30 7A`
What would count as a hit:
- any visible wake-up on the panel
- selector/query families reopening later in the same run
- a new recurring non-heartbeat family replacing the current idle rhythm
- a run that behaves differently from the usual "group 1 only, then collapse"
#### HE32a: Discovery-first, then `90 -> E8`, then maintained `7A`
Hypothesis:
- The panel may want to see readable identity/capability pages before it accepts
a page/value stream.
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --prompt-screen --pre-read 0.5 --frame "00 00 A0 00 80 7A" --frame "00 00 B0 00 80 6A" --frame "00 00 B5 00 80 6F" --frame "00 00 90 00 80 4A" --frame "00 00 E8 40 30 C2" --frame "00 00 7A 50 26 56" --frame "00 00 00 00 80 DA" --frame "00 00 7A 50 26 56" --frame "00 00 00 00 80 DA" --frame "00 00 7A 50 26 56" --read-after-frame 0.15 --frame-interval 0.20 --read-after-group 2.0 --log captures/rcp-he32-discovery-then-e8-maintain.txt
```
#### HE32b: `A0 -> 90 -> E8`, then heartbeat-only maintenance
Hypothesis:
- The missing piece may be a one-time selector/opening chain, with heartbeat
alone sufficient afterward.
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --prompt-screen --pre-read 0.5 --frame "00 00 A0 00 80 7A" --frame "00 00 90 00 80 4A" --frame "00 00 E8 40 30 C2" --frame "00 00 7A 50 26 56" --frame "00 00 00 00 80 DA" --frame "00 00 00 00 80 DA" --frame "00 00 00 00 80 DA" --frame "00 00 00 00 80 DA" --read-after-frame 0.15 --frame-interval 0.20 --read-after-group 3.0 --log captures/rcp-he32-a0-90-e8-heartbeat-tail.txt
```
#### HE32c: `A0 -> 90 -> E8`, then `7A`-only maintenance
Hypothesis:
- Heartbeat may only mean "host present," while `7A 50 26` may be the real page
value stream the panel wants once opened.
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --prompt-screen --pre-read 0.5 --frame "00 00 A0 00 80 7A" --frame "00 00 90 00 80 4A" --frame "00 00 E8 40 30 C2" --frame "00 00 7A 50 26 56" --frame "00 00 7A 50 26 56" --frame "00 00 7A 50 26 56" --frame "00 00 7A 50 26 56" --read-after-frame 0.15 --frame-interval 0.25 --read-after-group 3.0 --log captures/rcp-he32-a0-90-e8-7a-tail.txt
```
#### HE32d: `AF -> 90 -> E8`, then maintained `FA`
Hypothesis:
- `AF` may be a more camera-flavored opener, and `FA 50 26` may be the sibling
page/value family this context actually wants.
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --prompt-screen --pre-read 0.5 --frame "00 00 AF 00 80 75" --frame "00 00 90 00 80 4A" --frame "00 00 E8 40 30 C2" --frame "00 00 FA 50 26 D6" --frame "00 00 00 00 80 DA" --frame "00 00 FA 50 26 D6" --frame "00 00 00 00 80 DA" --frame "00 00 FA 50 26 D6" --read-after-frame 0.15 --frame-interval 0.20 --read-after-group 2.0 --log captures/rcp-he32-af-90-e8-fa-tail.txt
```
#### HE32e: `A0 -> AF -> EC`, then maintained `7B`
Hypothesis:
- `EC` is stricter than `E8`; it may need both a general opener and a mode
opener before the page/value feed makes sense.
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --prompt-screen --pre-read 0.5 --frame "00 00 A0 00 80 7A" --frame "00 00 AF 00 80 75" --frame "00 00 EC 40 30 C6" --frame "00 00 7B 50 26 57" --frame "00 00 00 00 80 DA" --frame "00 00 7B 50 26 57" --frame "00 00 00 00 80 DA" --frame "00 00 7B 50 26 57" --read-after-frame 0.15 --frame-interval 0.20 --read-after-group 2.0 --log captures/rcp-he32-a0-af-ec-7b-tail.txt
```
#### HE32f: Repeated `90` identity beacon, then single `E8` page
Hypothesis:
- The panel may want to see a short identity/mode beacon first, before any page
selection at all.
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --prompt-screen --pre-read 0.5 --frame "00 00 90 00 80 4A" --frame "00 00 90 00 80 4A" --frame "00 00 90 00 80 4A" --frame "00 00 E8 40 30 C2" --frame "00 00 7A 50 26 56" --frame "00 00 00 00 80 DA" --frame "00 00 7A 50 26 56" --read-after-frame 0.15 --frame-interval 0.25 --read-after-group 2.5 --log captures/rcp-he32-90-beacon-then-e8.txt
```
#### HE32g: Repeated `AF` identity beacon, then single `EC` page
Hypothesis:
- Same idea as above, but aimed at the stricter `EC` branch.
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --prompt-screen --pre-read 0.5 --frame "00 00 AF 00 80 75" --frame "00 00 AF 00 80 75" --frame "00 00 AF 00 80 75" --frame "00 00 EC 40 30 C6" --frame "00 00 7B 50 26 57" --frame "00 00 00 00 80 DA" --frame "00 00 7B 50 26 57" --read-after-frame 0.15 --frame-interval 0.25 --read-after-group 2.5 --log captures/rcp-he32-af-beacon-then-ec.txt
```
Recommended order:
1. `HE32a` discovery-first then `E8`
2. `HE32b` `A0 -> 90 -> E8` then heartbeat tail
3. `HE32c` `A0 -> 90 -> E8` then `7A` tail
4. `HE32e` `A0 -> AF -> EC` then `7B` tail
5. `HE32f` `90` beacon then `E8`
6. `HE32d` `AF -> 90 -> E8` then `FA` tail
7. `HE32g` `AF` beacon then `EC`
Reasoning:
- These are the strongest remaining handshake-shaped guesses:
- discovery before page
- stacked openers rather than alternative openers
- set-once then maintain-later
- beacon first, page second
### 2026-05-13 CAM POWER Context Retests
Goal:
- Re-test the older `CAM POWER` exact echo inside stronger modern contexts:
- stable `E8` page context
- base-status context
- See whether `CAM POWER` starts to behave like a meaningful event once the
panel already has more believable host/session traffic behind it.
Logs found:
- `captures/rcp-cam-power-e8-context-exact-echo.txt`
- `captures/rcp-cam-power-base-context-exact-echo.txt`
Note:
- I do **not** currently see separate host-shaped context reruns in
`captures/`. This section only reflects the two exact-echo context captures
that are present.
#### CAM POWER exact echo inside `E8` page context
Sequence:
- repeating startup page stream:
- `00 00 90 00 80 4A`
- `00 00 E8 40 30 C2`
- `00 00 7A 50 26 56`
- button response:
- `00 00 07 80 00 DD`
Result:
- The page stream initially produced the known `E8` family:
- `07 80 7A 50 26 D1`
- During the run, the panel emitted repeated `CAM POWER` event frames:
- `00 00 07 80 00 DD`
- When the exact echo was finally sent back, no new structured response family
appeared afterward.
- The run remained on button-event / heartbeat-class behavior with no visible
wake-up.
Read:
- Stronger page context does **not** make the older exact `CAM POWER` echo turn
into a session-advancing command.
- It does show that `CAM POWER` traffic can coexist with the `E8` page stream
without disrupting the panel into a richer state.
#### CAM POWER exact echo inside base-status context
Sequence:
- repeating startup base-status stream:
- `00 00 40 40 30 6A`
- `00 00 00 00 80 DA`
- `00 00 50 40 30 7A`
- button response:
- `00 00 07 80 00 DD`
Result:
- The first startup cycle briefly showed:
- `07 80 C0 40 30 6D`
- After that, the run settled into plain heartbeat-compatible traffic.
- No useful new structured response appeared after the base-status context.
- No visible wake-up occurred.
Read:
- Base-status context also does **not** make the exact `CAM POWER` echo behave
like a meaningful wake/session event.
- Compared with the `E8` context run, this one looks even flatter.
### Context-Retest Read
What changed:
- We re-tested `CAM POWER` exact echo inside stronger session-like backgrounds.
What did **not** change:
- no panel wake-up
- no new session-like serial stage
- no evidence that `CAM POWER` becomes a useful host/CCU handshake element when
wrapped in `E8` page traffic or base-status traffic
Best current read:
- `CAM POWER` still looks much more like an **outbound panel-origin operator
event** than a wake/session negotiation hook.
- `CALL` remains the more protocol-interesting operator event family.