fix: accept Hamlib's VFO-prefixed commands — JTDX could not set the frequency

MSHV worked immediately, JTDX answered "Hamlib error: Invalid parameter while
setting frequency". The two use different Hamlib dialects: MSHV sends
"F 14074000", JTDX names the target first — "F VFOA 14074000". The VFO name
landed in the slot the frequency was read from, the parse failed, and we returned
RPRT -1, which is exactly the error JTDX reported.

A leading VFO name is now stripped from every command's arguments. It costs
nothing: OpsLog follows the rig's own VFO selection, so the name carries no
information we act on — but refusing it locked out a whole family of clients.
Both dialects are covered by a test, the plain one included, since this is an
addition and must not become a swap.

A rejected frequency is also logged with the raw line now. The client only shows
"Invalid parameter", which says nothing about what it actually sent — that is
why this took a screenshot to diagnose rather than a log.

changelog.json

@@ -3,7 +3,7 @@
     "version": "0.21.9",
     "date": "2026-07-28",
     "en": [
-      "CAT sharing: OpsLog can now serve its rig connection to other programs (Settings → CAT → Share CAT). WSJT-X, JTDX, MSHV or Log4OM connect with rig model \"Hamlib NET rigctl\" at 127.0.0.1:4532 — needed because a native CAT backend holds the radio serial port on its own. Works with every backend.",
+      "CAT sharing: OpsLog can now serve its rig connection to other programs (Settings → CAT → Share CAT). WSJT-X, JTDX, MSHV or Log4OM connect with rig model \"Hamlib NET rigctl\" at 127.0.0.1:4532 — needed because a native CAT backend holds the radio serial port on its own. Works with every backend, and with both Hamlib command dialects (JTDX names the VFO, MSHV does not).",
       "Native Yaesu CAT: a new backend talks to an FTDX10/FTDX101 directly over its serial port, without OmniRig — frequency, mode, VFO A/B, split and PTT. Pick \"Yaesu (native CAT)\" in Settings → CAT. First release, feedback welcome.",
       "Changing band from OpsLog now updates the displayed frequency straight away. The rig moved, but its answer arrived inside the short grace window that protects what you are typing and was discarded — so the frequency stayed on the old band until you nudged the VFO.",
       "Bulk edit can now set the contacted station gridsquare, so a batch of QSOs imported without a locator can be corrected in one go.",
@@ -14,7 +14,7 @@
       "CQ and ITU zones you correct by hand in your profile stay corrected. They are derived from cty.dat, which gives the zones of the whole entity — in a country spanning several, the automatic value is wrong and it came back at every restart. They now only fill in when empty, and recompute when the callsign or grid changes."
     ],
     "fr": [
-      "Partage du CAT : OpsLog peut désormais servir sa liaison radio aux autres logiciels (Réglages → CAT → Partager le CAT). WSJT-X, JTDX, MSHV ou Log4OM s'y connectent avec le modèle « Hamlib NET rigctl » sur 127.0.0.1:4532 — nécessaire car un backend CAT natif occupe seul le port série. Fonctionne avec tous les backends.",
+      "Partage du CAT : OpsLog peut désormais servir sa liaison radio aux autres logiciels (Réglages → CAT → Partager le CAT). WSJT-X, JTDX, MSHV ou Log4OM s'y connectent avec le modèle « Hamlib NET rigctl » sur 127.0.0.1:4532 — nécessaire car un backend CAT natif occupe seul le port série. Fonctionne avec tous les backends, et avec les deux dialectes Hamlib (JTDX nomme le VFO, MSHV non).",
       "CAT Yaesu natif : un nouveau backend dialogue directement avec un FTDX10/FTDX101 par son port série, sans OmniRig — fréquence, mode, VFO A/B, split et PTT. À choisir dans Réglages → CAT sous « Yaesu (CAT natif) ». Première version, retours bienvenus.",
       "Changer de bande depuis OpsLog met désormais la fréquence affichée à jour immédiatement. La radio se déplaçait bien, mais sa réponse arrivait pendant le court délai qui protège votre saisie et était ignorée — la fréquence restait donc sur l'ancienne bande jusqu'à ce qu'on touche le VFO.",
       "L'édition groupée peut désormais définir le locator de la station contactée : un lot de QSO importés sans locator se corrige en une fois.",

internal/rigctld/rigctld.go

@@ -179,7 +179,7 @@ func (s *Server) handle(line string) (resp string, quit bool) {
 	if len(fields) == 0 {
 		return "", false
 	}
-	cmd, args := fields[0], fields[1:]
+	cmd, args := fields[0], stripVFOArg(fields[1:])
 
 	switch cmd {
 	case "\\dump_state", "dump_state":
@@ -200,6 +200,10 @@ func (s *Server) handle(line string) (resp string, quit bool) {
 		}
 		hz, err := parseFreq(args[0])
 		if err != nil {
+			// Logged with the RAW line: a client that phrases a command in a
+			// dialect we don't accept shows only "Invalid parameter" on its side,
+			// which says nothing about what it actually sent.
+			s.log("rigctld: cannot read a frequency from %q — client dialect not handled", line)
 			return rprt(-1), false
 		}
 		if err := s.rig.SetFreq(hz); err != nil {
@@ -275,6 +279,28 @@ func (s *Server) handle(line string) (resp string, quit bool) {
 
 func rprt(code int) string { return fmt.Sprintf("RPRT %d\n", code) }
 
+// stripVFOArg drops a leading VFO name from a command's arguments.
+//
+// Hamlib has two dialects. In the plain one a client sends "F 14074000"; in VFO
+// mode it names the target first — "F VFOA 14074000". MSHV uses the first and
+// worked immediately; JTDX uses the second, so the frequency landed in the
+// argument slot where a VFO was expected, the parse failed, and JTDX showed
+// "Hamlib error: Invalid parameter while setting frequency" (our RPRT -1).
+//
+// Accepting both costs nothing here: OpsLog follows the rig's own VFO
+// selection, so the name carries no information we act on — dropping it is not
+// losing anything, and refusing it locks out a whole family of clients.
+func stripVFOArg(args []string) []string {
+	if len(args) == 0 {
+		return args
+	}
+	switch strings.ToUpper(args[0]) {
+	case "VFOA", "VFOB", "VFOC", "VFO", "CURRVFO", "CURR", "MAIN", "SUB", "MEM", "A", "B":
+		return args[1:]
+	}
+	return args
+}
+
 // parseFreq accepts both the integer Hz and the "14074000.000000" form clients
 // send interchangeably.
 func parseFreq(s string) (int64, error) {

internal/rigctld/rigctld_test.go

@@ -93,6 +93,40 @@ func TestHandleCommands(t *testing.T) {
 	}
 }
 
+// Hamlib's VFO dialect. JTDX names the target VFO before the value — "F VFOA
+// 14074000" — where MSHV sends "F 14074000". Reading the VFO name as the
+// frequency is what produced "Hamlib error: Invalid parameter while setting
+// frequency" on JTDX while MSHV worked perfectly.
+func TestHandleAcceptsVFOPrefixedCommands(t *testing.T) {
+	rig := &fakeRig{freq: 7074000, mode: "SSB"}
+	s := New(0, rig, nil)
+
+	if got, _ := s.handle("F VFOA 14074000"); got != "RPRT 0\n" {
+		t.Fatalf("handle(\"F VFOA 14074000\") = %q, want RPRT 0", got)
+	}
+	if got := rig.Freq(); got != 14074000 {
+		t.Errorf("frequency = %d, want 14074000 — the VFO name swallowed the value", got)
+	}
+	if got, _ := s.handle("M VFOA USB 2400"); got != "RPRT 0\n" {
+		t.Errorf("handle(\"M VFOA USB 2400\") = %q, want RPRT 0", got)
+	}
+	if got, _ := s.handle("T VFOA 1"); got != "RPRT 0\n" {
+		t.Errorf("handle(\"T VFOA 1\") = %q, want RPRT 0", got)
+	}
+	// A read with the VFO named must still answer the value, not an error.
+	if got, _ := s.handle("f VFOA"); got != "14074000\n" {
+		t.Errorf("handle(\"f VFOA\") = %q, want the frequency", got)
+	}
+	// And the plain dialect must keep working — this is an ADDITION, not a swap.
+	if got, _ := s.handle("F 21074000"); got != "RPRT 0\n" {
+		t.Errorf("plain set_freq broke: %q", got)
+	}
+	// "S 1 VFOB" starts with the split flag, not a VFO: nothing must be eaten.
+	if got, _ := s.handle("S 1 VFOB"); got != "RPRT 0\n" {
+		t.Errorf("handle(\"S 1 VFOB\") = %q, want RPRT 0", got)
+	}
+}
+
 // A rig that refuses must produce an error report, not a success — a client told
 // "RPRT 0" believes the radio moved and will log the wrong frequency.
 func TestHandleReportsBackendFailure(t *testing.T) {