run 11

docs/discovery-notes.md

@@ -3140,3 +3140,59 @@ python scripts/serial_button_response_test.py --port COM5 --duration 15 --prompt
 
 For each follow-up test, note whether the LCD changes, whether more serial data
 appears after the follow-up, and whether the panel returns to heartbeat only.
+
+### 2026-05-13 CALL `0x45` Follow-Up Result
+
+Captures:
+
+- `captures/rcp-buttons-call-45-followup-generic-ack.txt`
+- `captures/rcp-buttons-call-45-followup-payload-echo.txt`
+- `captures/rcp-buttons-call-45-followup-exact-echo.txt`
+
+Observed result:
+
+| Test | Follow-up sent after `07 80 45 20 D0 68` | Serial result |
+| --- | --- | --- |
+| F1 generic ACK | `00 00 45 00 80 9F` | heartbeat only after follow-up |
+| F2 payload echo | `00 00 45 20 D0 EF` | heartbeat only after follow-up |
+| F3 exact echo | `07 80 45 20 D0 68` | heartbeat only after follow-up |
+
+Notes:
+
+- F1 and F2 reproduced the normal CALL-high echo path, then sent the follow-up
+  frame after the RCP emitted `07 80 45 20 D0 68`.
+- F3 still reproduced `07 80 45 20 D0 68`, but the triggering CALL event was
+  captured as a split CALL-off frame rather than a clean CALL-on log line. The
+  script's rolling buffer still recognized the frame and sent the configured
+  responses.
+- None of the three follow-up shapes caused a visible serial-side state change
+  in the captured data. After the follow-up, the RCP returned to heartbeat.
+
+Interpretation:
+
+- The `0x45` frame is likely an RCP-origin response/notification in the CALL
+  event path, but these simple host answers are not the missing activation
+  handshake.
+- The panel may not expect a direct answer to `0x45`, or the answer needs more
+  session context than a single command frame.
+- Since `0x45` can be produced from the CALL-off side too, the RCP may be
+  responding to a CALL state transition sequence rather than specifically to
+  CALL high.
+
+Next direction:
+
+- Use the reproducible CALL echo/gap sequence as a diagnostic, but return to
+  the main activation problem: what host/session traffic makes the RCP leave
+  `CONNECT NOT ACT`.
+- Test whether a known discovery query still works immediately after the CALL
+  `0x45` path, and whether CALL `0x45` changes the one-shot/latch behavior.
+
+CALL then discovery query:
+
+```powershell
+python scripts/serial_button_response_test.py --port COM5 --duration 15 --prompt --respond-to-call --respond-once --response-delay 0.05 --response-frame-interval 0.05 --response-frame "00 00 15 80 00 CF" --response-frame "00 00 15 00 00 4F" --watch-frame "07 80 45 20 D0 68" --followup-on-watch-frame --followup-frame "00 00 00 00 80 DA" --followup-frame "00 00 B5 00 80 6F" --log captures/rcp-buttons-call-45-followup-discovery-b5.txt
+```
+
+If this produces the known `B5` response `07 80 6D 20 D8 48`, then the CALL
+path does not consume the one-shot discovery response. If it returns heartbeat
+only, CALL/`0x45` may put the RCP into a similar one-shot consumed state.