Measured on real hardware: IO1=right IO2=left IO3=top IO4=middle IO5=bottom
(0x01=right 0x02=left 0x04=top 0x08=middle 0x10=bottom). The earlier verbal
'left=IO1/upper=IO2...' spec was wrong; this reverts to the original Phase-1
mapping, which the measurement confirms.
- protocol.js REGION constants + getRegionName + REGION_NAMES
- CRITICAL: buildVendorCommand ioMasks was built from REGION.* constants whose
values just flipped, scrambling IO slot order; pin to literal [0x01..0x10]
- diagnosis.js REGION_DEFS key↔mask; pd_region_map values unchanged (PD is
keyed by orientation, which is stable) — right=PD5 left=PD1 top=PD2
middle=PD3,6,7 bottom=PD4
- common.js region labels back to right/left/top/middle/bottom (上/中/下)
- treatment-setup / manual-treatment / treating / scan-report / ble-debug
face-map bindings and REGION_MAP realigned
- verified: mock pipeline lands left→IO2, middle→IO4 correctly
- entry in profile menu, visible only while a device is connected
- live FFE4 readout: 7x PD, VBAT, fitting, scan wave marker, run state
- tap a face-map region to fire a 2s single-region treat command
(verifies region-to-IO mapping on the physical mask)
- wavelength selector (red/ir/uv/yellow) to verify color byte order
- scan command / full-face 2s / stop buttons, hex log of every write
- intentionally not i18n'd; remove page before release
Guoguo