Re: [Hamlib-developer] Proper API implementation for Rotor-EZ

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

On Tue, Feb 25, 2003, Nate Bargmann wrote:
[..]
> However, the Rotor-EZ and DCU-1 (Hy-Gain) interfaces do not support what
> I gather to be the rot_move function's idea of direction (CW, CCW, Up or
> Down) nor a rotational speed.  So, to use rot_move any passed values
> would be ignored and a static command sent to the interface.

If a protocol has no provision for rot_move, well the backend is not
obliged to implement it. I would say, rot_move is for rotators who cannot
implement rig_set_position.

> So, what is the intent of the API?  Is the application code expected to 
> call rot_set_position and then rot_move for positioning to actually occur?

no, rot_set_position is all what an application can need.
Applications are supposed to use either one exclusively, depending
on what they need to do.
Actually, the rot_move tries to mimic the manual CW and CCW paddles.
That comes handy when you want to sweep the horizon, hear a signal and
come back on it by "interpolation", i.e. you don't knwo the az/el in
advance.

> I see that fodtrack uses just rot_set_position while easycomm uses
> rot_move.  So, whichever why I go will set a 2 to 1 preference.

easycomm has both. Just implement what the protocol can do and
that should do it.

> I'd be happy to add comments to rotator.c to make this more clear.  :-)

Sure, you'd be very welcome!


Cheers,
Stephane