Electronics > Projects, Designs, and Technical Stuff

An STM32H7 based Audio Analyser (or so it begins...)

(1/4) > >>

Hey all,

I wanted to share this project with you and ask for advice as well.

First of all, feel free to ask questions or use any resources here presented as you wish, as well as suggesting improvements.

I'm a bit of an audio buff. Not the "virgins in the moonlight" and "golden Ethernet cables" guy, more of a "I want it to measure and sound good" sort of person. I had a chance to work eons ago with an Audio Precision unit at Uni, and it was such a pleasure. However, I didn't like:

* The price
* The fact that it's only windows
* Some proprietary PC - unit interface
I used it mainly to see frequency response on DSP's transfer functions and just fun really.

Years later I bought the QA200 (I guess that was the name), it was a cheap chinese Audio Analyser which worked Ok but it required some .NET BS framework installs, the USB port protocol was proprietary and I could not get it to run on Linux either. By the way, I'm not against Windows, happy to use it at work, but my choice is Linux at home just because after 10+ years I got very used to it. I sold that unit a year or so later after I measured what I wanted to measure (I think it was the output of a Headphone amp and some OpAmp things).

For the last 3 or so years (I move slow) I've been working on an Audio Analyser myself. Requirements:

* STM32 based
* Linux and Windows compatible
* Ethernet IF to the PC (open and easy)
* Have a simple UI that I can expand
The motivation for the above was also that Ethernet is electrically decoupled from the PC (unlike USB). And I get around with LWIP. Plus it's fast. And no drivers required.

I purchased an STM32H7 board (400MHz!) when they first came out 2017 or so with the idea of using it (still am), not knowing it was going to be a PAIN to set up compared to the F7 or F4. But I managed. I had some PCM1793 (DAC) and PCM1802 (ADC) chips at hand (still have) on boards, and I managed to wire all together. Surprisingly enough, after a lot of swearing and sweating, it all worked! I was getting audio data on my PC.

Later I decided to "update" everything to an OS, using FreeRTOS. Also very frustrating experience, especially since STM32 decided to update their libraries and neglected to mention some direction bit that had to be set on the I2S transfer, let alone the bloody MPU issues. But.... I managed yet again!

In the meantime a PCB to be mounted on the STM32H7 Nucleo board was on the way, I purchased all components for 2, built only one, and came across a few hardware bugs that I fixed by removing components and re-wiring OpAmps (the rookie mistake, swapped + and -). But I got it to work!


So there's the hardware mounted on the Nucleo H7, all powered by an 10V AC wall wart (all the power is converted on the board) and connected to my desktop switch.

This is an updated schematic (differs from the actual board, some power supplies have been removed, +/- have been corrected on the OpAmp).


Basic theory of operation so far is:

* Receive a TCP request from the client (he who wants data)
* Generate a pulsed sine signal of a certain frequency and amplitude and send it out on the DAC
* Start grabbing audio on the ADC. Both actions are timed to be able to sync the data
* Start sending the audio input over the TCP stream
* Stop the connection when the requested data amount has been sent
* [Wait for another request/li]
The client is written in Python using PyQt and the plots are using pyqtgraph. This combination seems to be very fast and good for plotting. All FFTs and calcs are done using the python script.

Here's a screenshot of a single synced stereo channel (You can't see the left channel on the bottom graph because it's behind the red, but you can see the tiny differences on the frequency spectrum)


Unfortunately most of the options don't yet work, I'm still working on this. Good news though, I managed to receive and calculate 32K FFT's at 96KHz. It takes a while, but the level of detail is great. Ah, and yes, I still need to add the FFT length options .

I'm working now on the rev. B of the PCB, but I'm a bit unsure how to split the power rails. I need +/-12V for the output signal, so that's a must. Do I just remove those tiny components and build a separate +/-12V power supply? My tendency is to go with the latter. The ADC/DAC 5V supply needs to be derived from the +12V with a linear converter, don't want any switching noise in there...
Do I power the 3V3 and 5VD from the bottom board, needing then an additional 5V supply for the uC? Or do I derive all from the +12V rail?

Not sure how to proceed, your opinions are welcome.

Ok, gotta go prepare dinner, but I'm happy to answer more questions.



I, like you, bought I think every stm32 board that came out a few years ago because the were dirt cheap, fast, functional, with integrated displays on many, etc.  The one I used for my ICOM rotary dial has a display like a cell phone.  I'd be interested in taking a look at what you are developing.  I have an HP audio analyzer.  You need the external ADCs and DACs to get close to that performance.  The oscillator used as a source. is critical as well.  Lots about a DIY analog analyzer is on Diyaudio. 

I think instead of running an FFT you want to control the source frequency and amplitude and then measure the input and output the DUT.   FFT is nice for a quick plot but jn order to measure the very low distortion numbers you really need to filter and measure that frquency amplitude precisely, at least that's my thinking.   
I hope it work out and you get some results to share.


Nicely done, there is a lot of work in what you have accomplished. I assume that the data you receive and transmit to the PC is burst mode only i.e. you couldn't record a, say song, continuously? I have one of the Nucleo STM32H7 boards, but found, if I remember correctly, that the USB port was Full Speed only, because the High Speed port was occupied by the Ethernet port.(I hope that is correct) I also had a lot of issues getting some of the USB code examples to work, I finally gave up in frustration and moved on to the NXP iMXRT1020 etc. processors. So you have my admiration for succeeding and persevering. ;D
I guess it makes sense to derive everything from the +12v, as long as you don't have to dissipate too much current/power through the +5v and +3.3v regulators. How does the Nucleo get its power? 

Actually, the tool is capable of recording continuously into a PC, that is, I have a test python script that opens the connection to the micro and the micro starts streaming audio into the PC. No issues that I've detected. The script writes the raw data to file. I need to convert it to WAV still or add the correct headers.

I have a bunch of LP, records (those black old round disc shaped things) that I convert to digital for convenience (car, walkman, etc), and I was planning to use this, just haven't built a good enough case or enclosure around.

I'm not a fan of USB in general, you need specific drivers for specific applications and they are a pain to implement both on the IC and on the PC side. That's why I went with Ethernet. Additionally, the H7 introduces the MPU (Memory Protection Unit) and a different cache architecture than all the F series, and that was poorly documented at the beginning (2018 or so). It's way better now.

In case you want to get the settings right for doing Ethernet on the H7 I wrote a "how to" in case I forget in the future (I tend to forget!). https://github.com/betocool-prog/h7_lwip_freertos. Works only on the H7 Nucleo boards.



Very nice that it is continuous, do you know what a realistic bandwidth limit is? i.e. stereo in and out at 96k?
With regard to the USB drivers, for the NXP micro's, the devices I use appear as a USB Audio Class 2.0 device so no specific drivers are required.
Wow, your github has a lot of detail about getting the ethernet working. Any plans on githubbing your current code?


[0] Message Index

[#] Next page

There was an error while thanking
Go to full version