Integrating gr-satellites into SatNOGS

[pierros]

Hey @EA4GPZ !

I will try to address some of the points/suggestions you are raising but will look into the technical input from @Acinonyx @surligas and @fredy @cshields for the architecture pieces.

@EA4GPZ

I am opening this thread to think about the best way of integrating gr-satellites into the SatNOGS client software. I have assumed that these forums are the best place to have the discussion. Feel free to move the conversation to another medium if you see fit.

This is the right place to discuss this, thanks for bringing this forward here!

@EA4GPZ

A good interface design will make it easy to plug in decoders from gr-satellites or other projects into the SatNOGS system.

Early on and on key points of SatNOGS development we have always planned for plugability and modularity. For that reason we have always assumed that gr-satnogs might not be the only “radio” part of our technology stack and specifically satnogs-client is re-architected (and should be re-architected more) to accommodate such options.

@EA4GPZ

Each gr-satellites flowgraph has as input a UDP source.

Although currently our input is gr-osmosdr blocks, we will be moving away from it soon to a Soapy SDR based approach (we have a project underway to develop Soapy SDR gnuradio blocks. That said I find great value on having an agnostic UDP based approach for the IQ input on any of our radio solutions.

@EA4GPZ

Off the top of my head I am thinking about deciding some good interfaces and encapsulating each gr-satellites decoder into a hierarchical flowgraph with these interfaces. In this way, it will be easy to drop in the hierarchical flowgraph into a gr-satnogs flowgraph. I don’t think is a good idea to make a different hierarchical flowgraph per satellite. Probably it is better to do it per modem (understood as a set of modulation, coding, framing and FEC settings).

This seems like a nice way forward. One thing to keep in mind is that within our architecture the flow of data looks like this currently:

The most important and relevant point here is the differentiation between demodulated (raw hex) and decoded (structured/readable) data. In the SatNOGS workflow the decoding happens on SatNOGS DB (see other posts for more details). My understanding is that gr-satellites produces both (?). The only case where we decode to something directly in gr-satnogs is APT transmissions (and soon HRPT too) but there is a pending dicussion there if we should decode on gr-satnogs or follow the data flow architecture and decode on DB.

@EA4GPZ

There is a flowgraph for each satellite. This was a decission that I took when the project started, with the goal of making it possible to fine tune decoding parameters (loop bandwiths, etc) for each particular satellite. Currently I am not so sure if this is the best way to do things, since there are several satellites which have very similar flowgraphs, since they use the same radio.

On the point of one flowgraph per satellite, we have always been questioning our approach too (flowgraphs specific to modulations). We believe that the latest modular abstractions that gr-satnogs 2.0 brings verify that we should stay away from satellite specific flowgraphs and instead bring any satellite specific information (FECs, framings etc) as arguments through trasmitter information. (thus extending our transmitter model in DB to fit all needs).

Once again, I would like to convey the excitement of the whole SatNOGS team for the chance to align and de-duplicate efforts with you @EA4GPZ and express our gratitude for all the great work you have been doing with gr-satellites so far.

@surligas @Acinonyx @fredy @cshields and others please do chime in with ideas on how to push this forward.