fix: read the FIRST digit of the Yaesu VFO reply — I inverted it yesterday

Reported both ways round, which is what settles it. With RX and TX on SUB
everything worked; with them on MAIN the frequency froze and a spot click tuned
the sub VFO. The log shows the rig answering FR01 in the MAIN case.

So on an FTDX101 the state is the FIRST digit — 0 = main — and the second is a
separate parameter. Yesterday I changed this to the LAST digit, which read FR01
as SUB and inverted the whole thing. The fault that change was meant to fix ("SUB
shows MAIN") came from reading VS instead of FR, and probing FR had already fixed
it on its own; the digit change was an unnecessary guess layered on a real fix.

Nothing else needed changing for the operator's two questions: the display and
SetFrequency already follow curVFO, so a spot now tunes whichever VFO holds RX
and TX, and the main frequency is read when on main. A test states that in those
terms — active VFO and which command a spot writes — rather than only as a byte,
because the byte is what I got wrong while believing the logic was right.
This commit is contained in:
2026-07-29 21:39:22 +02:00
parent f3807c21ba
commit 6501e97895
3 changed files with 71 additions and 31 deletions
+13 -16
View File
@@ -506,27 +506,24 @@ func yaesuModeDigit(mode string, freqHz int64) byte {
}
}
// yaesuStateDigit returns the STATE digit of a reply — the last digit before the
// terminator — or 0 if the reply does not belong to this command.
// yaesuStateDigit returns the STATE digit of a reply — the FIRST digit after
// the command — or 0 if the reply does not belong to this command.
//
// The parameter is not always one character. An FTDX101 answers "FR01;" where an
// FTDX10 answers "FR0;", and reading the FIRST digit took the 0 of "01" as the
// answer: the rig was on SUB and OpsLog said MAIN, showing the main frequency and
// making the split flip on alternate polls (F4NBZ, 2026-07-29). The last digit is
// the state on both, so it is what gets read.
// The parameter is not always one character: an FTDX101 answers "FR01;" where an
// FTDX10 answers "FR0;". The state is the FIRST digit in both; the second is a
// separate parameter. Reading the LAST digit inverted it — with RX and TX on
// MAIN the rig answered FR01, OpsLog concluded SUB, the main frequency stopped
// updating and a spot click tuned VFO B (F4NBZ, 2026-07-29). That was my own
// correction of the previous evening, made the wrong way round: the earlier
// "SUB shows MAIN" fault came from reading VS, not from this digit.
func yaesuStateDigit(reply, cmd string) byte {
r := strings.TrimSpace(reply)
if !strings.HasPrefix(r, cmd) {
if !strings.HasPrefix(r, cmd) || len(r) <= len(cmd) {
return 0
}
r = strings.TrimSuffix(r, ";")
digits := r[len(cmd):]
if digits == "" {
d := r[len(cmd)]
if d < '0' || d > '9' {
return 0
}
last := digits[len(digits)-1]
if last < '0' || last > '9' {
return 0
}
return last
return d
}