1

I have interfaced a I2S digital microphone to PIC32MZ controller. I am able to read the digital output from the microphone over I2S-DMA transfer.

Following are the details of my set-up:-

  1. Controller:- PIC32MZ1024EFE064
  2. Audio Sensor:- SPH0645LM4H-B
  3. MPLAB Harmony Configurator (MHC) v2.0.6.0

When I play some tone near the microphone, I get somewhat these values:-

  • 0xFA8C8000
  • 0xFA8AC000
  • 0xFA6EC000
  • 0xFA6C8000
  • 0xFA600000
  • 0xFA544000
  • 0xFA6E0000
  • 0xFA6AC000

I tried to cover the microphone with glue and tape (so that it does not catch any audio signals), and got the following values:-

  • 0xF9DD0000
  • 0xF9DD0000
  • 0xF9D9C000
  • 0xF9D80000
  • 0xF9D6C000
  • 0xF9D5C000
  • 0xF9D4C000
  • 0xF9D3C000
  • 0xF9D30000
  • 0xF9D24000

In the answer to the post Digital Microphone : I2S data output, it is mentioned that the I2S has a rather weird one clock offset compared to the other common formats, and if you get this wrong you will always see a 1 in the MSB of the recovered sample which causes everything to appear negative if interpreted as a signed value.

In my set-up, the MSB is always 1 (or 0xF), no matter what input I give to my microphone. I am planning to use my data to calculate the mean, average and peak-to-peak values. So, the sign-bit is important to me.

Now, I have used MPLAB Harmony to configure my I2S.

My questions are,

  1. If the one clock offset of the I2S clock is causing the MSB of my data to always be 1, which settings/code should I modify in MPLAB to resolve this issue?
  2. Apart from the I2S clock issue, what else can be the issues that I must resolve in order to read correct data from my microphone?

Thanks in advance

Sandrocottus
  • 431
  • 2
  • 5
  • 11

1 Answers1

1

Your MSb is likely set because the electrical signal entering the ADC has a significant DC offset from the mid-point of the ADC. Try capturing data points and "viewing" the signal graph when there are periods of quiet and periods of high levels of sound present. If necessary capture some data and view it in excel or something similarly usable to graphically view the data.

Your microphone has a sensitivity of -26 dBFS per RMS pascal (94 dB SPL) at 1 kHz. So with an RMS sound pressure level of 94 dB at 1 kHz I would expect a digital reading of -26 dB compared to full scale. -26 dB is about 5% of full-scale so, if you are expecting the microphone to produce a big audio signal that might have a relatively small DC offset, please consider this as unlikely; your digital audio signal will be small and "sat" on top of a large digital DC offset.

Andy aka
  • 434,556
  • 28
  • 351
  • 777
  • Hi Andy, Thanks a lot for your answer. For removing the DC offset and normalize the sample set, I have calculated the mean value of the sample set and subtracted it from each value in the sample set. Then, I found the maximum and minimum values form the sample set and calculated the peak-to-peak value. After that, I calculate the rms value by dividing the peak-to-peak value by square-root of 2. Then, 20 * log10(rms) gives me the corresponding decibel value. – Sandrocottus Nov 29 '18 at 12:45
  • However, I am not sure that:- 1.Does the above logic take care of the " offset " that you mentioned? 2.I am yet to find a test plan to verify the calculated decibels, but have I mathematically calculated the decibel value correctly? – Sandrocottus Nov 29 '18 at 12:46
  • RMS is more complex because you are not dealing necessarily with a sine wave. If it is a sinewave then it is the peak value you use not p-p. – Andy aka Nov 29 '18 at 12:53
  • Okay, so I need to change the way I calculate the rms value. Maybe, I should calculate it by using the actual rms formula of squaring values, adding them, taking average, then calculating the square root. – Sandrocottus Nov 29 '18 at 12:58
  • Atleast, did I get the offset" part correct? – Sandrocottus Nov 29 '18 at 12:59
  • The offset part sounds correct but I'd still be interested in viewing the raw data values if I were you; just to make sure that there isn't some number-crunching anomaly or there isn't the problem that you initially suspected i.e. the bit shift. – Andy aka Nov 29 '18 at 13:02
  • Hi :@Andy aka: Need your suggestion on the "decibels" part. I calculated the average value of the sample (sum of samples / number of samples). Then I subtracted it from each sample to normalize the sample set. Now, I found the rms value (square-root((sum of squares) / number of samples))). Then I divided this number by 2^17 (since values range from 2^-17 to 2^17 - 1). After this I calculate 20*log10(value), which yields a negative value. Could you suggest how do I relate this value to "decibels"? Sensitivity of my sensor is -26dBFS at 94 dB SPL @ 1 kHz. – Sandrocottus Dec 07 '18 at 09:22
  • What was the RMS value? – Andy aka Dec 07 '18 at 09:26
  • The RMS value = 260.0942137 – Sandrocottus Dec 07 '18 at 09:33
  • 1
    This is about 0.2% full scale and this is 25 times smaller than the reading you would get for 94 dB SPL (one pascal). So it is 0.04 Pa (RMS). In terms of dB SPL, one-twentyfifth is a reduction of 28 dB or an SPL of 66 dB. – Andy aka Dec 07 '18 at 09:39
  • Thanks a lot! This really helps. Also, I really gained from your suggestions in the posts and . Unfortunately, due to my low reputation, I cannot vote-up for you, but your knowledge in this field is highly appreciated. Thanks a lot once again. – Sandrocottus Dec 07 '18 at 09:57
  • I think your reputation may be high enough but no problems. – Andy aka Dec 07 '18 at 10:25
  • :-) Was 13 before this, will vote-up. Thanks a ton! – Sandrocottus Dec 07 '18 at 10:26
  • I am facing a weird issue with my microphone. Whenever I play loud audio, the calculated decibel value increases. However, once I lower the audio sound or stop it, the decibel value does not decrease. It increases on playing louder sound, but never decrease. Any suggestions on this? – Sandrocottus Dec 07 '18 at 14:13
  • That sounds like a software issue to me - maybe you can output the digital data to a DAC and feed the DAC analogue to an audio amp. Are you re-calculating the average value continually because there may be a shift after a loud audio sound has been heard but it does sound like a code problem rather than the mic itself. – Andy aka Dec 07 '18 at 14:52