I have started a massive refactoring of the
gr-satnogs codebase. The ongoing work is at the https://gitlab.com/librespacefoundation/satnogs/gr-satnogs/merge_requests/174
One of the most difficult parts are already done. I managed to create a generic enough API for the available decoders and seems that it works pretty well. The benefits from the system point of view, is drastically less python memory usage (swig interface is simpler) and faster compilation times. From the usage perspective, every decoder now is a variable that can be attached to a generic frame decoder block. To me at least, is much more convenient and easy to use. For every frame decoded, there is also a set of metadata (count of errors or corrections, etc)
As a next step is the metadata together with the decoded data to be serialized and stored or sent to another entity (socket, file, whatever).
My thoughts is also to create an arbiter that can generate a flowgraph on the fly. For this reason, the capabilities of the sat transmitter should be known to
gr-satnogs somehow. With this approach there will be no need for a hard dependency of the client and
gr-satnogs every time we need to add a new decoder. It is much easier to handle RF related info into the radio code rather than in the client. I believe that hacking and experiment should be also easier.
What we have to decide:
- Should we continue with the model of storing the generated files? Personally, I would propose to drop it and send them via sockets
- In case we want to store them in files, shall I proceed with hdf5?