[Hamlib-developer] Hamlib and rotators

[Stephane F. <f4...@fr...>]

On Sat, Dec 22, 2001, Francois Retief wrote:
> The Easycom spec can be found at:
> ftp://ftp.amsat.org/amsat/software/win32/wisp/easycomm.txt

Hmm, the protocol looks simple, but I don't understand why the hell there
are frequencies and modes to be specified when controlling the rotator.
Do you have a clue?

Some examples of the EASYCOMM II protocol would help also.
Maybe you are the right person to implement these backends, and test it
while you're at it.

> For a start the basic functions we need to control a rotator is:
> 
> rot_set_position  -  Set the azimuth & elevation position.
> rot_get_position  -  Get the current azimuth & elevation position.
> rot_stop	  -  Stop rotator movement. (either in both axis 
>                      or only one)
> rot_move          -  Move rotator in a spesified direction 
>                      (optional: speed of movement)
> rot_reset	  -  (optional) Reset the rotator before use. 
>                      [warm-up motors, self-calibration, etc.]
> rot_park          -  (optional) Park rotator in safe position after use.

Fine. Work on going, at least on the frontend side (cf. latest cvs
commits)

> The basic capabilities of a rotator will be:
> 
> Movement range and mode:  Minimum and maximum values of the two axis,
> 	and also where the turn-around point is. 
>         (0-180, 0-360, 180-0-180 or 360-0-360, etc.)

Hmm, I'm sorry, I don't understand why we need a turn-around point.
Let's say we have min_elevation/max_el and min_az/max_az, all
being angles relative to horizon / north. Shouldn't it be enough?
Or did I miss something?

Another question. If I'm not mistaken, there are rotator controllers and
rotators being controlled. And a given rotator model can be controlled by
different models of controllers. So, do you think Hamlib should have a
database of rotator capabilities on top of the backends (which are for 
controllers) ?

> I have looked at the RPC stuff.  At the moment the server that it 
> is connecting to, is hard coded.  How would one make the server 
> address and port configurable?  
> 
> Would the 'rig_set_conf' function be a possible solution? 

exactly! I've done some work on the rpcrig. Works better, still not
complete (esp. caps retrieval). Right now, I'm testing "rpc.rigd -vvv"
setup for use with dummy backend, and "rigctl -vvvv -m  1901 -r localhost"
in another window. 
Seems okay, please let me know how it goes on your side.

Cheers 
and best wishes for the new coming year!

Stephane F8CFE