An operator with a tower at each end and an AlfaSpid on both wanted OpsLog to
talk to them directly. Multiple rotors were already there; the missing half was
the protocol.
Rot2Prog and Rot1Prog, over the controller's own COM port. The byte layout is
in the package doc and pinned by table tests against Hamlib's spid.c, the
reference implementation — including the one trap this protocol has: digits go
out as ASCII and come back as raw bytes. Send raw and the controller ignores
you; read as ASCII and every heading is wrong by a constant nobody would
recognise as such.
Two things the UI has to get right because they cannot be detected: the dialect
(different reply length AND baud rate) and the baud list, which for a SPID is
600 or 1200 — offering the usual 4800-and-up would have left the controller
permanently mute. Both are handled: picking SPID sets serial transport, 600
baud and Rot2Prog, and the baud dropdown changes to the rates these use.
The connection test reads a status rather than moving anything, so a wrong
dialect shows up there as a reply of the wrong length instead of as an antenna
that behaves oddly an hour later.
Untested against real hardware — I have none. The frames are pinned; the
controller is the only thing that can confirm the rest.
