Rotctl With South Centered Rotor-EZ Hy-Gain Controller?

[n9gxa]

Hello,

I have a working Rotor-EZ controller for a Hy-Gain HAM II rotator. I would like to use the South-centered direction scale, but am having trouble configuring rotctld to accommodate this. I tried using the offset option of -180 which displays the correct direction in the logging program that I am using, but I get a "Limited exceeded" error if I try to move the antenna.

Could someone point me to information that explains the proper setup?

TNX
73 - Paul - N9GXA

[n9gxa]

I found the set-conf south_zero option. I find this to work when set with rotctl. It does not seem to work when set with rotctld. Using Backend version: 20230328.0. Rotator # 401. adding to command line is "--set-conf=south_zero=1".

Both rotctl and rotctld initialize the same with (in part):

...
rotorez_rot_init called
rot_token_lookup called lookup south_zero
rot_token_lookup called lookup south_zero
rot_set_conf called
rot_set_conf: south_zero='1'
...

If I use rotctl directly and request the rotator's position, I get correct results:

Rotator command: p rotctl_parse: input_line: p rot_get_position called rotorez_rot_get_position called rotorez_send_priv_cmd called write_block(): TX 4 bytes 0000 41 49 31 3b AI1; read_block_generic called, direct=1 read_block_generic(): RX 4 bytes, direct=1 0000 3b 30 30 30 ;000 rotorez_rot_get_position: "000" after conversion = 0.0 rotorez_rot_get_position: azimuth = 0.0 deg; elevation = 0.0 deg rot_get_position: got az=0.00, el=0.00 rot_get_position: south adj to az=180.00 Azimuth: 180.00 Elevation: 0.00

If I initialize with rotctld, start a rotctl -m 2 and request position, I get:

Rotator command: p rotctl_parse: input_line: p rot_get_position called netrotctl_get_position called network_flush called write_block(): TX 2 bytes 0000 70 0a p. read_string_generic(): RX 7 characters, direct=1 0000 31 38 30 2e 30 30 0a 180.00. read_string_generic(): RX 5 characters, direct=1 0000 30 2e 30 30 0a 0.00. rot_get_position: got az=180.00, el=0.00 rot_get_position: south adj to az=0.00 Azimuth: 0.00 Elevation: 0.00

Am I doing something wrong or can this be fixed if it is a bug?

TNX
73 - Paul - N9GXA

[N0NB]

Are you passing the south_zero parameter to rigctld when starting it?

[n9gxa]

Yes, thank you. For rotctld, I use:
rotctld -m 401 --set-conf=south_zero=1 -r /dev/ttyS2 -t 4533 -s 4800

[N0NB]

I think the next step is to get the trace output from both commands by adding -vvvvv to each command line and then posting the text output to see where they differ.

[n9gxa]

Yeah, that is what I did for the above info. The rotator is now sitting about center scale at 182°.

This first one is running rotctl directly connected to -m 401 and reports correctly:

rotctl -m 401 -r /dev/ttyS2 --set-conf=south_zero=1 -vvvvv
rotctl Hamlib 4.6.2 2025-02-09T21:03:50Z SHA=870364 64-bit
Report bugs to <hamlib-developer@lists.sourceforge.net>

rot_init called
initrots4_rotorez called
rot_register (401)
rot_register (402)
rot_register (403)
rot_register (404)
rot_register (405)
rot_register (406)
rotorez_rot_init called
rot_token_lookup called lookup south_zero
rot_token_lookup called lookup south_zero
rot_set_conf called
rot_set_conf: south_zero='1'
frontrot_set_conf called
rot_open called
serial_open: /dev/ttyS2
serial_setup: tcgetattr
serial_setup: cfmakeraw
serial_setup: cfsetispeed=4800,0x000c
serial_setup: cfsetospeed=4800,0x000c
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 401, 'Rotor-EZ'
Backend version: 20230328.0, Status: Stable

Rotator command: p
rotctl_parse: input_line: p
rot_get_position called
rotorez_rot_get_position called
rotorez_send_priv_cmd called
write_block(): TX 4 bytes
0000    41 49 31 3b                                         AI1;            
read_block_generic called, direct=1
read_block_generic(): RX 4 bytes, direct=1
0000    3b 30 30 32                                         ;002            
rotorez_rot_get_position: "002" after conversion = 2.0
rotorez_rot_get_position: azimuth = 2.0 deg; elevation = 0.0 deg
rot_get_position: got az=2.00, el=0.00
rot_get_position: south adj to az=182.00
Azimuth: 182.00
Elevation: 0.00

Rotator command:

[n9gxa]

This is starting rotctld. It seems like the reported position is "corrected" twice:

rotctld -m 401 --set-conf=south_zero=1 -r /dev/ttyS2 -t 4533 -s 4800 -vvvvv
rotctld, Hamlib 4.6.2 2025-02-09T21:03:50Z SHA=870364 64-bit
Report bugs to <hamlib-developer@lists.sourceforge.net>

rot_init called
initrots4_rotorez called
rot_register (401)
rot_register (402)
rot_register (403)
rot_register (404)
rot_register (405)
rot_register (406)
rotorez_rot_init called
rot_token_lookup called lookup south_zero
rot_token_lookup called lookup south_zero
rot_set_conf called
rot_set_conf: south_zero='1'
frontrot_set_conf called
rot_open called
serial_open: /dev/ttyS2
serial_setup: tcgetattr
serial_setup: cfmakeraw
serial_setup: cfsetispeed=4800,0x000c
serial_setup: cfsetospeed=4800,0x000c
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 401, 'Rotor-EZ'
Backend version: 20230328.0, Status: Stable

...and then I run rotctl pointing to -m 2 and requesting a position:

rotctl -m 2 -vvvvv
rotctl Hamlib 4.6.2 2025-02-09T21:03:50Z SHA=870364 64-bit
Report bugs to <hamlib-developer@lists.sourceforge.net>

rot_init called
initrots4_dummy: _init called
rot_register (1)
rot_register (2)
rot_register (3)
rot_register (4)
rot_open called
rot_open: using network address 127.0.0.1:4533:TCP
network_open: TCP connect
network_open: hoststr=127.0.0.1, portstr=4533
network_open: client port=58091
netrotctl_open called
network_flush called
write_block(): TX 12 bytes
0000    5c 64 75 6d 70 5f 73 74 61 74 65 0a                 \dump_state.    
read_string_generic(): RX 2 characters, direct=1
0000    31 0a                                               1.              
read_string_generic(): RX 4 characters, direct=1
0000    34 30 31 0a                                         401.            
read_string_generic(): RX 16 characters, direct=1
0000    6d 69 6e 5f 61 7a 3d 30 2e 30 30 30 30 30 30 0a     min_az=0.000000.
read_string_generic(): RX 18 characters, direct=1
0000    6d 61 78 5f 61 7a 3d 33 36 30 2e 30 30 30 30 30     max_az=360.00000
0010    30 0a                                               0.              
read_string_generic(): RX 16 characters, direct=1
0000    6d 69 6e 5f 65 6c 3d 30 2e 30 30 30 30 30 30 0a     min_el=0.000000.
read_string_generic(): RX 16 characters, direct=1
0000    6d 61 78 5f 65 6c 3d 30 2e 30 30 30 30 30 30 0a     max_el=0.000000.
read_string_generic(): RX 13 characters, direct=1
0000    73 6f 75 74 68 5f 7a 65 72 6f 3d 31 0a              south_zero=1.   
read_string_generic(): RX 15 characters, direct=1
0000    72 6f 74 5f 74 79 70 65 3d 4f 74 68 65 72 0a        rot_type=Other. 
read_string_generic(): RX 5 characters, direct=1
0000    64 6f 6e 65 0a                                      done.           
Opened rot model 2, 'NET rotctl'
Backend version: 20221110.0, Status: Stable

Rotator command: p
rotctl_parse: input_line: p
rot_get_position called
netrotctl_get_position called
network_flush called
write_block(): TX 2 bytes
0000    70 0a                                               p.              
read_string_generic(): RX 7 characters, direct=1
0000    31 38 32 2e 30 30 0a                                182.00.         
read_string_generic(): RX 5 characters, direct=1
0000    30 2e 30 30 0a                                      0.00.           
rot_get_position: got az=182.00, el=0.00
rot_get_position: south adj to az=2.00
Azimuth: 2.00
Elevation: 0.00

Rotator command: 

And this is the accompaning rotctld trace after running above rotctl:

connection opened from 127.0.0.1:60386
rotctl(d): � '' '' '' ''
rotctl(d): p '' '' '' ''
rot_get_position called
rotorez_rot_get_position called
rotorez_send_priv_cmd called
write_block(): TX 4 bytes
0000    41 49 31 3b                                         AI1;            
read_block_generic called, direct=1
read_block_generic(): RX 4 bytes, direct=1
0000    3b 30 30 32                                         ;002            
rotorez_rot_get_position: "002" after conversion = 2.0
rotorez_rot_get_position: azimuth = 2.0 deg; elevation = 0.0 deg
rot_get_position: got az=2.00, el=0.00
rot_get_position: south adj to az=182.00

[n9gxa]

Attempting to file a request to hamlib-developer@users.sourceforge.net

This returns a failure notice because the address could not be found.

[N0NB]

Try hamlib-developer@lists.sourceforge.net

[N0NB]

Looping in @GeoBaltz and @dforsi.

Most definitely the correction is being applied twice and this is due to rotctld and rotctl sharing the same code paths internally. This is probably a case where rotctl should not apply this correction when -m 2 is passed or only when --set-conf=south_zero=1 is explicitly passed to it (I think I prefer this approach).

[GeoBaltz]

I'd say that the virtual rotator provided by rotctld is north-centered - let it do the conversion to the actual hardware, as it is doing the controlling. You could make things much more complicated by having rotctld configure both the read and virtual connections, but I don't think it's worth the effort ;-).

…

On 7/10/26 6:15 AM, Nate Bargmann wrote: Looping in @GeoBaltz <https://github.com/GeoBaltz> and @dforsi <https://github.com/dforsi>. Most definitely the correction is being applied twice and this is due to |rotctld| and |rotctl| sharing the same code paths internally. This is probably a case where |rotctl| should not apply this correction when |-m 2| is passed or only when |--set-conf=south_zero=1| is explicitly passed to it (I think I prefer this approach). — Reply to this email directly, view it on GitHub <#2090?email_source=notifications&email_token=AC36NNG4WYLIGYYL6CCEHXL5EC65JA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZVHE2TGMZSUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17595332>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC36NNHB4MFFYZOW3TACGN35EC65JAVCNFSNUABHKJSXA33TNF2G64TZHM4TSNRSGMYTSMJ3IRUXGY3VONZWS33OHMYTAMZXGQ4DGNNBOYBA>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AC36NNEQ5SSKAE5JXJDPJLD5EC65JA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZVHE2TGMZSUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/AC36NNC5FZQH5WLUSWX2N4L5EC65JA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZVHE2TGMZSUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[N0NB]

Maybe I'm being dense, George, but I don't quite follow.

As rotctld has clients other than rotctl then it needs to be the process to apply the south_zero correction whether that be through a command-line option or network command.

Conversely, rotctl should only apply a correction if it specifically was given the --set-conf=south_zero=1 command line option (this would likely imply that it is not a rotctld client but perhaps that needs to be confirmed with the -m option).

So far I've not traced the code path but since the correction is being applied twice, my assumption is that rotctl is reading the configuration setting from the state structure and applying it again, thus negating what rotctld has done.

Am I close to the right track?

BTW, replace all occurrences in my posts regarding rig with rot. Too much time spent in that device sector, I suspect.

[n9gxa]

If it matters (I doubt it), while running rotctld with the south_zero=1 and getting incorrect reading from rotctl, I quit rotctl and restarted it also with the south_zero=1 (hoping to adjust yet one more time to correct), but no relief. A hack, I know, but I was curious.

[dforsi]

There may be a language barriere here, but when I read
south_zero: "Adjust azimuth 180 degrees for south oriented rotators"
I understand that the software is going to add 180 to the value passed by the user, so that it doesn't make sens to pass that option to both rigctld and rigctl they will both add 180, which IIUC it's the current behavior.

George wrote:

I'd say that the virtual rotator provided by rotctld is north-centered -
let it do the conversion to the actual hardware, as it is doing the
controlling.

it make sense to me.

[GeoBaltz]

Did a little reading in netrotctl.c and yes, the first thing it does is send \dump_caps to rotctld, which sends the value of south_zero back to the app.

I think the way to look at this is: all values of the azimuth must be the real direction toward the guy on the other end. The only piece of the control chain that should worry about any offset on the antenna is the part that actually talks directly to the rotator. It might even be preferable to move all the offset code out of the common path and into the rotator drivers themselves.

The offset may still be needed by the app for its own purposes, and the cw/ccw movement limits might need to be proxied or adjusted; haven't looked at this at all.

[n9gxa]

Hey, how about I simply go back to North-centered scale? It's not that big of a deal. I thought it may be more efficient to use a South-centered setup. I don't know that it is worth all this.

Thanks for looking into this.

73 - Paul - N9GXA