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.

Now everything flows through a ParsedData struct that captures all the message components upfront:

• Callsigns, grid squares, and signal reports
• Boolean flags for R, RR73, CQ, etc.
• Contest-specific fields like ARRL sections and serial numbers
• Free text and telemetry hex data

The idea is that each encoding function can grab exactly what it needs without worrying about side effects.

Here’s the frustrating part: my C++ QA tests still validate every step from message parsing through LDPC encoding to final symbol generation. The bit patterns are correct, the sync sequences align perfectly, and test vectors match the reference implementation.

But somehow, when I try to import this into Python, still something goes sideways. The error messages are impossible and frankly I’m quite ensure where to even look next.

With the major message types implemented, the encoder is approaching feature completeness for the FT8 protocol. Once I crack the Python import issue (and I will), this should handle everything from casual QSOs to contest exchanges to DXpedition pileups and some of hte people in the HAM radio gc in GNU have been pretty excited about this project, so the pressure is definitely on.

The real test will be putting these signals on the air and seeing if other stations can decode them. But for now, I’m confident that by next when someone transmits CQ DX K1ABC FN42 or W1ABC 59 CT, my encoder will pack those bits exactly where they belong.

Until next week (and hopefully with Python imports working),

Aloha