pcb

.gitattributes

@@ -1 +1,2 @@
 *.pdf filter=lfs diff=lfs merge=lfs -text
+.png filter=lfs diff=lfs merge=lfs -text

captures/rcp-he33-90-644030-with-heartbeat.txt

@@ -0,0 +1,28 @@
+Sequence probe: 7 frames x 1 group(s) on COM5 at 38400 8N1
+FRAME 1: 00 00 90 00 80 4A
+FRAME 2: 00 00 90 00 80 4A
+FRAME 3: 00 00 64 40 30 0E
+FRAME 4: 00 00 00 00 80 DA
+FRAME 5: 00 00 64 40 30 0E
+FRAME 6: 00 00 00 00 80 DA
+FRAME 7: 00 00 64 40 30 0E
+BASELINE heartbeat-compatible RX: 6 bytes, offset 0, 1 frames + 0 bytes
+BEGIN group 1/1
+21:57:19.772  TX group=1 frame=1 len=006  00 00 90 00 80 4A
+21:57:19.772  RX group=1 frame=1 no RX bytes
+21:57:20.177  TX group=1 frame=2 len=006  00 00 90 00 80 4A
+21:57:20.177  RX group=1 frame=2 ANOMALY 18 RX bytes; first mismatch at byte 6: got 07, heartbeat offset 0 expected 00
+21:57:20.177  RX group=1 frame=2 raw 00 00 00 00 80 DA 07 80 64 40 30 C9 07 80 64 40 30 C9
+21:57:20.613  TX group=1 frame=3 len=006  00 00 64 40 30 0E
+21:57:20.613  RX group=1 frame=3 ANOMALY 12 RX bytes; first mismatch at byte 0: got 07, heartbeat offset 0 expected 00
+21:57:20.613  RX group=1 frame=3 raw 07 80 64 40 30 C9 00 00 00 00 80 DA
+21:57:21.047  TX group=1 frame=4 len=006  00 00 00 00 80 DA
+21:57:21.047  RX group=1 frame=4 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
+21:57:21.450  TX group=1 frame=5 len=006  00 00 64 40 30 0E
+21:57:21.450  RX group=1 frame=5 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
+21:57:21.854  TX group=1 frame=6 len=006  00 00 00 00 80 DA
+21:57:21.854  RX group=1 frame=6 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
+21:57:22.257  TX group=1 frame=7 len=006  00 00 64 40 30 0E
+21:57:22.257  RX group=1 frame=7 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
+GROUP 1 TAIL heartbeat-compatible RX: 54 bytes, offset 0, 9 frames + 0 bytes
+Anomalies: 2

captures/rcp-he33-90-then-644030.txt

@@ -0,0 +1,25 @@
+Sequence probe: 6 frames x 1 group(s) on COM5 at 38400 8N1
+FRAME 1: 00 00 90 00 80 4A
+FRAME 2: 00 00 90 00 80 4A
+FRAME 3: 00 00 64 40 30 0E
+FRAME 4: 00 00 64 40 30 0E
+FRAME 5: 00 00 64 40 30 0E
+FRAME 6: 00 00 64 40 30 0E
+BASELINE heartbeat-compatible RX: 6 bytes, offset 0, 1 frames + 0 bytes
+BEGIN group 1/1
+21:55:33.852  TX group=1 frame=1 len=006  00 00 90 00 80 4A
+21:55:33.852  RX group=1 frame=1 no RX bytes
+21:55:34.256  TX group=1 frame=2 len=006  00 00 90 00 80 4A
+21:55:34.256  RX group=1 frame=2 ANOMALY 12 RX bytes; first mismatch at byte 6: got 07, heartbeat offset 0 expected 00
+21:55:34.256  RX group=1 frame=2 raw 00 00 00 00 80 DA 07 80 64 40 30 C9
+21:55:34.662  TX group=1 frame=3 len=006  00 00 64 40 30 0E
+21:55:34.662  RX group=1 frame=3 ANOMALY 12 RX bytes; first mismatch at byte 0: got 07, heartbeat offset 0 expected 00
+21:55:34.662  RX group=1 frame=3 raw 07 80 64 40 30 C9 00 00 00 00 80 DA
+21:55:35.066  TX group=1 frame=4 len=006  00 00 64 40 30 0E
+21:55:35.066  RX group=1 frame=4 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
+21:55:35.500  TX group=1 frame=5 len=006  00 00 64 40 30 0E
+21:55:35.500  RX group=1 frame=5 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
+21:55:35.903  TX group=1 frame=6 len=006  00 00 64 40 30 0E
+21:55:35.903  RX group=1 frame=6 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
+GROUP 1 TAIL heartbeat-compatible RX: 48 bytes, offset 0, 8 frames + 0 bytes
+Anomalies: 2

captures/rcp-he33-90-then-e44030.txt

@@ -0,0 +1,25 @@
+Sequence probe: 6 frames x 1 group(s) on COM5 at 38400 8N1
+FRAME 1: 00 00 90 00 80 4A
+FRAME 2: 00 00 90 00 80 4A
+FRAME 3: 00 00 E4 40 30 8E
+FRAME 4: 00 00 E4 40 30 8E
+FRAME 5: 00 00 E4 40 30 8E
+FRAME 6: 00 00 E4 40 30 8E
+BASELINE heartbeat-compatible RX: 6 bytes, offset 0, 1 frames + 0 bytes
+BEGIN group 1/1
+21:55:54.727  TX group=1 frame=1 len=006  00 00 90 00 80 4A
+21:55:54.727  RX group=1 frame=1 no RX bytes
+21:55:55.130  TX group=1 frame=2 len=006  00 00 90 00 80 4A
+21:55:55.130  RX group=1 frame=2 ANOMALY 12 RX bytes; first mismatch at byte 6: got 07, heartbeat offset 0 expected 00
+21:55:55.130  RX group=1 frame=2 raw 00 00 00 00 80 DA 07 80 64 40 30 C9
+21:55:55.565  TX group=1 frame=3 len=006  00 00 E4 40 30 8E
+21:55:55.565  RX group=1 frame=3 ANOMALY 12 RX bytes; first mismatch at byte 0: got 07, heartbeat offset 0 expected 00
+21:55:55.565  RX group=1 frame=3 raw 07 80 64 40 30 C9 00 00 00 00 80 DA
+21:55:55.968  TX group=1 frame=4 len=006  00 00 E4 40 30 8E
+21:55:55.968  RX group=1 frame=4 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
+21:55:56.372  TX group=1 frame=5 len=006  00 00 E4 40 30 8E
+21:55:56.372  RX group=1 frame=5 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
+21:55:56.775  TX group=1 frame=6 len=006  00 00 E4 40 30 8E
+21:55:56.775  RX group=1 frame=6 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
+GROUP 1 TAIL heartbeat-compatible RX: 54 bytes, offset 0, 9 frames + 0 bytes
+Anomalies: 2

captures/rcp-he33-a0-90-then-644030.txt

@@ -0,0 +1,27 @@
+Sequence probe: 7 frames x 1 group(s) on COM5 at 38400 8N1
+FRAME 1: 00 00 A0 00 80 7A
+FRAME 2: 00 00 90 00 80 4A
+FRAME 3: 00 00 64 40 30 0E
+FRAME 4: 00 00 64 40 30 0E
+FRAME 5: 00 00 64 40 30 0E
+FRAME 6: 00 00 00 00 80 DA
+FRAME 7: 00 00 64 40 30 0E
+BASELINE heartbeat-compatible RX: 6 bytes, offset 0, 1 frames + 0 bytes
+BEGIN group 1/1
+21:56:29.044  TX group=1 frame=1 len=006  00 00 A0 00 80 7A
+21:56:29.044  RX group=1 frame=1 no RX bytes
+21:56:29.448  TX group=1 frame=2 len=006  00 00 90 00 80 4A
+21:56:29.448  RX group=1 frame=2 ANOMALY 6 RX bytes; first mismatch at byte 0: got 07, heartbeat offset 3 expected 00
+21:56:29.448  RX group=1 frame=2 raw 07 80 64 40 30 C9
+21:56:29.853  TX group=1 frame=3 len=006  00 00 64 40 30 0E
+21:56:29.853  RX group=1 frame=3 no RX bytes
+21:56:30.255  TX group=1 frame=4 len=006  00 00 64 40 30 0E
+21:56:30.255  RX group=1 frame=4 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
+21:56:30.688  TX group=1 frame=5 len=006  00 00 64 40 30 0E
+21:56:30.688  RX group=1 frame=5 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
+21:56:31.092  TX group=1 frame=6 len=006  00 00 00 00 80 DA
+21:56:31.092  RX group=1 frame=6 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
+21:56:31.495  TX group=1 frame=7 len=006  00 00 64 40 30 0E
+21:56:31.495  RX group=1 frame=7 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
+GROUP 1 TAIL heartbeat-compatible RX: 48 bytes, offset 0, 8 frames + 0 bytes
+Anomalies: 1

captures/rcp-he33-a0-af-then-0d04ab.txt

@@ -0,0 +1,31 @@
+Sequence probe: 7 frames x 1 group(s) on COM5 at 38400 8N1
+FRAME 1: 00 00 A0 00 80 7A
+FRAME 2: 00 00 AF 00 80 75
+FRAME 3: 00 00 0D 04 AB F8
+FRAME 4: 00 00 0D 04 AB F8
+FRAME 5: 00 00 0D 04 AB F8
+FRAME 6: 00 00 00 00 80 DA
+FRAME 7: 00 00 0D 04 AB F8
+BASELINE heartbeat-compatible RX: 6 bytes, offset 0, 1 frames + 0 bytes
+BEGIN group 1/1
+21:57:05.146  TX group=1 frame=1 len=006  00 00 A0 00 80 7A
+21:57:05.146  RX group=1 frame=1 no RX bytes
+21:57:05.557  TX group=1 frame=2 len=006  00 00 AF 00 80 75
+21:57:05.557  RX group=1 frame=2 ANOMALY 18 RX bytes; first mismatch at byte 6: got 07, heartbeat offset 0 expected 00
+21:57:05.557  RX group=1 frame=2 raw 00 00 00 00 80 DA 07 80 0D 04 AB 7F 07 80 0D 04 AB 7F
+21:57:05.961  TX group=1 frame=3 len=006  00 00 0D 04 AB F8
+21:57:05.961  RX group=1 frame=3 ANOMALY 6 RX bytes; first mismatch at byte 0: got 07, heartbeat offset 3 expected 00
+21:57:05.961  RX group=1 frame=3 raw 07 80 0D 04 AB 7F
+21:57:06.394  TX group=1 frame=4 len=006  00 00 0D 04 AB F8
+21:57:06.394  RX group=1 frame=4 ANOMALY 12 RX bytes; first mismatch at byte 0: got 07, heartbeat offset 3 expected 00
+21:57:06.394  RX group=1 frame=4 raw 07 80 0D 04 AB 7F 07 80 0D 04 AB 7F
+21:57:06.827  TX group=1 frame=5 len=006  00 00 0D 04 AB F8
+21:57:06.827  RX group=1 frame=5 ANOMALY 12 RX bytes; first mismatch at byte 0: got 07, heartbeat offset 3 expected 00
+21:57:06.827  RX group=1 frame=5 raw 07 80 0D 04 AB 7F 07 80 0D 04 AB 7F
+21:57:07.231  TX group=1 frame=6 len=006  00 00 00 00 80 DA
+21:57:07.231  RX group=1 frame=6 ANOMALY 12 RX bytes; first mismatch at byte 0: got 07, heartbeat offset 0 expected 00
+21:57:07.231  RX group=1 frame=6 raw 07 80 0D 04 AB 7F 00 00 00 00 80 DA
+21:57:07.635  TX group=1 frame=7 len=006  00 00 0D 04 AB F8
+21:57:07.635  RX group=1 frame=7 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
+GROUP 1 TAIL heartbeat-compatible RX: 42 bytes, offset 0, 7 frames + 0 bytes
+Anomalies: 5

captures/rcp-he33-af-0d04eb-with-heartbeat.txt

@@ -0,0 +1,28 @@
+Sequence probe: 7 frames x 1 group(s) on COM5 at 38400 8N1
+FRAME 1: 00 00 AF 00 80 75
+FRAME 2: 00 00 AF 00 80 75
+FRAME 3: 00 00 0D 04 EB B8
+FRAME 4: 00 00 00 00 80 DA
+FRAME 5: 00 00 0D 04 EB B8
+FRAME 6: 00 00 00 00 80 DA
+FRAME 7: 00 00 0D 04 EB B8
+BASELINE heartbeat-compatible RX: 6 bytes, offset 0, 1 frames + 0 bytes
+BEGIN group 1/1
+21:57:34.136  TX group=1 frame=1 len=006  00 00 AF 00 80 75
+21:57:34.136  RX group=1 frame=1 no RX bytes
+21:57:34.539  TX group=1 frame=2 len=006  00 00 AF 00 80 75
+21:57:34.539  RX group=1 frame=2 ANOMALY 12 RX bytes; first mismatch at byte 6: got 07, heartbeat offset 0 expected 00
+21:57:34.539  RX group=1 frame=2 raw 00 00 00 00 80 DA 07 80 0D 04 AB 7F
+21:57:34.945  TX group=1 frame=3 len=006  00 00 0D 04 EB B8
+21:57:34.945  RX group=1 frame=3 ANOMALY 12 RX bytes; first mismatch at byte 0: got 07, heartbeat offset 0 expected 00
+21:57:34.945  RX group=1 frame=3 raw 07 80 0D 04 AB 7F 00 00 00 00 80 DA
+21:57:35.349  TX group=1 frame=4 len=006  00 00 00 00 80 DA
+21:57:35.349  RX group=1 frame=4 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
+21:57:35.782  TX group=1 frame=5 len=006  00 00 0D 04 EB B8
+21:57:35.782  RX group=1 frame=5 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
+21:57:36.185  TX group=1 frame=6 len=006  00 00 00 00 80 DA
+21:57:36.185  RX group=1 frame=6 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
+21:57:36.588  TX group=1 frame=7 len=006  00 00 0D 04 EB B8
+21:57:36.588  RX group=1 frame=7 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
+GROUP 1 TAIL heartbeat-compatible RX: 54 bytes, offset 0, 9 frames + 0 bytes
+Anomalies: 2

captures/rcp-he33-af-then-0d04eb.txt

@@ -0,0 +1,25 @@
+Sequence probe: 6 frames x 1 group(s) on COM5 at 38400 8N1
+FRAME 1: 00 00 AF 00 80 75
+FRAME 2: 00 00 AF 00 80 75
+FRAME 3: 00 00 0D 04 EB B8
+FRAME 4: 00 00 0D 04 EB B8
+FRAME 5: 00 00 0D 04 EB B8
+FRAME 6: 00 00 0D 04 EB B8
+BASELINE heartbeat-compatible RX: 6 bytes, offset 0, 1 frames + 0 bytes
+BEGIN group 1/1
+21:56:43.107  TX group=1 frame=1 len=006  00 00 AF 00 80 75
+21:56:43.107  RX group=1 frame=1 no RX bytes
+21:56:43.511  TX group=1 frame=2 len=006  00 00 AF 00 80 75
+21:56:43.511  RX group=1 frame=2 ANOMALY 18 RX bytes; first mismatch at byte 6: got 07, heartbeat offset 0 expected 00
+21:56:43.511  RX group=1 frame=2 raw 00 00 00 00 80 DA 07 80 0D 04 AB 7F 07 80 0D 04 AB 7F
+21:56:43.916  TX group=1 frame=3 len=006  00 00 0D 04 EB B8
+21:56:43.916  RX group=1 frame=3 ANOMALY 12 RX bytes; first mismatch at byte 0: got 07, heartbeat offset 0 expected 00
+21:56:43.916  RX group=1 frame=3 raw 07 80 0D 04 AB 7F 00 00 00 00 80 DA
+21:56:44.319  TX group=1 frame=4 len=006  00 00 0D 04 EB B8
+21:56:44.319  RX group=1 frame=4 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
+21:56:44.754  TX group=1 frame=5 len=006  00 00 0D 04 EB B8
+21:56:44.754  RX group=1 frame=5 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
+21:56:45.189  TX group=1 frame=6 len=006  00 00 0D 04 EB B8
+21:56:45.189  RX group=1 frame=6 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
+GROUP 1 TAIL heartbeat-compatible RX: 54 bytes, offset 0, 9 frames + 0 bytes
+Anomalies: 2

docs/README.md

@@ -21,6 +21,8 @@ service information, diagrams, related devices, and compatibility notes.
 - [PT2 State Map](pt2-state-map.md) - working protocol-state map showing current
   selector/context branches, downstream response families, and likely state
   transitions.
+- [PCB Notes](pcb-notes.md) - board-level observations, identified components,
+  connector tracing leads, and hardware-side restoration notes.
 
 ## High-Value Starting Points
 

docs/discovery-notes.md

@@ -7686,6 +7686,260 @@ It may still require:
 - a missing hardware/state signal on another wire
 - or a specific startup family we have touched indirectly but not yet maintained
 
+### HE33: Maintain The Startup-Beacon Families
+
+Goal:
+
+- Follow the strongest new HE32 clue directly.
+- Treat the startup-beacon families as possible **maintained classes** rather
+  than merely one-shot opening responses.
+
+Working idea:
+
+- `90` and `AF` increasingly look like startup beacons or mode/class selectors.
+- In HE32 we immediately switched from those beacon effects into `E8`/`EC` page
+  traffic.
+- That may have been too eager.
+- Instead, try:
+  - open `64 40 30 C9`, `E4 40 30 49`, `0D 04 AB 7F`, or `0D 04 EB 3F`
+  - then maintain **that class**
+  - and only optionally add heartbeat alongside it
+
+What would count as a hit:
+
+- the startup family reappears or stays reusable
+- a new recurring non-heartbeat family appears later in the same run
+- the panel visibly changes state
+- `CONNECT NOT ACT` behavior changes while the maintained class is running
+
+Checksums for host-shaped maintained-class frames:
+
+- host `64 40 30` -> `00 00 64 40 30 0E`
+- host `E4 40 30` -> `00 00 E4 40 30 8E`
+- host `0D 04 AB` -> `00 00 0D 04 AB F8`
+- host `0D 04 EB` -> `00 00 0D 04 EB B8`
+
+#### HE33a: Repeated `90` beacon, then maintain `64 40 30`
+
+Hypothesis:
+
+- `64 40 30` may be the real maintained class after `90`, not an intermediate
+  page on the way to `E8`.
+
+```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 64 40 30 0E" --frame "00 00 64 40 30 0E" --frame "00 00 64 40 30 0E" --frame "00 00 64 40 30 0E" --read-after-frame 0.15 --frame-interval 0.25 --read-after-group 3.0 --log captures/rcp-he33-90-then-644030.txt
+```
+
+#### HE33b: Repeated `90` beacon, then maintain `E4 40 30`
+
+Hypothesis:
+
+- The alternate `90` beacon branch may want `E4 40 30` as its maintained class.
+
+```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 E4 40 30 8E" --frame "00 00 E4 40 30 8E" --frame "00 00 E4 40 30 8E" --frame "00 00 E4 40 30 8E" --read-after-frame 0.15 --frame-interval 0.25 --read-after-group 3.0 --log captures/rcp-he33-90-then-e44030.txt
+```
+
+#### HE33c: `A0 -> 90`, then maintain `64 40 30`
+
+Hypothesis:
+
+- `A0 -> 90` may be a more deterministic way to enter the `64 40 30` startup
+  family than bare repeated `90`.
+
+```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 64 40 30 0E" --frame "00 00 64 40 30 0E" --frame "00 00 64 40 30 0E" --frame "00 00 00 00 80 DA" --frame "00 00 64 40 30 0E" --read-after-frame 0.15 --frame-interval 0.25 --read-after-group 3.0 --log captures/rcp-he33-a0-90-then-644030.txt
+```
+
+#### HE33d: Repeated `AF` beacon, then maintain `0D 04 EB`
+
+Hypothesis:
+
+- The repeated-`AF` startup branch may want the `0D 04 EB` class maintained.
+
+```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 0D 04 EB B8" --frame "00 00 0D 04 EB B8" --frame "00 00 0D 04 EB B8" --frame "00 00 0D 04 EB B8" --read-after-frame 0.15 --frame-interval 0.25 --read-after-group 3.0 --log captures/rcp-he33-af-then-0d04eb.txt
+```
+
+#### HE33e: `A0 -> AF`, then maintain `0D 04 AB`
+
+Hypothesis:
+
+- `A0 -> AF` may open a slightly different startup/status class than repeated
+  `AF`, and it may want `0D 04 AB` instead of `0D 04 EB`.
+
+```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 0D 04 AB F8" --frame "00 00 0D 04 AB F8" --frame "00 00 0D 04 AB F8" --frame "00 00 00 00 80 DA" --frame "00 00 0D 04 AB F8" --read-after-frame 0.15 --frame-interval 0.25 --read-after-group 3.0 --log captures/rcp-he33-a0-af-then-0d04ab.txt
+```
+
+#### HE33f: `90` startup family with heartbeat interleaved
+
+Hypothesis:
+
+- The maintained class may still need a low-rate host-presence heartbeat beside
+  it, even if the page-class itself is the important thing.
+
+```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 64 40 30 0E" --frame "00 00 00 00 80 DA" --frame "00 00 64 40 30 0E" --frame "00 00 00 00 80 DA" --frame "00 00 64 40 30 0E" --read-after-frame 0.15 --frame-interval 0.25 --read-after-group 3.0 --log captures/rcp-he33-90-644030-with-heartbeat.txt
+```
+
+#### HE33g: `AF` startup family with heartbeat interleaved
+
+Hypothesis:
+
+- Same logic as above, but for the `AF`-derived startup family.
+
+```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 0D 04 EB B8" --frame "00 00 00 00 80 DA" --frame "00 00 0D 04 EB B8" --frame "00 00 00 00 80 DA" --frame "00 00 0D 04 EB B8" --read-after-frame 0.15 --frame-interval 0.25 --read-after-group 3.0 --log captures/rcp-he33-af-0d04eb-with-heartbeat.txt
+```
+
+Recommended order:
+
+1. `HE33a` repeated `90`, then `64 40 30`
+2. `HE33c` `A0 -> 90`, then `64 40 30`
+3. `HE33d` repeated `AF`, then `0D 04 EB`
+4. `HE33e` `A0 -> AF`, then `0D 04 AB`
+5. `HE33f` `90` family with heartbeat
+6. `HE33g` `AF` family with heartbeat
+7. `HE33b` repeated `90`, then `E4 40 30`
+
+Reasoning:
+
+- `64 40 30` looks like the strongest `90`-side startup family so far.
+- `0D 04 AB/EB` is the matching `AF`-side family.
+- The cleanest question first is simply:
+  can maintaining those classes do anything at all?
+
+### HE33 Results
+
+Practical outcome:
+
+- No visible panel wake-up.
+- No useful LCD change beyond the already familiar inactive behavior.
+- Maintaining the startup-beacon families did **not** turn them into live
+  reusable session classes.
+
+Serial outcome:
+
+- The beacon families themselves are real and reproducible.
+- But once opened, host-shaped maintenance of those same families mostly just
+  drained the initial one-shot response and then fell back to
+  heartbeat-compatible traffic.
+
+#### HE33a: repeated `90`, then maintain `64 40 30`
+
+Observed:
+
+- second `90` produced:
+  - `07 80 64 40 30 C9`
+- first host `64 40 30` produced one more:
+  - `07 80 64 40 30 C9`
+- later host `64 40 30` frames were heartbeat-compatible only
+
+Interpretation:
+
+- `64 40 30` is a real startup-family surface.
+- But simply maintaining host `64 40 30` does not keep that branch open.
+
+#### HE33b: repeated `90`, then maintain `E4 40 30`
+
+Observed:
+
+- repeated `90` still opened:
+  - `07 80 64 40 30 C9`
+- host `E4 40 30` did **not** pivot it into a stable `E4`-maintained state
+- later traffic was heartbeat-compatible only
+
+Interpretation:
+
+- The `90` beacon can still prefer `64` on this run.
+- Host `E4 40 30` did not make the alternate `E4` startup family reusable.
+
+#### HE33c: `A0 -> 90`, then maintain `64 40 30`
+
+Observed:
+
+- `A0 -> 90` produced:
+  - `07 80 64 40 30 C9`
+- later host `64 40 30` frames were heartbeat-compatible only
+
+Interpretation:
+
+- `A0 -> 90` is still a clean opener for the `64` family.
+- But, again, the family did not become maintainable as a live background
+  class.
+
+#### HE33d: repeated `AF`, then maintain `0D 04 EB`
+
+Observed:
+
+- repeated `AF` produced:
+  - `07 80 0D 04 AB 7F`
+  - `07 80 0D 04 AB 7F`
+- first host `0D 04 EB` drained one more:
+  - `07 80 0D 04 AB 7F`
+- later host `0D 04 EB` frames were heartbeat-compatible only
+
+Interpretation:
+
+- On this run, repeated `AF` did **not** prefer the older `EB`-suffixed
+  startup family; it stayed on the `AB` family instead.
+- That makes the `AF` startup side look more slippery than the `90` side.
+
+#### HE33e: `A0 -> AF`, then maintain `0D 04 AB`
+
+Observed:
+
+- `A0 -> AF` produced repeated:
+  - `07 80 0D 04 AB 7F`
+- host `0D 04 AB` continued to drain more `AB` responses briefly
+- then the run collapsed back to heartbeat-compatible traffic
+
+Interpretation:
+
+- `A0 -> AF` remains the cleanest opener for the `AB` startup family.
+- It is stronger than the bare repeated-`AF` case, but still not enough to
+  create a sustained live session layer.
+
+#### HE33f: `90` family with heartbeat interleaved
+
+Observed:
+
+- repeated `90` produced:
+  - `07 80 64 40 30 C9`
+  - `07 80 64 40 30 C9`
+- host `64 40 30` plus heartbeat still fell back to heartbeat-compatible
+  traffic after that
+
+Interpretation:
+
+- Interleaving heartbeat did not make the `64` family maintainable.
+
+#### HE33g: `AF` family with heartbeat interleaved
+
+Observed:
+
+- repeated `AF` produced:
+  - `07 80 0D 04 AB 7F`
+- host `0D 04 EB` plus heartbeat did not reopen a live `EB`/`AB` maintained
+  branch
+
+Interpretation:
+
+- Heartbeat beside the `AF` startup family also did not help.
+
+HE33 conclusion:
+
+- The `90`/`AF` startup-beacon families are real, but they still behave like
+  one-shot startup surfaces rather than the missing maintained wake/session
+  stream.
+- `90` is the cleaner side:
+  - it repeatedly lands on `64 40 30`
+- `AF` is the sloppier side:
+  - it can land on `AB` or `EB`, and on this pass it mostly preferred `AB`
+- Maintaining those family classes directly did not wake the panel, did not
+  make later traffic reusable, and did not create a stable active state.
+
 ### 2026-05-13 CAM POWER Context Retests
 
 Goal:

docs/pcb-notes.md

@@ -0,0 +1,573 @@
+# RCP-TX7 PCB Notes
+
+These notes track direct physical observations from inside the Sony RCP-TX7.
+They are intentionally separate from the PT2 protocol notes, because the board
+layout and component choices may explain what the serial experiments alone do
+not.
+
+## Current Physical Overview
+
+- The RCP appears to be split into **two circuit boards**.
+- One board looks like a **front-panel / operator interface board**:
+  - button matrix
+  - lamps / indicators
+  - LCD support
+  - mostly resistors and small logic
+  - many TI `HC595A`-family or similar shift-register-style chips
+- That board connects through an intermediate link to a second board.
+- The second board appears to be the **main logic / controller board**:
+  - single-sided
+  - carries the main digital devices
+  - appears to contain the actual control logic / firmware for the RCP
+
+## Connector / Wiring Observations
+
+- The main logic board has an **8-pin connector** associated with the external
+  10-pin plug/cable assembly.
+- The **wire colors inside the RCP do not match** the cable color mapping noted
+  earlier from the cable itself.
+- This means:
+  - internal color cannot be trusted as a one-to-one continuation of external
+    cable color
+  - the board-side harness should be mapped by continuity, not by color
+
+## Identified Components
+
+Observed on the main logic board:
+
+- `Sanyo LC3564BM-10`
+- `XICOR X20C05J-55 9926`
+- `27C512 RCPTX7 V1.05 SONY98`
+  - socketed / clip-retained
+  - appears user-replaceable
+  - additional marking observed: `0047K`
+- `H8/536 HD`
+- full observed line-by-line marking on the main controller:
+  - small logo resembling a target / concentric mark
+  - `H8/536`
+  - `1B1     A`
+  - `HD`
+  - `6435368F  16`
+  - `W34 JAPAN`
+- several smaller TI logic ICs with varying markings
+
+## Firmware Cluster Photo Notes
+
+From the close-up photo of the firmware area:
+
+- the firmware device is an **ST** `M27C512-10F1` family EPROM/OTP-style part
+  carrying the Sony application label:
+  - `27C512`
+  - `RCPTX7`
+  - `V1.05`
+  - `©SONY98`
+- the package-side marking also shows:
+  - `M27C512`
+  - `10F1`
+  - `58826`
+  - `0047K`
+  - `SINGAPORE`
+- the ROM is installed in a **socket**, which strongly supports the idea that
+  the firmware can be removed and dumped without desoldering
+- the `XICOR X20C05J-55` sits immediately beside the firmware device
+- the `LC3564BM-10` sits directly above the firmware area
+
+This creates a very plausible classic memory cluster:
+
+- EPROM = program storage
+- SRAM = working memory
+- Xicor NVRAM/EEPROM = retained setup/configuration data
+
+## Silkscreen Clarifications From Photo
+
+The close-up suggests a couple of earlier markings may need cautious reading:
+
+- the vertical marking beside the ROM socket still looks like
+  `CNI12` / `CN112`-like text and should be rechecked carefully from the board
+  itself
+- `RV1` appears near an **unpopulated footprint** below the ROM area
+  rather than clearly identifying the ROM itself
+
+So, for now:
+
+- treat `RV1` as a likely local board reference near that empty footprint
+- do not treat `RV1` as the firmware module identifier
+
+## Additional Photo-Backed Board Observations
+
+From the newer board photos:
+
+### Internal Harness Connector
+
+- the internal board connector is silked as **`CN1`**
+- it is an **8-pin connector**
+- the visible wire colors at this connector appear to be:
+  - red
+  - brown
+  - white
+  - orange
+  - yellow
+  - gray
+  - blue
+  - black
+- this reinforces the earlier point that the internal harness color order does
+  **not** match the earlier external cable-color assumptions
+
+Useful implication:
+
+- `CN1` is now the strongest candidate for the board-side harness/IO connector
+  that should be traced against the external 10-pin cable assembly
+
+### H8 / DIP Area
+
+- the H8 marking is now clearly readable in-package as:
+  - `H8/536`
+  - `HD`
+  - `6435368F16`
+  - `W34 JAPAN`
+- the DIP switches `S2` and `S3` are clearly visible above the H8
+- the switches show an `ON` legend on one side, which will help keep bit
+  numbering consistent during testing
+- the pin-number silkscreen around the H8 is clearly printed, which supports
+  the earlier observation that the DIP banks land in the `43-50` region
+
+### Likely `S1` Footprint
+
+- one photo shows an **unpopulated circular-pad footprint** labeled `S1`
+- this is important because it suggests:
+  - `S1` was not "missing from our search" by accident
+  - it may be an intentionally unpopulated switch or selector position on this
+    board revision
+  - Sony may have designed this PCB for multiple variants/options
+
+This makes the earlier "no visible `S1`" mystery much less mysterious.
+
+### Board / Assembly Markings
+
+- one photo shows a boxed marking:
+  - `A-8315`
+  - `-095-A`
+- there is also a small sticker:
+  - `2A1`
+
+Working interpretation:
+
+- `A-8315-095-A` is very likely a Sony board or assembly identifier
+- `2A1` may be an inspection, revision, or production tracking sticker
+
+### Additional Logic / Glue Area
+
+- one of the smaller TI chips in the photo area is marked `HC74A`
+- this is consistent with ordinary glue logic / state / timing support around
+  the CPU rather than with a second major processor
+- nearby resistor-network and option-footprint areas also fit the picture of a
+  configurable CPU/control board with variant population options
+
+## Additional Silkscreen / Board Markings
+
+Observed so far:
+
+- possible connector / reference markings:
+  - `RV1`
+  - `CNI12`
+- near the `H8/536`:
+  - `CNI50`
+- DIP switches:
+  - `S2`
+  - `S3`
+- board label:
+  - `EP-(GW+GN)`
+- large board text:
+  - `CPU-345`
+- board appears visually split into quadrants
+- the main custom Sony chip appears to sit in:
+  - `B-2`
+
+## Initial Interpretation
+
+These are working interpretations, not yet final identifications.
+
+- `27C512 RCPTX7 V1.05 SONY98`
+  - very likely the panel firmware EPROM
+  - the `V1.05` label strongly suggests a firmware revision
+  - the socketed mounting is very useful for restoration and dumping
+- `H8/536 HD`
+  - likely the main microcontroller or one of the main controllers
+  - especially likely given that the DIP switches reportedly connect to it
+  - the full observed marking is consistent with a Hitachi `HD6435368F`
+    H8-family MCU
+- `X20C05`
+  - likely nonvolatile storage for configuration / calibration / retained setup
+- `LC3564BM-10`
+  - likely RAM or working memory associated with the controller/firmware
+- TI `HC595A`-style parts on the front board
+  - consistent with lamp, display, or scanned front-panel I/O expansion
+
+Additional interpretation from the newer markings:
+
+- `0047K` on the EPROM may be:
+  - an internal Sony build/program label
+  - a batch/date/option code
+  - or a board/personality identifier tied to this firmware image
+- `CPU-345` strongly suggests this board is treated by Sony as a CPU/control
+  board assembly rather than only an interface board
+- `B-2` may be a board-coordinate locator, which could help if a service manual
+  or board overlay ever turns up
+- `CNI12` and `CNI50` both look more like connector/reference designators than
+  component values
+- `RV1` is ambiguous:
+  - often that would imply a variable resistor / trim pot
+  - but if the silkscreen is hard to read, it is worth re-checking because it
+    may instead be another connector or reference prefix
+- the `H8/536` line-by-line marking strongly suggests the main CPU is not a
+  Sony custom controller but a member of the Hitachi H8 family, with Sony
+  firmware and surrounding glue logic providing the product-specific behavior
+- the `16` suffix likely indicates a speed grade / variant marker rather than a
+  board reference
+- the `JAPAN` marking fits an original Japanese-manufactured MCU package
+
+## Cross-Equipment Clue
+
+- The RM-M7G reportedly contains a chip with the same target-like logo and
+  `JAPAN` marking from the same apparent manufacturer family.
+
+Why this matters:
+
+- the RCP-TX7 and RM-M7G may share a similar controller platform philosophy
+- they may use related H8-family firmware architecture even if the surrounding
+  hardware and protocol behavior differ
+- this strengthens the idea that DIP-config, ROM content, and NVRAM content may
+  matter as much as the raw serial traffic itself
+
+## DIP Switches
+
+- There are **two 4-position DIP switches**
+- All switches are currently **off**
+- One side of each DIP bank appears tied together
+- They appear to act as **ground sinks / pull-to-ground configuration inputs**
+- They reportedly connect to the `H8/536`
+- The DIP switch reference designators are:
+  - `S2`
+  - `S3`
+- Based on the silkscreen tracing, the DIP switches connect to
+  **pins 43 through 50**
+
+This makes them likely candidates for:
+
+- panel address / ID selection
+- mode or personality selection
+- service / factory configuration
+- communication mode selection
+
+Notable oddity:
+
+- no obvious `S1` has been found yet
+
+That could mean:
+
+- `S1` exists on another board
+- `S1` is an unpopulated option on this revision
+- `S1` is present but hidden/obscured
+- Sony numbering simply did not start at `S1` on this assembly
+
+Why the `43-50` range matters:
+
+- eight switch positions feeding a contiguous pin range is exactly what you
+  would expect for a boot-time configuration byte or bitfield
+- that makes `S2` + `S3` look less like analog trims and more like true digital
+  mode/config inputs
+- if those really are `H8/536` pins, they may be read very early at reset or
+  power-up
+
+Current best interpretation of the DIP banks:
+
+- together they likely form an **8-bit configuration field**
+- likely uses pull-ups or default highs on the MCU side
+- each switch probably pulls its line low when turned on
+- possible meanings still include:
+  - panel address
+  - model/personality select
+  - PT mode / CCU compatibility mode
+  - service / factory behavior bits
+  - test/diagnostic mode
+
+## Missing / Unpopulated Components
+
+- Several components look **intentionally unpopulated**
+
+For now, assume these may be:
+
+- factory options
+- alternate hardware revisions
+- model-variant population differences
+- unused test or expansion circuitry
+
+They should not be treated as damaged/missing until compared against:
+
+- both PCB sides
+- silk labels
+- any service-manual board drawing
+- other RCP-TX7 board photos, if found later
+
+The newer photos strengthen this:
+
+- `S1` now appears to be an intentionally unpopulated footprint
+- there are at least two additional unpopulated IC footprints in the same area
+- this board very likely supported multiple build options or derivatives
+
+## Why This Matters
+
+This hardware picture is encouraging because it suggests the RCP is not just a
+"dumb front panel."
+
+It likely contains:
+
+- a real MCU (`H8/536`)
+- local firmware (`27C512`)
+- nonvolatile memory (`X20C05`)
+- a front-panel scan / display subsystem
+
+That means the panel may have:
+
+- multiple boot/configuration modes
+- stored setup or address data
+- more internal state than the serial experiments alone reveal
+
+It also makes a **firmware dump** or **DIP-switch mapping** potentially very
+high-value later.
+
+## Next Hardware Inspection Targets
+
+Highest-value things to map next:
+
+1. Exact full part markings on the `H8/536` package
+2. Exact full part markings on the `LC3564BM-10`
+3. Exact full part markings on each smaller TI logic IC near the I/O connector
+4. Continuity from the external 10-pin pins to the main-board connector pins
+   - especially through `CN1`
+5. Continuity from the serial pins (`4`, `7`, `9`, `10`) to their destination
+   chips/components
+6. Whether any of the remaining wires land on:
+   - MCU GPIO
+   - analog conditioning
+   - optocouplers
+   - comparator/op-amp circuitry
+   - transceiver/interface ICs
+7. Silk labels near the two DIP switch blocks
+   - including the exact orientation of the `ON` legend on `S2` and `S3`
+8. Any test pads labeled for:
+   - `TX`
+   - `RX`
+   - `CLK`
+   - `DATA`
+   - `RST`
+   - `ROM`
+   - `RAM`
+   - `GND`
+   - `+5V`
+   - `+12V`
+
+## Strong Next Leads
+
+Based on the current findings, the best hardware-side leads are:
+
+1. **Map the DIP switches**
+   - note silk labels
+   - test whether any switch changes startup behavior or serial responses
+   - specifically record the current `S2` / `S3` bit positions before touching
+   - if possible, determine whether the switches are read only at boot or also
+     during runtime
+2. **Dump or at least photograph the EPROM label and socket area clearly**
+   - the socketed `27C512` is one of the most promising restoration clues
+   - include the `0047K` marking in the photo record
+3. **Trace the 8-pin internal connector**
+   - identify which of those lines are serial, power, and "something else"
+4. **Identify whether the 10-pin path includes a dedicated interface chip**
+    - if not, the extra lines may go directly into the MCU or surrounding logic
+5. **Verify the likely connector references**
+   - confirm whether `CNI12` is the 8-pin internal cable header
+   - confirm whether `CNI50` refers to the H8 area, a nearby header, or another
+     assembly reference
+   - note that `CN1` is now the strongest observed silk for the internal
+     8-pin harness connector in the photos
+6. **Compare the RM-M7G controller board if possible**
+   - look for the exact MCU family/part
+   - compare ROM / EEPROM / switch architecture
+   - note whether Sony reused the same CPU platform with different front-end
+     logic
+
+## Open Questions
+
+- Is the `H8/536` definitely the primary CPU, or is there another Sony custom
+  controller sharing that role?
+- Is the socketed `27C512` the only firmware store?
+- What exactly is stored in the `X20C05`?
+- Do the DIP switches select mode, address, or board variant?
+- Do `S2`/`S3` form a single boot configuration byte across MCU pins `43-50`?
+- Do any of the non-serial wires carry required wake/session information?
+- Is there a hardware reason the panel never fully leaves `CONNECT NOT ACT`
+  under our emulated PT2 traffic?
+- What do `CPU-345`, `EP-(GW+GN)`, `CNI12`, and `CNI50` correspond to in Sony's
+  internal board naming?
+- Is `A-8315-095-A` the specific board assembly number for this CPU board?
+- Does the RM-M7G use the same H8-family controller and a similar ROM/NVRAM
+  arrangement?
+
+## DIP Switch Experiment Ladder
+
+Current known baseline:
+
+- all 8 DIP positions are currently **off**
+- switches are grouped as:
+  - `S2` = 4 positions
+  - `S3` = 4 positions
+- together they likely feed MCU pins `43-50`
+
+### Safety / Method
+
+Use this method for every DIP test:
+
+1. Photograph the current DIP positions before changing anything.
+2. Change **one switch only**.
+3. Reassemble only as much as needed for safe power-on.
+4. Power up the panel.
+5. Observe behavior **before connecting serial**.
+6. Then run the normal serial baseline checks.
+7. Power down fully before changing the next switch.
+8. Return to the all-off baseline between non-adjacent tests.
+
+Recommended observations for each run:
+
+- LCD startup text
+- whether the active light changes
+- whether `CONNECT NOT ACT` appears, and when
+- whether the idle heartbeat is still `00 00 00 00 80 DA`
+- whether known probes still behave the same:
+  - `A0`
+  - `90`
+  - `AF`
+  - `E8`
+  - `EC`
+- any new button behavior in idle state
+- any change in baud-like behavior or complete silence
+
+### Naming Convention
+
+Use a simple notation in notes/logs:
+
+- baseline = `S2=0000 S3=0000`
+- example single change:
+  - `S2=1000 S3=0000`
+  - meaning only the first `S2` switch is changed from baseline
+
+If the physical switch numbering is unclear, first label them visually as:
+
+- `S2-1` .. `S2-4`
+- `S3-1` .. `S3-4`
+
+based on one fixed left-to-right or top-to-bottom convention, and stick to it.
+
+### Phase 1: Single-Bit Sweep
+
+Goal:
+
+- find out whether any single DIP bit has an obvious effect on startup,
+  protocol, or front-panel behavior
+
+Run these eight tests, always starting from all-off baseline:
+
+1. `S2-1` on, all others off
+2. `S2-2` on, all others off
+3. `S2-3` on, all others off
+4. `S2-4` on, all others off
+5. `S3-1` on, all others off
+6. `S3-2` on, all others off
+7. `S3-3` on, all others off
+8. `S3-4` on, all others off
+
+For each test:
+
+- power-cycle
+- watch LCD/startup state
+- check for idle heartbeat
+- try one minimal probe set:
+  - idle listen
+  - `A0`
+  - `A0 -> 90`
+  - `A0 -> AF`
+
+What would count as a hit:
+
+- panel boots into a different visible mode
+- panel no longer shows `CONNECT NOT ACT`
+- heartbeat changes or disappears
+- known startup families change:
+  - `64 40 30`
+  - `0D 04 AB`
+  - `0D 04 EB`
+  - `E4 40 30`
+- buttons become active in idle
+
+### Phase 2: Group Identity Test
+
+Only do this after Phase 1.
+
+Goal:
+
+- see whether one whole DIP bank behaves like an address nibble or mode nibble
+
+Run these four tests:
+
+1. all `S2` on, `S3` all off
+2. all `S2` off, all `S3` on
+3. all `S2` on, all `S3` on
+4. return to all off baseline and confirm behavior is restored
+
+What this can reveal:
+
+- one bank may control personality while the other controls address
+- one bank may do nothing while the other changes the panel sharply
+- all-on may expose service/test behavior that single-bit changes do not
+
+### Phase 3: Follow-Up Only If A Bit Matters
+
+If Phase 1 reveals a promising bit, branch carefully:
+
+1. repeat that same switch setting twice to confirm reproducibility
+2. test neighboring bits in the same bank
+3. test that bit plus one neighboring bit
+4. compare:
+   - startup text
+   - heartbeat
+   - `A0 -> 90`
+   - `A0 -> AF`
+   - `E8` / `EC` selector behavior
+
+### Good First Serial Checks Per DIP Setting
+
+Keep the serial side small at first.
+
+Recommended order:
+
+1. idle listen only
+2. repeating heartbeat only
+3. `A0`
+4. `A0 -> 90`
+5. `A0 -> AF`
+
+Only if something changes meaningfully, then test:
+
+- `E8`
+- `E9`
+- `EC`
+- CALL synthetic trigger
+
+### Strong Cautions
+
+- Do not change multiple unknown DIP bits at once in the first pass.
+- Do not assume "on" means logic high; it may actually pull the line low.
+- Some switches may only be sampled at cold boot, not warm reset.
+- A strange setting may stop normal serial output entirely; that is still a
+  useful result.
+- If one setting produces a dramatically different boot state, stop and record
+  it before going wider.

docs/pt2-protocol-summary.md

@@ -395,6 +395,20 @@ Current caution:
 - That makes `90` and `AF` look increasingly like startup beacons or mode/class
   selectors, but still not sufficient to activate the panel or make later page
   feeds become live.
+- HE33 followed that clue directly by maintaining the startup-family classes
+  themselves instead of switching immediately to `E8` / `EC` page traffic.
+- That still did not wake the panel.
+- The `90` side remained the cleaner startup surface:
+  - repeated `90` or `A0 -> 90` reliably opened `07 80 64 40 30 C9`
+  - host maintenance of `64 40 30` then fell back to heartbeat-compatible
+    traffic
+- The `AF` side remained sloppier:
+  - `A0 -> AF` cleanly opened `07 80 0D 04 AB 7F`
+  - repeated `AF` sometimes preferred `AB` rather than the earlier `EB` family
+  - host maintenance of `0D 04 AB` or `0D 04 EB` still did not create a live
+    maintained session class
+- Interleaving heartbeat beside these startup-family maintenance frames also did
+  not help.
 
 ## What We Do Not Know
 

docs/pt2-state-map.md

@@ -472,6 +472,40 @@ So, on the map, these now look like:
 - separate from the later selector/page layer
 - still not sufficient to produce full wake/session activation
 
+## HE33 Maintained Startup-Class Follow-Up
+
+HE33 tested the next obvious question:
+once a startup-beacon family opens, can the host maintain that same class as a
+live background stream?
+
+What happened:
+
+- `90 -> 64 40 30` stayed real, but did not become maintainable
+- `A0 -> 90 -> 64 40 30` behaved the same way
+- `90 -> E4 40 30` did not pivot into a stable `E4`-maintained state
+- `A0 -> AF -> 0D 04 AB` could briefly drain more `AB` responses, then fell
+  back to heartbeat
+- repeated `AF` plus host `0D 04 EB` was slippery and often still returned the
+  `AB` family instead
+- adding heartbeat beside these startup classes did not help
+
+What this means on the map:
+
+- the startup-beacon layer is probably **real but shallow**
+- it can bias or open a startup family
+- but those families still do not behave like the maintained session stream the
+  panel needs in order to wake fully
+
+Refined startup-layer view:
+
+| Startup opener | Family observed | Maintainable as a live class? |
+| --- | --- | --- |
+| repeated `90` | `07 80 64 40 30 C9` | no |
+| `A0 -> 90` | `07 80 64 40 30 C9` | no |
+| repeated `90` alternate branch | `07 80 E4 40 30 49` | not confirmed as maintainable |
+| repeated `AF` | `07 80 0D 04 AB 7F` or `07 80 0D 04 EB 3F` | no |
+| `A0 -> AF` | `07 80 0D 04 AB 7F` | no |
+
 ## Best Next Uses Of This Map
 
 This map is meant to help us ask sharper questions, for example: