configuring rotator

[mbruski]

So I having a problem connecting G-S to my SatNOGS v3.1 rotator. I have setup a controller device under Hardware settings but do not see how to tell G-S that the rotator speeks EASYCOMIII protocol at 9600 baud on /dev/ttyACM0 (i'm using an RPi5 for my server). I've hunted through DeepWiki but don't see anything specific about conveying parameters for rotctld. I've tried launching rotctld separately on the localhost but I'm not seeing any interaction with G-S in my terminal when I try to connect with the rotator. G-S simply reports there was an error connecting to the rotator. There must be something in setup that I'm missing. Could someone enlighten me please?

[Kxrma47]

G-S does not configure the serial protocol directly; its controller is a SATROTCTL client and connects to host:port (default 127.0.0.1:4533) (source). Start rotctld with the EASYCOMM model and serial settings, then point G-S at that TCP endpoint:

rotctl -l | grep -i easycomm
rotctld -m <listed-model-number> -r /dev/ttyACM0 -s 9600 -T 0.0.0.0 -t 4533 -vvvv

Test first with printf 'p\nq\n' | nc 127.0.0.1 4533. If G-S runs in Docker, 127.0.0.1 is the container; use the Pi/host-gateway address and expose port 4533. Only the machine running rotctld needs access to /dev/ttyACM0.

[mbruski]

Thank you very much for that response. So I launch rotctld as I normally do when using gpredict: $ rotctld -m 204 -r /dev/ttyACM0 -s 9600 -T 0.0.0.0 -t 4533 -vvvvv rotctld, Hamlib 4.6.2 2025-02-09T21:03:50Z SHA=870364 64-bit Report bugs to ***@***.***> rot_init called initrots4_easycomm called rot_register (201) rot_register (202) rot_register (204) easycomm_rot_init called rot_open called serial_open: /dev/ttyACM0 serial_setup: tcgetattr serial_setup: cfmakeraw serial_setup: cfsetispeed=9600,0x000d serial_setup: cfsetospeed=9600,0x000d serial_setup: data_bits=8 serial_setup: stopbits=1 serial_setup: parity=0 serial_setup: Handshake=None serial_setup: tcsetattr TCSANOW ser_set_dtr: DTR=0 ser_set_rts: RTS=0 Opened rot model 204, 'EasycommIII' Backend version: 2022312180, Status: Stable So far so good. But when I test, rotctld reports an error: $ printf 'p\nq\n' | nc 127.0.0.1 4533 Connection opened from 127.0.0.1:57292 rotctl(d): p '' '' '' '' rot_get_position called easycomm_rot_get_position called easycomm_transaction called: AZ write_block(): TX 3 bytes 0000 41 5a 0a AZ. easycomm_transaction read_string failed with status -5:Unknown error -5 easycomm_rot_get_position got error: -5 rotctl_parse: NETROTCTL_RET -5 Connection closed from 127.0.0.1:57292 I should note this is my first time using HamLib on RPi5 Trixie. I have used HamLib/rotctld successfully on RPi4 BULLSEYE and other AMD64 versions of Ubuntu to control this same rotator. but that is an earlier version of HamLib. any further suggestions you or anyone else might have are welcome. Message ID: ***@***.***>

[mbruski]

On a whim this morning, I fired up an RPi4 with BULLSEYE and connected rotator to that machine. Also enabled rotctld as I have in the past. Back on G-S host, I configured the rotator to use the RPi4's hostname and port 4533. Press 'Connect' and it is working. Now I'm confused as to why rotctld throws errors when running locally on my G-S host?

[Kxrma47]

That result isolates the problem below G-S: the RPi5 rotctld opens the serial device and transmits AZ\n, but the Easycomm backend receives no terminated reply, so -5 is a serial read failure rather than a G-S TCP/configuration problem.

With G-S and rotctld stopped, compare both Pis:

rotctld -V
rotctl -l | grep -i easycomm
ls -l /dev/ttyACM0
fuser /dev/ttyACM0

Then test the same model directly on the Pi 5:

rotctl -m <same-model-id-as-Pi4> -r /dev/ttyACM0 -s 9600 -vvvv
# at the rotctl prompt:
p

If that fails only on Trixie, check that the user is in dialout, stop ModemManager if it has claimed the ACM port, and run the same Hamlib version/container on both Pis to confirm a version regression. The Easycomm backend's query/read path is here: https://github.com/Hamlib/Hamlib/blob/master/rotators/easycomm/easycomm.c

[mbruski]

I'll give the 'AZ EL' and 'AZ' command a go tomorrow a report what I get. As for updating controller firmware, all my update was going to do was increase the baud rate and add support for an LCD panel to read position data at the rotator. I suppose I need to spend some time looking at easycomm protocol spec to see what needs fixing.

[mbruski]

So I ran 'screen /dev/ttyACM0 9600' on both RPi this morning and got the same results from both of them.

AZ provokes no response
AZ EL yields
AZ0.0 EL0.0

Where does that leave me?

I plan to review the protocol spec for EASYCOMMIII later today and compare to my controller code. I also want to take a look at yapiolibs/hamlib-rotctl-easycomm-parser for some clues as well

[mbruski]

Looking at Hamlib issues #1931. Another user is getting timeout errors using GS232 protocol. He found that DTR was 0 by default in rotctl when it apparently should be 1. He fixed it thusly:

rotctl -m 602 -r /dev/ttyACM0 -vvvvvv --set-conf=dtr_state=ON

I'm about to try this on my setup on the RPi5. Fingers crossed!

[mbruski]

No joy with that...

eport bugs to hamlib-developer@lists.sourceforge.net

rot_init called
initrots4_easycomm called
rot_register (201)
rot_register (202)
rot_register (204)
easycomm_rot_init called
rot_token_lookup called lookup dtr_state
rot_token_lookup called lookup dtr_state
rot_set_conf called
rot_set_conf: dtr_state='ON'
frontrot_set_conf called
rot_token_lookup called lookup timeout
rot_token_lookup called lookup timeout
rot_set_conf called
rot_set_conf: timeout='500'
frontrot_set_conf called
rot_token_lookup called lookup retry
rot_token_lookup called lookup retry
rot_set_conf called
rot_set_conf: retry='0'
frontrot_set_conf called
rot_open called
serial_open: /dev/ttyACM0
serial_setup: tcgetattr
serial_setup: cfmakeraw
serial_setup: cfsetispeed=9600,0x000d
serial_setup: cfsetospeed=9600,0x000d
serial_setup: data_bits=8
serial_setup: stopbits=1
serial_setup: parity=0
serial_setup: Handshake=None
serial_setup: tcsetattr TCSANOW
read_string_generic called, rxmax=4095 direct=1, expected_len=1
ser_set_dtr: DTR=1
ser_set_rts: RTS=0
Opened rot model 204, 'EasycommIII'
Backend version: 2022312180, Status: Stable
Connection opened from 127.0.0.1:35308
rotctl(d): p '' '' '' ''
rot_get_position called
easycomm_rot_get_position called
easycomm_transaction called: AZ

read_string_generic called, rxmax=4095 direct=1, expected_len=1
write_block(): TX 3 bytes
0000 41 5a 0a AZ.
read_string_generic called, rxmax=32 direct=1, expected_len=1
read_string_generic(): Timed out 0.500 seconds after 0 chars, direct=1
easycomm_transaction read_string failed with status -5:Unknown error -5
easycomm_rot_get_position got error: -5
rotctl_parse: NETROTCTL_RET -5
Connection closed from 127.0.0.1:35308
Connection opened from 127.0.0.1:59546
rotctl(d): p '' '' '' ''
rot_get_position called
easycomm_rot_get_position called
easycomm_transaction called: AZ

read_string_generic called, rxmax=4095 direct=1, expected_len=1
write_block(): TX 3 bytes
0000 41 5a 0a AZ.
read_string_generic called, rxmax=32 direct=1, expected_len=1
read_string_generic(): Timed out 0.500 seconds after 0 chars, direct=1
easycomm_transaction read_string failed with status -5:Unknown error -5
easycomm_rot_get_position got error: -5
rotctl_parse: NETROTCTL_RET -5
Connection closed from 127.0.0.1:59546

[sgoudelis]

What raises my suspicion is this:

AZ provokes no response

perhaps this is the cause of the timeout, perhaps the version of hamlib with the version of firmware installed are not exactly compatible, I would focus a bit there

[sgoudelis]

I am reading here that -5 is a timeout if I am not mistaken, and I see you are using 9600 baud, is that correct? I see here the default is 19200. Mike what was the command you used on the rpi4 ?

[mbruski]

The command I use on both PIs is:
rotctld -m 204 -r /dev/ttyACM0 -s 9600 -T 0.0.0.0 -t 4533 -C timeout=500 -C retry=0 -vvvvvv &

I flashed my Uno with the firmware recommended by the libre community (I would need to dig around on another machine to find the source). But where I too thought it was using a higher baud rate I found out it was actually 9600. I have been thinking about changing it but until I get everything working I'm reluctant to reflash it at this point.

[Kxrma47]

Yes, -5 is -RIG_ETIMEOUT: Hamlib sent AZ\n and received no newline-terminated response. One nuance is that the Easycomm backend declares 9600–19200 as its supported range, so 9600 is valid; the controller firmware still has to be configured for the same rate. Comparing the exact RPi4 command is therefore the best next check. If it also used -s 9600, baud mismatch becomes unlikely and the remaining difference is the Pi5/Trixie serial stack or Hamlib version. If the RPi4 used 19200, stop rotctld on the Pi5 and retry once with -s 19200. Source references: RIG_ETIMEOUT = 5 and the Easycomm read/rate configuration.

[mbruski]

Being kinda new with this docker/container magic I not sure whats doable here but is there a way for may to 'tweak' my local container image by removing this newer version of Hamlib, and replacing it with a copy of Hamlib 4.0 that I built from source?
Maybe 'docker rmi ', install Hamlib 4.0 locally, than 'docker run ...' or is docker going to pull a new copy of the library to run in the container and ignore the one I install on the local host?

[sgoudelis]

Replacing hamlib inside the ground-station docker image you mean ?

[mbruski]

Yes, on my local copy. Or does having a local copy installed before 'docker run' override docker so it doesn't install the newer version? This docker stuff is all magic to me.

[sgoudelis]

Ground-station currently does NOT include hamlib the library, it only "talks" hamlib language, in the early versions of ground-station I included and used hamlib in it, but the issue is that hamlib uses GIL a lot in python due to the python bindings they offer, and it interfered with the rest of the backend in way that made it impossible to include it, the up side is that it is easy to simply "talk" hamlib. I do not think there is where the issue, if you got it to work the Rpi4 there is some software incompatibility somewhere in the path outside of ground-station. I am considering supporting the satnogs controller, I think I have an Uno somewhere, I might be able to hack the firmware with the help of an LLM to make a dummy rotator. This will take days, even weeks to develop.

[mbruski]

Ok. I understand now.

A few minutes ago, I built Hamlib v4.6.0 from source and tested it on the RPi5 and it worked perfectly. v4.6.2 is the problem.
I just checked and discovered v4.6.2 was a dependency of Gpredict which I had installed a few weeks before trying G-S. Trying to figure out how to remove v4.6.2. Its like a klingon. After removing gpredict and autoremove dependencies... hamlib is still hanging around. It might just be easier for me to start with a fresh install and try all over again.

Anyway, thank you for all your help with this. I am so sorry about all the time we lost trying to find the problem.

[mbruski]

Yes! HAPPY, HAPPY, HAPPY! there was a funky version of libhamlib2t64 installed with qsstv and fldigi. All gone now and v4.6.0 is installed and G-S and my rotator are now working fine. Time to throw one back.

[sgoudelis]

Nice!

[mbruski]

I guess this isn't quite over just yet.

Today I setup my rotator on the Dell Optiplex because I wanted to capture both LRPT and HRPT (2-dongles, different antennas) from M-2 3 and I was concerned the RPi5 wasn't up to the task. The Dell is setup with Hamlib-4.6 like my RPi4 was last week. Launched GS on the Dell and setup hardware. But when trying to connect with the rotator, it is throwing errors again.

$ rotctld -m 204 -r /dev/ttyACM0 -s 9600 -T 0.0.0.0 -t 4533 -C timeout=500 -C retry=0 -vvvvvv
rotctld, Hamlib 4.6 from indeterminate source revision. 64-bit
Report bugs to hamlib-developer@lists.sourceforge.net

rot_init called
initrots4_easycomm called
rot_register (201)
aj9x@GroundStation:~$ rot_register (202)
rot_register (204)
easycomm_rot_init called
rot_token_lookup called lookup timeout
rot_token_lookup called lookup timeout
rot_set_conf called
rot_set_conf: timeout='500'
frontrot_set_conf called
rot_token_lookup called lookup retry
rot_token_lookup called lookup retry
rot_set_conf called
rot_set_conf: retry='0'
frontrot_set_conf called
rot_open called
serial_open: /dev/ttyACM0
serial_setup: tcgetattr
serial_setup: cfmakeraw
serial_setup: cfsetispeed=9600,0x2580
serial_setup: cfsetospeed=9600,0x2580
serial_setup: data_bits=8
serial_setup: stopbits=1
serial_setup: parity=0
serial_setup: Handshake=None
serial_setup: tcsetattr TCSANOW
read_string_generic called, rxmax=4095 direct=1, expected_len=1
ser_set_dtr: DTR=0
ser_set_rts: RTS=0
Opened rot model 204, 'EasycommIII'
Backend version: 2022312180, Status: Stable
Connection opened from 172.17.0.2:37274
rotctl(d): p '' '' '' ''
rot_get_position called
easycomm_rot_get_position called
easycomm_transaction called: AZ

read_string_generic called, rxmax=4095 direct=1, expected_len=1
write_block(): TX 3 bytes
0000 41 5a 0a AZ.
read_string_generic called, rxmax=32 direct=1, expected_len=1
read_string_generic(): Timed out 0.500 seconds after 0 chars, direct=1
easycomm_transaction read_string failed with status -5:Unknown error -5
easycomm_rot_get_position got error: -5
rotctl_parse: NETROTCTL_RET -5
Connection closed from 172.17.0.2:37274

I tried hamlib-4.6.1 and hamlib-4.6.5 with the same results. I'm running out of ideas here.
Sames results on USB-2 and USB-3 ports. Could it be it's expecting something else like '0d' for EOL? Grasping at straws now.

My Host setup:
Dell Optiplex 7080SFF i7-10th gen, 32GB RAM, Lubuntu 26.04 LTS, ground-station:0.8.9

[sgoudelis]

Minicom is your friend. Try doing the following, You can test the controller directly with Minicom.

First stop rotctld, then confirm nothing is using the port:

fuser /dev/ttyACM0

Install and start Minicom:

sudo apt install minicom
minicom -o -D /dev/ttyACM0 -b 9600 -8

Press Ctrl-A, then O, select Serial port setup, and verify:

Speed: 9600
Data/parity/stop: 8N1
Hardware flow control: No
Software flow control: No

Press Ctrl-A, then E to enable local echo. The Arduino may reset when the port opens, so wait a few seconds before testing.

Enter these commands separately:

AZ
EL
AZ EL

Please report the response to each command. I expect the older firmware to behave like this:

AZ       → no response
EL       → no response
AZ EL    → AZ0.0 EL0.0

If so, that confirms the problem: Hamlib 4.6.x queries AZ and EL separately, while the older controller firmware only answers the combined AZ EL query. Minicom sends carriage return when Enter is pressed, and the firmware accepts both carriage return and newline, so this also rules out the proposed 0d line-ending issue.

Exit Minicom with Ctrl-A, then X.

At the end you will know if this is a serial connection issue or a hamlib compatibility issue