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.
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.
Support is provided for the following Second Edition (-SE) variants:
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.
Command syntax for
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
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.
The following rotctl rotator commands are supported:
p - get position P - set position M - move S - stop
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.
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.
The easiest way I have found to calibrate the ARS-RCI is as follows:
Repeat the the procedure for elevation.
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.
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.
From Nate Bargmann, N0NB, regarding the Idiom Press rotorez backend.
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.
Please report all bugs to firstname.lastname@example.org
From Norvald H. Ryeng, LA6YKA, regarding the spid backend.
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.