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

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

On Fri, Sep 06, 2002, Luc Langehegermann wrote:
> Am Do 05 Sep 2002 22:42 schrieb al...@ph...:
> > The basic idea behind Hamlib is to provide a single and unified API for all
> > radios that can be controlled by a computer. This is a very noble idea even
> > if some fancy functions specific to this or that radio have to be left out
> > for the greater good.

Note: It does not have to be left out, provided the API can model the
feature. However, since it's not often-used features, it might not be
modeled/implemented first :)

> Yes, hamlib is the first choice. Actually using it will give the users control 
> of most of the rigs out there. Currently I am working on an class that will 
> control up to 2 rigs... one for the uplink and one for the downlink (no 
> problem in this case) or only control one radio for both frequncies. Here I 
> am not shure how other radios do work. In the case of my ICOM910, uplink is 
> the sub band, and downlink the main band. Are the FT847 / TS2000 the same? 
> Don't know. Will be an future brand new Rig the same? I don't know. So, for 
> now I will assume that sub band will be the uplink band.

It's okay to assume main is downlink, and sub is the uplink (as long as
the assumption keeps documented somewhere). By the way, it's alreay like 
that the split is implemented (at least for Icom's). 
The VFO A is the receive frequency and the VFO B the transmit frequency.
All the "magic" happens in the backend code. See icom_set_split_freq for 
an insight. Note: the actual code may still be more clever.

Now, talking about the class you're developping that will control up to 2
rigs, do you have any plan using hamlib++ library? This class could be
drivated from the Rig class. And it may make sense then to integrate it
in hamlib++. But we're not there yet.

> Concerning the IC910 I will need to pay attention to the current bands, and 
> swap main / sub to be able to set different bands on the radio. For this I 
> still think hamlib should do that automatically!

Sure. Why not always staying with the main band, switching temporarily 
to the sub only when you need to change any attribute of the uplink, 
and shoadow (or retrieve each time) the state of current bands so they
don't step over.
This would be all done in icom.c if all Icom's work the same, 
or in ic910.c otherwise.


Stephane