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?
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?
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
“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:
Client runs observation task
Client runs every 2 minutes (if not changed) the upload task
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:
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.
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:
Vetting doesn’t affect data uploading
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)
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.
Observations data, currently as this will be changed in the future, can be retrieved from the Network API.
Satellites data, currently not by transmitter, can be retrieved from DB API or Satellite page after user authentication/login.
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”.
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.
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:
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)