Zebra Waterfall


Regarding Observation 2459970
Does it look like more like a bug or an USB connection problem with my RTL-SDR, or a coax problem ?


Another exemple : https://network.satnogs.org/observations/2459971/

There is ongoing discussion of this in another thread. Apparently it’s a bug that affects the tuner, and basically it switches back and forth between the current frequency and the frequency used in the last observation. I believe it’s being worked on (or at least researched).

Is this the same issue? Take Observation 2434434 mentioned in Observation 2412799: METEOR-M 2 (40069). There’s a distinct shift at about 700 seconds where the central line shifts left substantially. You can also see a fair bit of regular back and forth around the 200 second mark. Whereas with these observations they exhibit the zebra lines but the signal stays central. Are the ‘zebra lines’ part of the same issue, an artefact of it, or an independent problem?

I also have some observations that seem to have the frequency shift problem on my station.

Not sure. I suggested that at first glance, but you may be correct.

In the interim, if this behavior is caused by the same issue as the others with this symptom, doing a full power-off shutdown and coming up fresh seems to clear things up.

Still not sure if it’s the same issue, but I think I can cause this ‘on demand’ by trying to be too clever.

In trying to run radiosonde_auto_rx when my station wasn’t doing anything else, I had a pre-observation script:

sudo systemctl stop auto_rx.service
/home/pi/rtl_biast/build/src/rtl_biast -b 1

Sometimes I got a usb_claim_interface error -6 from rtl_biast when it hadn’t quite managed to shut down auto_rx in time. That generally killed the observaton as it either didn’t work at all, or at least got no signal with the LNA not being powered. Other times it appears to work, but seems to initiate the ‘zebra’ effect in the waterfall image (see observation 2501914).

It could be a fluke of timing but my guess is not. I couldn’t prove either way as it needed both auto-rx stopped and satnogs-client restarted to clear latent issues.

Another process keeping the ‘handle’ is not the same as the same process doing so, but thought it worth documenting this as another data point possibly useful for digging deeper. I’ve seen the same symptoms when not running the above on this station too.