Do not trust the engine's count as the pace

The second probe run read TxBufLen as 0 one millisecond and again fifty
milliseconds after twenty-one characters had been pushed, while those characters
were already going out: the first of them was decoded back off the air 420 ms
later. The number is right when it is a second old and wrong when it is fresh,
so it runs behind the engine.

A pump that fed on it would have handed over the whole message in half a second
and put all of it beyond reach, which is worse than the clock it replaced. So
the clock is the pace again, and the count is a check on it: the engine is never
given more than Lead + Slack characters however fast the clock says to feed, and
a message ends when the count and the clock estimate both say it has. Characters
fed since the last answer are added to it, so a stale answer cannot be spent
twice.

The engine is set to Character out: ABCD with no space after it went out at
once. Word out would have held it, so the holding case stays, but it now needs
the count to be neither going down nor being added to, since an engine kept
exactly at the cap has a count that does not move either.

The probe writes down every reading for two seconds after a push and does not
believe an empty one in that window, which is what the run needed to measure the
lag and did not do.

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

docs/unfinished.md

@@ -50,32 +50,30 @@ so it never runs dry and never transmits idle in the middle of a message. Those
 two characters cannot be taken back; everything behind them can still be
 rewritten.
 
-How far the engine has got comes from the engine. MMTTY answers `TxBufLen` with
-the number of characters it still has to transmit, so the pump asks, feeds while
-the answer is under `Lead`, and asks again, 50 ms at a time. An engine that will
-not answer is paced by the clock at the baud rate in the digital settings
-instead, which drifts; that is what the baud setting is still for.
+The pace comes from the clock at the baud rate in the digital settings. The
+engine's own count of what it has left is a check on that rather than the pace
+itself, for the reason in the table below: it is used as a cap, so the engine is
+never given more than `Lead + Slack` characters however fast the clock says to
+feed, and as the end of a message, together with the clock estimate. A count
+that neither goes down nor is being added to means the engine is holding what it
+has, and the pump feeds a character every `HoldingPatience` until it moves.
 
-What the engine probe established on 2026-09-01, with MMTTY 1.70 under Wine on a
-machine with a sound card:
+What the engine probe established, with MMTTY 1.70 under Wine on a machine with
+a sound card:
 
 | What | Answer |
 |---|---|
 | 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. |
 | 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. |
-| How long after a push does the count include it? | Not immediately. A count read a millisecond after the push still read 0, so one empty answer is not the end of a message. |
+| 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. |
 
-Two things the probe has still to answer, and it now asks both:
-
-- **Way to send.** MMTTY set to Word out holds a word until the space after it,
-  which the first run appeared to show but could not confirm, because the engine
-  was not keyed for that step. The pump handles it either way: a count that
-  stops going down means the engine is holding what it has, so the pump feeds
-  one character per look until it moves again.
-- **Whether `{RX}` sends a held word.** `SetMmttyPTT(1)` stops once the buffer is
-  empty. If a held word does not count as buffer, a macro whose last word has no
-  space after it loses that word.
+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,
+which would be a per-character report of what has gone out with no polling at
+all. With loopback on, which is how this station runs it, the decoded text
+arrives about 420 ms after the character goes out and matches what was sent.
 
 ```sh
 ./build.sh run --project tools/Nonemm.EngineProbe -- \
@@ -85,13 +83,6 @@ Two things the probe has still to answer, and it now asks both:
 It transmits on the sound card for about twenty seconds and keys no serial port
 unless `--ptt` names one. `EngineProbe` states what each answer means.
 
-The receive side is worth watching in the report as well. With MMTTY's sound
-loopback off, its help says the receive window is fed from the transmit window,
-which would be a per-character report of what has gone out with no polling at
-all. With loopback on it is the demodulator hearing the transmission, which
-arrives about half a second late and can carry decode errors, so the count is
-what the pump uses.
-
 **Voice keying.** `MessageSender` was written to cover a voice keyer playing a
 recording, and nothing implements it. Each operator's recordings folder is
 stored with the rest of his settings and waits on the same thing. No DVK support either, so the second radio