Hey Martin,
welcome to the community :)
As you can imagine, with the GNU Radio project, code contributions are always welcome,
especially when it comes to adding code generation for existing blocks written in C++. I'm
pretty optimistic Daniel feels the same way about gr-satellites.
The S-NET flowgraph screenshot is already a bit older, it still uses GNU Radio 3.7, but
with the symbol sync block, it might be quite straightforward to port it (Clock Recovery
MM has been deprecated; you can use Symbol Sync with a Mueller and Müller TED instead).
You need modern GNU Radio, because on 3.7, C++ generation was not there, and also, the
more modern the GNU Radio, the more blocks already come with C++ generation definitions.
I do have one piece of bad news for you, though: Many (most, I think) blocks in
gr-satellites, such as the S-NET deframer, are Python blocks. So, the thing that's missing
for creating C++ flowgraphs out of these is not only the definition of how the C++ code
needed to instantiate them looks like, but also: a C++ implementation!
And that is where it gets hairy: I don't think it's overly complicated to re-implement
snet_deframer.py from gr-satellites in C++. The question is whether you *should*, on two
levels: first, that's an effort you'd be doing to recreate something that already exists,
and second, you should probably really work with upstream (so, Daniel) on whether he would
prefer your C++ implementation (he positively might! It's going to faster, especially
since you'll be implementing the BCH decodder in C++) or his Python implementation (which
is going to be easier to read and maintain, probably). The thing with upstreaming is that
you're giving someone your code to take care of, and that's a bit like giving away free
puppies: A great gesture, but comes with some work.
In this light, I'd recommend you go through each block in the flowgraphs / applications
you want to use and consider whether it's worth going through the porting effort to avoid
having to package Python.
There's an alternative to having to package Python yourself, and all the libraries (which
are quite a few) that (the used subset of the in-tree modules of) GNU Radio +
gr-satellites would use:
Make sure the conda recipes work flawlessly for the software you want to ship, and build a
conda installer akin to Ryan's radioconda for that specific application. I guess you're
mostly targeting Windows there – making a nice installer should not be impossible, but I
don't have any personal experience with it. That would have the added benefit that, if you
decide that you want your target audience to also have access to truly unportable
Python-only software like GRC, you could, at nearly no development cost, add that.
Either way, what you set out to do is truly remarkable and I'm happy you're
tackling it!
Best,
Marcus
On 18.05.23 11:25, Martin Hübner wrote:
Similarily, the C++ support for the rather easy quadrature demod block should look like
this then, right?
https://github.com/Akira25/gnuradio/tree/add\_cpp\_generation-quadmod
That link's private, but if you want us to have a look at it, why don't you open a pull
request against gnuradio/gnuradio? You can mark it as "Draft" and write a nice comment
what it signifies, and maybe even link to your message in the discuss-gnuradio mailing
list archives.
