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

run 18

Browse Source
This commit is contained in:
Aiden
2026-05-13 18:59:20 +10:00
parent b9e76911bb
commit e03fb7da2a
13 changed files with 833 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

458
docs/discovery-notes.md
View File

@@ -4293,3 +4293,461 @@ Next branch worth testing:
- or combine heartbeat maintenance with the synthetic CALL path, to test
whether "host present" plus an event-path trigger behaves differently than
"host present" plus a plain table query
## Camera-Info-Stream Hypothesis Ladder
Goal:
- Test the idea that the panel wants more than a plain link heartbeat.
- Treat one frame family as "host present" and another as possible
camera-state/camera-info traffic.
- Check whether the transient heartbeat-induced `0x40` / `0xC0` family is a
different readable page or context, not just noise.
Working model:
1. host heartbeat says "I am here"
2. a second family says "here is current camera state"
3. only then does the panel become fully active
### CI1: Provoke `0x40` Family, Then Query `B0`
Use the same dense double-heartbeat pattern that previously provoked
`07 80 40 40 30 ED`, then immediately ask for a known `B0` block.
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --frame "00 00 00 00 80 DA" --frame "00 00 00 00 80 DA" --frame "00 00 B0 00 80 6A" --frame "00 00 00 00 80 DA" --frame "00 00 00 00 80 DA" --repeat 4 --frame-interval 0.10 --read-after-frame 0.25 --read-after-group 0.5 --log captures/rcp-camerainfo-40-then-b0.txt
```
Question:
- Does the `0x40` family suppress `B0`, alter `B0`, or allow a different `B0`
response family than the normal `07 80 6C 40 30 C1`?
### CI2: Provoke `0x40` Family, Then Query `B5`
Same idea, but use the strongest discovery-like block we have.
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --frame "00 00 00 00 80 DA" --frame "00 00 00 00 80 DA" --frame "00 00 B5 00 80 6F" --frame "00 00 00 00 80 DA" --frame "00 00 00 00 80 DA" --repeat 4 --frame-interval 0.10 --read-after-frame 0.25 --read-after-group 0.5 --log captures/rcp-camerainfo-40-then-b5.txt
```
Question:
- If `B5` is really a discovery/status block, does entering the heartbeat-driven
`0x40` state make it return a different page, or consume it entirely?
### CI3: Probe Commands Aligned With The Heartbeat-Induced Family
Try a simple `00 -> 40` and `00 -> C0` query again, but now with a small
heartbeat run-up first instead of a bare primer.
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --frame "00 00 00 00 80 DA" --frame "00 00 00 00 80 DA" --frame "00 00 40 00 80 9A" --read-after-frame 0.4 --read-after-group 1.0 --log captures/rcp-camerainfo-preheart-40.txt
python scripts/serial_sequence_probe.py --port COM5 --prompt --frame "00 00 00 00 80 DA" --frame "00 00 00 00 80 DA" --frame "00 00 C0 00 80 1A" --read-after-frame 0.4 --read-after-group 1.0 --log captures/rcp-camerainfo-preheart-c0.txt
```
Question:
- Do these commands return something closer to the transient `0x40` / `0xC0`
response families when the panel has just seen two host heartbeats?
### CI4: Sustained Mixed Stream, Status-Block Style
Instead of repeating one query, rotate through a small set of known readable
blocks while keeping heartbeat in the stream.
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --frame "00 00 00 00 80 DA" --frame "00 00 A0 00 80 7A" --frame "00 00 00 00 80 DA" --frame "00 00 B0 00 80 6A" --frame "00 00 00 00 80 DA" --frame "00 00 B5 00 80 6F" --repeat 3 --frame-interval 0.20 --read-after-frame 0.25 --read-after-group 0.8 --log captures/rcp-camerainfo-mixed-a0-b0-b5.txt
```
Question:
- Does a rotating "camera info block" stream behave differently from hammering a
single one-shot query?
### CI5: Sustained Mixed Stream, Heartbeat-Driven Family
Rotate heartbeat around `0x40`-family and normal query candidates to see
whether the panel prefers a page/state rhythm instead of a static query.
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --frame "00 00 00 00 80 DA" --frame "00 00 40 00 80 9A" --frame "00 00 00 00 80 DA" --frame "00 00 B0 00 80 6A" --frame "00 00 00 00 80 DA" --frame "00 00 C0 00 80 1A" --repeat 3 --frame-interval 0.20 --read-after-frame 0.25 --read-after-group 0.8 --log captures/rcp-camerainfo-mixed-40-b0-c0.txt
```
Question:
- Does mixing the heartbeat-aligned family with a known readable block expose a
reusable page, a new response family, or any visible panel state change?
### CI6: Sparse Heartbeat Run-Up, Then `A0`
Try the same idea as the dense `0x40` trigger, but with slower heartbeat spacing
that previously nudged the `0xC0` family.
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --frame "00 00 00 00 80 DA" --frame "00 00 00 00 80 DA" --frame "00 00 A0 00 80 7A" --repeat 3 --frame-interval 1.50 --read-after-frame 0.45 --read-after-group 1.0 --log captures/rcp-camerainfo-c0-then-a0.txt
```
Question:
- Does a slower heartbeat-derived state family behave differently from the dense
`0x40` case?
What to watch for:
- the panel stays out of `CONNECT NOT ACT` for the whole run
- a known readable block changes family or value fields
- a later query responds where it previously would not
- the transient `0x40` / `0xC0` family appears immediately before a different
stable block
- any lamp or display change beyond the usual timeout behavior
Recommended order:
1. `CI1`
2. `CI2`
3. `CI4`
4. `CI5`
5. `CI6`
### 2026-05-13 Camera-Info-Stream Result
Captures:
- `captures/rcp-camerainfo-40-then-b0.txt`
- `captures/rcp-camerainfo-40-then-b5.txt`
- `captures/rcp-camerainfo-preheart-40.txt`
- `captures/rcp-camerainfo-preheart-c0.txt`
- `captures/rcp-camerainfo-mixed-a0-b0-b5.txt`
- `captures/rcp-camerainfo-mixed-40-b0-c0.txt`
- `captures/rcp-camerainfo-c0-then-a0.txt`
User observation:
- In `CI6`, the panel appeared to enter `CONNECT NOT ACT` and then emit a
single latch/readable response afterward.
#### CI1: Provoke `0x40`/`0xC0`, Then Query `B0`
Observed result:
- Group 1:
- the second heartbeat produced `07 80 C0 40 30 6D`
- the following `B0` query produced only heartbeat-compatible RX
- Groups 2-4:
- no structured `B0` response
- all later frames stayed heartbeat-compatible
Read:
- The heartbeat-induced `0xC0` family did not open a new `B0` page.
- It appears to consume or displace the normal one-shot response opportunity.
#### CI2: Provoke `0x40`, Then Query `B5`
Observed result:
- Group 1:
- the second heartbeat produced `07 80 40 40 30 ED`
- the following `B5` query produced only heartbeat-compatible RX
- Groups 2-4:
- `B5` remained heartbeat-compatible only
Read:
- Same story as `CI1`: the heartbeat-driven family does not seem to lead into a
richer `B5` discovery page.
- It suppresses or replaces it.
#### CI3: Probe Commands Aligned With The Heartbeat-Induced Family
Observed result:
| Sequence | Result |
| --- | --- |
| double heartbeat, then `00 -> 40` | heartbeat-induced `07 80 40 40 30 ED`, then `00 -> 40` gave heartbeat only |
| double heartbeat, then `00 -> C0` | heartbeat-induced `07 80 40 40 30 ED`, then `00 -> C0` only drained more `07 80 40 40 30 ED` plus heartbeat |
Read:
- The pre-heartbeat `0x40` state does not make the explicit `40` or `C0`
commands bloom into a clear new readable block.
- The explicit commands mostly arrive after the transient state is already in
progress.
#### CI4: Sustained Mixed Stream, Status-Block Style
Observed result:
- Group 1:
- `A0` produced `07 80 68 40 30 C5`
- later `B0` and `B5` in the same mixed stream were heartbeat only
- Groups 2-3:
- `A0`, `B0`, and `B5` were all heartbeat-compatible only
Read:
- A rotating "camera info block" stream did not keep opening new readable
status pages.
- The first successful block still wins, then the rest are suppressed.
#### CI5: Sustained Mixed Stream, Heartbeat-Driven Family
Observed result:
- Group 1:
- `00 -> 40` produced `07 80 50 40 30 FD`
- later `B0` and `C0` in the same stream were heartbeat only
- Groups 2-3:
- all later frames were heartbeat-compatible only
Read:
- This confirms `00 -> 40` is a stable explicit query family in its own right.
- But, again, the first successful readable family suppresses later queries in
the same stream.
#### CI6: Sparse Heartbeat Run-Up, Then `A0`
Observed result:
- Group 1:
- two widely spaced heartbeat frames stayed heartbeat-compatible
- the later `A0` produced a delayed `07 80 68 40 30 C5` burst
- Groups 2-3:
- the same pattern returned heartbeat-compatible RX only
Read:
- This matches the user's observation well: a slow run-up can leave the panel
visibly in `CONNECT NOT ACT`, yet a later single readable/latch response can
still occur afterward.
- That suggests the visible display state and the one-shot readable window are
related, but not identical.
- A panel that has already fallen into `CONNECT NOT ACT` may still accept one
later readable query under the right timing.
Overall interpretation:
- The "camera info stream" hypothesis is not wrong, but this particular test set
did not show a sustained multi-block camera-state feed.
- The heartbeat-induced `0x40` / `0xC0` family is real, but it mostly acts like
a competing one-shot response family, not a gateway into a larger page.
- Mixed streams still collapse into "first successful block wins."
- The cleanest new points are:
- `00 -> 40` is a real explicit readable family: `07 80 50 40 30 FD`
- heartbeat cadence can provoke `0x40` / `0xC0` families without an explicit
query
- a visible `CONNECT NOT ACT` state does not completely forbid one later
readable/latch response
Next branch worth testing:
- isolate the delayed-after-`CONNECT NOT ACT` case from `CI6` with a small
timing ladder around the final `A0`
- compare `A0`, `B0`, and `40` after a deliberate wait-until-`CONNECT NOT ACT`
phase
- test whether the `0x40` / `0xC0` families are better thought of as alternate
readable pages rather than camera-info keepalives
## `CONNECT NOT ACT` vs Latch-State Decoupling Test
Goal:
- Prove that the visible `CONNECT NOT ACT` state and the one-shot readable/latch
state are related, but not the same thing.
- Show one case where the latch is spent even though the panel does **not**
enter `CONNECT NOT ACT`.
- Show another case where the panel **does** enter `CONNECT NOT ACT` and can
still produce one later readable response.
Interpretation target:
- If both paths happen, the LCD state is not a direct indicator of whether the
one-shot readable window is still available.
### DL1: Latch Spent While `CONNECT NOT ACT` Stays Away
This is the "no visible timeout, but latch already consumed" proof.
Watch the LCD throughout. The expected result is that the panel stays out of
`CONNECT NOT ACT` while running.
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --frame "00 00 00 00 80 DA" --frame "00 00 A0 00 80 7A" --frame "00 00 00 00 80 DA" --frame "00 00 00 00 80 DA" --frame "00 00 00 00 80 DA" --repeat 3 --frame-interval 0.25 --read-after-frame 0.35 --read-after-group 0.5 --log captures/rcp-decouple-no-connectnotact-a0.txt
```
What proves decoupling:
- group 1: `A0` responds
- later groups: `A0` does not respond
- LCD never enters `CONNECT NOT ACT` during the run
That shows the latch can be spent even while the display does not show the
timeout/not-active state.
### DL2: Deliberate `CONNECT NOT ACT`, Then Late `A0`
This is the "visible timeout, but one late readable response still exists"
proof.
Method:
- power-cycle
- watch for the panel to show `CONNECT NOT ACT` between the first heartbeat and
the later `A0`
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --pre-read 1.0 --frame "00 00 00 00 80 DA" --frame "00 00 A0 00 80 7A" --frame-interval 2.50 --read-after-frame 0.30 --read-after-group 1.0 --log captures/rcp-decouple-connectnotact-then-a0.txt
```
What proves decoupling:
- the panel visibly enters `CONNECT NOT ACT`
- the later `A0` still returns `07 80 68 40 30 C5`
That shows the visible `CONNECT NOT ACT` state does not automatically mean the
readable/latch opportunity is gone.
### DL3: Deliberate `CONNECT NOT ACT`, Then Two Late `A0` Queries
This tightens `DL2` by checking whether the first late query can consume the
remaining one-shot readable window while the LCD state stays the same.
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --pre-read 1.0 --frame "00 00 00 00 80 DA" --frame "00 00 A0 00 80 7A" --frame "00 00 A0 00 80 7A" --frame-interval 2.50 --read-after-frame 0.30 --read-after-group 1.0 --log captures/rcp-decouple-connectnotact-then-a0-a0.txt
```
What proves decoupling:
- panel enters `CONNECT NOT ACT`
- first late `A0` responds
- second late `A0` does not
- LCD remains in the same visible state
That shows the latch/readable state can change while the display state does not.
### DL4: Compare Late `A0`, `B0`, and `40` After `CONNECT NOT ACT`
This checks whether only some readable families survive the visible timeout
state.
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --pre-read 1.0 --frame "00 00 00 00 80 DA" --frame "00 00 B0 00 80 6A" --frame-interval 2.50 --read-after-frame 0.30 --read-after-group 1.0 --log captures/rcp-decouple-connectnotact-then-b0.txt
python scripts/serial_sequence_probe.py --port COM5 --prompt --pre-read 1.0 --frame "00 00 00 00 80 DA" --frame "00 00 40 00 80 9A" --frame-interval 2.50 --read-after-frame 0.30 --read-after-group 1.0 --log captures/rcp-decouple-connectnotact-then-40.txt
```
Useful outcomes:
- only `A0` responds late:
the post-timeout window may be family-specific
- `A0`, `B0`, and `40` all respond late:
the timeout state is clearly not the same as the latch state
- none respond late:
the `CI6` late response was timing-sensitive and needs a tighter delay ladder
### DL5: Tight Delay Ladder Around Late `A0`
If `DL2` or `DL3` looks close but inconsistent, bracket the timeout edge.
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --pre-read 1.0 --frame "00 00 00 00 80 DA" --frame "00 00 A0 00 80 7A" --frame-interval 2.00 --read-after-frame 0.30 --read-after-group 1.0 --log captures/rcp-decouple-delay-2000ms-a0.txt
python scripts/serial_sequence_probe.py --port COM5 --prompt --pre-read 1.0 --frame "00 00 00 00 80 DA" --frame "00 00 A0 00 80 7A" --frame-interval 2.25 --read-after-frame 0.30 --read-after-group 1.0 --log captures/rcp-decouple-delay-2250ms-a0.txt
python scripts/serial_sequence_probe.py --port COM5 --prompt --pre-read 1.0 --frame "00 00 00 00 80 DA" --frame "00 00 A0 00 80 7A" --frame-interval 2.50 --read-after-frame 0.30 --read-after-group 1.0 --log captures/rcp-decouple-delay-2500ms-a0.txt
python scripts/serial_sequence_probe.py --port COM5 --prompt --pre-read 1.0 --frame "00 00 00 00 80 DA" --frame "00 00 A0 00 80 7A" --frame-interval 2.75 --read-after-frame 0.30 --read-after-group 1.0 --log captures/rcp-decouple-delay-2750ms-a0.txt
```
Recommended order:
1. `DL1`
2. `DL2`
3. `DL3`
4. `DL4`
5. `DL5` only if `DL2`/`DL3` are close but inconsistent
### 2026-05-13 `CONNECT NOT ACT` vs Latch-State Decoupling Result
Captures:
- `captures/rcp-decouple-no-connectnotact-a0.txt`
- `captures/rcp-decouple-connectnotact-then-a0.txt`
- `captures/rcp-decouple-connectnotact-then-a0-a0.txt`
User LCD observation:
- `DL1`: the panel never presented `CONNECT NOT ACT` while the script was
running.
- `DL2` and `DL3`: the panel presented `CONNECT NOT ACT` at the start of the
script.
#### DL1: Latch Spent While `CONNECT NOT ACT` Stays Away
Observed result:
- Group 1:
- `A0` produced a readable block, but this run returned
`07 80 E8 40 30 45` rather than `07 80 68 40 30 C5`
- Groups 2-3:
- `A0` produced heartbeat-compatible RX only
- LCD:
- no `CONNECT NOT ACT` while the script was active
Read:
- This is strong evidence for decoupling in one direction:
the readable/latch state can be consumed while the panel does **not** show
`CONNECT NOT ACT`.
- It also reinforces that the `A0` family can vary between at least `68` and
`E8` forms depending on context/timing.
#### DL2: Deliberate `CONNECT NOT ACT`, Then Late `A0`
Observed result:
- The panel showed `CONNECT NOT ACT` early in the run.
- The later `A0` query produced heartbeat-compatible RX only.
- No delayed `A0` readable block appeared at this exact timing.
Read:
- At a `2.50 s` gap in this two-frame form, visible `CONNECT NOT ACT` did not
guarantee a late readable response.
- This weakens the simple "enter `CONNECT NOT ACT`, then `A0` always still
works once" idea.
#### DL3: Deliberate `CONNECT NOT ACT`, Then Two Late `A0` Queries
Observed result:
- The panel showed `CONNECT NOT ACT` early in the run.
- Both later `A0` queries produced heartbeat-compatible RX only.
- No readable block appeared on either late `A0`.
Read:
- This does not provide the hoped-for second half of the decoupling proof.
- Instead, it says that once the panel has visibly entered `CONNECT NOT ACT` in
this specific timing pattern, the late `A0` opportunity may already be gone or
may require narrower timing than `2.50 s`.
Overall interpretation:
- We now have solid evidence for one half of the claim:
`CONNECT NOT ACT` is **not required** for the latch/readable state to be
consumed.
- We do **not** yet have equally solid evidence for the other half at this
timing:
a visible `CONNECT NOT ACT` state did not still yield a late `A0` response in
`DL2` or `DL3`.
- So the current safest statement is:
the LCD state and the latch/readable state are not directly coupled, but the
exact post-timeout behavior is more timing-sensitive than the earlier `CI6`
observation first suggested.
Best next move:
- run `DL4` and then a tight `DL5` delay bracket
- especially around `2.00 s`, `2.25 s`, `2.50 s`, and `2.75 s`
- because the difference between the earlier `CI6` late hit and these no-hit
decoupling runs is now most likely timing, framing shape, or both