The DCU-1 client opened a connection per command and closed it again,
"mirroring the gs232/pst/rotgenius idiom". That idiom is right for the
UDP backends beside it and wrong over TCP to an embedded serial server,
which is what an RT-21's Ethernet option is: the heading is polled every
500 ms while the antenna turns, GoTo sends two commands (AP1 then AM1),
Stop sends two more — each its own connect and close. Modules of that
class commonly accept a SINGLE session and need a moment to release it,
so the churn on its own looks like a controller ignoring half of what it
is told.
The socket is now kept between calls, one mutex serialises every
exchange — which also stops the poll and an operator command from
holding two sessions at once — and a write or read error drops it so the
next call redials. One retry after a redial, because a kept socket's
first write succeeds long after the far end has gone. Serial keeps
open-per-call: a COM port has one owner, and holding it would lock out
the controller's own software.
Keeping a session only helps if the client survives the call, and
dcu1Client built a fresh one every time, so it is cached per controller
identity. Two rotors on the same box share one client, which is the
point when one session is all there is. SaveRotators drops the cache:
a client left over from the previous host would hold the very session
its replacement needs.
Three tests against a fake controller that accepts one session at a
time: four commands share one session, a dropped session is redialled
exactly once, and a failed dial leaves nothing behind.
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