VFO and split mode, was Re: [Hamlib-developer] CVS checkin

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

On Mon, Jun 17, 2002, Dale E. Edmons wrote:
> I'd like very much if you'd test out my changes if you'd like.  However,
> since
> I've made some pretty extensive changes to things like RIG_VFO_* in
> rig.h,
> rig.c, and rigctl, I'd like the changes to be reviewed before being
> checked
> directly into CVS.

Dale, I'll add you in the developer list tomorrow. Unless you're really
sure of your code, don't commit too quickly, especially if it has an
impact on other rigs. Anything that touch rig.h or the frontend has to
be discussed beforehand. But don't worry, since we're using cvs,
it's safe for everyone.

> The gist of the non-ts2k changes are the addition of numerous VFO types.
> 
> They are as follows:
>            RIG_VFO_AB       // split, RX=VFOA on Main receiver
>            RIG_VFO_BA      // split, RX=VFOB on Main receiver
>            RIG_VFO_MEM_A    // Memory on Main receiver
>            RIG_VFO_MEM_C   // Memory on Sub receiver
>            RIG_VFO_CALL_A    // Call channel on Main
>            RIG_VFO_CALL_C    // Call channel on Sub
> I plan on adding the following:
>            RIG_VFO_A_MEM    // split, RX=VFOA, TX=MEMA
>            RIG_VFO_B_MEM    // split, RX=VFOB, TX=MEMA
> but it requires a little more programming.  (Plus any more that I can.)

I do not agree with all these RIG_VFO definitions.
This is true I never operated a rig as complex as the TS-2000, so I'd
like you to explain me a little. Please keep in mind Hamlib has to
support many many kind of rigs, and code has to be generic.

> The point of these changes is to make it obvious what the exact
> state of the rig is.  I can now put the TS-2000 into any of the above
> states (first six) plus the normal VFOA, VFOB, VFOC.  Just making
> VFOC was a chore without the changes.

In the current Hamlib's design, the rig_set_vfo is a kind of
rig_set_focus. If you want to operate in split mode, then use
rig_set_split. It's better to break down complexity in small pieces.
I'll do the math for you: 3 VFOs plus memories and call channel on each.
This is applicable for main and sub, which gives 5^2 = 25 RIG_VFO
definitions! And now imagine if the new model "Moon melter DSP8500" has
4 VFOs!

Okay, I'm exagerating a bit, and I don't know all the possible combinations
of the TS-2000, like is it possible to mix main and sub in split. 
But I hope you got my point.

In other words, tell me what are the limitations of the current API,
and we'll see how to fix/expand it to cover the TS-2000 and probably
others.

Looks like rig_set_split will have to be reworked...

> A word of caution:  Adding these extra vfo's is really cool in what
> you can do, but right now my _get_freq() doesn't work by default.
> If this is expected behaviour you could say its broken.  The _get_freq()
> now has to do commands to specifically read these other vfo's.
> In actuality, it is better since I won't receive VFOA when the rig
> is on the sub receiver, or MEMA when MEMC is selected.  Other
> developers may have solved this differently or better.

rig_get_freq		is for RX freq
rig_get_split_freq	is for TX freq

The vfo arg gives the ability to query a vfo different than the current
active one. Very few rigs can do this. So most applications use
RIG_VFO_CURR and the frontend emulate the right behaviour otherwise.

 

I'll give a look at your code this week and let you know how it suits to
the Hamlib frontend interface.

73's 
Stephane