Easycom Protocol v2 - 0 - 0
Easycom Protocol v2 - 0 - 0
Easycom Protocol v2 - 0 - 0
Authors:
Richard G. Desaulniers, VE2DX
Date :
June 18th 2011
Release:
2.0.0
Release Date Changes Approval
1.0.1 October 17th 2010 Applied changes from DF9GR, to address Richard G.
CS2 compatiblity and ease of Desaulniers, VE2DX
firmware/application integration.
1.0.2 October 17th 2010 Ajusted goals and problem list to changes Richard G.
in using more CS2 commands. Desaulniers, VE2DX
1.1.0 November 6th 2010 Added command priority and native Richard G.
command set explanation Desaulniers, VE2DX
1.2.0 December 8th 2010 Finalised document, reformated tables and Richard G.
general Cleaned up. Desaulniers, VE2DX
2 HISTORY:.......................................................................................................................................................... 5
3 GOALS:.............................................................................................................................................................. 6
4 THE PROBLEMS:............................................................................................................................................ 6
Release: 2.0.0
Thanks to : Rene Schmidt DF9GR, Geoff Anderson G3NPA, Robert C Furzer K4CY,
Simon Brown HB9DRV, Terry Genes G4POP and Buda Codrut Gabriel YO3DMU
1 Introduction:
For many years the evolution of the rotor control protocols has been almost none existent, there as
been some interesting evolutions in early 2000 with expanded DCU-1 AZ protocols to address very
basic needs, but most Azimuth interfaces use mostly the dated (late 1980's) DCU-1 which is a very
basic protocols that offers very little control and no feedback from the rotor.
Commands added to the original DCU-1 helped, but this being an already limited approach these were
very limited and just brought this approach to a barely acceptable level. And some of the protocol
design decisions in DCU-1 itself were none standard and even somewhat bizarre!
GS232A and GS232B introduced by Yaesu/Kempro for there rotor controllers in the 1990's were very
well designed and much more powerful then DCU-1, it can control either single axis (Azimuth only
rotors mostly but also Elevation only rotors) or dual axis rotors (Azimuth/Elevation Satellite setup only).
And because of the very high cost of the Yaesu/Kempro GS232A and GS232B hardware, there are
very little implementation of the GS232 protocols other then in satellite tracking applications. Logging
and contesting softwares likes Logger 32, N1MM, Wintest and HRD with its introduction of HRD
Rotator did address both Single (HF) axis and dual (Satellite) axis operations and integrated very well
the GS232A and GS232B protocols (HRD Rotator) along with many others.
But all DUAL Axis controllers until now were always satellite oriented controllers, even tough
technically an elevation rotor is nothing but an Azimuth rotor turned on it side, as more and
more hams are automating there HF stations using logging softwares likes HRD Rotator or Logger32
and contest softwares like N1MM or WINTEST, many of these stations have more then one azimuth
rotors turning HF antennas or HF and VHF antennas, thus why not offer the possibility in a new design
rotor interface like the DF9GR’s ERC-M to use the interface as a single Azimuth, an Azimuth/Elevation
or Dual Azimuth interface.
In this document we will look at the details of the GS232 protocols (AZ and AZ/EL), the possible
evolution of the GS232B-AZ and GS232B-AZ/EL protocols and how this advanced rotor control
protocol could take an evolution change to add dual Azimuth control called GS232B-AZ/AZ. Finaly
we will look at how this could also be implemented in GS232A-AZ/AZ
2 History:
Automated rotor control was introduced in the late 1980s by satellite ham radio operators (AMSAT). At
first these were very expensive Ham and commercial products, the evolution of low cost personal
computers and the requirement to track at all time of a fast moving satellites on dual axis with very
short communication windows, meant this was a badly needed accessory.
Hy-gain introduced a control box replacement with the DCU-1 protocol in the late 1980’s that was a
very limited control only protocol, in early 2000 some ham products in control box replacement or
addon pcbs expanded protocol versions of DCU-1 (with added position request and feedback
commands), but little more then that.
Early interfaces were very expensive and not very flexible; in the late 1990 we saw with XQ2FOD's
Fodtrack and soon after DL7AOT AOTTracker some great low cost approaches making these
affordable for all. These were soon followed in early 2000 by Mark WA8SME's Sat688 and Howard
G6LVB's LVB Trackers that were two very large advancements to the evolution of rotor control
interfaces, especially Howard's LVB Tracker made large steps in offering rotor position feedback and
using a better integration of the GS232A-AZ/EL protocols.
But all of these evolutions were mostly oriented for sat based AZ/EL operations, until the advancement
of better station automation/logging like Logger32 and Ham Radio Deluxe (HRD) with the introduction
of the HRD Rotator application, the complete station integration of the Azimuth only rotor was very
slow coming.
in 2009 Rene DF9GR introduce a product line called the Easy Rotor Control (Known as ERC) that was
a single axis rotor interface used for either Azimuth or Elevation. The ERC hardware and supporting
software design made for an incredible evolution that added both hardware and protocol compatibility
and flexibility. This was followed in late 2009 with the ERC-3D that took the strength of the ERC design
and added dual axis, LCD display, control, etc... And in mid 2010, with the very small plug ready based
dual axis USB ERC-R... and in june 2011 the new modular design of the ERC-M that also supports
DUAL-Azimuth (GS232A-AZ/AZ and GS232B-AZ/AZ).
The flexibility of the ERC designs raised some questions as to why not use a dual axis device like the
LVB, ERC-3D or ERC-R with TWO AZIMUTH rotors? Technically there is no difference, lets face it an
Elevation rotor is nothing but an azimuth designed to operate while sitting on its side and limited to
180 degrees instead of 360 or 450...
And with the growing ham radio station automation requirements, more and more hams are using
Azimuth only HF operations with applications like logger32, HRD 5 Rotator, N1MM and WinTest that
will let you pick a station from you DX Cluster, push it to you log entry screen, tune your radio and
change your rotor bearing to make your contact within one or two clicks of your mouse! With the
evolution of SO2R, this is even more important in contest operations, where you don’t have time to
decide if your rotors are positioned correctly or not... or even worse if you just turned the correct
rotor...
3 Goals:
In this document we itend to set a new dual Azimuth rotor control command set standard:
4 The problems:
The main problem is simple; there is presently no standard dual Azimuth protocol. Thus I intend in this
reference to explain how we can take the evolution of the GS232B protocols, originally introduced by
the Kempro/Yaesu group for there Azimuth and Azimuth/Elevation rotor product family, and add to it
the GS232B-AZ/AZ command set.
There are other issues that may need to be addressed to help GS232B-AZ/AZ product introduction;
1 Most application will not be GS232B-AZ/AZ compatible immediately. This will be adress with
application evolution adding support of GS232B-AZ/AZ and rotator interfacing applications like
Codrut's PSTRotator.
2 Application accessing one or both of the Azimuths may not be GS232B-AZ compatible (gs232a-
az, idiompress DCU-1 or DCU-1 modified). This will be address with application evolution adding
support of GS232B-AZ/AZ and rotator interfacing applications like Codrut's PSTRotator.
3 User may want have two distinct applications addressing each rotor. This will be address with
application applications like Codrut's PSTRotator.
4 Keeping firmware and application integration of the new protocol as simple as possible. Proper
firmware integration of command sets by interface suppliers like Rene DF9GR would address this
issue.
5 The generic S command used in GS232B-AZ and GS232B-AZ/EL (Stop Azimuth or stop Azimuth
and Elevation Movement) would be a problem in GS232B-AZ/AZ mode since it would apply to
both Azimuth and in most cases this would not be the intend… This will be adress with application
evolution adding support of GS232B-AZ/AZ and rotator interfacing applications like Codrut's
PSTRotator.
5 Why GS232 based evolution:
First we need to look at what is available to us and there strength, the goal being to add the
functionnality to an existing standard and make it fit without affecting the existing protocol and have a
simple logic to the evolution.
Easycom II was a major evolution from Easycom I, adding more rotor and also radio control
commands, but both Easycom version always had one MAJOR drawback they can not give rotor
position feedback. There are also some confusion around protocol standards since it is not well
documented, finally the Easycom II was designed as a complete station control protocol controlling not
only the rotor but also the radio, this last issue adds complexity that would make adapting it to Dual AZ
operation somewhat more complex.
5.2 DCU-1:
DCU-1 was introduced by Hy-Gain for there rotor controller replacement box, the nemonics used are
somewhat off the wall not using any simple easy to understand commands memonics. It is also a
protocol that does not offer rotor position feedback information even dougth this and other lacking
commands were added by some Ham product suppliers to there version of DCU-1, it is still a very
limitating protocol and being that it was not originaly design to support dual axis (AZ only and no
AZ/EL versions...) it is somewhat more complicated to adapt...
GS232B was an evolution of the GS232A, mainly changing the response feedback format from a
+0nnn+0nnn format to a more simple and easier to understand AZ=nnn and EL=nnn format.
The GS232B is well designed for the evolution to add a DUAL Azimuth command set being that it is
already based on two distinct command sets;
Thus it is a natural fit for Command Set 3 that would be an evolution of the first two based largely on
how command set 2 was implemented to add Dual Azimuth based commands oriented mainly into
controlling mostly the second Azimuth.
6 Principals of operations of Dual Azimuth rotor interface:
A dual azimuth interface is mainly a dual axis controller similar if not identical to an AZ/EL controller as
far as hardware is concerned. Except, the second axis can be used to control an Elevation rotor or a
second Azimuth rotor. This is done either via a single application like logger32 or HRD 5 Rotator
where both Axis rotor are then configured to specific portions of the applications, thus offering the
possibility to the user to operate two HF antennas distinctively for two HF operations or an HF and a
VHF/UHF Stack. Or like Logger32 did configure the Rotor Axis selection based on, band, frequency
and mode selection, as you operate the application switches rotors to cover your needs as per your
configuration...
There maybe other situations where two very different applications or a singles application that do not
support dual Azimuth rotor interfaces may require to control two Azimuth rotor via a GS232B-AZ/AZ
protocol, in this situation a third party interface application like PSTRotator maybe required to offer
these applications two separate virtual GS232B-AZ or why not DCU-1 com ports thus making the
GS232B-AZ/AZ transition a responsibility of this application. This would have the added advantage of
offering the advantages of the GS232B-AZ/AZ interfaces to any application and even running two
different applications each driving a different Azimuth rotor via the same interface.
Later with the evolution of controllers we are hoping to introduce the possibility to link both Azimuth
axis together to synchronize both antennas for specific operations with or without any offset, this
would be nice in contesting or large antenna farm setup where you want to use multiple antennas on
different rotors for the same goal.
7 GS232B Command sets:
The GS232B command sets are separated in two very distinct groups;
Evolution of the GS232B-AZ and GS232B-AZ/EL to cover the dual azimuth operations;
7.3.1 GS-232B-AZ/AZ protocol Command set 3 for Azimuth 2 (includes all command set 1
and 2)
Note : even if barely used the commands in YELLOW are still adapted to GS232B-AZ/AZ changes to keep compatibility.
7.4 Command set 3 GS232B-AZ/AZ design principales:
You will note that in the proposed Command set 3 most of the GS232B-AZ/AZ commands stayed the
same or very similar to GS232B-AZ/EL, these are commands that would be used in the same way as in
AZ/EL operations and thus do not require changes helping compatibility, we are hoping by not
replacing these commands we will be able to make the GS232B-AZ/AZ integration in existing
application easier.
Thus Azimuth 1 commands for Azimuth 2 like L is now D, R is U, A is now E and C is now B. You
should have noticed that these were all used previously in GS232B-AZ/EL to control the Elevation
portion of the interface thus the second Axis, since Azimuth 2 is also the second axis of the GS232B-
AZ/AZ interface we are keeping these same commands and keeping the firmware and application
changes to a minimum.
Where Command set 2 (GS232B-AZ/EL) Commands can not be used and the required command is
already used in Command set 1, then change is made by adding the letter B at the end of the command
before the variable value if there is one, such as MBnnn, XBn and ZB these are basically the same as
Mnnn, Xn and Z except the command set 3 commands will be applied to the Azimuth 2 rotor.
B = The B command is used in the same way as the B command in the GS232B-AZ/EL command set
2, upon reception of the command, the interface will return the present position of Azimuth 2 in the
EL=nnn format.
C2 = is used in Dual Azimuth operation to interrogate both axis present bearing, the interface will
return AZ=nnnEL=nnn, where AZ=nnn is the present bearing of the Azimuth 1 rotor and EL=nnn is the
present bearing of the Azimuth 2 rotor.
D = is used to initiate an immediate CCW move command to the Azimuth 2 rotor, once initiated this
will not stop until reception of one of the following; D, E, MBnnn, U, TB, S, Wxxx yyy, Y, Ynnn or
Y999 or when rotor reaches end of range.
E = Is used in the same way as the A command in GS232B command set 1, the E command is used to
stop all operation on the second Axis thus Azimuth 2.
MBxxx = Used to send a bearing request to the Azimuth 2 rotor, where the xxx is the requested
bearing, upon reception of the MBxxx the interface will initiate stop on Azimuth 2 and will initiate
movement toward bearing xxx using the shortest possible direction. If the rotor was already turning in
the proper direction the immediate stop command can be bypassed and the rotor simply changes the
destination to the new bearing. Once initiated this will stop upon reception of one of the following; E,
MBnnn, U, S, TB, Wxxx yyy, Y, Ynnn or Y999 or when rotor reaches destination.
S = This command is used to initiate an immediate STOP on both Azimuth attached to the interface.
Note: many application use the S command instead of the A or E commands to stop a GS232B-AZ or
EL operations, when using the S command in a GS232B-AZ/AZ environment, this could initiate
unwanted Azimuth 1 or 2 stops, we need to address this issue!
One way of doing this is to have the interface decide in its configuration where the S is applied
(Azimuth 1 only, Azimuth 2 only or both Azimuth?)
When using an external application interface, then S commands going to Azimuth 1 could be converted
to A commands. And the S commands going to Azimuth 2 should be converted to an E command.
U = is used to initiate a immediate CW move command to the Azimuth 2 rotor, once initiated this will
not stop until reception of one of the following; D, E, MBnnn, U, S, TB, Wxxx yyy, Y, Ynnn or Y999
or when rotor reaches end of range.
Wxxx yyy = This command is used to send dual axis azimuth values where xxx is used to set a new
bearing for Azimuth 1 and yyy is used to set a new bearing for Azimuth 2, upon reception both azimuth
will initiate immediate stop and start movement in direction of the new bearing. If the rotor was
already turning in the proper direction the immediate stop command can be bypassed and the rotor
simply changes the destination to the new bearing. Once initiated this will stop upon reception of one
of the following; D, E, MBnnn, U, S, TB, Wxxx yyy, Y, Ynnn or Y999 or when rotor reaches
destination.
XBn = Same as GS232B-AZ X command, this is a speed control command where n = the required
speed. N is a value from 1 to 4 where 1 is always full speed and 4 is always full speed, 2 and 3 can be
set to initiate variation in high speed ramping up and down delays. The XBn setting should be kept
until the next XBn command is received, power is recycled or until the user manually changes the
speed control to manual mode in the interface, when the interface speed is set in manual mode the XBn
commands will all be ignored.
Y, Ynnn and Y999 = The Y commands are used to synchronised both azimuth 1 and 2 together, a Y
command by itself, initiates full control of Azimuth 2 at same bearing and speed as Azimuth 1. A Ynnn
command is the same as a Y command except an offset value of nnn is added to the Azimuth 1 bearing
and set as the required Azimuth 2 bearing, thus is a Y090 is received and my Azimuth 1 bearing is 060
then my Azimuth 2 bearing will be 060 + 090 = 150 thus Azimuth 2 bearing should be 150… In the
same example if a Y330 is received then 330 + 060 = 390 and then this should be translated to a 030
bearing. The Y999 is used to cancel the Y or Ynnn command and return the Azimuth 2 rotor to
individual control. This command will be cancelled upon reception of the Y999 command or a
powerup reset of the interface. Once Y or Ynnn is initiated all other Command set 3 (Azimuth 2
commands) will be ignored.
GS232A-AZ/AZ implementation is fairly simple, the exact same commands and principles used in
GS232B-AZ/AZ can be applied to GS232A-AZ/AZ the only difference have to do with the responses
from the interface to the application.
In GS232B operations these responses were AZ=xxx and EL=xxx, in GS232A these are +0nnn+0nnn
or simply +0nnn when for a single Azimuth, this bring up a warning software developpers MUST be
carefull to properly time there request and the interfaces reply since both axis in GS232A mode
respond the same way to a single axis position request +0nnn... This was not an issue in GS232B
since the response included an axis specific portion AZ= for the first axis and EL= for the second
one...