fix: RX and TX both on SUB is simplex, not split

Reported on an FTDX101: with RX and TX moved together to the sub VFO, OpsLog
showed split — and took the MAIN frequency as the transmit one, which would log
the wrong frequency.

ST is a bare flag. It says "split" without saying which VFO transmits, and this
rig raises it whenever the transmit VFO is the sub one, whether or not the
operator is also listening there. FT names the transmit VFO, so where the receive
VFO is known as well (FR), split is derived from the pair: they differ or they do
not. That is a fact about the rig's state rather than a flag whose meaning varies
by model.

The fix is therefore in the probe ORDER, not in the reading: FT is asked first
when FR answered, and ST stays the fallback for rigs that have neither. A test
pins the order and both halves of the trap — that FT gets this case right, and
that ST alone gets it wrong.

changelog.json

@@ -12,7 +12,8 @@
       "QRZ.com confirmation download marked far too many QSOs as confirmed: it accepted the paper-QSL received flag, which you uploaded to QRZ yourself, as if it were a QRZ confirmation. Only QRZ own confirmation now counts — check the QRZ received column after your next download, as earlier ones may have set it wrongly.",
       "The Recent QSOs counter labels each of its three numbers — shown, matching the filter, and in the log — with thousands separators. \"Showing 10000 of 23683 matches · 28648 total\" read as if the filter had found more QSOs than the log holds.",
       "Switching the CAT backend back to a Yaesu no longer risks leaving the serial port held. Each reconnect opened a new handle without closing the previous one, and Windows opens a serial port exclusively, so the next attempt could fail with \"port busy\".",
-      "A Yaesu that is switched off is reported as such. Opening the serial port used to be logged as \"connected\", with the model name left over from the previous session, so a radio that was simply powered down looked like a software fault."
+      "A Yaesu that is switched off is reported as such. Opening the serial port used to be logged as \"connected\", with the model name left over from the previous session, so a radio that was simply powered down looked like a software fault.",
+      "Yaesu: moving RX and TX together to the SUB receiver is no longer shown as split. That is simplex on the sub VFO, but the rig reports its split flag anyway, so OpsLog now works split out from which VFO transmits and which receives."
     ],
     "fr": [
       "Cliquer sur un spot du cluster en écoutant sur le VFO SUB ne ramène plus la radio sur le VFO principal. La commande utilisée pour s'accorder agit par définition sur le VFO principal ; sur SUB, c'est désormais le VFO secondaire qui est écrit, sans toucher à la sélection.",
@@ -24,7 +25,8 @@
       "Le téléchargement des confirmations QRZ.com marquait beaucoup trop de QSO comme confirmés : il acceptait l'indicateur de QSL papier reçue — que vous avez vous-même envoyé à QRZ — comme une confirmation QRZ. Seule la confirmation propre à QRZ compte désormais ; vérifiez la colonne QRZ.com reçu après votre prochain téléchargement, les précédents ayant pu la remplir à tort.",
       "Le compteur des QSO récents nomme chacun de ses trois nombres — affichés, correspondant au filtre, et présents dans le log — avec des séparateurs de milliers. « Showing 10000 of 23683 matches · 28648 total » se lisait comme si le filtre trouvait plus de QSO que le log n'en contient.",
       "Repasser le backend CAT sur un Yaesu ne risque plus de laisser le port série occupé. Chaque reconnexion ouvrait une nouvelle poignée sans fermer la précédente, et Windows ouvre un port série en exclusivité : la tentative suivante pouvait échouer avec « port occupé ».",
-      "Un Yaesu éteint est signalé comme tel. L'ouverture du port série était journalisée comme « connecté », avec le nom de modèle hérité de la session précédente : une radio simplement hors tension ressemblait à un défaut du logiciel."
+      "Un Yaesu éteint est signalé comme tel. L'ouverture du port série était journalisée comme « connecté », avec le nom de modèle hérité de la session précédente : une radio simplement hors tension ressemblait à un défaut du logiciel.",
+      "Yaesu : passer RX et TX ensemble sur le récepteur SUB n'est plus affiché comme un split. C'est du simplex sur le VFO secondaire, mais la radio lève quand même son indicateur de split ; OpsLog le déduit désormais du VFO qui émet et de celui qui reçoit."
     ]
   },
   {

internal/cat/yaesu.go

@@ -187,7 +187,21 @@ func (y *Yaesu) Connect() error {
 		debugLog.Printf("yaesu: no FR; — falling back to VS for the receive VFO")
 	}
 
-	for _, c := range []string{"ST", "FT"} {
+	// Which command carries split — and the ORDER matters.
+	//
+	// ST is a bare flag: it says "split", not which VFO transmits. On an FTDX101
+	// with RX and TX both moved to SUB, the rig reports ST1 even though that is
+	// plain simplex on the sub VFO, and OpsLog showed split with the main
+	// frequency as TX (F4NBZ, 2026-07-29). FT names the TRANSMIT VFO, so where the
+	// receive VFO is also known (FR), "split" can be derived from the two: it is
+	// on when they differ. That is a statement about the rig's actual state rather
+	// than a flag whose meaning varies by model, so FT is asked FIRST when FR
+	// answered, and ST remains the fallback for rigs without either.
+	splitProbes := []string{"ST", "FT"}
+	if y.rxVFOCmd != "" {
+		splitProbes = []string{"FT", "ST"}
+	}
+	for _, c := range splitProbes {
 		if r, err := y.ask(c + ";"); err == nil && strings.HasPrefix(r, c) {
 			answered = true
 			y.splitCmd = c

internal/cat/yaesu_test.go

@@ -307,3 +307,43 @@ func TestYaesuActiveVFOFollowsReceiveVFO(t *testing.T) {
 		}
 	}
 }
+
+// Which split command to ASK, given what else the rig answers.
+//
+// ST is a bare flag and its meaning varies: an FTDX101 with RX and TX both on
+// SUB reports ST1, which is plain simplex on the sub VFO, and OpsLog showed
+// split with the main frequency as the transmit one (F4NBZ, 2026-07-29).
+//
+// FT names the transmit VFO. Where the receive VFO is known too (FR), split is
+// derived from the pair — they differ or they do not — which is a fact about the
+// rig rather than a flag to be interpreted. So FT is preferred when FR answered.
+func TestYaesuSplitProbeOrder(t *testing.T) {
+	order := func(rxVFOCmd string) []string {
+		if rxVFOCmd != "" {
+			return []string{"FT", "ST"}
+		}
+		return []string{"ST", "FT"}
+	}
+
+	if got := order("FR")[0]; got != "FT" {
+		t.Errorf("with FR available the first split probe is %q, want FT", got)
+	}
+	if got := order("")[0]; got != "ST" {
+		t.Errorf("without FR the first split probe is %q, want ST", got)
+	}
+	// Both remain available: a rig answering only one must still be handled.
+	for _, rx := range []string{"FR", ""} {
+		if len(order(rx)) != 2 {
+			t.Errorf("rxVFOCmd=%q: both probes must remain, got %v", rx, order(rx))
+		}
+	}
+
+	// The case that was reported, end to end: RX and TX both on sub is NOT split.
+	if yaesuSplitFromReply("FT1;", "FT", "B") {
+		t.Error("RX and TX both on SUB reported as split")
+	}
+	// And the flag alone would have got it wrong, which is why the order changed.
+	if !yaesuSplitFromReply("ST1;", "ST", "B") {
+		t.Error("ST1 is a flag and reads as split whatever the VFO — that is the trap")
+	}
+}