SatNOGS client fails after upgrade to version 1.7

SatNOGS Software
1

After having updated my client to version 1.7 on a Rapsberry Pi 3 I tried the first and best pass which turned out to be a XW-2E pass in CW mode. The client tried to start tracking OK but gave up immediately with the message:

satnogs_cw_decoder.py: error: unrecognized arguments: --udp-dump-port=57356

Believing I hadn’t done a complete update I rerun satnogs-upgrade but I didn’t have much luck here either:

Calculating upgrade... Done
The following packages will be upgraded:
  libuhd3.15.0 soapysdr0.7-module-airspy soapysdr0.7-module-audio soapysdr0.7-module-bladerf
  soapysdr0.7-module-hackrf soapysdr0.7-module-lms7 soapysdr0.7-module-osmosdr uhd-host
8 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 9,041 kB/11.6 MB of archives.
After this operation, 3,072 B of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://download.opensuse.org/repositories/home:/librespace:/satnogs/Raspbian_10 ./ uhd-host 3.15.0.0-4satnogs1 [9,041 kB]
Err:1 http://download.opensuse.org/repositories/home:/librespace:/satnogs/Raspbian_10 ./ uhd-host 3.15.0.0-4satnogs1
  File has unexpected size (9040820 != 9040824). Mirror sync in progress? [IP: 2001:6b0:17:f0a0::fd 80]
  Hashes of expected file:
   - SHA256:495aa8dea780e9473e4a7123df66709aa6680bcc16cfe201718061083a0291cf
   - SHA1:2d4bcc7f6ede1c5d8baccc42ca7c65ab5ca16ee5 [weak]
   - MD5Sum:9c9060affc1ff4ea5aadb160a8d325c0 [weak]
   - Filesize:9040824 [weak]
E: Failed to fetch http://ftp.lysator.liu.se/pub/opensuse/repositories/home:/librespace:/satnogs/Raspbian_10/armhf/uhd-host_3.15.0.0-4satnogs1_armhf.deb  File has unexpected size (9040820 != 9040824). Mirror sync in progress? [IP: 2001:6b0:17:f0a0::fd 80]
   Hashes of expected file:
    - SHA256:495aa8dea780e9473e4a7123df66709aa6680bcc16cfe201718061083a0291cf
    - SHA1:2d4bcc7f6ede1c5d8baccc42ca7c65ab5ca16ee5 [weak]
    - MD5Sum:9c9060affc1ff4ea5aadb160a8d325c0 [weak]
    - Filesize:9040824 [weak]
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
root@bastro:~#

I have tried both options mentioned above, but the doesn’t change anything.

So how do I best proceed from here? Is there another repository for satnogs than OpenSUSE?

PS Does this edotor have a ‘preview’ function? I’m writing this more or less in the dark.

2

I was able to remove uhd-host from my system and re-install it ok:

root@cruftpi6:~# apt install uhd-host
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following NEW packages will be installed:
  uhd-host
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 9041 kB of archives.
After this operation, 32.5 MB of additional disk space will be used.
Get:1 http://download.opensuse.org/repositories/home:/librespace:/satnogs/Raspbian_10 ./ uhd-host 3.15.0.0-4satnogs1 [9041 kB]
Fetched 9041 kB in 0s (26.5 MB/s)
Selecting previously unselected package uhd-host.
(Reading database ... 99019 files and directories currently installed.)
Preparing to unpack .../uhd-host_3.15.0.0-4satnogs1_armhf.deb ...
Unpacking uhd-host (3.15.0.0-4satnogs1) ...
Setting up uhd-host (3.15.0.0-4satnogs1) ...
Processing triggers for man-db (2.8.5-2) ...
Scanning processes...                                                                                                                   
Scanning linux images...                                                                                                                

Failed to check for processor microcode upgrades.

No services need to be restarted.

No containers need to be restarted.

No user sessions are running outdated binaries.

Which repositories are you using?

Here’s my sources.list files which I think is standard:

$ cat /etc/apt/sources.list
deb http://raspbian.raspberrypi.org/raspbian/ buster main contrib non-free rpi

$ cat /etc/apt/sources.list.d/ansible.list 
deb http://ppa.launchpad.net/ansible/ansible/ubuntu trusty main

$ cat /etc/apt/sources.list.d/raspi.list 
deb http://archive.raspberrypi.org/debian/ buster main

$ cat /etc/apt/sources.list.d/satnogs.list 
deb http://download.opensuse.org/repositories/home:/librespace:/satnogs/Raspbian_10 ./

Note, the deb-src (source code) lines don’t matter for this.

You could do an apt clean and see if it re-downloads ok. I don’t see anything wrong with the download, at least on the server it gave me the file from.

As a side note: a preview window can be viewed on the right of your editor.

3

I followed your advise and removed uhd-host, but couldn’t reinstall it: Same miserable result. I did find out, however, (apt search -n uhd-host) that uhd-host is the driver for Ettus Research product and I don’t have any of those (outside my budget) so I left it out and did an upgrade without any problems.

The next available pass was another XW-satellite (XW-2F in CW mode) and it showed unfurtunately that an upgrade did not solve the original problem:

satnogs_cw_decoder.py: error: unrecognized arguments: --udp-dump-port=57356

so what can be done about that?

OT: This time I saw the preview, the first time there was something else in that place - a list of posts IIRC.

4

Are you using the UDP dump port for satnogs-gr-satellite or anything else? If not, you can disable it. Run sudo satnogs-setup, go to Advanced, then Radio, then at the bottom UDP_DUMP_PORT, and you can erase that (if anything is there), then apply and see if it works. If not, go to Advanced, then Support to generate a config to upload here for review.

Checking out this observation:

https://network.satnogs.org/observations/6293190/

It shows a UDP port has been set, but not a UDP host. Maybe that causes an issue (?). If you use it, it may be you want it set to nothing or 127.0.0.1 unless you have a more complex setup.

From your metadata:

* udp-dump-host: null,
* udp-dump-port: 57356
5

The observation you refer to is from OZ7SAT (Station 49). I am part of the OZ7SAT group, but the things I’m doing here are on my own setup (Station 70). See eg. observation 6300098.

Out of interest: How do you get the meta data? out of the database?

I will take a look at my configuration, but that will be tomorrow. Its tea- and bed-time.

6

Not sure if it is a coincidence or not, but I see that station 49 has recently started having failures as well as your station 70.

Go to an observation. In the left hand column with all the details, one is Metadata. Click the arrows on that to expand to see the details.

7

Well, it is not quite coincidental. Some of us decided to update the OS to get a newer python without considering all the consequences :frowning_face:

I updated OZ7SAT to Lubuntu 22.04 and we all know (now) that that’s not a Good Thing. That’s why OZ7SAT is in ‘Testing’. We are now debating whether to reinstall Lubuntu 20.04 or install Debian Buster (Debian 10).

Meanwhile I decided to update my own station which was running version 1.4 - with all the dust that raised. More on that later.

8

I have tried a couple of things.

First I defined a UDP dump host (127.0.0.1) and run a pass (6303640). It didn’t like any of the UDP dump parameters, so it aborted.

Then I cleared both the UDP dump host and the UDP dump port and run another pass (6303645) which also aborted. The odd thing here is that if you look in the metadata for the pass, the UDP dump port still has a non-null value in spite of my clearing it out in satnogs-setup.

So here is the support dump, which alas doesn’t show the UDP dump parameters:

------------[ copy here ]------------
{
    "versions": {
        "satnogs-client": "1.7",
        "satnogs-client-ansible": "202205101826",
        "satnogs-flowgraphs": "1.2.2-1",
        "gr-satnogs": "2.1.2.1-1",
        "gr-soapy": "2.1.3.1-1",
        "gnuradio": "3.8.2.0-14satnogs2",
        "satnogs-config": "0.12"
    },
    "state": {
        "is-applied": true,
        "pending-tags": null
    },
    "system": {
        "date": "2022-08-06T17:33:16.872950+00:00",
        "distribution": {
            "DESCRIPTION": "Raspbian GNU/Linux 10 (buster)",
            "RELEASE": "10",
            "CODENAME": "buster",
            "ID": "Raspbian"
        },
        "pending-updates": false,
        "platform": {
            "system": "Linux",
            "node": "bastro",
            "release": "5.10.103-v7+",
            "version": "#1529 SMP Tue Mar 8 12:21:37 GMT 2022",
            "machine": "armv7l",
            "processor": ""
        },
        "memory": {
            "total": 968052736,
            "available": 768430080,
            "percent": 20.6,
            "used": 107835392,
            "free": 376070144,
            "active": 333283328,
            "inactive": 177324032,
            "buffers": 78233600,
            "cached": 405913600,
            "shared": 24666112,
            "slab": 60203008
        },
        "disk": {
            "total": 31090814976,
            "used": 3703025664,
            "free": 26077331456,
            "percent": 12.4
        }
    },
    "configuration": {
        "satnogs_antenna": "RX",
        "satnogs_api_token": "[redacted]",
        "satnogs_client_version": "1.7",
        "satnogs_log_level": "DEBUG",
        "satnogs_ppm_error": "7",
        "satnogs_rf_gain": "49.6",
        "satnogs_rx_samp_rate": "2.048e6",
        "satnogs_soapy_rx_device": "driver=rtlsdr",
        "satnogs_station_elev": "37",
        "satnogs_station_id": "70",
        "satnogs_station_lat": "55.83904",
        "satnogs_station_lon": "12.39592"
    }
}
------------[ copy end ]-------------
9

A third thing I have done:

It appears that the default value for UDP_DUMP_PORT is 57356 as defined in

/var/lib/satnogs/lib/python3.7/site-packages/satnogsclient/settings.py

Not knowing exactly how to treat environ.get I tried to manually change as follows and restarted satnogs-client:


UDP_DUMP_HOST = environ.get('UDP_DUMP_HOST', None)
UDP_DUMP_PORT = int(environ.get('UDP_DUMP_PORT', 0))
#UDP_DUMP_PORT = int(environ.get('UDP_DUMP_PORT', 57356))

but that still aborted a pass (6303981)

I believe I’ll leave it to more knowledgeable people to decide what to do next.

10

Good day,

I don’t think the dump variable is the problem, it is an indication of the fact that not all packages are updated.
This mix of old and new is causing this error, you will not see this error when all version of the same release are installed.

Based on your config output, it seems satnogs-flowgraphs is an old version.

I don’t have a 1.7 stable running right now, maybe somebody who has and is also reading this post can check and share the version.

Update:

I found a Virtual server with stable and that has satnogs-flowgraphs 1.4-1

1 Like
11

I have version 1.7 running, and have just checked the versions by running sudo satnogs-setup and go to advanced and support. It shows the following versions, they work but may not be the latest as I have not updated in a while.

    "versions": {
        "satnogs-client": "1.7",
        "satnogs-client-ansible": "202109022142",
        "satnogs-flowgraphs": "1.4-1",
        "gr-satnogs": "2.3.1.1-1",
        "gr-soapy": "2.1.3.1-1",
        "gnuradio": "3.8.2.0-14satnogs2",
        "satnogs-config": "0.12"
2 Likes
12

Thanks @EelkeVisser, so this seems to support my idea, not all packages are updated and that explains the UDP port error.

The client sends a command that the flowgraph doesn’t understand, because in that version it wasn’t available.

2 Likes
13

I tend to agree with you so I may have done an incomplete update/upgrade.

In order to amend that I rerun satnogs-upgrade but it didn’t do much:

root@bastro:~# satnogs-upgrade 
Hit:1 http://ppa.launchpad.net/ansible/ansible/ubuntu trusty InRelease
Hit:2 http://raspbian.raspberrypi.org/raspbian buster InRelease     
Hit:3 http://archive.raspberrypi.org/debian buster InRelease        
Get:4 http://download.opensuse.org/repositories/home:/librespace:/satnogs/Raspbian_10 ./ InRelease [1545 B]
Fetched 1545 B in 3s (521 B/s)                                      
Reading package lists... Done
root@bastro:~#

This looks to me like an ‘apt update’ run but it isn’t complete:

root@bastro:~# apt update
Hit:1 http://archive.raspberrypi.org/debian buster InRelease
Hit:2 http://raspbian.raspberrypi.org/raspbian buster InRelease     
Hit:3 http://ppa.launchpad.net/ansible/ansible/ubuntu trusty InRelease
Get:4 http://download.opensuse.org/repositories/home:/librespace:/satnogs/Raspbian_10 ./ InRelease [1,545 B]
Fetched 1,545 B in 3s (516 B/s)                                     
Reading package lists... Done
Building dependency tree       
Reading state information... Done
All packages are up to date.
root@bastro:~#

‘apt update’ has three more lines at the end. An ‘apt upgrade’ run didn’t do much either:


root@bastro:~# apt upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@bastro:~#

So today’s question is: How do I get this stuff updated? Or can I find an up-to-date image for the RPi and install that? The SatNOGS wiki page on RaspberryPi points me to a version from December 2020. Is that version new enough?

14

I am guessing all the sudo satnogs-setup steps are already done multiple times, so lets look further.

There was a repository expired key issue some months ago, maybe you are running into that one.
apt-key list should show all the key and make clear if they are all ok.

If that is fine, lets try some other options.

Try apt-cache search satnogs-flowgraphs this should show all satnogs-flowgraphs versions
With apt-cache show satnogs-flowgraphs you can see details.

A sudo ap-get install satnogs-flowgraphs=version should install the new version.

15

I shamefully have to admin that I cannot have done my homework properly because when I hit ‘Apply’ in satnogs-setup an awfully lot of thing happened and when I looked at the support report I saw this:

------------[ copy here ]------------
{
    "versions": {
        "satnogs-client": "1.7",
        "satnogs-client-ansible": "202205101826",
        "satnogs-flowgraphs": "1.4-1",
        "gr-satnogs": "2.3.1.1-1",
        "gr-soapy": "2.1.3.1-1",
        "gnuradio": "3.8.2.0-14satnogs2",
        "satnogs-config": "0.12"
    },

(the rest of the report is identical to the one I posted, except for memory usage (RAM and disk))

Also a couple of tracking runs I scheduled (6306883 and 6306885) worked as they should. That I didn’t get any data is a completely different story.

I would like to say thank you for the good advise I got here. It is always a pleasure to talk to people who knows what they talk about.

3 Likes
16

Great to see the system is working again, enjoy.

3 Likes