How can I calculate the exact Audio frequency of a MEMS microphone?

[MAndr.7]

Hi,

I developed an application that uses an STM32L452 and MP34DT06J, with SPI and DMA. I don't have an external clock on the MCU so I'm using the internal one. Regarding the storage, I'm using an external Micro SD driven with SDMMC.

Since I've more sensors acquiring at the same time, for me it's extremely important to know the exact frequency of the signals since it can lead to a misalignment of the signals. When I was recording sound with my application and comparing it with my smartphone, I found that the sampling frequency isn't exactly 16kHz. So the questions are:

1. How can I find the exact frequency?
2. Does the internal clock allow me to have a constant sampling frequency, with drift over time?

Best Regards

[KnarfB]

> for me it's extremely important to know the exact frequency of the signals since it can lead to a misalignment of the signals

If all sampling instants are derived from the same clock, there should be no drift between the signals.

If you have a different master clock, feed the audio clock to a 32-bit timer/counter and record the counter value together with the other data for later correlation.

If you know the total recording time of your data (from a wall clock, GPS,...) you may adjust the audio speed afterwards by a tool like audacity to match the correct play time.

hth

KnarfB

[gregstm]

I don't bother trying to calibrate the HSI/MSI - I just use the LSE clock as the drumbeat for everything (input/output audio). DMAing the data from the DFSDM to a single location (let's call it location X) ensures that the data is up to date at location X (and independent of the LSE clock), and I then use the LSE driven timer to sample location X as if it was any other analogue source. Basically I'm using the DMA channels to re-sample the data at an accurate rate.

[LCE]

@Community member​  That's interesting, thanks for the explanation!

What is your effective final sampling rate then?

[gregstm]

I sample from the DFSDM at a rate of 16,384Hz (using the DMA to put it into a circular buffer). For DAC output I use 32,768Hz using the method I described here https://community.st.com/s/question/0D53W00001oXHXKSA4/how-did-i-miss-this-32khz64khz-dma-using-lse

[Piranha]

Yes, that 200 ps is a peak-to-peak jitter. The RMS jitter is 15 ps, which at 20 kHz gives 114 dB or 19 bits. Sorry, I didn't pay enough attention to the "RC" part. Thanks, good to know such information! I guess the HSE was used with a crystal, not fed some external clock signal?

[LCE]

@Piranha​ I got these very good results with the HSE from all non-RC sources until now, even the MCO from the ST-Link MCU on the Nucleos, which was a really nice surprise:

• F767 (and some G4) Nucleo: 8 MHz from ST-Link
• H723 Nucleo: 8.333 MHz*** from ST-Link
• H735 discovery kit : 25 MHz from oscillator
• F767 custom board: 8 MHz crystal

*** The 8.333 MHz (25M/3) started as being a real pita, but through that I learned that the FRACN of the H7 PLL can be changed on the fly so that I can use that as VCO - great stuff!

I actually found out about the H723 Nucleo's default clock source being the STLink's HSI (was it? or the H723... anyway, some crappy HSI) because I just had ethernet running (ported my F7 driver) but with abysmal PTP timings (a factor of about 1000 worse, from 100 ns to 100 µs). As soon as I didn't use the HSI anymore, PTP was good again.

I should have started with the TX SPDIF signal...

[Piranha]

By the way, read this:

https://community.st.com/s/question/0D53W00001wqRPySAM/fractional-mode-register-changes-need-a-delay

Do you have any data on how using the fractional mode impacts the PLL jitter?