Ctrl+B calls CQ on one radio, and when that message has gone out, moves to the other and calls there. The keyboard, the entry window and the SO2R box follow each turn. N1MM calls this dueling CQs and puts it on the same key. The turn is taken when the keyer says the message has ended, not when a timer guesses it has. So MessageSender grew a Finished event and a ReportsCompletion flag, and both keyers fill them in: cwdaemon answers the <ESC>h reply request that now goes out in front of every message, and a WinKeyer clears the busy bit in the status bytes it sends of its own accord. The status-byte reading is in WinkeyerStatus, away from the serial port, because that is the half that can be tested without a keyer on the desk. A keyer that reports nothing refuses to start alternating CQ rather than keying the second radio over the first. AlternatingCq itself takes the keyer, a callback that calls CQ on a radio, the gap and a wait function, so the alternation is tested without sleeping. The gap is in Config ▸ Keyer and messages and will not go below 100 ms, which is N1MM's floor too: an SO2R box works relays. docs/keying.md writes down why cwdaemon does the timing and we do not. N1MM keys DTR itself with a coarse sleep, a busy-wait and a margin that grows every time the sleep overshoots, and it raises the thread to TIME_CRITICAL for the length of the message. The busy-wait ports to Linux; the priority does not, without CAP_SYS_NICE, and a garbage collection mid-element is audible. A direct serial keyer stays a reasonable third option, to be taken knowingly. Running it against a fake daemon that takes 1.5 seconds to play a message: six CQs went out back to back and the keyboard moved between the two entry windows each time. Escape stopped it, let the message in flight finish, and started nothing further. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
4.4 KiB
What is not finished, and what has not been tested
Two separate lists. A feature can be finished and untested, or half-built and exercised every day. Written 2026-08-27.
Never run against the real thing
Everything below is written from a published protocol or from N1MM's source and tested against a fake that speaks the same protocol. A fake agrees with whatever the person who wrote it believed, so these are the places where a wrong belief is still sitting there undiscovered.
| What | Tested against | What has never happened |
|---|---|---|
RigctldRadio |
a stand-in for rigctld over a real socket |
no real rigctld, no real radio. The extended answer format, the + prefix and the split commands are from the documented protocol. If the format is wrong, nothing works rather than something being subtly off — check this first. |
OtrspBox |
a MemoryStream, checking the bytes |
no real SO2R box. Command forms are from N1MM's N1MMPort.cs. |
ClusterClient |
a node fake over a real socket, sending the telnet negotiation, the login prompt and spot lines | no live cluster node. Which nodes send bare CR, and which send option negotiation, is guessed from N1MM's code. |
StationNetwork |
the message format, round-tripped | no second station, and no N1MM on the same network. |
CwDaemonSender |
the UDP messages, and a fake daemon that answers the <ESC>h reply request |
no cwdaemon, no radio keyed. |
WinkeyerSender |
the status-byte reader, on its own | no test of the serial side, and no WinKeyer. The host-mode open sequence is from the WinKeyer datasheet; the status bits are from N1MM's Winkey.cs. |
The Cabrillo output has not been put in front of a contest sponsor's robot.
Half-built
Voice keying. MessageSender was written to cover a voice keyer playing a
recording, and nothing implements it. No DVK support either, so the second radio
of an SO2R station cannot call CQ by voice. Alternating CQ therefore works on CW
only, though nothing in it is CW-specific: a voice keyer that reports when the
recording has finished would drive it as it stands.
Alternating CQ does not restart itself after a contact. Escape stops it, and it has to be started again with Ctrl+B. N1MM carries on calling after the QSO is logged.
Call history: the section-validating directives. !!Validate50State!!,
!!ValidateArrlSection!!, !!MapOnSection!! and !!GTA2GH_NT2TER!! are read
and passed over. Acting on them means holding N1MM's section lists and its
rules about which sections are retired, and getting that wrong throws away good
data. The file is read without them.
QTC handling for WAE. Not started. WAE logs will not be complete without it.
Digital modes. A contact can be logged as RTTY or another digital mode, and the contest rules score it, but there is no digital window: no decoding, no transmitting, no interface to fldigi, MMTTY or similar.
Contest coverage. Eight contests are built in, plus whatever .udc files
are in the user-defined folder. N1MM ships well over a hundred. Opening a log
from a contest not in the registry fails with the contest name, which is the
right answer but it is still a wall.
Known rough edges
The log window's column widths are the grid's own automatic sizing with a character-count floor. A column can change width as rows scroll into view.
Contacts arriving over the station network are applied from the socket
thread, and AppSession.TakeFromNetwork reopens the whole contest to do it.
That is correct but heavy, and it discards what is typed in an entry window on
another radio.
The band plan covers 160M to 2M only. 60M and everything above 2M get no CW, digital or phone shading on the bandmap, because N1MM's own numbers for those bands contradict themselves — its CW top for 1.25M is below its phone start, and its 70CM CW top is above the band. Config ▸ Sub bands cannot add a band that has no default.
Available mults and Qs is only as good as the bandmap. It lists what is spotted, so a multiplier nobody has spotted is not there. N1MM's window also shows the mults a contest has and nobody has worked, which needs a list of every multiplier the contest counts. Only the section and state lists are held here, so the zone and country lists would have to come from the country file first.
Two entry windows and one keyer. The SO2R box is told which radio to key before each message, but nothing stops both radios sending at once if the operator asks them to.