Satnogs software package w/o Ansible

lz1mzk · February 14, 2025, 5:03pm

Hello.

I have a computer running OpenWebRX with RSPdx that works just fine.
Now I want to replace the WebRX client with SatNogs software /the hard way/.
My OS is Devuan Chimaera (4) == Debian Bullseye.

In the past I built the soapy stuff manually - SoapySDR, SoapySDRPlay3, they should work just fine.

Today I built satnogs-client. It runs well, I can see it connecting to the main server each minute polling tasks. However I don’t see any data uploaded.

Here are the env vars:
export SATNOGS_STATION_ID=3946
export SATNOGS_SOAPY_RX_DEVICE=“driver=sdrplay”
export SATNOGS_RX_SAMP_RATE=2e6
export SATNOGS_GAIN_MODE=“Settings Field”
export SATNOGS_OTHER_SETTINGS=“RFGR=1,IFGR=30”
export SATNOGS_RX_BANDWIDTH=600e3
export SATNOGS_ANTENNA=“Antenna A”
export SATNOGS_STATION_LAT=“42.678”
export SATNOGS_STATION_LON=“23.310”
export SATNOGS_STATION_ELEV=“600”
export SATNOGS_LOG_LEVEL=DEBUG

After some research I decided that I should also have gr-satnogs package and I build it, together with gnuradio 3.10.

All the gnuradio and satnogs packages are locally installed in .local/
Libraries are loaded and are reported by ldconfig -p.

Still no data uploaded to the SatNogs server.
I don’t understand how satnogs-client invokes the radio module (rspdx in my case) in order to listen and save the audio output (probably?).

I decided that it might call something through satnogs-flowgraphs.
Now I’m stuck here, on satnogs-flowgraphs that is missing the module SoapySDR.

++++++++++
satnogs-flowgraphs/generic/afsk1200_ax25.grc: (ModuleNotFoundError(“No module named ‘SoapySDR’”)
++++++++++

I guess that the module in question is the gr-soapy module - librespacefoundation / gr-soapy · GitLab

Here I having the followig error message:
++++++++++
gr-soapy/lib/source_impl.h:35:16: error: ‘function’ in namespace ‘boost’ does not name a template type; did you mean ‘is_function’?
++++++++++

BTW I’m building gr-soapy w/o SWIG, since cmake successfully finishes.

I’ll be grateful for quick explanation on the GR and SatNogs programs sequence in order to debug my setup.

Thank you,
73 de LZ1MZK

SA2KNG · February 15, 2025, 8:18am

mixing all these on a host build is daring (:
anyways, the gnuradio-3.10 stuff is not a stable release, there’s still some quirks being ironed out.
soapy was a out of tree in gnuradio-3.8 and is in tree at version 3.10

for gnuradio 3.8
satnogs-flowgraphs 1.5
gr-satnogs 2.3
gr-soapy 2.1

for gnuradio 3.10
satnogs-flowgraphs master
gr-satnogs 3.0

regarding ModuleNotFoundError I’m guessing the PYTHONPATH.

when developing for these, I have separate VM’s that run debian 11 and 12.
for testing I use docker, if you’re interested have a look at kng/satnogs-client-docker

lz1mzk · February 15, 2025, 12:25pm

Than you for your suggestions @SA2KNG

I’ll go with GR 3.10 now.

I intentionally didn’t install python3-soapy since I installed it manually before. My previous version didn’t have the SoapySDR.py wrapper. After quick update now I have it. I put it in PYTHONPATH also, as you mentioned.

The available packages are
GR 3.10
satnogs-client
gr-satnogs
satnogs-flowgraphs

All of SatNogs’ stuff is master, GR is maint-3.10.

I lack experience with docker, that’s why I build the packages locally, to prevent system mess.

I just found that my system clock lagged almost 10 minutes behind! (This machine stood off for almost a year).

What actually happened was that the scheduled task was never started, and the server dropped the task after the sunset time of the satellite.

Now I scheduled an observation and I’m happily getting some error messages related to the rig and Soapy (I’ll need to rebuild… gr and what else? with the new soapy module).

+++++++++++++
dummy_rot_set_position called: 114.54 10.03
DEBUG satnogsclient.observer.observer Start rigctrl thread.
DEBUG satnogsclient.observer.observer Rig Frequency 435025000
DEBUG satnogsclient.observer.observer Observation end: 2025-02-15 12:19:21+00:00
DEBUG satnogsclient.observer.worker Tracking initiated
rig_init: rig does not have rx_range!!
network_open: hoststr=127.0.0.1, portstr=4532
connect to 127.0.0.1:4532 failed, (trying next interface): Network error 111: Connection refused
network_open: failed to connect to 127.0.0.1:4532
++++++++++++++

And here for the Soapy

++++++++++++++
Traceback (most recent call last):
File “/home/mzk/.local/lib/python3.9/site-packages/gnuradio/soapy/init.py”, line 17, in
from .soapy_python import *
ImportError: libSoapySDR.so.0.8-2: cannot open shared object file: No such file or directory

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File “/home/mzk/.local/bin/satnogs_afsk1200_ax25.py”, line 27, in
from gnuradio import soapy
File “/home/mzk/.local/lib/python3.9/site-packages/gnuradio/soapy/init.py”, line 21, in
from .soapy_python import *
ImportError: libSoapySDR.so.0.8-2: cannot open shared object file: No such file or directory
+++++++++++++

Lessons learned:

the clock should be in sync;
SoapySDR.py was missing in older build

Do you know if there’s some way to force satnog-client to run the SDR hardware? Or issuing other script with the target frequency? I have to dive into the internals and I’m a bit afraid that they’re too deep!

SA2KNG · February 15, 2025, 4:22pm

this means that the dummy rigctld is’nt running, and that means doppler control will not work.

yeah, build issues.

when you say “build locally”, what does this mean exactly ?

you do know that all these have debian build scripts, so making packages is pretty straight forward and means you easily can uninstall etc.

yes, always run ntp or similar.

you can start the flowgraphs manually, they’re simple gnuradio flowgraphs with command line options.
modify this to suit your needs, it doesn’t work for all settings as-is.

lz1mzk · February 16, 2025, 8:32am

I would like to have it doppler corrected, but since this isn’t general failure, lets leave it for now.

For the record, after I updated SoapySDR I had to remove the gr-soapy directory inside gr/build directory in order to rebuild it. Obviously either cmake didn’t do it for me, or I don’t know how to instruct it to consider the updated SoapySDR. Now it works fine, or at leas doesn’t give a hint if it doesn’t.

I build and install in /usr only the most important drivers/libraries - the SDRPlay’s API, SoapySDR.
I strive to put SatNogs and GR into ~/.local
I added ~/.local/lib to ld.so.conf

Here are my current versions:

r-satnogs	fb0c154ddbfd53e4dbbace8fc1035d1e9cc6e320 3rd commit after 3.0.0.1
satnogs-client	5a9bbbc4d182dc7f48970ce69dab01b3b36bfcc0	again 3rd commit after 1.9.3
gnuradio	35b0664b9d758c813bac53f6874197f9f2abb4b8	v3.10.12.0-rc1
satnogs-flowgraphs	3fe619456747eb8332556698fb3d8a06847d6e79 commited 05. Feb. 2025

SDRPlay API 3.07.1 /a bit older/
SoapySDR	309335ec6a52eb712387ed025d705a3c0f7a1e24

My SDR device is sdrplay’s rspdx

Currently I can verify the flowgraph invoking the SDR device - there is /the typical/ CPU usage when the SDR device is listening. However I doesn’t fill the output files, nor I can stop the script with Ctrl+C. I have to stop it witk kill -9

$ satnogs_fm.py --soapy-rx-device="driver=sdrplay" --samp-rate-rx=2e6 --rx-freq=437349000 --file-path=snogs-rx --waterfall-file-path=snogs-wf --decoded-data-file-path=snogs-decoded --rigctl-host=127.0.0.1 --rigctl-port=4532 --antenna="Antenna A" --gain=0  --bw=600000 --enable-iq-dump=0 --udp-dump-port=57356
[INFO] devIdx: 0
[INFO] SerNo: 200104F042
[INFO] hwVer: 4
[INFO] rspDuoMode: 0
[INFO] tuner: 1
[INFO] rspDuoSampleFreq: 0.000000
rig_init called
initrigs4_dummy: _init called
rig_register called
rig_register: rig_register (1)
rig_register called
rig_register: rig_register (2)
rig_register called
rig_register: rig_register (4)
rig_register called
rig_register: rig_register (5)
rig_register called
rig_register: rig_register (6)
rig_init: rig does not have rx_range!!
netrigctl_init version 20210108.0
[INFO] Using format CF32.
network_open: hoststr=127.0.0.1, portstr=4532
network_open: failed to connect to 127.0.0.1:4532
thread_body_wrapper :error: ERROR thread[thread-per-block[3]: ]: caught unrecognized exception

And it stalls there, on the doppler_correction_cc(8) exception.

Do you think I’ve messed up with the versions? As you noted, maybe it will be good idea to switch to GR 3.8 and follow the versions you provided.

Thanks! I worry a bit for the strings "Antenna A", Settings Field. The env variable isn’t double-quoted and I think some of the manually invoked commands failed once or twice. I’m almost sure that the flowgraph didin’t put the correct RFGR=1,IFGR=30 since it warned with the following message

[WARNING] Not updating IFGR gain because AGC is enabled

Thanks!

SA2KNG · February 16, 2025, 9:27am

Good progress.

I don’t know how it behaves if it cannot connect to that, but it is very easy to solve, just run rigctld -T 127.0.0.1 -m 1 and it’ll be done. -client and -flowgraphs will connect to it and communicate the frequency adjustments.

lz1mzk · February 16, 2025, 8:45pm

@SA2KNG with your help now I have my first observation. Of course there’s no data since I’m still missing LNA for my antenna, but there is data uploaded to the server.

You can have a look: SatNOGS Network - Observation 11107125

I got this error:

$ satnogs-client
INFO     satnogsclient                   Starting status listener thread...
INFO     satnogsclient.scheduler.tasks   Registering `get_jobs` periodic task (60 sec. interval)
INFO     satnogsclient.scheduler.tasks   Registering `post_data` periodic task (180 sec. interval)
INFO     satnogsclient                   Configuration valid, satnogs-client started successfully.
INFO     satnogsclient.scheduler.tasks   Received job for observation 11106497, starting at 2025-02-16T17:08:49+00:00
INFO     satnogsclient.observer.observer Begin observation 11106497 ...
rig_init: rig does not have rx_range!!
network_open: hoststr=127.0.0.1, portstr=4532
INFO     satnogsclient.observer.observer Start gnuradio thread.
[INFO] devIdx: 0
[INFO] SerNo: 200104F042
[INFO] hwVer: 4
[INFO] rspDuoMode: 0
[INFO] tuner: 1
[INFO] rspDuoSampleFreq: 0.000000
[WARNING] Not updating IFGR gain because AGC is enabled
rig_init called
initrigs4_dummy: _init called
rig_register called
rig_register: rig_register (1)
rig_register called
rig_register: rig_register (2)
rig_register called
rig_register: rig_register (4)
rig_register called
rig_register: rig_register (5)
rig_register called
rig_register: rig_register (6)
rig_init: rig does not have rx_range!!
netrigctl_init version 20210108.0
pm_remez :error: insufficient extremals -- cannot continue
Warning: set ripple to 0.1100 dB. If this is a problem, adjust the attenuation or create your own filter taps.
[INFO] Using format CF32.
network_open: hoststr=127.0.0.1, portstr=4532
netrigctl_close: done status=Command completed successfully
netrigctl_close: done status=Command completed successfully
ERROR    satnogsclient.scheduler.tasks   Observation aborted due to an unhandled exception 'NoneType' object has no attribute 'trackstop'
Traceback (most recent call last):
  File "/home/mzk/.local/lib/python3.9/site-packages/satnogsclient/scheduler/tasks.py", line 60, in spawn_observer
    observer.observe()
  File "/home/mzk/.local/lib/python3.9/site-packages/satnogsclient/observer/observer.py", line 267, in observe
    self.poll_gnu_proc_status(flowgraph)
  File "/home/mzk/.local/lib/python3.9/site-packages/satnogsclient/observer/observer.py", line 363, in poll_gnu_proc_status
    self.tracker_rot.trackstop()
AttributeError: 'NoneType' object has no attribute 'trackstop'

And managed to solve it by changing SATNOGS_ROT_ENABLED to True (note that initially I set it to false - lowercase f) together with running rotctld --model=1.
I also set SATNOGS_ROT_MODEL=ROT_MODEL_DUMMY.

Follow my full output of the above mentioned observation:

$ satnogs-client
INFO     satnogsclient                   Starting status listener thread...
INFO     satnogsclient.scheduler.tasks   Registering `get_jobs` periodic task (60 sec. interval)
INFO     satnogsclient.scheduler.tasks   Registering `post_data` periodic task (180 sec. interval)
INFO     satnogsclient                   Configuration valid, satnogs-client started successfully.
INFO     satnogsclient.scheduler.tasks   Received job for observation 11107125, starting at 2025-02-16T20:06:54+00:00
INFO     satnogsclient.observer.observer Begin observation 11107125 ...
rot_init called
initrots4_dummy: _init called
rot_register (1)
rot_register (2)
dummy_rot_init called
rot_open called
dummy_rot_open called
rot_get_position called
dummy_rot_get_position called
rot_get_position: got az=0.00, el=0.00
rot_set_position called az=351.87 el=10.00
rot_set_position: south_zero=0 
rot_set_position: range problem az=351.87(min=-180.00,max=180.00), el=10.004099(min=0.00,max=90.000000)
rig_init: rig does not have rx_range!!
network_open: hoststr=127.0.0.1, portstr=4532
INFO     satnogsclient.observer.observer Start gnuradio thread.
[INFO] devIdx: 0
[INFO] SerNo: 200104F042
[INFO] hwVer: 4
[INFO] rspDuoMode: 0
[INFO] tuner: 1
[INFO] rspDuoSampleFreq: 0.000000
[WARNING] Not updating IFGR gain because AGC is enabled
rig_init called
initrigs4_dummy: _init called
rig_register called
rig_register: rig_register (1)
rig_register called
rig_register: rig_register (2)
rig_register called
rig_register: rig_register (4)
rig_register called
rig_register: rig_register (5)
rig_register called
rig_register: rig_register (6)
rig_init: rig does not have rx_range!!
netrigctl_init version 20210108.0
[INFO] Using format CF32.
network_open: hoststr=127.0.0.1, portstr=4532
netrigctl_close: done status=Command completed successfully
netrigctl_close: done status=Command completed successfully
INFO     satnogsclient.observer.observer Observation 11107125 finished.
INFO     satnogsclient.scheduler.tasks   Upload successful.
INFO     satnogsclient.scheduler.tasks   Upload successful.

I have some settings to do in order to ensure proper work of the receiver. I’ll try to list my questions:

Do I have to run rotctld also or maybe it was my fault using lowercase false in the variable?
Note the [WARNING] Not updating IFGR gain because AGC is enabled. My best observations are with manual gain controls of the RF gain and IF gain. I’m not sure how to correctly set the env variables to do so. I’m using SATNOGS_RF_GAIN=0 because I think I got some errors w/o using it (or maybe there weren’t? Were they with the test script? Should figure out).
The rspdx device supports bias. I’ll be happy to use it for the (future) LNA. I think there is a software option to enable or disable it.
Same question as 3. for built-in notch filter.

Oh, I just saw somewhere on the Internet these options: device_string = "driver=sdrplay,biasT_ctrl=1" so probably I can set these options together with the driver?

Thanks!

SA2KNG · February 17, 2025, 10:51am

Hi Kul,

That does not look good, not sure if it’s some new issue or old one you triggered there.
Look in the issues and submit one if you cannot find it there.

I’d say that it does show signal, it is a bit hard to see and differentiate from qrm, but the signal is very wide, usually over 100kHz. in this case, the thin horizontal lines would be LoRA transmissions. The flowgraphs does not handle lora at all, so the bw is only 48k

You should not need a dummy rotator at all. The flowgraphs does not care about this, only the client sends this and it is not a requirement. Let the variables be unset and -client will manage the defaults.
I quite dislike sdrplay and very reluctantly use mine, these settings and warning is a complete jungle and I just gave up.
many sdr’s do support enabling the bias-tee through device string or other settings, you have to experiment. in this case it might be in the soapy driver.
filtering in the sdr’s is also a jungle, I recommend experimenting with it in a custom gui flowgraph so you can see the results immediately and not rely on scheduling and waiting for the observations.

PE0SAT · February 17, 2025, 11:52am

I follow this conversation with great interest,

I also gave up on the SDRPlay, mainly because of the closed source part and there AGC behavior. But had a quick look what options are available to enable the BiasT. And as one can see, there is the biasT_ctrl option that should be a bool value. So If I am not mistaken that should be true or false and no 1 or 0.

SoapySDRUtil --probe="driver=sdrplay"

----------------------------------------------------
-- Peripheral summary
----------------------------------------------------
  Channels: 1 Rx, 0 Tx
  Timestamps: NO
  Other Settings:
     * RF Gain Select - RF Gain Select
       [key=rfgain_sel, default=4, type=string, options=(0, 1, 2, 3, 4, 5, 6, 7, 8)]
     * IQ Correction - IQ Correction Control
       [key=iqcorr_ctrl, default=true, type=bool]
     * AGC Setpoint - AGC Setpoint (dBfs)
       [key=agc_setpoint, default=-30, type=int, range=[-60, 0]]
     * ExtRef Enable - External Reference Control
       [key=extref_ctrl, default=true, type=bool]
     * BiasT Enable - BiasT Control
       [key=biasT_ctrl, default=true, type=bool]
     * RfNotch Enable - RF Notch Filter Control
       [key=rfnotch_ctrl, default=true, type=bool]

The to enable the BiasT the string should be: "driver=sdrplay,biasT_ctrl=true"

lz1mzk · February 17, 2025, 10:13pm

Dear Daniel,

The error disappeared once I started rotctld as per your hint with rigctld.
However the doppler corrections seems to be known issue with GR 3.10, but not with satnogs-client, but gr-satnogs. Just has been assigned: Doppler correction is not working right (#258) · Issues · librespacefoundation / SatNOGS / gr-satnogs · GitLab

I agree. I’ll give it a try and I’ll post my results here.

Sure, I’ll do it on my PC since the current setup is on a remote server.

I have spammed the production server a bit, my fault, but some signals can be seen there, with the metadata options. I tried today to “induce” short bursts of carrier frequency to understand what is going on. The doppler correction is already mentioned. I also found that the satellite frequency doesn’t equal the sdr’s frequency (I compensated it with 45 ppm drift, but I’ll have a look on the issues page, since the device has TCXO and doesn’t show drifts with its previous job as Web SDR.

@PE0SAT thank you for your interest! I found pretty much the same strings in Soapy’s code. Later I saw the default options as you cited. Both notch filters (fm+dab) have great impact on signal reception (on my FM WebSDR). Usually I slightly increase the gain values RFGR and IFGR.

For satellite reception however I need to boost these values. As you may know, they’re in reverse - RF is max at 0 and min at 27, and IF gain is max at 20 and min at 59.

HDR option is useful for HF, so I’ll keep it false.

agc_setpoint extreme values might be of interest. Actually since OpenWebRX successfully operates on these settings I believe it is only a matter of syntax and some peculiarities with the flowgraphs.

I will be a bit busy with my weekly tasks and I’ll be responding slowly. 73 to both of you!