Next step is to add icom_rig_open to other icom rigs
This routine should work on any icom rig -- those that don't have
the ability to power up will just be ignored and should produce error if not
power up already. USB echo test should work on all icom rigs.
Some Icom rigs use USB for the CI-V connection. This can be set to echo or not. This mod permits a check of the echo state on start-up & flags the frame handling accordingly.
A new member of the icom_priv_caps is defined to flag that this check should be done. A new icom_rig_open function performs this check & sets a flag in priv_data which frame.c then uses to process the input accordingly.
So here is the first release of the new IC-R8600 rig backend.
Implemented functions so far:
set/get freq
set/get mode
functions: NB TSQL ANF NR AIP MN LOCK VSC RESUME
level: PREAMP ATT AF RF SQL NR PBT_IN PBT_OUT CWPITCH AGC RAWSTR STRENGTH
extra levels (params): ANN BACKLIGHT KEYLIGHT
Mode list: AM CW USB LSB RTTY FM WFM CWR RTTYR SAM SAL SAH
Next up:
* correct filter settings
* new digital modes
* memory store/retrieve
* correct CTCSS, DTCS handling
* correct BEEP handling (broken)
73,
Ekki, DF4OR
Do the minimum swapping and other manipulation to determine the Tx and
VFO status when setting the split frequency and mode.
TODO - other funcitons.
The strategy to determine the current VFO at the start of a set or
query sequence of the split transmit VFO should not switch back to the
Rx VFO unless it is certain that it was current at the start of the
sequence.
This implementation reduces the number of VFO excahnges or sets to a
minimum when setting the TX VFO frequency and mode together.
This also includes a much smarter implementation of the logic used
when the new config option 'no_xchg' is enabled. Now it is able to
accurately determine the original VFO selected and leaves the
sequences with the same VFO selected. There is one corner case when
both VFOs are identical (frequency, mode and width) at the start where
it has to take a guess as to the selected originally VFO (Icom CAT
protocol has no command to elicit this information). In that case it
guesses as the last VFO selected using Hamlib. Applications can gain
absolute certainty by setting the VFO themselves prior to using the
rig_{set,get}_{split,}_{freq,mode,freq_mode}() function series. This
now gives seamless TX VFO configuration without any relay clattering
or TX/RX audio glitches.
Only ask Icom rigs once then desist if bandwidth request returns
command rejected. This avoids sending the request with every mode
query and possibly retrying 'retries' times for rigs that do not
suport the '1a 03' command which wastes much time at slow baud rates.
With Icom rigs that use MAIN?SUB VFOs there is a trade off when
setting the mode or frequency of the "other" VFO. Untill now Hamlib
uses the XCHG VFO command to address the "other" VFO. This has some
advantages, particularly it preserves the selected VFO and it
preserves memory mode of either VFO. The disadvantage is that any
split command causes the Rx to glitch when the VFO/MEMs are exchanged.
I have added a config parameter for Icom rigs called "no_xchg" which
forces the direct addressing of VFOs to set split mode/frequency. It
is a boolean option with a default of "0" (false) which equates to
prior behaviour. Setting it to "1" (true) will make the backend use
change VFO commands to set the "other" VFO. This means that TX on
"SUB" in split is assumed, that both are in VFO mode (not MEM), and
set/get split functions will leave the MAIN VFO selected.
From Martin, CT1IQI:
"Several programs under Linux rely on Hamlib for control. I wanted to
try WSJT-X (digital modes like JT65) and found that my new IC-7100 was
not yet supported, also after having compiled the current git version of
Hamlib and having compiled WSJT-X against that.
So I added a IC-7100 by taking the ic-7200 and 7420 rig files as
example, be it without going (yet) through all of the very many commands
the ic-7100 supports.
This produced the situation where there was communication, e.g. setting
and reading frequencies, but the PTT control did not work. I debugged
that to actually the lack of a PTT mode in Hamlib that uses serial and
CAT at the same time; currently PTT per 'serial' seems equivalent to
toggling certain RS232 pins but not to any serial command level. So I
added a RIG_PTT_SERIAL_CAT mode for PTT control. Now the wsjt-x program
works nicely with the ic-7100 and controls both frequency and PTT via
the single USB cable."
Signed-off-by: Nate Bargmann <n0nb@n0nb.us>