RE: [Hamlib-developer] vfo_t rewrite

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

Looks interesting, but I'm slightly confused about how this would work with a
satellite rig.
And you asked for comments. :)
I hope this makes sense and I didn't give you too many. :)
And if it just looks like I'm not reading you message correctly, just let me
know. :)
And if it doesn't make sense feel free to let me know. :)

I'm a little fuzzy about the IC-970's transmit offset/split feature because I
have not used it yet (I will soon) and I don't have the radio and/or the user
manual handy.

-

With a radio like the IC-970:

The radio has two radio modules that can each be tied to any of the band
modules (but with the IC-970 not the same band)

main transceiver with optional transmit offset (or is it a split)
sub receiver

Common uses:
cross band satellite (full duplex):
main is the transmitter
sub is the receiver

other uses (half duplex):
main is the transceiver with optional transmit offset

-

Now from my reading of your description:

RIG_VFO_MAIN and RIG_VFO_SUB don't necessarily have anything to do with the
vfo's the radio calls main and sub.

RIG_VFO_TX for the sub receiver would the the main

RIG_VFO_TX for the main would be the main transmit offset?
or would this be a split which is set with rig_set_split_vfo?
Is RIG_VFO_TX_VFO part of the radio description or settable by the user?
What happens when you turn split on and off?

I don't think it matters that much to me because my software has a config file
that you set up ahead of time that has lists of transmitter and receiver pairs
that you can select between.
I can deal with transmit on radio 1 on RIG_VFO_1 and receive on radio 2 on
RIG_VFO_2.

However, I figured I would ask just in case.

---

For the medium/long term, I'm thinking it would be nice to have some sort of
searchable extended capabilities database (I'm not sure if it should be a hard
coded in a structure, stored in a file, or something else) with things like:
name radio calls vfo (left, right, main, sub, vhf, uhf, ...)
transmit range
receive range
various other info

so I could do a query something like:
what vfos should I use to transmit on vhf, receive on uhf, preferably full
 duplex?  And does the radio need to be in a special mode and/or setup?

If you had enough info in there, then someone could write a piece of software
that could do fairly complicated things to the radio without a lot of special
configuration.  On the other hand, a lot of software probably only has to worry
about RIG_VFO_CURR because alot of things that you can do with the front panel
can just as easily be done with software using hamlib.  (eg. for memories, the
things I can think of you would want to do to them are backup, restore, and
editing.  You don't really need to use them in hamlib)

However, this would take alot of thinking to try to come up because it seems
they are adding all sorts of different modes to the new high end radios for
different uses.  And how what modes share hardware and/or software vfo's with
other modes.  
And then with the software defined radios you could have multiple receivers
active in the dsp up to the speed of the dsp.  (Either different modes or
different frequencies inside of the IF passband)  (vfo1 is spectrum display
across the IF passband, vfo2 is one frequency in USB, vfo3 is a slightly
different frequency in PSK31, ...)






On 10-Mar-03 Stephane Fillod wrote:
> 
> Hi everyone,
> 
> Here's a rewrite of the vfo_t can of worms (special brand).
> The former control band paradigm is gone, mainly because putting too much
> capabilities in one data field makes code totaly messed up.
> 
> Please comment heavily, the vfo_t rewrite is the only reason holding the
> hamlib-1.1.4 release.
> 
> I hope the new vfo_t will be saner. It can designate 2 kinds of "VFO"
> (ie. control channel): real VFO, and aliases.
> - what I call real VFO's are not exactly "Variable Frequency Oscillator",
>   but control channels like VFO A, VFO B, VFO C.
> - what I call aliases are conceptual channels like "Transmit VFO" and
>   "Receive VFO".
> 
> Here are the macros that can be used:
> 
> aliases:
> -------
> RIG_VFO_NONE  used in caps, not to be used as a target
> RIG_VFO_CURR  the almighty
> RIG_VFO_MEM   Memory mode (last selected channel), used by set_vfo, 
>               as opposed to VFO mode
> RIG_VFO_VFO   VFO mode (last selected VFO), used by set_vfo, 
>               as opposed to Memory mode
> 
> RIG_VFO_RX    maps to RIG_VFO_CURR
> RIG_VFO_TX    maps to the transmit channel associated with RIG_VFO_CURR.
>               Therefore, the following 2 calls are equivalent:
>                       rig_set_split_freq(RIG_VFO_CURR, ..)
>                       rig_set_freq(RIG_VFO_TX, ..)
> 
> RIG_VFO_MAIN  set_vfo switch convenience, not to be used as a target
> RIG_VFO_SUB   set_vfo switch convenience, not to be used as a target
> 
> "real" VFO's:
> ------------
> RIG_VFO_N(n)  starts from 0, allows at least 20 VFO's for now
> 
> RIG_VFO_A     VFO 0
> RIG_VFO_B     VFO 1
> RIG_VFO_C     VFO 2
> 
> Special macro:
> RIG_VFO_TX_VFO(v)     Designate the transmit channel of VFO.
>                       e.g. RIG_VFO_TX_VFO(RIG_VFO_C) is the transmit
>                       channel associated with VFO C.
>                       Sometimes, RIG_VFO_TX_VFO(RIG_VFO_C) may
>                       designate the same VFO as VFO C.
> 
> Why the RIG_VFO_TX_VFO? 
> ----------------------
> Because some calls do not have a rig_set_split_xxx to target the
> transmit channel, eg. rig_set_ant().
> 
> 
> Remarks:
> -------
> * Some rigs use 2 VFO's to handle the transmit and receive channels.
>   However, other models may use only one for both directions (in a half-
>   duplex manner). This should be transparent for the application.
> 
> * 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?
> 
> * 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).
> 
> * For now, only rig.h has been modified. If everyone agrees upon this
>   rewrite, all the backend will have to be adaptated to honor this new
>   semantic.
> 
> * It is already possible to know which VFO has support for which
>   frequency band. 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.
> 
> 
> Here's the relevant part of rig.h:
> ---------------------------------
> /**
>  * \brief VFO definition
>  *
>  * There's several way of using a vfo_t. For most cases, using RIG_VFO_A,
>  * RIG_VFO_B, RIG_VFO_CURR, etc., as opaque macros should suffice.
>  *
>  * Strictly speaking a VFO is Variable Frequency Oscillator.
>  * Here, it is referred as a tunable channel, from the radio operator
>  * point of view. The channel can be designated individualy by its real 
>  * number, or using an alias.
>  * Aliases may, or may not be honored by backend, and are defined using
>  * high significant bits, like RIG_VFO_MEM, RIG_VFO_MAIN, etc.
>  *
>  */
> typedef int vfo_t;
> 
> /** \brief used in caps */
>#define RIG_VFO_NONE    0
> 
>#define RIG_VFO_TX_FLAG    ((vfo_t)(1<<30))
> 
> /** \brief current "tunable channel"/VFO */
>#define RIG_VFO_CURR    ((vfo_t)(1<<29))
> 
> /** \brief means Memory mode, to be used with set_vfo */
>#define RIG_VFO_MEM    ((vfo_t)(1<<28))
> 
> /** \brief means (last or any)VFO mode, with set_vfo */
>#define RIG_VFO_VFO    ((vfo_t)(1<<27))
> 
>#define RIG_VFO_TX_VFO(v)      ((v)|RIG_VFO_TX_FLAG)
> 
> /** \brief alias for split tx or uplink, of VFO_CURR  */
>#define RIG_VFO_TX     RIG_VFO_TX_VFO(RIG_VFO_CURR)
> 
> /** \brief alias for split rx or downlink */
>#define RIG_VFO_RX     RIG_VFO_CURR
> 
> /** \brief alias for MAIN */
>#define RIG_VFO_MAIN   ((vfo_t)(1<<26))
> /** \brief alias for SUB */
>#define RIG_VFO_SUB    ((vfo_t)(1<<25))
> 
>#define RIG_VFO_N(n) ((vfo_t)(1<<(n)))
> 
> /** \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)
> 
> 
> If something is not clear, please ask questions. If documentation is too
> vague, please complain, or better, propose your own comments!
> 
> Application developers, please let me know if this new design does not let
> you do what you want.
> 
> Backend developers, please let me know if this new design does not let
> you describe what your rig can do.
> 
> 
> Cheers,
> Stephane
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

----------------------------------
E-Mail: Chuck Hemker <n2...@am...>
Date: 11-Mar-03
Time: 04:40:00

This message was sent by XFMail
----------------------------------