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
+36
View File
@@ -5,6 +5,7 @@ import (
"os"
"path/filepath"
"sync"
"sync/atomic"
)
// LogSink, when set by the host app at startup, receives every CAT debug
@@ -73,3 +74,38 @@ func DebugLogPath() string {
}
return filepath.Join(base, "OpsLog", "cat.log")
}
// ── CI-V byte trace ────────────────────────────────────────────────────────
//
// Opt-in, off by default. Turning it on logs every CI-V frame sent and received
// as hex, exactly like the WinKeyer protocol trace.
//
// That trace exists because a fault nobody could reason about — "the keyer sends
// one element then stalls" — was settled in one line the moment the actual bytes
// were visible. The CI-V link has now produced the same class of report: a MOX
// button that sets split instead of transmitting, on a rig whose PTT command is
// demonstrably correct in the source. Guessing at that from the command table
// has already cost this project a wrong fix; the bytes will say what the rig was
// really asked.
var civTrace atomic.Bool
// SetCIVTrace turns the CI-V byte trace on or off.
func SetCIVTrace(on bool) {
civTrace.Store(on)
if on {
debugLog.Printf("civ trace ON — every CI-V frame to and from the rig is logged")
} else {
debugLog.Printf("civ trace OFF")
}
}
// CIVTraceEnabled reports whether the trace is running (for the settings UI).
func CIVTraceEnabled() bool { return civTrace.Load() }
// traceCIV logs one frame. dir is "TX" (to the rig) or "RX" (from it).
func traceCIV(dir string, b []byte) {
if !civTrace.Load() || len(b) == 0 {
return
}
debugLog.Printf("civ %s % X", dir, b)
}