Hello fellow SatNOGS rotators!
Have you had this error before, if so, how did you solve it? What is causing it?
satnogs-client[481]: rig_init: rig does not have rx_range!!
My setup file includes four reception ranges (antennas), and planned observations fall within them, so I don’t know why I am getting this error when the start time comes, regardless of which reception frequency should be used. I am using an Adalm Pluto, which more than covers all required frequencies, on an RPi3B+ with a SPID rotator. (And yes, I have done all the adaptation necessary to get these devices properly recognised on the USB ports, and they both check out OK).
Any good ideas very welcome!
That message is from rigctl and is benign, you can disregard it safely.
Sounds like a good station you have, multiband support and rotator is nice.
How do you solve the band switching btw ?
Thanks - it’s good to know that I can ignore this particular error message. I still can’t get observations to complete though … still more faultfinding to do.
Antenna switching is done with two remote coax relays (VHF/UHF and L-Band/S-Band) in boxes on the mast and one in-house relay (thin VHF/UHF coax / thick L/S-band coax) right before the Pluto, all controlled by a Pimoroni Automation Hat. I’ll take some photos when it all works!
Software is based on this thread:
and lightly modified for this environment.
Is it station station 2153?
What does the logs say ?
I have some experience with running the pluto. It can be quite annoying on a few details.
I did run a similar setup some time ago, one relay switching UHF/VHF, and enable mast preamp.
The worst was the pluto always stopped responding after a while. This seems to be due to the DC blocking of the usb ports from the RF section. Making sure the SMA is grounded at the same potential as the PSU is important. I feed it power separately from usb to host computer, both should share the same ground thou.
Regarding settings, ppm must be unset or 0, but you have probably already seen that 
Yes, well spotted, that’s me. My Pluto seems to work perfectly when not required to do so by the Satnogs client (i.e. through SDR#), but I get the error
network open: hoststr=127.0.0.1, portstr=4532
[ERROR] no device context found
with each attempted observation, and very quickly afterwards
satnogslicent.observer.observer - ERROR No waterfall data found
Feedback from the last two attempts: the problem seems to be with
... /soapy_swig.py", line 131, in make satnogs satnogs-client[13785]:
return soapy_swig.source_make(nchan, device, ... etc.
and then
.../satnogs_fsk.py", line 97, in __init__ satnogs satnogs-client[13785]: self.soapy_source_0_0 = soapy.source( ... etc.
To my untrained eyes, this looks like the Pluto hasn’t been identified as the receiver … any ideas?
Here’s the current configuration - does anything strike you as obviously wrong?
------------[ copy here ]------------
{
"versions": {
"satnogs-client": "1.8.1",
"satnogs-client-ansible": "202209101521",
"satnogs-flowgraphs": "1.4-1",
"gr-satnogs": "2.3.4.0-1",
"gr-soapy": "2.1.3.1-1",
"gnuradio": "3.8.2.0-14",
"satnogs-config": "0.13.2"
},
"state": {
"is-applied": false,
"pending-tags": [
"satnogs_client_config"
]
},
"system": {
"date": "2023-04-24T15:34:43.370952+00:00",
"distribution": {
"DESCRIPTION": "Raspbian GNU/Linux 11 (bullseye)",
"RELEASE": "11",
"CODENAME": "bullseye",
"ID": "Raspbian"
},
"pending-updates": false,
"platform": {
"system": "Linux",
"node": "satnogs",
"release": "6.1.21-v7+",
"version": "#1642 SMP Mon Apr 3 17:20:52 BST 2023",
"machine": "armv7l"
},
"memory": {
"total": 966750208,
"available": 779681792,
"percent": 19.4,
"used": 126369792,
"free": 339128320,
"active": 216199168,
"inactive": 336715776,
"buffers": 38649856,
"cached": 462602240,
"shared": 794624,
"slab": 45715456
},
"disk": {
"total": 15244124160,
"used": 5868576768,
"free": 8701329408,
"percent": 40.3
}
},
"configuration": {
"hamlib_utils_rot_enabled": true,
"hamlib_utils_rot_opts": "-m 901 -s 600 -r /dev/SNROT -C post_write_delay=300",
"satnogs_antenna": "A_BALANCED",
"satnogs_api_token": "[redacted]",
"satnogs_log_level": "ERROR",
"satnogs_post_observation_script": "/home/david/scripts/unwind.py --home_azimuth=180.0 --home_elevation=10.0 --station_id=2153",
"satnogs_ppm_error": "0",
"satnogs_pre_observation_script": "/home/david/scripts/antswitch.py -f {{FREQ}}",
"satnogs_rf_gain": "50",
"satnogs_rot_baud": "600",
"satnogs_rot_enabled": true,
"satnogs_rot_model": "ROT_MODEL_SPID_ROT2PROG",
"satnogs_rot_port": "/dev/SNROT",
"satnogs_rot_threshold": "2",
"satnogs_rx_bandwidth": "2e6",
"satnogs_rx_samp_rate": "2e6",
"satnogs_scheduler_log_level": "ERROR",
"satnogs_soapy_rx_device": "driver=plutosdr,hostname=192.168.2.1",
"satnogs_station_elev": "283",
"satnogs_station_id": "2153",
"satnogs_station_lat": "50.3884",
"satnogs_station_lon": "8.2852",
"satnogs_waterfall_max_value": "-40"
}
}
------------[ copy end ]-------------
This is doppler control and looks ok.
I would suggest raising the log level to INFO, this way it is easier to follow what’s going on.
Regarding the pre obs script, it needs to be executable etc, otherwise obs will fail, looks to be ok.
A check for the pluto, I have seen different support in the distributions for it, some does not bring up the usb ethernet interface for some reason, just ping it and see with ping 192.168.2.1.
Does it show up in the probe ? SoapySDRUtil --probe="driver=plutosdr,hostname=192.168.2.1
Do you have it plugged in with two usb cables ?
Is the SMA or coax relay connected to the same ground as the Rpi ?
Thanks for the suggestions.
Yes, the script has been set to executable. Pluto is pingable: 0% packet loss.
SDRUtil probe delivers:
######################################################
Soapy SDR – the SDR abstraction library
######################################################
Probe device driver=plutosdr,hostname=192.168.2.1
[INFO] Opening PlutoSDR #0 192.168.2.1...
----------------------------------------------------
-- Device identification
----------------------------------------------------
driver=PlutoSDR
hardware=ADALM-PLUTO
ad9361-phy,model=ad9364
ad9361-phy,xo_correction=39999633
backend_version=0.24 (git tag: v0.24)
fw_version=v0.35
hw_model=Analog Devices PlutoSDR Rev.B (Z7010-AD9364)
hw_model_variant=1
hw_serial=1044739659930004efff27004816280bbe
ip,ip-addr=192.168.2.1
library_version=0.24 (git tag: 2945479)
local,kernel=5.10.0-98231-g9dfba10b795d
uri=ip:192.168.2.1
----------------------------------------------------
-- Peripheral summary
----------------------------------------------------
Channels: 1 Rx, 1 Tx
Timestamps: NO
Sensors: xadc_temp0, xadc_voltage0, xadc_voltage1, xadc_voltage2, xadc_voltage3, xadc_voltage4, xadc_voltage5, xadc_voltage6, xadc_voltage7, xadc_voltage8, adm1177_current0, adm1177_voltage0, ad9361-phy_temp0, ad9361-phy_voltage2
* xadc_temp0: 39.619128 C
* xadc_voltage0 (vccint): 1.000488 V
* xadc_voltage1 (vccaux): 1.787842 V
* xadc_voltage2 (vccbram): 1.013672 V
* xadc_voltage3 (vccpint): 1.009277 V
* xadc_voltage4 (vccpaux): 1.792236 V
* xadc_voltage5 (vccoddr): 1.343262 V
* xadc_voltage6 (vrefp): 1.240723 V
* xadc_voltage7 (vrefn): -0.007324 V
* xadc_voltage8: 0.897705 V
* adm1177_current0:
* adm1177_voltage0:
* ad9361-phy_temp0: 22.807000 C
* ad9361-phy_voltage2: 0.604090 V
----------------------------------------------------
-- RX Channel 0
----------------------------------------------------
Full-duplex: YES
Supports AGC: YES
Stream formats: CS8, CS12, CS16, CF32
Native format: CS16 [full-scale=2048]
Antennas: A_BALANCED
Full gain range: [0, 73] dB
PGA gain range: [0, 73] dB
Full freq range: [70, 6000] MHz
RF freq range: [70, 6000] MHz
Sample rates: [0.260417, 61.44] MSps
Filter bandwidths: 0.2, 1, 2, 3, 4, 6, 7, 8, 9, 10 MHz
----------------------------------------------------
-- TX Channel 0
----------------------------------------------------
Full-duplex: YES
Supports AGC: NO
Stream formats: CS8, CS12, CS16, CF32
Native format: CS16 [full-scale=32768]
Antennas: A
Full gain range: [0, 89] dB
PGA gain range: [0, 89] dB
Full freq range: [70, 6000] MHz
RF freq range: [70, 6000] MHz
Sample rates: [0.260417, 61.44] MSps
Filter bandwidths: 0.2, 1, 2, 3, 4, 6, 7, 8, 9, 10 MHz
So nothing strikes me there as wrong. I am only using one USB cable directly from the RPi - do you think it could be a power problem, in particular because I have the Pimoroni Automation hat on top as well?
I did read your info about grounding, although it’s not a problem here because everything is powered by one chunky lab power supply (5V, 12V & 15V) so there can be no lack of ground nor a ground loop. All three coax relays are of the same type. I’ll try some more observations and see what errors are thrown up now …
P.S. I’ve since taken the “-f” out of the pre observation script command, which now passes the obs frequency across correctly to the script.
My experience with one usb cable to a regular computer almost always results in the pluto disappearing after some hours. Is it still responding to ping after a failed obs ? Anyway, just for fault findings sake I still think double usb is a good test.
Try measuring resistance between the microusb inlets and the sma, iirc there is some inductor on the inside with a pretty high resistance. Good for separation of noise, but bad in a environment where there will be too big disturbances between the two and making the device crash, or possibly worse. That’s why I’m suggesting a separate ground here. If it has low resistance then there should not be a problem.
One thing I note here is the “is-applied: false”, this isn’t good ? Applying means writing the config that the client uses, if there’s settings changed in ansible they need to be applied to the conf.
Could you paste more log around the failing flowgraph ? like 10-20 lines or so.