MetoerM2-2 OQPSK

[jeffreypkelly]

Use Medet everyday!
Will you be creating a version with OQPSK to decode the new Meteor 2-2 Satellite?

[SA7BNT]

That should be very nice. We will hope.

[neoklis]

I also very much hope so. I have incorporated medet into an integrated and complete LRPT receiver/demodulator/decoder/rectifier application (mlrpt/glrpt) and I would like to make them capable of receiving M2-2.

Thanks!

[pr0xibus]

I would also be interested in a OQPSK demodulator, M2-2 Is broadcasting Images all the time, Windows is relatively easy to capture, but Linux is just becoming a pain

[dvdesolve]

Vote for this too! It will be nice to have such feature!

[artlav]

I'm afraid the answer is maybe. It's been a while since i was set up to receive LRPT signals, and i can't really get a sample of the new one myself.

So if someone could send me a capture (or point at somewhere they are available publicly), i'll try to add support for it.

[jeffreypkelly]

Will do. Currently sending 80k OQPSK on 137.900 I’ll capture a good pass and send you a download link. Jeff K2SDR

…

Sent from my iPad

On Aug 23, 2019, at 6:53 PM, artlav ***@***.***> wrote: I'm afraid the answer is maybe. It's been a while since i was set up to receive LRPT signals, and i can't really get a sample of the new one myself. So if someone could send me a capture (or point at somewhere they are available publicly), i'll try to add support for it. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[jeffreypkelly]

Artlav, Here is a link to a file from Scott, K4KDR... He's welcome to the following .s file from a daylight pass yesterday if it's helpful: https://www.qsl.net/k/k4kdr//upload/2019_08_22_LRPT_15-35-08.s <https://www.qsl.net/k/k4kdr//upload/2019_08_22_LRPT_15-35-08.s> The resulting image wasn't bad: https://www.dropbox.com/s/v7ns5b2y3xg8blf/2019_08_22_LRPT_15-35-08.s_123.vegetation.jpg?raw=1 <https://www.dropbox.com/s/v7ns5b2y3xg8blf/2019_08_22_LRPT_15-35-08.s_123.vegetation.jpg?raw=1> Jeff K2SDR

…

On Aug 23, 2019, at 6:53 PM, artlav ***@***.***> wrote: I'm afraid the answer is maybe. It's been a while since i was set up to receive LRPT signals, and i can't really get a sample of the new one myself. So if someone could send me a capture (or point at somewhere they are available publicly), i'll try to add support for it. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#7?email_source=notifications&email_token=AIGIVP4FQHJHVVD36NWNC3TQGBS6NA5CNFSM4IFFBCB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5BQKIA#issuecomment-524485920>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIGIVP7XFM6OXWKJXI5S723QGBS6NANCNFSM4IFFBCBQ>.

[artlav]

Thanks!

Hm, after spending a few hours looking at it and googling stiff, the prognosis is not good.

No matter what i do, i can't detect the sync pattern in the signal, so either i'm missing something obvious or they added or changed some step in the encoding process.

And there is no documentation to be found...

[jeffreypkelly]

It has changed from QPSK to OQPSK. Don’t know if that helps.

…

Sent from my iPad

On Aug 23, 2019, at 10:49 PM, artlav ***@***.***> wrote: Thanks! Hm, after spending a few hours looking at it and googling stiff, the prognosis is not good. No matter what i do, i can't detect the sync pattern in the signal, so either i'm missing something obvious or they added or changed some step in the encoding process. And there is no documentation to be found... — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[jeffreypkelly]

https://community.libre.space/t/oqpsk-for-meteor-mn2-2-lrpt/4383 Jeff

…

Sent from my iPad

On Aug 23, 2019, at 10:49 PM, artlav ***@***.***> wrote: Thanks! Hm, after spending a few hours looking at it and googling stiff, the prognosis is not good. No matter what i do, i can't detect the sync pattern in the signal, so either i'm missing something obvious or they added or changed some step in the encoding process. And there is no documentation to be found... — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[artlav]

Probably not, since that is a job for the demodulator, not the decoder.

[neoklis]

Probably not, since that is a job for the demodulator, not the decoder.

Hi artlav and all, Yes, I can confirm that receiving Meteor M2-2 is a matter of getting the demodulator to extract the right soft symbols from the I/Q stream produced by the SDR receiver. I have incorporated a modified demodulator code produced recently by Davide Belloli https://github.com/dbdexter-dev/ into glrpt and I was able, after a lot of work, to decode images from M2-2 but only from a raw recording of I/Q data saved when M2-2 was transmitting at 72k sym rate. This was with the same medet decoder as incorporated into glrpt originally so no need to do anything to medet. I tried yesterday to decode images from M2-2 but failed because Davide's demodulator appears to work only with 72k sym rate. This is mentioned in his documentation of the package. After much detective work, I believe the problem with the demodulator is in the Gardner symbol timing algorithm, being rather sensitive to one or two parameters. I am planning today to make another raw I/Q recording so that I might try to find out what it might take to make the demodulator work with 80k sym rate. Important and good work by Davide, he found that in fact M2-2 is using Differential OQPSK modulation and so he produced a rather simple code that seems to make the output of the demodulator usable by the decoder. This code is in the diff.c file in the development branch of meteor_decode and it works in glrpt. His Costas PLL seems to work well and I get a good QPSK constellation and good lock, even though this is with the sym rate parameter at 80k. Davide told me that the double-rate OQPSK modulation is taken into account in his demodulator code somewhere. Well, my task now seems to be to fix the final issues with the demodulator but my problem is - when I was a student it was thermionic valves and silicon transistors ;-) IC's were a remote curiosity, no PC's and not even a hint of SDR and digital comms. So it looks like I should try to implement the ancient Greek wisdom - "I grow old forever learning"! P.S. I can supply any working copies of glrpt code and other stuff as needed.

…

-- Best Regards Neoklis - Ham Radio Call: 5B4AZ http://www.5b4az.org/ https://www.qsl.net/5b4az/index.html

[dvdesolve]

Neoklis, why not to upload glrpt on GitHub? It would be very useful!

[artlav]

Ok, having slept on it i think i figured out what is missing.

The question to ask is why 80k instead of 72k? And the answer is the difference between the two is that 80k one got a convolutional interleaver step in it. Described in LRPT spec, section 3.2.2.7

So now it's a matter of legwork... Should be fairly straightforward to support.

[jeffreypkelly]

Great news. During the testing we have seen both 72 and 80 so not sure where it will land! Currently on 80. Jeff

…

Sent from my iPhone

On Aug 24, 2019, at 8:57 AM, artlav ***@***.***> wrote: Ok, having slept on it i think i figured out what is missing. The question to ask is why 80k instead of 72k? And the answer is the difference between the two is that 80k one got a convolutional interleaver step in it. Described in LRPT spec, section 3.2.2.7 So now it's a matter of legwork... Should be fairly straightforward to support. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.