127 lines
6.4 KiB
Markdown
127 lines
6.4 KiB
Markdown
# PT2 Lamp And Panel Output Selector Map
|
|
|
|
This note tracks bench-visible lamp/readout effects from CCU-to-RCP selector writes.
|
|
|
|
## Current Model
|
|
|
|
The panel lamps and seven-segment displays are driven by selector-table state, not by one monolithic "connected" flag. Command 0 writes into the primary/current tables, and several selectors immediately affect visible panel outputs while `CONNECT: OK` is alive.
|
|
|
|
Known active-state foundation:
|
|
|
|
- `E000[0x0000] = 0x8080` wakes/holds `CONNECT: OK`.
|
|
- `E000[0x008F]` drives shutter `EVS`/`OFF` style display state and iris AUTO side effects.
|
|
- `E000[0x0093]` drives at least white-balance and black/flare lamp state.
|
|
|
|
## Bench Observations 2026-05-26
|
|
|
|
### `lamp-0093-lowbyte-sweep`
|
|
|
|
Result: no new visible behavior beyond the already-known `0x0093` family.
|
|
|
|
Interpretation:
|
|
|
|
- The earlier `0x0093` mapping still stands.
|
|
- Individual low-byte probes inside a streamed `0x90xx` context did not reveal a new lamp in this run.
|
|
- Keep `0x9020` as a useful manual/baseline context and `0x90FF` / `0xFFFF` as black/flare AUTO positive controls.
|
|
|
|
### `lamp-known-button-selector-probe`
|
|
|
|
Visible result:
|
|
|
|
- CAM button/lamp flashed on/off.
|
|
- CALL lamp flashed on/off.
|
|
- BARS and MASTER lamps flashed on/off.
|
|
- Camera tally changed red, then later green.
|
|
- Each visible output illuminated by itself, not as a broad all-lamps blast.
|
|
|
|
Serial result:
|
|
|
|
- The run stayed in normal `CONNECT: OK` response cadence.
|
|
- Each command-0 write produced an immediate `04 ...` readback-style frame and repeated `02 00 02 00 00 5A` active responses.
|
|
|
|
Candidate mapping:
|
|
|
|
| Selector/value pair | Current meaning |
|
|
| --- | --- |
|
|
| `0x0007 = 0x8000/0x0000` | CAM POWER lamp blink confirmed by isolated run |
|
|
| `0x0015 = 0x8000/0x0000` | CALL lamp blink confirmed; red tally also blinked in the same phase |
|
|
| `0x0012`, `0x0013`, `0x0016`, `0x0017`, `0x0018`, `0x001A` | ordered candidates for SLAVE, green tally, BARS, MASTER, and neighboring lamp states |
|
|
|
|
Follow-up `lamp-isolate-cam-call` result:
|
|
|
|
- First phase blinked CAM POWER.
|
|
- Second phase blinked CALL and red tally.
|
|
|
|
Follow-up `lamp-isolate-known-neighbors` result:
|
|
|
|
- Visible order was SLAVE, then green tally, then BARS.
|
|
- The pattern repeated, and at one point SLAVE and BARS were visible together.
|
|
- Treat the ordered mapping as likely but not final until a fresh-boot single-selector run separates latch/persistence effects from the selector under test.
|
|
|
|
Follow-up `lamp-isolate-neighbor-single-boot` result:
|
|
|
|
| Fresh-boot candidate | Visible result |
|
|
| --- | --- |
|
|
| `0x0012 = 0x8000/0x0000` | no visible change reported |
|
|
| `0x0013 = 0x8000/0x0000` | SLAVE lamp |
|
|
| `0x0016 = 0x8000/0x0000` | camera tally green |
|
|
| `0x0017 = 0x8000/0x0000` | BARS lamp |
|
|
| `0x0018 = 0x8000/0x0000` | no visible result reported yet |
|
|
| `0x001A = 0x8000/0x0000` | no visible result reported yet |
|
|
|
|
This confirms that the host/CCU can directly drive panel lamps through selector-table writes. It also validates using the ROM dispatch-neighbor list around `0x0007` and `0x0015` as a high-value lamp map.
|
|
|
|
### `lamp-broad-status-selector-sweep`
|
|
|
|
Visible result:
|
|
|
|
- KNEE AUTO lamp flashed a few times.
|
|
- No other new visible result was reported.
|
|
- Follow-up isolation saw KNEE AUTO toward the end of the run, then blinking.
|
|
|
|
Candidate selectors in that run:
|
|
|
|
`0x0003`, `0x0040`, `0x0081`, `0x0092`, `0x00A7`, `0x00B7`, `0x00B9`, `0x0110`
|
|
|
|
Interpretation:
|
|
|
|
- KNEE AUTO is likely in this broader status cluster.
|
|
- Because the visible change happened toward the end, strongest next candidates are `0x00A7`, `0x00B7`, `0x00B9`, and `0x0110`, with `0x0092` kept as a guard candidate.
|
|
- Exact selector/value still needs isolation because the broad sweep changed several selectors in sequence.
|
|
|
|
Follow-up `lamp-isolate-knee-tail-single-boot` result:
|
|
|
|
| Fresh-boot candidate | Visible result |
|
|
| --- | --- |
|
|
| `0x0092` | iris AUTO/OFF behavior |
|
|
| `0x00A7` | no visible result reported |
|
|
| `0x00B7` | no visible result reported |
|
|
| `0x00B9` | KNEE AUTO |
|
|
| `0x0110` | KNEE AUTO |
|
|
|
|
Interpretation:
|
|
|
|
- `0x00B9` and `0x0110` are now the strongest KNEE AUTO candidates.
|
|
- Because two selectors can light the same lamp, the KNEE status may be split between camera status and panel/display state, or one selector may select the subsystem while the other sets the visible mode.
|
|
- The next useful step is a bit scan of `0x00B9` and `0x0110` to see whether `0x8000` is the only live bit or whether lower bits select other KNEE states.
|
|
|
|
## Follow-Up Isolation Scenarios
|
|
|
|
Run these with the console visible and record the exact label shown when each lamp changes:
|
|
|
|
```powershell
|
|
.\.venv\Scripts\python.exe scripts\serial_scenario.py scenarios\lamp-isolate-cam-call.json --parity E --log captures\lamp-isolate-cam-call.txt --result-json captures\lamp-isolate-cam-call-result.json
|
|
.\.venv\Scripts\python.exe scripts\serial_scenario.py scenarios\lamp-isolate-known-neighbors.json --parity E --log captures\lamp-isolate-known-neighbors.txt --result-json captures\lamp-isolate-known-neighbors-result.json
|
|
.\.venv\Scripts\python.exe scripts\serial_scenario.py scenarios\lamp-isolate-knee-status-selectors.json --parity E --log captures\lamp-isolate-knee-status-selectors.txt --result-json captures\lamp-isolate-knee-status-selectors-result.json
|
|
.\.venv\Scripts\python.exe scripts\serial_scenario.py scenarios\lamp-isolate-neighbor-single-boot.json --parity E --log captures\lamp-isolate-neighbor-single-boot.txt --result-json captures\lamp-isolate-neighbor-single-boot-result.json
|
|
.\.venv\Scripts\python.exe scripts\serial_scenario.py scenarios\lamp-isolate-knee-tail-single-boot.json --parity E --log captures\lamp-isolate-knee-tail-single-boot.txt --result-json captures\lamp-isolate-knee-tail-single-boot-result.json
|
|
.\.venv\Scripts\python.exe scripts\serial_scenario.py scenarios\lamp-isolate-knee-bit-scan.json --parity E --log captures\lamp-isolate-knee-bit-scan.txt --result-json captures\lamp-isolate-knee-bit-scan-result.json
|
|
```
|
|
|
|
Method notes:
|
|
|
|
- Record visible changes immediately during each labeled hold. Later `CONNECT: NOT ACT` cleanup is not selector evidence.
|
|
- If a selector causes a latch or unexpected mode, stop and keep the log instead of continuing the whole sweep.
|
|
- Prefer exact notes like `selector_0018_high -> tally red`, because the logs already preserve send timestamps and readback frames.
|
|
- For the single-boot follow-ups, each candidate gets a fresh power cycle. That is deliberate: it tests whether a lamp is truly driven by that selector rather than retained from a previous write.
|