We (TU Vienna Space Team) are working on a CubeSat and we intend to have switchable up- and downlink data rates (1200-115200 bit/s GMSK) while always transmitting the beacon at the lowest intended rate (either 1200, 4800 or 9600 - still to be decided).
Now the question was how to best integrate this into a satnogs flowgraph.
The two ideas I came up with is to either have two decoders in the flowgraph. One always running at the beacon rate and one running at the “selected rate” and having multiple transmitters defined in the satnogs DB and then schedule the appropriate one.
Or the other option I can think of is to have 4-5 predefined rates and having one flowgraph that has decoders for all of them at once.
For both options I’d set the baud rate that received a packet as extra data in the json encapsulation of the packets.
For both of them - but especially the second one - I’m not sure if the “usual” smallest hardware used by clients (probably a Pi3?) has enough oopmf for running 2 or 5 decoding chains at once.
Which option is preferred here or do you have any better ideas?
Another slightly related question is how the satnogs network handles the extra data in the JSON. If I can add arbitrary data points here I’d also like to get RX parameters (SNR, FEC errors rates, …) also in there as this is valuable information for us.
currently satnogs-client and satnogs-flowgraphs does not support this, maybe in the future with the hier/modular style.
in the meantime this is pretty much what gr_satellites does, it runs all the defined transmitters in the satyaml, like BOBCAT-1
data to be sent to satnogs-network does use json, but the client only looks for pdu at the moment and discards any more information.
So if I’d PR a flowgraph for our cubesat client in the near future, would you merge one that runs two decode chains in parallel?
Then I’d add transmitters with the relevant baud rates to the satnogs-db and schedule them accordingly. that way satnogs can decode the beacons in any case and the payload data as long as the correct baud rate “transmitter” is scheduled.
gr-satellites is not used by the satnogs client right? just the gr-satnogs module?
It’s a but unfortunate that the client does not allow additional metadata, especially data from the FEC would be quite interesting. ignoring any additional data is ok though - we plan on feeding the json messages of our station directly into COSMOS (which we are using for communication with the cubesat. Our groundstation will also run a modified version of the flowgraph that allows for uplink as well by listening on a UDP socket and transmitting all frames received there by COSMOS)
We’re not aiming for one flowgraph per satellite, rather cumbersome to manage and keep the stations updated. Looking at the FSK flowgraph you can see it manages different modes internally but only one at the time.
As I’m only a contributor I cannot really tell what the future looks like, there’s a pretty big software debt being worked on right now, as well as a new architecture.
For our specific case it will probably be relevant in slightly less than a year.
The downlink will be in compliance with CCSDS with the one special case of always leaving the telemetry at the same baud rate while switching the rest.
I do see why you don’t want a separate flowgraph per sat, which is partly why I asked if gr-satellites is included with a standard satnogs client installation.
The worst case is that at this point we will only be able to use satnogs for reception of telemetry but I’d love to be able to receive everything sent by the cubesat using satnogs.
gr_satellites is not part of a vanilla install of satnogs-client, either in the current host based or the newly released docker based.
I have however integrated it in both, and there’s a few stations that is running it currently.
How the future looks for it I’m not sure. I’m a bit tired of maintaining a external tool by now.
The documentation and sw for it is located at kng/satnogs-client-docker.
I have a gist on how to do it on the newly released docker-ansible. This is not the finalized version thou.
well, correction, gr_satellites the program is part of satnogs-client, but not any tool to use it in the observations. that is what grsat.py does, and is launched in the pre-/post-scripts.
So if we add support in gr_satellites, this should work with this docker image?
Also: Do I see that correctly that satdump will also work? (I’m in contact with the satdump author and they want to add support for our sat)
The grsat.py belongs in satnogs as it is glue for that implementation. I don’t think Dani thinks it is of any use in gr_satellites package.
My addons has a bunch of extra software and drivers, SatDump being one of them. it doesn’t have a completed implementation to manage the satdump image products for upload in satnogs-network yet, the basic stuff is there thou.