Re: [Hamlib-developer] vfo_t rewrite

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

On Tue, Mar 11, 2003, Chuck Hemker wrote:
> 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. :)

don't worry, feedback is always welcome!

> 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_MAIN and RIG_VFO_SUB have to do with the radio vfo's.
The backend developer is responsible for mapping RIG_VFO_MAIN and RIG_VFO_SUB
to the so-called vfo's of the radio.
RIG_VFO_MAIN and RIG_VFO_SUB are only to be used by humain (through a
GUI), since their definition is quite vague, and may change from one rig
to another.
Most propably, what you intend to use instead, is RIG_VFO_TX and 
RIG_VFO_RX, the uplink and downlink in satellite world.

> RIG_VFO_TX for the sub receiver would the the main

up to you (and the IC970)

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

good question. Here you will have to handle 2 split modes.
The first one is the full-duplex case, with separate VFO's.
The second one is the half-duplux case, with transmit offset.

I don't know what the IC970 protocol looks like. If you want a bit of
help on this topic, let me know where I can have a glance over the
manual.

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

You mean using 2 different radios? i.e. a simple and expensive way of make a
full-duplex transceiver out of 2 half-duplex rigs.
IIRC, ktrack is doing the same.

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

I see what you mean.
Right now, all the capabilities are stored in C structures, with various
hacks to describe everything. It would have been neat to have some kind
of database (xml file?) and an automatic database-to-C-structure
program instead. But the C structures are not firmed up yet, so the C
way is easier for now.

But you can do the other way around. Generate a database out of
the C structures.
Have a look at http://f8cfe.free.fr/ham/hamlib/rigmatrix.html 
if it's still there. This is an extract of rigs capabilities.
It's done in C. I plan to rewrite it in perl one day. Generating an
export to XML (or any other db format) would fairly easy.

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

yep, it makes little sense to use memories in Hamlib, yet it is
possible. Like you said, most often usage will be backup/restore and
editing. I'm really surprised not such application does exist yet,
it's so easy with get_channel/set_channel. Using the perl binding, it's
a piece of cake.

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

the task is not easy, but we'll try to keep up..

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

Talking about SDR (software defined radios), I have a pretty good idea
since I currently develop the gnuradio backend, which is a SDR.
The API may have to be adapated again, but so far, it's not too bad.
BTW, a lot of backends will have to be updated to the new vfo_t design.


Cheers,
Stephane