Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 16 of 16

Thread: I2S Microphone (SPH0645LM4H-B)

  1. #1
    Senior Member
    Join Date
    Feb 2017
    Posts
    418

    I2S Microphone (SPH0645LM4H-B)

    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:
    Click image for larger version. 

Name:	SPH.jpg 
Views:	117 
Size:	39.9 KB 
ID:	11793

    This is different than every other I2S device Iíve looked at. The NXP SGTL5000 for example:
    Click image for larger version. 

Name:	SGTL2.jpg 
Views:	114 
Size:	87.1 KB 
ID:	11794

    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

  2. #2
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,075
    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 image for larger version. 

Name:	file.png 
Views:	151 
Size:	52.8 KB 
ID:	11796

    Click image for larger version. 

Name:	file.png 
Views:	122 
Size:	47.0 KB 
ID:	11797
    (click for full size)

  3. #3
    Senior Member
    Join Date
    Feb 2017
    Posts
    418
    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

  4. #4
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,075
    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.

  5. #5
    Senior Member
    Join Date
    Feb 2017
    Posts
    418
    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.

  6. #6
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,075
    Maybe post to this thread a link on the Adafruit forum, so people who find that thread can access the info here.

  7. #7
    Senior Member
    Join Date
    Feb 2017
    Posts
    418
    Good idea, done.

  8. #8
    Senior Member
    Join Date
    Feb 2017
    Posts
    418
    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.

    Click image for larger version. 

Name:	Frame.jpg 
Views:	104 
Size:	145.0 KB 
ID:	11845

    Click image for larger version. 

Name:	LRCLK.jpg 
Views:	116 
Size:	123.9 KB 
ID:	11844

    Click image for larger version. 

Name:	Zoomed.jpg 
Views:	103 
Size:	126.6 KB 
ID:	11843

    Click image for larger version. 

Name:	Logic.jpg 
Views:	178 
Size:	48.1 KB 
ID:	11842

  9. #9
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,075
    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.

  10. #10
    Senior Member
    Join Date
    Feb 2017
    Posts
    418
    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.

    Click image for larger version. 

Name:	Prop Delay.jpg 
Views:	170 
Size:	64.9 KB 
ID:	11846

  11. #11
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,075
    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.

  12. #12
    Junior Member
    Join Date
    Oct 2017
    Posts
    5
    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.

    Click image for larger version. 

Name:	Mic Sample.jpg 
Views:	233 
Size:	101.9 KB 
ID:	11848

  13. #13
    Junior Member
    Join Date
    Oct 2017
    Posts
    3
    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

  14. #14
    Senior Member
    Join Date
    Feb 2017
    Posts
    418
    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.

  15. #15
    Junior Member
    Join Date
    Oct 2017
    Posts
    3
    hehe, same here, instead i ordered an ics43434 breakout from tindie because arduino store wouldn't ship to my country.

  16. #16
    Senior Member
    Join Date
    Feb 2017
    Posts
    418
    Quote Originally Posted by gfvalvo View Post
    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.

    Click image for larger version. 

Name:	n_frame.jpg 
Views:	68 
Size:	139.3 KB 
ID:	11897

    Click image for larger version. 

Name:	n_lrclk.jpg 
Views:	55 
Size:	121.6 KB 
ID:	11898

    Click image for larger version. 

Name:	n_eye.jpg 
Views:	88 
Size:	133.6 KB 
ID:	11899
    Last edited by gfvalvo; 10-26-2017 at 03:28 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •