hamlib-developer

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

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

Hello,

As I am currently rewriting the entire radio control code for ktrack, I took
a closer look at hamlib. But I am really disapointed as with it's curent
status it is not useable for controlling satellite radios for automatic doppler
correction.

One of the problem is the sub band. How do I change it at a way that does
work with every radio? On my IC-910 I have to enable the sub band - set the
frequency - and disable it. The code should really do that at is own. In the
case of the ic910 there is another problem. I want to set a frequency of 145.950
- but the transceiver has currently 70cm on the main band. I have to
retrieve the current frequency - look if I need to swap the bands - and swap them if
needed. This is very IC910 specific - why does I have to do it?

Note... these 2 examples are only for the IC910 - not for the other
satellite radios. So, for every satellite radio I still need my satellite dependent
code? I even don't know if the sub band is uplink or downlink on the different
radios.

Note, this is not meant flaming about hamlib. Hamlib is a neat project, and
the right direction for rig control - but in it's current state not really
useable for satellite radios.

73, Luc

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

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

[<al...@ph...>]

Hi Luc,

I can not help you with your IC901 specific problems, but I can put a couple of
words in for Hamlib.

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.

Now, I understand that you want to tune your radio to a satellite frequency and
to do that, you need to correct for the doppler shift. You could do that by
calculating the correct frequency in your program and using the rig_set_freq()
function of the Hamlib API. Thus you can be sure, that your program will work
with any radio which is supported by Hamlib and which is able to tune to the
desired frequency. On the other hand, if you insist on using some fancy
automatic doppler correction function that is available on a few sat-comm
radios, you can be certain, that your code will only work with these radios and
not with the traditional VHF/UHF radios.

I think the choice is obvious... Hamlib is the way to go!


Alex, OZ9AEC



Quoting lx...@gm...:

> Hello,
> 
> As I am currently rewriting the entire radio control code for ktrack, I
> took
> a closer look at hamlib. But I am really disapointed as with it's
> curent
> status it is not useable for controlling satellite radios for automatic
> doppler
> correction.
> 
> One of the problem is the sub band. How do I change it at a way that
> does
> work with every radio? On my IC-910 I have to enable the sub band - set
> the
> frequency - and disable it. The code should really do that at is own. In
> the
> case of the ic910 there is another problem. I want to set a frequency of
> 145.950
> - but the transceiver has currently 70cm on the main band. I have to
> retrieve the current frequency - look if I need to swap the bands - and
> swap them if
> needed. This is very IC910 specific - why does I have to do it?
> 
> Note... these 2 examples are only for the IC910 - not for the other
> satellite radios. So, for every satellite radio I still need my
> satellite dependent
> code? I even don't know if the sub band is uplink or downlink on the
> different
> radios.
> 
> Note, this is not meant flaming about hamlib. Hamlib is a neat project,
> and
> the right direction for rig control - but in it's current state not
> really
> useable for satellite radios.
> 
> 73, Luc
> 
> -- 
> GMX - Die Kommunikationsplattform im Internet.
> http://www.gmx.net
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer
> 

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

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

Am Do 05 Sep 2002 22:42 schrieb al...@ph...:
> Hi Luc,
>
> I can not help you with your IC901 specific problems, but I can put a
> couple of words in for Hamlib.
>
> 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.

I have to fully agree with you!

>
> Now, I understand that you want to tune your radio to a satellite frequ=
ency
> and to do that, you need to correct for the doppler shift. You could do
> that by calculating the correct frequency in your program and using the
> rig_set_freq() function of the Hamlib API. Thus you can be sure, that y=
our
> program will work with any radio which is supported by Hamlib and which=
 is
> able to tune to the desired frequency. On the other hand, if you insist=
 on
> using some fancy automatic doppler correction function that is availabl=
e on
> a few sat-comm radios, you can be certain, that your code will only wor=
k
> with these radios and not with the traditional VHF/UHF radios.
>
> I think the choice is obvious... Hamlib is the way to go!
>

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

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

Luc


>
> Alex, OZ9AEC
>
> Quoting lx...@gm...:
> > Hello,
> >
> > As I am currently rewriting the entire radio control code for ktrack,=
 I
> > took
> > a closer look at hamlib. But I am really disapointed as with it's
> > curent
> > status it is not useable for controlling satellite radios for automat=
ic
> > doppler
> > correction.
> >
> > One of the problem is the sub band. How do I change it at a way that
> > does
> > work with every radio? On my IC-910 I have to enable the sub band - s=
et
> > the
> > frequency - and disable it. The code should really do that at is own.=
 In
> > the
> > case of the ic910 there is another problem. I want to set a frequency=
 of
> > 145.950
> > - but the transceiver has currently 70cm on the main band. I have to
> > retrieve the current frequency - look if I need to swap the bands - a=
nd
> > swap them if
> > needed. This is very IC910 specific - why does I have to do it?
> >
> > Note... these 2 examples are only for the IC910 - not for the other
> > satellite radios. So, for every satellite radio I still need my
> > satellite dependent
> > code? I even don't know if the sub band is uplink or downlink on the
> > different
> > radios.
> >
> > Note, this is not meant flaming about hamlib. Hamlib is a neat projec=
t,
> > and
> > the right direction for rig control - but in it's current state not
> > really
> > useable for satellite radios.
> >
> > 73, Luc
> >
> > --
> > GMX - Die Kommunikationsplattform im Internet.
> > http://www.gmx.net
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: OSDN - Tired of that same old
> > cell phone?  Get a new here for FREE!
> > https://www.inphonic.com/r.asp?r=3Dsourceforge1&refcode1=3Dvs3390
> > _______________________________________________
> > Hamlib-developer mailing list
> > Ham...@li...
> > https://lists.sourceforge.net/lists/listinfo/hamlib-developer

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

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

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

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

Hi Luc!

On Thu, Sep 05, 2002, lx...@gm... wrote:
> One of the problem is the sub band. How do I change it at a way that does
> work with every radio? On my IC-910 I have to enable the sub band - set the
> frequency - and disable it. The code should really do that at is own. In the

I agree with you the code(backend) should really do that on his own.
Then, this makes everything looks simple for the application using Hamlib.

> case of the ic910 there is another problem. I want to set a frequency of 145.950
> - but the transceiver has currently 70cm on the main band. I have to
> retrieve the current frequency - look if I need to swap the bands - and swap them if
> needed. This is very IC910 specific - why does I have to do it?

Well, it looks like the IC910 backend needs some changes. And it's not
impossible to extend the frontend API if justified.
Okay, I'd like to understand your needs.

Your goal is to operate in "split" mode, on a full-duplex rig, with a
"follow-me" mode (rx and tx stay consistent).
In satellite mode, you want to be able to control independently the receive 
and the transmit frequencies (and associated modes,etc.). From an API point of
view, this would be done first by entering rig_set_split_mode, and then
using rig_set_freq (receive) and rig_set_split_freq (transmit).
REM: tell me if this is enough or not for your application.
     If not, feel free to express what kind of call you would like to
     have, with a prototype and an idea of the semantic.

Now, let's talk about the IC910. I never operated a rig with a sub band,
I don't have the IC910 manual, so you'll have to walk me. 
Please correct me if I'm wrong on what's following.
The main and sub bands can be seen as 2 independant VFO's when not in
"split" (or satellite?) mode. But in "split" mode, one band is the
receive "channel" and the other one is the "transmit". If I read
correctly between the lines, on the IC910 in this setup, the main and sub
can not be both in the same freq "range" (VHF - VHF, UHF - UHF, SHF - SHF), 
so one has to be VHF and the other one UHF for example.
Question: how do you decide which band is receive, and wich one is
transmit?
Talking about your example (setting freq of 145.950, and main band on
70cm), do you know if you want to change the transmit or the receive
frequency or change the frequency of the 2m link?
In other words, how works you application?


> Note... these 2 examples are only for the IC910 - not for the other
> satellite radios. So, for every satellite radio I still need my satellite dependent
> code? I even don't know if the sub band is uplink or downlink on the different
> radios.

The goal of Hamlib is to hide the radio depdendant code in a library, 
such a way that the application has only to support only one ideal (somewhat
virtual) radio. An abstraction layer if you prefer.

My idea is that an application developer should concentrate on his
*application*, and not on writing code to support every remote control
protocol on earth.

> Note, this is not meant flaming about hamlib. Hamlib is a neat project, and
> the right direction for rig control - but in it's current state not really
> useable for satellite radios.

alright, let's make it useable!

BTW, do you plan to also use the rotator control piece in Hamlib?
There's much to do, but it'd be nice to identify some potential users
first :)

 
73,
Stephane

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

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

Hi Stephane,
> 
> Hi Luc!
> 
> 
> > case of the ic910 there is another problem. I want to set a frequency of
> 145.950
> > - but the transceiver has currently 70cm on the main band. I have to
> > retrieve the current frequency - look if I need to swap the bands - and
> swap them if
> > needed. This is very IC910 specific - why does I have to do it?
> 
> Well, it looks like the IC910 backend needs some changes. And it's not
> impossible to extend the frontend API if justified.
> Okay, I'd like to understand your needs.
> 
> Your goal is to operate in "split" mode, on a full-duplex rig, with a
> "follow-me" mode (rx and tx stay consistent).
> In satellite mode, you want to be able to control independently the
> receive 
> and the transmit frequencies (and associated modes,etc.). From an API
> point of
> view, this would be done first by entering rig_set_split_mode, and then
> using rig_set_freq (receive) and rig_set_split_freq (transmit).
> REM: tell me if this is enough or not for your application.
>      If not, feel free to express what kind of call you would like to
>      have, with a prototype and an idea of the semantic.
> 
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. 

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.

> Now, let's talk about the IC910. I never operated a rig with a sub band,
> I don't have the IC910 manual, so you'll have to walk me. 
> Please correct me if I'm wrong on what's following.
> The main and sub bands can be seen as 2 independant VFO's when not in
> "split" (or satellite?) mode. But in "split" mode, one band is the
> receive "channel" and the other one is the "transmit". If I read
> correctly between the lines, on the IC910 in this setup, the main and sub
> can not be both in the same freq "range" (VHF - VHF, UHF - UHF, SHF -
> SHF), 
> so one has to be VHF and the other one UHF for example.
> Question: how do you decide which band is receive, and wich one is
> transmit?

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!

The satellite mode is different. SUB Receive and Transmit / MAIN only
receive. Additionally tuning manually affects both Bands.


> Talking about your example (setting freq of 145.950, and main band on
> 70cm), do you know if you want to change the transmit or the receive
> frequency or change the frequency of the 2m link?
> In other words, how works you application?

The rig control part of my program does work this way:

The user changed manually the frequency (downlink) on the rig. The program
gets the new frequency, calculates reverse doppler for this frequency,
calculates the coresponding uplink and sets the uplink on the rig. 

As the doppler changes, it will store the uplink and downlinkfrequency
internally, and compare with the doppler shift. It this is more than 25Hz for one
frequency it will set a new uplink / downlink frequency on the rig.

It will be able to do this with 2 rigs (one for uplink / one for downlink -
no problem here) or only one rig (full duplex uhf/vhf rig).

What I have not yet decided if I want du support only one simplex rig as in
this case you cannot hear your downlink. But in the case of the ISS it would
make sense.

> 
> 
> > Note... these 2 examples are only for the IC910 - not for the other
> > satellite radios. So, for every satellite radio I still need my
> satellite dependent
> > code? I even don't know if the sub band is uplink or downlink on the
> different
> > radios.
> 
> The goal of Hamlib is to hide the radio depdendant code in a library, 
> such a way that the application has only to support only one ideal
> (somewhat
> virtual) radio. An abstraction layer if you prefer.
> 
> My idea is that an application developer should concentrate on his
> *application*, and not on writing code to support every remote control
> protocol on earth.

That is defenitly the right direction!

> 
> > Note, this is not meant flaming about hamlib. Hamlib is a neat project,
> and
> > the right direction for rig control - but in it's current state not
> really
> > useable for satellite radios.
> 
> alright, let's make it useable!
> 
> BTW, do you plan to also use the rotator control piece in Hamlib?
> There's much to do, but it'd be nice to identify some potential users
> first :)
> 

Yes I do. But rig control first ;-) I have code to control an fodtrack
device, which is really easy, as it is an one-direction interface (Computer -->
interface) using the parallel port.

>  
> 73,
> Stephane
> 
> 

73, Luc

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

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

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

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

Hello Stephane,

> 
> 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 about an half duplex split and an full duplex split. Maybe even
automatically choose beetween them. (ie rig can full duplex and the frequencies are
on 2 different bands --> switch do satmode if available). In fact, the
satmode is nothing elso than split, but not using VFO_A and VFO_B but VFO_A und
VFO_C (sub)

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

Is it really that different from other rigs. I could imagine, that the
TS2000 and FT847 are similar.

>  
> Thank you for all the information,
> 
> 73,
> Stephane
> 
> 

BTW. you got the patch for the IC910 i sent to you directly?

73, Luc

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

RE: [Hamlib-developer] Why hamlib is not really suited for satel

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

On 05-Sep-02 lx...@gm... wrote:
> Hello,
> 
> As I am currently rewriting the entire radio control code for ktrack, I took
> a closer look at hamlib. But I am really disapointed as with it's curent
> status it is not useable for controlling satellite radios for automatic
> doppler
> correction.

I understand.  I've been working on my own satelite tracking program using
hamlib.  (However, currently I've been testing it with an IC-R7000 receiver
that only has one VFO, because it's handy.)  
(I also need to clean it up a bit so I can release it)

As you say, every satelite radio behaves slightly differently dealing with
tuning and sub-bands and such.
(Just take a look at at some of the comments made by the writer of InstantTune
 in both the docs and some of his talks.  Some radios won't let you change the
 frequency while transmitting, some won't let you get to the receiver to change
 frequency while transmitting, etc)

Currently hamlib is writen at a level where it lets you do the commands that
the radio can do, but it doesn't necessarly let you do things that are a bit
more complicated in a general sort of way.

What I was thinking, once I thought about it and played with enough radios to
try to come up with a generic api, was to try to write either an extention to
hamlib or a separate library that called hamlib to handle some of the things,
such as tuning satelite radios, that are common to several programs.

If you want to try to work together on something like this, let me know.

RE: [Hamlib-developer] Why hamlib is not really suited for satel

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

Hi Chuck,
> 
> I understand.  I've been working on my own satelite tracking program using
> hamlib.  (However, currently I've been testing it with an IC-R7000
> receiver
> that only has one VFO, because it's handy.)  
> (I also need to clean it up a bit so I can release it)
> 
> As you say, every satelite radio behaves slightly differently dealing with
> tuning and sub-bands and such.
> (Just take a look at at some of the comments made by the writer of
> InstantTune
>  in both the docs and some of his talks.  Some radios won't let you change
> the
>  frequency while transmitting, some won't let you get to the receiver to
> change
>  frequency while transmitting, etc)

Thank you for the pointer! Very interesting reading.

> 
> Currently hamlib is writen at a level where it lets you do the commands
> that
> the radio can do, but it doesn't necessarly let you do things that are a
> bit
> more complicated in a general sort of way.
> 
> What I was thinking, once I thought about it and played with enough radios
> to
> try to come up with a generic api, was to try to write either an extention
> to
> hamlib or a separate library that called hamlib to handle some of the
> things,
> such as tuning satelite radios, that are common to several programs.
> 
> If you want to try to work together on something like this, let me know.
> 

See my comments to Stephane's post. I don't think the the changes I
suggested really do need an additional library.

Luc

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net