Impact of SDR ADC Resolution on Telemetry Decoding (QMR-KWT 2 / SAKHACUBE-CHOLBON)

SatNOGS
1

Hello everyone,

Recently, I have been trying to acquire telemetry data from QMR-KWT 2 and SAKHACUBE-CHOLBON. However, I have not been successful so far.

After checking observations on the SatNOGS network, I noticed that successful telemetry decoding seems to be mainly achieved by the following stations:

One common feature among these stations is that they use SDRs with 12-bit ADCs, which are higher performance compared to the 8-bit ADC of RTL-SDR.

My question is:
How significant is ADC resolution for successful telemetry decoding in these cases?

For reference, my SatNOGS station (ID 4394) uses an RTL-SDR. I have successfully decoded telemetry from satellites such as UmKA-1, but I have never succeeded in decoding telemetry from these two satellites.

Interestingly, when I record the audio and input it into SoundModem, decoding sometimes works.

I would greatly appreciate any insights into:

  • The impact of ADC resolution on decoding performance
  • Possible reasons why offline decoding (via SoundModem) works while real-time decoding does not

Thank you very much for your support.

2

Apart from the resolution there is also the LO used, and the noise figure from the receiver.

I can share some IQ recording from the observations so you can compare them to your own.

Regarding Sound modem software, it is highly optimized by UZ7HO and when you replay the observation audio you are using the demodulated signal and not the IQ stream as with real-time observations.

Some comparison I did in the past, cab be found at this location.

I have a look your observation with id 13635213, the SatNOGS network is not able to decode USP framing so you will need the gr-satellites integration.

When I replay your obs 13635213 I am successful in decoding the frames, I do see the received signals aren’t centered in the spectrum, maybe you need to check and correct your SDR LO, this can be done with the ppm variable.

gr_satellites SAKHACUBE-CHOLBON.yml --wavfile 13635213.ogg --samp_rate 48e3

-> Packet from 2k4 FSK downlink
Container: 
    header = Container: 
        addresses = ListContainer: 
            Container: 
                callsign = u'R2ANF' (total 5)
                ssid = Container: 
                    ch = False
                    ssid = 0
                    extension = False
            Container: 
                callsign = u'RS18S' (total 5)
                ssid = Container: 
                    ch = False
                    ssid = 1
                    extension = True
        control = 0x00
        pid = 0xF0
    info = b'FB\x02\x00\x01\x00\x19\x00\x01\x00\xffn"\x0e\x00\x0eT\xa8\xc0i\x02\xd2\x00\x00`\t\x00\x00&\x00\xf4\x1e\x00!\xde\x04\x00\x01\x00.\x00\xfc\x14D\x05\xf1\x15\x06\x01\xc6\x04\x01\x00h\x00\x00\x00#\x00\x00\x00\x00\x00w\xfe}\xfe}\xfed\xfe0 \x00\x00\xcc\x1e;\xd2\x00\x00\xb5\xcd\x95Z\x8f\x04' (total 87)

Jan | PE0SAT

2 Likes
3

Hi! nishikazu0417, I’m using the gr-satellites integration + satyaml files.

2 Likes
4

Hello,

It is not related to the equipment (well it can be, but i don’t think it is the case here).

Like @PE0SAT said, gr-satnogs doesn’t support the sputnix platforme USP format. You have to rely on gr-sat. Jan share with you the yaml file for SAKHACUBE-COLBON, i added the one for QMR-KWT 2 few weeks ago in gr-sat (have in mind that at that time QMR-KWT 2 had a temporary NORAD ID, so you have to change the one in the file to 67291 [ I didn’t have the time to create a new PR for it yet, i will do it asap).

Also, regarding successful telemetry reception, have in mind that stations doesn’t always upload frame directly within the process of an observation, sometimes it is done via sids afterward, so you won’t see it on the SatNOGS network website. For instance, regarding QMR-KWT 2 , you can see on its dashboard that there are more stations receiving it than the ones you listed in your post :slight_smile:

2 Likes
5

One thing I forgot to mention, the filtering and dynamic range of the SDR is also of influence of the reception quality.

Jan | PE0SAT

2 Likes
7

Hello @PE0SAT, @JH4XSY, and @deckbsd,

Thank you very much for your helpful advice!

To provide some additional context, gr-satellites has already been enabled on my SatNOGS station for some time by adding the following settings to docker-compose.yml:

> - GR_SATELLITES_ENABLED=true
> - GR_SATELLITES_APP=gr_satellites
> - GR_SATELLITES_KEEPLOGS=true

With this configuration, I have been successfully decoding telemetry from satellites such as UmKA-1. (Apologies if there are any mistakes or missing points in my setup.)

Based on your suggestions, I will first check the LO configuration.
I will also review the gr-satellites settings in more detail.

If necessary, I may ask for IQ recordings for further analysis.

Thank you again for your support, and I appreciate your continued guidance.

8

What SatNOGS docker install/config are you using ?

Did you configure your own docker-compose.yml or are you using the sudo satnogs-setup method ?

Jan | PE0SAT

1 Like
10

Hello Jan,
Thank you. As requested, I am using a custom docker-compose.yml file for my SatNOGS setup.
For your reference, here is the full content of my docker-compose.yml:

docker-compose.yml 
#version: "3.8"

services:
  rigctld-uhf:
    image: librespace/hamlib:latest
    #network_mode: host
    restart: unless-stopped
    command:
      - rigctld
      - -m
      - "1"
      - -T
      - 0.0.0.0
      - -t
      - "4533"
      - -vvvv
    healthcheck:
      test: ["CMD-SHELL", "rigctl -m 2 -r 127.0.0.1:4533 f >/dev/null 2>&1"]
      interval: 5s
      timeout: 2s
      retries: 6
    networks:
      - satnogs-uhf-net


  satnogs-uhf:
    image: librespace/satnogs-client:master-unstable
    container_name: satnogs_uhf
    depends_on:
      - rigctld-uhf
    #network_mode: host
    restart: unless-stopped
    devices:
      - /dev/bus/usb/001/002:/dev/bus/usb/001/002
    tmpfs:
      - /tmp
    volumes:
      - ./uhf:/var/lib/satnogs-uhf
    environment:
      - SATNOGS_STATION_ID=4394
      - SATNOGS_API_TOKEN=[TOKEN VALUE]
      - SATNOGS_NETWORK_API_URL=https://network.satnogs.org/api/
      - SATNOGS_SOAPY_RX_DEVICE=driver=rtlsdr,serial=UHF,biastee=true
      - SATNOGS_RIG_IP=rigctld-uhf
      - SATNOGS_RIG_PORT=4533
      - SATNOGS_RF_GAIN=28.0
#      - SATNOGS_RF_GAIN=22.9
      - SATNOGS_RX_SAMP_RATE=2.048e6
      - SATNOGS_PPM_ERROR=-3
      - SATNOGS_ANTENNA=RX
      - SATNOGS_DEV_ARGS=
      - SATNOGS_OUTPUT_PATH=/var/lib/satnogs-uhf
      - SATNOGS_SAVE_IQ=false
      - SATNOGS_STATION_LAT= [LAT VALUE]
      - SATNOGS_STATION_LON= [LON VALUE]
      - SATNOGS_STATION_ELEV=10
      - SATNOGS_ARTIFACTS_ENABLED=true
      - SATNOGS_ARTIFACTS_API_URL=https://db.satnogs.org/api/
      - SATNOGS_ARTIFACTS_API_TOKEN= [TOKEN VALUE]
      - GR_SATELLITES_ENABLED=true
      - GR_SATELLITES_APP=gr_satellites
      - GR_SATELLITES_KEEPLOGS=true
    command:
      - /bin/bash
      - -lc
      - |
          set -euo pipefail
          # rigctld が 4532 を開くまで最大60秒待機
          for i in $$(seq 1 60); do
            if exec 3<>/dev/tcp/rigctld-uhf/4533; then
              echo "rigctld on 4533 is up"
              exec 3>&- 3<&-
              break
            fi
            echo "Waiting rigctld on 4533... ($$i/60)"
            sleep 1
          done

          # 念のため一時ディレクトリを用意（存在しててもOK）
          mkdir -p /tmp/.satnogs/data/incomplete /tmp/.satnogs/data/complete

          # 本体起動（PID1 を置き換え）
          exec satnogs-client
    networks:
      - satnogs-uhf-net

networks:
  satnogs-uhf-net:
    driver: bridge

Please note that the PPM correction value was added recently.
(The API token has been renewed.)

Please let me know if anything looks incorrect.

Kazuki NISHIOKA | JF6FYI

11

To be able to add and modify gr-satellites yml files I have created a separate volume where these are stored.
This gives me the opportunity to add also temporary yml files.

      - type: 'volume'
        target: '/usr/lib/python3/dist-packages/satellites/satyaml'
        source: 'satyaml'

volumes:
  satyaml:

I hope this snippets is enough for you to modify your compose and make use of this setup.

Jan | PE0SAT

4 Likes
12

this is the super answer. every station should enable this advice

2 Likes
13

Hello Jan,

Thank you very much for the excellent code snippet!

I will integrate it into my docker-compose.yml and try receiving again.
I will let you know once I have the results.

Thank you again for your support, and I appreciate your continued help.

Best regards,
Kazuki NISHIOKA | JF6FYI

14

recommend satyaml collection by @PE0SAT here: GitHub - janvgils/Launches: Information sharing on coming launches · GitHub

and @SA2KNG script here: satnogs-client-docker/addons/scripts/liveupdate-satyaml.sh at main · kng/satnogs-client-docker · GitHub

1 Like
15

Only the ones with custom docker-compose can use this.

1 Like
16

This options also comes with yml management, keep that in mind.

I have already been in the situation where I forgot the change temporary ID’s to there definite one and disrupted the SatNOGS db storage.

Please keep that in mind.

Jan | PE0SAT

1 Like
17

O dear, that reminds me, I also need to update those, it is a git repository I hoped others would also help by proposing updates (pull requests).

Jan | PE0SAT

2 Likes
18

The two satellites you mention, QMR-KWT2, and Sakhacube-Cholbon. I have not had any difficulty receiving telemetry from QMR-KWT-2 using my cheap RTL-SDR v3 dongle. I posted YouTube videos showing my setup and packets being received. Search YouTube for Satellite QMR-KWT 2 (RS95S) Telemetry recording over Fortaleza. The other one, Sakhacube-Cholbon, I’m still trying! I’m having problems finding the correct UZ7HO Soundmodem for GMSK 9600. 73, PU7MOJ

1 Like
19

Hello dean,

Thank you very much. I have also successfully decoded real-time packet data from both satellites using RTL-SDR v4 and Soundmodem.
However, the issue is that I have not been able to properly decode packet data and upload it to SatNOGS using my SatNOGS ground station.
I am currently working on this problem and adjusting my SatNOGS GS setup based on Jan’s advice.

73,
JF6FYI

20

Thanks for your reply. Can you tell me which soundmodem you used? 73, PU7MOJ

1 Like
21

Hello dean,

I have previously used “High-Speed SoundModem by UZ7HO - Ver 0.12b - [GMSK USP 9600bd]”, which was published by sputnix, to successfully decode telemetry data from QMR-KWT-2 and SAKHACUBE-CHOLBON at 9600 bps (GMSK USP).

However, I have not yet been able to decode the telemetry of SAKHACUBE-CHOLBON at 2400 bps (GMSK USP).

73,
JF6FYI