Is "Failed" the new "Bad"?

oz1sej1 · March 19, 2021, 8:34am

I added a new station (2095) the other day. Since then, I’ve made a few observations, some with signal, some without. But it seems that “the algorithm” automatically vets all my observations as “Failed” - even the ones with signal in. The two successful observations are now listed as “Good”, because I changed them manually.

So I basically only have two outcomes: Failed or Good. Is this a problem? Should I just be happy for the good ones, and if there was no signal, then it’s a failed pass? Or is there a problem with my station? If so, how do I find out?

fredy · March 19, 2021, 12:34pm

Currently there are two ways an observation to be marked as failed:

Observation has none of the artifacts(audio, waterfall, data) uploaded.
Observation has audio artifact with duration at least 1min different from the scheduled duration.

The second case is still under investigation as it happens in several stations, but seems to be affected by different factors (sdr, scripts running before/after the observation, cpu usage etc).

Marking the waterfall with “has signal” changes the observation status. As vetting is in transition, I wouldn’t care too much, if you can keep vetting the waterfalls of your observations then it’s ok, if not then again it’s ok.

Edit: Check also this thread What am I supposed to do with all the unvetted observations?. Unfortunately some other tasks have been prioritized, so discussion on vetting has been stalled, but hopefully it will start again soon, so we can move forward.

oz1sej1 · March 19, 2021, 1:04pm

Thanks! Hm, in this failed observation, for example, the waterfall has a duration of more than 900 seconds, but the audio is only 320 seconds. Do you have any tips on how to find the cause of this? Logs, etc.?

satcolintel5 · March 19, 2021, 3:46pm

You may want to run some manual tests with your SDR using rtl_test or similar. It could be your SDR device is intermittently connecting to the computer’s BUS. Hence the 900 second record time but only a 300 second recorded audio time.

For logs,
RPi running the satnogs-client image

tail -f /var/log/syslog
or
grep satnogs-client /var/log/syslog

Ansible docker (footloose) on Debian 10 (buster) is a bit different
journalctl -u satnogs-client.service -f

oz1sej1 · March 19, 2021, 4:36pm

Okay, there are some - hm - interesting - things in /var/log/syslog (apologies for the long paste):

Mar 19 13:30:33 satnogs-s satnogs-client[17714]: OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
OOOOOOOOOOOOOOOOOOOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsO
sOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOs
OsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
Mar 19 13:30:33 satnogs-s satnogs-client[17714]: Traceback (most recent call last):
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:   File "/var/lib/satnogs/lib/python3.7/site-packages/urllib3/connectionpool.py", line 426, in _make_request
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:     six.raise_from(e, None)
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:   File "<string>", line 3, in raise_from
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:   File "/var/lib/satnogs/lib/python3.7/site-packages/urllib3/connectionpool.py", line 421, in _make_request
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:     httplib_response = conn.getresponse()
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:   File "/usr/lib/python3.7/http/client.py", line 1336, in getresponse
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:     response.begin()
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:   File "/usr/lib/python3.7/http/client.py", line 306, in begin
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:     version, status, reason = self._read_status()
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:   File "/usr/lib/python3.7/http/client.py", line 267, in _read_status
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:     line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:   File "/usr/lib/python3.7/socket.py", line 589, in readinto
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:     return self._sock.recv_into(b)
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:   File "/usr/lib/python3.7/ssl.py", line 1052, in recv_into
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:     return self.read(nbytes, buffer)
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:   File "/usr/lib/python3.7/ssl.py", line 911, in read
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:     return self._sslobj.read(len, buffer)
Mar 19 13:30:33 satnogs-s satnogs-client[17714]: socket.timeout: The read operation timed out
Mar 19 13:30:33 satnogs-s satnogs-client[17714]: During handling of the above exception, another exception occurred:
Mar 19 13:30:33 satnogs-s satnogs-client[17714]: Traceback (most recent call last):
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:   File "/var/lib/satnogs/lib/python3.7/site-packages/requests/adapters.py", line 449, in send
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:     timeout=timeout
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:   File "/var/lib/satnogs/lib/python3.7/site-packages/urllib3/connectionpool.py", line 727, in urlopen
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:     method, url, error=e, _pool=self, _stacktrace=sys.exc_info()[2]
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:   File "/var/lib/satnogs/lib/python3.7/site-packages/urllib3/util/retry.py", line 410, in increment
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:     raise six.reraise(type(error), error, _stacktrace)
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:   File "/var/lib/satnogs/lib/python3.7/site-packages/urllib3/packages/six.py", line 735, in reraise
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:     raise value
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:   File "/var/lib/satnogs/lib/python3.7/site-packages/urllib3/connectionpool.py", line 677, in urlopen
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:     chunked=chunked,
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:   File "/var/lib/satnogs/lib/python3.7/site-packages/urllib3/connectionpool.py", line 428, in _make_request
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:     self._raise_timeout(err=e, url=url, timeout_value=read_timeout)
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:   File "/var/lib/satnogs/lib/python3.7/site-packages/urllib3/connectionpool.py", line 336, in _raise_timeout
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:     self, url, "Read timed out. (read timeout=%s)" % timeout_value
Mar 19 13:30:33 satnogs-s satnogs-client[17714]: urllib3.exceptions.ReadTimeoutError: HTTPSConnectionPool(host='network.satnogs.org', port=443): Read timed out. (read timeout=45)
Mar 19 13:30:33 satnogs-s satnogs-client[17714]: During handling of the above exception, another exception occurred:
Mar 19 13:30:33 satnogs-s satnogs-client[17714]: Traceback (most recent call last):
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:   File "/var/lib/satnogs/lib/python3.7/site-packages/apscheduler/executors/base.py", line 125, in run_job
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:     retval = job.func(*job.args, **job.kwargs)
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:   File "/var/lib/satnogs/lib/python3.7/site-packages/satnogsclient/scheduler/tasks.py", line 171, in get_jobs
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:     timeout=45)
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:   File "/var/lib/satnogs/lib/python3.7/site-packages/requests/api.py", line 76, in get
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:     return request('get', url, params=params, **kwargs)
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:   File "/var/lib/satnogs/lib/python3.7/site-packages/requests/api.py", line 61, in request
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:     return session.request(method=method, url=url, **kwargs)
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:   File "/var/lib/satnogs/lib/python3.7/site-packages/requests/sessions.py", line 530, in request
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:     resp = self.send(prep, **send_kwargs)
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:   File "/var/lib/satnogs/lib/python3.7/site-packages/requests/sessions.py", line 643, in send
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:     r = adapter.send(request, **kwargs)
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:   File "/var/lib/satnogs/lib/python3.7/site-packages/requests/adapters.py", line 529, in send
Mar 19 13:30:33 satnogs-s satnogs-client[17714]:     raise ReadTimeout(e, request=request)
Mar 19 13:30:33 satnogs-s satnogs-client[17714]: requests.exceptions.ReadTimeout: HTTPSConnectionPool(host='network.satnogs.org', port=443): Read timed out. (read timeout=45)

What is that?

satcolintel5 · March 19, 2021, 5:18pm

Looks like your DNS entries are not resolving network.satnogs.org so it can’t upload your results.

Most of the time your DNS gets auto-set by your home router, which isn’t always bad but has caused issues for me with satnogs. So I set my two DNS nameservers on my satnogs-client machines for google (8.8.8.8 and 8.8.4.4) and life returned to normal (satnogs observations uploaded when they were failing before).

hb9fxx · March 19, 2021, 5:28pm

The 0s are dropped samples, that’s why the audio ends shorter than the observation.
If the difference is bigger than 1 minute it gets automatically vetted as failed as mentioned by @fredy

You cannot re-vet it directly as good if it contains signal, but you can re-vet it as unknown and then as good.

One solution is to use a lower samplerate.

The https error i got many of them in my logs, it usually connects fine a little later when retrying.

fredy · March 19, 2021, 6:35pm

@oz1sej1 can you copy paste here your settings. To do that you can go to Advanced -> Support in sudo satnogs-setup.

oz1sej1 · March 19, 2021, 9:15pm

Thanks for the suggestions. I manually added 8.8.8.8 and 8.8.4.4 as DNS servers. Running pi-hole locally, so that might be interfering.

The 0s are dropped samples,

A-ha! So why is it dropping samples? This is a Raspberry Pi 3 model B and a HackRF One at 8 MSPS.

Settings:

------------[ copy here ]------------
{
    "versions": {
        "satnogs-client": "1.4",
        "satnogs-client-ansible": "202012231828",
        "satnogs-flowgraphs": "1.3-1",
        "gr-satnogs": "2.2.0.0-1",
        "gr-soapy": "2.1.3.1-1",
        "gnuradio": "3.8.2.0-14satnogs2",
        "satnogs-config": "0.11"
    },
    "state": {
        "is-applied": true,
        "pending-tags": null
    },
    "system": {
        "date": "2021-03-19T21:07:30.717580+00:00",
        "distribution": {
            "DESCRIPTION": "Raspbian GNU/Linux 10 (buster)",
            "RELEASE": "10",
            "CODENAME": "buster",
            "ID": "Raspbian"
        },
        "pending-updates": true,
        "platform": {
            "system": "Linux",
            "node": "satnogs-s",
            "release": "5.10.17-v7+",
            "version": "#1403 SMP Mon Feb 22 11:29:51 GMT 2021",
            "machine": "armv7l",
            "processor": ""
        },
        "memory": {
            "total": 969105408,
            "available": 659542016,
            "percent": 31.9,
            "used": 221270016,
            "free": 293761024,
            "active": 220516352,
            "inactive": 385277952,
            "buffers": 53850112,
            "cached": 400224256,
            "shared": 24637440,
            "slab": 50282496
        },
        "disk": {
            "total": 15345393664,
            "used": 3250802688,
            "free": 11416784896,
            "percent": 22.2
        }
    },
    "configuration": {
        "satnogs_antenna": "TX/RX",
        "satnogs_api_token": "[redacted]",
        "satnogs_gain_mode": "Settings Field",
        "satnogs_other_settings": "AMP=14,LNA=24,VGA=14",
        "satnogs_rx_samp_rate": "8e6",
        "satnogs_soapy_rx_device": "driver=hackrf",
        "satnogs_station_elev": "30",
        "satnogs_station_id": "2095",
        "satnogs_station_lat": "55.785",
        "satnogs_station_lon": "12.326"
    }
}
------------[ copy end ]-------------

hb9fxx · March 19, 2021, 9:16pm

I also noted you set 8MS/s on your HackRF. Previously i ran my HackRF also at 8MS/s with sometimes sample losses sometimes not. Since december i experience much more sample losses (probably the cpu load of satnogs increased). I run it now at 4MS/s without issues. (using a Pi4)

This is out-of-spec as the front-end filter is not designed for lower samplerates than 8, but aliasing is still enough attenuated in the middle of the tuning range (https://github.com/mossmann/hackrf/wiki/Tips-and-Tricks)

oz1sej1 · March 20, 2021, 10:44am

Hm. I’ll try with 4 MS/s for the next pass.

EDIT: Still failed with 4 MS/s, but now I got 500 seconds of audio. Is the Raspberry Pi 3 just too slow for this?

hb9fxx · March 20, 2021, 5:18pm

Never tried a HackRF on a Pi3. I use a Pi4 8GB, but RAM usage seems low, so the 4 or even 2GB should be enough. A Pi4 might be required.

vk5qi · March 20, 2021, 9:44pm

In short, yes. A RPi 3 isnt going to handle more than maybe 2 MHz of bandwidth.

oz1sej1 · March 21, 2021, 10:18am

Shoot. I don’t want to use my HackRF for this in the long run anyway, so I’ll need a downconverter, so I can use an RTL-SDR with my Pi 3. Any suggestions for a downconverter?

hb9fxx · March 21, 2021, 10:23am

Looked the same route some time ago, didn’t find a cheap solution. Kuhne Electronics has a nice one, but like 1000$ it seems.

oz1sej1 · March 21, 2021, 11:20am

(Perhaps this thread should be moved to “Hardware”, but…)

As I now understand it, the main reason the Raspberry Pi 3 is too slow for the HackRF is the 8 MS/s samplerate. But the Pi 3 can handle the 2 MS/s provided by the RTL-SDR. So: Do SDR receivers exist (LimeSDR/KiwiSDR/Adalm Pluto/…?) that can deliver no more than 2 MS/s?

hb9fxx · March 22, 2021, 8:21am

LimeSDR, Adalm Pluto, BladeRF can deliver lower samplerates than 2MS/s from what i know.

HackRF can even run as low as 1MS/s but with aliasing issues. Lowest ‘in-spec’ sample rate is 8MS/s. 4 runs quite fine. 2 will already show more aliasasing, if us use only really the ‘center’ of the spectrum it might work well enough.

oz1sej1 · March 22, 2021, 1:15pm

Thanks! Hm, might actually be cheaper to use HackRF+RPi4

hb9fxx · March 23, 2021, 8:45am

Personally i have been very disappointed by the LimeSDR mini above 2GHz. Seems very noisy (just plugin it in without using on the same Pi4 than the HackRF causes much noise on the HackRF, even with short usb cables with ferrit beads). Might be that i didn’t find good settings for it… but for now i’m disappointed.

I hope to upgrade my HackRF to a BladeRF 2.0 soon. For a cheaper variant i’d choose the Adalm Pluto.

Commercial quality down converter seem expensive. As my HackRF is now GPSDO locked, in case of down converter i’d like the down converters’s frequency be locked as well.

Nevertheless i’ll start to experiment with building a down converter but more as an educational project. Got a nice PLL OCXO, mixer and filter. Just missing time.

nigel · March 26, 2021, 4:16pm

Hmm…not sure why you had to ‘mess’ with something that seemed to be working…?