H2-1 — HCL definition and system boundary

Engineering thesis: Human-Centric Lighting (HCL) is an engine that converts time-based scenes and optional sensor feedback into stable tunable-white output (CCT + illuminance) using controlled transitions, constraints, and evidence-ready telemetry.

What this chapter proves (in engineering terms, not marketing): HCL is not a “feature label”. It is a control system with (1) explicit targets, (2) explicit actuators, (3) optional feedback, and (4) a state machine that makes behavior deterministic across schedule changes, overrides, and reboots.

Define the three variable layers (this is the vocabulary used by every later chapter):

• Setpoints (what the user wants): correlated color temperature and illuminance targets that can change over time (scenes, schedules).
• Actuators (what the system controls): per-channel output commands (normalized channel ratios or absolute channel current setpoints).
• Feedback/Observations (what the system measures): ambient light level (ALS), estimated CCT (color/CCT sensor), and temperature for drift compensation.

System boundary (what this page covers): circadian scheduling (RTC + scene table), CCT mixing, closed-loop stabilization using ALS/CCT sensors, smooth fades (perceptual ramps), calibration storage, and telemetry/log fields for field proof.

Explicit exclusions (keeps this page from overlapping siblings): protocol specifics (DALI/DMX/0–10V), LED driver power-stage design (buck/boost/flyback/LLC), and compliance subsystems (EMC/surge/creepage).

Minimum Evidence Bundle (the smallest log snapshot that proves the HCL engine is behaving correctly):

H2-2 — Reference architecture: dataflow + timing model

What this chapter solves: HCL becomes unstable or “feels inconsistent” when scheduling, sensing, and output updates run at the same rate or write the same variables. A robust HCL architecture separates responsibilities by rate, enforces a single source of truth for active state, and exchanges data only through timestamped buffers.

Rate separation (three loops, three responsibilities):

• Fast control/update loop (≈ 200 Hz–2 kHz): applies ramps/gamma, enforces slew limits, preserves chromaticity during fades, and outputs Cmd_norm[ch] (actuators).
• Sensor loop (≈ 10–50 Hz): samples sensors, filters noise, validates freshness, and produces CCT_est/Lux_est (observations).
• Schedule/scene loop (≈ 0.1–1 Hz): advances time-of-day scenes, resolves priority/overrides, and updates only setpoints (never raw actuator commands).

Single source of truth (state machine rules):

• One owner of: Scene_ID, schedule state, override priority, ramp phase, and persistence policy.
• Every external change (manual scene recall, schedule tick, restore on boot) must enter through the same state machine to avoid split-brain behavior.
• Persistent state must be stored with version + CRC so field issues can be proven as “bad state restore” vs “bad control”.

Dataflow contract (who writes what): This page stays interface-agnostic by defining a clean contract. Slow logic writes setpoints; sensor logic writes estimates; fast logic writes actuator commands. Cross-rate exchange uses two buffers (timestamped) so stale data never silently corrupts output.

Field-proof guideline: if output “hunts”, “steps”, or “ignores schedule”, the fastest root-cause split is to compare timestamps: (1) is the sensor fresh, (2) is the fast loop running on time, (3) is the state machine overriding schedule for a reason.

H2-3 — CCT mixing fundamentals (2-channel and multi-channel)

Design thesis: CCT mixing is not “warm% + cool%”. It is a 2D mapping from a brightness target (Total_flux / Lux proxy) and a chromaticity target (CCT, optionally duv) into a channel command vector that remains stable under gain mismatch, temperature drift, and actuator constraints.

2-channel tunable white (Warm + Cool): A warm/cool ratio moves chromaticity, but the mapping is non-linear and brightness-coupled. Two effects make naïve linear mixing drift:

• Different luminous efficacy per channel: equal current change does not produce equal lux change. Holding lux constant forces the ratio to move as brightness changes.
• Non-linear color mapping: ratio maps to chromaticity first, then to CCT (CCT is not a linear axis). Small ratio errors can create uneven CCT steps, especially near the ends.

Multi-channel mixing (W + CW + WW, or adding R): Extra channels can reduce green/magenta bias and improve CRI/duv control, but only if mixing is defined as a matrix/LUT problem. The output must be a vector that satisfies two primary axes:

• Brightness axis: Total_flux (or a lux proxy) sets overall energy.
• Chromaticity axis: CCT (and optionally duv) sets color appearance.

Control variables (recommended contract):

• Inputs: CCT_target, Lux_target (or Total_flux_target).
• Core internal representation: Ch_ratio[] (normalized per-channel weights, sum not necessarily 1 before scaling).
• Actuator-facing command: I_set[] (absolute channel current setpoints) or a normalized command vector (Cmd_norm[ch]).
• Optional chromaticity quality metric: duv_est to capture green/magenta bias even when CCT is near target.

Why a “mixing matrix” is the stable approach: Define a mixing surface that maps (CCT_target, Lux_target) into a channel vector, then apply calibration gains and constraints. This avoids ratio drift when brightness changes and provides predictable behavior across scenes.

Legal region and reachability: Not every (CCT, flux) point is physically reachable. A robust mixer must detect when a request is outside the legal region and apply a deterministic rule (project to boundary, clamp one axis, or trade brightness for chromaticity) so transitions remain smooth and explainable in logs.

Evidence-first debugging: When CCT “wanders” under dimming or across units, the fastest proof split is to compare the command vector and the estimate:

• Ch_ratio[] stable but CCT_est drifts: likely gain/temperature model mismatch or optical mixing drift.
• Ch_ratio[] changes unexpectedly with the same targets: constraints/clamps or a non-deterministic mapping (missing matrix/LUT ownership).
• CCT_est stable but perception is off: duv_est bias or sensor transfer mismatch (covered in calibration chapter).

Implementation checklist (scope-safe):

• Separate brightness and chromaticity axes; do not embed brightness control inside “ratio”.
• Use matrix/LUT output as the source of truth for the channel vector.
• Apply Gain_k[] and Temp_coeff[] as a post-map correction (calibration), then clamp.
• Always expose Ch_ratio[], I_set[], and CCT_est in telemetry for field proof.

H2-4 — Calibration: from LED binning to mixing matrix (and what must be stored)

Calibration goal: Keep color and brightness behavior consistent across units and over time. Mixing quality depends on calibration assets (gains, matrices, temperature coefficients, optional sensor transfer), and those assets must be stored with versioning and integrity so field behavior is provable.

What calibration must cover (minimum set):

• Channel gain mismatch: differences from LED binning, optics, and assembly. Without per-channel gain, the same scene produces different CCT across fixtures.
• Temperature coefficients: chromaticity and flux drift with temperature. A stable mixer needs coefficients that correct the mapping as the system warms up.
• Sensor transfer (if feedback exists): sensor offset/scale must be aligned so closed-loop control is not “correcting toward a biased measurement”.

From characterization to a mixing matrix: A practical approach is to build a 2D mapping surface over (CCT, flux) and store it as a matrix/LUT. The mixer reads the matrix entry (and interpolates between entries), then applies calibration gains and temperature correction before clamping to actuator limits.

What must be stored in NVM (non-negotiable for field proof):

• Gain_k[ ]: per-channel gain normalization that anchors brightness and color repeatability.
• Mix_matrix / Mix_LUT: maps (CCT_target, Lux_target) to a channel vector (Ch_ratio[ ]).
• Temp_coeff[ ]: corrects channel contributions vs temperature (prevents warm-up color drift).
• Sensor_offset (optional): ties estimation to reality for stable closed-loop behavior.
• CRC + version: prevents silent corruption and enables controlled updates.

Factory-only vs field-updatable boundaries: Calibration assets that require controlled measurement conditions should be factory-only, while small trims can be field-updatable. This separation avoids “fixing” a symptom by damaging the foundational mapping.

• Factory-only (recommended): Mix_matrix/Mix_LUT and baseline Gain_k[ ] (requires instrumentation and controlled optics).
• Field-updatable (limited): small offsets/trims and timestamps, always with integrity checks and audit trail.

Integrity rule: Updates must be atomic (write → verify CRC → commit). A valid Cal_version and Cal_crc are required before enabling the mixer, otherwise the system should fall back to a safe default profile and log the condition.