1
0
Files
h8-536-decoder/docs/pt2-lamp-selector-map.md
2026-05-26 18:25:03 +10:00

3.7 KiB

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 strongest CAM POWER lamp candidate
0x0015 = 0x8000/0x0000 strongest CALL lamp candidate
0x0012, 0x0013, 0x0016, 0x0017, 0x0018, 0x001A BARS, MASTER, tally red/green candidates; exact assignment still needs isolation

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.

Candidate selectors in that run:

0x0003, 0x0040, 0x0081, 0x0092, 0x00A7, 0x00B7, 0x00B9, 0x0110

Interpretation:

  • KNEE AUTO is likely in this broader status cluster.
  • Exact selector/value still needs isolation because the broad sweep changed several selectors in sequence.

Follow-Up Isolation Scenarios

Run these with the console visible and record the exact label shown when each lamp changes:

.\.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

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.