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

run 14

Browse Source
This commit is contained in:
Aiden
2026-05-13 17:18:32 +10:00
parent 693735dc0a
commit 676162920f
4 changed files with 130 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

51
docs/discovery-notes.md
View File

@@ -3457,6 +3457,57 @@ python scripts/serial_button_response_test.py --port COM5 --duration 22 --prompt
python scripts/serial_button_response_test.py --port COM5 --duration 24 --prompt --startup-delay 1.0 --startup-frame-interval 0.05 --startup-frame "00 00 15 80 00 CF" --startup-frame "00 00 15 00 00 4F" --startup-repeat 3 --startup-repeat-interval 2.0 --startup-read-after-group 0.8 --watch-frame "07 80 45 20 D0 68" --watch-frame "07 80 45 30 D0 78" --log captures/rcp-buttons-cold-call-repeat-3x-gap-2s-v2.txt
```
### 2026-05-13 Corrected CALL Retrigger Result
Captures:
- `captures/rcp-buttons-cold-call-repeat-2x-gap-2s-v2.txt`
- `captures/rcp-buttons-cold-call-repeat-2x-gap-5s-v2.txt`
- `captures/rcp-buttons-cold-call-repeat-3x-gap-2s-v2.txt`
User observation:
- No LCD changes were observed beyond the already known `CONNECT NOT ACT`.
Observed serial result:
| Test | Trigger groups sent | `0x45` result |
| --- | --- | --- |
| 2x, 2 second gap | 2 | both groups produced `07 80 45 20 D0 68`, four copies each |
| 2x, 5 second gap | 2 | only first group produced `07 80 45 20 D0 68` |
| 3x, 2 second gap | 3 | only first group produced `07 80 45 20 D0 68` |
Interpretation:
- The synthetic CALL path is not a strict one-shot latch, because the 2x/2s run
clearly retriggered on the second group.
- It is also not cleanly repeatable on every later trigger, because the 2x/5s
and 3x/2s runs only produced the `0x45` burst on the first group.
- Each successful trigger can produce a short burst of repeated identical
`07 80 45 20 D0 68` frames rather than a single reply.
- Current best model: the CALL path is re-enterable but phase/state-sensitive.
Something about timing relative to the RCP's internal scan/heartbeat/session
state affects whether later trigger groups are accepted.
Practical takeaway:
- We can use the synthetic CALL pair as a reproducible probe, but not yet as a
guaranteed repeatable command in every cycle of a run.
- For future CALL-path experiments, treat one successful `0x45` burst per power
cycle as the reliable baseline, and repeated triggers as conditional behavior
worth probing rather than assuming.
Next retrigger refinement:
```powershell
python scripts/serial_button_response_test.py --port COM5 --duration 20 --prompt --startup-delay 1.0 --startup-frame-interval 0.05 --startup-frame "00 00 15 80 00 CF" --startup-frame "00 00 15 00 00 4F" --startup-repeat 2 --startup-repeat-interval 2.0 --startup-read-after-group 1.5 --watch-frame "07 80 45 20 D0 68" --watch-frame "07 80 45 30 D0 78" --log captures/rcp-buttons-cold-call-repeat-2x-gap-2s-read1500ms.txt
python scripts/serial_button_response_test.py --port COM5 --duration 23 --prompt --startup-delay 1.0 --startup-frame-interval 0.05 --startup-frame "00 00 15 80 00 CF" --startup-frame "00 00 15 00 00 4F" --startup-repeat 2 --startup-repeat-interval 3.0 --startup-read-after-group 1.5 --watch-frame "07 80 45 20 D0 68" --watch-frame "07 80 45 30 D0 78" --log captures/rcp-buttons-cold-call-repeat-2x-gap-3s-read1500ms.txt
```
These should help distinguish whether the second-trigger variability is caused
by too-short post-trigger read windows, or by a genuine acceptance window/state
inside the RCP.
### 2026-05-13 Adjacent `0x45` Follow-Up Result
Captures: