LRPT "NOSYNC" in terminal even if images are decoded; decoding slower than before

[shuyuan-liu]

Basically, SatDump always says NOSYNC in the terminal when decoding an LRPT baseband file, even though the constellation diagram looks very clean and images are in fact produced at the end.

Below is an example of this behaviour. Even with BER below 1%, the program still says NOSYNC.

[04/12/21 - 01:07:39] (I) Starting processing pipeline meteor_m2_lrpt...
[04/12/21 - 01:07:39] (D) Input file (baseband) : /mnt/Data/Recordings/IQ/lrpt-trimmed.wav
[04/12/21 - 01:07:39] (D) Output file (products) : /mnt/Data/Pictures/Satellite
[04/12/21 - 01:07:39] (D) Starting meteor_m2_lrpt
[04/12/21 - 01:07:39] (W) Data is already at level baseband, skipping
[04/12/21 - 01:07:39] (W) Processing data to level soft
[04/12/21 - 01:07:39] (D) Parameters :
[04/12/21 - 01:07:39] (D)    - agc_rate : 0.00001
[04/12/21 - 01:07:39] (D)    - baseband_format : i16
[04/12/21 - 01:07:39] (D)    - buffer_size : 8192
[04/12/21 - 01:07:39] (D)    - costas_bw : 0.004
[04/12/21 - 01:07:39] (D)    - dc_block : 0
[04/12/21 - 01:07:39] (D)    - iq_swap : 0
[04/12/21 - 01:07:39] (D)    - rrc_alpha : 0.6
[04/12/21 - 01:07:39] (D)    - rrc_taps : 361
[04/12/21 - 01:07:39] (D)    - samplerate : 256000
[04/12/21 - 01:07:39] (D)    - symbolrate : 72000
[04/12/21 - 01:07:39] (I) Using input baseband /mnt/Data/Recordings/IQ/lrpt-trimmed.wav
[04/12/21 - 01:07:39] (I) Demodulating to /mnt/Data/Pictures/Satellite/meteor_m2_lrpt.soft
[04/12/21 - 01:07:39] (I) Buffer size : 8192
[04/12/21 - 01:07:40] (I) Progress 0.000000%
[04/12/21 - 01:07:50] (I) Progress 21.600000%
[04/12/21 - 01:08:00] (I) Progress 45.200001%
[04/12/21 - 01:08:10] (I) Progress 59.099998%
[04/12/21 - 01:08:20] (I) Progress 71.699997%
[04/12/21 - 01:08:30] (I) Progress 83.900002%
[04/12/21 - 01:08:40] (I) Progress 95.099998%
[04/12/21 - 01:08:44] (I) Demodulation finished
[04/12/21 - 01:08:44] (W) Processing data to level cadu
[04/12/21 - 01:08:44] (D) Parameters :
[04/12/21 - 01:08:44] (D)    - baseband_format : i16
[04/12/21 - 01:08:44] (D)    - dc_block : 0
[04/12/21 - 01:08:44] (D)    - diff_decode : 0
[04/12/21 - 01:08:44] (D)    - iq_swap : 0
[04/12/21 - 01:08:44] (D)    - samplerate : 256000
[04/12/21 - 01:08:44] (I) Using input symbols /mnt/Data/Pictures/Satellite/meteor_m2_lrpt.soft
[04/12/21 - 01:08:44] (I) Decoding to /mnt/Data/Pictures/Satellite/meteor_m2_lrpt.cadu
[04/12/21 - 01:08:50] (I) Progress 1.200000%, Viterbi BER : 26.733398%, Lock : NOSYNC
[04/12/21 - 01:09:00] (I) Progress 3.800000%, Viterbi BER : 26.904297%, Lock : NOSYNC
[04/12/21 - 01:09:10] (I) Progress 7.400000%, Viterbi BER : 28.088379%, Lock : NOSYNC
[04/12/21 - 01:09:20] (I) Progress 10.200000%, Viterbi BER : 6.542969%, Lock : NOSYNC
[04/12/21 - 01:09:30] (I) Progress 14.000000%, Viterbi BER : 3.198242%, Lock : NOSYNC
[04/12/21 - 01:09:40] (I) Progress 18.700001%, Viterbi BER : 0.646973%, Lock : NOSYNC
[04/12/21 - 01:09:50] (I) Progress 23.400000%, Viterbi BER : 0.170898%, Lock : NOSYNC
[04/12/21 - 01:10:00] (I) Progress 28.100000%, Viterbi BER : 0.219727%, Lock : NOSYNC
[04/12/21 - 01:10:10] (I) Progress 32.599998%, Viterbi BER : 0.195312%, Lock : NOSYNC
[04/12/21 - 01:10:20] (I) Progress 37.000000%, Viterbi BER : 0.207520%, Lock : NOSYNC
...

It seems this problem is quite new but I'll need to find the exact commit after which it appeared. Related to this, it seems LRPT decoding is a lot slower now than before. Before the problem appeared, as soon as the decoder recognises the signal and BER drops the progress becomes a lot faster, and once the signal is lost it slows down again; now it's slow all the way through.

I can provide the baseband files I used, although I believe this behaviour is not specific to any particular recording.

[shuyuan-liu]

I tried building previous versions and it seems commit 9401767 "Fixup LRPT a bit" started the issue. This commit removes a piece of code that makes decoding "go faster" if locked, but I don't quite understand why - @Aang23 do you mind giving a brief explanation?

I tried decoding the same recording with SatDump before and after commit 9401767, and below are the results. For this particular recording at least, less data is decoded at the start and end where the signal is bad. The amount of errors caused by signal level fluctuations in the middle of the pass stays about the same.

[Aang23]

There was an issue with the correlator, that is now fixed since a recent commit. About the NOSYNC, that's indeed a bug I need to fix. Thanks though!

The NOSYNC issue appeared after I reworked the decoder a while ago...