Decoders used in SatNogs?

[K4KDR]

Apologies if this has been asked & answered previously - I searched & did not find it.

My specific interest is how to decode the 12k5 BPSK downlink from MOVE-II, but this is a general question as well.

I see from MOVE-II ‘Observations’ that apparently SatNogs is successfully decoding those downlink packets. However, from searching the GitLab page & elsewhere, I’ve not found anything to use for that task.

So my question is, specifically for MOVE-II but also in general, when we see that SatNogs is successfully decoding & parsing telemetry from an object, where might one find the underlying info / tools to allow for decoding locally by an individual?

Many thanks!

-Scott, K4KDR

[SA2KNG]

Looking at obs data we can see the file naming doesn’t match the regular frame names:
https://network.satnogs.org/observations/8737588/#tab-data
Looks like there’s a few stations that does this: 355, 378, 2032.
Not sure what software they use, but also not finding it in gr-satellites satyaml (@PE0SAT hint hint).

MOVE-II(b) Radio Tracking Instructions

Producing a satyaml would be a easy path I guess (:

[PE0SAT]

Based on information I could find and share at the following location, the modulation seems to be similar to ARQ and uses nanolink framing.

The techniques aren’t present in the current gr-satellites framework.

Trying to build there AppImage based on an old github repository wasn’t successful. (GNuRadio 3.7 and python2.7)

Been trying to get the AppImage build, but keep running into this error:

reparing transaction: ...working... done
Verifying transaction: ...working... done
Executing transaction: ...working... done
Traceback (most recent call last):
  File "./move2radio/move2radio/build/deps/conda_env/usr/bin/conda", line 7, in <module>
    from conda.cli import main
ModuleNotFoundError: No module named 'conda'
make[3]: *** [CMakeFiles/conda_env.dir/build.make:73: deps/conda_env/usr/conda_success] Error 3
make[2]: *** [CMakeFiles/Makefile2:1071: CMakeFiles/conda_env.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:165: CMakeFiles/appimage.dir/rule] Error 2
make: *** [Makefile:124: appimage] Error 2

gr-satellites yml:

This is what I came up with based on this gr-satellites documentation:

name: MOVE-II
norad: 43780
data:
  &tlm unknown telemetry:
    unknown
transmitters:
  12k5 BPSK AX.25 downlink:
    frequency: 145.950e+6
    modulation: BPSK
    baudrate: 12500
    framing: CCSDS Concatenated
    precoding: differential
    RS basis: conventional
    frame size: 1024
    data:
    - *tlm

gr_satellites MOVE-II.yml --rawint16 gqrx_20231221_150159_145942500_78125_MOVE-II.wav --samp_rate 48e3 --iq
Sample rate 48000.0 sps insufficient for 12500 baud BPSK demodulation. Demodulator will not work.

The search continues.

Jan PE0SAT

[PE0SAT]

Scott,

Did you manage to create a recording with a higher sample rate ?

[K4KDR]

Many thanks for all the ideas & feedback!

My original point, though, is that SatNogs already IS decoding MOVE-II and the output of that Project’s command-line decoder is already showing up on Observations that have good packets. So, I was really wondering by what means the SatNogs back-end is demodulating and parsing out the correct frames?

But to the question of decoding with our usual tools like GNU Radio, echoing several others I have also not had any luck yet.

This morning I recorded a very high pass and was very careful to output the audio to a recording with centered doppler tracking that was as precise as possible. Please note that this is an AUDIO file, not I/Q. The sample rate is 192k and it’s located at:

https://www.qsl.net/k/k4kdr//audio/move2/2023-12-22/

Thanks for any additional info on the mechanism being used by SatNogs and I’ll continue to see if I can follow Jan’s lead and work out something natively in GNU Radio.

[PE0SAT]

Thanks Scott,

How is the reception demodulated, I guess USB, maybe you can confirm this.

[K4KDR]

Yes - sorry!

A 15 kHz USB passband w/ the signal centered right on the 7500 Hz point.

[N6RFM]

Jan and Scott, So far I have only been successfull using IQ (as WAV) files recorded using SDRConsole. These files are then loaded onto an OS with GNU3.7 which includes the move-ii-decoder block. AT some point the MOVE2 team also had an appimage which connected to an RTLSDR dongle and allowed for direct uploading to a MOVE2 server. Alas, that was taken down several years ago along with the repo which I recall installed the decoder block and required ccsds files. There was an effort by a former team member to port the repo to gnu3.8, but I am not sure if that continued. I will continue to look at the docker container and reach out to the team to see if more might be done. 73, Bob

[PE0SAT]

What container are you trying to enable Bob ?

[PE0SAT]

I am going to build an old Debian Buster image, that should have GNURadio 3.7 and go from threre.
Lets see if we can build the AppImage on this old version.

[PE0SAT]

The same conda error as on all other platform that I tried, full build log

[SA2KNG]

Silly me also looking into getting that to build
I’m doing it on docker (big surprise) and looking at the issues, one of the big ones is the mixing of python 2.7 and 3.5. Not sure packages are available for 2.7

installing: python-2.7.15-h1571d57_0 ...
Python 2.7.15 :: Anaconda, Inc.

[PE0SAT]

I get the impression make appimage and also the other make options are creating there own virtual conda environment to overcome the possible conflicts.

Trying to modify this environment isn’t clear to me, the only option I can investigate further is:

cmake -DCONDA_ENV_OFFLINE=ON ../ and create my own conda env.

And this brings other challenges

[K4KDR]

With the magic “MOVE-II Decoder” block for the old GNU Radio 3.7 MOVE-II flowgraph no longer available, I foolishly decided to try to create an alternative with gr-satellites blocks.

Thanks to strong SNR recordings from N6RFM, I’ve had some success if anyone is brave enough to try it.

https://twitter.com/scott23192/status/1740963268917670315

…with permission from the Project Team who had utilized customized dependency repositories, I have placed copies at:

GitHub - K4KDR/gr-ccsds

… and I should mention that this repository includes modified paths to additional customized dependencies in .gitmodules. So, in theory (not tested), they should install automatically.

Also, this only runs in GNU Radio 3.8 (which is what I use). If anyone would like to update it to work with 3.9 & 3.10, please feel free.

All I can say is that, as you can see in the screen shots from my tweet, it DOES parse out the BPSK payloads (every 6th packet) from MOVE-II and using the ‘beaconparser’ utility, outputs what appear to be largely correct JSON payloads.

It’s a start that others can improve on, or perhaps use a template for other satellites, hopefully. That was the goal.

Thanks!

[K4KDR]

My goodness! Someone already made the necessary changes to run this experimental MOVE-II decoder in GNU Radio 3.10! Many thanks!

GitHub - K4KDR/gr-ccsds at 3.10

[K4KDR]

If anyone is experimenting with the MOVE-II repository that I’ve been sharing, please re-download the .GRC file.

Since I was never getting ‘VALID’ decodes, I kept digging to find out why. Turns out some additional python modules needed to be available to the flowgraph with IMPORT blocks. Also, I adjusted the filter & GT GUI settings for slightly better performance.

Here’s my tweet:

https://twitter.com/scott23192/status/1741355943743365144

… and here is a direct link to the updated .GRC file:

Please note, that’s specifically the flowgraph for GNU Radio 3.8. I messaged the fellow who was good enough to create a branch for GNU Radio 3.10 so if he has time to update the flowgraph in that branch, you’ll see a new version there as well. Otherwise, just look at the 3.8 flowgraph and add those IMPORT blocks manually.

UPDATE: the .GRC flowgraph file in the 3.10 branch has been updated!

Really amazing to finally see a 100% VALID packet from Bob’s recording!