ftx1_set_rptr_offs() converted the requested offset into the EX menu's
step count with a truncating integer division, so any offset that was
not an exact multiple of the step was silently programmed as a smaller
one, with nothing returned to tell the caller it had been changed.
Round to the nearest step instead.
Also reject a negative offset up front. The offset is a magnitude --
direction comes from set_rptr_shift -- and truncation towards zero
meant a small negative value was accepted as "no offset" rather than
rejected, while a larger one failed later in the menu range check.
Verified on an FTX-1 (Optima) on 144 MHz, with #2110 applied so the
step is the correct 50 kHz:
set_rptr_offs 625000 -> 650000 (exactly half a step, rounds up)
set_rptr_offs 630000 -> 650000
set_rptr_offs 620000 -> 600000
set_rptr_offs 624999 -> 600000
set_rptr_offs 600000 -> 600000 (exact, unchanged)
set_rptr_offs -600000 -> -RIG_EINVAL, menu value left untouched
The truncation is present independently of #2110 -- that PR only makes
it easier to hit by correcting the 144/430 MHz step to 50 kHz.
(cherry picked from commit 335820ad0a)
On the FTX-1, WFM is a bit special: Inside the 76-108 MHz WFM band the
radio is set to WFM by sending the normal FM mode code (MD...4), and
when read back the MD reply carries P2='0', which newcat_get_mode cannot
map and so returns -RIG_EPROTO. Override get_mode/set_mode with ftx1
wrappers:
- ftx1_get_mode: on -RIG_EPROTO with mode '0', verify the current VFO
frequency falls in a WFM rx range (rx_range_list), and if so report
RIG_MODE_WFM instead of the protocol error.
- ftx1_set_mode: when asked for RIG_MODE_WFM, reject it (-RIG_EINVAL)
outside the WFM range, and inside the range translate it to
RIG_MODE_FM with RIG_PASSBAND_NOCHANGE (let the radio apply its WFM
bandwidth).
- ftx1_check_freq_wfm(): helper scanning rx_range_list for a WFM-typed
entry covering the given frequency.
(cherry picked from commit 2d1974a748)
Correct several issues in the FTX-1 CTCSS/DCS implementation:
* Add DCS code table (ftx1_dcs_codes[]) and index<->code conversion
helpers (ftx1_code_to_dcs_num/ftx1_dcs_num_to_code). Previously
set_dcs_code/get_dcs_code passed the raw DCS code value (e.g. 023)
directly to the CN command, which expects a 0-based table index
(000-103). The code value is now converted to/from the index on
set/get respectively.
* Fix CN command parameter documentation. P1 is the VFO selector
(0=Main/1=Sub), not a TX/RX selector as previously stated.
* Simplify set/get_ctcss_sql to delegate to set/get_ctcss_tone, and
set/get_dcs_sql to delegate to set/get_dcs_code. The FTX-1 does not
support separate TX/RX tones or DCS codes, so the previous
CN10/CN11 (Sub VFO) usage was incorrect.
* Add RIG_FUNC_CSQL support in set_func/get_func and rig caps,
mapping it to the CT3 (DCS) mode via FTX1_CTCSS_MODE_DCS.
(cherry picked from commit 3f3e4becb3)
to_hex() left non-empty destination buffers untouched when the source
length was zero. Initialize the output string before returning and cover
the empty conversion in testbcd.
(cherry picked from commit 439f91fa28)
PMR-171 and Q900 can return the private filter width when a mode query
falls back to cached state. Initialize it to RIG_PASSBAND_NORMAL during
backend setup.
(cherry picked from commit 951ff93651)
Malformed K3/K3S SW and K4 TM replies could leave parsed meter
fields uninitialized. The K4 SWR path also discarded helper failures.
Reject incomplete conversions with RIG_EPROTO and return K4 transaction
and parse errors to callers.
(cherry picked from commit 900c4d354e)
The raw value of frequency offset for 144 MHz and 430 MHz band is in
50 kHz unit, and the available range is from 0 to 100 MHz.
Tested on real hardware.
Fixes: 2c0ba29d53 ("FTX-1: Fix capability gaps - DCD, CWPITCH, RPTR_OFFS, BAND_UP/DOWN")
Signed-off-by: Miao Wang <shankerwangmiao@gmail.com>
(cherry picked from commit e0c8de6936)
dummy_get_level() copied a full value_t into result pointers even when
rig_get_strength() passed an int-sized buffer, overflowing the caller.
Copy only the integer or float member selected by the level while
retaining memcpy() for targets with weaker alignment.
Fixes: 5805de6e1e ("dummy/dummy.c: Fix unaligned access in dummy_get_level()")
(cherry picked from commit ee57b43282)
Concurrent calls to rig_debug() could use the same temporary buffer
and corrupt the saved debug history.
Give each call its own buffer and update the shared history under the
existing mutex.
(cherry picked from commit cf3fcc4b8a)
Hardware-verified on an FTX-1 + ATAS-120A: with an ATAS selected, the general
AC000 stop is rejected ('?'), and because newcat does not read the AC reply
that '?' leaked into the next command. Route RIG_FUNC_TUNER off by the active
antenna's tuner type — AC120 for ATAS, AC000 otherwise — matching rad-con.
(cherry picked from commit 9fe116a417)
ftx1_set/get_tuner claimed "AC is status-only", gated everything behind
SPA-1, wrote 0/1 into EX030104 (the general select, not an on/off), and
returned ENIMPL for tune. Replace with the hardware-tested AC model:
- get_tuner: read AC and report P3 != '0' (tune active), like rad-con
Power.isTuning(); no SPA-1 gate.
- set_tuner: mode 0 -> AC000 (stop/bypass); mode 1 -> no-op (the FTX-1 has no
persistent tuner-on toggle; select type via ext-parms, tune via RIG_OP_TUNE).
- Add ftx1_atas_ctrl() (AC120 stop / AC121 up / AC122 down / AC123 start),
mirroring rad-con's AtasTunerProvider, exposed as the write-only ATAS_CTRL
ext-parm (synthetic non-menu token, dispatched directly).
(cherry picked from commit af6165a8b2)
The driver conflated GENERAL TUNER SELECT (EX030104, 0=Option/1=ATAS) with
the per-antenna tuner type (EX030701/2, 0=INT/1=INT_FAST/2=EXT/3=ATAS) and
gated EXT/ATAS selection + HF antenna select behind SPA-1. On a field head
(or any head with an ATAS/EXT antenna) that wrongly blocked tuner setup.
- GEN_TUNER_SELECT: range 0-3 -> 0-1 (Option/ATAS), in both the menu table
(set-time validation) and the ext-parm descriptor (caps.extparms).
- OPT_TUNER_ANT1/ANT2 + OPT_HF_ANT_SEL: drop FTX1_MENU_FLAG_SPA1 — EXT/ATAS
tuning and antenna select work on any head; only INT/INT_FAST need SPA-1,
which the radio enforces itself. Power-limit items (EX030705-11) stay gated.
- Fix the ftx1_ext.c guardrail (EX030104 no longer SPA-1-gated; the OPTION
gate now applies only to power items >= 5) and the header/tuner_select docs.
Menu model hardware-verified on an FTX-1 + ATAS-120A: EX030704=ANT1,
EX030701=ATAS matched the physical setup.
(cherry picked from commit 771b5b3c3c)
RIG_OP_TUNE sent AC110, which the radio rejects with '?;' (P3=0 is
off/stop, not a tune start) — so `vfo_op TUNE` never tuned. Verified on an
FTX-1 + ATAS-120A: AC110 -> '?;' while AC123 starts an ATAS auto-tune.
Send the tune form for the tuner type selected on the active antenna:
AC123 (P2=2 ATAS, P3=3 start) for ATAS, AC103 (external-port start) for
INT/INT_FAST/EXT, defaulting to AC103 on read failure. Drop the SPA-1 gate
here: EXT/ATAS tune on any head type; only INT/INT(FAST) need SPA-1, which
the radio enforces itself.
Add ftx1_get_effective_tuner_type() (active antenna EX030704 -> per-antenna
type EX030701/2), mirroring the hardware-tested rad-con model.
(cherry picked from commit 76427ee7b4)
Misplaced close-paren in if statement caused "IF" command to be cached,
even if rig settings were changed. Note that the last if-clause would
never be evaluated as true due to the strlen() in the first clause.
(cherry picked from commit 1a46034995)
Add TS-790 to rigs needing change FR->FN, and make it mutually exclusive
to addition of ";FT#".
Part of issue #2084
(cherry picked from commit d633ccf263)
Will allow rigctl_parse() routines access to connection data, without
reworking all of the internal and external interfaces.
(cherry picked from commit b56f8d8f8a)
