Kenwood and Xiegu

Kenwood and Xiegu (native CAT)

Kenwood (USB, network)

A native backend talks straight to a TS-590 / TS-890 / TS-990 / TS-2000 over its serial port — frequency, mode, VFO, split and PTT, no OmniRig in between. Elecraft K3/K4 speak the same dialect. Pick Kenwood (USB, network) in Settings → CAT.

• Serial: COM port + baud.
• Network: give a host:port instead — for a serial bridge (ser2net, an Ethernet-serial adapter). Not the radio's own RJ45, which speaks Kenwood's KNS/ARCP protocol.
• Split is detected from FR/FT when the radio omits it from its status frame.
• The backend was tested end-to-end against a TS-2000 emulator and reports useful errors: a port that opens but stays silent is distinguished from one sending data that never answers (the error quotes what arrived).

What to send for a data mode

There is no single command that fits every rig in this family, so it is a setting (Data mode command) rather than a guess:

Rig	Pick
Elecraft K3 / K4	DATA (MD6) — this is what they want.
TS-590SG / TS-990S	USB, or safest Leave unchanged: on these the data mode is a modifier of USB, set on the radio itself.

Do not send MD6 to a plain Kenwood (TS-590 / TS-990) — it lands on FSK/RTTY.

The radio's own RJ45

The network option above is a serial bridge carrying the same CAT commands over TCP. The radio's built-in LAN port is a different thing: KNS/ARCP is a session with its own framing and login, not the CAT byte stream in a socket, so it has to be implemented per radio and against a real one. Not supported yet — use USB or a serial-to-Ethernet bridge.

It is also not Hamlib. Port 4532 is rigctld, another protocol again, and it is the one OpsLog itself serves under Share CAT.

The console

Shared with the Elecraft backend — a K3 speaks this dialect and the panel reads whatever answers. Beyond the meters, power, volume, filter and RIT/XIT:

• Monitor — a level rather than a switch on these radios, where 0 is off. The top of the scale is the radio's own: 60 on an Elecraft, 20 on a TS-590SG.

• NB level — 1-10 on a Kenwood, 0-21 on an Elecraft.

• NR level — Kenwood and K4, 1-10.

  A K3 has no noise-reduction command at all: it is a menu setting on that radio, so the row is left out rather than drawn dead. A K4 does have one — in fact two, LMS and SSNR — and OpsLog does not offer them yet.

The two levels only appear while their switch is on, because both radios answer an error when asked for a level whose function is off — there would be nothing current to show.

Xiegu (G90, X6100, X6200, X5105)

These radios speak CI-V but with a reduced command set (no scope, no DSP block, no data mode), so they have their own backend — pick Xiegu (USB) in Settings → CAT. Frequency, mode, split and PTT.

PTT on a G90 — read this

A G90 ignores the CI-V PTT command. That has three consequences:

1. In the Xiegu settings, choose how the rig is keyed: CI-V command, RTS or DTR — pick the hardware line your interface wires to PTT.
2. WSJT-X & co transmit through OpsLog's shared CAT link (Hamlib NET rigctl 127.0.0.1:4532 — see CAT Control): OpsLog converts the PTT request into the hardware line. This is the supported path and it works.
3. WSJT-X + OmniRig will NOT transmit a G90: OmniRig sends PTT as a CI-V command, which the radio ignores. Either use the native Xiegu backend + rigctl sharing, or configure the PTT line (RTS/DTR) inside OmniRig itself.

Keying on connect

Behind an interface that carries PTT on a modem line (e.g. a DE-19), a G90 used to go straight into transmit when OpsLog connected — Windows raises DTR and RTS when a serial port opens. The Xiegu backend now drops both lines on connect, then drives only the line you selected for keying.

Notes

• Both backends refuse a CI-V/CAT frame read at the wrong offset, so a garbled answer can no longer turn into a phantom frequency.
• The protocol trace (Settings → CAT) covers both — see CAT Control.