ericek111/Nonemm
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Let MMTTY hold the text waiting to go out, behind a setting

Browse Source 
MMTTY has a type-ahead buffer of its own: characters go into it, a backspace
takes back one it has not transmitted, and TxBufLen says how many are left. Used
that way it paces itself, so there is no gap between characters to tune and no
baud rate to keep in step with the engine.

EngineTypeAhead does that, and Config > Digital picks between it and the pump
that is there now. Off is still the default: three things it rests on have never
been seen with a real engine.

tools/Nonemm.EngineProbe asks the engine those three questions and writes the
answers to a file. It starts MMTTY through the bridge, pushes a message, polls
TxBufLen while it goes out, backspaces over text that has and has not been
transmitted, and logs what came back on the receive side and when.

The bridge learns one verb for it: `buffer` reads TxBufLen and answers with the
count, or -1 when the control will not say. A property the control does not know
is a log line rather than an error, since it stops nothing.

TypeAhead and EngineTypeAhead share the TransmitBuffer interface, which is what
the digital window now works through, so the window does not know which one it
has.

docs/unfinished.md states what each buffer assumes and how to run the probe.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RtspmWmS7f8kUvcyaHpRWZ
This commit is contained in:
ericek111
2026-09-01 22:41:18 +00:00
parent da7f7fb3f5
commit 54b9181c06
25 changed files with 1311 additions and 68 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
docs/digital-bridge.md
View File

@@ -32,6 +32,7 @@ To the bridge:
| `send <text>` | `SendString` |
| `ptt <0\|1>` | `SetMmttyPTT` |
| `post <message> <parameter>` | `PostMmttyMessage`, for everything in `MmttyMessage` |
| `buffer [property]` | reads `TxBufLen`, or the property named instead, and answers `buffer` |
| `close` | shuts the engine down and leaves the bridge running |
| `quit` | shuts the engine down and exits |
@@ -46,9 +47,17 @@ From the bridge:
| `tx <0\|1>` | the engine started or stopped transmitting |
| `mark <hz>`, `space <hz>` | the tone pair moved |
| `switch <bits>`, `view <bits>` | AFC (4), net (8) and reverse (256), and the engine's view state |
| `buffer <n>` | how many characters the engine still has to transmit, or -1 when the control would not say |
| `log <text>`, `error <text>` | anything the bridge has to say |
Each of those comes from an event of the control's own: `OnCharRcvd`,
`buffer` is the one thing that is asked for rather than reported: the control
has no event for the length of the transmit buffer, so it is polled. A property
name in the request is only for finding out what the control answers to; a name
it does not know fails with `DISP_E_UNKNOWNNAME`, which comes back as a `log`
line and `buffer -1` rather than an `error`, because a property the control will
not answer stops nothing.
Each of the others comes from an event of the control's own: `OnCharRcvd`,
`OnPttEvent`, `OnFreqChanged` (mark and space in one event), `OnSwitchChanged`
and `OnViewChanged`. The control raises `OnTranslateMessage` only for the
MMTTY messages it has no event for — width, resolution, thread and the like —