[Gpredict-discussion] Bug Report - Rotator Control

[<cj...@in...>]

Alex and co.,

Running Ubuntu Desktop 14.04, Gpredict 1.3 and Hamlib 3.0.1.  Rotator
is Kenpro KR-5400 using GS232 protocols.  I'm operating from the
southern hemisphere (VK-Land) so as is somewhat typical here our
rotators are set with the end stops in the south direction and will
freely move through North as centre.  As such, I've configured the
rotator as being -180 - 0 - 180 arrangement with elevation control
capable of 0-180deg operation.  Whenever a negative azimuth value to
presented, the rotators no longer move.  Some investigation later,
I've been able to confirm that the GS232 protocol allows only positive
values and this appears to have been appropriately implemented in
Hamlib. I have a video of the issue during a pass including a
wireshark capture of the transmissions between Gpredict and Hamlib
(showing the negative values being sent) as well as a text file of the
commands issued by Hamlib to the controller which I can forward on
request. I can confirm that Hamlib isn't crashing but it is not
sending commands while it received negative azimuth values from
GPredict.

I've had a quick look at the source code of gtk_rot_ctrl.c and believe
the fix lies in the lines that currently read (in two locations):

"if ((ctrl->conf->aztype == ROT_AZ_TYPE_180) && (sat->az > 180.0))
{
sat->az = sat->az - 360;
}

 There may be other lines affected, especially when 'flip mode' is
involved ( haven't had time to work through the code to see how 'flip
mode' determines where the end stops are).

This issue has appeared as I am assisting one of the 3 Australian QB50
teams.  At least two of the teams are looking to utilise Gpredict for
their tracking.

There are a few conceptual issues here. There is a difference between
a rotator controller (and its associated rotator) that:

a. Accepts commands of -180deg to 0 deg to +180deg and swings through
north (i.e. has south pointing end stops), and
b. Accepts commands of 0deg to 360deg (with these both being north
commands) and swings through north (i.e. has south pointing end
stops), and
c. Accepts commands of 0deg to 360deg however as it has its end stops
pointing south is 180degrees out of rotation (ie. 0/360 is south and
180 is actually pointing north).

I also note that there is an open ticket 89 - I'm not sure however the
behaviour would 'appear' the same if that user had a similar setup.

If you or the team requires further info - please do not hesitate to
contact me.

Best Regards,

Cameron McKay - VK2CKP