The RT-21 speaks the Hy-Gain DCU-1 command set in its default protocol
setting, and internal/rotator/dcu1 has driven that since it landed —
AP1nnn/AM1 to point, AI1 to read back, over a COM port or over TCP.
Nothing was missing except a way to find it: "Green Heron" sat in a
parenthesis after "Hy-Gain DCU-1", which an operator scanning the list
for RT-21 does not see.
So the dropdown leads with the controller people actually own, and the
hint says the two things that decide whether it works: the RT-21's
protocol must be set to DCU-1 / Rotor-EZ (on GS-232 it belongs to the
GS-232 entry instead), and with the Ethernet option TCP reaches it
directly rather than through a serial-over-IP bridge, which is what the
hint used to imply was necessary.
The package doc now also records what is NOT here: the native Green
Heron protocol is a third command set, with 0.1° readback and a real
stop, and writing it from memory is exactly the mistake this repo warns
about for wire protocols.
New internal/rotator/dcu1 client speaking the DCU-1 command set (AP1nnn / AM1
to go-to, AI1 to read bearing), over a serial COM port (4800 baud default) or a
raw TCP serial-over-IP bridge. Azimuth-only; Stop re-commands the current
bearing since the base set has no stop opcode.
Wired through app.go (normRotorType, default port 4001, GoTo/Heading/Stop/test
switches, park returns the same "PstRotator only" note as ARCO) and exposed in
the rotor settings as "Hy-Gain DCU-1 (RotorCard DXA, Rotor-EZ, Green Heron)"
with the ARCO's serial/TCP transport chooser and a bilingual hint. Protocol is
implemented from the standard DCU-1 spec and still needs field confirmation
against a real RotorCard DXA.
rouggy