Stage Head & Pixel Strip Driver: PWM, DMX/RDM, Art-Net
← Back to: Lighting & LED Drivers
Stage Head & Pixel Strip drivers are real-time lighting control nodes: they turn DMX/RDM/Art-Net frames into stable, camera-safe grayscale output while keeping mapping, power transients, and thermal/OC protections from breaking the look. The core is an evidence-based pipeline—timing budget + buffering/latch + clean power/ground + smooth derating—so the fixture stays deterministic and debuggable on stage.
System boundary: what “Stage Head & Pixel Strip driver” includes
This page defines the fixture electronics that turn control frames into stable light output under stage conditions. It covers system-level partitioning (power/control/output/comms/protection) and measurable performance targets—rather than a single power topology or protocol tutorial.
Two fixture archetypes (why they are hard in different ways)
- Moving head (motors, fans, sensors in the same enclosure): load steps and ground bounce can corrupt timing, reset logic rails, or force protection states during cues.
- Pixel strip / pixel bar (dense pixels + mapping): channel scale and frame budgets dominate; long cables and frequent hot-plugging raise ESD/EMI and intermittent fault risk.
Three-domain layering (the architecture that prevents scope creep)
- Power domain: CV input (often 24V/48V) → multi-rail DC/DC (logic, pixel rail, auxiliaries). Goal: survive inrush, brownout, and load steps without visible artifacts.
- Control domain: frame ingest (DMX/RDM or Art-Net/sACN) → buffering/timebase → mapping → grayscale/PWM scheduling. Goal: deterministic updates with bounded jitter.
- Output domain: PWM MOSFET banks for CV strips, or constant-current pixel outputs. Goal: high-speed grayscale with safe fault behavior (OC/OT/UVLO).
Evidence targets (must be defined up front)
Cite this figure Figure ID: F1 Topic: Fixture domain map
Performance targets that actually matter on stage
Stage complaints (banding, strobing, low-level steps, color shift) must be translated into measurable timing and modulation targets. The key is to control both the light modulation timebase (PWM/bit-planes) and the frame update determinism (refresh + jitter).
Perceptual failures → engineering causes → evidence
- Banding / tearing: partial-frame updates or non-atomic latching. Evidence: latch alignment, update jitter, frame-miss counters.
- Strobing / flicker: low-frequency envelope from bit-plane scheduling or rail ripple. Evidence: photodiode waveform low-frequency content, bus ripple correlation.
- Low-level steps: insufficient effective bits or poor gamma/dither policy. Evidence: 1–5% ramp test, adjacent-code luminance delta statistics.
- Color shift: channel thermal drift, unequal current ripple, or line-loss on long strips. Evidence: per-channel current waveforms + temperature map + remote voltage drop.
The four numbers that force correct tradeoffs
- PWM base frequency (Hz): sets the primary modulation rate and EMI/edge constraints.
- Refresh rate (FPS): sets how often a complete “look” is applied (scene update cadence).
- Effective grayscale bits (bits): sets low-level smoothness after gamma + dithering.
- Per-frame update budget (ms/µs): the hard ceiling for receive/parse → map/compose → schedule → latch.
Minimum acceptance test pack (fast, repeatable)
- Waveform A: PWM gate or LED current (frequency + edge timing jitter).
- Waveform B: photodiode output (low-frequency envelope and beat patterns).
- Logs: frame-miss, sequence error, input inter-arrival histogram (jitter).
- Visual: low-level ramp (1%→5%), fast cue transitions, slow-motion capture for stripes/banding.
Cite this figure Figure ID: F2 Topic: Budget triangle + timing budget
Reference architecture: from DMX/Art-Net to photons
A stage fixture driver is a deterministic pipeline: control frames enter through DMX/RDM or Art-Net/sACN, are conditioned and buffered, then mapped into synchronized grayscale outputs. This reference architecture is organized by module boundaries so each block can be implemented, tested, and logged independently.
Module split (what each block must guarantee)
- Input PHY: DMX512/RDM via RS-485, or Art-Net/sACN via Ethernet. Goal: loss-tolerant frame ingest with error visibility.
- Input conditioning: sequence check, jitter smoothing, stale-frame policy, and hold-last-look fallback. Goal: stable frame cadence even with noisy lines or network jitter.
- Frame buffer (double buffer): two complete “looks” (front/back). Goal: atomic swap so partial updates never reach outputs (no tearing).
- Mapper: universe/channel patch → fixture outputs (segments/pixels). Goal: deterministic mapping with versioning and CRC to prevent wrong addressing.
- Output scheduler: converts mapped intensities into grayscale timing (bit-planes/dither) aligned to a single timebase. Goal: synchronized latch across all channels.
- Output stage: PWM MOSFET banks for CV strips, or pixel-driver chain (SPI/differential) for constant-current pixels. Goal: clean edges, bounded EMI, and recoverable fault behavior.
- Monitoring + fault log: temperature, rail voltage, output current, link errors, and protection events exported via RDM/network. Goal: stage-side diagnostics within minutes.
Latency map (the minimum measurable end-to-end timeline)
- T0 Frame received (DMX frame complete / network packet received)
- T1 Frame validated (CRC/slot/sequence check)
- T2 Frame queued (jitter buffer entry)
- T3 Mapping complete (patch + compose done)
- T4 Output prepared (scheduler loaded / pixel queue ready)
- T5 Global latch/blank edge (the moment the “look” becomes visible)
Cite this figure Figure ID: F3 Topic: End-to-end architecture
High-speed PWM & grayscale engine: bit depth, dithering, gamma
Stage-grade output is defined by stable grayscale at low levels, synchronized updates across channels, and predictable camera behavior. The grayscale engine is a scheduling problem under hard frame-time budgets: PWM base frequency, bit-plane timing, gamma mapping, and temporal dithering must be coordinated with a single latch point.
PWM base frequency selection (constraints, not a single “higher is better” rule)
- Visual + camera interaction: stripes and banding depend on the low-frequency envelope created by bit-plane scheduling and refresh jitter, not only PWM Hz.
- Acoustic risk: some fixtures exhibit audible artifacts in certain PWM ranges due to mechanical coupling (enclosure, wiring, magnetic components).
- EMI and cable reality: higher edge activity increases radiated/common-mode stress on long wiring and pixel strips.
- Thermal headroom: higher switching losses raise MOSFET/driver temperature and can force derating earlier.
Grayscale pipeline (the minimum complete chain)
- Linear intensity → Gamma correction (perceptual linearity)
- Quantize to target bit depth (8/12/16-bit policy)
- Temporal dithering (frame-to-frame shaping to increase effective bits)
- Bit-plane scheduling (time slices per bit, bounded within each refresh frame)
- Global latch + blank (atomic update to prevent tearing across channels)
Multi-channel synchronization (what prevents tearing and banding)
- Single timebase: all channels share one scheduler clock reference (no per-port drift).
- Atomic update: new frame data becomes visible only at the latch edge (no partial-frame mixing).
- Global blanking window: short blank around latch prevents edge overlap and mixed states during transitions.
Evidence chain (required waveforms + counters)
- Waveform #1: PWM gate (or driver output) — verify base frequency stability and latch-aligned timing jitter.
- Waveform #2: LED current (or photodiode) — verify low-frequency envelope and low-level continuity under dimming ramps.
- Counter: frame miss/drop — log and export to correlate visual glitches with real missed updates.
Cite this figure Figure ID: F4 Topic: Bit-plane timing + latch/blank
Pixel mapping pipeline: addressing, universes, and failure containment
Pixel mapping is a runtime pipeline, not a static table: it must translate universes/channels into ports and pixel chains, apply chunked updates without visible tearing, and contain single-point failures so a bad node or chain does not corrupt the whole look.
Pipeline stages (configuration → atomic apply)
- Universe budget → allocate channels per fixture/zone (head, strip, bar), with a refresh target and margin.
- Patch table → fixture_id, port_id, pixel_start, pixel_count, color_order, gamma_profile, group/zone tags.
- Chunk planner (tile/chunk) → split large pixel payloads into bounded chunks for transport and compute.
- Staging buffer → assemble all chunks into a complete “look” (or a complete port segment) before commit.
- Atomic commit → a single latch/commit point applies the staged look so partial frames never become visible.
- Per-port scheduler → enforce per-port limits (rate, cable-length constraints, thermal derate hooks).
Failure containment (minimize visual blast radius)
- Port boundary: link errors on one port never propagate to other ports (independent queues + independent counters).
- Chain boundary: a bad pixel link/segment triggers localized actions (freeze segment, bypass if supported, or safe dim) rather than global reset.
- Escalation policy: only safety-relevant faults (overcurrent, overtemp, rail collapse) escalate to global blank/off.
Hold-last-look & fallback scene (input loss behaves predictably)
- Hold-last-look: short interruptions keep the last valid look to avoid sudden jumps.
- Fallback scene: after a defined timeout or repeated integrity failures, transition to a safe scene (fade to safe level, static scene, or off).
- Traceability: every fallback event is logged with cause, time, and recovered state.
Evidence chain (must be exportable via RDM / network)
- Patch integrity: patch_version + patch_crc + last apply time; reject updates that fail CRC or schema version.
- Link health: per-port link_err, retry/resync, and frame_integrity_err counters (no single “total only” counter).
- Fallback triggers: input_timeout_ms, seq_error_limit, err_rate_threshold, and safety triggers (OT/OC/UVLO).
Cite this figure Figure ID: F5 Topic: Mapping + containment
DMX512/RDM/Art-Net in fixture engineering terms: timing, buffering, diagnostics
Inputs are evaluated by how they affect real-time output quality: jitter, loss, and contention must be absorbed by a timing conditioner that normalizes all sources into a stable frame stream. Diagnostics must expose the right counters so “random” stage failures become measurable.
DMX (serial reality): gaps, jitter tolerance, and drop behavior
- Frame validity: detect incomplete frames and byte errors early; never apply partially decoded looks.
- Gap tolerance: small timing variations must not shift output cadence; a conditioner defines an acceptance window.
- Drop strategy: missing frames trigger hold-last-look for short gaps, then fallback after a defined timeout.
RDM (maintenance reality): half-duplex switching and diagnostic payload
- Direction switching: half-duplex timing must be scheduled so diagnostic responses do not destabilize frame ingest.
- Response window discipline: rate-limit diagnostics; avoid bursts that starve the output scheduler.
- Useful telemetry: expose temperatures, rail status, output current, protection events, firmware/patch version, and error counters.
Art-Net / sACN (network reality): jitter, reordering, loss → buffer & replay policy
- Reorder by sequence: accept newest valid frames; drop stale/out-of-order frames beyond a reorder window.
- Jitter buffer: smooth arrival variation to a single internal frame cadence.
- Loss policy: define replay/hold behavior; do not “guess” in ways that cause visible pops.
On-site evidence (three logs that must exist)
- rx_frame_rate: per-source effective valid frame rate (DMX vs network).
- sequence_error: duplicate/out-of-order/missed sequence counters (network source).
- net_jitter_hist: inter-arrival histogram to separate network jitter from internal scheduling jitter.
Cite this figure Figure ID: F6 Topic: Input conditioner + logs
Output stage options: CV PWM MOSFET vs constant-current pixels
Stage fixtures typically drive two very different output loads: CV LED strips/segments (switched by PWM MOSFETs) and constant-current pixel chains. Correct selection depends on how wiring loss, grayscale stability, and uniformity are handled under real cable lengths and heat distribution.
Path A — CV LED strip (low-side PWM MOSFET + segmented feed)
- Structure: CV rail → segment feed points → low-side PWM MOSFET per segment/channel.
- Primary risk: cable/trace voltage drop changes LED current and amplifies brightness/color mismatch along the strip.
- Common mitigation: segmented power injection (shorter current paths), star return where possible, and per-segment diagnostics.
- Typical symptom translation: “same PWM but different look” usually indicates far-end voltage sag or ground return coupling, not mapping logic.
Path B — Constant-current pixels (current sinks + calibration/uniformity)
- Structure: pixel supply rail → CC sinks (per pixel/per channel) → LED. Brightness is tied to sink accuracy and grayscale timing.
- Primary risk: clock/update jitter and resync events distort low-level grayscale; temperature gradients reduce uniformity.
- Common mitigation: per-lot calibration, temperature-aware derating, bounded resync policy, and stable update/latch boundaries.
- Typical symptom translation: “low gray unstable” is often a timing/refresh problem (jitter/resync), not a power drop problem.
Shared physics (both paths)
- Current ripple → color shift: supply ripple or switching coupling modulates LED current and changes perceived color at low levels.
- Thermal gradient → non-uniform brightness: hot zones shift LED VF and driver characteristics, creating spatial mismatch.
Evidence chain (must be measurable)
- Strip far-end voltage: measure segment head vs far end, then build a Vdrop vs length curve.
- Single-pixel current waveform: verify the current shape at multiple gray levels (especially low gray) and during fast cues.
- Cable drop curve: document voltage drop under different brightness (load current) to separate wiring from scheduler issues.
Cite this figure Figure ID: F7 Topic: Output path comparison
Power tree & transient robustness: inrush, brownout, motor/strip interaction
Fixtures often combine motors, fans, pixel power, and logic in one enclosure. Transient events (hot-plug inrush, brownout, motor start/brake) can collapse the input bus or inject noise into sensitive rails, causing resets, frame drops, and visible output glitches.
Power tree (typical stage fixture split)
- Input bus (often 24V/48V) feeds multiple DC-DC rails with different sensitivity and load steps.
- Logic rail (3V3/5V_logic): most reset-sensitive; even brief dips can reboot control.
- Pixel rail (5V/12V_pixel): large dynamic load; ripple affects grayscale and color stability.
- Motor/fan rail: large step current during start/brake; can pull the input bus and disturb other rails.
Inrush & hot-plug (what must be defined)
- Inrush event: bulk capacitors charge at plug-in, creating a bus sag that can trip UVLO or reset logic.
- Soft-start & precharge: limit initial current so logic rail reaches regulation cleanly before heavy loads ramp.
- Start-up sequencing: delay high-load pixel/motor rails until logic is stable and input bus is settled.
Brownout behavior (how output should fail safely)
- Define thresholds: when the bus dips, decide whether to freeze output, fade to safe scene, or blank.
- Separate domains: a pixel rail dip may be tolerable; a logic rail dip usually forces a controlled reset path.
- Log cause: brownout entry/exit and reset reasons must be recorded to avoid “random reboot” narratives.
Motor start/brake coupling (disturbance chain)
- Load step on motor rail → input bus dip (supply impedance) → logic rail dip → MCU reset → output glitch.
- Return coupling → ground bounce shifts PWM thresholds or sensing references, increasing low-gray instability.
- DC-DC transient response limits determine whether the system rides through or resets.
Scope capture order (three rails first, always)
- 1) Input bus (24/48V): plug-in sag, motor step sag, peak ripple.
- 2) Logic 3V3: dips that correlate with resets or frame drop counters.
- 3) Pixel rail (5/12V): ripple bursts that correlate with flicker/color shift under cues.
Cite this figure Figure ID: F8 Topic: Power tree + disturbance path
OC/OT protections & thermal derating that doesn’t break visuals
Protection design in stage fixtures is not “trip and done.” The goal is to keep visuals stable while current and temperature are brought back into safe limits—without flicker spikes, sudden color shifts, or frame-tearing during derate/recover.
Over-current (OC): choose the correct action granularity
- Per-channel limiting: contain a single fault without collapsing the whole look. Best for multi-channel PWM or per-port pixel sinks.
- Group fuse / segment isolate: shut down only the affected port/segment and keep other groups alive (limits fault propagation).
- Global shutdown: reserve for unsafe conditions (PSU collapse, wiring overheat, repeated fault bursts). Prefer fade-to-safe then off.
Over-temperature (OT): multi-point sensing + soft derate curve
- Multi-point sensors: LED board (lumen/colour stability), MOSFET/driver hotspot (reliability), PSU hotspot (system safety).
- Soft derate: reduce output by a continuous scalar while preserving gamma and channel ratios (avoid sudden hue changes).
- Hysteresis & hold: stabilize transitions to prevent “in/out” oscillation near thresholds.
Fault recovery: hiccup vs latch + smooth fade-back
- Hiccup: periodic retry for transient events; requires retry limits and cooldown timers to avoid visible pulsing.
- Latch: lockout for hazardous events; requires explicit recovery conditions (temperature, time, manual service).
- Fade-back: recovery must ramp output on a controlled schedule and commit changes on frame/latch boundaries (no tearing).
Evidence chain (must be defined, logged, and testable)
- Thresholds: OC (per channel / per group / global), OT (derate start, trip temperature) per sensor.
- Durations: minimum sustain time before state change (ms), and cool-down hold time before recovery (ms).
- Recovery conditions: recovery temperature, stable hold time, retry limit, and “safe look” constraints.
- Event log fields: timestamp, source (CH/PORT/SENSOR), measured value, action taken, output scalar, frame-drop counter.
Cite this figure Figure ID: F9 Topic: Protection state machine
Cable EMC/ESD & grounding for stage realities
Stage cabling is long, frequently hot-plugged, and exposed to noisy mains environments. EMC/ESD robustness depends less on “more parts” and more on controlling return paths: where surge/ESD energy flows, where common-mode current closes, and how shield/chassis/logic grounds relate.
DMX / RS-485 port (fixture-side principles only)
- ESD entry: plug-in events inject energy into signal pair and shield—provide a short, wide path to chassis, not through logic ground.
- Common-mode behavior: long lines carry common-mode shifts; protect with controlled impedance to chassis and maintain a clean reference.
- Shield termination: prioritize low-inductance shield-to-chassis bonding near the connector; keep pigtails short.
Pixel output long lines (edge rate + loop area + radiation)
- Fast edges increase radiation and susceptibility; control drive strength/series damping to reduce ringing without reducing refresh rate.
- Return path must stay close to the signal path; large loop areas amplify common-mode emissions and increase cross-talk.
- Ground bounce from high current rails can shift logic thresholds, showing up as low-gray instability or occasional data corruption.
Three stage-proven pitfalls (why issues look “random”)
- Ground bounce: ESD or motor step currents share the same return as signal reference → frame errors and visible glitches.
- Uncontrolled “all grounds tied everywhere”: shield/chassis/logic/power returns hard-bonded without planning → noise flows through sensitive areas.
- Shield termination mistakes: long shield pigtails, inconsistent connector bonding → high-frequency effectiveness collapses.
Evidence chain (turn EMC into measurable data)
- Plug / ESD counters: plug_event_count, protection_trigger_count (if available), with timestamps.
- Comms error counters: DMX frame errors, RDM timeouts, network sequence/jitter issues (if applicable).
- Environment tags: temperature (minimum), optional humidity, correlated to error bursts.
Cite this figure Figure ID: F10 Topic: Return path & shielding
Validation & debug playbook (symptom → evidence → isolate → fix)
A stage fixture driver must be debuggable under time pressure. This playbook turns common on-site symptoms into a repeatable script: capture two waveforms, read three log fields, isolate the fault domain, apply the fastest stabilizing fix, and verify via counters.
Playbook format (copy/paste per symptom)
- Measure first (2 waveforms): pick the shortest probes that separate timing vs power vs comms.
- Read (3 log fields): one integrity field, one timing/sequence field, one drop/miss/error counter.
- Isolate: decide mapping vs buffer/latch vs power/rail vs PHY/EMC vs thermal/protection.
- Fastest fix: a stabilizing action that keeps visuals acceptable (hold-last-look, camera-safe mode, DMX-only, smooth derate).
- Verify: confirm counters stop increasing and the output becomes deterministic (no tearing, no periodic resets, no burst errors).
A) Scramble / misalignment (pixel map looks wrong)
Typical field reports include “wrong segment lights up,” “tiles shift,” or “random pixels stuck.” The first goal is to separate a mapping/patch integrity issue from a frame timing / latch boundary issue.
- Measure first (2 waveforms)
- WF1: Pixel data line (or differential pair) + any latch/blank/update strobe (if available).
- WF2: Frame boundary marker (DMA half/full interrupt pin, VSYNC-like pulse, or “frame commit” GPIO).
- Logs (3 fields)
map_crc(mapping/patch table CRC) +map_version(monotonic version ID).rx_seq_err(DMX slot miss / sACN or Art-Net sequence errors / reorder count).frame_drop_count(missed output latch / missed frame commit).
- Isolate
- map_crc changes → mapping storage/versioning or bad update source.
- rx_seq_err rises with low frame drops → input timing jitter / buffering policy.
- frame_drop_count rises → output pipeline bandwidth, commit gating, or latch boundary violation.
- Fastest fix
- Force-load a known-good mapping profile; lock
map_version; enable hold-last-look while re-syncing. - Switch to “tile/chunk update” (smaller chunks per frame) to avoid overruns; commit only on latch boundary.
- Force-load a known-good mapping profile; lock
- Example parts (MPN)
- Mapping storage: Microchip 24LC256 (I²C EEPROM), ST M24C64 (I²C EEPROM), Winbond W25Q64JV (QSPI NOR).
- MCU/DMA engine: ST STM32H743, NXP MIMXRT1062, Renesas RA6M5.
- FPGA for parallel PWM/pixel timing: Lattice ECP5 (e.g., LFE5U series), Xilinx Artix-7.
- Pixel protocols commonly encountered: Worldsemi WS2812B / SK6812 (1-wire), APA102 (SPI-like clocked pixels).
- Verify
map_crcstable across boots;rx_seq_errnot increasing;frame_drop_countflat during stress scenes.
B) Flicker / banding (visible steps, camera stripes, low-gray instability)
This symptom must be translated into measurable timing and ripple. The fastest separation is: PWM/bit-plane instability vs rail ripple modulating LED current.
- Measure first (2 waveforms)
- WF1: PWM gate (or PWM output pin) for a representative channel at low-gray and mid-gray.
- WF2: LED current (sense resistor or current monitor output) or pixel supply current proxy during the same scene.
- Logs (3 fields)
pwm_freq_hz+refresh_fps(actual running parameters snapshot).bitplane_miss/latch_miss(missed plane or missed commit events).rail_min_mv/rail_ripple_pkpk(min rail or ripple estimate in the window).
- Isolate
- Gate jitter / missing planes → grayscale engine scheduling, DMA starvation, or commit not aligned to blanking.
- Rail ripple tracks flicker → supply transient response, grounding, or load step coupling (motors/fans/PSU).
- Fastest fix
- Enable camera-safe mode: increase PWM base, constrain bit-plane scheduling, and use deterministic temporal dithering.
- Reduce peak brightness (global scalar) to shrink ripple and thermal load; keep gamma/channel ratios unchanged.
- Example parts (MPN)
- High-channel PWM / grayscale drivers: TI TLC5957, TI TLC5947, Macroblock MBI5153, NXP PCA9685.
- Current sensing / waveform-friendly monitors: TI INA181, TI INA240, ADI LT6106.
- Low-noise temperature sensors for derate curves: TI TMP117, Maxim MAX31875, Microchip MCP9808.
- Verify
- Low-gray ramps show no steps; camera at common shutter ranges shows no stable banding; counters
bitplane_miss/latch_missremain flat.
- Low-gray ramps show no steps; camera at common shutter ranges shows no stable banding; counters
C) Dropout / no response (controls stop, fixture ignores changes)
Do not start with protocol theory. The first separation is PHY/EMC and direction control vs network jitter buffering vs CPU overload.
- Measure first (2 waveforms)
- WF1: RS-485 A/B (DMX/RDM) or transceiver DE/RE direction-enable timing during RDM activity.
- WF2: RX frame timing marker (DMX break detect pulse) or network RX interrupt pulse (Ethernet controller/MCU IRQ).
- Logs (3 fields)
rx_frame_rate(frames/s received) +rx_valid_ratio(valid/total).rdm_timeout_countordir_switch_err(half-duplex control failures).net_seq_err/net_jitter_p95(sequence errors or jitter histogram percentile).
- Isolate
- Bad A/B waveforms or unstable break detect → EMC/ground/shield/ESD events.
- Stable receive but output stale → CPU overload, buffering policy, or commit gating.
- net jitter bursts → increase jitter buffer and reorder handling; enable hold-last-look.
- Fastest fix
- DMX/RDM: fall back to DMX-only (reduce/disable RDM queries), lock direction windows, keep last look on signal loss.
- Art-Net/sACN: enlarge buffer window, enforce sequence rules, and hold last look on gap/timeout.
- Example parts (MPN)
- RS-485/DMX transceivers: TI SN65HVD1781, Maxim MAX3485E, ADI ADM3485E.
- Isolated RS-485 (when needed): ADI ADM2682E, TI ISO1410 (with separate transceiver), TI ISO35 (family reference for digital isolation).
- Ethernet PHY / controllers: Microchip LAN8720A, TI DP83825I, Microchip KSZ8081, WIZnet W5500 (Ethernet controller).
- ESD protection commonly used on ports: Nexperia PESD2ETH series (Ethernet), Nexperia PESD1CAN (general-purpose TVS family reference).
- Verify
rx_frame_ratestable; timeouts stop; hold-last-look triggers only on actual cable disconnect; output resumes without tearing on reconnect.
D) Overheat shutdown / ugly derate (dims abruptly or “pulses” during recovery)
Protection must keep the show stable. The first goal is to confirm whether the system enters derate/trip due to real temperature rise, or due to incorrect thresholds/filtering/retry strategy that creates visible “in-and-out” oscillation.
prot_state toggles frequently, increase hysteresis/hold and convert recovery into ramped fade-back.
- Measure first (2 waveforms)
- WF1: Output scalar / global dimming ramp (or representative PWM duty envelope over time).
- WF2: Rail sag during thermal events (VIN + logic 3V3 or pixel rail 5V/12V) to separate “thermal” from “brownout resets”.
- Logs (3 fields)
temp_ledboard,temp_mosfet,temp_psu(multi-point).prot_state(NORMAL/DERATE/TRIP/RECOVER) +prot_reason.recover_rulessnapshot:Trec,hold_ms,retry_count,scalar.
- Isolate
- True thermal: temperature rises smoothly; derate should follow a smooth curve.
- Protection tuning: temperature below threshold yet state toggles → sensor filtering/threshold/hysteresis error.
- Power interaction: rail sag precedes state changes → brownout, inrush, or motor/fan load-step coupling.
- Fastest fix
- Switch to smooth derate curve (continuous scalar), add hysteresis and a minimum hold time, and ramp recovery (fade-back) on latch boundaries.
- Limit hiccup retries; prefer a stable safe look over repeated bright/dim pulsing.
- Example parts (MPN)
- Temperature sensors: TI TMP117, Maxim MAX31875, Microchip MCP9808.
- eFuse / inrush / hot-swap: TI TPS25947, TI TPS25982, ADI LTC4366 (surge stopper family).
- Fan control / monitoring (common building blocks): Microchip EMC2101 (fan controller), TI AMC6821 (fan controller).
- Verify
- Derate is monotonic and smooth;
prot_statedoes not oscillate; recovery returns via ramp without visible step changes.
- Derate is monotonic and smooth;
Cite this figure Figure ID: F11 Topic: Troubleshooting flowchart
mode_change_reason so the event timeline can be replayed after the show.
FAQs (evidence-based, mapped to H2-2…H2-11)
Each answer gives a minimal debug script: measure 2 waveforms, read 3 log fields, apply the fastest stabilizing fix, then jump back to the referenced chapters for deeper design context.
FAQ 1Low-level shimmer—bit-plane jitter or power ripple?
bitplane_miss, rail_ripple_pkpk, frame_drop_count. Fast fix: commit updates only on global blank and switch to deterministic dithering; add hold-up/inrush control (TPS25947) or a fast current monitor (INA240).
FAQ 2Camera banding—PWM frequency too low or refresh/bit-depth budget wrong?
pwm_freq_hz, refresh_fps, bitplane_miss. Fast fix: enable a camera-safe preset (higher PWM base, constrained planes) and keep gamma ratios fixed; a multi-channel PWM driver like TLC5957 or MBI5153 helps enforce deterministic timing.
FAQ 3DMX looks normal but pixels misalign—mapping table or frame-buffer tearing?
map_crc, map_version, frame_drop_count. Fast fix: reload a known-good map, lock map_version, and enable hold-last-look while resyncing; store maps in EEPROM/NOR such as 24LC256 or W25Q64JV with CRC verification.
FAQ 4RDM intermittent no-reply—direction window or bus-power budget?
rdm_timeout_count, dir_switch_err, rx_frame_rate. Fast fix: reduce RDM query rate or fall back to DMX-only for the show; use a robust transceiver like SN65HVD1781 or ADM3485E, and isolate if ground noise is severe (ADM2682E).
FAQ 5Art-Net occasional “scramble”—jitter buffer too small or out-of-order not handled?
net_jitter_p95, net_seq_err, reorder_drop_count. Fast fix: increase jitter buffer, reorder by sequence, and hold-last-look on gaps; common Ethernet blocks include LAN8720A or DP83825I, or an integrated controller like W5500.
FAQ 6Motor motion makes LEDs flicker—bus sag or ground-bounce coupling? What to probe first?
vin_min_mv, brownout_reset_count, frame_drop_count. Fast fix: limit acceleration/brake slew and add hold-up/inrush control (TPS25982); separate motor and LED rails where possible.
FAQ 7One strip segment is dimmer—voltage drop or thermal hotspot?
vdrop_mv, temp_ledboard, output_scalar. Fast fix: add remote power injection or heavier conductors and segment the rail; for thermal, apply zone derating with fixed color ratios. A precise temperature sensor (TMP117) helps stabilize the curve.
FAQ 8After overcurrent trip, recovery “twitches”—hiccup policy or missing fade-back?
prot_state, retry_count, recover_ramp_ms. Fast fix: cap retries, extend hold time, and enforce ramped fade-back aligned to blank/latch; an eFuse like TPS25947 can provide controlled retry behavior, and INA181 can verify current limit dynamics.
FAQ 9At high temperature, colors drift—LED thermal shift or rising current ripple?
temp_ledboard, rail_ripple_pkpk, output_scalar. Fast fix: use multi-point thermal derating that preserves channel ratios and reduce ripple by improving rail transient response; sensors like MCP9808 (or TMP117) keep the derate curve stable.
FAQ 10Long pixel cable sporadic wrong colors—edge too fast or common-mode noise?
pixel_link_err, esd_event_count, comm_err_burst. Fast fix: add series damping, slow the edge, and correct return path; add TVS protection at the connector (PESD2ETH family example for fast ESD clamps).
FAQ 11Plug/unplug DMX causes reboot—ESD path or power transient?
brownout_reset_count, esd_event_count, rx_err_burst. Fast fix: route ESD to chassis/shield, add controlled inrush/hold-up (TPS25982), and use an ESD-hardened RS-485 transceiver (MAX3485E or SN65HVD1781).
FAQ 12Same config fails only in a new venue—ground/shield differences or network quality?
net_jitter_p95, rx_frame_rate, comm_err_count. Fast fix: enlarge jitter buffer + hold-last-look, and normalize shield/chassis strategy at the fixture; an Ethernet PHY like DP83825I can improve robustness on marginal links.