SPID rotator setup

SatNOGS Software
1

Before I go bald from tearing my hair out, can someone please help me with the settings to get the SatNOGS client to control a SPID SPX running through a ROT2PROG controller and a USB cable to a RPi3B+. Yohan Hadji had this same problem in 2019 but I don’t see the solution … And yes, I have already sorted out the changing USB port by using a symlink :wink:

When booting, the Pi fails to start the rotctld server - it starts and stops multiple times.
Running systemctl status rotctld delivers:

rotctld.service - rotctld server
Loaded: loaded (/etc/systemd/system/rotctld.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Mon 2021-11-15 18:17:07 UTC; 40min ago
Process: 456 ExecStart=/usr/bin/rotctld $ROT_OPTS (code=exited, status=2)
Main PID: 456 (code=exited, status=2)

Nov 15 18:17:07 SatNOGS systemd[1]: rotctld.service: Failed with result ‘exit-code’.
Nov 15 18:17:07 SatNOGS systemd[1]: rotctld.service: Service RestartSec=100ms expired, scheduling restart.
Nov 15 18:17:07 SatNOGS systemd[1]: rotctld.service: Scheduled restart job, restart counter is at 5.
Nov 15 18:17:07 SatNOGS systemd[1]: Stopped rotctld server.
Nov 15 18:17:07 SatNOGS systemd[1]: rotctld.service: Start request repeated too quickly.
Nov 15 18:17:07 SatNOGS systemd[1]: rotctld.service: Failed with result ‘exit-code’.
Nov 15 18:17:07 SatNOGS systemd[1]: Failed to start rotctld server.

In the Rotator settings of SatNOGS-setup I have:
[ROT-MODEL-SPID-ROT2PROG]
baud rate [600]
rotctld port [localhost:4533]
etc.

Any ideas why the rotctld service won’t start? Thanks for your thoughts!

2

@blackeye Try starting rotctld from the command line first and fiddle with the ‘timeout’ and ‘retry’ settings. Example:


 rotctld -m 202 -r  /dev/ttyACM0  -s 9600 -t 4533 -C timeout=500 -C retry=0 -vvvvvvvv
3

I had issues where the RPi was not able to power the USB-Serial device within the Rot2Prog. You can confirm this by looking at the output of ‘dmesg’ on the RPi when the device is inserted.

I ended up disconnecting the 5V line from the USB cable going to the RPi, and adding a bodge wire to the Rot2Prog to power the FTDI (?) adaptor within the rot2prog from an existing 5V rail.

4

Thanks guys, sadly neither suggestion was the solution. Using dmesg showed a ‘normal’ usb connection of the ROT2PROG and entering the command to manually start rotctld did not start the service. systemctl status rotctld shows “code = exited, status=2”. Does anyone know what this actually means and where I have to change something to get rotctld running from boot?

[Update] Some progress: manually starting rotctld with a post_write_delay of 300 now makes the rotator move to the starting position of a scheduled observation, but it doesn’t track … [sigh]

5

Just adding a bit more on my own setup, this is what i’m running on boot to start rotctld:

rotctld -m 901 -r /dev/rotator -s 600 -vvvvv -t 4533 -C az_resolution=2,el_resolution=2,post_write_delay=300

Note that this is for a 0.5 degree step RF HamDesign SPX-02, hence the az/el resolution settings.

6

Thanks Mark, I have the same model, which is now moving reliably to the start position for a pass, but not tracking at all. In satnogs-setup, what do you have under Advanced > Rotator > SATNOGS-ROT-MODEL … NETROTCTL or ROT_MODEL_SPID_ROT2PROG ?
And under SATNOGS-ROT-PORT do you have localhost:4533 ?

7

I have the following settings:

        "satnogs_rot_ip": "localhost",
        "satnogs_rot_model": "ROT_MODEL_NETROTCTL",
        "satnogs_rot_port": "localhost:4533",
        "satnogs_rot_threshold": "5",

I don’t think the satnogs_rot_ip setting does anything.

I’m starting rotctld separately via a line in /etc/rc.local (probably not the best way to to do it):

su - pi -c "screen -dm -S rotator /home/pi/start_rotator.sh"

Then the start_rotator script:

$ cat start_rotator.sh
#!/usr/bin/env bash
rotctld -m 901 -r /dev/rotator -s 600 -vvvvv -t 4533 -C az_resolution=2,el_resolution=2,post_write_delay=300

This lets me use screen to check on the status of the rotator by running: screen -r rotator

I have a udev rule setup to add in a symlink from whatever usb device the rotator ends up on to /dev/rotator:

$ cat /etc/udev/rules.d/99-rotator.rules
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A906JCDM", SYMLINK+="rotator"
8

Thanks for the very helpful information Mark. I don’t even have an IP setting in my satnogs client … but I have checked and/or altered all the others (with my own device’s serial number). At least now rotctld starts without an error, and the rotator does move to the start position. Now I just need to find out why it doesn’t track the satellite at all.
The ‘screen’ command doesn’t work for me: I get an error message saying:
“There is no screen to be resumed matching rotator.” Any ideas why?

9

re: moves to start position

At least now rotctld starts without an error, and the rotator does move to the start position. Now I just need to find out why it doesn’t track the satellite at all.

Sounds like it is still timing out after the initial movement to the AOS position and the rotctl settings still need tweaking. What are the rotctl and/or satnogs (DEBUG) logs showing now?

What if you try manually moving to the AOS position ahead of time using satnogs-unwinder

  unwind.py --home_azimuth=30 --home_elevation 15

This way the first call to move for a scheduled observation will not be to move into position but rather to move along the tracking path. See if the result is different.

10

I’ve scoured through the daemon log file this morning and found this:

RuntimeError: SoapySDR::Device::make() no match

which suggests to me that the client didn’t set up the SDR (an Adalm Pluto) properly, had some problems with satnogs_bpsk.py and cancelled the event. I have a 200-line (and already edited!) log file if anyone is really interested … :wink:

I’ll work on fixing this first … and I’m open to any further suggestions - thanks!

1 Like
11

There are several others to have reported problems with the Pluto, stopping at the make(). See this thread:

However, I have stumbled on one stations that uses the Pluto successfully:
https://network.satnogs.org/stations/2415/

Maybe @mraptakis can assist you?

12

re: rotator not tracking

The rotator should still track despite the SDR Device::make() error. The RF chain (rigctl) and rotctld daemon operate independently of each other AFAIK.

Maybe run rotctld from a termnial and not rely on satnogs-client starting it as a background daemon so maybe you can see more info on what’s going on. I still recommend manually moving to the AOS position ahead of time to see if that helps it successfully track a scheduled observation.

13

Hello! Glad to help!
First of all, I guess you followed the instructions in the pothosware/SoapyPlutoSDR repository, right?
If so, you should know that you do not need to install SoapySDR as it comes pre-installed on SatNOGS image.
If the installation is done correctly, then running the command SoapySDRUtil --info, on the computer running the client, you should see an output similar to the following:

SoapySDRUtil --info
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Lib Version: v0.7.2-1
API Version: v0.7.1
ABI Version: v0.7
Install root: /usr
Search path:  /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7
Search path:  /usr/local/lib/arm-linux-gnueabihf/SoapySDR/modules0.7                (missing)
Search path:  /usr/local/lib/SoapySDR/modules0.7
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7/libHackRFSupport.so  (0.3.3)
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7/libLMS7Support.so    (20.01.0)
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7/libRedPitaya.so      (0.1.1)
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7/libairspySupport.so  (0.1.2)
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7/libaudioSupport.so   (0.1.1)
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7/libbladeRFSupport.so (0.4.1)
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7/libosmosdrSupport.so (0.2.5)
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7/libremoteSupport.so  (0.5.2)
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7/librtlsdrSupport.so  (0.3.1)
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7/libuhdSupport.so     (0.3.6)
Module found: /usr/local/lib/SoapySDR/modules0.7/libPlutoSDRSupport.so              (0.2.1-38a34f6)
Available factories... airspy, audio, bladerf, hackrf, lime, osmosdr, plutosdr, redpitaya, remote, rtlsdr, uhd
Available converters...
 -  CF32 -> [CF32, CS16, CS8, CU16, CU8]
 -  CS16 -> [CF32, CS16, CS8, CU16, CU8]
 -  CS32 -> [CS32]
 -   CS8 -> [CF32, CS16, CS8, CU16, CU8]
 -  CU16 -> [CF32, CS16, CS8]
 -   CU8 -> [CF32, CS16, CS8]
 -   F32 -> [F32, S16, S8, U16, U8]
 -   S16 -> [F32, S16, S8, U16, U8]
 -   S32 -> [S32]
 -    S8 -> [F32, S16, S8, U16, U8]
 -   U16 -> [F32, S16, S8]
 -    U8 -> [F32, S16, S8]

Point to the line that says: Module found: /usr/local/lib/SoapySDR/modules0.7/libPlutoSDRSupport.so (0.2.1-38a34f6)

1 Like
14

Hi Mixalis, yes, the
SoapySDRUtil --info
command does give that result. Was your answer complete, or did something get cut off the bottom. What’s next?

15

Yes… Practically, in this way you confirm that the installation of PlutoSDR modules has been done correctly! It is also quite important that the version of SoapySDRUtil does not change compared to the one already in the SatNOGS image

16

OK, I think I’ll reload the SatNOGS image to be safe - too many settings have been ‘tweaked’ over the last few weeks - and then I will follow your instructions above. I’ll report what happens … :anguished:

17

Yeah… A “clean” image is the best solution! Let me know if you need anything