new vfo_t feedback, Re: [Hamlib-developer] Re: Hamlib-developer digest, Vol 1 #342 - 3 msgs

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

On Wed, Mar 12, 2003, Dale E. Edmons wrote:
> 1)  My rig has two independent memory pointers.  If someone calls:
>         rig_set_vfo(rig, RIG_VFO_MEM)
> I presume I treat this just like RIG_VFO_CURR but set mem mode rather than

no, RIG_VFO_CURR means "don't change vfo" (ie. a no-op for rig_set_vfo) while 
RIG_VFO_MEM means switch to memory mode (recalling last selected #).

Rem:
all the vfo_t problems lie with the fact that some so-called VFO's are
actually control bands, and some others are just "glorified" memories.
Sometimes it's not clear how they should be interpreted.
Let see if we can make it as designed for now. Otherwise, a new
proposal will have to come up.

> vfo mode.  This is probably okay.  But, now, what do I do on rig_get_vfo()?
> It would be pointless to return RIG_VFO_MEM just as it would be pointless
> to return RIG_VFO_CURR (the rig is *always* in the current configuration).

It is pointless for rig_get_vfo() to return RIG_VFO_CURR, however it is
NOT pointless to return RIG_VFO_MEM.

> Either of the following would have meaning and would be useful:
>     RIG_VFO_MEM | RIG_VFO_C
>     RIG_VFO_MEM | RIG_VFO_MAIN
> But is this defined?

yes, RIG_VFO_MEM | RIG_VFO_C is valid.
RIG_VFO_VFO implicitly applies to RIG_VFO_CURR
RIG_VFO_MEM implicitly applies to RIG_VFO_CURR
for most backends, RIG_VFO_VFO | RIG_VFO_N will be nothing more than RIG_VFO_N
RIG_VFO_MEM | RIG_VFO_N is okay

RIG_VFO_MEM | RIG_VFO_MAIN is not valid because no "real vfo" is defined.

For me, RIG_VFO_MAIN and RIG_VFO_SUB are aliases, and the way some rigs
define them is misleading. That's why it's better not to use them.
Besides, RIG_VFO_MAIN and RIG_VFO_SUB would provide only 2 control
bands, which is not enough in the case of SDR, where each vfo 
IS independant wrt other control channels.

> 2) I can also directly access memory.  This is useful for memory backup
> restore type routines.  For example if one calls rig_get_channel() and
> sets the channel_num to the desired memory, it may be retreived without
> accessing either of the memory pointers.  Alternatively, one may wish to
> do rig_get_channel() using either one of the pointers.  RIG_VFO_MEM
> tells me only one piece of the information I need.  Again, either:
>         RIG_VFO_MEM | RIG_VFO_A
>         RIG_VFO_MEM | RIG_VFO_MAIN
> etc.... would do the trick for the pointers.  Then, I could use RIG_VFO_MEM
> to imply direct access if the caller has properly set channel_num.

I am not very keen on the RIG_VFO_MAIN for the previous reason, but
your remark is worth adding in the rig_get_channel API documentation.
Backends will have to be modified to follow this behaviour.

> >
> > RIG_VFO_VFO     VFO mode (last selected VFO), used by set_vfo,
> >                 as opposed to Memory mode
> 
> Is this supposed to turn memory mode off using the vfo_t?

yes, rig_set_vfo(RIG_VFO_VFO) would turn memory mode off, selecting last
previously VFO for this control channel.

> > * Split combinations are not to be handled here. We need to
> >   create (or modify) an API call like the following:
> >   rig_set_plit_vfo(RIG*, vfo_t rx_vfo, split_t split, vfo_t tx_vfo);
> >   What do you think?
> 
> With one small change to vfo_t you can avoid  changing the API
> (which is bound to not be binary compatible).  Add RIG_VFO_REV
> to the vfo_t definitions.  Then a split may be defined in one vfo_t:
>         rx_vfo = RIG_VFO_A;
>         tx_vfo = RIG_VFO_B;
>         vfo = rx_vfo | tx_vfo;    // A/B split
> 
>         vfo |= RIG_VFO_REV;    // B/A split
>         // This works for all n in RIG_VFOn.
> 
> Either will require changes to the backends, but the API will be unchanged.

Adding new calls is not a problem. Your RIG_VFO_REV proposal is too
hackish to my taste, and it would prevent setup of a channel being memory
and the other not.

> The RIG_VFO_REV is also handy to have for specifing the REV on a
> repeater, and similar items.

see RIG_FUNC_REV instead

> > * Call channels should be accessed through a forged memory channel,
> >   unless they are truly plain VFO. I would recommand to go the memory way
> >   anyway, because memory channels are saved by application whereas
> >   VFO channels aren't (they're kind of temprorary working area).
> 
> VFO channels could be saved as easily as memory.   If the channel_t has
>     chan->vfo = RIG_VFO_A;
> then shouldn't we save freq, mode, etc... into the chan from VFO_A?  This
> way, memory<->vfo operations will be more transparent.

This is the way the API is designed already. Have a look at the
rig_get_channel comments, and generic_save_channel in src/mem.c

When I was saying "..whereas VFO channels aren't", I meant they aren't
saved by application because even though it can, it is pointless for 
the application, unless you want to setup your rig to the exactly 
the same state when you left your application.

> 
> > However, a new field will have to be created
> >   in the caps to describe what frequency band is exclusive to which one,
> >   determining if full-duplex is possible or not.
> 
> I don't think I understand this.  Would this be similar to saying, "My rig will do
> 
> A/B, split or B/A split, but not A/C or C/A split"?

I was not thinking this case, with "VFO" split incompatibilities, but it
will have to be modelled.

I was thinking of the case were VFOA can be tuned to either VHF or UHF
band, and VFOB can be tuned to either VHF or UHF band too. However, VFOA
and VFOB can NOT use the same band at the same time in full-duplex mode,
which leaves only the following possibilities: VFOA:VHF/VFOB:UHF or
VFOA:UHF/VFOB:VHF in my example.

> Please add something like the following:
>     /** \brief Reverse */
>     #define RIG_VFO_REV    ((vfo_t) (1<<24))

I'd prefer not to.

> > Application developers, please let me know if this new design does not let
> > you do what you want.
> 
> Can we specify RIG_VFO_A etc... as a target in rig_get_channel().  This
> would be very nice for MEM<->VFO operations.

it's already there, as long as backends honors the news vfo_t.


73's
Stephane