On May 19, 2025, at 6:01?PM, Oliver KI3P via groups.io <oliver@...> wrote:

?

Update time! I've been working steadily on the code changes for the last month.

?

I've taken this as an opportunity to learn more about test-driven development and the concept of writing unit tests for code. This makes it take longer to write the code, but should make it easier to extend and maintain the code in the future. I'm building a test suite using the so that (almost) every part of the T41 code can be tested on a desktop computer before it touches a Teensy. This also lets me run the code with a debugger (GDB, in my case) which is a much more satisfying way to figure out why the code isn't doing what I want. This testing approach leaves me with confidence that the code is doing what I expect it to do before I load it onto the Teensy. There will undoubtedly still be bugs to find, but they should all be related to hardware integration rather than software bugs.

?

My focus for the last few weeks has been on the Receive signal processing chain. I've ported, cleaned up, refactored, and tested most of the receive DSP chain. I'm using Google Test to do things like run a comb of signals through the convolution filter to make sure that its filtering the frequencies we expect, generating plots like the one below for visual analysis (plotted using Python) as well as numerical tests that don't rely on visual inspection. Working on the receive code has been a great refresher in the principles of digital signal processing! I've had to dust of a lot of knowledge that had been gathering cobwebs in the back of my mind.

?

<inline.0.part>

?

Writing the code with a unit test framework is actually pretty enjoyable and is well worth the time investment. Every time I modify the code, I can run the full set of tests I've written against the entire code base in mere seconds and immediately know if my change has broken anything anywhere. Testing every function with its own dedicated set of tests helps to reveal unanticipated behaviors and edge cases. I can highly recommend it as an approach for a complex project like this! It lets me refactor and change parts of the code without fear that this will break something subtle somewhere else.

?

How am I changing the code? In addition to the cleanup, I'm getting rid of almost all global variables, have found many opportunities to reduce memory usage, and am separating the display code from the signal processing code as I rewrite it. I hope to be at the point where I can run the new receive code on the Teensy in a few weeks (without the display) to have a real-world verification that it's working as expected before continuing.

?

?