Peripherals

This page collects optional hardware used around the iDotMatrix/WLED system. Peripherals are documented separately from the controller and matrix because electrical requirements and support status can differ substantially.

---

Buzzer

The 0.9.2 development line supports both active and passive buzzer backends from Config → Usermods → iDotMatrix. The BLE protocol is unchanged; this is local hardware configuration.

• Active — for self-oscillating buzzers/modules. The GPIO is held at a static active level while sound is requested; buzzerActiveHigh selects active-high or active-low polarity.
• Passive — generated by the ESP32 LEDC peripheral at 2 kHz. buzzerPassiveTrigger selects whether the connected passive buzzer/module is triggered by a High or Low signal.

For a transistor-driven module marked low level trigger, select Passive + Low. The GPIO is held HIGH while silent and the hardware square wave is emitted only while sound is requested. This avoids continuously biasing the module at rest. Direct passive buzzers normally use the High-trigger/default electrical convention.

The existing non-blocking pattern engine is shared by both backends: Test Buzzer emits one three-pulse group, Alarm can repeat the trill for the alarm lifetime, and Program/Schedule uses its existing finite activation notice. BLE and rendering continue while sound is active.

Leaving the buzzer pin unassigned disables the hardware backend. GPIO suitability and any required external transistor/MOSFET stage remain hardware-dependent.

RTC modules

Project status: Model-specific / catalog section

An RTC is not required for the core BLE protocol or matrix renderer: normal WLED timekeeping can provide the runtime clock.

RTC boards may nevertheless be useful in standalone or future hardware configurations. Each RTC must be documented by exact chip/module because voltage levels, I2C pull-ups, backup-battery behavior and library support differ.

For each RTC entry record:

• RTC chip;
• module/board model;
• operating voltage;
• I2C voltage and pull-up arrangement;
• backup battery/supercapacitor;
• tested controller;
• whether time survives power loss;
• any level shifting required;
• project integration status.

Do not mark a generic “RTC” as supported without identifying the actual device.

---

Audio / microphone input

Project status: Depends on the WLED AudioReactive hardware/profile

The iDotMatrix Usermod can consume WLED AudioReactive data. The physical microphone / audio-front-end is therefore primarily a WLED hardware concern.

The Usermod sees:

• overall audio level for LEVEL effects;
• 16 WLED GEQ bands, combined into 8 logical iDotMatrix FFT bands.

When documenting an audio board or microphone, include:

• microphone/front-end model;
• analog or digital interface;
• controller pins;
• WLED AudioReactive profile/settings;
• observed noise floor;
• whether LEVEL and FFT effects both work correctly.

---

Level shifters and driver stages

Some combinations may require external interface electronics, for example:

• 3.3 V -> 5 V logic level shifting;
• HUB75 buffering;
• MOSFET/transistor buzzer drivers;
• power distribution;
• I2C level conversion.

These components should be documented with the board/panel they were needed for. A successful test without a level shifter on one panel must not be generalized to every panel using the same nominal interface.

---

---

MatrixPortal LIS3DH accelerometer

Project status: Available on the MatrixPortal S3 hardware, intentionally outside the iDotMatrix Usermod

The MatrixPortal S3 includes an LIS3DH accelerometer. Automatic display orientation is a controller/WLED presentation concern rather than an iDotMatrix BLE-protocol function, so it is intentionally not coupled to this Usermod.

If automatic 0°/90°/180°/270° orientation is developed, the project direction is to implement it as a separate WLED Usermod. That keeps orientation applicable to native WLED effects and other content as well as iDotMatrix output, avoids adding LIS3DH dependencies to C3/other targets, and leaves room for additional accelerometer backends later.

A future implementation should use stable-orientation timing and hysteresis rather than rotating on individual noisy samples.

Adding a peripheral

Please provide:

1. exact model/part number;
2. photograph or product link;
3. supply/interface voltage;
4. connection diagram or pin assignment;
5. tested controller;
6. firmware/WLED version;
7. observed result;
8. any required external circuitry.

See Hardware Compatibility Report.

Passive low-level-trigger idle behavior

On Arduino-ESP32 3.x, ledcWriteTone() uses 10-bit LEDC resolution. The final 0.9.2 passive-buzzer backend attaches the channel at 10 bits and uses full-scale duty (1023) for a trigger-low module's silent HIGH state. This hardware-validated behavior avoids residual PWM after a tone and prevents the module from continuing to sound while idle.

The settings UI groups the buzzer controls under a dedicated Buzzer heading in the order Buzzer Pin -> Buzzer Type -> type-specific polarity -> Test buzzer. Only Active buzzer active-high: or Passive buzzer trigger: is shown at a time, according to the selected buzzer type. Switching type updates the visible option immediately. The test button appears once, uses the saved buzzer type and polarity, and is followed on a new line by Save first: test uses saved settings. The generated settings script remains below the project safety budget.