INMP441 I2S microphone gives zeros: pins, channel select and data format

Check the clock, word select and data pins, and tie the L/R pin to a fixed level.

What the message means

The microphone sends 24-bit samples in a 32-bit frame on one channel. A floating channel pin or wrong format gives silence or noise.

Fix it in this order

  1. Wire SCK, WS, SD to the I2S pins set in your driver configuration.
  2. Tie the L/R pin to ground or to 3.3 V, and read the matching channel.
  3. Power the module from 3.3 V.
  4. Set the sample rate and the 32-bit format and shift the samples to the right to get the useful bits.
  5. Keep wires short.
  6. Print the raw values to see if they change when you clap.

Why it happens

The INMP441 is a digital MEMS microphone that sends its samples over I2S. It sends 24-bit data inside a 32-bit frame, most significant bit first, so the useful part sits in the top bits and has to be shifted down in software. The L/R pin chooses which half of the frame the microphone speaks in: tied low it uses the left slot, tied high the right. If the pin floats, or the driver reads the other channel, you get zeros.

The datasheet supply range is 1.8 to 3.3 V, so power the module from 3.3 V and never 5 V. Printing raw samples while you clap is the quickest check, because even a small sound should change the numbers.

If you see this, do this

You seeDo this
All zerosWiring or wrong channel.
Noise onlyFormat or wire length.

input-only pins, power problems.

Last reviewed: November 2026. These are the usual causes and the order that finds them fastest. Test on your own board; clones and cables differ.

Why this happens

I2S uses three signal wires for this microphone: a bit clock, a word select line that marks the left and right slots, and a data line. The ESP32 is the master and generates the clock and word select; the microphone only drives the data line. Each frame has two 32-bit slots, so the bit clock runs at 64 times the sample rate. The microphone puts 24 bits of data at the top of its slot, most significant bit first, and the remaining low bits are zero.

The L/R pin selects the slot the microphone talks in. With L/R tied to ground it uses the left slot. If your driver is set to read only the right channel, it will receive the other, empty slot, which is all zeros. A floating L/R pin makes the choice unpredictable. Reading 32-bit words without shifting gives numbers that are 256 times too large, but a correct reading still changes when you clap.

How to confirm the cause

  • Print a block of raw 32-bit values with the room quiet and then while clapping. Values that change with sound mean the wiring works and only the processing is wrong.
  • If every value is exactly zero, swap the channel setting in the driver (left or right) and check the L/R pin level with a meter.
  • If every value is the same non-zero number, the microphone is not getting a clock. Check the bit clock and word select wires and the pin numbers in the configuration.
  • Check that the module is powered from 3.3 V and that ground is common.
  • Check that the clock and word select pins are output-capable. GPIO 34 to 39 are input-only on the classic ESP32, so they cannot drive the clock.

Worked example

Reading samples with the legacy driver in the ESP32 Arduino core 2.x. Newer cores have a different I2S API, so match the example to your core. Pin numbers and driver setup are omitted here.

// config: 32-bit samples, left channel only (L/R pin at GND)
int32_t raw[64];
size_t bytes = 0;
i2s_read(I2S_NUM_0, raw, sizeof(raw), &bytes, portMAX_DELAY);
for (size_t i = 0; i < bytes / 4; i++) {
  int32_t sample = raw[i] >> 8;   // 24-bit signed value
  Serial.println(sample);
}

Common mistakes

  • Powering the module from 5 V. The datasheet supply range tops out at 3.3 V.
  • Leaving the L/R pin unconnected.
  • Using a 16-bit sample setting in the driver for a microphone that outputs 24 bits in a 32-bit frame.
  • Mixing the clock and word select wires.
  • Using long jumper wires for the clock line, which adds noise and edge errors.

If this did not fix it

  • Check the sample rate. A mismatch between the configured rate and the pin timing can give noise instead of silence.
  • Check for a core or library update that changed the I2S API, since old examples fail silently on new cores.
  • Try a second microphone module in case one is damaged by a wrong supply voltage.