I2S Microphone (SPH0645LM4H-B)

[gfvalvo]

Hi All.

Wondering if anyone has looked at the I2S Microphone breakout module over at Adafruit:
https://www.adafruit.com/product/3421

Datasheet for the device itself is here:
https://cdn-shop.adafruit.com/produc...0Datasheet.PDF

The I2S timing for this device looks odd. It expects the WS (aka Frame Sync, aka LRCLK) signal to transition on the falling edge of BCLK while the Data transitions on the rising edge:


This is different than every other I2S device I’ve looked at. The NXP SGTL5000 for example:


I’m not even sure the Teensy 3.2 (MK20DX256) can do this since it looks like the Bit Clock Polarity (BCP) field in the I2Sx_TCR2 register applies to both LRCLK and Data.

Appreciate hearing thoughts on this topic.

Thanks.

PS -- I’ve posted a similar question on the Adafruit forum. No response so far:
https://forums.adafruit.com/viewtopic.php?f=19&t=125101

[PaulStoffregen]

That is very odd. I2S almost always shows the rising edge of BCLK in the center of each data bit.

As a quick sanity check, I connected my scope to a Teensy 3.6 with the audio shield. Here's a couple screenshots of the actual signals.




(click for full size)

[gfvalvo]

Thanks for the quick response Paul. Agreed, I haven’t seen any other “I2S” device where Data and LRCLK transition on opposite edge of BCLK.

Guess I’ll try shooting an email off to the manufacturer and see what happens.

Greg

[PaulStoffregen]

If you actually have the mic, just connecting it to Teensy and watching what it actually transmits on its data when when it receives the 2 clocks would probably be the simplest way to find out with certainty.

Don't forget to put a pulldown resistor on the data pin, or maybe even a pair of resistors to bias it to some particular voltage, so you can see on your scope when the mic isn't actually driving the data pin.

[gfvalvo]

Yea, I’m just gonna order a couple and try. The more I look into it, the more I think that it’s just a datasheet error. Adafruit states that this microphone works with their Feather M0 (Atmel SAMD). I don’t see any evidence in this processor's spec sheet that it supports this unconventional opposite-clock-edge protocol.

I’m thinking it’s going to need a tweaked Audio Library I2S input object since the data format is 18 bits.

Will post results.

Thanks again.

[PaulStoffregen]

Maybe post to this thread a link on the Adafruit forum, so people who find that thread can access the info here.

[gfvalvo]

Good idea, done.

[gfvalvo]

OK, got the part, wired it up, and took some scope shots. See below:


Top Trace: LRCK (from T3.2)
Middle Trace: BCK (from T3.2)
Bottom Trace: Data (from mic)


Data is indeed changing on the rising edge of BCK -- just the opposite of LRCK. So, the device’s data sheet was correct and it’s in clear violation of the I2S spec. What were they thinking?

Suppose I could put Data into a DFF that’s clocked with the falling edge of BCK. Output of DFF would go to I2S0_RXD0 on T3.2. That would get Data transitioning on the proper edge and fix the timing for T3.2 input. What a pain. Diagram below.

[PaulStoffregen]

Looks like they are keeping the data signal valid for a short time after the rising edge. If I'm reading this right, it really looks like they're just doing the output almost a half cycle earlier than normal. Hopefully their brief valid data time after the rising edge will meet the required hold time.

I'd guess there's a good chance this will actually work.

[gfvalvo]

The datasheet specs a maximum propagation delay of ~66ns from rising edge of clock input to data output valid (Tdc in timing diagram below). This part’s showing about 20ns. The K20 Datasheet claims a 0ns required hold time on I2S0_RXD0 after clock transitions. So, yes, it should “work”. Feels “icky” though.

[PaulStoffregen]

Yeah, their datasheet has only a maximum for "tDC" (Data Delay from CLK Rising Edge). The big question is what would the minimum possible be? There's a big empty hole in the table on page 4 for the min spec. That's less than ideal, since the I2S communication depends on the data meeting the setup and hold time of whatever is receiving the signal. Fortunately Teensy has a zero hold time requirement and your scope seems to be showing about 20ns, so I'd say you're probably in pretty good shape, as long as you don't use any logic chips or other stuff that might delay the clock. Hopefully that 20ns doesn't become much, much less at other temperatures or vary much between mic chips.

[cbuxton]

Hi, New here.

Attached two of the adafruit mics for stereo and ran through Paul's example peak tutorial.
As you can see it looks like they work.

[janwillemp]

Hi, new here too. I came to the forum to ask a question about these microphone when I saw this topic. I can confirm the exact same behavior ( haven't figured out how to include scope screenshots here, yet) and alos that they work. However, I'm not really happy with the performance, and I wonder if this behavior may have to do with it. I wired a pair of these mics to usb audio and notice that the mic levels when the room is mostly silent are fairly high (4 out of 15 notches on the mac audio settings screen) but the gain is very low, so I can never max it out. Have to route a Mixer in between to make a normal voice recording from half a meter audible.

I notice on my scope readings, and similarly on the picture @gvalvo posted that the first 5 data bits are always high, consistently. Could this somehow be related to the odd timing requirements? Datasheet requires this:

I2S Timing And Port Configuration Guidelines
• BCLK period must be in the range shown in Figure 2
• WS must be synchronized(changing) on the falling edge of BCLK
• WS must be BCLK/64
• The Hold Time (see Figure 2) must be greater than the Hold Time of the Receiver
• The mode must be I2S with MSB delayed 1 BCLK cycle after WS changes

[gfvalvo]

For what it's worth, I've ordered two of these microphones:
https://store.arduino.cc/usa/ics4343...tal-microphone

They use the ICS43432 device. It's datasheet shows proper I2S timing:
https://www.invensense.com/wp-conten...sheet-v1.3.pdf

I'll report back test results after evaluation.

[janwillemp]

hehe, same here, instead i ordered an ics43434 breakout from tindie because arduino store wouldn't ship to my country.

[gfvalvo]

For what it's worth, I've ordered two of these microphones:
https://store.arduino.cc/usa/ics4343...tal-microphone

They use the ICS43432 device. It's datasheet shows proper I2S timing:
https://www.invensense.com/wp-conten...sheet-v1.3.pdf

I'll report back test results after evaluation.

Here’s some scope shots from the ICS43432 microphone:


Top Trace.......WS (aka LRCLK)
Middle Trace....BCLK
Bottom Trace....DATA



As you can see, this device does conform to the I2S timing spec. It also seems to perform better than the SPH0645LM4H-B unit, although I haven’t done extensive testing.

While the microphone from Adafruit (Knowles SPH0645LM4H-B device) did work (for some definition of “work”), I prefer this one. I’ve never been a fan of ignoring timing specs or pushing margins. In doing so you essentially become an unpaid test pilot.