An operator with a WinKey2 USB had to run K1EL's WKdemo and close it again
before OpsLog could talk to the keyer at all. That workaround is the diagnosis:
closing another program does something to the keyer that opening the port does
not, and whatever state it was stuck in survives a failed connect.
So the second handshake attempt now does what closing WKdemo does, in an order
that survives each step failing:
- Host Close, in case the keyer is still in host mode from a session that
ended without one — a crash, a cable pulled, a machine switched off. It has
been waiting ever since for a host that went away.
- Admin Reset, which returns it to its power-up state. A parser stuck
part-way through a command whose parameters will never arrive cannot be
talked out of it any other way.
- A DTR pulse, which is what closing a program actually does to the line. On
a WKUSB and on every Arduino-based clone, DTR runs to the processor's reset:
it is a power-on reset in all but name.
RTS is left alone throughout — on a serial WinKeyer it is the negative rail the
RS-232 swing comes from, and driving it starves the chip.
A keyer that answers the echo and then refuses to open is the same leftover
session seen from the other side, so that case sends Host Close and asks again
rather than reporting a keyer that demonstrably just spoke to us as absent.
And a port already known to need the slow path gets the wake-up on the FIRST
attempt from then on: making the operator sit through a failure to earn it again
doubles the connect time for no new information.
The handshake bytes are already logged on every connect, so the next report of
this shape says where it stopped.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
rouggyandClaude Opus 5
8f643b5b67