Observation 2412799: METEOR-M 2 (40069)

Regarding Observation 2412799

Anyone got any idea what’s happening here? I’ve had this before and rebooting the PI normally fixes it but no such luck this time.

Are you getting any obvious errors during the observation, like overruns? Or does it all just appear to run normally?

Frustratingly, immediately after rebooting again I realised I should have kept the logs. Nothing was obvious when I had a scan through. It was also happening on every observation, regardless of bandwidth. Rebooting did fix it though. One would think it could be local interference, but unless it’s in the Pi, it’s unlikely as rebooting seems to fix it most of the time.

I need to think about a status and log aggregator for all my devices.

It’s doing it again now but with lines in the other direction… Observation 2428660 but that could be a different issue. Presumably any overruns would appear in the log somehow?

I’d suggest as soon as you see it, don’t reboot the Pi, but try and run up an observation manually by running the flowgraph. You need to do this as the satnogs user, which you can switch to by running:
sudo su satnogs -s /bin/bash

If you haven’t done that before, run --help to see the options. The list is a little daunting, but you only need a few of them for the flowgraph to run. Example:
satnogs_lrpt_demod.py --soapy-rx-device=‘driver=rtlsdr’ --samp-rate-rx=2.048e6 --antenna=RX --rx-freq=137.1e6

This should at least clearly show any errors that might be missed in the logs.

Ah, I was wanting to run an observation manually when I was trying to get things going before. Never twigged just running the flowgraph would do it at the time - of course it will provided you specify the basics.

I seem to have be having other problems now, recent observations https://network.satnogs.org/observations/2434434/ with lots of dropouts/interference. But either way, next time it occurs I’ll dig a little deeper.

That looks suspiciously like the doppler correction issues that have been encountered by others. It appears to be in part due to a previous observation (not the flowgraph, but the task within satnogs-client which controls the centre freq) not closing correctly, so the currently running observation and the ‘new’ observation ‘fight’ over the centre frequency.