I see that the observation is yet to be vetted, does the process to demodulate start after vetting? I would like to get into this open source project but first I have a few questions
Are the decoders built into the ground station when installed by the playbook? Are there any open source projects for parsing data from the audio files? I took a look at the list provided and the one modulation method I’m interested in is not listed (GMSK). I work in a university research lab and using a computer to slowely crank through audios files wouldn’t be a problem.
Are there are rules against crawling the observations? I looked in the robots file for the overarching satnogs.org/robots.txt and it doesn’t seem like I would be restricted from there if I created a webcrawler that would pick up a set amount of audio files before attempting to parse the information.
Let me know if I am in violation of any rules I’m not aware of in case this post violates that.
Demodulation happens on client during an observation, if there are any demodulated frames then they are uploaded to Network and are visible in the observation page.
Vetting is manually done at least for now, except if there are any demodulated frames, this some times gives some false positives, like vet as good an observation with demodulated frames from other satellite or false CW decoding.
About RADSAT-G and the linked observation, I think that the signal doesn’t belong to RADSAT-G but we need to confirm it by checking if other satellites were over the station and transmitting at near frequency, for example UNISAT-6.
I don’t think that is RADSAT-G, because it has never transmitted, and also it follows some TLE (Object with NORAD ID 43553) that we are not 100% sure that belong to RADSAT-G as we had never heard it.
Just to be accurate what is built in client that is installed in ground station is scripts for demodulating. Decoding part comes later in SatNOGS DB if there is a decoder in satnogs-decoders project.
Depending on the modulation there are, for example direwolf.
You can use the Observations API to get the info about the audio files you want, you can also use filters on this API endpoint to make sure that you get only the results you need. There isn’t currently a specific rule, but I would suggest to limit your crawler to 1 request per 2 seconds for the API.
By the way have in mind that audio is a compressed result with a limited bandwidth which is smaller than the one shown in waterfall. This means that visible signal in waterfall doesn’t mean that it will be always able to be demodulated.
I have a hunch it is RADSAT-G because at my place of work we have a groundstation that is tuned to 2m and 70cm bands particularly around 435 MHz. I’ve been able to run observations that show the beacon of the cubesatellite on each pass. The design of RADSAT-G’s beacons are ~2m apart with 3-5s space between each of the beacons. The radio used on the cubesatellite has been known to go into a thermal lock state where its max transmit power is limited to .1W instead of 1W. Which is one of the theories on why it has been so quiet.
On the subject of the compressed audio files being uploaded. I noticed the the resulting waveform (once all of the AGC noise is cut out) is very downsampled, which is of course caused by the compression. Has anyone tried interpolating the resulting waveform before attempting to decode the waveform?
If I end up writing a crawler I’ll make sure to limit my queries to at least 2s at the fastest polling rate. I think I want to try and see if varying degrees of interpolating the signal will result in anything before I work on the crawler and processing stage.
I took the liberty to vet as yet unvetted observations, and also re-vetted earlier observations that were vetted as good, but did not contain the same signals as we see now.
These are objects 43546 through 43554, of which CSpOC has identifications for all but 43551/98067NZ, 43553/98067PB and 43554/98067PC. We’ve identified 43551/98067NZ as EnduroSAT One, so if we trust the other identifications then that leaves MEMSAT with BPSK9k6 at 437.350 MHz and RADSAT-G with GMSK19k2 at 437.425 MHz.
The TLEs for all these objects have drifted far apart, so given that we are seeing signals on 437.425MHz that follow the TLE, suggests to me that the TLE matches the frequency, and given that the frequency matches the satellite, the TLE matches the satellite, and hence that the identification is correct.