Fall 2025 Course Review: EECS 452¶
2026-01-05
Course Title: Digital Signal Processing Lab
Rating: 2.5/5
Instructor (Victor Liu)¶
Alumnus of Xi'an Jiaotong University, worked in some very famous companies before coming to UM. The lectures could not reflect his true skills, because we were using the "flipped classroom" scheme. This means for the first half of the semester, we were required to watch pre-recorded videos and finish quizzes ahead of lecture, then on the lecture we would discuss the quizzes and occasionally elaborate on a topic as needed.
I'm not a big fan of the flipped classroom. For one, the videos were quite dry, which reminded me of online courses I took in 2022. Also the quiz discussion had an uptight atmosphere, as the student stutters to explain how floating point numbers work while the professor tries to encourage the answer without spoiling it. It is a difficult job. The classroom also happened to be the one I taught labs in last semester so I can relate.
Course topics¶
The course features a variety of assorted topics, some only marginally related to DSP. The prerequisite course 351 was waived for me because I'm a grad student. As such, I did not take this course as intended, so I'll just list what I remember.
- Number representations
- Fixed point numbers
- Floating point numbers
- Quantization error
- Time- and frequency domain transformations
- DFT
- FFT
- DTFT
- STFT (how spectrograms are made)
- Windowing
- Filters
- FIR
- IIR
- Kalman
- Machine Learning-adjacent
- SVD
- PCA
- And somehow stuff like homogeneous transformation matrices
Labs¶
The lab staff handed me a lab kit with all sorts of stuff, including a Raspberry Pi 4B, ESP32, Arduino, Teensy, and a ton of cables. Many of the tasks they asked me to perform on the RPi can actually be done on my own laptop at 2x the speed.
Unlike 473, the lab is locked when no staff is present, but I was able to finish all five within the time given, at least the part where I need physical lab access.
The lab was also next to the ham radio shack, so we could sometimes hear people going on air. I could also conveniently borrow a multimeter from there.
The labs involved NumPy, SciPy, some OpenCV, matplotlib on the RPi, and code on the Teensy. The Teensy is a vaguely Arduino Nano-shaped devkit with a really powerful ARM Cortex MCU, specifically designed to handle DSP well. It's got an Audio library which we used extensibly. It reminds me of the code I wrote with ESP-ADF in 473, with the same notion of sources, filters, and sinks. I didn't have to write much Teensy code though, they were mostly given to me and all I had to do was fill in the blanks, e.g. implement a complex multiplication.
Project¶
We had freedom to form groups of 3-5 and select a project. Our project was a beamforming microphone array thing. The intended use case is in the classroom, where students can raise their hand to make the microphone focus on their voice but attenuate sound from other directions. The system consists of two parts:
- Computer Vision: Use YOLO to locate raised hands
- Beamforming: Steer the beam toward student
The first part worked, but the second did not. This was because audio beamforming was way harder than any of us imagined. Combined with intermittently faulty hardware and bad wiring, this was not the project I'm the most proud of.
PCB¶
I must however talk about the PCB I made. Did it work? No. Is it beautiful? Hell yes. Especially the shameless inclusion of Rix's puppy Asbestos:

Late October. Our beamforming hardware was a breadboard with a Teensy and a linear array of four MEMS mic modules, one inch apart. I thought it was a good idea to avoid breadboard wires and to have more mics, in hope that it makes beamforming easier.
There was a paper where they made a PCB that could sample 8 microphones. I emailed all six of the authors to ask how they did it, and Dr. Jilu Jin suggested we use ADC chips such as TI PCM1865, so that's what I did.
I used two PCM1865s (each sampling 4 mics) and put the Teensy directly on the PCB via headers to make the I2S wires as short as possible. However, it just didn't work. I2C register writes sometimes fail. I would write 0x28 and read out 0x00 or some other garbage value. I emailed TI about this but they ghosted me. I2S (technically TDM) works, but sometimes 4 mics, sometimes 5, rarely all 8, and the rest of the times just nothing at all. Even when it worked, the gain was super low, so I had to apply 20dB of amplification before sending it to the beamformer. It was just horrible.
No more PCB¶
We ended up abandoning the PCB altogether and pieced together a comically large cardboard apparatus with four breadboards, each with a MEMS mic connected to a central Teensy via jumper wires.
One thing I didn't find out until too late was that when you do
Serial.begin(115200); on the Teensy, the baud rate isn't actually capped
at 115200. The Teensy Serial library just ignores the parameter, because
Teensy supports USB natively without the need for a USB-to-UART chip like
Arduino does. So it just uses the USB speed of at least 12 Mbit/s. Had
I realized this sooner, I wouldn't have insisted on doing the beamforming
on the Teensy. The day I realized that, I just had the Teensy dump the PCM
data to the laptop instead.
Sadly I was not at the design expo because I was running around the BBB atrium checking out 473 demos with the rest of the staff.
Jira rant¶
One thing that annoys me is how much time was spent on some of the lectures advocating Jira. The reason was that use of a project management tool was one of the things that makes a degree program ABET-accredited. My team didn't use it as our primary tracking tool, and I would say it didn't help nor harm us. It just felt dissonant that a DSP course was using Jira, as I used to view Jira as a mostly software development thing.
Verdict¶
- Diverse course topics
- Flipped classroom was not the most effective way of teaching
- Labs and homework were reasonable in length and difficulty
- No exams
- Project had the potential to be amazing (Mine just failed to be)