radio_io: say when radio_device is the wrong kind of port for the rig (#179)

[rafael2k]

Closes the diagnosis half of #179.

A FlexRadio (SmartSDR, model 23005) is a network rig: Hamlib wants an address in rig_pathname and appends its own default port. Configured with radio_device = COM4, Hamlib built "COM4:4992", failed to resolve it, and returned Invalid parameter — which sent the reporter looking at baud rates and CAT ports instead of at the address he actually needed.

Nothing in Mercury told him the rig was a network rig. Three things now do.

Before / after

# before
[ERR] rig_open: error = COM4 rig_test_2038: enter _TIME_BITS=64, __TIMESIZE=64 …
      (…hamlib's whole debug ring buffer…)

# after
[WRN] radio_device='COM4' looks wrong for SmartSDR Slice A -- this rig is reached
      over the NETWORK, not a serial port: set radio_device to the radio's address
      (e.g. 192.168.1.50, or 192.168.1.50:4992 to override the port).
      radio_serial_speed does not apply.
[ERR] rig_open(COM4) failed: Invalid parameter (-1)

and -K gains a Port column, so the port kind is visible at the moment you pick the model number:

 Rig #  Mfg          Model              Version      Status   Port    Macro
     2  Hamlib       NET rigctl         20240418.0   Stable   net     RIG_MODEL_NETRIGCTL
  1049  Yaesu        FT-710             20241118.7   Stable   serial  RIG_MODEL_FT710
 23005  FlexRadio    SmartSDR Slice A   20240814.0   Stable   net     RIG_MODEL_SMARTSDR_A

Changes

• -K shows the port kind (serial / net / usb).
• radio_serial_speed is only pushed at serial rigs. It was sent unconditionally, so every network rig logged rig_set_conf(serial_speed) failed: -1 — alarming, and a waste of the one signal that says this is not a serial rig at all.
• radio_device is checked against the rig's port kind before rig_open, with the advice repeated next to the failure (the pre-flight line is easily lost in Hamlib's backend chatter).
• rigerror2() instead of rigerror() — the latter appends Hamlib's debug ring buffer, so above log level 0 the actual reason is buried.
• Dead rig_state lookup removed (separate commit): rs was assigned and never read — gcc has been warning about it — and its fallback arm dereferenced radio->state, which Hamlib 5 removed. It was the only thing in radio_io.c that would not compile against 5.

The check is advisory only

It matches the device string by shape, and a shape heuristic must never veto a configuration that would in fact have worked — so Hamlib still gets to try either way. test_radio_port leans on the false-positive side accordingly: bare and bracketed IPv6, rigctld host:port, \\.\COM12, /dev/serial/by-id/... and an unset device all have to stay silent, and COMPUTER / com.example.net must not read as COM ports.

Hamlib 5

Port kind and model name are read via rig_get_caps_int() / rig_get_caps_cptr() rather than rig->caps->…, for the same reason the conf tokens are already preferred over rig->state.rigport: accessors keyed on the model number don't depend on a struct layout Hamlib 5 is progressively closing off.

Verified with -fsyntax-only against Hamlib 5.0.0~git (a475dad9d): radio_io.c and rigctl_parse.c both compile with 0 errors (before this branch, radio_io.c failed on radio->state). All three symbols used are declared in Hamlib 5's rig.h and exported by the vendored w64/macOS libs. Still builds and behaves on the 4.6.2 we ship against.

Testing

• make test — 234 pass (8 new in test_radio_port)
• go test -count=1 in tests/integration — PASS
• Ran the reporter's exact config (-R 23005 -A COM4) and his fix (-A 192.168.1.50); the latter draws no warning. Serial rig + /dev/ttyUSB0 also stays silent.

Not addressed here

• No ptt_pathname / ptt_type config. The reporter has "COM5 for PTT only on RTS"; Mercury can't express that. Harmless for his Flex (SmartSDR keys over the network) but a real gap for split CAT/PTT setups.
• No Windows or radio-setup guide in docs/ — he asked, and the answer is currently no.

🤖 Generated with Claude Code