[Hamlib-developer] VFO caps

[Stephane F. <f4...@fr...>]

Hi there!

It seems like everyone is quite busy, somehow you'll find
a minute or two to comment on my previous "mode" proposal
or this one.

All right, the purpose of this mail is to discuss about VFO capabilities.
Well, actually the subject might be a bit misleading as we should rather talk
about "independantly tunable channels". As Matthew Francey was saying on 
this list so long ago, << A "radio" can actually consist
  of several independent channels.  What people call "VFO's" on many
  radios are actually just glorified memories.  Some radios, however,
  do have 2 or more independently tunable channels. >>

So what is a VFO? Even though a VFO is nothing else than a glorified memory,
Hamlib can consider the difference from a user point of view. The frontier 
could be defined by the M>VFO and VFO>M operations. Therefore, CALL channels
are not VFO. Let's have another example, it is possible to have the same memory channel on two VFOs, but the other way is non sense.
Hmmm, all in all, we do need a definition. Anyone to extend our vocabulary?

Anyway, the goal is to have a mean to target a "VFO" (unique identifier),
and also describe which "VFO" are available in the capabilities
of this rig. The first goal assumes we decided not to provide support for
targetting memories as well (like the 'vfo' arg do in all the Hamlib API 
calls), but rather matching more closely the way most the rigs out there works. And there're still these rig_set_channel/rig_get_channel calls.
The second goal is dealt with the following examples.

Most rigs have only one "tunable channel", which could be represented by:
    |
    `-- MAIN
        |-- VFO A
        `-- VFO B

However, some lucky guys have two "tunable channels" (e.g. FT847, TS2000..):
    |
    |-- MAIN
    |   |-- VFO A
    |   `-- VFO B
    `-- SUB
        `-- VFO C

Which brings the question of whether a rig represented by the following 
figure has ever existed (note the VFO names)?
    |
    |-- MAIN
    |   |-- VFO A
    |   `-- VFO B
    `-- SUB
        |-- VFO A
        `-- VFO B

To my mind, we should number the so-called VFO locally to the "tunable 
channels", and use VFOA, VFOB only as convenient shortcuts (which could 
be wrong on some weird radios BTW).

So enough babling, here's some code:

#define RIG_VFO_CURR    0       /* current "tunable channel"/VFO */

#define RIG_VFO1 (1<<0)
#define RIG_VFO2 (1<<1)
#define RIG_CTRL_MAIN 1
#define RIG_CTRL_SUB 2

/*
 * one byte per "tunable channel":
 *
 *    MSB           LSB
 *     8             1
 *    +-+-+-+-+-+-+-+-+
 *    | |             |
 *    CTL     VFO
 */

/* How to call it? "tunable channel"? Control band? */
#define RIG_CTRL_BAND(band,vfo) ( 1<<(8*((band)-1)) | (vfo)<< (8*((band)-1) )

 /* macros */
#define RIG_VFO_A (RIG_CTRL_BAND(RIG_CTRL_MAIN, RIG_VFO1))
#define RIG_VFO_B (RIG_CTRL_BAND(RIG_CTRL_MAIN, RIG_VFO2))
#define RIG_VFO_C (RIG_CTRL_BAND(RIG_CTRL_SUB, RIG_VFO1))
#define RIG_VFO_MAIN (RIG_CTRL_BAND(RIG_CTRL_MAIN, RIG_VFO_CURR))
#define RIG_VFO_SUB  (RIG_CTRL_BAND(RIG_CTRL_SUB, RIG_VFO_CURR))


As you can see, VFO_A, VFO_B, etc. are unique, which is what Hamlib
was achieving right now, but it is now possible to describe in caps
what "VFOs" the rig is equipped with.

For example, 0x8183 would suit for a TS2000, 0x0083 for an Icom706
and 0x0081 for PCReceiver like the WiNRADiO. As a matter of fact,
0x8081 would be non-sense.

Now do you remember this caps->vfo_list added some times ago? Yes?No?
That doesn't matter as it becomes useless, or should I say misplaced.
If you're following this proposal, we can imagine moving this vfo_list
field in the freq_range_t struct. Therefore, backend developers would
be able to describe which "VFOs" have access to which bands, for
the benefits of the happy final user. For example, on Kenwood TS2000,
VFOC can only do 2m and 70cm bands.

One might want to throw in antenna description in the caps too. Yet
I haven't seen enough antenna output configuration to come up with
a proposal likewise. So anyone comments are welcome!
Let me know what you think of it, and if it's worth to be coded.

I think Hamlib does need a 1.1.1 release very soon ("Release often, release
early"), let's say once an viable solution for mode/filters and VFO 
is commited. And then we can schedule harmonized scan support for 1.1.2,
besides other goodies like Nate's docs!


As usual, feedback most wanted 8-)

-- 
Stephane