As the author of gr-satellites, this is something that I have been thinking to do for a long time but never got to it. Now that SatNOGS observations are becoming really popular and useful, it would be great to have demodulated data automagically appear for all the satellites that gr-satellites supports.
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.
I am not very familiar with the SatNOGS software, but I’ve been taking a look at the flowgraphs in gr-satnogs to see how things are done. It seems that the key to getting this right is in the interfaces. A good interface design will make it easy to plug in decoders from gr-satellites or other projects into the SatNOGS system.
Let me briefly describe how the interfaces in gr-satellites currently work. 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. Nevertheless, the list of different modes to support is also large. With the exception of a few standard modes (mainly AX.25, and the GOMspace radios, which are quite popular), many satellites implements custom protocols, especially regarding framing and FEC. As a side effect, this makes it easy to distinguish between different satellites when sending telemetry to the SatNOGS server, since each flowgraph has the NORAD id of the satellite.
Each gr-satellites flowgraph has as input a UDP source. The idea of this source is that the user could stream samples in real-time from gqrx, a flowgraph in gr-frontends, or another source. The UDP source expects real samples at 48kHz. The format depends on the particular flowgraph, but it is always one of the following three:
- FM. FM-demodulated audio, as you would use to receive FSK.
- SSB. USB-demodulated audio, with the signal centred at 1.5kHz.
- Wide SSB. USB-demodulated audio, with the signal centred at 12kHz.
The design goal was to allow the user to use a conventional radio in FM or SSB mode (note that SSB mode usually has a bandwidth of 3kHz) as long as possible (some modes, especially 9k6 BPSK, need SSB but don’t fit in 3kHz). This also explains the distinction between SSB and wide SSB. We use SSB instead of wide SSB whenever it’s possible.
The output of the flowgraph is essentially text on the console. Depending on the satellite, there is either a telemetry parser that prints out the telemetry in human readable format (it would also be a nice touch to show this information in SatNOGS observations), or just a hex dump of the packet. Most telemetry parsers use construct, so the parsed telemetry is also machine readable and can be passed around, pickled, etc.
There is also a telemetry submitter that sends packets to any SiDS compatible server (currently the SatNOGS server is used).
In some cases there are other kinds of output. Some AX.25 flowgraphs support a TCP KISS socket (which is kind of standard for a TNC), and you can also save the packets to a file in KISS format.
That’s more or less all regarding gr-satellites interfaces.
What I have seen in gr-satnogs is that the input is really an osmocom source. However, there is some DSP done until we arrive to the OGG Encoder. At this point we have something very similar to what gr-satellites expects in its UDP input.
The output are PDUs that go into a frame file sink and UDP message sink. This fits very well with gr-satellites. We have PDUs with the packets at some point in the gr-satellites flowgraph.
Now some ideas about how to get this going.
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).
I still want to maintain the current scheme for the gr-satellites flowgraphs, since people are already using them in this way, and they are also useful for processing recordings, and even sending to the SatNOGS server the telemetry from recordings. The idea of doing hierarchical flowgraphs also fits nicely into this scheme, since a large part of each flowgraph will get replaced by the hierarchical flowgraph. This also saves some repetition between satellites using the same modem.
I think this long post is all for now. Please contribute with any ideas you may have. Careful planning will probably save us a lot of work.