Write down what the count lag and the symbol count measure

The third probe run puts numbers on both. TxBufLen lags by 100 to 150 ms, about
one character at 45.45 baud: twenty-one characters pushed at 2496 ms read 0 at
2497, 2547 and 2597, then 26 at 2647. It moves once per symbol transmitted, so
readings 50 ms apart repeat.

It read 26 for 21 characters because it counts Baudot symbols, and the message
carried two digits: a shift to figures and a shift back each time, plus one at
the start. That is the case the cap was needed for and I had not seen. A contest
exchange is mostly digits, so the engine always has more to transmit than the
clock thinks, and the clock alone would run ahead of it on every QSO.

Slack of three characters covers both, so nothing changes in the pump. The
count reaching 0 does not cut the end of a message off either: it emptied 350 ms
before the last character was decoded back and the engine held the transmitter
up for another 900 ms.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RtspmWmS7f8kUvcyaHpRWZ

docs/unfinished.md

@@ -65,9 +65,16 @@ a sound card:
 |---|---|
 | Does the control answer `TxBufLen`? | Yes, and a name it does not know fails with `DISP_E_UNKNOWNNAME`, so the two are distinguishable. |
 | What does it count? | Characters left to transmit. Seventeen were pushed; a second later, with five decoded back off the air, it read 12, and it counted down to 0 as the message went out. |
-| How current is that number? | Not current. Read a millisecond and again fifty milliseconds after twenty-one characters had been pushed — and were already going out, the first of them decoded back a moment later — it still said 0. So a pump that fed on the count alone would hand over a whole message in half a second and put all of it beyond reach. How far behind it runs has not been measured; the probe now writes down every reading for the two seconds after a push, which is where the number will come from. |
+| How current is that number? | It lags by 100 to 150 ms, about one character at 45.45 baud. Twenty-one characters pushed at 2496 ms read 0 at 2497, 2547 and 2597, then 26 at 2647. That is why the count cannot be the pace: a pump that fed on a fresh 0 would hand over a whole message in half a second and put all of it beyond reach. |
+| What is it counting? | Baudot symbols, not the characters handed over. Twenty-one characters read as 26, and the message was `CQ TEST DE OM5M OM5M `: two digits, each needing a shift to figures and a shift back, plus one shift at the start. It also only moves once per symbol transmitted, so four readings 50 ms apart are the same number. |
 | Does a backspace take back a character the engine has not transmitted? | No. Pushed in as a character it made the count go **up** by four, and the text went out unchanged. MMTTY's help describes its backspace key doing this in its own window; through `PostMmttyMessage(4, 8)` it is just another character. So text in the engine cannot be retracted, only aborted. |
-| Way to send | This engine is set to Character out: `ABCD` with no space after it went out at once, a character every 200 ms. MMTTY's help says Word out is the usual setting, which would hold that word, so the pump copes with both. |
+| Way to send | This engine is set to Character out: `ABCD` with no space after it went out at once. MMTTY's help says Word out is the usual setting, which would hold that word, so the pump copes with both. |
+| Does the count reaching 0 cut the end of a message off? | No. It reached 0 about 350 ms before the last character was decoded back, and the engine held the transmitter up for another 900 ms after that, so `{RX}` straight after the count empties does not truncate anything. |
+
+Counting symbols rather than characters is what makes the cap earn its place. A
+contest exchange is full of digits, so the engine has more to transmit than the
+pump's clock thinks: `599 001` is seven characters and eleven symbols. The clock
+would run ahead of the engine on every exchange; the cap is what stops it.
 
 The report is worth reading for the receive side as well. With MMTTY's sound
 loopback off, its help says the receive window is fed from the transmit window,

src/Nonemm.Digital/TypeAhead.cs

@@ -21,12 +21,12 @@ namespace Nonemm.Digital;
 ///
 /// The pump is paced by the clock at the baud rate, and the engine's own count
 /// of what it has left is a check on it rather than the pace. MMTTY answers
-/// `TxBufLen` with the number of characters it still has to transmit, but the
+/// `TxBufLen` with the number of Baudot symbols it still has to transmit, which
-/// answer is behind what the engine is really doing: the probe read 0 fifty
+/// is more than the characters handed to it: a digit costs a shift to figures
-/// milliseconds after twenty-one characters had been pushed and were already
+/// and a shift back, so `599 001` is seven characters and eleven symbols. The
-/// going out, and read a right-looking 12 a second after a push. A pump that
+/// answer also lags the engine by about a character time. A pump that believed
-/// believed a stale 0 would hand over the whole message in half a second and
+/// a fresh 0 would hand over a whole message in half a second and put all of it
-/// put all of it beyond reach, so the count is used two ways only:
+/// beyond reach, so the count is used two ways only:
 ///
 /// - as a cap. The engine holding more than `Lead + Slack` characters stops the
 ///   pump until it comes down, whatever the clock thinks.
@@ -59,9 +59,9 @@ public sealed class TypeAhead : IDisposable
     /// stands while the operator is not typing into the pane.
     public const int NoCursor = int.MaxValue;
 
-    /// How many characters the engine's count may be behind what it is really
+    /// How much the engine may hold above `Lead` before the pump stops feeding.
-    /// doing. The count is what stops the pump when the engine falls behind the
+    /// It covers the count's lag, measured at 100 to 150 ms, and the shift
-    /// clock, so it has to allow for the lag rather than fight it.
+    /// symbols the engine has to transmit that the clock does not know about.
     public const int Slack = 3;
 
     /// How often the engine is asked how much it has left.