DMX Refresh Rate Explained: Timing, FPS, and Real-World Limits

Timing failure prevention

Protect shows from timing issues by understanding frame timing and running simple diagnostics before you go live.

Timing test

• Fade one channel slowly and watch for jitter.
• Run a pan/tilt sweep to confirm motion stays smooth.
• Swap cables or terminators if you see flicker.

USB DMX jitter is real—prove it by comparing a hardware node to a USB dongle. If the USB stream wobbles, move to a buffered interface or hardware node.

Les på norsk: DMX-timing på norsk

DMX Timing & Refresh Rate

Quick answer: DMX refresh behavior depends on frame timing and channel load. Stability comes from predictable timing, not just higher update claims.

Break / Mark-After-Break, the 44 Hz Myth, and Why USB Dongles Jitter

DMX problems that feel like “lag,” “random flicker,” or “unsteady movement” are very often timing problems, not programming mistakes. To understand why, you need to understand how a DMX frame is actually transmitted — and why refresh rate is not a fixed number.

This guide breaks down DMX timing at the signal level and explains why cheap USB interfaces are a common source of jitter.

The DMX Frame: What’s Actually on the Wire

A DMX512 signal is not a continuous stream. It is a repeating frame, made up of three main parts:

1. Break

2. Mark After Break (MAB)

3. Data slots (channels)

1. Break

The break is a deliberate pause where the line is held low longer than a normal data bit.

Purpose:

• Signals the start of a new frame

• Allows fixtures to resynchronize

Typical timing:

• Minimum: ~88 µs

• Common implementations: 100–200 µs or more

---

2. Mark After Break (MAB)

The MAB is a short idle high period immediately after the break.

Purpose:

• Gives receivers time to prepare for incoming data

• Separates framing from payload

Typical timing:

• Minimum: ~8 µs

• Common values: 12–20 µs

This is why “mark after break” is a real timing parameter, not trivia.

---

3. Data Slots (Channels)

Each DMX slot:

• 1 start bit

• 8 data bits

• 2 stop bits
  → 11 bits per channel

At 250 kbaud, each channel takes ~44 µs to transmit.

A full universe (512 channels) therefore takes about 22.7 ms just for data.

---

Why the “44 Hz DMX Refresh Rate” Is a Myth

You’ll often see DMX described as running at 44 Hz. That number comes from:

1 / 22.7 ms ≈ 44 Hz

But this assumes:

• A full 512-channel universe

• Minimal break and MAB

• No extra timing gaps

In reality:

• Fewer channels = faster refresh

• Longer breaks = slower refresh

• Different controllers = different behavior

Practical examples

• 96 channels → significantly higher refresh rate

• 512 channels → ~30–44 Hz depending on implementation

• Controllers may deliberately slow refresh for stability

There is no single DMX refresh rate.

---

Why Refresh Rate Changes with Channel Count

DMX is serialized. Channels are sent in order, whether fixtures exist or not.

If you send:

• 64 channels → short frame → fast refresh

• 512 channels → long frame → slower refresh

This is why large rigs can feel less “snappy” even with perfect programming.

(Related: DMX latency vs jitter, why lights feel “off”.)

---

What DMX Jitter Actually Is

Jitter is variation in frame timing, not latency.

Symptoms:

• Slightly uneven pan/tilt motion

• Shimmering dimmer fades

• Inconsistent strobe timing

DMX fixtures assume frames arrive at roughly regular intervals. When that assumption breaks, motion looks unstable.

---

Why Cheap USB DMX Dongles Jitter

Many low-cost USB DMX interfaces are not real-time devices.

Common causes:

• USB is packet-based, not deterministic

• Host OS scheduling delays transmission

• No hardware buffer for full frames

• Timing generated in software, not hardware

• Competing USB traffic (audio, storage, networking)

Result:

• Break length varies

• MAB timing fluctuates

• Frame spacing is inconsistent

Even if average refresh rate looks fine, micro-jitter accumulates visually.

---

Why Pro Interfaces Behave Better

Professional DMX interfaces typically use:

• Dedicated microcontrollers

• Hardware UART timing

• Buffered frame transmission

• Deterministic scheduling independent of USB timing

USB becomes a configuration link, not a timing source.

---

Why This Matters for Motion and Fades

Pan/tilt motors and dimmer curves assume:

• Stable frame intervals

• Predictable delta between values

Jitter breaks that assumption, making even high-resolution data look rough.

This is why “everything is patched correctly” but motion still feels wrong.

---

Final Takeaway

DMX is simple, but not forgiving.

• Refresh rate is variable

• Timing consistency matters more than raw speed

• Cheap interfaces often fail silently

• Jitter is a signal problem, not a programming one

Understanding break, mark-after-break, and frame timing explains a large class of “mystery DMX issues.”

FAQ: DMX Timing

• What is the real DMX refresh rate? ~30–44 Hz for a full universe; fewer channels refresh faster.
• Why does USB DMX jitter? OS/USB scheduling and lack of hardware buffering.
• How do I test timing? Run slow pan/tilt and smooth fades; watch for stutter or flicker.

Quick timing checklist

• DMX cable + termination
• No passive Y-splits
• Try a node/hardware buffer if USB jitter persists

Related Reading

• DMX512 Protocol Explained
• 3-Pin vs 5-Pin XLR for DMX
• How to Find and Set DMX Address