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

[Luc L. <lx...@gm...>]

Am Sa 07 Sep 2002 17:12 schrieb Stephane Fillod:
> 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 nob=
le
> > > idea even if some fancy functions specific to this or that radio ha=
ve
> > > 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 user=
s
> > control of most of the rigs out there. Currently I am working on an c=
lass
> > 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 t=
he
> > 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 t=
he
> > 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 lik=
e
> that the split is implemented (at least for Icom's).
> The VFO A is the receive frequency and the VFO B the transmit frequency=
=2E
> All the "magic" happens in the backend code. See icom_set_split_freq fo=
r
> 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.
>

My class uses the C lib directly. Most of the things of the IC910 do work=
 now.=20
About the switchable bands, I do not know what other rigs also need to ha=
ve=20
it. I will modify the ic910.c file, and submit a patch if I get the switc=
hing=20
properly done. I was thinking of keeping the frequency of both bands=20
somewhere stored. So, sub band is 2m, we want to change main band to 2m -=
->=20
exchange the main / sub bands.


> > Concerning the IC910 I will need to pay attention to the current band=
s,
> > and swap main / sub to be able to set different bands on the radio. F=
or
> > 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.
>

Another thing:=20

Switching on/off satmode does work, but status must be '1' for disabling =
the=20
mode, and '0' for enabling it.

Luc