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

[Dale E. E. <de...@w-...>]

Stephane,

It's looking better.  Thanks for the effort.

Here's my comments/questions:

> RIG_VFO_MEM     Memory mode (last selected channel), used by set_vfo,
>                 as opposed to VFO mode

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
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).
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?

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.

>
> 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?

> * 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.

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

> * 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.

> 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"?

> Here's the relevant part of rig.h:
> ---------------------------------
> /**
>  * \brief VFO definition
>  *

>
> /** \brief VFO A */
> #define RIG_VFO_A RIG_VFO_N(0)
> /** \brief VFO B */
> #define RIG_VFO_B RIG_VFO_N(1)
> /** \brief VFO C */
> #define RIG_VFO_C RIG_VFO_N(2)
>

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

>
> If something is not clear, please ask questions. If documentation is too
> vague, please complain, or better, propose your own comments!

Only the purpose of the new caps entry was vague.

> 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.

> Backend developers, please let me know if this new design does not let
> you describe what your rig can do.

These were the issues I first ran into several months ago.  I'm glad to see
things progressing.  This is roughly equivalent to my initial changes to rig.h.


73's

Dale, kd7eni