PDM microphone glitch at beginning of the recording

[frnt]

Hello,

I'm using the IMP34DT05 microphone using the I2S interface. I'm sampling at 22kHz but I have a problem when I look at the recording saved on micro SD. In the first part of the audio, I see a glitch and then an exponential decay of that spike (see attached image).

The strange thing is that not all the recordings have such a glitch at 0.046 s, which is exactly after the first 512 Bytes (see second screenshot).

The PDM data are converted to PCM using the PDMFilter function. Any suggestion on how to get rid of this? and the reason why is happening?

 

[SPozz.1]

Hello,

about audio_file_0, before 0.046s I can't see any signal, seem that the first 512 bytes you mention are saturated over 1.0. Check the microphone's DOUT and CLK with a scope. It should be very easy to check if the signal you see matches what is being written to the file. You may be surprised to see that the microphone works perfectly and the data becomes corrupted afterwards. "512" seems to be related to a memory block or a sector of the SD card or to unflushed FIFO or something else, rather than a real glitch in the digital domain of the microphone.

[frnt]

Dear @SPozz.1​ ,

I did some additional test. The code flow is the following:

• microphone power on
• HAL_I2S_Receive_DMA(.....)
• dma_state = DMA_WAIT;
• Start acquisition loop
• HAL_I2S_DMAStop(...);

Now all the recordings show the same behavior with a well-defined saturation 186ms after power on, then saturation last up to 195ms, then the signal saturate negatively and then there is an exponential decrease before reaching a stable behavior.

I really do not understand why. The first 512Bytes has to deal with SD write blocks.

 

[SPozz.1]

I don't know on which mcu type you are running your code, maybe this is your case: https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices

/* Invalidate D-cache before reception */

/* Make sure the address is 32-byte aligned and add 32-bytes to length, in case it overlaps cacheline */

SCB_InvalidateDCache_by_Addr((uint32_t*)(((uint32_t)rx_buffer) & ~(uint32_t)0x1F), RX_LENGTH+32);

/* Start DMA transfer */

HAL_UART_Receive_DMA(&huart1, rx_buffer, RX_LENGTH);

/* No access to rx_buffer should be made before DMA transfer is completed */

[frnt]

Hello @SPozz.1​ ,

I'm using an STM32WL (M4 core). I'll try to look at the thread you shared but at first look the cores are different and the M4 memory layout is much simpler

[frnt]

Dear @SPozz.1​ ,

as suggested I have looked with the scope and when the I2S clock appears, I see immediately data coming from the DATA signal of the microphone.

I have fixed I small bug in the code that was creating the first portion without audio.However, there is still 25ms of garbage and then there is the exponential behavior. From the datasheet, ST reports the turn-on time as 10ms as maximum. Could it be that this time is larger?

[SPozz.1]

Turn-on time should be not greater than 10ms, but you can check it by introducing a HAL_Delay(50) in main, just after HAL_Init() and hardware initialization.

As the signal is initially saturated at bottom, then at top and then at bottom again, look with the scope if the PDM signal follows the same behaviour. This should give you a chance to rule out that the microphone is the problem. Pulse density should be very high when the signal is top-saturated and very low when the signal is bottom-saturated.

 

Since the signal shape is changed after the bug fix, it seems that the problem is due to the firmware. Try changing something, for example introducing delays, see if this changes the signal shape, and if you can get some new clues that help you understand where the problem is.

PDM stream needs to be filtered and decimated to be converted to PCM, the problem may arise in the filter during conversion. This would explain the exponential behavior of the signal before stabilization.

[frnt]

Dear @SPozz.1​ ,

you were right, with the scope I see that the PDM signal has high density of one and then of zeros before starting recording.

The i2s clock is available right after the call to:

HAL_I2S_Receive_DMA

Therefore is not easily possible to add the "Turn-on" delay by software. It is equivalent to skip the first 10ms of data. Therefore, I did not write into the SD card the first bunch of PCM-converted data, obtained from the PDM filter. I have skipped about the first 400ms.

I'm sharing a few recordings: https://www.dropbox.com/t/6msnhkugsKUvc3S0

The recordings have no sound and are taken in a quiet environment. I you can see they are very noisy.

Here few recordings with 800Hz pure tone: https://www.dropbox.com/t/GfkBRrxg04smdoo5

Also in this case the sound is very noisy.

The PDM filter is configured as:

• PDM_FILTER_BIT_ORDER_LSB;
• PDM_FILTER_ENDIANNESS_BE;
• high_pass_tap = 2104533974;
• in_ptr_channels = 1;
• out_ptr_channels = 1;
• decimation_factor = PDM_FILTER_DEC_FACTOR_128;
• output_samples_number = 512;
• mic_gain = 30;

PDM_FILTER_BIT_ORDER_MSB or PDM_FILTER_BIT_ORDER_LSB seems to have effect on the final output.

Do you have any suggesting on why it is so noisy?

Best,

[frnt]

Dear @SPozz.1​ ,

do you have any suggestion on reducing this background noise? Sorry for using the dropbox link, I didn't find the attach file button before.

I have tried changing the data frame from 24bit to 32bit, but nothing changes. I have tried activating the CRC but I don't see any difference by enabling or disabling the CRC.

Is getting me crazy this noise... If you increase the volume you can ear it very well even in the track with 800 Hz sound and this is quite annoying.

Best,

[SPozz.1]

While this microphone has decent PSR (Power supply rejection), you may have a lot of power supply noise, which should be filtered out. You should check the power supply with an oscilloscope, possibly with FFT parsing if it is present.

It could pick up vibrations or noise generated by nearby circuits, like DC/DC converters; it is known that a ceramic capacitor, due to the piezoelectric effect, moves and transmits vibrations to the PCB when a non-DC voltage is applied to its ends. Vibration may be generated by nearby devices, like fans or hard-disks; if you are testing with the board on a table, put a vibration damper like an open cell foam block in the middle.

You might also have a bug/miscalculation in the PDM->PCM conversion chain. You can verify it by simulating the microphone's PDM signal, creating an in-memory table with a perfectly clean PDM data and use a for/while loop or the DMA to send the table data to the PDM->PCM conversion algorithm/peripheral and see if the resulting PCM signal is actually clean.

This is the spectrum analysis of your audio_file_0_silence

noise near 100Hz is very high