Can you please change the baud rate for RadSat-g to 19200? It is currently at 9600.
Thank you,
Brock LaMeres (Bozeman, MT)
I’ve just seen this request, please for such requests in the future, use the suggestion functionality in SatNOGS DB after you login with the same credentials you log in here.
From this observation https://network.satnogs.org/observations/2219639/ it seems that RADSAT-G is still transmitting with 9600 baud rate as there are decoded data. Was this changed back or we should change it to 19200 as it is going to change in the future?
Yes, please change back to 19200. We had luck at the 19200 audio setting by running a post-processing script on the SatNogs audio files. It worked well while at 19200, but it immediately stopped working when I requested we go back to 9600.
Thanks and apologies for posting to the wrong area.
Brock
We would like it changed to 19200. We have found that at 19200, we are able to post-process the audio file and retrieve data more reliably than having SatNogs set to 9600.
Thanks,
Brock
@lameres changing baud rate to something that is not right for just decoding is the wrong way to go. For solving the decoding issue we will need to improve the current script that runs in SatNOGS clients.
Please for moving forward open an issue in satnogs-flowgraphs repo. For checking this quicker I suggest you provide any details on decoding and if there is available any IQ file from satellite’s transmission in order to be able to test changes on the decoding script.
I’m cc’ing @surligas, as he may give or ask more details about it.
I’m wondering if the issue presented here is more due to the spacecraft using a wider modulation index than is expected by the flowgraph.
The flowgraph currently uses the baud rate (and probably some assumed modulation index), to determine the width of a filter to put around the signal before performing FM demodulation and producing the output audio file. This filtering is performed in an attempt to improve the SNR of the FM-demodulated signal. This audio file is what’s being used by Brock above to do post-processing and demodulation.
If the assumptions about modulation index are incorrect, then the signal may be incorrectly filtered, resulting in clipping or some other corruption, and hence not being decodable.
Once we have more metadata about the transmissions in the DB, then this problem will go away, but in the meantime I don’t see an obvious solution.
vk5qi,
What you are saying is what we think is going on. When we were using audio files from the 19200 setting, it seemed that our script could successfully determine data at 9600. But once we changed the SatNogs br to 9600, the audio files appeared to not have enough band width for our script to decode at 9600.
What do you propose? Would it help for us to send you our script? Or can SatNogs widen the width of the filter for RadSat-g to match what it would have been at 9600?
Thanks,
Brock