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:
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user