Alfa Spid RAS with Green Heron RT-21 Az-El Controller

I set up ground station #2733 (above) with a Yaesu rotator and Yaesu USB controller. It worked well with satnogs-client for a few months including the latest upgrade. The Yaesu products are readily available in the USA (from DX Engineering in my case). But the AZ rotator failed. The rotator isn’t designed for continuous use and I had been scheduling on cron pretty much non-stop, likely causing early failure.

A bill of materials and notes on this setup are available here:

Since the Yaesu isn’t rated for continuous operation, a different rotator was selected. After some digging and suggestions in matrix, I decided to get an Alfa Spid RAS with Green Heron RT-21 Az-El Controller.

I received it in ~two weeks, with the rotator coming from Canada and the controller shipped from the USA. I presume that Green Heron used Alfa Radio Ltd for a drop shipping distributor:

One thing that is immediately clear is the Alfa Spid RAS is a major upgrade from the Yaesu. The the two Yaesu rotator parts are 4.5kg, compared to 14.4kg for the Alfa. It looks and feels much more heavy duty than the Yaesu.

The Green Heron RT-21 Az-El Controller doesn’t work out-of-the-box with the satnogs-client software. There is RT-21 support in Hamlib for 10+ years now with device 405 (-m 405), but it only supports either Az or El, but not both. The reason for this, is the RT-21 Az-El controller uses one USB port for each. For control, two USB cables are used for two devices, such as /dev/ttyUSB0 and /dev/ttyUSB1. Hamlib only support(ed) one USB device for control.

At one point, greenctld, a libre driver, was written for the RT-21 Az-El controller. It listens on a TCP port and functions similar to rotctld. It is in Python 2 though, which is obsolete.

With cluebats from matrix I was able to port greenctld to Python 3 and it is working:

I don’t quite see the best way to connect this greenctld to satnogs-client.

After all that, I saw that the latest versions of Hamlib now include control with two USB ports, for use with RT-21 Az-El controller. The command line option in rotctl looks like this:

  -R, --rot-file2=DEVICE        set device of the 2nd rotator controller to operate on

The version of Hamlib that supports a second rotator controller isn’t used by satnogs-client, which has an older version of Hamlib.

Edit: Currently satnogs-client uses Debian Bullseye’s Hamlib version 4.0-7. The dual USB control was added to Hamlib 4.3, with additional “features”, such as stop currenly in Hamlib HEAD, but not tagged yet.

At this point, it seems my options are:

  • Configure satnogs-client to use greenctld instead of rotctld.
  • Patch satnogs-client to use recent Hamlib (no changes to Hamlib).
  • Patch Hamlib with backported dual USB patches (no changes to satnogs-client).
  • Other.

If anyone has this particular setup or has suggestions which would be the best way to go, it would be appreciated, thanks!

3 Likes

If greenctld is listening on the usual TCP port (4533) with the usual rotctld protocol, then you can just setup SatNOGS to use RIG_MODE_NETROTCTL, and set the rotator port to localhost:4533

From my config:

        "satnogs_rot_model": "ROT_MODEL_NETROTCTL",
        "satnogs_rot_port": "localhost:4533",

You will need to startup greenctld separately.

1 Like

I set my config like this:

SATNOGS_ROT_ENABLED=True
SATNOGS_ROT_MODEL="ROT_MODEL_NETROTCTL"
SATNOGS_ROT_PORT="192.168.108.84:4533"

It was able to connect to the port with satnogs-client and get the current location:

2022-10-03T18:18:09.248481174Z satnogsclient.observer.observer - INFO - Start rotctrl thread.
2022-10-03T18:18:09.248962701Z satnogsclient.observer.worker - INFO - Tracking initiated
2022-10-03T18:18:09.250085826Z rot_init called
2022-10-03T18:18:09.250152677Z initrots4_dummy: _init called
2022-10-03T18:18:09.250192398Z rot_register (1)
2022-10-03T18:18:09.250210453Z rot_register (2)
2022-10-03T18:18:09.250597316Z rot_open called
2022-10-03T18:18:09.250635148Z rot_open: using network address 192.168.108.84:4533
2022-10-03T18:18:09.250670833Z network_open called
2022-10-03T18:18:09.250688666Z network_open version 1.0
2022-10-03T18:18:09.250704295Z network_open: hoststr=192.168.108.84, portstr=4533
2022-10-03T18:18:09.252861770Z netrotctl_open called
2022-10-03T18:18:09.252938787Z rig_flush: called for network device
2022-10-03T18:18:09.252957101Z network_flush called
2022-10-03T18:18:09.252972378Z write_block called
2022-10-03T18:18:09.253247021Z write_block(): TX 12 bytes
2022-10-03T18:18:09.253298520Z 0000    5c 64 75 6d 70 5f 73 74 61 74 65 0a                 \dump_state.    
2022-10-03T18:18:09.253324019Z read_string called, rxmax=64
2022-10-03T18:18:09.253500423Z read_string(): RX 7 characters
2022-10-03T18:18:09.253540385Z 0000    52 50 52 54 20 30 0a                                RPRT 0.         
2022-10-03T18:18:09.254732713Z rot_get_position called
2022-10-03T18:18:09.254799989Z netrotctl_get_position called
2022-10-03T18:18:09.254816989Z rig_flush: called for network device
2022-10-03T18:18:09.254832655Z network_flush called
2022-10-03T18:18:09.254847266Z write_block called
2022-10-03T18:18:09.254962856Z write_block(): TX 2 bytes
2022-10-03T18:18:09.255006707Z 0000    70 0a                                               p.              
2022-10-03T18:18:09.255123409Z read_string called, rxmax=64
2022-10-03T18:18:09.296609083Z read_string(): RX 10 characters
2022-10-03T18:18:09.296714154Z 0000    35 35 2e 30 30 30 30 30 30 0a                       55.000000.      
2022-10-03T18:18:09.296739339Z read_string called, rxmax=64
2022-10-03T18:18:09.297633839Z read_string(): RX 10 characters
2022-10-03T18:18:09.297702060Z 0000    35 30 2e 30 30 30 30 30 30 0a                       50.000000.      
2022-10-03T18:18:09.297721134Z rot_get_position: got az=55.00, el=50.00
2022-10-03T18:18:09.298011758Z satnogsclient.observer.observer - INFO - Start rigctrl thread.
2022-10-03T18:18:09.298860870Z satnogsclient.observer.worker - INFO - Tracking initiated
2022-10-03T18:18:09.298981201Z rot_set_position called az=344.39 el=10.36
2022-10-03T18:18:09.299008941Z rot_set_position: south_zero=0 
2022-10-03T18:18:09.299028144Z rot_set_position: range problem az=344.39(min=-180.00,max=180.00), el=10.355809(min=0.00,max=90.000000)
2022-10-03T18:18:09.300270360Z rig_init: rig does not have rx_range!!
2022-10-03T18:18:09.300598020Z network_open: hoststr=127.0.0.1, portstr=4532
2022-10-03T18:18:10.329971968Z satnogsclient.observer.observer - INFO - Start gnuradio thread.
2022-10-03T18:18:11.613928919Z Found Rafael Micro R820T tuner
2022-10-03T18:18:11.799883614Z [INFO] Opening Generic RTL2832U OEM :: 00000001...
2022-10-03T18:18:12.055964142Z Found Rafael Micro R820T tuner
2022-10-03T18:18:12.280082912Z [R82XX] PLL not locked!
2022-10-03T18:18:12.321099836Z [INFO] Using format CF32.
2022-10-03T18:18:49.901216719Z Allocating 15 zero-copy buffers

It may be failing on the line rig_init: rig does not have rx_range!!.

I can see in the greenctld logs that satnogs-client is connecting and getting the repeated position updates:

<-- 'p'
<== 55,50
--> 55,50

But it never actually moves the rotator. Getting closer.

Thanks!

I got satnogs-client working to send the rotator command by applying the rotator.py patchlet mentioned in this thread:

I also added the modified rotator.py to my greenctld repo.

Now the RT-21 won’t go past 90 El, 91 Az, but I think that is a configuration setting in the Green Heron itself.

I flipped USB devices (whoops) and it’s working! :slight_smile:

1 Like

@jebba Nicely done, impressive rig, very awesome! :+1: :satellite: