rouggy/OpsLog
0
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 50 Wiki Activity

docs: name PC KEYING = DAKY, the setting that should enable CAT keying

Browse Source 
The operator found the menu I said to look for: it offers DAKY, RTS and DTR. KY
is the CAT route, so DAKY is the setting that would enable it — which makes my
previous "this rig has no CAT keying command" too strong a claim to leave
standing, since it was drawn from a refusal at the DEFAULT setting.

The error and the settings hint now name DAKY first, and keep the serial line
keyer as the fallback. That order matters: the CAT route costs nothing, the
fallback costs a second COM port.

Marked as untested rather than verified — I have no confirmation that DAKY makes
KY work on this model, only that it is the option that should.
This commit is contained in:
rouggy
2026-07-29 13:23:22 +02:00
parent e120bd4f04
commit b0b25c7f1f
3 changed files with 20 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files
internal/cat/yaesu_cw.go
+16 -13
View File
@@ -13,12 +13,14 @@ package cat
//
// The leading SPACE after KY is part of the command, not padding.
//
// Verified on: an FTDX10 REFUSES this — it answers "?;" to both KY; and KY <text>;,
// so that model has no CAT keying command at all and needs the serial DTR keyer
// on its second COM port instead. The code stays because KY is documented for
// the FTDX101 / FT-991A / FT-710 family; it now says so plainly when refused
// rather than failing silently. STOP is the other uncertain half: Yaesu
// documents no buffer-clear, so see StopCW.
// Observed on an FTDX10 (2026-07-29): it answered "?;" to both KY; and
// KY <text>; with PC KEYING left at its default. That rig's CW menu offers
// DAKY / RTS / DTR, and KY is the CAT route, so DAKY is the setting that should
// enable it — untested at the time of writing. When the rig refuses, the error
// says so and names both that setting and the serial line keyer as the fallback,
// rather than failing silently.
//
// STOP is the other uncertain half: Yaesu documents no buffer-clear, see StopCW.
import (
"errors"
@@ -120,13 +122,14 @@ func (y *Yaesu) drainCWReply() error {
frame := strings.TrimSpace(string(buf[:i+1]))
buf = buf[i+1:]
if frame == "?;" {
// Confirmed on an FTDX10 (2026-07-29): it answers "?;" to KY, so this
// rig simply has no CAT keying command — it is not a setting to find.
// The message therefore names the way that DOES work rather than
// sending the operator hunting through menus.
return fmt.Errorf("this rig does not accept CW over CAT (it answers \"?;\" to KY). " +
"Use the \"Serial port (DTR=CW / RTS=PTT)\" keyer on the rig's OTHER COM port — " +
"the standard one, while CAT keeps the enhanced one")
// Observed on an FTDX10 (2026-07-29). Its PC KEYING menu offers DAKY,
// RTS and DTR: KY is the CAT route, so DAKY is the setting that would
// enable it — worth naming, since the alternative costs the operator a
// second COM port. If DAKY does not help, the line keyer does.
return fmt.Errorf("the radio refused the CW keying command (it answered \"?;\" to KY). " +
"Set PC KEYING to DAKY in the rig's CW menu; if that does not help, use the " +
"\"Serial port (DTR=CW / RTS=PTT)\" keyer on the rig's other COM port (the standard " +
"one) with PC KEYING set to DTR, while CAT keeps the enhanced port")
}
debugLog.Printf("yaesu cw: rig answered %q to KY — ignoring", frame)
}