I’m turning to you for help again today because I’m having problems automatically decoding the Meteor-M satellites (LRPT) with my SatNOGS station(s). Since I have already invested some time and am beginning to doubt my debugging attempts, I wanted to ask if anyone has any tips or has the same error. I also hope that this is the right place for this request. I was thinking about creating a GitHub issue.
Background information / my current understanding:
I run my station in a Docker container on a Raspberry Pi 5.
I use the experimental image from sa2kng because I had no success with the standard image(s) and because it perfectly covers my other needs.
In the station.env file, I configured the UDP host and the lines (relevant in my eyes) for automatic Meteor decoding.
The message Could not open input file appears in the log after calling meteor.sh.
I cannot understand where this message comes from, since this error message does not appear in udp2ishort.py, meteor_demod, and meteor_decode either!?
I’m also confused as to why satnogs_fm.py is logged as the script name.
I have attached my station.env and the error message. If anything else is needed, I will of course add it here.
if the flowgraph running is satnogs_fm then you have selected the wrong transmitter. the client doesn’t support lrpt so selects fm in that case, and as you can see in the spectrum plots, it is only about +/- 20kHz.
that is the reason we added the “IQ recording usage” transmitters some years ago, as these specifies fsk as modulation and 40k as baudrate, which results in a wider bw.
I can see you made at least one of these in 11813358.
Thanks for the answer @SA2KNG ! The tip was helpful.
My understanding now is that the meteor_decode is not able to (meaningfully) read from the console’s standard input. This could mean that the UDP stream/encoding is not working properly. It may help to play with the UDP_DUMP_HOST address in station.env, but unfortunately, I have not had any success with this in the past.
In my new recordings, I have now switched to IQ recording (as in the observation you mentioned), as I had also identified this as an error from another forum post. The log now also seems to agree. No more errors and Meteor demod+decode: 11824131, Norad: 57166, Name: METEOR-M2_3, Script: satnogs_fsk.py. Further down (now new): MPDUs received: 0 (0 lines). Maybe I was just unlucky with this observation…
SLEEP-Now is a hint to me that I should take care of improving my temporary solution : I had the problem that when two SatNOGS stations (both connected to the same Raspberry) started a recording at exactly the same time, one of the two RTL-SDR receivers (or the USB bus) would drop out and then one of them would always fail. I therefore currently delay the ‘weaker’ station by approx. 1-2 seconds before recording in the pre-observation script. I have now also commented it out for testing.
Ok, we did test this in the past, but I don’t remember any issues with the stdin method, but maybe we missed that.
I don’t have any good antennas on VHF now, but a good IQ recording could help with testing this theory, actually got one from Jan just now.
summer vacation getting closer, so maybe there’s some time available to mess with this (:
This little ‘bug’ has also kept me busier than it should Still no success so far. I have now set my sampling rate to 2.048e6 (from 1.024e6). But that shouldn’t really matter, as a bandwidth of 120kHz is actually used… Perhaps there is a problem with the conversion. I have not seen any station using a sampling rate below 2 MHz that automatically decodes Meteor LRPT in SatNOGS. There are no more errors in the log, and at the end, MPDUs received: 0 (0 lines) is still displayed. I am waiting for the next passes. However, it appears to me that meteor_decode is now at least being called correctly. If you also need an IQ recording from me, please let me know.
I had a look at Jan’s observation 9823084 with a iqdump, and it is running at 160ksps, symrate 72k non-interlaced. The stdin method isn’t the issue here afaict.
As the script is written, it tries to autodetect 80k/72k symrate based on the baud*2, which means the FSK-40k runs at 160ksps and 80k symrate, which doesn’t match what the satellite was transmitting at that time.
For testing, you can change this line to hardcoded 72k: SYMRATE=72000
With the updated variant (meteor.sh), the error Could not open input file no longer occurs, but neither does MPDUs received: 0 (0 lines) at the end. So, no error is logged, but unfortunately, no image either.
The odd thing is that it is in batch mode, and have the quiet option set, so I don’t even expect it to print anything… I don’t have enough signal strength on my VHF antenna to reliably decode any of these.
The last obs was a pretty low pass as well, maybe no lines ok.
During a Meteor pass, can you run htop to monitor the two meteor_* programs are running and consuming some cpu ?
Inside the container, look in the output data path if there’s some image left. find /tmp/.satnogs/data
: I had the problem that when two SatNOGS stations (both connected to the same Raspberry) started a recording at exactly the same time, one of the two RTL-SDR receivers (or the USB bus) would drop out and then one of them would always fail. I therefore currently delay the ‘weaker’ station by approx. 1-2 seconds before recording in the pre-observation script. I have now also commented it out for testing.