Rotator Specific Notes
This section details various notes on rotor backends regarding backend or hardware limitations and bugs noted when using the backend to control a given piece of hardware.
EA4TX Controller Notes
From Chris Bryant, G3WIE, regarding the ars backend
The EA4TX ARS-RCI rotator controller is supported from hamlib 1.2.11 onwards.
The ARS-RCI connects to a parallel port on a PC. This MUST be a real parallel port. USB-to-parallel ports do not contain the necessary hardware and will not work in any operating system.
Variants of the ARS-RCI
Support is provided for the following Second Edition (-SE) variants:
- ARS-RCI-SE Azimuth and Elevation (hamlib number 1101) with 8 or 10 bit ADC
- ARS-RCI-SE Azimuth only (hamlib number 1102) with 8 or 10 bit ADC
The original RCI variant is not supported. This is an older variant which accepts a daughter-board with the two elevation relays. The -SE variant is a single board which contains all five relays.
12 bit ADC are not supported.
Rotctl (and rotctld) capability
Suggested command line for rotctl or rotctld
Command syntax for rotctl or rotctld:
rotctl -r dddd -m 1101 -C min_az=xxx -C max_az=yyy -C min_el=aaa -C max_el=bbb
rotctl -r dddd -m 1102 -C min_az=xxx -C max_az=yy y
Where xxx, yyy, aaa, bbb should be chosen to match the limits of rotation or elevation for your rotators, and dddd is the device name for the parallel port connected to the ARS (note this may default correctly).
For further information, use the shell command man rotctl or man rotctld as appropriate.
Supported commands
The following rotctl rotator commands are supported:
p - get position
P - set position
M - move
S - stop
Timeout
The P command includes a timeout set to 5 seconds by default. If the rotator has not completed the requested movement within this timeout, the operation is aborted.
Brake relay
The brake relay is energized whenever a command is issued that results in a movement in the azimuth direction. At the end of the command, the relay is de-energized. The brake relay is not used for elevation.
Calibration
The easiest way I have found to calibrate the ARS-RCI is as follows:
- Manually set the rotator fully anti-clockwise
- Start rotctl
- Repeatedly issue the p command
- Observe the minimum reading and adjust the zero trimpot until the output from the p command JUST gives the correct reading (-180, 0 etc). Approach the correct reading from above.
- Manually set the rotator fully clockwise
- Repeatedly issue the p command
- Observe the maximum reading and adjust the gain trimpot until the output from the p command gives the correct reading (360, 180 etc). Approach the correct reading from below.
Repeat the the procedure for elevation.
Bugs, restrictions, and workarounds
Default parameters not correctly used
The default parameters for minimum and maximum limits for azimuth and elevation are not always correctly used. To ensure you get the ranges that match your situation, specify these parameters on the rotctl or rotctld command line (as per the suggested command lines above). You can use negative values, for example -180 to 180 for azimuth for a rotator with its end-stop at South.
Hamlib is unable to tell if the ARS-RCI is connected or has power
The parallel interface for the ARS-RCI is write-only so there is no possibility to directly detect the ARS-RCI is connected or working. It is possible to infer this situation as a rotctl p command will generally return azimuth or elevation values which are at the minimum or maximum limit. A P command will result in a timeout.
RotorEZ
From Nate Bargmann, N0NB, regarding the Idiom Press rotorez backend.
Quirks, known bugs, and other notes
In this document I'll try to describe the behavior of the Idiom Press Rotor-EZ and RotorCard interfaces as well as the HyGain DCU-1/DCU-1X control units with Hamlib. For background information see rotorez/rotorez.txt in the Hamlib source distribution.
The Idiom Press interfaces are the most capable of the units supported by this backend and all available commands are supported by these units at this time. The HyGain control units only support a subset of the command set involving rotor positioning.
This document is organized by Hamlib function calls and documents observed behavior with each call.
rot_set_position
- Fractional values passed for azimuth are dropped. i.e. 180.6 becomes 180 while a value greater than 359.4999 is converted to 0 for DCU1/DCU-1X compatibility.
- Allowed range for azimuth is 0 to 360.
- Values passed for elevation are ignored. The protocol only supports azimuthal positioning
rot_get_position
- Position reading is returned in whole degrees from 0 to 359.
- Not supported by DCU-1/DCU-1X.
rotorez_rot_stop
- Causes immediate cessation of rotor positioning.
- Not supported by DCU-1/DCU-1X.
rot_set_conf
- Accepts one of E, e, J, j, O, o, S, and s (see rotorez/rotorez.txt) in *val.
- The value in token is not used by the backend and may be safely set to TOK_BACKEND_NONE.
- Not supported by DCU-1/DCU-1X.
BUGS
Please report all bugs to hamlib-developer@users.sourceforge.net
SPID Rot2Prog
From Norvald H. Ryeng, LA6YKA, regarding the spid backend.
Quirks
The Rot1Prog and Rot2Prog controllers are slow to process commands. This may lead to timing issues if your software outputs commands too quickly. Especially Rot2Prog may suffer if auto sensing of position sensor granularity is used (this is the default). Symptoms may be that the rotator controller ignores a command to rotate to the given position, even if debugging info shows that the command is sent to the controller. If run in verbose mode, rotctl may output something like this:
$ rotctl -m 901 -vvvv -r /dev/ttyS0
[...]
Rotator command: P 0 0
spid_rot_set_position called: 0.000000 0.000000
TX 13 bytes
0000 57 00 00 00 00 00 00 00 00 00 00 1f 20 W...........
RX 12 bytes
0000 57 03 07 00 00 02 03 07 05 00 02 20 W..........
TX 13 bytes
0000 57 30 37 32 30 02 30 37 32 30 02 2f 20 W0720.0720./
Azimuth: Elevation:
For this set position command, it first reads the current position to get the position sensor granularity (in this case 2 pulses per degree), and then it sends the command to set the position. This is done because the granularity is needed to calculate position parameters for the last command. To avoid this, rotctl/rotctld should be run with -C az_resolution=x,el_resolution=x, where x is the number of pulses per degree. If the resolution is given, hamlib will no longer need to ask for the current position before each set position command, and thus there is less probability of timing issues.
Another tuning parameter that may be useful is the post_write_delay, which is set to the number of milliseconds to wait after each command sent to the rotator controller.
Download
FAQ
Documentation
Licensing
Supported Radios
Radio Specific Notes
Supported Rotators
Rotator Specific Notes
Supported Amplifiers
Applications and Screen Shots
Network Device Control
Credits
Copyright © 2000-2023 the Hamlib developers (various contributors)