There is no LRPT decoder flowgraph in satnogs by default. There is a thread… somewhere on here about adding a custom one to decode it. Your station is probably using the default FM flowgraph, which results in a waterfall with a narrower bandwidth (48 kHz) than the LRPT signal (~80 kHz).
However, I’m not sure if Meteor M-2 is functional at the moment? I know there was some issue with loss of attitude control a few weeks ago, unsure if it’s been resolved.
As for signal, from the bit that I can see on that waterfall, you are receiving it, but there is a lot of fading, which could be the attitude control issue.
Can i set a broader bandwidth in my station settings or od this something to choose when scheduling? If i were to use broader bandwidth is there drawback for receiving other data or is it just more computation to be performed on my raspberry?
The resultant bandwidth is set in the flowgraph, so it can’t be overridden from scheduling or settings.
In the case of the FM demod it’s 48 kHz. The solution here is a proper LRPT flowgraph integrated properly into SatNOGS, however since LRPT decoding is currently a two-stage process requiring a post-observation script to post-process received samples, it hasn’t been included…
Do in this case decoded image is produced by software not installed in satnogs raspbian distro by default ? Awesome that satnogs service od extensible do it allows additional decoding. I will look for thread about it.
@EelkeVisser that is so awesome - do I understand this correctly - I can execute any code which will perform decoding generate some artifacts into directory and then this will be uploaded to satnogs db? Is there limitation of file types or sizes?
Broadly speaking are there more cases of such let’s say “contrib” decoders here on forum? It would be awesome if they would be integrated with the base distribution - of course if licencing is not a blocking issue or something.