meteor_decoder
meteor_decoder copied to clipboard
artlav
MetoerM2-2 OQPSK
Use Medet everyday! Will you be creating a version with OQPSK to decode the new Meteor 2-2 Satellite?
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!
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
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.
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 [email protected] 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.
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 [email protected] 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 https://github.com/artlav/meteor_decoder/issues/7?email_source=notifications&email_token=AIGIVP4FQHJHVVD36NWNC3TQGBS6NA5CNFSM4IFFBCB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5BQKIA#issuecomment-524485920, or mute the thread https://github.com/notifications/unsubscribe-auth/AIGIVP7XFM6OXWKJXI5S723QGBS6NANCNFSM4IFFBCBQ.
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...
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 [email protected] 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.
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 [email protected] 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.
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
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.
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 [email protected] 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.
@neoklis,
I tried yesterday to decode images from M2-2 but failed because Davide's demodulator appears to work only with 72k sym rate.
master branch of dbdexter-dev/meteor_demod have support fo 80K. https://github.com/dbdexter-dev/meteor_decode/issues/1#issuecomment-524560381 — source with 80K OQPSK (nice example for experiments).
with "-r 80000 -m oqpsk -b 130 -f 128 -O 8" options meteor_demod produce .s file (test_oqpsk_80k.s.zip), which can't be decoded now with meteor_decode, but M2_LRPT_Decoder (v.48 - v.53) can do this:
Anyone got a 72k .s file from the new sat?
Best i can tell i implemented the deinterleaving correctly, but i'm still getting noise out. So I'm starting to suspect that there is more to it than just interleaving - people are talking about differential coding, for example. I would have liked to eliminate variables.
Neat. As i suspected, it's differentially coded.
Apparently i didn't implement the deinterleaving properly...
On the plus side, everything else works fine and it decoded properly.
Getting excited! :-)
Jeff
Sent from my iPad
On Aug 24, 2019, at 11:43 PM, artlav [email protected] wrote:
Neat. As i suspected, it's differentially coded.
Apparently i didn't implement the deinterleaving properly...
On the plus side, everything else works fine and it decoded properly.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
And it's done. Releases are built, same link as always.
To decode in 72k mode, add -diff To decode in 80k mode, add -diff -int
It seems to be a bit worse than M2_LRPT_Decoder, with extra lines present. Not sure how prevalent that would be and what the difference is.
Thanks very much Artyom!
I will try to incorporate the changes into glrpt and mlrpt, hopefully make it compatible with M2-2. I made a mistake though, did not think of saving the Pascal code for the original version, so I can't do a diff to find the changes. If you could, I would much appreciate a copy of the original code - Thanks!
Neoklis
@neoklis
I can't do a diff to find the changes.
https://github.com/artlav/meteor_decoder/commits/master — click on last four commits and you get what you want ;)
Hi Artyom
I have been working to translate the changes in meteor_decode from Pascal to C so that I may incorporate them in mlrpt and glrpt. I don't use Pascal and what little I learned is only for the translation. But I suspect the following lines may cause an off-by-one error in accessing isqrt_tab[]:
In function mean(): if (v>32768)or(v<-32768) then exit; if v>=0 then result:=isqrt_tab[v] else result:=-isqrt_tab[-v];
In procedure de_diffcode(): for i:=0 to 32768 do isqrt_tab[i]:=round(sqrt(i));
These are surely wrong in C. But then I know so little of Pascal.... ;-)
Neoklis
Off by one as in overrunning the array?
The languages should be identical as far as indexing an array goes. Pascal syntax is array[0..2] is an array of three elements indexed 0, 1 and 2. For loop is from a to b, inclusive.
So, the array got 32769 elements, indexed from 0 to 32768, the loop covers indexes from 0 to 32768 inclusive, and the mean got a (probably redundant) check what the modulus of the product does not exceed 32768.
I don't see a problem. If i missed something, please elaborate.
OK Artyom,
As I said, I don't have any experience with Pascal, I learned just enough to translate to C. So it looks like your code is right and I will have to adjust my C translation. Thanks for explaining.
-- Best Regards
Neoklis - Ham Radio Call: 5B4AZ http://www.5b4az.org/ https://www.qsl.net/5b4az/index.html
Thank you again for building a great program. Would it be possible to build a MAC binary as in the past?
TY!
Jeff K2SDR
On Aug 25, 2019, at 3:02 PM, artlav [email protected] wrote:
And it's done. Releases are built, same link as always.
To decode in 72k mode, add -diff To decode in 80k mode, add -diff -int
It seems to be a bit worse than M2_LRPT_Decoder, with extra lines present. Not sure how prevalent that would be and what the difference is.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/artlav/meteor_decoder/issues/7?email_source=notifications&email_token=AIGIVP336VFACXAXS5XL7VLQGLJKZA5CNFSM4IFFBCB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5CZVYY#issuecomment-524655331, or mute the thread https://github.com/notifications/unsubscribe-auth/AIGIVP6JJJ63QKNV5JB3GELQGLJKZANCNFSM4IFFBCBQ.