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

run 2

Browse Source
This commit is contained in:
Aiden
2026-05-14 01:19:50 +10:00
parent 962d0e5dec
commit 1d66f3baaf
12 changed files with 1203 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

370
docs/discovery-notes.md
View File

@@ -8588,3 +8588,373 @@ Interpretation guide:
low-command-region effect rather than a single magic frame
- if the same effect also appears at `cmd=0x01 @ 00 80`, then the LCD behavior
may be more about traffic density than payload meaning
### HE35 Result: `20 D0` Narrowing Pass
Capture files present:
- `captures/he35-direct-20d0-cmd00-03.txt`
- `captures/he35-repeat-cmd01-20d0.txt`
- `captures/he35-repeat-cmd01-0080-control.txt`
#### HE35a: direct compare `cmd=0x00-0x03` under `20 D0`
Results:
- `cmd=0x00` -> heartbeat only
- `cmd=0x01` -> repeated:
- `07 80 40 24 DD 64`
- `cmd=0x02` -> heartbeat only
- `cmd=0x03` -> new sibling:
- `07 80 20 12 97 78`
So `0x01` is **not** the only responsive command in the early `20 D0` region,
but it is still the clearest `0x40`-family member.
#### HE35b: repeat only `cmd=0x01 @ 20 D0`
Target frame:
- `00 00 01 20 D0 AB`
Serial result:
- first useful response appeared on the second send
- observed:
- `07 80 40 24 DD 64`
- then one more fragmented repeat of the same family
- after that, the run returned to plain heartbeat even though the frame kept
repeating
Panel-side observation:
- `CONNECT NOT ACT` reportedly stayed off until the script finished
Read:
- this looks like a **one-shot branch opener with continued timeout suppression**
- the payload still matters after the serial branch is spent, at least at the
LCD/state-timer level
#### HE35c: repeat only `cmd=0x01 @ 00 80` baseline control
Target frame:
- `00 00 01 00 80 DB`
Serial result:
- first useful response again appeared on the second send
- observed several copies of:
- `07 80 40 20 D8 65`
- after that, the run also returned to plain heartbeat while the frame kept
repeating
Panel-side observation:
- `CONNECT NOT ACT` reportedly also stayed off until the script finished
Read:
- this weakens the stricter interpretation that only `20 D0` delays the LCD
timeout
- repeated `cmd=0x01` traffic under both payloads appears capable of holding
the panel out of `CONNECT NOT ACT` while the stream is active
Current best interpretation after HE35:
- the distinctive thing about `20 D0` is still the **response family shift**
from:
- `07 80 40 20 D8 65`
to:
- `07 80 40 24 DD 64`
- but the timeout-holding effect may belong more broadly to sustained repeated
`cmd=0x01` traffic than to `20 D0` alone
- `cmd=0x03 @ 20 D0` is now worth treating as a second live lead because it
opened:
- `07 80 20 12 97 78`
Best next follow-up from HE35:
1. run `HE35d` slow `cmd=0x01 @ 20 D0` to separate content from cadence
2. run `HE35e` neighboring repeats to see whether `0x00`, `0x02`, or `0x03`
also suppress `CONNECT NOT ACT`
3. consider a matched repeat on `cmd=0x03 @ 20 D0` because it now has its own
distinct structured family
### HE35 Follow-Up: Slow + Neighbor Repeats
Additional capture files present:
- `captures/he35-repeat-cmd01-20d0-slow.txt`
- `captures/he35-repeat-cmd00-20d0.txt`
- `captures/he35-repeat-cmd02-20d0.txt`
- `captures/he35-repeat-cmd03-20d0.txt`
Panel-side observation from this pass:
- all of these additional runs reportedly kept the LCD in the same "clear"
state while the script was running
That is important because it means the timeout-holding effect is **not** unique
to repeated `cmd=0x01`.
#### HE35d: slow repeat of `cmd=0x01 @ 20 D0`
Target frame:
- `00 00 01 20 D0 AB`
Serial result:
- second send still opened the same family:
- `07 80 40 24 DD 64`
- it produced a larger one-shot burst than the faster repeat
- after that, the stream returned to heartbeat for the rest of the run
Read:
- slowing the cadence to `1.5 s` did **not** kill the branch
- so this is not purely a "dense traffic only" effect
#### HE35e-1: repeat only `cmd=0x00 @ 20 D0`
Target frame:
- `00 00 00 20 D0 AA`
Serial result:
- second send opened a new sibling:
- `07 80 40 48 3A EF`
- then the run fell back to heartbeat
Read:
- `cmd=0x00 @ 20 D0` is not heartbeat-only after all
- it appears to open its own `0x40`-family sibling under repetition
#### HE35e-2: repeat only `cmd=0x02 @ 20 D0`
Target frame:
- `00 00 02 20 D0 A8`
Serial result:
- second send opened:
- `07 80 20 12 87 68`
- then returned to heartbeat
Read:
- this makes the `0x02/0x03 @ 20 D0` region look like a small structured
`0x20 0x12 ...` family surface, not a one-off anomaly
#### HE35e-3: repeat only `cmd=0x03 @ 20 D0`
Target frame:
- `00 00 03 20 D0 A9`
Serial result:
- second send opened:
- `07 80 20 12 97 78`
- then returned to heartbeat
Read:
- `0x03 @ 20 D0` behaves consistently with the direct-compare run
- it is the stronger `0x20 0x12 ...` sibling of the `0x02` branch
Current read after the full HE35 pass:
- the low `0x00-0x03` command region under `20 D0` is now clearly structured:
- `0x00` -> `07 80 40 48 3A EF`
- `0x01` -> `07 80 40 24 DD 64`
- `0x02` -> `07 80 20 12 87 68`
- `0x03` -> `07 80 20 12 97 78`
- each branch still looks one-shot on the serial side
- but repeated traffic from this small region appears sufficient to hold the LCD
out of `CONNECT NOT ACT` while the script is active
That suggests a better model:
- these frames may not be "the wake command"
- but they do look like a **low-command session-presence/status surface**
- and different command bytes select neighboring structured families within it
### HE36: Low-Command Mixer + Broadened Keep-Alive Search
Goal: test whether mixing the known low-command `20 D0` frames does more than
repeating one at a time, and broaden the search to nearby commands that might
belong to the same "keep-alive-ish" session-presence surface.
Known live low-command `20 D0` frames so far:
- `00 00 00 20 D0 AA`
- `00 00 01 20 D0 AB`
- `00 00 02 20 D0 A8`
- `00 00 03 20 D0 A9`
#### HE36a: maintained 4-frame mixer, medium cadence
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --prompt-screen --pre-read 2.0 --frame "00 00 00 20 D0 AA" --frame "00 00 01 20 D0 AB" --frame "00 00 02 20 D0 A8" --frame "00 00 03 20 D0 A9" --repeat 10 --frame-interval 0.50 --read-after-frame 0.20 --read-after-group 0.80 --log captures/he36-mixer-20d0-00-03-medium.txt
```
What to watch:
- whether the LCD stays clear / non-`CONNECT NOT ACT`
- whether new structured families appear beyond the known one-shot siblings
- whether the mixed stream looks "more alive" than any single-frame repeat
#### HE36b: maintained 4-frame mixer, slow cadence
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --prompt-screen --pre-read 2.0 --frame "00 00 00 20 D0 AA" --frame "00 00 01 20 D0 AB" --frame "00 00 02 20 D0 A8" --frame "00 00 03 20 D0 A9" --repeat 8 --frame-interval 1.20 --read-after-frame 0.25 --read-after-group 1.20 --log captures/he36-mixer-20d0-00-03-slow.txt
```
Purpose:
- separate "this class matters" from "the panel only likes brisk chatter"
#### HE36c: 2-frame split mixers by family
`0x40`-leaning pair:
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --prompt-screen --pre-read 2.0 --frame "00 00 00 20 D0 AA" --frame "00 00 01 20 D0 AB" --repeat 12 --frame-interval 0.60 --read-after-frame 0.20 --read-after-group 0.80 --log captures/he36-mixer-20d0-40pair.txt
```
`0x20 0x12`-leaning pair:
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --prompt-screen --pre-read 2.0 --frame "00 00 02 20 D0 A8" --frame "00 00 03 20 D0 A9" --repeat 12 --frame-interval 0.60 --read-after-frame 0.20 --read-after-group 0.80 --log captures/he36-mixer-20d0-20pair.txt
```
Purpose:
- see whether one subfamily is better at holding the panel clear
- or whether mixing both subfamilies is what helps
#### HE36d: broadened direct sweep `0x04-0x0F @ 20 D0`
```powershell
python scripts/serial_direct_response_sweep.py --port COM5 --prefix1s 0x00 --prefix2s 0x00 --commands 0x04-0x0F --states 0x20 --values 0xD0 --settle 3.0 --after-each 0.8 --after 2.0 --pause-on-anomaly --log captures/he36-direct-20d0-cmd04-0f.txt
```
Purpose:
- look for more neighboring "keep-alive-ish" branches without re-running the
whole `0x00-0xFF` space
- map whether this structured low-command surface extends further upward
#### HE36e: broader direct sweep `0x10-0x1F @ 20 D0`
```powershell
python scripts/serial_direct_response_sweep.py --port COM5 --prefix1s 0x00 --prefix2s 0x00 --commands 0x10-0x1F --states 0x20 --values 0xD0 --settle 3.0 --after-each 0.8 --after 2.0 --pause-on-anomaly --log captures/he36-direct-20d0-cmd10-1f.txt
```
Purpose:
- test whether the same effect is really a "low command region" phenomenon
- or mostly a tight `0x00-0x03` pocket
#### HE36f: single-frame repeats for any new HE36d/e hits
If `HE36d` or `HE36e` turn up new live candidates, repeat them individually with
the same pattern used in HE35:
```powershell
python scripts/serial_probe_response.py --port COM5 --tx-frame "<candidate frame>" --repeat 20 --interval 0.50 --delay 3 --after 3 --frame-size 0 --log captures/he36-repeat-<candidate>.txt
```
Use this only for commands that actually produce a structured family in the
direct sweep.
#### Recommended order
1. `HE36a` 4-frame medium mixer
2. `HE36c` split mixers
3. `HE36b` 4-frame slow mixer
4. `HE36d` broadened `0x04-0x0F` sweep
5. `HE36e` broadened `0x10-0x1F` sweep
6. `HE36f` repeat any new hits individually
Interpretation guide:
- if the mixer holds the LCD clear **and** produces richer serial behavior,
we may be getting closer to a maintained background stream class
- if the mixer holds the LCD clear but still stays serially one-shot, that
still supports a "session-presence without full activation" model
- if `0x04-0x1F @ 20 D0` reveals more structured siblings, then this is likely
a broader maintained low-command surface rather than just a four-command oddity
### HE36 Result: Mixer + Broadened Low-Command Surface
Capture files present:
- `captures/he36-mixer-20d0-00-03-medium.txt`
- `captures/he36-mixer-20d0-00-03-slow.txt`
- `captures/he36-mixer-20d0-40pair.txt`
- `captures/he36-mixer-20d0-20pair.txt`
- `captures/he36-direct-20d0-cmd04-0f.txt`
- `captures/he36-direct-20d0-cmd10-1f.txt`
#### Mixer behavior
The mixer runs were surprisingly consistent:
- they did **not** open deeper multi-turn branches
- they mostly produced the same early one-shot family behavior in group 1
- after that, the stream settled into heartbeat-compatible traffic while the
script continued
The practical implication is still important:
- the mixed low-command stream behaves like a stable maintained background
surface
- but not yet like a full session activator
The split-pair mixers behaved the same way:
- `00/01` pair stayed on the `0x40` side
- `02/03` pair stayed on the `0x20 0x12` side
- neither pair triggered a richer second-stage exchange
#### Broadened direct sweep: `0x04-0x0F @ 20 D0`
This region is definitely live and patterned:
- `0x05` -> `07 80 41 24 DD 65`
- `0x07` -> `07 80 10 09 D7 13`
- `0x09` -> `07 80 42 24 DD 66`
- `0x0B` -> `07 80 21 12 17 F9`
- `0x0D` -> `07 80 43 24 DD 67`
#### Broadened direct sweep: `0x10-0x1F @ 20 D0`
The pattern extends cleanly upward:
- `0x11` -> `07 80 44 24 DD 60`
- `0x13` -> `07 80 22 12 97 7A`
- `0x15` -> `07 80 45 24 DD 61`
- `0x17` -> `07 80 11 09 D7 12`
- `0x19` -> `07 80 46 24 DD 62`
- `0x1B` -> `07 80 23 12 17 FB`
- `0x1D` -> `07 80 47 24 DD 63`
Current best structural read:
- the low `20 D0` command region is not just a tiny `0x00-0x03` pocket
- it extends at least through `0x1D` with repeating family structure
- the active commands are mostly the odd ones in the region
- and the responses appear to cluster into at least three sibling families:
- `07 80 4x 24 DD 6x`
- `07 80 2x 12 .. ..`
- `07 80 1x 09 D7 1x`
That is a much stronger hint that we are seeing a real maintained status/control
surface rather than random one-shot exceptions.

36
docs/pt2-protocol-summary.md
View File

@@ -432,6 +432,42 @@ Current caution:
LCD behavior
- That suggests `20 D0` may be a more session-like or status-like host payload
pair than `00 80`, even though it still does not by itself wake the panel.
- A later targeted follow-up refined that further:
- `cmd=0x01 @ 20 D0` repeatedly opened `07 80 40 24 DD 64`
- `cmd=0x01 @ 00 80` repeatedly opened `07 80 40 20 D8 65`
- `cmd=0x03 @ 20 D0` also opened a second distinct family:
`07 80 20 12 97 78`
- in both repeated-`cmd=0x01` tests, the panel reportedly stayed out of
`CONNECT NOT ACT` until the script ended
- So the clearest difference between `20 D0` and `00 80` is currently the
**family selected** by repeated `cmd=0x01`, while the timeout-holding effect
may be a broader property of sustained repeated `cmd=0x01` traffic.
- A broader HE35 follow-up then showed that the early `0x00-0x03` command
region under `20 D0` is itself structured:
- `0x00` -> `07 80 40 48 3A EF`
- `0x01` -> `07 80 40 24 DD 64`
- `0x02` -> `07 80 20 12 87 68`
- `0x03` -> `07 80 20 12 97 78`
- All of those still looked one-shot on the serial side, but the user reported
the LCD stayed in the same clear/non-`CONNECT NOT ACT` state while the repeat
scripts were active.
- That makes the low `0x00-0x03 @ 20 D0` area look less like a single magic
wake frame and more like a small session-presence/status surface.
- A broader HE36 pass strengthened that further:
- the active pattern extends at least through `0x1D @ 20 D0`
- and it is mostly the odd commands that answer
- examples:
- `0x05` -> `07 80 41 24 DD 65`
- `0x09` -> `07 80 42 24 DD 66`
- `0x0D` -> `07 80 43 24 DD 67`
- `0x11` -> `07 80 44 24 DD 60`
- `0x15` -> `07 80 45 24 DD 61`
- `0x19` -> `07 80 46 24 DD 62`
- `0x1D` -> `07 80 47 24 DD 63`
- interleaved siblings also appear in `0x10 0x09 D7 ..` and
`0x20 0x12 .. ..` families
- So `20 D0` now looks like a broader low-command maintained surface, not just
a four-command curiosity.
## What We Do Not Know