Station not uploading any data with latest software

Hello all,
With the latest satnogs update, my station isn’t uploading any data, and doesn’t appear to be even starting observations successfully. I am using a Raspberry Pi 3B+ with the ready-made satnogs image titled “2020-03-04-Raspbian-SatNOGS-lite.img”. I ran sudo journalctl -f -u satnogs-client.service during an observation and got the following output:

Apr 21 19:30:13 raspberrypi satnogs-client[6117]: retval = job.func(*job.args, **job.kwargs)
Apr 21 19:30:13 raspberrypi satnogs-client[6117]: File “/var/lib/satnogs/lib/python3.7/site-packages/satnogsclient/scheduler/tasks.py”, line 82, in spawn_observer
Apr 21 19:30:13 raspberrypi satnogs-client[6117]: observer.observe()
Apr 21 19:30:13 raspberrypi satnogs-client[6117]: File “/var/lib/satnogs/lib/python3.7/site-packages/satnogsclient/observer/observer.py”, line 160, in observe
Apr 21 19:30:13 raspberrypi satnogs-client[6117]: self.plot_waterfall()
Apr 21 19:30:13 raspberrypi satnogs-client[6117]: File “/var/lib/satnogs/lib/python3.7/site-packages/satnogsclient/observer/observer.py”, line 258, in plot_waterfall
Apr 21 19:30:13 raspberrypi satnogs-client[6117]: waterfall_png=self.observation_waterfall_png)
Apr 21 19:30:13 raspberrypi satnogs-client[6117]: File “/var/lib/satnogs/lib/python3.7/site-packages/satnogsclient/observer/waterfall.py”, line 20, in plot_waterfall
Apr 21 19:30:13 raspberrypi satnogs-client[6117]: _ = np.fromfile(wf_file, dtype="|S32", count=1)[0]
Apr 21 19:30:13 raspberrypi satnogs-client[6117]: IndexError: index 0 is out of bounds for axis 0 with size 0

I’ve tried completely reflashing the micro SD card twice and double-checked the entire configuration, though this still occurs. Does anyone know what could be causing this and what steps I should take to try to fix it?

Thanks,
Ben

can you run sudo satnogs-setup?
go to the advanced section
select support at the bottom and post the results here.
Some configuration has changed. I got caught out the same way when I upgraded.

Here’s the support information:

{
“versions”: {
“satnogs-client”: “1.3.1”,
“satnogs-client-ansible”: “202004031132”,
“satnogs-flowgraphs”: “1.1.1-1”,
“gr-satnogs”: “2.1.2-1”,
“gr-soapy”: “2.1.2-1”,
“gnuradio”: “3.8.0.0-6”,
“satnogs-config”: “0.10.1”
},
“state”: {
“is-applied”: true,
“pending-tags”: null
},
“system”: {
“distribution”: {
“DESCRIPTION”: “Raspbian GNU/Linux 10 (buster)”,
“RELEASE”: “10”,
“CODENAME”: “buster”,
“ID”: “Raspbian”
},
“pending-updates”: true,
“platform”: {
“system”: “Linux”,
“node”: “raspberrypi”,
“release”: “4.19.97-v7+”,
“version”: “#1294 SMP Thu Jan 30 13:15:58 GMT 2020”,
“machine”: “armv7l”,
“processor”: “”
},
“memory”: {
“total”: 971059200,
“available”: 777854976,
“percent”: 19.9,
“used”: 119808000,
“free”: 136204288,
“active”: 293789696,
“inactive”: 443756544,
“buffers”: 44285952,
“cached”: 670760960,
“shared”: 6406144,
“slab”: 75898880
},
“disk”: {
“total”: 31090814976,
“used”: 3224117248,
“free”: 26556239872,
“percent”: 10.8
}
},
“configuration”: {
“satnogs_antenna”: “RX”,
“satnogs_api_token”: “[redacted]”,
“satnogs_ppm_error”: “0”,
“satnogs_rf_gain”: “14.4”,
“satnogs_rx_samp_rate”: “2.048e6”,
“satnogs_soapy_rx_device”: “driver=rtlsdr”,
“satnogs_station_elev”: “170”,
“satnogs_station_id”: “1051”,
“satnogs_station_lat”: “34.60225”,
“satnogs_station_lon”: “-88.547191”
}
}

Please run Update, and then Apply on satnogs-setup, and then paste in the support information again.

Cheers,
Mark

I’m no expert at this. Follow Mark’s instructions. He fixed my problem.Your station 1051 NTSatlink come up but no waterfall or audio.
Only thing I could see, your gain setting is much lower than mine (29.7) do you use a LNA?

Having issues after the latest update as well. Station seems to not be updating anything, empty waterfall. After upgrade it didn’t want to start until I fixed basic settings, updated with the new required fields.

I use LNA and this is my basic settings:

Per @vk5qi I’ve ran update and apply on satnogs-setup and generated the support information:

------------[ copy here ]------------
{
“versions”: {
“satnogs-client”: “1.3.1”,
“satnogs-client-ansible”: “202004031132”,
“satnogs-flowgraphs”: “1.1.1-1”,
“gr-satnogs”: “2.1.2-1”,
“gr-soapy”: “2.1.2-1”,
“gnuradio”: “3.8.1.0~rc1-2”,
“satnogs-config”: “0.10.1”
},
“state”: {
“is-applied”: true,
“pending-tags”: null
},
“system”: {
“distribution”: {
“DESCRIPTION”: “Raspbian GNU/Linux 10 (buster)”,
“RELEASE”: “10”,
“CODENAME”: “buster”,
“ID”: “Raspbian”
},
“pending-updates”: false,
“platform”: {
“system”: “Linux”,
“node”: “satnogs”,
“release”: “4.19.97-v7+”,
“version”: “#1294 SMP Thu Jan 30 13:15:58 GMT 2020”,
“machine”: “armv7l”,
“processor”: “”
},
“memory”: {
“total”: 971055104,
“available”: 788672512,
“percent”: 18.8,
“used”: 108208128,
“free”: 409120768,
“active”: 333406208,
“inactive”: 142540800,
“buffers”: 48463872,
“cached”: 405262336,
“shared”: 8912896,
“slab”: 64528384
},
“disk”: {
“total”: 15348867072,
“used”: 4026187776,
“free”: 10652762112,
“percent”: 27.4
}
},
“configuration”: {
“hamlib_utils_rot_enabled”: false,
“satnogs_antenna”: “RX”,
“satnogs_api_token”: “[redacted]”,
“satnogs_dev_args”: “rtl=0,buffers=32,buflen=16384,bias=1”,
“satnogs_post_observation_script”: “/home/pi/rtl_biast/build/src/rtl_biast -b 0”,
“satnogs_rf_gain”: 16.6,
“satnogs_rx_device”: “rtlsdr”,
“satnogs_rx_samp_rate”: “2.048e6”,
“satnogs_soapy_rx_device”: “driver=rtlsdr”,
“satnogs_station_elev”: 518,
“satnogs_station_id”: 521,
“satnogs_station_lat”: 43.858,
“satnogs_station_lon”: 18.422,
“satnogs_waterfall_autorange”: true
}
}
------------[ copy end ]-------------

Thanks!

The software versions look OK now, but I’m not sure the satnogs_dev_args are required any more, or if they cause issues if used.
Try deleting those and see if anything changes.

73
Mark VK5QI

1 Like

Thanks for your response. I’ve removed the dev args and applied settings. Will report back.

No luck, same with removed dev args.

systemctl status satnogs-client output:

● satnogs-client.service - SatNOGS client
Loaded: loaded (/etc/systemd/system/satnogs-client.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2020-04-22 11:51:37 CEST; 1h 44min ago
Main PID: 7320 (satnogs-client)
Tasks: 22 (limit: 2200)
Memory: 87.0M
CGroup: /system.slice/satnogs-client.service
└─7320 /var/lib/satnogs/bin/python3 /var/lib/satnogs/bin/satnogs-client

Apr 22 13:04:00 satnogs satnogs-client[7320]: return request(‘get’, url, params=params, **kwargs)
Apr 22 13:04:00 satnogs satnogs-client[7320]: File “/usr/lib/python3/dist-packages/requests/api.py”, line 60, in reque
Apr 22 13:04:00 satnogs satnogs-client[7320]: return session.request(method=method, url=url, **kwargs)
Apr 22 13:04:00 satnogs satnogs-client[7320]: File “/usr/lib/python3/dist-packages/requests/sessions.py”, line 533, in
Apr 22 13:04:00 satnogs satnogs-client[7320]: resp = self.send(prep, **send_kwargs)
Apr 22 13:04:00 satnogs satnogs-client[7320]: File “/usr/lib/python3/dist-packages/requests/sessions.py”, line 646, in
Apr 22 13:04:00 satnogs satnogs-client[7320]: r = adapter.send(request, **kwargs)
Apr 22 13:04:00 satnogs satnogs-client[7320]: File “/usr/lib/python3/dist-packages/requests/adapters.py”, line 516, in
Apr 22 13:04:00 satnogs satnogs-client[7320]: raise ConnectionError(e, request=request)
Apr 22 13:04:00 satnogs satnogs-client[7320]: requests.exceptions.ConnectionError: HTTPSConnectionPool(host='network.sat
lines 1-19/19 (END)

The device has connectivity and can ping. Something with new update broke.

UPDATE

I now have satnogs-client process running fine:

● satnogs-client.service - SatNOGS client
Loaded: loaded (/etc/systemd/system/satnogs-client.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2020-04-22 18:29:04 CEST; 2min 38s ago
Main PID: 3988 (satnogs-client)
Tasks: 5 (limit: 2200)
Memory: 29.5M
CGroup: /system.slice/satnogs-client.service
└─3988 /var/lib/satnogs/bin/python3 /var/lib/satnogs/bin/satnogs-client

Apr 22 18:29:04 satnogs systemd[1]: Started SatNOGS client

What I did was to change the sample rate from “2.048e6” to “2.4e6” (even though the first value should work fine and is advised on satnogs wiki) and I’ve then increased gain. I don’t think this particular change helped but when I applied settings via satnogs-setup again, it looked like many settings were re-installed and configured correctly this time.

I’ve scheduled another observation soon so I’ll know if it’s working now.

UPDATE 2

No good. No waterfall data now.

● satnogs-client.service - SatNOGS client
Loaded: loaded (/etc/systemd/system/satnogs-client.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2020-04-22 18:29:04 CEST; 28min ago
Main PID: 3988 (satnogs-client)
Tasks: 22 (limit: 2200)
Memory: 98.6M
CGroup: /system.slice/satnogs-client.service
└─3988 /var/lib/satnogs/bin/python3 /var/lib/satnogs/bin/satnogs-client

Apr 22 18:48:56 satnogs satnogs-client[3988]: File “/usr/bin/satnogs_fsk_ax25.py”, line 92, in init
Apr 22 18:48:56 satnogs satnogs-client[3988]: tune_args, settings, samp_rate_rx, “fc32”)
Apr 22 18:48:56 satnogs satnogs-client[3988]: File “/usr/lib/python3/dist-packages/soapy/soapy_swig.py”, line 166, in
Apr 22 18:48:56 satnogs satnogs-client[3988]: return _soapy_swig.source_make(nchan, device, dev_args, stream_args, t
Apr 22 18:48:56 satnogs satnogs-client[3988]: RuntimeError: soapy::source: Unsupported sample rate. Rate must be in the
Apr 22 18:48:59 satnogs satnogs-client[3988]: Found 1 device(s):
Apr 22 18:48:59 satnogs satnogs-client[3988]: 0: Realtek, RTL2838UHIDIR, SN: 00000001
Apr 22 18:48:59 satnogs satnogs-client[3988]: Using device 0: Generic RTL2832U OEM
Apr 22 18:48:59 satnogs satnogs-client[3988]: Found Rafael Micro R820T tuner
Apr 22 18:49:01 satnogs satnogs-client[3988]: satnogsclient.observer.observer - ERROR - No waterfall data file found

I guess it’s time to advise others to not update?

Hi there, I’ve been getting some recent instabilities while updating to the latest versions. The most obvious issue is that I’m unable to make AFSK and BPSK observations due to missing python files. Here’s a recent example:

Apr 22 16:08:33 rpi3bp satnogs-client[283]: apscheduler.executors.default - ERROR - Job     "spawn_observer (trigger: date[2020-04-22 16:08:30 UTC], next run at: 2020-04-22 16:08:30 UTC)" raised an exception
Apr 22 16:08:33 rpi3bp satnogs-client[283]: Traceback (most recent call last):
Apr 22 16:08:33 rpi3bp satnogs-client[283]:   File "/usr/lib/python3/dist-packages/apscheduler/executors/base.py", line 125, in run_job
Apr 22 16:08:33 rpi3bp satnogs-client[283]:     retval = job.func(*job.args, **job.kwargs)
Apr 22 16:08:33 rpi3bp satnogs-client[283]:   File "/var/lib/satnogs/lib/python3.7/site-packages/satnogsclient/scheduler/tasks.py", line 82, in spawn_observer
Apr 22 16:08:33 rpi3bp satnogs-client[283]:     observer.observe()
Apr 22 16:08:33 rpi3bp satnogs-client[283]:   File "/var/lib/satnogs/lib/python3.7/site-packages/satnogsclient/observer/observer.py", line 151, in observe
Apr 22 16:08:33 rpi3bp satnogs-client[283]:     self.observation_decoded_data)
Apr 22 16:08:33 rpi3bp satnogs-client[283]:   File "/var/lib/satnogs/lib/python3.7/site-packages/satnogsclient/upsat/gnuradio_handler.py", line 109, in exec_gnuradio
Apr 22 16:08:33 rpi3bp satnogs-client[283]:     proc = subprocess.Popen(args)
Apr 22 16:08:33 rpi3bp satnogs-client[283]:   File "/usr/lib/python3.7/subprocess.py", line 775, in __init__
Apr 22 16:08:33 rpi3bp satnogs-client[283]:     restore_signals, start_new_session)
Apr 22 16:08:33 rpi3bp satnogs-client[283]:   File "/usr/lib/python3.7/subprocess.py", line 1522, in _execute_child
Apr 22 16:08:33 rpi3bp satnogs-client[283]:     raise child_exception_type(errno_num, err_msg, err_filename)
Apr 22 16:08:33 rpi3bp satnogs-client[283]: FileNotFoundError: [Errno 2] No such file or directory: 'satnogs_bpsk_ax25.py': 'satnogs_bpsk_ax25.py'

Here is my current config:

{
"versions": {
    "satnogs-client": "1.3.1",
    "satnogs-client-ansible": "202004031132",
    "satnogs-flowgraphs": "1.1.1+5+g83d39898-1",
    "gr-satnogs": "2.1.2-1",
    "gr-soapy": "2.1.2-1",
    "gnuradio": "3.8.1.0~rc1-2",
    "satnogs-config": "0.10.1+1.g3495702"
},
"state": {
    "is-applied": true,
    "pending-tags": null
},
"system": {
    "date": "2020-04-22T17:02:02.277185+00:00",
    "distribution": {
        "DESCRIPTION": "Raspbian GNU/Linux 10 (buster)",
        "RELEASE": "10",
        "CODENAME": "buster",
        "ID": "Raspbian"
    },
    "pending-updates": false,
    "platform": {
        "system": "Linux",
        "node": "rpi3bp",
        "release": "4.19.97-v7+",
        "version": "#1294 SMP Thu Jan 30 13:15:58 GMT 2020",
        "machine": "armv7l",
        "processor": ""
    },
    "memory": {
        "total": 971055104,
        "available": 662470656,
        "percent": 31.8,
        "used": 246333440,
        "free": 473870336,
        "active": 330547200,
        "inactive": 98902016,
        "buffers": 43397120,
        "cached": 207454208,
        "shared": 6549504,
        "slab": 47271936
    },
    "disk": {
        "total": 62811418624,
        "used": 5485367296,
        "free": 54744756224,
        "percent": 9.1
    }
},
"configuration": {
    "experimental": true,
    "gpsd_enabled": true,
    "hamlib_utils_rot_enabled": false,
    "satnogs_antenna": "RX",
    "satnogs_api_token": "[redacted]",
    "satnogs_post_observation_script": "/home/pi/rtl_biast/build/src/rtl_biast -b 0",
    "satnogs_pre_observation_script": "/home/pi/rtl_biast/build/src/rtl_biast -b 1",
    "satnogs_remove_raw_files": true,
    "satnogs_rf_gain": "7.7",
    "satnogs_rx_samp_rate": "2048e6",
    "satnogs_soapy_rx_device": "driver=rtlsdr",
    "satnogs_station_elev": 70,
    "satnogs_station_id": 1156,
    "satnogs_station_lat": [redacted],
    "satnogs_station_lon": [redacted]
}

}

You have enabled installation of experimental software for some reason. It’s normal to get instabilities with it.

2 Likes

I think that you may be making to many changes to fast. The above won’t work. Revert back to what is suggested in the wiki.

The connection errors you see in journalctl are expected from time to time either due to local network resets or during new SatNOGS Network deployments.

2 Likes

Okay, I’ve returned it. For the record I only applied changes twice… yesterday after updating and installing new version and today when I made change for sample rate and gain. I have an observation in 20 minutes so I’ll know if it makes any difference, however what about:

Apr 22 18:49:01 satnogs satnogs-client[3988]: satnogsclient.observer.observer - ERROR - No waterfall data file found

UPDATE:

Finally a waterfall with data! https://network.satnogs.org/observations/2079144/

First one, so I’ll see if there are more soon. Thanks!

1 Like

Thanks a lot for noticing that. I unset that switch and then could get back to functionality after doing a sudo apt-get upgrade --allow-downgrades

Best regards,
Andreas / VA2WBT

1 Like

An update on the situation.

After applying satnogs settings several times, fixing the sample rate and removing the dev args, waterfalls show data. It looks like my LNA wasn’t working after removing dev args, so I had to also include the pre-observation script.

As advised by @vk5qi, I removed old dev arguments but because that section had:

“rtl=0,buffers=32,buflen=16384,bias=1”,

…my LNA didn’t start, as it was missing the pre-observation script:

home/pi/rtl_biast/build/src/rtl_biast -b 1

After adding pre-observation script, things are looking better. I had to tweak gain a bit and it appears that the station is producing solid observation results. Hopefully this info helps to others.

Hi @ivor,

Yes, unfortunately, enabling the bias tee is not possible at the moment without a pre-obs script.

1 Like

No problem, I just pointed it out so others reading can see it.

A question while you’re here, did you notice issues with loading waterfalls (which load from CDN’s if I correctly understood)? It’s really slowly loading, like 5 mins or more.

In fact, it appears to be slow loading only when being embedded in network.satnogs.org, if I right click and copy the link, it will load fast in another window.

Thank you!

That’s very interesting. What is your location? We recently enabled CDN and we expected some caching issues. Yet, what you are reporting is totally different.

1 Like

Check station 521 for specifics about location please. It’s pulling info from German CDN node so I would assume it should be fast. To add more info, seems to be periodic issue. Maybe on first upload only? Right now it’s working well but that’s probably because it’s cached, there’s been many times since yesterday where graphs were very slow loading. I have another observation ending in 1 min and I’ll record first loading of the waterfall.

Update, this observation just finished and it’s loading fast enough.