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
|
