I would like to control my Sacrtrac Rotor by Skyroof.
For that I have to to start rotctld.exe -m 202 -r COM6 -s 9600 -T 127.0.0.1 -t 4533 and got an error "Invalid configuration"
:
rot_init called
initrots4_easycomm called
rot_register (201)
rot_register (202)
rot_register (204)
set_conf: called
rot_open called
serial_open: COM6
serial_setup: tcgetattr
serial_setup: cfsetispeed=9600,0x000d
serial_setup: cfsetospeed=9600,0x000d
serial_setup: data_bits=8
serial_setup: parity=0
serial_setup: Handshake=None
serial_setup: tcsetattr TCSANOW
serial_setup: tcsetattr failed: No error
Invalid configuration
When I omit "-s 9600" in the syntax, I'll get no error, but it seems that there will be no communication between rotctld and SkyRoof...
COM6 is the USB2Serial Controller (USB-Serial CH340) for the Sactrac-Rotor.
By using Putty I can control the Rotor. The Rotoc-Controller shouls work with Hamlib and
The Rotor-Controller should work with Hamlib EasycommII Model.
Portsettings for COM6:
Bits per second: 9600 (should be for Sarctrac)
Data bits: 8
Paryty: none
Stop Bits: 1
Flow control: none
Fifo Buffers are on
SerEnum is not enabled (default)
ModemHandShake is not disabled (default)
Any idea about the problem?
Greets
Achim
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for replying, Nate.
CH340 is a USB Serial to WiFi-Adapter shipped with theSarctrac.
It connects the Rotor via COM-Interface by WiFi.
I can control the Rotor this way by Ham Radio Deluxe and by Putty - so it basicly works.
Using commandline
C:\Program Files\hamlib-w64-4.5.5\bin\rotctld.exe -m 202 -r COM6 -s 9600 -T 127.0.0.1 -t 4533 creates the error above.
Now changed to 19200 in the Config for COM6 and used -s 19200 and the commandline returns no error - I think I am a step ahead... But Rotor dosn't move at all..
Now tested:
"C:\Program Files\hamlib-w64-4.5.5\bin\rotctl.exe" -m 202 -r COM6 -s 19200 -t 4533
Got no error!
Rotator command: P
Azimuth: 30
Elevation: 30
Nothng happpens, so I'll check the current Position that should be at 0, 0
rig_flush: called for serial device
read_string_generic called, rxmax=4095 direct=1, expected_len=1
tcflush
write_block(): TX 14 bytes, method=2
rot_get_position called
easycomm_rot_get_position called
easycomm_transaction called: AZ EL
rig_flush: called for serial device
read_string_generic called, rxmax=4095 direct=1, expected_len=1
tcflush
write_block(): TX 7 bytes, method=2
read_string_generic called, rxmax=32 direct=1, expected_len=1
read_string_generic(): Timed out 0.481 seconds after 2 chars, direct=1
easycomm_transaction read_string failed with status -5
easycomm_rot_get_position got error: -5
Communication timed out
Maybe hamlib won't accept 9600 and Sarctrac won't accept 19200?
But what I saw at other COM-Devices that it soesn't matter, what speed was selected it always worked...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Using commandline "C:\Program Files\hamlib-w64-4.5.5\bin\rotctld.exe" -m 202 -r COM6 -s 9600 -T 127.0.0.1 -t 4533 creates the error above.
Now changed to 19200 in the Config for COM6 and used -s 19200 and the commandline returns no error - I think I am a step ahead... But Rotor dosn't move at all..
Now tested: "C:\Program Files\hamlib-w64-4.5.5\bin\rotctl.exe" -m 202 -r COM6 -s 19200 -t 4533
Got no error!
Did you kill the rotctld process before starting rotctl? If not, you have two programs in contention for the same serial port.
Make sure you have no rotctld process(es) running in Task Manager (or whatever they call it now). Then try:
As I see it, unless the serial rate in the rotator controller has been changed, then 9600 is the rate that should be used. If 19200 works, then I suspect the controller setting has been changed and you'll need to use 19200 throughout.
If that succeeds, then exit rotctl and start rotctld:
Years back I learned that MS Windows doesn't seem to like localhost and works with 127.0.0.1. Perhaps that has changed.
Bear in mind that rotctld is using the serial port, and then rotctl is using the network loopback address to communicate to it. This should probably be explained more clearly in the manual page.
Finally, regarding serial speeds. Unless otherwise told, e.g. the -s option, Hamlib will select the fastest serial rate defined in the device's capability structure. Here is that part of the capabilities for rotator model 202:
I started rotctld in a commandline box
I started rotctl in another commandline box
If I paste P 20 20 into rotctl I can see rotctld is receiving data but rotor stays quite.
I think there is a problem with the speed of the COM-Port.
In the Documentation of Sarctrac I noticed it needs 9600.
starting rotctld -s 9600 will produce an error (invalid configuration)
So I cheked what happens with different connection speed using Putty.
Puty with 9600 works, I can controll Sarctrac
Puty with 19200 produce an error 31 (a connected device ist noch working)
It seems, that Sarctrac just accept 9600.
Cause rotctld -s 9600 will produce an error (invalid configuration), I think rotctld will not accept 9600
- It doesn't matter, if I set the Com-Port to 9600 or 19200 in the Devicemanager...
I checked that there just one process of rotctld and rotctl ist running and no other Program that may use the Com-Port. Putty is also closed when using the rot-commands.
What do you think about my thoughts, that rotctld has problems with speed of 9600?
Maybe I also should look for a Serialport-Monitor to see what happens when I use Putty @9600 and rotctld @19.200 ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I would like to control my Sacrtrac Rotor by Skyroof.
For that I have to to start rotctld.exe -m 202 -r COM6 -s 9600 -T 127.0.0.1 -t 4533 and got an error "Invalid configuration"
:
rot_init called
initrots4_easycomm called
rot_register (201)
rot_register (202)
rot_register (204)
set_conf: called
rot_open called
serial_open: COM6
serial_setup: tcgetattr
serial_setup: cfsetispeed=9600,0x000d
serial_setup: cfsetospeed=9600,0x000d
serial_setup: data_bits=8
serial_setup: parity=0
serial_setup: Handshake=None
serial_setup: tcsetattr TCSANOW
serial_setup: tcsetattr failed: No error
Invalid configuration
When I omit "-s 9600" in the syntax, I'll get no error, but it seems that there will be no communication between rotctld and SkyRoof...
COM6 is the USB2Serial Controller (USB-Serial CH340) for the Sactrac-Rotor.
By using Putty I can control the Rotor. The Rotoc-Controller shouls work with Hamlib and
The Rotor-Controller should work with Hamlib EasycommII Model.
Portsettings for COM6:
Bits per second: 9600 (should be for Sarctrac)
Data bits: 8
Paryty: none
Stop Bits: 1
Flow control: none
Fifo Buffers are on
SerEnum is not enabled (default)
ModemHandShake is not disabled (default)
Any idea about the problem?
Greets
Achim
Trying to learn a bit about this device.
First, I see SkyRoof appears to be a software application: https://ve3nea.github.io/SkyRoof/index.html Does it not support EasyCommII natively?
The SARCTRAC is descrribed here: https://sarcnet.org/sarctrac.html That page notes that the EasyCommII protocol is supported.
As for
-s 9600
failing, I see that the model 202 capabilities shows a maximum data rate of 19200, so that option is required.Let's back up a bit. Can you run the interactive utility
rotctl
and get the same error? I'm guessing you will.Finally, I presume the CH340 is built into the SARCTRAC?
Thanks for replying, Nate.
CH340 is a USB Serial to WiFi-Adapter shipped with theSarctrac.
It connects the Rotor via COM-Interface by WiFi.
I can control the Rotor this way by Ham Radio Deluxe and by Putty - so it basicly works.
Using commandline
C:\Program Files\hamlib-w64-4.5.5\bin\rotctld.exe -m 202 -r COM6 -s 9600 -T 127.0.0.1 -t 4533 creates the error above.
Now changed to 19200 in the Config for COM6 and used -s 19200 and the commandline returns no error - I think I am a step ahead... But Rotor dosn't move at all..
Now tested:
"C:\Program Files\hamlib-w64-4.5.5\bin\rotctl.exe" -m 202 -r COM6 -s 19200 -t 4533
Got no error!
Rotator command: P
Azimuth: 30
Elevation: 30
Nothng happpens, so I'll check the current Position that should be at 0, 0
Rotator command: p
get_pos: error = easycomm_rot_set_position called: 30.000000 30.000000
easycomm_transaction called: AZ30.0 EL30.0
rig_flush: called for serial device
read_string_generic called, rxmax=4095 direct=1, expected_len=1
tcflush
write_block(): TX 14 bytes, method=2
rot_get_position called
easycomm_rot_get_position called
easycomm_transaction called: AZ EL
rig_flush: called for serial device
read_string_generic called, rxmax=4095 direct=1, expected_len=1
tcflush
write_block(): TX 7 bytes, method=2
read_string_generic called, rxmax=32 direct=1, expected_len=1
read_string_generic(): Timed out 0.481 seconds after 2 chars, direct=1
easycomm_transaction read_string failed with status -5
easycomm_rot_get_position got error: -5
Communication timed out
At https://www.sarcnet.org/sarctrac-mk3.html they wrote:
Rotator emulation - Serial protocol: AMSAT EasyCommII with position feedback - 9600/N/8/1.
Maybe hamlib won't accept 9600 and Sarctrac won't accept 19200?
But what I saw at other COM-Devices that it soesn't matter, what speed was selected it always worked...
Did you kill the
rotctld
process before startingrotctl
? If not, you have two programs in contention for the same serial port.Make sure you have no
rotctld
process(es) running in Task Manager (or whatever they call it now). Then try:"C:\Program Files\hamlib-w64-4.5.5\bin\rotctl.exe" -m 202 -r COM6 -s 9600
As I see it, unless the serial rate in the rotator controller has been changed, then 9600 is the rate that should be used. If 19200 works, then I suspect the controller setting has been changed and you'll need to use 19200 throughout.
If that succeeds, then exit
rotctl
and startrotctld
:"C:\Program Files\hamlib-w64-4.5.5\bin\rotctld.exe" -m 202 -r COM6 -s 9600 -T 127.0.0.1 -t 4533
To have
rotctl
communicate with it, you'll use a different syntax than you used above:"C:\Program Files\hamlib-w64-4.5.5\bin\rotctl.exe" -m 2 -r 127.0.0.1:4533
You can find an example at:
https://n0nb.users.sourceforge.net/man1/rotctl.1.html#EXAMPLES
Years back I learned that MS Windows doesn't seem to like
localhost
and works with127.0.0.1
. Perhaps that has changed.Bear in mind that
rotctld
is using the serial port, and thenrotctl
is using the network loopback address to communicate to it. This should probably be explained more clearly in the manual page.Finally, regarding serial speeds. Unless otherwise told, e.g. the
-s
option, Hamlib will select the fastest serial rate defined in the device's capability structure. Here is that part of the capabilities for rotator model 202:Hope this helps.
Last edit: Nate Bargmann 2025-08-04
Thanks for the advice.
Some hours later without success...
I started rotctld in a commandline box
I started rotctl in another commandline box
If I paste P 20 20 into rotctl I can see rotctld is receiving data but rotor stays quite.
I think there is a problem with the speed of the COM-Port.
In the Documentation of Sarctrac I noticed it needs 9600.
starting rotctld -s 9600 will produce an error (invalid configuration)
So I cheked what happens with different connection speed using Putty.
Puty with 9600 works, I can controll Sarctrac
Puty with 19200 produce an error 31 (a connected device ist noch working)
It seems, that Sarctrac just accept 9600.
Cause rotctld -s 9600 will produce an error (invalid configuration), I think rotctld will not accept 9600
- It doesn't matter, if I set the Com-Port to 9600 or 19200 in the Devicemanager...
I checked that there just one process of rotctld and rotctl ist running and no other Program that may use the Com-Port. Putty is also closed when using the rot-commands.
What do you think about my thoughts, that rotctld has problems with speed of 9600?
Maybe I also should look for a Serialport-Monitor to see what happens when I use Putty @9600 and rotctld @19.200 ...
Did you try
rotctl.exe
stand alone as I suggested? Make sure anyrotctld.exe
processes are killed first.Let's simplify this as much as possible. Also, please add
-vvvvv
to the command line.