feat: CI-V byte trace, for a fault the command table cannot explain

Reported on an IC-9100: the MOX button does not transmit, it sets split. The
source sends the PTT command (0x1C 0x00) and nowhere sends the split one (0x0F),
so the discrepancy is between what OpsLog sends and what the rig acts on — and
that link has already been shown, in the same operator's log, to lose frame sync.

Rather than guess from the command table, this adds what settled the WinKeyer
bug in one line: the actual bytes. Settings → CAT → Log the CI-V protocol writes
every frame in both directions as hex. RX is traced BEFORE framing, since the
bytes as they arrived are what reveals a lost boundary — a decoded view would
hide exactly the fault being hunted.

Session-only, like the keyer trace: it is a diagnostic, and a log full of hex
helps nobody who forgot it was on.

I am not claiming a cause yet. The last time I inferred one from a protocol
document rather than from evidence, I inverted a digit and broke the case that
worked.
This commit is contained in:
2026-07-30 14:30:05 +02:00
parent ef84b04c99
commit 75c02ea2a0
8 changed files with 76 additions and 5 deletions
+11
View File
@@ -14428,6 +14428,17 @@ func (a *App) SetWinkeyerTrace(on bool) {
winkeyer.SetTrace(on)
}
// SetCIVTrace turns the byte-level CI-V trace on or off.
//
// Same reasoning as the WinKeyer trace, and prompted by the same shape of
// report: an IC-9100 whose MOX button sets split instead of transmitting, while
// the source demonstrably sends the PTT command (0x1C 0x00) and not the split
// one (0x0F). Something between the two is not what it appears, and on a link
// already shown to lose frame sync, the bytes are the only witness.
func (a *App) SetCIVTrace(on bool) {
cat.SetCIVTrace(on)
}
// WinkeyerConnect opens the serial link using the saved config.
func (a *App) WinkeyerConnect() error {
if a.winkeyer == nil {