The next step forward this week was finally implementing the complete message flow from PMT input to RF output though granted with errors. Previously, I’d been stuck trying to understand how all these GNU Radio components actually fit together. This felt overwhelming initially but became much clearer once I started connecting actual blocks.

This week I worked on understanding what PMTs and PDUs actually are and why my current approach is honestly just broken. Previously, I’d been treating GNU Radio like a kind C++ signal processing library where you just generate waveforms in constructors and call it a day. This felt reasonable initially but became a complete nightmare when trying to handle multiple messages. Now I understand the core issue: I’ve been fighting the architecture instead of working with it. GNU Radio has two distinct domains - synchronous stream processing and asynchronous message passing - and I was trying to force everything into the wrong one. Here’s what PMTs (Polymorphic Types) actually solve: • Type-safe data containers that work seamlessly between C++ and Python • Built-in serialization for passing complex data between blocks • Support for everything from simple integers to dictionaries and vectors • Thread-safe immutability (except for vectors) that prevents race conditions • Automatic type conversion so you don’t have to worry about casting nightmares If the above seems a little too complex, the documentation is kind of amazing so I would recommend checking it out: https://wiki.gnuradio.org/index.php/Polymorphic_Types_(PMTs)

This week was spent finally understanding what pybind11 actually does under the hood. I went through the pybind11 documentation. Previously, I’d been treating it like some magical black box that somehow made C++ code work in Python. Which to be fair wasn’t that far from reality. This felt like enough to get by initially but became a real problem when debugging binding issues. For those unfamiliar, pybind11 “is a lightweight header-only library that exposes C++ types in Python and vice versa, mainly to create Python bindings of existing C++ code”. So some highlights of what this does:

The biggest change this week was getting rid of the “shrinking string” approach. Previously, my parser would consume parts of the message string as it went, making it shorter each time. This felt clever initially but became a debugging nightmare.

This week I focused on building out QA tests for my FT8 encoder and continuing to debug the errors I’ve been getting on that front, let’s walk through what I’ve been validating.