The attached patch restores what I think is the original easycomm
rotator interface functionality. It eliminates the conditional code
for USE_CUSTOM_CODE and USE_TEST_CODE.
Apparently for a very long time, the easycomm back end has been build
with USE_CUSTOM_CODE hardcoded in the source file. This generated code
that issued commands not even remotely similar to what's specified in
the easycommII protocol, which is documented in the easycomm directory
for hamlib.
It appears that at some point someone used the easycomm back end to
implement some custom tests for something, and it was committed and
has been carried this way ever since.
This restored what I think is proper functionality according to the
easycomm spec.
If you are a user of the easycomm back end, or you know of any
easycomm compatible rotor controllers that can be used for testing,
let me know and I can be more thorough about this.
Notes and disclaimers:
0. The original easycomm spec author seems to be unavailable.
1. I don't think that there was valid code to parse the position data
returned from the rotor controller. What was actually getting compiled
simply set some hard-coded values. I replaced it with what I think is
called for by the spec.
2. The easycomm spec is vague about what is supposed to be returned
for any command, so I may still not be parsing position information
correctly as it comes from other easycomm controllers.
3. I wrote my own rotator controller code based upon an interpretation
of the easycomm II spec. This back end for rotctl works with my
implementation. I don't have access to any other easycomm controllers
or even know whether any exist, so I am unable to test this against
any other implementation of easycomm.
4. Even when you select EASYCOMM II as the back end, it sends commands
which are only supposed to be valid for easycomm I according to the
spec (i.e. the position set command includes uplink and downlink
frequency and mode information fields). My rotor controller handles
these, so I didn't change the position set portion of the code.
I understand if there's concern for breaking rotator control for
existing users of the easycomm back end (if any actually exist). If
this patch is too risky, I'll either rewrite my controller to use
another protocol, or add another back end for my own newly invented
protocol "ai4qrcomm" (and document it better than easycomm).
Thanks,
Steve, AI4QR
Signed-off-by: Nate Bargmann <n0nb@n0nb.us>
Alexander Schultze