kopia lustrzana https://github.com/Hamlib/Hamlib
130 wiersze
5.4 KiB
Plaintext
130 wiersze
5.4 KiB
Plaintext
Elecraft K3 notes and Hamlib errata by Nate Bargmann, N0NB.
|
|
|
|
While the K3 uses a large set of commands compatible with the standard Kenwood
|
|
commands, a number are extended and others have side effects that are peculiar
|
|
to the K3. As such, a separate set of elecraft.[c|h] files have been written
|
|
to support the K2 and K3 in the best possible way using shared code when
|
|
possible. K3 specific code can be found in k3.c
|
|
|
|
As always, comments and bug reports should be submitted to
|
|
hamlib-developer@lists.sourceforge.net
|
|
|
|
|
|
elecraft_open()
|
|
===============
|
|
|
|
The kenwood_open() function fails for the Elecraft radios as the function checks
|
|
the backend to be certain the ID from the radio matches the backend that called
|
|
the function. As the ID command of the Elecraft radios returns "017" which
|
|
corresponds to the TS-570, the backend test fails. Rather than muck up a
|
|
working function, I chose to implement an independent elecraft_open which not
|
|
only checks for the existence of a connected radio that returns an ID of "017",
|
|
it also checks for K2 or K3 extensions and sets a pair of private variables
|
|
that may be used later for advanced functions. This way the backend should be
|
|
able to reliably test for either a K2 or K3 (needs more testing with the K2).
|
|
|
|
|
|
k3_set_vfo()
|
|
============
|
|
|
|
The K3's use of VFO A and VFO B differs from other rigs in that VFO A is
|
|
*always* the main or upper display and VFO B is *always* the sub or lower
|
|
display. The A/B panel button simply swaps the contents of the two displays.
|
|
The K3 manual states that VFO A is always the receive frequency and VFO B is
|
|
the transmit frequency in split mode. This is complicated somewhat when the
|
|
second receiver is installed and VFO B serves as its display frequency *and*
|
|
the transmit frequency in split mode. Got that? Good!
|
|
|
|
As a result of the above, I found that using the kenwood_set_vfo function had
|
|
the side effect of clearing the rig out of split mode when the VFO was set to
|
|
RIG_VFO_B. The Kenwood command 'FT1;' is used to make VFO B the transmitting
|
|
VFO while this command will cause the K3 to enter split mode. Likewise, the
|
|
Kenwood command 'FR1;' is used to set VFO B as the receiving VFO while the K3
|
|
exits split mode when it receives *any* set value for 'FR'. My solution is
|
|
to simply issue the 'SWT11;' command which emulates tapping the A/B button on
|
|
the K3's front panel to swap the displays when the k3_set_vfo function is called
|
|
with RIG_VFO_B. Any other vfo value leaves the display alone. Feedback on
|
|
improving this function is welcome.
|
|
|
|
|
|
k3_get_mode() k3_get_mode()
|
|
===========================
|
|
|
|
As an extension to the common Kenwood mode definitions, the K3 implements the
|
|
custom 'DT' command which can query and set its data sub-modes. These are as
|
|
follows:
|
|
|
|
DT0 DATA A
|
|
DT1 AFSK A
|
|
DT2 FSK D
|
|
DT3 PSK D
|
|
|
|
The main difference is that DT0 and DT1 are for soundcard audio modes from a
|
|
computer such as PSK31, MFSK, Olivia, etc. with DT1 being "optimized for RTTY".
|
|
Conversely, DT2 and DT3 utilize "direct FSK in" on the accessory jack as well
|
|
as enable the K3's internal encoding/decoding of RTTY and PSK31 modes (outside
|
|
the realm of Hamlib).
|
|
|
|
As implemented the k3_get_mode function will query the data sub-mode when the
|
|
kenwood_get_mode function returns RIG_MODE_RTTY or RIG_MODE_RTTYR. As of k3
|
|
backend version 20101027 the following will be returned:
|
|
|
|
MD6 MD9
|
|
DT0 RIG_MODE_PKTUSB RIG_MODE_PKTLSB
|
|
DT1 RIG_MODE_RTTY RIG_MODE_RTTYR
|
|
DT2 N/A N/A
|
|
DT3 N/A N/A
|
|
|
|
Perhaps it would be preferable to return the RTTY modes when DT2 is detected.
|
|
Feedback is requested.
|
|
|
|
Mode setting is little different as the MD and DT values will be set as above
|
|
for the Hamlib RIG_MODE values. Feedback is requested on whether RTTY/RTTYR
|
|
should map to AFSK A (DT1) or FSK D (DT2).
|
|
|
|
The K3 can set any bandwidth in any mode using its custom 'BW' command. Band-
|
|
width values are sent to the K3 in 10 Hz increments and the K3 will round down
|
|
to the nearest 100 Hz values from 10 to 40 Hz. It will round down to the
|
|
nearest 50 Hz values from 50 to 90 Hz. As an example, sending 'BW0236' (2360 in
|
|
rigctl) will set the bandwidth to 2350 Hz (rounded down by the K3).
|
|
|
|
The k3_get_mode function will query and return the actual bandwidth in use in
|
|
Hertz.
|
|
|
|
|
|
k3_set_ext_level()
|
|
==================
|
|
|
|
This function is used to set the K3 for some extra level functions (rigctl
|
|
command examples shown).
|
|
|
|
To clear the RIT and XIT offset, use the 'L' command with the token name
|
|
'ritclr' for 'Level' to set in rigctl[d]. The prompted value is not used
|
|
and can be safely set to 0. Use this level to clear the RIT and XIT offsets
|
|
when it is not desired to turn RIT|XIT off.
|
|
|
|
|
|
k3_get_ext_level()
|
|
==================
|
|
|
|
This function is used to query the K3 for some extra information (rigctl
|
|
command examples shown).
|
|
|
|
To query the IF center frequency, use the 'l' command with the token name
|
|
'ifctr' for 'Level' to read in rigctl[d]. Value returned is 8210000.0 +
|
|
queried value from rig (see K3 Programmers Reference, FI command). Returned
|
|
type is a floating point value.
|
|
|
|
To query the TX status, use the 'l' command with the token name 'txst' for
|
|
'Level' to read in rigctl[d]. Value returned is 1 for K3 in transmit mode
|
|
and 0 for receive mode. Returned type is an integer.
|
|
|
|
|
|
kenwood_get/set_ext_parms()
|
|
===========================
|
|
|
|
These functions are used to get and set RIT/XIT on and off. The special token
|
|
names of 'rit' and 'xit' are used with the P/p commands of rigctl[d] for the
|
|
'parm'. Set/returned value is 0 or 1 for off or on.
|
|
|