When to expect decoded data?

Is there a way to know when I should expect decoded data for an observation?

It seems like the “Data” tab always displays “Waiting for demoded data”, even for transmitters where we don’t expect to be able to decode data?

Some modes, such as voice, will never have data I guess. On the other hand, CW should always have decoded data, right?

Is there a way to tell if a given transmitter should give decoded data? Opening the satellite in Satnogs DB doesn’t seem to show anything about decodes.

Is the best way to go to ksy · master · librespacefoundation / SatNOGS / satnogs-decoders · GitLab and see if there is a file for the satellite?

Some related questions that I found answers to here in the forum. Adding them for completeness:
Q: When are decodes created? By the observing station, during the observation? Or later, of the observation is vetted “good”? Or something else?
A:

By the observing station, during the observation. Source

Q: If an observation looks good according to the waterfall, but there is no decoded data, is there a way to try to figure out why no data was decoded?
A:

If the observation is more than 1h in past you can say 99.99% safely that it is not going to get any data source

Also related: Actually getting data from Observations? (very old though so some things are probably out of date)

1 Like

“Waiting for demoded data” (and also “Waiting for waterfall” and “Waiting for audio”) is the placeholder of the tab when there are no data to show. If the observation is in the future or usually in the recent past (<10-15m) then we still expecting the data, otherwise is unlikely that the client will upload any data.

Currently in each station that uses the client image this is what happens:

  1. Client runs observation task
  2. Client runs every 2 minutes (if not changed) the upload task
  3. If there are data, even for an observation that is not finished yet, then they will be uploaded by the upload task every 2 minutes.

About decoded data… usually we confuse demodulation and decoding… so there are two processes:

  1. Demodulation:
    This happens on client side by using the gnuradio scripts of gr-satnogs project. The scripts create frames that will be uploaded to the network. Some of them (currently for selected satellites) will be pushed immediately to DB.
  2. Decoding:
    DB stores demodulated frames from many sources (Telemetry Forwarder, gr-satellites and Network). Through the satnogs-decoders project, these frames (for the satellites that have a decoder) are decoded and pushed to another database as decoded data for being visualized by grafana in Dashboard.

Disclaimer: Sometimes we refer to demodulation as decoding but we really mean demodulation. Also in some cases demodulation and decoding can be the same like in some CW cases.


About the 2 Q&A some comments:

  1. Vetting doesn’t affect data uploading
  2. When an observation gets some data, it is automatically vetted as good, however this doesn’t always mean that data are correct (for example the known CW issue) or from the transmitter that was scheduled (crossovers of satellites happen sometimes)
  3. 1h and 99.99% is just a safe assumption. As described above, usually we have data much earlier but we have seen cases that there was an internet connection error on the station and the data were uploaded after some time when the internet connection was restored.
  4. Observations data, currently as this will be changed in the future, can be retrieved from the Network API.
  5. Satellites data, currently not by transmitter, can be retrieved from DB API or Satellite page after user authentication/login.
3 Likes

Thanks for explaining.

If I want to see what demodulation and decoding a particular satellite uses (for example https://db.satnogs.org/satellite/40908/ ) - what would I do?
I tried searching for “lilacsat” in the two repos you linked, but got no hits. I also tried searching for file names containing “lilacsat”.

It is as easy as that: there is no lilacsat demodulator or decoder :wink:

I see. That explains why my station never is able to get any decoded data for that satellite :wink:

Is the method I used (search both repos for matches on the satellite name) the easiest way to find out, or is there a simpler way?

There seem to be decoded data, even though there are no decoders. See https://network.satnogs.org/observations/?future=0&bad=0&unvetted=0&failed=0&norad=40908&observer=&station=&results=d1&start=&end=

Mightily confusing

Its demodulated data only. The decoding goes from what you see in the data tab to actual values say visible in the dashboard. https://dashboard.satnogs.org/d/QjDe5S8mk/satellite-telemetries?orgId=1

But DL4PD stated above that there is no demodulator for that satellite?

I think he might have forgot? It has a CW, AFSK and GFSK transmitter which are all transmission types that have demodulators for in gr-satnogs

Since this might be confusing especially to new users I just opened an issue (satnogs-network#711) to track this.

2 Likes

Is there a more efficient way to determine if a satellite has demodulators, and if it has, which demodulators are used, than asking here in the forum (and relying on people’s potentially imperfect memory)?

It seems like the methods I tried (searching the repos for the satellite name + looking at the Satnogs DB page for the satellite) are unreliable.

1 Like

Yes, but unfortunately it requires quite a few steps.

Right now, to gather reliable information which transmitters of a satellite can be received including demodulation by a given station you have to check the following sources:

  1. Check which ‘Downlink Mode’ is used by the transmitter in https://db.satnogs.org
  2. Check which flowgraph corresponds to the given mode in satnogs-client:scheduler/tasks.py#L53-70
  3. Check if the flowgraph is available in gr-satnogs:apps/flowgraphs

The links given above assume that the station is following the ‘stable’ branch of satnogs-client-ansible, i.e. that it was installed using the pre-generated SD-card image, no advanced configuration was changed and the latest updates were installed using ‘satnogs-setup’. Such a station would currently have the following software versions:

1 Like

Thanks! While fewer steps would be nice, I don’t mind digging a bit now that I have a process to follow :slight_smile:

For AAUSAT 4 https://db.satnogs.org/satellite/41460/ we have 3 transmitters, using the following modes: CW, GMSK9k6, GMSK2k4
In this case I’m interested in the GMSK modes, which both use GNURADIO_MSK_SCRIPT_FILENAME according to https://gitlab.com/librespacefoundation/satnogs/satnogs-client/-/blob/1.0/satnogsclient/scheduler/tasks.py#L53-70

https://gitlab.com/librespacefoundation/satnogs/satnogs-client/-/blob/1.0/satnogsclient/settings.py#L57-66 shows that GNURADIO_MSK_SCRIPT_FILENAME is satnogs_msk_ax25.py
I can then look at satnogs_msk_ax25.py at https://gitlab.com/librespacefoundation/satnogs/gr-satnogs/-/tree/v1.5.1/apps/flowgraphs

I would guess that https://gitlab.com/librespacefoundation/satnogs/gr-satnogs/-/blob/v1.5.1/apps/flowgraphs/msk_ax25.grc is also involved somehow? Is there an explicit connection between satnogs_msk_ax25.py and msk_ax25.grc somewhere, or is the connection just inferred by the name?

1 Like

I believe the satnogs_msk_ax25.py is the python version of the grc that gnuradio outputted. (GNURadio builds .grc files to python files when you run them. So I believe we have them pre-built in the repo)

I might be wrong but its from what I remember.

1 Like