Keep the engine fed instead of feeding it a character at a time

The pump handed the engine one character and then waited a character time
before the next, on purpose, so it stayed behind the engine rather than ahead.
That leaves the engine with an empty buffer between every two characters of a
message, and an engine with an empty buffer transmits idle rather than waiting.
The idle is added to how long the message takes, which in a contest is time
paid for nothing.

The pump now keeps two characters in the engine: one being transmitted and one
behind it, so the engine never runs dry. The clock at the baud rate says when
the engine has room for the next one, and the engine reporting that it has
stopped transmitting sets the estimate back to an empty buffer.

The last two characters are now beyond reach rather than the last one. Everything
before them can still be rewritten, which is what the pane is for.

A message is finished when the buffer is empty and the engine is estimated to
have transmitted what it holds, so {END} and {RX} no longer run while the engine
still has the last characters of the message.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RtspmWmS7f8kUvcyaHpRWZ
This commit is contained in:
2026-09-01 21:56:41 +00:00
parent 9d0af06686
commit da7f7fb3f5
4 changed files with 184 additions and 50 deletions

View File

@@ -44,14 +44,22 @@ type-ahead transmit pane were checked. Nothing has been decoded from a real
signal and nothing has gone on the air: this machine has no sound card, and
MMTTY does not start on it.
**What paces the type-ahead pump.** It counts character times off the clock at
the baud rate in the digital settings, so it runs a little behind the engine
rather than ahead of it. The engine can be asked instead: `XMMT.ocx` has a
`TxBufLen` property, and a probe against the control shows it answers, though
what it answers while a message is going out could not be measured here because
the engine will not start. Reporting it from the bridge would make the red text
exact and let the pump keep the engine's buffer full rather than leaving a gap
between characters.
**What paces the type-ahead pump.** The pump keeps two characters in the
engine and counts character times off the clock at the baud rate in the digital
settings to work out when the engine has room for the next one. Two characters
is what stops the engine running dry between characters, which would make it
transmit idle and add that idle to the time the message takes; the price is that
the last two characters cannot be taken back. The estimate is corrected when the
engine reports that it has stopped transmitting, which means its buffer is
empty.
The engine can be asked instead of estimated: `XMMT.ocx` has a `TxBufLen`
property, and a probe against the control shows it answers, though what it
answers while a message is going out could not be measured here because the
engine will not start. Reporting it from the bridge would make the red text
exact and would take out the one error the estimate can still make: a baud rate
that does not match what the engine transmits at leaves a small gap between
characters near the end of a long message.
**Voice keying.** `MessageSender` was written to cover a voice keyer playing a
recording, and nothing implements it. Each operator's recordings folder is