Meteor MN2 decoder for rpi 3B+

A few things I have noticed with the new medet_arm:

  • It appears to require write permissions on the soft-bit files. I’m not sure if this has always been the case, but it was the result of some interesting errors during some debugging.
  • To decode Meteor M2-2, medet_arm needs the -diff option added to the command line. This is a bit of a problem, as it means the script needs to know what satellite is being observed. Unfortunately, this is not something that can be passed through (according to what I’m seeing in satnogs-client here: ). There is an option to pass through the entirety of the TLE, from which we can extract the satellite number, but it’s going to be a bit of a pain.

So for now, the meteor decoder script is not going to work correctly with the new Meteor sat. I’m not sure when/if I’ll have the time to modify the scripts to deal with this.

Hi all,
I have started a (very quick and exceedingly dirty) implementation of the mode switch needed to operate with both M2 and M2-2.
Three changes:

It seems that this procedure did call in the correct manner although it looks like the SNR was not high enough for my modest station (I am unable to decode the *.s files for M2-2 manually so there may be an issue for me down the chain somewhere).

@vk5qi do we need to use the “-int” option as well?

 -int       Deinterleave (for 80k signal, i.e. Meteor M2-2, default - 72k)
 -diff      Diff coding (for Meteor M2-2)

If someone would like to test this please see the links above, otherwise I’ll wait for a better pass and see how it goes! Please let me know if it does work and if it does I’ll document and make it all look nice! :slight_smile:

If anyone sees an issue please let me know!



I don’t know if they have settled on 72k or 80k for Meteor M2-2. That will determine what options are needed.

Once you’ve tested it, could you submit a pull request please?

Yep - once I am happy it works, I’ll submit a pull request.



Hmmm so it seems that the script modifications I made are working but it looks as if the *.s files that I am getting for M2-2 are garbage whereas the *.s files for M2 are working fine.

Do we also need to make a change to the GRC flowgraph for the *.s files to be demodulated correctly (as it looks as if M2-2 and M2 run at different symbol rates?).


(Sorry for the spam)…
We also need to ensure that the GRC file is decoding the data stream as OQPSK rather than QPSK… Looks like we may also need to modify the call to the GRC flowgraph for the different satellites.

It is noted that this station here seems to be getting amazing results for both M2 and M2-2:

I have started a separate thread here asking about his station:

My understanding is that the settings for the METEOR satellites is currently as below(please correct me if I am wrong, I can’t find any reliable citations on how these spacecraft are being operated. If someone knows a good source please let me know!):
72kbps QPSK @ 137.100
80kbps OQPSK @ 137.900

A good source for the settings of Meteor is and
I try to keep a list of the changes at and if I missed one please let me know or create a PR.

My setup is barely working r/n, there is some weird interference present from time to time, but the processing works (most of the time).

What I do is very hack-y and while I’m willing to give as much detail as people want, I’m not advocating for people to setup a station like this :rofl:

First off I modified the satnogs-client to let me pass the observation and satellite id via the post observation script. With hindsight your approach with passing the TLE and just getting the id from there is a lot better.

I then modified the file generated with the GRC to dump the I/Q data no matter what the global setting in satnogs is. I also modifed the paths the .s and .dat files are written to.
I write them to /data/satnogs/tmp/which is on a USB mounted ssd so that the SD card doesn’t die after a few weeks.

My post observation scipt then calls my rewritten (with nice and ionice as not to affect other observations too much). looks for the iq.dat and .s and processed them based on the satellite id.

  • Meteor-M N2 (40069):
    decodes that data directly from the .s with meteor_decode (or medet; I used meteor_decode as it created png’s directly)

  • Meteor-M N2-2 (44387):
    demodulates the iq.dat anew with meteor_demod (which does OQPSK), then decodes the data with medet and converts them to pngs. (the parameters for the demodulator still need some tweaking to get a reliable lock)

Again, do not use these files directly, they were hacked together and won’t work as is on any other setup, but I hope someone can take them and create a setup that works more generally!

Thanks for your reply!

My setup is barely working r/n, there is some weird interference present from time to time, but the processing works (most of the time).

If it works it works!!! :stuck_out_tongue:

Lots to think about, thanks!

Do we know if Meteor M2-2 has settled on a particular configuration yet? Or is it likely to change modes again?

A manual process more or less worked for me with Meteor M2-2
git pull update meteor_demod and meteor_decode

$ rtl_fm -M raw -f 137.9M -s 288k -g 28 -p 1 m2_iq.raw
$ sox -t raw -r 288k -c 2 -b 16 -e s m2_iq.raw -t wav meteor_a.wav rate 144k
$ sox meteor_a.wav meteor.wav gain -n

visit above link for 72 or 80k symbols, currently 72000. -f -b can be tweaked for best results

$ ~/src/meteor_demod/src/meteor_demod -f 64 -b 100 -s 144000 -r 72000 -m oqpsk -o meteor.oqpsk meteor.wav
$ ~/src/meteor/meteor_decoder/medet  meteor.oqpsk meteor -cd  -diff
Reading meteor.oqpsk...
 pos=94431039 ( 99.98%) ( 4,13962,49) sig= -219 rs=(-1,-1,-1,-1) EF89C21A 
Total:        92.889374
Processing:   2.498837
Correlation:  33.918762
Viterbi:      50.282986
ECC:          4.905700
Remainder:    1.283093
Packets:      2051 / 4611
Elapsed time: 00:04:59.168
$ ~/src/meteor/meteor_decoder/medet meteor.dec meteor_122 -r 65 -g 65 -b 64 -d

enjoy (after convert -rotate 180)

1 Like

There was a suggestion in DB for changing 44387 - Meteor-M 2-2 LRPT transitter from 80kbps to 72kbps SymbolRate according to this source.

I’ve accepted the change, let me know if that doesn’t make sense or if more changes should be performed for either 44387 - Meteor-M 2-2 or 40069 - METEOR-M 2.

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 :slight_smile:


Ideally if this goes to in a page would be more visible and linkable :slight_smile:


Agreed. If I manage to gather enough information and get it working, I will be happy to update wiki.


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?


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. :wink:


This is great. I would be happy to test this and help with wiki as well! Count me in :slight_smile:

1 Like