Re: [Hamlib-developer] Why hamlib is not really suited for satellite radias

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

On Fri, Sep 06, 2002, lx...@gm... wrote:
> In my application I need to read the current downlink frequency (MAIN band
> of the IC910 if it is in the satellite mode), setting the modes on main and
> sub bands, and setting the frequency on the main and sub bands.
> 
> My suggestion is to have 2 more VFO's in the API. VFO_DOWNLINK and
> VFO_UPLINK. So the application does not need to worry about using the right VFO's. 

Funnily enough, I like the idea of adding 2 new VFO's. They would be kind
of alias to existing VFO's the backend would map.
However, I'm not happy with the names. For me, satellite mode looks a
lot like split mode. And I realize that even though rig_set_split_freq and
rig_set_split_mode are fine (change TX freq & mode), the current API has 
no provision for changeing other attributes of the transmit band.
Hence, I would propose to rename your 2 new VFO's something like VFO_RX
and VFO_TX (or whatever else if you got a better idea, I'm rather short
at findings names). We would then add a new mode to rig_set_split:
SPLIT_SATELLITE.

What do you all think?

> The IC910 uses the sub band VFO as transmit band if it is in satellite mode.
> Another rig could use other VFO's. I think it would be the easiest to simply
> let the DOWNLINK / UPLINK VFO point to the real one - dependent of the radio
> in use.

looks definitely like an excellent idea to support all kind of radios
out there.

 
> The IC910 has 2 receivers and one Transmitter. The MAIN VFO is receive and
> transmit, and the SUB is only receive. The frequencys on both have to be on
> different bands. But they can both be any band!

okay, I don't know yet how to model that in the capabilities of the
backends, but we'll think about it.

 
Thank you for all the information,

73,
Stephane