Microphone Array - PDM Demodulation - Custom FPGA Code


#1

Hi all,

I am currently working on a project that will enable the microphone data to be read and saved in a similar fashion to that of micarray_recorder. The intention is to provide easier direct access to the microphone data and an improved sample rate. Additionally, having briefly tested the array in a semi-anechoic chamber at various single frequencies, the harmonic distortion is very high which I can only contribute to the demodulation process itself.

Harmonic distortion will be present, that is an inevitable fact! However it shouldn’t really be this high and all the sigma-delta modulation / demodulations I have modelled in Matlab / Simulink confirm this (60 dB THD), even using only a CIC filter for full demodulation of a 64 x Fs PDM signal where Fs = 48 kHz. I can only assume they have used CIC decimation filters as the Spartan-6 only has 8 DSP slices, which massively limits things!!

Anyway, to get to the main point, I am unsure of the best way to send the data from the FPGA over to the Pi and save it in a file (as raw format or else). I have used UART before when wanting to do this from an FPGA (linked to Matlab or Teraterm), however I’m not convinced this is the best method for it. I think creating a program in C/C++ as with micarray_recorder is the best way forward however my C/C++ is fairly limited at the moment so any help / advice or pointing me the right direction will be greatly appreciated! I’m happy to share info, code, models etc if anyone so wishes!

Thanks in advance.


#2

Hi @kool_herc,

Really interesting your test with the microphones. Answering your questions:

  • The way the data is sent from teh PFGA to the Raspberry Pi is using SPI. Not sure if you are trying a different approach. You can right now get data using HAL library (C++ HAL examples). Are you trying to stream data to Matlab ? Not sure what is your goal here.
  • What language you are confortable with ? We currently have the microphone data sent to ALSA so you can get mic data from various languages.

We are finalizing the support for multiple sample frequency up to 48KHz and support for Pyaudio and Portaudio for the microphone data for Raspbian Stretch. Will keep you posted on this.

Please feel free to share any progress on your project, code, graphs, results or suggestions!

Yoel


#3

Hi Yoel

Many thanks for the reply!

My ultimate aim is to develop a sound localisation system based on the MUSIC algorithm, which was the basis of my dissertation. Ideally this would be fully performed on the FPGA however given the limitations off the Spartan-6 I am hoping I may be able to daisy chain another FPGA through the GPIO’s.

Initially, I’d like to get the signal data from microphones so I can verify that I am performing the demodulation correctly and everything is working properly there, before I develop the full localisation code. I’d prefer to save the signal data in a file, then analysis it in Matlab after, rather than stream it directly. I’m okay-ish on the FPGA side of things and can develop the protocol to send the data, I’m just bit unsure how to go about receiving it and then saving it as a file on the host PC. I know Python and C, but my C++ is lacking, so I think I will have to improve this!!

Unless I’m mistaken, 8 channels of 48kHz, 16 bit audio, will require at least 6.144 Mbits/s transfer rate, so surely SPI and UART are unsuitable for this process? I’m working on just a single stream at the moment so it is not a major issue for me as yet.

Obviously, as I intend to develop this solely on an FPGA I would need the demodulation code anyway, and as the MUSIC algorithm works on correlation I really could do with limiting the harmonics as much as possible. Admittedly I have only modelled up to 2nd order ‘standard’ sigma-delta process as it becomes unstable after that, while it is possible for 4th order delta-sigma (as with the mics), the arrangement is modified and I’m struggling to find out which process the manufactures use! As said, the demodulation process is basically same in each case so this is more to understand why the harmonics are a lot higher than predicted.

I’ll neaten up some of the Matlab / Simulink models that I’ve done and upload them later.