Any chance of an updated summary of how-to decode Meteor M 2 and 2-2 on satnogs station? This thread is over a year old now and with so much information it’s a bit overwhelming 
Meteor MN2 decoder for rpi 3B+
2 Likes
Agreed. If I manage to gather enough information and get it working, I will be happy to update wiki.
3 Likes
It would be great, does anyone know of satellites that send images like METEOR and NOAA but in the band UHF (430MHZ) approximately ???
PSAT-2 sends SSTV on 70cm, but it’s not as detailed as NOAA or Meteor.
1 Like
Hi all,
I just got Meteor M2 processing working again, planning on fiddling with Meteor M2-2 later. If I get everything working I might create a repo with a Makefile to get/build/install/config/patch everything necessary for the Meteors, and then create a wiki page about it. Would there be support for this from the satnogs team, as it would involve a post install satnogs-client patch or a satnogs-client fork?
3 Likes
It would be really helpful to have the right default transmitters selected when you schedule an observation on the Meteors:
Meteor-M 2: LRPT 1 (137.100 MHz)
Meteor-M 2-2: LRPT S-E RHCP D 72 kbps (137.900 MHz)
I’ve added two suggestion for moving from active to inactive these transmitters:
Meteor-M 2: LRPT 2 (137.900 MHz)
Meteor-M 2-2: LRPT S-E RHCP D 80 kbps (137.100 MHz)
and then approved them. By the way anyone can add suggestion into the DB for transmitters.
So, with these as inactive the ones in the post above are the default ones now.
Ping me here or add a suggestion in DB if anything changes. 
2 Likes
This is great. I would be happy to test this and help with wiki as well! Count me in
2 Likes
Ok, I have implemented a new process_meteor.py based on the python scripts by @vk5qi and @benelsen. It takes an observation id and tle string as arguments, and then runs the right demodding/decoding tools. The only manual changes to satnogs-client that are needed are adding satnogs_lrpt_demod.py for LRPT observations to settings.py and tasks.py as was necessary for M2 1 already. Furhtermore, you should edit satnogs_lpt_demod.py to always output iq files. To use it, you should set the following value as post observation script in satnogs_setup:
/path/to/the/script.py --id {{ID}} --tle {{TLE}}
The script does the following:
- Meteor M2: Use medet to generate images from the s-file generated by satnogs_lrpt_demod
- Meteor M2 2: Use meteor_demod to generate an s-file from the iq-file from satnogs_lrpt_demod, then use medet to generate images from that s-file.
If anyone wants to test it or have a look at it, it’s on my github. You need medet and meteor_demod (devel branch) installed and you need to update the paths to these tools and to the satnogs_lrpt_demod output files in the beginning of the script to the correct ones.
Some words of warning:
- Thermal images are not produced yet, only a false color image and images for the separate channels, I will add this later.
-
[edit: the following is fixed]: I have not been able to get a proper image from Meteor M2 2, even on passes where @benelsen’s station did produce images. I tried to use the same command line options for medet and meteor_demod as @benelsen did, however he used
-Fas argument for meteor_demod in his scripts which is not supported in the latest version of meteor_demod, so there could be something wrong there. I do get a lock on the signal in meteor_demod, medet seems to decode some packets too, but there are no images produced. It could be that M2 2 just needs a bit more SNR than my station produces. My command line options are the following, @benelsen, could you have a look to see if you are doing something differently?
MEDET_ARGS_M2_2 = ['-q', '-S', '-r', '65', '-g', '65', '-b', '64', '-diff'] METEOR_DEMOD_ARGS_M2_2 = ['-B', '-R', '5000', '-f', '24', '-b', '300', '-s', '156250', '-r', '72000', '-m', 'oqpsk']
1 Like
Rico,
Not tried this out…yet.
Having a read through I am assuming you used @BenNelsen’s changes to ‘satnogs_lrpt_demod.py’ to dump the .iq file prior to processing with your modified ‘process_meteor.py’.
Also, shouldn’t your post observation script send the sat_id as well?
Michael
Hi,
True, I also updated the satnogs_lrpt_demod.py script to always dump the iq file, but to my understanding this can also be configured in satnogs_setup.
The sat_id is extracted from the TLE data. I used a TLE data argument because that is available als a post observation script argument out of the box, no changes necessary. Instead of the full TLE you can also use the --sat_id argument to pass the sat id, which is easier when you start the script by hand.
I currently have been able to produce Meteor M2 2 images, so the complete setup seems to be working now for both Meteors. It turns out the devel branch of meteor_demod has some improvements to get a more reliable lock, one of which is the possibility to specify a frequency delta -d, which is the distance from the center frequency that the demodulator will look for a carrier. Since the observations are doppler compensated and the satellite’s frequency is quite stable this delta can be set quite tight, I have set it at 1000 Hz which works nicely for me. I have updated the script on my repo with this change.
First working observation. Has a lot of black bars, but hey, it’s something.
https://network.satnogs.org/observations/1301416/#tab-data
@Rico I see you managed to get it working!
I probably forgot to remove the -F argument, which I implemented on a fork of meteor_demod because sometimes the frequency wandered off and failed to get a lock. This is now on the devel branch as -c and -d. (I set mine to 1000 as well, but a tighter delta might work better, the signals from the 2 satellites appear pretty stable at around +200Hz for me).
I found that I get the best results with a PLL bandwidth (-b) of around 75 for M N2 (40069) and around 250-350 for M N2-2 (44387). Reducing the RRC filter order -f didn’t affect the demodulation too much for me and speeds the process up a bit on the Pi, but might depend on the RFI at your location.
I switched to use medet for both satellites as well, it’s a bit quicker and meteor_decode sometimes produced images with misaligned channel.
Here’s my current process_meteor.py (ignore the ntfy stuff, it’s simply a push notification whenever a Meteor-M observation succeeds/fails)
Remember that with medet you need to update your script every time they change channels/AP IDs if you want all 3 channels. I try to keep https://github.com/benelsen/weather_satellites updated, but usually only after an or two observation return blank images.
Hi @benelsen, thanks for your response. Ok, so our findings correspond. The max freq delta of 1 kHz helps a lot I’m also seeing better results with a loop bandwidth of 300, and lowering the RRC filter order does not seem to matter much, so I’m keeping it at 24:
Images:
BW 100, RRC 64
BW 300 RRC 64
BW 300 RRC 24
Anyone willing to experiment can try to use my process_meteor.py, see a few posts up for instructions, I will make something to auto-install on an existing satnogs setup later.
That already looks a lot better.
btw. the different PLL bandwidth is due to
Maybe the lower bandwidth is necessary for observations that aren’t doppler-corrected?
Could be, I don’t know. I read a little bit about the subject: A higher bandwidth leads to a faster lock, but also a faster loss of lock. In some applications the bandwidth is high to begin with and is lowered upon locking. Just dividing the bandwidth by a magic number for a slightly different modulation mode seems a bit silly to me.
Anyway, the current parameters seem to work fine judging by the image I just received:
I now have a problem where an observation is messed up if it starts while the post-observation script of a previous observation is still running. @benelsen, I see you used nice and ionice, was that in an attempt to remedy this issue? And did that fix it for you?
I try not to schedule Meteor passes too low to so to reduce the possibility, but judging from the observations that are within 20 minutes it seems to help.
I also only dump the I/Q for Meteor (onto an external SSD) which helps with the following observation running into disk IO bottlenecks. CPU isn’t the biggest problem with only 1 core at 100% during the demod+decode.
I also only dump meteor iq-files, on a thumb drive in my case (which will probably break at some point). It is true that the demod/decode takes only 1 core, but the gnu radio scripts can use more than one core and may need all four of them, so may still be bothered if one core is already fully occupied. Ah well, it’s no problem if you leave some breathing room between observations.