UDP dump port issue

Hi@all,

I gave the 2020 version of artifacts a try. As I got so much errors (I won’t call it buggy) I have decided to use the development version (1.7+1.g07f6c80). Well, most of the errors are gone. But unfortunately I can not work out a solution for unrecognized arguments: --udp-dump-port=57356 as it shows up in every demodulation attempt. Followed by the good old satnogsclient.observer.observer - ERROR - No waterfall data file found

Any help is appreciated.
Thank you in advance
MrMoo

Hi @mrmoo,

Please copy/paste your satnogs configuration from the output of:

sudo satnogs-setup
Advanced → Support information

If you haven’t done so already, set Advanced → Debug → SATNOGS_LOG_LEVEL to DEBUG

Does your client work if you simply unset the udp-dump-port setting?

Scott

1 Like

Hi Scott,

thank you for the reply.

As requested, the support informations:

------------[ copy here ]------------
{
    "versions": {
        "satnogs-client": "1.7+1.g07f6c80",
        "satnogs-client-ansible": "202206091629",
        "satnogs-flowgraphs": "1.3-1",
        "gr-satnogs": "2.2.0.0-1",
        "gr-soapy": "2.1.3-1",
        "gnuradio": "3.8.2.0-2",
        "satnogs-config": "0.12+3.g014a15d"
    },
    "state": {
        "is-applied": true,
        "pending-tags": null
    },
    "system": {
        "date": "2022-06-14T21:31:39.800756+00:00",
        "distribution": {
            "DESCRIPTION": "Raspbian GNU/Linux 10 (buster)",
            "RELEASE": "10",
            "CODENAME": "buster",
            "ID": "Raspbian"
        },
        "pending-updates": false,
        "platform": {
            "system": "Linux",
            "node": "raspberrypi",
            "release": "5.15.45-v7+",
            "version": "#1562 SMP Thu Jun 9 13:56:09 BST 2022",
            "machine": "armv7l",
            "processor": ""
        },
        "memory": {
            "total": 968380416,
            "available": 762216448,
            "percent": 21.3,
            "used": 126480384,
            "free": 129847296,
            "active": 362221568,
            "inactive": 367378432,
            "buffers": 114503680,
            "cached": 597549056,
            "shared": 12574720,
            "slab": 78028800
        },
        "disk": {
            "total": 125510692864,
            "used": 4583350272,
            "free": 115772289024,
            "percent": 3.8
        }
    },
    "configuration": {
        "experimental": true,
        "hamlib_utils_rig_enabled": true,
        "satnogs_antenna": "RX",
        "satnogs_api_token": "[redacted]",
        "satnogs_log_level": "DEBUG",
        "satnogs_rot_port": "localhost:4533",
        "satnogs_rx_samp_rate": "2.048e6",
        "satnogs_soapy_rx_device": "driver=rtlsdr",
        "satnogs_station_elev": "345",
        "satnogs_station_id": "2701",
        "satnogs_station_lat": "48.8707",
        "satnogs_station_lon": "12.3615",
        "sentry_enabled": true
    }
}
------------[ copy end ]-------------

Well, I have checked unsetting udp dump port settings in the settings.py
When cheking the service the error is gone - but upload still does not work. Therefore I would assume it is still not working.

MrMoo

Ok, thanks for posting your results. At this point, we need to focus on what the logs are saying when an observation begins to get more clues.

The beginning of an observation is marked in the logs by a string that contains:

Spawning observer worker

Locate that in the logs and then look for error/abort/fail/exit in the next hundred or so lines and post the results.

Hi Scott,

unfortunately there is no dedicated satnogs log stored in /var/log. (even find / -name *.log 2> /dev/null | sort -r -n -k7 does not show such a log)
Might you point me to the location, please.

journalctl brings up that error:

Jun 16 12:41:11 raspberrypi satnogs-client[369]: satnogsclient.observer.observer - INFO - Observation Finished
Jun 16 12:41:11 raspberrypi satnogs-client[369]: satnogsclient.observer.observer - INFO - Executing post-observation script.
Jun 16 12:41:11 raspberrypi satnogs-client[369]: satnogsclient.observer.observer - INFO - Creating waterfall plot.
Jun 16 12:41:11 raspberrypi satnogs-client[369]: satnogsclient.waterfall - INFO - Reading waterfall file
Jun 16 12:41:11 raspberrypi satnogs-client[369]: satnogsclient.observer.observer - ERROR - No waterfall data file found
Jun 16 12:41:11 raspberrypi satnogs-client[369]: urllib3.connectionpool - DEBUG - Resetting dropped connection: sentry.io
Jun 16 12:41:11 raspberrypi satnogs-client[369]: urllib3.connectionpool - DEBUG - https://sentry.io:443 "POST /api/2818206/store/ HTTP/1.1" 200 41
Jun 16 12:41:13 raspberrypi satnogs-client[369]: urllib3.connectionpool - DEBUG - Starting new HTTPS connection (1): network.satnogs.org:443
Jun 16 12:41:13 raspberrypi satnogs-client[369]: urllib3.connectionpool - DEBUG - https://network.satnogs.org:443 "PUT /api/observations/6091223/ HTTP/1.1" 200 0

Btw. the manual run of satnogs_afsk1200_ax25.py works as expected. Both files audio-out.ogg and waterfall.dat contain data.

You need journalctl to look at the log files.

This example will show the latest 512 lines

sudo journalctl -f -u satnogs-client -n 512 and also show new real time messages.

More in general, I am puzzled why you get the udp messages, this functionality is created to interact with other programs and needs to be configured specifically. If you do, there will be extra lines in your /etc/default/satnogs-client file.

Example of the lines:

UDP_DUMP_HOST="127.0.0.1"
UDP_DUMP_PORT="57356"

Hi Jan,

I am aware about journalctl, but I thought there might/shoud be an old fashioned log file, too :slight_smile: This would be easier to check for “ERROR” and other states in nano with Strg+W :wink:

Well, I started out with a clean installation, so there are no other programs installed. Thats courious. Even there are no lines in the config adressing the udp port (also adding them does not fix the issue).

Btw. very nice QSL Card.

1 Like

There’s probably some logs in /var/log/daemon too.

1 Like

Hi jebba,
thank you. That makes things easier.

The only error (which repeats every time) is satnogsclient.observer.observer - ERROR - No waterfall data file found

1 Like

This is really a puzzle, I am running the same version on a Debian x86 system without a rotor and I will share my support output, maybe that will help.

------------[ copy here ]------------
{
    "versions": {
        "satnogs-client": "1.7+1.g07f6c80",
        "satnogs-client-ansible": "202206091629",
        "satnogs-flowgraphs": "1.4-1",
        "gr-satnogs": "2.3.1.1+3+gb02af152-1",
        "gr-soapy": "2.1.3.1+2+gf2c6097a-1",
        "gnuradio": "3.8.2.0-14satnogs2",
        "satnogs-config": "0.12+3.g014a15d"
    },
    "state": {
        "is-applied": true,
        "pending-tags": null
    },
    "system": {
        "date": "2022-06-17T20:51:47.758938+00:00",
        "distribution": {
            "DESCRIPTION": "Debian GNU/Linux 10 (buster)",
            "RELEASE": "10",
            "CODENAME": "buster",
            "ID": "Debian"
        },
        "pending-updates": false,
        "platform": {
            "system": "Linux",
            "node": "exomars",
            "release": "4.19.0-20-686-pae",
            "version": "#1 SMP Debian 4.19.235-1 (2022-03-17)",
            "machine": "i686",
            "processor": ""
        },
        "memory": {
            "total": 2113404928,
            "available": 1410666496,
            "percent": 33.3,
            "used": 438915072,
            "free": 290680832,
            "active": 348909568,
            "inactive": 1294356480,
            "buffers": 61870080,
            "cached": 1321938944,
            "shared": 16261120,
            "slab": 108654592
        },
        "disk": {
            "total": 4194500608,
            "used": 1396928512,
            "free": 2589708288,
            "percent": 35.0
        }
    },
    "configuration": {
        "experimental": true,
        "satnogs_antenna": "RX",
        "satnogs_api_token": "[redacted]",
        "satnogs_artifacts_enabled": true,
        "satnogs_artifacts_api_token": "[redacted]",
        "satnogs_dev_args": "biastee=true",
        "satnogs_post_observation_script": "/usr/local/bin/satnogs-post {{ID}} {{FREQ}} {{TLE}} {{TIMESTAMP}} {{BAUD}} {{SCRIPT_NAME}}",
        "satnogs_ppm_error": "-1",
        "satnogs_pre_observation_script": "/usr/local/bin/satnogs-pre {{ID}} {{FREQ}} {{TLE}} {{TIMESTAMP}} {{BAUD}} {{SCRIPT_NAME}}",
        "satnogs_rf_gain": "29.7",
        "satnogs_rx_samp_rate": "2.048e6",
        "satnogs_soapy_rx_device": "driver=rtlsdr,serial=00001220",
        "satnogs_station_elev": "5",
        "satnogs_station_id": "[redacted]",
        "satnogs_station_lat": "[redacted]",
        "satnogs_station_lon": "[redacted]",
        "snmpd_enabled": true,
        "udp_dump_host": "127.0.0.1",
        "udp_dump_port": "57356"
    }
}
------------[ copy end ]-------------

Thank you,
but now it seems to be really crazy…

The old Error was:

satnogs-client[19152]: satnogs_cw_decoder.py: error: unrecognized arguments: --udp-dump-port=57356
satnogs-client[19152]: satnogsclient.observer.observer - ERROR - No waterfall data file found

But after addig UDP data in the setup like:

UDP_DUMP_HOST="127.0.0.1"
UDP_DUMP_PORT="57356"

The Error message includes then the added localhost value:

satnogs-client[19263]: satnogs_fsk.py: error: unrecognized arguments: --udp-dump-host=127.0.0.1 --udp-dump-port=57356

So far I might state that the whole in the second case is due to the mod in /etc/default/satnogs-client
But I have no clue what triggers the error when the satnogs-client remains untouched.

I have tried to check the setup.py and settings.py, too but those do not seem to be the cause. ?.?.?.?.?

Looking at the config again, it seems you don’t have the right flow-graph package installed.

Can you try sudo satnogs-setup → update → apply → exit

Restart sudo satnogs-setup and check the Advanced → support.

Hi Jan,

I have tried it several times. Flowgraphs does not update. It still remains in Version 1.3-1.
It also states repository has not changed (in fact MD5 is the same)…

Well, as it seems to be that there will be an updated image in the future, it might make sense to use the RaspiNOAA V2 again now. And check back in a few weeks/months and give satnogs an another try with the new pi image…

Then maybe also try the command line apt update:

sudo apt-get update && sudo apt-get upgrade

Of course, and not just once (incl.rpi-update).

When you start satnogs-setup update do you see a similar output, and then especially the -c master ?

In the meantime I have also reached out to the developer channel to see if someone has another bright idea.

Yes, it is pretty the same:

Thank you for your help so far.

I have toyed around with random manual updates / reinstall. Now I get GPG Error due to unsigned keys from the satnogs-unstable repo. But I also did the workaround as su wget -qO - http://download.opensuse.org/repositories/home:/librespace:/satnogs-unstable/Raspbian_10/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg add - So this should not affect us at all.

Well something completely out of the box and there is a risk things will break :flushed:

Having a look at:

http://download.opensuse.org/repositories/home:/librespace:/satnogs-unstable/Raspbian_10/all/ there you can find satnogs-flowgraphs_1.4-1_all.deb maybe install it manually.

wget http://download.opensuse.org/repositories/home:/librespace:/satnogs-unstable/Raspbian_10/all/satnogs-flowgraphs_1.4-1_all.deb and sudo dpkg -i satnogs-flowgraphs_1.4-1_all.deb

Maybe there are also other packages that are more recent then installed on your system.

An add-on, is etc/apt/sources.list.d/satnogs.list pointing towards:

deb http://download.opensuse.org/repositories/home:/librespace:/satnogs-unstable/Debian_10 ./ ?

Well,
it seems there are a lot of problems. Manual installation of flowgraphs 1.4-1 would work, but it aborts due to outdated gr_satnogs.

Can the update script itself updated manually? Maybe the various outdated versions cause the problems?

1 Like

Then also download the other packages and try to install them.

To see what happens on a Pi I have just updated a Raspberry Pi to experimental and I don’t experience any issues …

This doesn’t help you, but I really don’t understand what is happening on your system and what was the reason why this happened.