Support for SpaceTeamSat1

[XDjackieXD]

Hi!

Our cubesat (https://db.satnogs.org/satellite/GCRL-7329-1908-5510-3384) will launch soon.
Protocol wise it is relatively standard CCSDS and I'd ask you to support it gr-satellites.
It is an amateur mission, see https://spaceteam.at/en/sts1-en/ for detailed mission description.
We intend to publish all data regarding the satellite (most of it can already be found on GitHub and Zenodo, including hardware designs and the firmware running on the cubesat).

Modulation and channel coding is GMSK with 9600 Baud, dual-basis RS223/255, CCSDS scrambling and unpunctured convolutional coding.
Baud rate can be increased for non-beacon data up to 115200.

The Flowgraph (based on gr-satellite blocks) we are currently using can be found here: https://github.com/SpaceTeam/STS1_Channel_Coding_Tests/blob/master/sdr_trx_cosmos.grc (feel free to give input in case there are obvious improvements that could be made. One thing we noticed that seems odd is that the decode success rate is strongly dependant on the sample rate and decimation and more often isn't better).

Sorry for the late coordination :/

[K4KDR]

Greetings! I'm sure you will get a reply to your inquiry. Meanwhile, do you have a specific launch date yet?

Thanks and best of luck on the mission!

-Scott, K4KDR

[XDjackieXD]

Thanks for the quick reply! The public information on this is "probably December" (after getting moved a bunch of times).
I'd love to have more time (as we are quite lacking on resources for people with RF and SDR knowledge) so I somewhat hope for it to get moved back further ^^'

if you have time for a quick chat I'd love to get some input regarding the groundstation side (my current flowgraph is working but decoding with weak signal has pretty bad success rate and I have some other issues). Us not really having enough time lead to the complete GS side getting neglected until now...)

[K4KDR]

Sorry - one other question, please. I see that you've been using GNU Radio to generate test signals, but do you have any I/Q (or audio) recordings from the spacecraft radio itself. Everyone likes to test their ground station w/ actual signals BEFORE launch when possible. Thanks!

(just saw your reply - thank you! And yes, your RX flowgraph can be greatly simplified w/ the "standard" .YML file -based flowgraph that is common for those using gr-satellites in GNU Radio. Would you prefer that I email you an example)

[XDjackieXD]

I don't have an I/Q recording handy but I can definitely record one at the end of this week on the flatsat (currently a bit sick else I'd do it tomorrow ^^).
Any benefit of doing multiple recordings with different SDRs (PlutoSDR, RTL-SDR, HackRF) and different attenuation?
Also any specific settings you'd like in the recording? (LO offset, sample rate)

[K4KDR]

If possible, please use an SDR that does not add the dreaded 'DC Spike' to the recording. (Products such as AirSpy & HydraSDR-RFone do not add the center spike). Of course, if the only SDR hardware available DOES add the center spike, kindly offset your RX frequency so that the entirety of your signal is clear of the center spike. We can adjust our playback offset as needed.

Any reasonable sample rate is fine. Since I/Q files can get large, it's helpful to keep the sample fairly short with a modest sample rate. For testing, a good clean signal is preferable. So, no need to artificially inject attenuation, noise, etc.

Just specify the type of file & sample rate when shared.

Thanks!

[XDjackieXD]

Will do thanks, I don't think I have a SDR without a DC spike so an offset will have to do.
I'll report back with samples in a few days.

[K4KDR]

Here is an example (UN-tested) of a basic satellite telemetry decoder using gr-satellites, configured for SpaceTeamSat1.

You can adjust the sample rate and specify file names for I/Q or Audio input files. Or, input 'live' audio from an SDR. Note that audio is only useful up to certain baud rates! The outputs are self-explanatory. It's common for each ground station to make adjustments to suit their own experience & preferences, so please do the same. (you can also include a SOURCE block in the flowgraph for your SDR hardware if preferred, including doppler compensation!)

What is lacking in this example (other than input files) is the .YML file that I'll leave to others to assist with. That will define all of your stated downlink modes & baud rates; that way, decodes are possible even from multiple modes/bauds in the same session!

The URL is --> https://www.dropbox.com/scl/fi/wjhhs7nng1fgvxtsiftz4/SpaceTeamSat1_YML_decoder.grc?rlkey=s3n8xvvo6g6kv15mnxvyxg4a7&dl=0

[daniestevez]

Modulation and channel coding is GMSK with 9600 Baud, dual-basis RS223/255, CCSDS scrambling and unpunctured convolutional coding.

All of this is already supported in gr-satellites, so a suitable SatYAML file should work. Once you share an IQ file I can validate that the SatYAML file works and add it. Documentation and/or code for a construct telemetry parser would also be appreciated, but probably I won't have time to turn documentation into code for this, so this will need support from your team.

I will move this issue to a discussion, since we have a specific discussions section for support to satellite teams.

[janvgils]

Good evening, up front all the best with your mission.

When the IQ is available I will also put some effort in creating a yaml file.
Please share the IQ details when it is available. sample rate, format, center frequency etc.

Jan | PE0SAT

[XDjackieXD]

Sorry for the long silence.
I finally got around to record the I/Q samples (https://data.space.tuwien.ac.at/index.php/s/9xPTjJWQyRakzFs).
They are recorded using a hackrf one clone at 8Msps with 200kHz lo offset. The file format is whatever GQRX records (according to them standard gnuradio complex sample format), in case this is an issue please let me know what format you'd prefer.
I tried to keep the samples short for filesize, if a longer recording works better please let me know as well.

I'll work on the telemetry parser definition next.

[K4KDR]

Thank you for the sample files! Can you confirm if those are 9600 baud signals (as mentioned in your original post).

And by chance was there any decimation applied to the SDR doing the recording... when I replay your files, at 8M sample rate they don't appear as I would expect. Thanks!

[XDjackieXD]

It should be without decimation (Config in GQRX was 8Msps, No Decimation, 3.2MHz Bandwidth).
Also yes I can confirm 9600 Baud, I can decode the Beacons with gnuradio directly connected to the hackrf set to 9k6.

[XDjackieXD]

I can replay the file with gqrx using file=/home/jakob/gqrx_20260128_174242_437195000_8000000_fc.raw,freq=437.195,rate=8e6,repeat=true,throttle=true as the file string and it is looking correct.

[K4KDR]

Very good - thank you. Could you please share the GRC file that produces decodes for you?

[XDjackieXD]

https://github.com/SpaceTeam/STS1_Channel_Coding_Tests/blob/master/sdr_trx_cosmos.grc this is what I'm running on the "groundstation" of our flatsat

[K4KDR]

Thanks again for the sample files & example flowgraph. Things were not working correctly for me because of the additional 256k decimation in the decoder flowgraph. If the payload shown below looks correct, I'll get this cleaned up for generic SDR (or audio) input and share for anyone interested.

[janvgils]

Good evening, after some testing and the hint given by @K4KDR I got a working solution.

name: SPACETEAMSAT1
norad: 99416
data:
  &tlm Telemetry:
    unknown
transmitters:
  9k6 FSK CCSDS downlink:
    frequency: 437.195e+6
    modulation: FSK
    baudrate: 9600
    deviation: 4800
    framing: CCSDS Concatenated
    frame size: 223
    RS basis: dual
    RS interleave depth: 1
    scrambler: CCSDS
    syncword threshold: 0
    data:
    - *tlm

gr_satellites SPACETEAMSAT1.yml --rawint16 iq_437195_125000.wav --samp_rate 125e3 --iq

***** VERBOSE PDU DEBUG PRINT ******
((transmitter . 9k6 FSK CCSDS downlink) (rs_errors . 0))
pdu length =        223 bytes
pdu vector contents = 
0000: 12 36 0e 0e 18 00 08 cc c0 0e 00 87 20 03 19 00 
0010: 0e aa 33 9e ef 34 3b 00 07 60 00 00 22 18 02 00 
0020: 00 00 ff ff 00 00 00 00 01 e0 9e ef 34 3b 80 00 
0030: 00 6f 00 00 03 73 00 00 00 00 00 00 00 00 00 00 
0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0080: 25 80 00 00 25 80 00 19 00 00 80 28 00 00 0d 08 
0090: 01 00 00 00 55 55 55 55 55 55 55 55 55 55 55 55 
00a0: 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 
00b0: 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 
00c0: 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 
00d0: 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 
************************************

Files can found at the following location.

Jan | PE0SAT

[K4KDR]

That's great, Jan!! And I've just finished testing a flowgraph from I/Q, audio WAV, and 'live' audio from GQRX if anyone would like a starting point in GNU Radio to adjust to their preferences.

The GRC file is at: https://www.dropbox.com/scl/fi/ybqu2swl9yynaemojpic4/sdr_trx_cosmos_2026-01-28_k4kdr-shared.grc?rlkey=4u74bfcezb9w5k9sthpoii25m&dl=0

... and the 48k audio file created from the Team's I/Q recording is at: https://www.dropbox.com/scl/fi/me04uf7vlnddq675s5ljm/FM-demod_SpaceTeamSat-1_sample_48k_AUDIO.wav?rlkey=kuzac5r8m39e4mk62owyp0w6e&dl=0

[daniestevez]

deviation: 4800

Wasn't this supposed to be GMSK? If so, the deviation would be 9600/4 = 2400 Hz.

[XDjackieXD]

Yes and apparently that has changed after I last measured it (probably while implementing baud rate switching as that has been done "last minute" and the Silabs WDS tool used to generate the register contents sometimes produces weird outputs when generating different configs in succession without closing the tool in between).
And thanks to massive time pressure I apparently failed to notice until now :/
Not the end of the world but that definitely shouldn't have gone unnoticed...

[janvgils]

deviation: 4800

Wasn't this supposed to be GMSK? If so, the deviation would be 9600/4 = 2400 Hz.

Also missed that one, updating the yml.