RE: [Hamlib-developer] VFO proposal for peer review. (Initial d

[Chuck H. <n2...@am...>]

I'm slightly confused about having RIG_VFO_CURR being treated as an explicit
request to call rig_get_vfo().  With many of the radio protocols (Icom's CI-V
for example) there is a concept of a "current" vfo.  Many of the commands don't
have a place to specify the vfo (a set frequency command sets the frequency of
whatever the radio thinks is the "current" vfo).

I'm thinking a simple program that doesn't care about vfo's can just do
rig_set_freq, rig_get_freq and such with RIG_VFO_CURR.

Now I haven't taken a look at the TS-2000's protocol, if it doesn't have a
concept of a "current" vfo then you will have to handle this by either doing a
rig_get_vfo each time or remembering the "current" vfo from the previous
command.

>         RIG_VFO_CURR:   This should be treated as an explicit request
>                 to call rig_get_vfo() or mmelter_get_vfo() by any
>                 function (except rig_get_vfo()) that receives it.
>                 No function should ever output this value.  It
>                 may only be used for comparison or as a parameter
>                 to rig_get_vfo().
> 
>         RIG_VFO_VFO:    This is similar to RIG_VFO_CURR except that
>                 it eliminates special modes such as MEM, SCAN, and
>                 anything else.  Which ever *single* VFO may be
>                 considered current will be the target.  For example,
>                 rig_set_vfo(rig, RIG_VFO_VFO) will be considered
>                 an explicit request to turn off (or temporarily
>                 disable) MEM, SCAN, SAT, etc... and act the same
>                 as RIG_VFO_CURR after other potential targets are
>                 ruled out.  Functions should never output RIG_VFO_VFO.