I figured it might be worth documenting what I’ve been playing around with for LRPT demodulation.
First off, the flowgraph: https://github.com/darksidelemm/satnogs-extras/blob/master/flowgraphs/lrpt_demod.grc
This is based off this flowgraph, adapted to work with SatNOGS doppler correction. This flowgraph gets added into satnogsclient/scheduler/tasks.py where you would expect it to.
The flow-graph performs the appropriate resampling, produces a waterfall output, and performs QPSK demodulation, with 8-bit signed soft-bit data saved to /tmp/< decoded_data_file_path >.s
I haven’t yet found software suitable for decoding the LRPT bitstream in ‘realtime’. Instead, I’m using this decoder, being run from a post-observation script by this python code. The python code looks in /tmp/ for soft-bit files and runs medet_arm to produce a set of .bmp files. Depending on the settings, ‘convert’ (from imagemagick) is used to concatenate and convert the multiple outputs into a single png file. This png file is then placed in /tmp/.satnogs/data/ for upload.
At the moment I’m not using the patches to satnogs-client to allow auto upload, since it’s a bit broken with the NOAA demod (uploads the file mid-decode). Instead my post-observation script just uses rsync to copy any *.png files in /tmp/.satnogs/data/ to a webserver.
There are a few issues at the moment:
-
This post-processing approach doesn’t really fit in with the current SatNOGS client architecture. Ideally the processing of the soft-bit file could be performed on the network server, however the raw files are around 130MB/observation, which is a bit much to upload. I’m not really sure how feasible it would be to implement a complete LRPT demod (right to image output) that could run in real-time. I’m also not sure if it’s worth the effort, and I think this is a good use-case for a 2-part decoder (live capture, non-realtime post-processing prior to upload to network).
-
I’ve noticed that there are no timestamps passed to flow-graph in the decoded_data_file_path parameter, just ‘data’ and the observation ID. The NOAA flow-graph appears to get this data somehow, but I haven’t worked out where yet (probably just missed something). Once I figure this out the resultant images should integrate much nicer with the network observation pages.
Hopefully this proves useful to someone!