Completing gr-satnogs porting to gnuradio-3.10

The porting effort to gnuradio 3.10 has almost been completed, but there is at least some issues with the python bindings not being installed properly.
This means that some projects that depends on this completion is blocked.

We have a proposal for this as a short paid project. Contact me via mail for a time/cost quotation and I will discuss with the others involved in this.
It does not include any larger changes of the architecture. This needs to work on the Debian 12 implementation of gnuradio and satnogs-flowgraphs. Feel free to build it in docker etc, I can arrange a build environment for this if needed.

The project lives at gr-satnogs at the specified branch. Some additional changes is proposed in MR !314 that makes it build on Debian 12.

Feel free to ask for any details in this thread.

Related links:
gnuradio 3.9 oot porting guide
gnuradio 3.10 oot porting guide
docker-gnuradio

4 Likes

This means that some projects that depends on this completion is blocked

Is there a list or overview of projects that are causing this block ?

Mostly moving to stable debian again, also gr-satellites deprecating gnuradio-3.8 soon.
The repos mentioned above is the main two being directly blocked.

gr-satnogs and satnogs-flowgraphs ?

The key point when building the package dpkg-buildpackage -us -uc -b :

-- Installing: []debian/tmp/usr/lib/python3.11/site-packages/gnuradio/satnogs/__init__.py
-- Installing: []debian/tmp/usr/lib/python3.11/site-packages/gnuradio/satnogs/__init__.pyc
-- Installing: []debian/tmp/usr/lib/python3.11/site-packages/gnuradio/satnogs/__init__.pyo

No other .py, .pyc or .pyo

It does however compile them:

[ 80%] Building CXX object python/satnogs/bindings/CMakeFiles/satnogs_python.dir/doppler_correction_cc_python.cc.o

After porting SatNOGS to gnuradio-3.10, does this mean that satnogs_gr-satellites is going to be obsolete, or is it still needed for decoding, for example, FunCube?

No, the integration will still be possible but there will be some changes.

I’m does not understand the full picture, why isn’t it possible to decode - for example - Funcube in SatNOGS direct? Does every type of decoder needed to be included in SatNOGS?

This specifically is due to bpsk flowgraph, or gr-satnogs, not sure which.

The change to gnuradio-3.10 is both due to 3.8 being quite old and projects stop supporting it, and also that debian stable and most other dists are now on 3.10, so making it necessary to keep up with the OS releases.

As it stands now, Bjoern Kerler has put some decent work into this and we now have some progress. It builds ok but some pybinds needs work, the fm flowgraph looks to be working for example, but fsk is not due to the ax25 stuff not being done.

Somebody needs to include the following specific FUNcube (GitHub - funcube-dev/funcubeLib: decodes/encodes data from/for the FUNcube family of satellites, detects and tracks them too.) decoding into the SatNOGS client.

I am not an expert, but what I understand it is mainly the AO40 encoding.

Thank you @PE0SAT and @SA2KNG for explaining.
What about integrate satnogs_gr-satellites into the main SatNOGS? Should it be possible?

I think it should be ported to python before any integration in satnogs, I do have a embryo on that here.
For now, the management of additional software with docker is quite easy, and can be made much easier with some menu system to select optional software. I refer to my addons for how I have implemented this in on big compilation. Main drawback of my images is that I build them manuallt, I should set up automatic building on github for this and add hooks to trigger build when the gnuradio/satnogs-client images are updated.

1 Like

Should be interesting to follow. Thank you for your excellent work with SatNOGS!