And programming is in session…

As some of you may recall, last week I had started work on the FT8 encoder block. This week while I was testing some code, I suddenly had a realization: logging should be something that’s standardized in GNU Radio, I should not need to reinvent the wheel here.

I present to you: d_logger. In C++ within a GNU Radio block, d_logger is a member and there are levels to this. Trace, debug, info, warn, error, and critical. I found the categories created in this manner to be a reasonable and logical way of posting errors. The “debug” category obviously is the one I’ll be using frequently right now but I already see uses for the different levels that exist already. For example, the “warn” is a level I’m using when the input has a double space or an invalid character and I remove it. While “error” is something I use when there is no message input and so there’s no way of actually sending the message, since there isn’t one.

But before I got to actually implementing and testing this incredibly nice functionality a wrench was thrown into the mix. To test the code I’m writing I’ve been importing the module completely into Python and then I planned to use d_logger. However d_logger requires GNU radio 3.10 while the version I’d created everything so far in was 3.8. And so I updated everything expecting life to go on simply. However, as is the case when you expect things to go easy, everything crashed. Suddenly I was faced with the error:

ImportError: generic_type: type “encoder” referenced unknown base type “gr::sync_block”

This would turn out to be a major pain. I started with just the boiler plate code and was already getting this error. Turns out the culprit was pybind11. In gnuradio 3.8 SWIG was used instead of pybind11 and so I’d not had a reason to encounter this problem. For those unaware, both swig and pybind11 accomplish the same task: they exist to create bindings between C++ code and Python, this allows you to call C++ functions directly from Python (which was my goal in the testing process). This is obviously an important and useful feature, though for me this introduced quite some iterative debugging.

The module was build and installing successfully but when importing in Python it crashed. I tried adding the missing GNU radio headers directly to the bindings, modifying the PYTHONPATH, I did many rebuilds with different library and Python versions, creating multiple conda environments built with different versions, and even changing the installation path to the conda environment compared to the system. It turns out the problem was, the pybind version required for gnuradio was older but the older versions don’t work for the version of Python I was working with. Once this was discovered I realized that this was as an easy enough fix by just downgrading Python.

Anyways for next week, I’ll be submitting a PR with a significant portion of the preprocessing complete – we shall see though.

Continue following for seeing what adventures this newbie gnu radio contributer goes out on.

References: https://wiki.gnuradio.org/index.php/Logging