LRPT Locking issues (RS, Demod?) (M2 LRPT) about satdump HOT 20 CLOSED

Well, it's only one attempt but on tonight's M2 pass (w/ 'DC Block' enabled), SatDump achieved RS-Lock without having to be restarted. I will continue to use the 'DC-Block' option to see if that continues to give me a lock when SNR is good.

from satdump.

i'm using it on win10 with rtl_tcp source and not able to get reed-solomon green even with this workaround. Sometimes is flash green for less than second, screen and qpsk constellation looks same as above. Offline recorded file is processed without troubles, even with worse signal.

from satdump.

@K4KDR, do you think you could record a baseband once and share it? (Using the same settings / etc). I will then try to reproduce the issue on my side.

There was a bug like that back before I released anything, but it is supposed to be fixed...

@marianzb this appears to be a RTL-TCP issue. Mind opening another issue about this?

from satdump.

I assume you mean a recording when it is NOT locked?

Yes, will do! Just to be clear, is it the .CADU file you are looking for?

Thanks!

from satdump.

No, I meant a baseband (maybe preferably using SatDump's recorder in f32 mode, as it uses the same DSP chain). That way I can feed it back into the demod / decode and see where something fails / etc.
(f32 as it is guaranteed not to be slightly modified by re-encoding to 16 or 8 bits... Bigger but safer to avoid missing something I'd say)

from satdump.

Very good - will do on the next pass!

from satdump.

I spoke too soon - I can record a 32-bit .raw I/Q with GQRX, but I have no idea how to "us(e) SatDump's recorder in f32 mode".

Any guidance appreciated!

from satdump.

Oh right, I did not release the recorder in 0.0.37... So either use the current source on Git or GQRX, should do too since I doubt the issue lies in the SDR part.

from satdump.

No problem - and there is also a catch... if I am not "Live Processing", I would not know if the capture was 'good' or was failing to lock.

Well, please let me know if I can do anything to provide something useful. It could certainly be an issue here if no one else has seen this.

from satdump.

Without looking at the code I bet the incoming data bytes get desyncronized and that causes the Q value from one sample to be read with the I value of the next sample. This won't have much effect on the constellation but will mess up the symbols

from satdump.

Without looking at the code I bet the incoming data bytes get desyncronized and that causes the Q value from one sample to be read with the I value of the next sample. This won't have much effect on the constellation but will mess up the symbols

Thing is, you're entirely right... But that is something the decoder should be handling if it is the case. In this instance I'm pretty confident it's something a bit more finicky as viterbi wouldn't lock if it was purely symbol inversion, yet the BER looks good.

No problem - and there is also a catch... if I am not "Live Processing", I would not know if the capture was 'good' or was failing to lock.

Definitely, might not work directly but I don't really see how else to do it. I have tried with a few captures on my end and couldn't reproduce it. Maybe need to try with the R2 directly though, most of those samples were from RTL-SDRs or some of my newer recordings on an Airspy HF+ Discovery.

from satdump.

Wait, @K4KDR, could you also see if enabling DC Blocking helps? Some R2 units (mostly older ones it seems) sometimes had some I/Q offset that could effectively cause this kind of issues. If it's the case it wouldn't be too hard to fix at least.

from satdump.

Very good. Would an I/Q recording from the Airspy-R2 be of any use? Or, is there any particular setup / config in SatDump that I could do to provide you more info? FYI, I always use the 2.5M sample rate - should I try the 10M option for any reason?

from satdump.

Very glad to enable the 'DC Block' option. I normally do not since the Airspy doesn't have that issue. I'll have that checked on future passes just to see if this issue does or does not continue. Thanks!

from satdump.

Very good. Would an I/Q recording from the Airspy-R2 be of any use? Or, is there any particular setup / config in SatDump that I could do to provide you more info? FYI, I always use the 2.5M sample rate - should I try the 10M option for any reason?

Yes, with a recording it's always easier to take a look on my side. Setup / Config-wise, there honestly is nothing to go that wrong unless you played with Volk's. May just be worth running volk_profile to be sure if you want, but I highly doubt that. I don't think trying 10M is worth it though, it will still get resampled the same so it effectively changed nothing on SatDump's side.... And well, if it breaks at 2.5M and isn't purely an issue on your side, it's still a bug anyway!

Very glad to enable the 'DC Block' option. I normally do not since the Airspy doesn't have that issue. I'll have that checked on future passes just to see if this issue does or does not continue. Thanks!

Thanks. Indeed, usually Airspys are very good in that regard but well, I've seen it happen (granted, rarely), so as it could cause this exact behavior, it's a good idea to rule it out as soon as possible. An I/Q imbalance effectively causes a DC spike, which can interfere with the demodulator causing it to output garbage RS won't lock onto... But as it usually contains a lot of "11111" or "00000"s, Viterbi can still show a low BER. It's not usually an issue though, but for example happens when ELEKTRO-L 3's xRIT switches over to a carrier before / after transmissions.

from satdump.

Same issue yesterday:
#50
Merge?

from satdump.

Well, it's only one attempt but on tonight's M2 pass (w/ 'DC Block' enabled), SatDump achieved RS-Lock without having to be restarted. I will continue to use the 'DC-Block' option to see if that continues to give me a lock when SNR is good.

Thanks, if it doesn't happen again that way, may have been the issue.

Same issue yesterday: #50 Merge?

It's not exactly the same issue, but similar enough to merge both into this one I think, both are essentially about the same issue. If it does it again @benb0jangles, could you record a baseband?

On another note, I have just rewritten the entire DSP used in SatDump. (see 699076e)
It is very possible the issue was fixed along the way, so if you don't mind I would encourage using the current master from now on.

from satdump.

[v0.0.38 / master branch / build: 01a8276, built from source]

Running 'Live Processing' with Airspy-R2 @ 2.5M Sample Rate:

On the first live Meteor-M2 LRPT pass with this build, the Reed-Solomon indicator locked green without having to stop & re-start the GUI. However, since this was an intermittent issue, I will continue to monitor the situation & verify that it locks each time without the need for a stop & re-start. Thanks very much for the updates!

from satdump.

it looks my problem with RS locking was caused by some jitter on rtl-tcp server. Recently I have reinstalled Raspberry Pi there and now live decoding works perfectly all indicators green. :-) Also updated latest version, thanks for updating this project!

from satdump.

RTL-TCP has this kind of issue pretty often... So not too surprised it was that.

I guess this can be closed now!

from satdump.