kopia lustrzana https://github.com/Hamlib/Hamlib
133 wiersze
5.9 KiB
Plaintext
133 wiersze
5.9 KiB
Plaintext
Quirks, known bugs, and other notes.
|
|
====================================
|
|
|
|
In this document I'll try to describe the behavior of the Yaesu FT-920
|
|
transceiver with Hamlib. Some of these are limitations of the radio
|
|
while others are programming trade-offs with Hamlib.
|
|
|
|
This document is organized by Hamlib function calls and documents observed
|
|
behavior with each call.
|
|
|
|
rig_set_mode
|
|
* No matter the status of the main display, MEM or VFO, display
|
|
will be set to VFO mode if RIG_VFO_A or RIG_VFO_VFO is passed.
|
|
* If radio is in MEM or MEM TUNE state, main display mode can be
|
|
changed when RIG_VFO_MEM or RIG_VFO_MAIN is passed.
|
|
* When RIG_VFO_CURR is passed, the display will be set per the VFO
|
|
stored by the last rig_get_vfo call.
|
|
* Modes DATA USB and DATA FM cannot be set at this time
|
|
(Hamlib limitation). See below.
|
|
* My FT-920 does not support USB/LSB narrow so attempting to
|
|
set a narrow passband with these modes will return an Invalib
|
|
Parameter error.
|
|
|
|
rig_get_mode
|
|
* Modes DATA USB and DATA FM cannot be returned as rig.h only has
|
|
RIG_MODE_RTTY (Hamlib limitation).
|
|
* DATA LSB is mapped to RIG_MODE_RTTY.
|
|
* I would like to hear from anyone who gets a narrow passband
|
|
value in USB/LSB mode returned.
|
|
|
|
rig_set_freq
|
|
* When passed RIG_VFO_A or RIG_VFO_VFO the main display is forced
|
|
to VFO mode and then the frequency is set.
|
|
* When passed RIG_VFO_B or RIG_VFO_SUB, the sub display frequency
|
|
is set.
|
|
* When passed RIG_VFO_MEM, or RIG_VFO_MAIN, the main display
|
|
frequency is set regardless of whether the main display is in
|
|
memory (thus activating MEM Tune) or VFO mode.
|
|
* When RIG_VFO_CURR is passed, the display will be set per the VFO
|
|
stored by the last rig_get_vfo call.
|
|
* RIG_TARGETABLE_ALL is properly handled (I think).
|
|
|
|
rig_get_freq
|
|
* When passed RIG_VFO_A or RIG_VFO_VFO, the radio returns the
|
|
frequency in the main VFO, even if the main display is in MEM or
|
|
MEM Tune.
|
|
* When passed RIG_VFO_B or RIG_VFO_SUB, the sub-display frequency
|
|
is returned.
|
|
* When passed RIG_VFO_MEM or RIG_VFO_MAIN, the current main display
|
|
frequency is returned regardless of main display mode.
|
|
* When passed RIG_VFO_CURR, the display will be read per the VFO
|
|
stored by the last rig_get_vfo call.
|
|
|
|
rig_set_vfo
|
|
* When called with RIG_VFO_A or RIG_VFO_VFO, the radio appears to
|
|
do nothing, however, rig_state->current_vfo will be updated.
|
|
* When called with RIG_VFO_B, the radio will swap the main and sub
|
|
displays, the same as if the front panel A<>B button is pressed.
|
|
* No provision exists to make VFO-B (sub display) the active RX
|
|
through CAT.
|
|
|
|
rig_get_split
|
|
* Both split capabilities are tested, i.e. RX A/TX B and RX B/TX A,
|
|
but Hamlib only supports an indication that the radio is split.
|
|
* The VFO value passed is not used by the ft920 backend lib.
|
|
FIXME: Is this a problem?
|
|
|
|
rig_set_split
|
|
* When called with RIG_SPLIT_OFF the radio will make TX A active if
|
|
TX B was active, otherwise no change.
|
|
* When called with RIG_SPLIT_ON the radio will make TX B active if
|
|
TX A was active, otherwise no change.
|
|
* The FT-920 has no capability to change the active RX to RX B (sub
|
|
display) through CAT. Thus if VFO-B is active RX/TX the setting
|
|
RIG_SPLIT_ON will make no visible change on the radio.
|
|
* The VFO value passed is not used by the ft920 backend lib.
|
|
FIXME: Is this a problem?
|
|
|
|
rig_set_split_freq
|
|
* Backend simply wraps rig_set_freq--calling app needs to specify
|
|
target VFO to set frequency. Should backend determine split
|
|
and set "proper" VFO?
|
|
|
|
rig_get_split_freq
|
|
* Backend simply wraps rig_get_freq--calling app needs to specify
|
|
target VFO to set frequency. Should backend determine split
|
|
and set "proper" VFO?
|
|
|
|
rig_set_split_mode
|
|
* Backend simply wraps rig_set_mode--calling app needs to specify
|
|
target VFO to set frequency. Should backend determine split
|
|
and set "proper" VFO?
|
|
|
|
rig_get_split_mode
|
|
* Backend simply wraps rig_get_mode--calling app needs to specify
|
|
target VFO to set frequency. Should backend determine split
|
|
and set "proper" VFO?
|
|
|
|
rig_set_rit
|
|
* Hamlib specificies that passing 0 as the RIT frequency disables
|
|
RIT. Thus there is no way to meet the spec and mimic the front
|
|
panel RIT off function whilst keeping the RIT offset on the
|
|
display. The Hamlib spec causes behavior analogous to shutting
|
|
RIT off and then pressing the Clear button.
|
|
* There is no direct way to set RIT offset of VFOB/SUB. However,
|
|
rig_set_vfo can be used to swap VFO B and main, then set RIT, then
|
|
call rig_set_vfo to swap VFO B and main.
|
|
FIXME: Should backend do this automatically?
|
|
|
|
rig_get_rit
|
|
* Backend returns clarifier offset regardless of whether RIT is on.
|
|
* vfo is honored and stored RIT is returned.
|
|
|
|
rig_set_xit
|
|
* Hamlib specificies that passing 0 as the XIT frequency disables
|
|
XIT. Thus there is no way to meet the spec and mimic the front
|
|
panel XIT off function whilst keeping the XIT offset on the
|
|
display. The Hamlib spec causes behavior analogous to shutting
|
|
XIT off and then pressing the Clear button.
|
|
* There is no direct way to set XIT offset of VFOB/SUB. However,
|
|
rig_set_vfo can be used to swap VFO B and main, then set XIT, then
|
|
call rig_set_vfo to swap VFO B and main.
|
|
FIXME: Should backend do this automatically?
|
|
|
|
rig_get_xit
|
|
* Backend returns clarifier offset regardless of whether XIT is on.
|
|
* vfo is honored and stored XIT is returned.
|
|
|
|
General notes.
|
|
As with most all Yaesu radios the radio must be polled by the application
|
|
for status updates, i.e. no transceive mode in CAT.
|
|
|