Hi Marcus and Daniel,
sorry that I didn't respond fast in the last days. I am quite busy at
the moment.
Thank you very much for the thoughts and ideas you shared with us. They
are very valuable for our work and helped us a lot to get more context
on our project.
As we are obliged to fulfil a working package description from our
supervisors, we still discuss, how to incorporate your ideas into the
project goals exactly.
I will hopefully get some time to keep you updated on this.
Best,
Martin
Am 21.05.23 um 10:00 schrieb Daniel Estévez:
Hi Martin and Marcus,
Just seen this thread.
I would suggest that you base the demodulator part of the flowgraph on
the current FSK demodulator that gr-satellites uses:
https://github.com/daniestevez/gr-satellites/blob/main/python/components/demodulators/fsk_demodulator.py
This is a Python hier block that can handle several different cases,
but you can make a simpler C++ version adapted to S-NET.
This uses the Symbol Sync block with a Gardner TED instead of Mueller
and Müller (mainly because I heard fred harris say that Mueller and
Müller is not very good, though he didn't say which are the TEDs he
prefers), and in general it is a better and more modern approach at
FSK demodulation than the flowgraph for GNU Radio 3.7.
The Sync to PDU block is a Python hier block, but it uses only C++
blocks, so it would be really easy to port it to C++.
https://github.com/daniestevez/gr-satellites/blob/main/python/hier/sync_to_pdu.py
Regarding the S-NET deframer, as Marcus pointed out, this is Python
(it makes heavy use of numpy) and it uses a BCH decoder in Python. The
reason why this is done in Python (as all the other Python code in
gr-satellites) is primarily because of the faster development, and
also partly better maintainability due to the smaller and simpler code.
Performance-wise, the implementation of the BCH decoder in Python is a
joke, but for these satellites that transmit at a few kpbs,
performance is not a problem unless decoding on a really constrained
embedded platform.
I would be happy to see C++ implementations of the BCH decoder and the
S-NET deframer being upstreamed and replace the Python implementations
in gr-satellites. Marcus was right on the money with his comment about
giving away free puppies, but if the code quality is good and there
are unit tests, I have no regrets about taking over maintaining the
code when it is upstreamed.
I would definitely encourage upstreaming the resulting code. Specially
with university student projects, otherwise it is very difficult to
ensure the long-term maintenance of the software, since projects end
and students go. The code then bit rots. As an example, I can mention
the BEESAT GNU Radio out-of-tree module, which I think is still only
available for GNU Radio <= 3.8 (this was also a TU-Berlin project).
Finally, I agree with Marcus on whether porting all this stuff to C++
is the best approach if the goal is just improving how the software is
shipped and installed. The idea to build everything into a single
static binary might sound appealing, but to me it seems more similar
to how applications are bundled for embedded platforms than for the
desktop, and I can tell you that it can be full of issues.
Would you link statically the GNU Radio libraries in the binary as
well? This is definitely possible, and you can produce a binary that
only requires libc, libstdc++ and friends (libpthread, libm, etc.).
However, you'll face problems with libc and libstdc++ versions across
different distributions, unless you build against an version of these
that is older than the ones in all the distributions you want to support.
How about multi-platform support? Building just one of these static
binaries is a bit of a pain (for embedded I tend to set up a Docker
container that builds everything from scratch as required). If you
want to support Linux x86_64, Linux arm, Linux aarch64, Windows
x86_64, Mac x86_64 and Mac aarch64, then things start to look
daunting. And don't forget that if you want people to be able to
modify and rebuild the software, the build system needs to be easy to
use and not break when software versions change (this is why I use a
Docker container for building).
Also, coming back to what I said about bit rot, it's quite likely that
no one will maintain this static binary build system long-term, so
your binary will end up bundling an old version of GNU Radio and other
dependencies. It will work in the same way as it did on release day,
but it won't benefit from improvements in new versions of the
dependencies.
All I'm saying with this is that building and shipping software is
complicated. Marcus' suggestion of using conda is great because it
already saves you much of the work and complications.
Some words about user friendliness. Unless you're going to embed the
decoder in a GUI application that supports a wide range of SDR
devices, software like this is never going to be trivial to use.
You'll typically rely on users running your software as a "backend"
that receives samples from a "frontend" SDR application in some way
(audio interface, network protocols, pipe, etc.). Users will need to
know the tricks of how to set up their SDR hardware and frontend
application of choice and connect it to your backend (virtual audio
cables in Windows are a common trick, resampling might need to be
involved, etc.). I would say that, with this in mind, these days
gr-satellites is reasonably easy to install and use, even on Windows.
Users that are familiar with all of this can conda install
gr-satellites, and run something like
gr_satellites "S-NET A" --audio --samp_rate 48e3
or
gr_satellites "S-NET A" --udp --samp_rate 48e3
and setting up the connection to the SDR frontend software.
Where gr-satellite falls short is in providing a nicer user experience
in terms of GUI (there's no GUI), such as having graphical means to
assess signal quality (spectrum/waterfall display of received signal,
constellation diagram / symbol time domain plot, SNR estimate plot,
etc.), having a GUI to control options, and making it easier to
troubleshoot why decoding is failing (there are many subtle ways to
corrupt/distort a signal if the set up is not done properly). Tackling
part or all of this would be orders of magnitude more work than
porting a couple Python blocks to C++ and bundling the software as a
binary.
Regarding signal transmission, gr-satellites is generally lacking in
this respect. The main reason is that there are very few satellites to
which anyone can uplink, and most of the few which support an open
uplink use AX.25, for which there are many TNC applications available.
Implementing the required GNU Radio blocks to encode and modulate
uplink packets is a reasonably straightforward task, but where I'm
lacking a good architectural concept is in interfacing this with an
SDR. There is a varied degree of support of bursty transmission mode
in the different SDRs in the market, and most of the common SDR
"frontend" applications have no support for TX, let alone for getting
TX samples from an external application. There can be other potential
problems with GNU Radio implementations if things are not done right,
such as large latency. Additionally, there is often the need for
hardware control, such as PTT or TX/RX switches.
I think it would be great to open a discussion with the amateur
satellite community to try to come up with good solutions for this
problem.
Best,
Daniel.
On 18/05/2023 13:54, Marcus Müller wrote:
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.
