# How CW gets on the air, and why

Written 2026-08-27.

Nonemm has two keying paths and neither of them times the Morse itself:

| Path | What it is |
|---|---|
| `CwDaemonSender` | UDP to `cwdaemon`, which keys DTR or RTS on a serial port and does the element timing |
| `WinkeyerSender` | serial to a WinKeyer in host mode, which does the element timing in hardware |

Keying the serial port ourselves — writing the dots and dashes from inside the
logger — was looked at and left out. This file says what that would take and
why the answer was no for now.

## What N1MM does

N1MM has no cwdaemon. It keys the port itself, in `CWInt.cs`:

- `PortOn(n)` sets `CommPort.DtrEnable` or `RtsEnable` (or writes a parallel
  port bit through `inpout32.dll`), then waits `1200000 × n ÷ wpm`
  microseconds, minus the time the port write itself took. `PortOff(n)` is the
  same with the line dropped. `n` is the element length in dot units.
- The wait is `waitunit`: sleep in 40, 20, 4 and 1 ms steps while there is
  slack, then busy-wait on a `Stopwatch` for the rest. An element can end late
  but never early.
- The spin margin measures the machine. `CntDnAmount` starts at 2000 µs and
  grows every time a sleep overshoots — 200 µs for a small overshoot, up to
  10 ms for a large one — and never shrinks during the run. After a few
  characters it has found how sloppy this machine's timers are and starts
  spinning early enough to land on time.
- Error does not accumulate: each `PortOn`/`PortOff` starts its own
  `Stopwatch`, so one late element does not push the rest late.
- `sendCW` raises the thread to `THREAD_PRIORITY_TIME_CRITICAL` for the length
  of the message — `SetPriority((IntPtr)32, 15)` — and drops it back to normal
  afterwards. While CW is going out, that thread preempts the screen, the
  database and the network.

The keying also sits behind its own UDP listener, `CWIFMain` and `UDPClass`,
which N1MM calls the CW interface. In N1MM Classic it was a separate process;
in Logger+ it is a module in the same process, still spoken to over UDP. That
is the same shape as cwdaemon.

## Why we use cwdaemon instead

Most of N1MM's recipe ports. `SerialPort.DtrEnable` works on Linux, `Stopwatch`
is the same class, and a thread can spin the same way. Two things do not:

**Thread priority.** `THREAD_PRIORITY_TIME_CRITICAL` has real teeth on Windows.
On Linux, .NET's `ThreadPriority.Highest` is a nice value, and nice does not
stop the scheduler taking the core away mid-element. The equivalent is
`SCHED_FIFO`, which needs `CAP_SYS_NICE` or root. cwdaemon can have that
privilege; a logger the operator starts from a desktop should not ask for it.

**Garbage collection.** A collection that stops the keying thread part way
through an element makes an element the wrong length, and that is audible.
N1MM has the same exposure and lives with it. cwdaemon does not have it at all,
being C.

The parallel port is not worth copying either: `inpout32` has no Linux
equivalent that works without root, and the hardware is gone.

## What was decided

Keep cwdaemon as the Linux path and the WinKeyer as the hardware path. A
`SerialCwSender` doing N1MM's coarse-sleep-then-spin is a reasonable third
keyer kind later: it would remove the install-cwdaemon step, it is the only
software path that works on Windows without a WinKeyer, and its completion
signal would be exact rather than a UDP round trip. On Windows it would be as
good as N1MM. On Linux it would be worse than cwdaemon, for the two reasons
above, and that is the trade to make knowingly rather than by accident.

## Knowing when a message has gone out

Alternating CQ needs the end of a message, and both paths report it:

- cwdaemon: `<ESC>h<text>` in front of the message asks for a reply, and the
  daemon sends `h<text>` back on the same socket once it has played. The
  request covers one message, so it goes out before every message.
- WinKeyer: a byte from 0xC0 to 0xDF is a status byte and 0x04 is set while the
  keyer is sending, so busy going off is the end. The bit meanings are from
  N1MM's `Winkey.cs`; the K1EL datasheet is a scanned PDF that does not extract
  as text.

Timing the message from the length of its text was rejected. The guess runs
short exactly when the operator has turned the speed up, and a short guess keys
the second radio while the first is still sending.