I2S input example doesn't work with common MEMS microphones

[timboldt]

I was experimenting with a common I2S MEMS microphone (https://www.adafruit.com/product/3421) and it didn't work.

In retrospect, I think I found the problem. The datasheet (https://www.mouser.com/datasheet/2/218/ph0645lm4h_b_datasheet_rev_c-1525723.pdf) says that the SPH0645 needs a minimum clock rate of 1MHz in order to wake the device.

However, the example (https://github.com/earlephilhower/arduino-pico/blob/master/libraries/I2S/examples/I2SInput/I2SInput.ino) has 22050Hz * 16 bits * 2 channels = 705600Hz = 0.7MHz.

If you are interested, I can update the example to work with a modern I2S MEMS microphone, and send you a PR.

[earlephilhower]

Thanks, but the specs of the mikes really do differ. The one I built on and documented in the code is from the GOOG AI-Yourself pack that's got a nice PCB w/stereo MEMS chips with a nice separation between them, and they happily work at 22Khz, for example.

Maybe you'd like to do a PR adding some comments in the example like, "for the Adafruit mike, or if your mike doesn't seem to be reporting data, use XXKhz"? That way we cover all bases. The current comments spec a particular mike, and your add'l ones will cover some other options?

[timboldt]

You proposal sound reasonable.

I'm still having trouble getting the I2S data line to respond at all with an RP2040, so I'll do some digging with a Saleae and compare it against a different known-working microcontroller.

[timboldt]

It produces data with a Feather M0 and their example program at https://learn.adafruit.com/adafruit-i2s-mems-microphone-breakout/arduino-wiring-and-test:

I'll repeat the exercise with an RP2040.

[timboldt]

I was able to get the Pico to cooperate finally:

Next, I'll send a PR, adding some comments for how to configure an Adafruit I2S MEMS microphone to work with the example.

[timboldt]

One other thing to note is the difference in the LR clock, which is aligned with the falling clock in one case and the rising clock in the second case. I'll have to dig through the data sheets for both devices to see which (or both?) are correct.

[timboldt]

It looks like WS (LR Clock) is supposed to switch during a falling clock, but the Pico is doing the opposite, so the PIO code might be incorrect for WS (LRCLK).

This is true for both devices in question:

ICS-43434 (in Google AIY kit): https://invensense.tdk.com/wp-content/uploads/2016/02/DS-000069-ICS-43434-v1.2.pdf
SPH0645: https://www.mouser.com/datasheet/2/218/ph0645lm4h_b_datasheet_rev_c-1525723.pdf

Also of note, the ICS-43434 accepts 400kHz-3MHz and the SPH0645 accepts 1MHz-4MHz.

I'll keep exploring.

[timboldt]

The misaligned LR Clock looks like a fairly minor bug.

It seems to cause the most significant bit of one channel to leak into the least significant bit of the previous channel. As a result, the silent channel has a value of 1 and the non-silent has a value that is double what it should be.

The issue is partially mitigated by the fact that the top 2-3 significant bits are usually 1s.

Interestingly, the original Micropython code seems to have the same bug. Only the older SAMD21 code from Adafruit is correct.

If we did want to fix that, we'd probably need to run the PIO clock twice as fast, so that the LR Clock could be delayed half a BCLK cycle.

But at least the original reported I2S issue is resolved.

[KSpotter]

SPH0645 microphones do not follow standard I2S timing. The data output is modified and sampled on the opposite edges of the SCLK signal.

Compare the timing diagrams from the SPH0645 datasheet and the ICS-43434 datasheet

SPH0645 timing:

• Data output changes on rising edge of SCLK
• Data output is sampled on falling edge of SCLK

Standard I2S timing :

• Data output changes on falling edge of SCLK
• Data output is sampled on rising edge of SCLK

The I2S library implements the standard I2S timing. The different timing specifications for the SPH0645 can cause unpredictable or erratic changes in the captured audio (e.g., significant DC offset).

@earlephilhower Is it easy to add support for the non-standard SPH064 timing?

I am unsure how to modify the I2S/src/pio_i2s.pio file to handle the timing differences. I have never compiled PIO code.