v3.0.0b20

Added

• rigctld split frequency and mode for WSJT-X "Split: Rig" (MOR-3115,
  #4275, #4323). I/i and X/x set and read the unselected VFO's
  frequency and mode on the IC-7300, IC-7300MK2 and IC-705 without
  selecting that VFO, using the profile's set_/get_unselected_freq and
  set_/get_unselected_mode commands (26 01 for the mode). X sets the requested mode and fills DATA and the filter field
  by field: an ordinary mode keeps the VFO's current DATA setting, a packet
  mode (PKTUSB, PKTLSB, PKTRTTY) turns DATA on; an omitted or 0
  passband keeps the VFO's current filter, a positive passband selects filter
  1 (2800 Hz and up), 2 (2000 Hz and up) or 3. Whenever X keeps the current
  DATA or filter it reads them first; a VFO selection, swap or equalize
  through the runtime's own methods between that read and the write refuses
  X with RPRT -9. Known limitation: a raw w frame or another X from a
  second client that changes the same VFO between that read and the write can
  make X write the wrong DATA/filter back, and DATA also selects the TX
  audio source; a packet mode with a positive passband sets both fields
  itself and is not affected (tracked in MOR-3743, see
  docs/release-notes/2026-beta-known-limitations.md).
• Local audio bridge input and output gains (#4023, #4024).
  rigplane audio bridge takes --input-gain-db and --output-gain-db,
  rigplane web takes --bridge-input-gain-db and
  --bridge-output-gain-db (all default 0 dB), and PATCH /api/v1/bridge
  changes the running bridge. The gains apply to local device audio only.

Fixed

• A CW text send a stop or force-off ends gets a defined answer
  (MOR-3700). A pending send_cw_text that a CW stop ended answered HTTP
  500 with the transport's "Managed Yaesu CAT write is no longer current",
  and one a managed force-off ended got no answer at all: the HTTP
  connection closed and the WebSocket command never got a response. Both
  now answer HTTP 409 with error: "command_cancelled" and a message
  naming the cause (CW text send to <model> was cancelled by a CW stop /
  ... by a transmit abort); the WebSocket command answers ok: false
  with the same code and message, and the CLI prints Error: <message>
  and exits 1. The same holds for send_cw_text on POST /api/v1/commands
  and for Icom (CI-V) sends a force-off ends (a CW stop does not end a
  CI-V send in progress). See the refusal table in docs/api/web.md.
• Radio profiles name their CW modes in one place (MOR-3679, MOR-3678).
  Clients guessed CW mode names and missed the FTX-1's CW-U/CW-L, so
  the Pro CW console never left "Waiting for CW mode". A profile can now
  declare [modes] families = { cw = [...] }; the loader rejects a member
  that is not in [modes].list or is listed twice, and /api/v1/info and
  /api/v1/capabilities publish it as modeFamilies ({} when absent).
• FTX-1 CW text: no invalid KY <text>; frames; cwText capability
  (MOR-3678). The FTX-1 backend sent typed CW text as KY <text>; in
  24-character chunks and stopped with KY ;; neither is a valid FTX-1 CAT
  frame (CAT manual 2508-C printed p.18: KY P1 P2; plays a keyer memory).
  It now writes the text with KM into a keyer memory channel and plays it
  with KY, and stops with KY00;. Sending stays disabled on the FTX-1
  until the memory type is checked on a radio. A new profile section
  [cw_text] (supported, max_length, memory_channel, memory_type)
  is published as cwText inside capabilities on /api/v1/info and at
  the top level of /api/v1/capabilities; hasCw and the cw tag are
  unchanged. One check in every radio's send_cw_text enforces it, so
  HTTP, WebSocket and the CLI refuse the same requests with the same
  message; the web handler's own 512-character limit is gone (512 is now
  only the profile default). Profiles without a send_cw command (TX-500,
  X6100, X6200) publish supported: false. Yaesu CAT and Kenwood CAT
  profiles without [cw_text].supported = true publish supported: false;
  a Yaesu enable without keyer memory channel 1-5, a max_length of at
  most 50 (one KM write) and writable KM/KY commands, or any Kenwood
  enable, does not load. The cw tag no longer gates sending or stopping
  CW text over HTTP, WebSocket or the CLI; cwText alone decides. A
  backend with no CW text sending (external rigctld) answers all three as an
  unsupported command, and a rig profile that does not load is reported by
  every CLI path (including --model and audio probe) as Error: <file>: <key> ..., exit 1. cwText.supported is false when the active backend
  cannot send CW text (external rigctld), with the profile's limits kept.
• The RF front-end preamp buttons show the profile's preamp labels
  (#4029). The semantic RF front-end passes the profile's preamp labels
  through to the buttons instead of always showing P1/P2; a profile
  without labels keeps P1/P2. The FTX-1 declares IPO/AMP1/AMP2.
• IC-9700 attenuator is the documented 10 dB step (#4027). The profile
  declared [0, 20], so the ATT control sent CI-V 11 20, which the IC-9700
  CI-V Reference Guide does not list; it now declares [0, 10] (11 10).
  Not yet exercised on an IC-9700. This entry is missing from
  docs/CHANGELOG.md for 3.0.0b20 and will be added there with the next change.
• IC-705 reads its duplex offset with CI-V 0C (MOR-3624, #4295). The
  profile mapped the read to 0D, the send opcode, which the radio NAKs;
  writes still use 0D.
• Serial connections try the other CI-V baud rates after silence
  (MOR-3620, #4302). A radio set to another baud rate can now be found
  with a read-only identity retry, with a notice naming the rate found (a rate below 115200 warns that the
  scope needs 115200); if none answers, the profile baud is restored and the
  diagnostics name the likely causes.
• Packet receives with a timeout are cancellation-correct (MOR-3575,
  #4282). The audio bus and the transport now receive packets through
  asyncio.timeout.