I'm having a bit of trouble trying to map the various VFO combinations
in the FT-920 to Hamlib's set of defined VFOs. Compared to the '920,
Hamlib's set of defined VFOs in rig.h are quite limited. Here's my
problem.
The '920 has the appearance of a main band and a sub band. However, the
sub band display isn't really a sub band as there is no dual receive
capability in the radio. The sub band always acts as the VFO B
frequency display.
The main band will display the frequency of VFO A, when the VFO icon is
displayed. It will also display the selected memory channel when the
MEM icon is displayed and will automatically update the display and jump
into MEM TUNE mode when an action is taken to change the frequency on
the radio.
There are two CAT commands that return similar data. 0x10 P1 = 02 will
return 2 14 byte records that contain the current frequency and mode data
for each display, main and sub whether in VFO, MEM, or MEM TUNE modes.
The other command, 0x10 P1 = 03, explicitly returns the data for VFO A
and VFO B. Now keep in mind that with either command the frequency in
the second 14 byte record is considered VFO B by the radio regardless of
whether it was a VFO, MEM, or MEM TUNE frequency in the main display
before the A<>B button was pressed (or the set VFO B command was sent to
the rig--more on that later).
So my first question is, how do I label the current frequency display
mode in Hamlib so an application has an idea whether it is looking at a
VFO, MEM, or MEM TUNE frequency? I can test the status flags for these
three values plus QMB (Quick Memory Bank) and General Coverage Reception
to learn what the frequency display is related to. This is required as
one can change the VFO A frequency via the CAT command without changing
the displayed frequency if the main band is in anything but VFO mode.
Confused yet?
I think the solution is the addition of a few more VFO #define constants
in rig.h, something applications can test to properly associate the
display frequency.
On a related note, there is a peculiarity with the '920 and the set_vfo
command. Any time 920_set_vfo is called and the vfo variable is set to
VFOB (which I only found after digging through the rigctl source leading
me to misc.c where this constant is defined...grrrrr) and the associate
command is sent to the radio, the '920 will swap main and sub displays.
A successive call with VFOA passed will not change any state in the
radio, but will change Hamlib's idea of the current VFO.
So, using rigctl, if I wish to query VFO B's frequency I must set the
VFO to B which now swaps the main and sub displays in order to get
Hamlib (or is it rigctl) to pass VFOB to 920_set_vfo. But now, instead
of VFO B, I'm reading the former main band frequency. I can do one of
two things here. Either call 920_set_vfo with VFOB again to swap the
frequency back or jump back to reading VFO A by calling 920_set_vfo with
VFOA.
Ready to delete this mail yet?
Somehow, 920_get_freq needs to be told what VFO frequency to read
without resorting to 920_set_vfo first. So the application needs to be
able to set the vfo variable it passes to Hamlib. Am I confused?
I gotta go to work...
73, de Nate >>
--
Wireless | Amateur Radio Station N0NB | "We have awakened a
Internet | n0...@ne... | sleeping giant and
Location | Bremen, Kansas USA EM19ov | have instilled in him
Amateur radio exams; ham radio; Linux info @ | a terrible resolve".
http://www.qsl.net/n0nb/ | - Admiral Yamomoto
|
