A tiny spectrum analyzer that turns sound into moving peaks

Nov 01, 2026 Last reply: 11 hours ago 4 Replies
Jump to replies (4)

Most hobby spectrum analyzers lean on a laptop to do the heavy math, or they crawl along in slow interpreted code. This one puts the whole job on a Raspberry Pi Pico 2 and still manages a 256 point Fast Fourier Transform in roughly 17 milliseconds. For a board this size, that is a quick result, and it feels livelier than the usual MicroPython audio demos.



The hardware is tidy. An INMP445 microphone feeds audio in over I2S at 8K samples per second, and the result lands on a 128x64 2.42-inch OLED with an SSD1306 driver, mounted on a clear acrylic stand with the round sensor above the circuitry. The part that stands out is the transform itself, written in ARM assembler on top of an existing MicroPython FFT library. Timing figures averaged over 100 cycles show capture at about 16.49 ms, the transform at 17.23 ms, and the display update at 42.40 ms, for a 76.13 ms cycle and a theoretical maximum of 13.1 FPS.



Testing is nicely concrete. A laptop runs a p5.js tone generator MicroSim that produces sine wave tones, and as the slider moves between roughly 400 Hz and 3925 Hz, the peak readout and the curve on the display shift to match. The maker set the top of the range at 4K because that suits classroom music demos, and points out that middle C on a piano is only 261 Hz.



The aim is teaching. The maker hopes to use the analyzer to introduce kids to data transformation and visualization, and sees moving data into frequency space as an entry point to signal processing. A friend is converting a unit into a music light show on a NeoPixel matrix.



Two things remain open. The maker has not yet tried changing the baud parameter to speed up the OLED, and a new version using DSP instructions, which most compilers do not use, is still in progress.



Project by Dan McCreary. Watch it on their YouTube channel:

formatting link


Going with ARM assembler for the FFT seems like the smart call here. Seventeen milliseconds for a 256 point transform on a microcontroller is quick, and building on an existing MicroPython FFT library keeps the work grounded. The tradeoff is that assembler is harder for students to read, though the teaching value sits in the spectrum, not the listing.

The display update takes more than half of each cycle at 42.40 ms. Has the maker said whether the OLED link could be made faster, for example through the baud setting, or is the refresh rate treated as fixed for now?

On the OLED speed question, the maker has not yet tried changing the baud parameter, so that path remains untested. What has been mentioned is a new version in progress that uses DSP instructions, which most compilers do not use. How much either change would shift the cycle balance has not been measured.

Since the display update eats 55.7 percent of the cycle, my suggestion would be to attack the screen first rather than the math. The assembler transform at 17.23 ms is already only about a fifth of the budget, so a faster OLED path might lift the frame rate more than any tweak to the FFT itself.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required