2023-11-30 05:57 AM
Hello ST community,
I am unfortunately facing a problem with the MP34DT05-A MEMS microphone. I am using the DFSDM module to read in the microphone. Unfortunately, it happens again and again that extremely strong noise is added at a random time (see picture: At first, almost no noise can be recognized. Likewise after the first peak, which is a clap in the recording. After that, however, there is suddenly a very strong noise). I cannot clearly reproduce the behavior, as the noise sometimes occurs from the beginning, then after 2 seconds and so on. I have defined the DFSDM module as follows:
System Clock: 80MHz
Channel 2: mode PDM/SPI input from ch2 and internal clock
Output Clock: Divider 40
Channel 2: Type SPI with rising edge, SPI Clock with rising edge, Filter Order FastSinc filter type, Oversampling 1
Filter 0: regular channel selection Channel 2, Continous Mode, Fast Mode Enabled, Dma Mode Enabled, Sinc Order Sinc3 filter type, Fosr 50, Iosr 1
Has anyone had similar experiences?
2023-12-03 10:52 PM
Hey ChRegBrg
I had a similar problem with the mp23db01 (if I remember correctly), with random noise that came and went.
I found out that it was not due to data coming from the mic, instead the problem was in writing those data in my SD card (fixed just by getting a better sdcard)
maybe it's something like that?
2023-12-04 12:55 AM
Hi,
thanks for your reply. It could be something like that but i dont't write the data to an SD-Card. I am using the full and half complete callback of the DFSDM-Module. Here i set an Flag which indicated that upper or lower half of the buffer is ready to transmit. In the main while loop i check for these Flags and transmit the data via UART to my Computer where i have a Python script running an collecting the data. I checked the UART Tranmission - there are no collisions of the single transmissions. I dont know what else to check.
Greetings,
Christian
2023-12-13 01:42 AM
Hi @ChRegBrg ,
We don't think it's a problem related to our device, you might try testing the communication channel first.
For example, by overwriting the microphone buffer with a counter so as to send known data and verify that it reaches the PC correctly.
2023-12-13 02:11 AM
Hi @Federica Bossi ,
thanks for your response. I suspected something similar as you and therefore examined everything in debugging mode and the oscilloscope. I can now say with certainty that the errors do not come from the microphone, the connection from the microphone to the microcontroller, the processing software in the microcontroller or the UART connection from the microcontroller to the PC!
Rather it seems that there is a bug in the Windows driver for the COM-ports which only gets noticeable at very high baud rates. Due to some error, individual bits or bytes are lost (Which causes the "noise") resulting in completely useless data. In my research I also found that this my have something to do with the scheduling in Windows, among other things. Various forum posts have pointd out that this problem may not exist unter linux. However I haven't checked this myself.
Greetings,
ChRegBrg