Observation 14183111: FrontierSat (69015) - Why is there no data demodulated?

Satellites & Observations Observations
1

Regarding Observation 14183111 …

I’m hoping someone can help me understand why this totally-normal observation with clear, decodable data from FrontierSat doesn’t have demodulated data available with it.

I’ve downloaded the audio and demodulated it with gr_satellites, so it’s definitely a solid pass (i.e., the issue isn’t that the data is undecodable).

It’s now from 28h ago, so it doesn’t seem to be a delay thing (as the “2026-05-28 17:32:37” message seems to suggest). Is it maybe a client version thing (client version 2.1.1).

It seems that there’s lots of these cases where solid observations aren’t demodulated.

As a satellite operator, is there a way I can go back and demodulate these observations, and then push the data to satnogs so it’s available for all?

We’re building workflows around SatNOGS as the main central point of datasharing, but issues like this make it challenging to trust we’re not missing opportunities.

2

Good day,

I have also see this before and we would need more information from this specific observation to get an better understanding.

We would need the original IQ stream from this observation, to try and recreate the situation during this pass.

Also understand that there are three possible technologies to get the receptions decoded and produce valid frames.

Below some generic streams:

Source IQ stream --> SatNOGS Flowgraph --> decode frames and forward to the network
                                       --> create demodulated audio in ogg format forward to the network
                                       --> Saved IQ file (option)
                                       --> UDP port --> gr-satellites (option)

When you replay with for example gr-satellites you can use two different sources, the ogg demodulated audio or if available the IQ recording, only the IQ is the same as the starting point from this observation the ogg is already demodulated by the satnogs flow-graph and therefor no longer the same.

You can replay where you add the --start_time as input so the correct creation time would be in the network, the only thing missing is the correct location on earth.

Jan | PE0SAT

1 Like
3

Follow-up Question 1: How does data get into the db.satnogs.org data export? Does all data from the “Data” tab on network.satnogs.org end up in DB data export?

Follow-up Question 2: Why is the IQ decoding path worse than the ogg decoding path? Is there a bug that needs to be resolved there? Is it a client version issue?

1 Like
4

Q1: The decoded data is forwarded from the client to the network. The file that is written in the decoded_data_file_path variable. and then forwarded. Here an example log message:

2026-05-30T20:48:52.746228688Z INFO     satnogsclient.scheduler.tasks   Upload of data for observation 14198546 successful.

Q2: That one is more difficult to answer, the IQ stream is both used by the satnogs flow-graph and also as input for gr-satellites, I have seen examples where gr-satellites is more successful and visa versa.

Disregard the missing blocks, but this image gives you maybe a better idea of how the received data is processed.

SatNOGS fm.grc as an example:

image
image992×442 65.5 KB

SatNOGS environment variables overview.

Jan | PE0SAT

2 Likes
5

Is there an opportunity to debug this and fix it? Or is this just a case of “it is how it is”?

After doing an inspection on all FrontierSat recordings in SatNOGS, it seems that the satnogs flow-graph is just strictly worse than gr-satellites at decoding the available recordings (9600 baud, AX100 FSM Mode 5).

Our team can obviously setup a data processing pipeline to re-process all the recordings, but I’m more interested in helping improve SatNOGS by improving the decoding/demod capabilities.

3 Likes
6

can you share your flowgraph version here. i will try to test this on my station

1 Like
7

FrontierSat uses the AX100 FSM Mode 5 flowgraph built into satnogs (at 9600 baud). I’m not certain how to provide the flowgraph though (and am not using one myself).

The gr_satellites file I’ve had success for decoding is as follows (if that’s what you’re asking about):

name: FRONTIERSAT
norad: 69015
data:
  &tlm Telemetry:
    telemetry: hexdump
transmitters:
  9k6 FSK downlink:
    frequency: 436.150e+6
    modulation: FSK
    baudrate: 9600
    deviation: 3200
    framing: AX100 ASM+Golay
    scrambler: CCSDS
    syncword: 4
    data:
    - *tlm

# Usage:
# sox satnogs_download.ogg satnogs_download.wav
# gr_satellites gr_satellites_frontiersat.yml --hexdump --wavfile file.wav
2 Likes
8

mine:

name: FRONTIERSAT
norad: 69015
data:
  &tlm unknown Telemetry:
    unknown
  &csp csp Telemetry:
    telemetry: csp
transmitters:
  9k6 FSK downlink:
    frequency: 436.150e+6
    modulation: FSK
    baudrate: 9600
    deviation: 2400
    framing: AX100 ASM+Golay
    data:
    - *csp

nice detail for syncword, scrambler and higher deviation than satyml file that used by my station (4451)

maybe your team can look here flowgraph_dispatcher/flowgraph_dispatcher.py · master · librespacefoundation / SatNOGS / satnogs-flowgraphs · GitLab
, and make some improvement, especially for

'FSK AX.100 Mode 5': {
    'script_name': SATNOGS_FLOWGRAPH_SCRIPTS['FSK_AX100_MODE5'],
    'has_baudrate': True,
    'has_framing': True,
    'framing': 'ax100_mode5',
    'outputs_frames': True

----------> 'FSK_AX100_MODE5': 'satnogs_fsk_ax100_mode5.py',

you can share your modified satnogs_fsk_ax100_mode5.py , for us to try

1 Like
9

Hi,

same here - I always get debug messages like this, but maybe they don’t really help …

73, Stefan / oe6isp

CCSDS RS Decoder1 :debug: dropping RS block due to error symbols
crc_async :debug: Wrong CRC
CCSDS RS Decoder1 :debug: dropping RS block due to error symbols
crc_async :debug: Wrong CRC
CCSDS RS Decoder1 :debug: decoded RS block with 7 error symbols
crc_async :debug: Wrong CRC
CCSDS RS Decoder1 :debug: dropping RS block due to error symbols
crc_async :debug: Wrong CRC
CCSDS RS Decoder1 :debug: decoded RS block with 0 error symbols

10

i check my log , and same with you:

satnogs_client_1  | 2026-06-07T03:04:34.508198644Z CCSDS RS Decoder1 :debug: decoded RS block with 0 error symbols
satnogs_client_1  | 2026-06-07T03:04:34.508315254Z crc_async :debug: Wrong CRC
satnogs_client_1  | 2026-06-07T03:04:54.981364960Z CCSDS RS Decoder1 :debug: decoded RS block with 2 error symbols

using latest satnogs-client docker

i notice this error not only for frontier sat, but also for other sat that decoded using this flowgraph, like 46912 - KSM1-A

1 Like
11

A few stations are able to decode, but I cannot find a difference in the signal. Maybe they use a different version.

1 Like
12

im wondering only gs that enabled gr_satellites that success decoded it.

1 Like
13

dev (cc: @sdoukos @fredy) should fix this broken satnogs_fsk_ax100_mode5.py

maybe this answer why all my ION-SCV- satellites series is broken…

14

v2.1.1 VS v1.8.1 (both decode without gr_satellites)

image
image678×650 99.7 KB

image
image691×569 88.1 KB

1 Like
15

My gr-satellites Yaml and version on one off my old 1.8.1 legacy clients.

gr_satellites --version

gr_satellites v3.22.0

Copyright 2016-2025 Daniel Estevez

License GPL-3.0-or-later: GNU GPL version 3 or later
<https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

name: FRONTIERSAT
norad: 69015
data:
  &tlm unknown Telemetry:
    unknown
  &csp csp Telemetry:
    telemetry: csp
transmitters:
  9k6 FSK downlink:
    frequency: 436.150e+6
    modulation: FSK
    baudrate: 9600
    deviation: 2400
    framing: AX100 ASM+Golay
    data:
    - *tlm

Jan | PE0SAT

1 Like
16

For me both versions are working perfectly in gr-satellites V5.9.0.

Unfortunately I was unable so far to get the gr-satellites running in the docker-environment

Stefan / OE6ISP

17

Add the variable GR_SATELLITES_ENABLED: 'true' in your docker-compose.yml or run satnogs-setup and enable it.

Jan | PE0SAT

2 Likes
18

Thx Jan! I didnt realize that it is that simple :slight_smile:

19

Hello,

Thanks , i was also wondering why i didn’t have so many data and didn’t find any yaml in the gr_sat repository. My stations are configured to use gr_sat as post operation (lot of SatNOGS groundsation operators have that configured also). I just added the yml file, let’s see if it will improve data aquisition for FrontierSat on my side :slight_smile:

20

Hello I got confused because the conversation moved on. Is something wrong with the ax100 flowgraph that we should check?

1 Like