How Do You Use the ESP32 RMT Peripheral to Drive WS2812 LEDs and IR Remotes?

Detailed Explanation

The RMT peripheral is one of the ESP32's more specialised blocks — not a general-purpose timer or PWM channel, but hardware purpose-built to generate and capture arbitrary sequences of precisely-timed high/low pulses without ongoing CPU involvement. It was originally designed for infrared remote control encoding (hence the name), and its ability to output an exact, hardware-timed pulse train is exactly what WS2812-family addressable LEDs need for their single-wire bit-banging protocol. For general ESP32 GPIO, ADC, and timer peripheral usage, see How Do You Use GPIO, ADC, and Timers on the ESP32? — RMT is a separate, dedicated block from the general-purpose timers covered there.

How RMT Represents a Waveform

Each RMT channel has its own symbol memory — a small block of dedicated on-chip RAM (not shared with general SRAM) that stores the waveform as a sequence of RMT symbols. Each symbol encodes two duration-and-level pairs: a high time and level, followed by a low time and level, each duration expressed as a tick count at the channel's configured resolution. To transmit a waveform, firmware fills the symbol buffer (either directly, or via an RMT encoder — a small piece of code that translates application data, like a pixel colour value, into symbols on the fly) and starts the channel; the hardware then outputs the pulses with tick-level timing accuracy, entirely independent of what the CPU is doing afterward.

Clock Resolution and Timing Accuracy

Each RMT channel derives its tick rate from a configurable clock divider off the peripheral's source clock. For WS2812-class LEDs, the driver typically configures a resolution in the tens-of-MHz range (giving tick periods in the tens-of-nanoseconds range) so that the LED protocol's sub-microsecond high/low timing requirements can be expressed accurately as whole tick counts. The exact resolution needed depends on the specific timing tolerance of the LED part in use — always calculate against the datasheet's specified timing windows for the specific WS2812 variant (WS2812, WS2812B, SK6812, etc.) rather than assuming they're interchangeable, since minor timing differences between variants are a real source of "some LEDs work, others don't" bring-up issues on mixed-source LED strips.

Driving WS2812/NeoPixel LEDs

WS2812-family LEDs use a single data line where each bit is encoded as a specific high/low pulse-width pair — a "0" bit and a "1" bit have different high-time durations within the same overall bit period. Driving a strip means:

1. Configure an RMT TX channel with an appropriate resolution for the LED timing.
2. Provide an encoder (either a bytes encoder built into ESP-IDF's led_strip component, or a custom encoder) that converts each colour byte (GRB order is standard for WS2812) into the correct sequence of RMT symbols representing 0 and 1 bits.
3. Transmit the full pixel buffer for the strip in one RMT transaction, followed by the WS2812 reset/latch period (a minimum low-time gap, typically tens of microseconds, that tells the strip the frame is complete).

Espressif's own led_strip component (built on the modern RMT driver) is the most maintained starting point for new ESP-IDF projects; third-party libraries (FastLED, Adafruit NeoPixel via the Arduino core) also have ESP32 RMT-backed backends, but with varying levels of alignment to the current IDF v5 driver API.

Driving and Receiving IR Remote Signals

For IR transmission, RMT's carrier modulation feature superimposes a fixed carrier frequency (commonly 38 kHz for NEC-protocol consumer IR) onto the generated pulse train automatically — firmware only needs to specify the baseband on/off pattern for the protocol being emulated, and the hardware handles the carrier. This carrier feature must be explicitly disabled when using RMT for WS2812 LED output; leaving it enabled corrupts the LED bitstream, since LEDs have no carrier concept at all.

For IR reception, an RMT RX channel captures the raw pulse timing from an IR receiver module (such as the TSOP38238, which already demodulates the carrier and outputs a clean digital signal) into symbol memory, which firmware then decodes against the specific remote protocol's timing table (NEC, RC5, Sony SIRC, etc.). RX channels support a configurable idle threshold (how long a line must stay idle before the receiver considers the transmission finished) and a glitch filter (rejecting pulses shorter than a configured minimum, to filter electrical noise) — both need tuning against the specific IR protocol and receiver module in use.

Design Considerations

• Confirm which RMT driver API version a reference project uses before copying its code. ESP-IDF v5.x's channel-based API (rmt_new_tx_channel(), rmt_transmit()) is a different API surface from the legacy rmt_config()/rmt_write_items() calls still common in older tutorials and libraries — mixing the two doesn't work, and porting old example code to a current IDF version is a real but manageable task.
• Size symbol memory and buffering strategy to the actual LED count. A short strip (a handful of LEDs) fits comfortably in static symbol memory; a long strip needs a driver that streams data into the buffer as it drains, or DMA-backed RMT on chips that support it — check the chosen library's documentation for which strategy it uses and its practical LED-count limits.
• Disable carrier modulation for LED applications and enable it only for IR transmission — this is a single configuration flag, but an easy one to leave at the wrong default when adapting IR example code for LED use or vice versa.
• Validate WS2812 timing against the specific part's datasheet, not a generic "WS2812 timing" figure copied from an unrelated project — different manufacturers' WS2812-compatible parts have measurably different timing tolerances, and a driver tuned for one variant's tolerance window can produce marginal or unreliable results on a different variant.

For ESP32 firmware involving precise pulse-timing peripherals, LED control, or IR remote integration, Zeus Design's firmware team develops production ESP32 firmware for connected and IoT products.

Common Mistakes

• Leaving carrier modulation enabled while driving WS2812 LEDs — the LED bitstream requires a clean baseband signal; carrier modulation (intended for IR) corrupts it into unpredictable colours or a non-responsive strip.
• Copying WS2812 example code written against the legacy rmt_config() API into a current ESP-IDF v5.x project — the old API was removed in favour of the channel-based driver, and the code will fail to compile until ported to the new API's function calls and structures.
• Exhausting RMT symbol memory on a long LED strip without a streaming/refill strategy — a driver that assumes the entire strip's data fits in static symbol memory will silently truncate or corrupt the tail end of a strip once it exceeds the buffer's capacity.
• Using a timing configuration calculated for one WS2812 variant on a different, nominally-compatible LED part — subtle differences in bit-timing tolerance between manufacturers can produce a strip that works for some batches of LEDs and not others, a difficult intermittent-looking fault to trace back to a timing-margin issue.
• Not configuring an appropriate idle threshold on IR RX channels — too short a threshold splits one transmission into multiple fragments; too long a threshold merges consecutive button presses together, both producing incorrect protocol decoding.