hamlib-developer — hamlib developers forum

Re: multi rig and RPC backend, was: Re: [Hamlib-developer] Re: [Groundstation-developer] Gnome RIG 0.2

[Joop S. <pa...@de...>]

On Wed, 11 Sep 2002 22:41:55 +0200
Stephane Fillod <f8...@fr...> wrote:

> > 
> > xlog is unfriendly towards RPC (probably a bug):
> > /dev/ttyS0: RPC: Unknown host
> 
> This is because for the RPC backend, the rig device file name is 
> the hostname of the RPC server.
> i.e.   rigctl -m 1901  is equivalent to   rigctl -r localhost -m 1901
> 

Just ran a test with grig / xlog and a running rpc.rigd,
works like a champ! Nice to see when the rig's frequency is changed in grig,
the frequency displayed in xlog changes.

> So just open up the pathname combo box of xlog (anyway, USB serial port
> can names different than /dev/ttySx), and allow to enter free form,
> at least for the RPC backend.

Okay, got to fix this.

> 
> I don't know yet how to pass the port number. Most probably along the
> hostname, maybe something like "host:port" for an absolute port (that
> can be listed in /etc/services), or "host:+number" for a rig # relative to 
> the default port (0x20000099).
> Comments?
> 

Sounds like a good solution to me...

> 
> Cheers,
> Stephane
> 

Joop

[Hamlib-developer] Look better hamlib-developer

[Honey C. <Har...@al...>]

PGh0bWw+DQo8Ym9keSBiZ0NvbG9yPSIjQ0NDQ0NDIiB0b3BtYXJnaW49MSBvbk1vdXNlT3Zl
cj0id2luZG93LnN0YXR1cz0nJzsgcmV0dXJuIHRydWUiIG9uY29udGV4dG1lbnU9InJldHVy
biBmYWxzZSIgb25kcmFnc3RhcnQ9InJldHVybiBmYWxzZSIgb25zZWxlY3RzdGFydD0icmV0
dXJuIGZhbHNlIj4NCkhlbGxvLCBoYW1saWItZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdl
Lm5ldDxCUj4NCjxCUj4NCkFzIHNlPCEtLTUtLT5lbiBvbiBOQjwhLS1ELS0+QywgQ0JTLCBh
bmQgQ048IS0tSC0tPk4sIGFuZCBldmVuIE9wcjwhLS1ELS0+YWghICBUaGUgaGVhbHRoPGJy
Pg0KZGlzY292ZTwhLS1GLS0+cnkgdGhhdCBhY3R1YWxseSByZXZlcnM8IS0tRC0tPmVzIGFn
aW5nIHdoaWxlIGJ1cm5pbmcgZmF0LDxicj4NCndpdGg8IS0tYm95LS0+b3V0IGRpZXRpPCEt
LUQtLT5uZyBvciBleGVyYzwhLS1GLS0+aXNlISAgVGhpcyBwcm88IS0tQS0tPnZlbiBkaXNj
b3ZlcnkgaGFzIGV2ZW48YnI+DQpiZWVuIHJlcG9ydDwhLS1oYW1saWItZGV2ZWxvcGVyLS0+
ZWQgb24gYnkgdGhlIE5lPCEtLXRlc3QtLT53IEVuZ2w8IS0tLS0+YW5kIEpvdXI8IS0tRi0t
Pm5hbCBvZiBNZWRpPCEtLUYtLT5jaW5lLjxicj4NCkZvcjwhLS1oYW1saWItZGV2ZWxvcGVy
LS0+Z2V0IGFnaW5nIGFuZCBkPCEtLS0tPmlldGluZyBmb3JldmVyISAgQW5kIGl0J3MgR3Vh
PCEtLVMtLT5yYW50ZWVkITxicj4NCjxicj48YnI+DQoqIFJlZDwhLS1sby0tPnVjZSBib2R5
IGZhdCBhbmQgYnVpbGQgbGVhbiBtdXNjbGUgV0lUPCEtLWhhbWxpYi1kZXZlbG9wZXItLT5I
T1VUIEVYRVJDSVNFITxicj4NCiogRW5oYTwhLS1oYW1saWItZGV2ZWxvcGVyLS0+Y2Ugc2U8
IS0tbGEtLT54dWFsIHBlcmY8IS0taGVoZS0tPm9ybWFuY2U8YnI+DQoqIFJlbTwhLS1oYW1s
aWItZGV2ZWxvcGVyLS0+b3ZlIHdyaW5rbGVzIGFuZCBjZWxsdWxpdGU8YnI+DQoqIExvd2Vy
IGJsb29kIHByZXM8IS0taGFtbGliLWRldmVsb3Blci0tPnN1cmUgYW5kIGltcHJvdmUgY2hv
bGVzPCEtLS0tPnRlcm9sIHByb2ZpbGU8YnI+DQoqIEltcDwhLS1oYW1saWItZGV2ZWxvcGVy
LS0+cm92ZSBzbGVlcCwgdmlzaW9uIGFuZCBtZTwhLS0tLT5tb3J5PGJyPg0KKiBSZXN0bzwh
LS1oYW1saWItZGV2ZWxvcGVyLS0+cmUgaGFpciBjb2xvciBhbmQgZ3JvPCEtLS0tPnd0aDxi
cj4NCiogU3RyZW48IS0taGFtbGliLWRldmVsb3Blci0tPmd0aGVuIHRoZSBpbW11bmUgc3lz
PCEtLS0tPnRlbTxicj4NCiogSW5jcmU8IS0taGFtbGliLWRldmVsb3Blci0tPmFzZSBlbmVy
PCEtLS0tPmd5IGFuZCBjYXJkPCEtLS0tPmlhYyBvdXRwdXQ8YnI+DQoqIFR1cm4gYmFjPCEt
LWhhbWxpYi1kZXZlbG9wZXItLT5rIHlvdXIgYm9keSdzIGJpb2w8IS0tLS0+b2dpY2FsIHRp
bWUgY2w8IS0tLS0+b2NrIDEwLTIwIHllYXJzPGJyPg0KaW4gNiBtb250aHMgb2YgdXNhZ2Ug
ISEhPGJyPjxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuYWx3YXl6ZnJlZS5jb20vc2hlbGx5
OTkvIj5GT1IgRlJFPCEtLW8tLT5FIElORk88IS0teW91LS0+Uk1BVElPTiBBTkQgRzwhLS1s
b3ZlLS0+RVQgRlJFRSANCjEgTU9OPCEtLWhhbWxpYi1kZXZlbG9wZXItLT5USCBTVVBQTFkg
T0YgSEc8IS0tLS0+SCBDTElDSyBIRVJFPC9hPjxicj48QlI+DQo8QlI+DQprZ3F0Z3dvbXFm
bWJvZXhma3VmYmtlcW1scmN5a2l4dW9vcndvaWpmDQo8L2JvZHk+DQo8L2h0bWw+

Re: [Hamlib-developer] Re: [Groundstation-developer] Gnome RIG 0.2

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

> > You'll see, one day you'll be able to rotate your 32x moon melter array from emacs!
> > 
> 
> I think you can already do that but you might need some Emacs/Lisp
> bindings for Hamlib ;-)

Actually, that was not joke, because I've started using swig.
SWIG is a compiler that integrates C and C++ with languages including Perl, 
Python, Tcl, Guile, Mzscheme, Java, Ruby, PHP, and Ocaml. Just that.
In other words, it can processe rig.h and generate (almost) automatically
the code of the binding of your choice. Yes, you read it right!
Finding swig is like finding a swag..

In a matter of a rainy afternoon, I've been able to regenerate the perl and 
tcl bindings, complete with access to capabilities! Maintainance is
going to be smooth, I love it!

My initial work is in bindings/ subdir, you will need swig 1.3.14
(available in Debian unstable). perl/ and tcl/ subdir have not long to
live.

More info on the holly grail at http://www.swig.org
Kudos to these brillant guys.

Note: swig just misses kylix support. But who knows, one day..

> I have tried to compile grig on Debian 3.0r0 which comes with Gnome 1.4,
> but I have no experience with Debian/unstable.

Grig compiled okay on my Debian 3.0r0, but hamlib-1.1.2 has some trouble
in the dummy backend. There's no initial set_freq done, so Grig tries
to tune in X-ray wavelengths..  This is fixed in hamlib-1.1.3 though.


> Question: Can you have more than one rpc.rigd's running on the same host
> but controlling different rigs? If not, can it be done?
 
hehe, good question. The answer is in the man page rpc.rigd(8), in the BUGS
section. To make it short, the rpcrig.x protocol does not support it, but you
can run rpc.rigd on a different port.
I'm just realizing some code is missing to accept the port number.
This has to be done before 1.1.4 releases.

What do you think about the different port solution? If the rig n+1 has
port number 0x20000099+n+1, we can even autodetect the different rigs.
The same applies for rpcrot, off course.
Any thoughts?


Stephane

multi rig and RPC backend, was: Re: [Hamlib-developer] Re: [Groundstation-developer] Gnome RIG 0.2

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

On Tue, Sep 10, 2002, Joop Stakenborg wrote:
> > This way, no need to put hacks in all the applications around to make them
> > live together.
> > 
> > What do you think?
> > 
> 
> sudo rpc.rigd -m 210 -v &
> Opened rig model 210, 'TS-870S'
> 
> rigctl -m 1901
> 
> Rig command: f
> Frequency: 14026540
> 
> Wow!
> 
> xlog is unfriendly towards RPC (probably a bug):
> /dev/ttyS0: RPC: Unknown host

This is because for the RPC backend, the rig device file name is 
the hostname of the RPC server.
i.e.   rigctl -m 1901  is equivalent to   rigctl -r localhost -m 1901

So just open up the pathname combo box of xlog (anyway, USB serial port
can names different than /dev/ttySx), and allow to enter free form,
at least for the RPC backend.

I don't know yet how to pass the port number. Most probably along the
hostname, maybe something like "host:port" for an absolute port (that
can be listed in /etc/services), or "host:+number" for a rig # relative to 
the default port (0x20000099).
Comments?


Cheers,
Stephane

[Hamlib-developer] Earn 24% on your money. Annually! 0096GmPK6-760JYZu2-17

[<Est...@ya...>]

PCEtLSBzYXZlZCBmcm9tIHVybD0oMDAyMilodHRwOi8vaW50ZXJuZXQuZS1t
YWlsIC0tPg0KPGh0bWw+PGhlYWQ+DQo8dGl0bGU+TmV3IEludmVzdG1lbnQg
UGFydG5lciBQcm9kdWN0IEFubm91bmNlbWVudDwvdGl0bGU+DQo8U1RZTEU+
QTpsaW5rIHtjb2xvcjojYjIyMjIyOyB0ZXh0LWRlY29yYXRpb246bm9uZX0N
ClAge3RleHQtYWxpZ246Y2VudGVyOyBmb250OiBib2xkIDE4cHQgIlZlcmRh
bmEiLCAiQXJpYWwifQ0KUC50eHQge3RleHQtYWxpZ246Y2VudGVyOyBmb250
OiBub3JtYWwgMTRwdCAiVmVyZGFuYSIsICJBcmlhbCI7IGxldHRlci1zcGFj
aW5nOi4xMGVtO30NClAuc3RyZXRjaCB7dGV4dC1hbGlnbjpjZW50ZXI7IGZv
bnQ6IGJvbGQgMjBwdCAiVmVyZGFuYSIsICJBcmlhbCI7IGxldHRlci1zcGFj
aW5nOjEuNWVtfQ0KUC5zbWxUeHQge3RleHQtYWxpZ246Y2VudGVyOyBmb250
OiBub3JtYWwgMTBwdCAiVmVyZGFuYSIsICJBcmlhbCI7fQ0KSDEge3RleHQt
YWxpZ246Y2VudGVyOyBmb250OiBib2xkIDI0cHQgIlZlcmRhbmEiLCAiQXJp
YWwiOyBjb2xvcj13aGl0ZX08L1NUWUxFPg0KPC9oZWFkPjxib2R5IGJnY29s
b3I9IiNmZmZmZmYiIHRleHQ9I2ZmZmZmZj48Y2VudGVyPg0KPHRhYmxlIHdp
ZHRoPSI1NTAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMiIgYm9y
ZGVyPSIzIiA+DQoNCjx0cj48dGQgYmdjb2xvcj0iIzAwMDAwMCI+DQo8dGFi
bGUgd2lkdGg9IjU1MCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIw
IiBib3JkZXI9IjAiPg0KDQo8dHI+PHRkIGJnY29sb3I9IiMwMDAwMDAiPg0K
Jm5ic3A7PC90ZD4NCjwvdHI+DQoNCjx0cj48dGQgYmdjb2xvcj0iI2ZmZmZm
ZiIgdmFsaWduPSJ0b3AiPjx0YWJsZSB3aWR0aD0iNTUwIiBib3JkZXI9IjAi
IGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iNCI+DQo8dHI+PHRkIHZh
bGlnbj1jZW50ZXIgYWxpZ249bWlkZGxlIGJnY29sb3I9IiNmZjk5MDAiIHdp
ZHRoPTU1Pg0KPGEgaHJlZj0iaHR0cDovL3d3dy5uZXd0b3BpY3MuY29tLzI1
MC1CaWxsaW9uLURvbGxhci1NYXJrZXRwbGFjZS8iPjxIMT48Qj5OPEJSPkU8
QlI+VzxCUj48QlI+RTxCUj5DPEJSPk88QlI+TjxCUj5PPEJSPk08QlI+WTwv
YT48L0I+PC9IMT48L3RkPg0KDQo8dGQgdmFsaWduPSJ0b3AiIGJnY29sb3I9
IiM2Njk5ZmYiPjx0YWJsZSB3aWR0aD00NTUgY2VsbHNwYWNpbmc9IjAiIGNl
bGxwYWRkaW5nPSIxNCIgYm9yZGVyPSIwIiBhbGlnbj1jZW50ZXIgc3R5bGU9
IldJRFRIOiA0NTVweCI+DQo8dHI+PHRkIGJnY29sb3I9IiM2Njk5ZmYiIGFs
aWduPW1pZGRsZSAgdmFsaWduPWNlbnRlcj48UD5FQVJOIFVQIFRPIDI0JSBB
Tk5VQUxMWTwvUD48UCBjbGFzcz10eHQ+Tm93IHlvdSBjYW4gaW52ZXN0IGlu
IHRoZSBtb3N0IG5lZWRlZCBhbmQgZmFzdGVkIGdyb3dpbmcgaW5kdXN0cnkg
aW4gdGhlIHdvcmxkPC9QPjxQIGNsYXNzPXN0cmV0Y2g+U0VDVVJJVFkhPC9Q
PjxQIGNsYXNzPXR4dD5HZXQgdGhlIGRldGFpbHMgb24gdGhpczxCUj48YSBo
cmVmPSJodHRwOi8vd3d3Lm5ld3RvcGljcy5jb20vMjUwLUJpbGxpb24tRG9s
bGFyLU1hcmtldHBsYWNlLyI+MjUwIEJpbGxpb24tRG9sbGFyIE1hcmtldHBs
YWNlPC9hPjxCUj48QlI+PEJSPlBBWVMgUVVBUlRFUkxZIENBU0ggRElTVFJJ
QlVUSU9OUzwvUD48YSBocmVmPSJodHRwOi8vd3d3Lm5ld3RvcGljcy5jb20v
MjUwLUJpbGxpb24tRG9sbGFyLU1hcmtldHBsYWNlLyI+PFA+Q0xJQ0sgSEVS
RSBGT1IgWU9VUiBGUkVFIElORk9STUFUSU9OPC9QPjwvYT48UCBjbGFzcz1z
bWxUeHQ+WU9VIE1VU1QgQkUgMjEgT1IgT0xERVIgVE8gUVVBTElGWTwvUD48
L3RkPg0KPC90cj48L3RhYmxlPjwvdGQ+DQoNCjwvdHI+PC90YWJsZT48L3Rk
Pg0KPC90cj4NCg0KPHRyPg0KPHRkIGJnY29sb3I9IiMwMDAwMDAiIGFsaWdu
PSJtaWRkbGUiIGNvbHNwYW49IjIiPg0KDQo8dGFibGUgYm9yZGVyPSIwIiBj
ZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjIiIGFsaWduPWxlZnQ+DQo8
dHI+PHRkPjxIUiBTSVpFPTEgd2lkdGg9IjEwMCUiIGNvbG9yPXdoaXRlPjxm
b250IHNpemU9IjEiIGZhY2U9IlZlcmRhbmEsIEFyaWFsIj5Zb3VyIHByaXZh
Y3kgaXMgZXh0cmVtZWx5IGltcG9ydGFudCB0byB1cy4gJm5ic3A7WW91IHJl
cXVlc3RlZCB0byByZWNlaXZlIHRoaXMgbWFpbGluZywgYnkgc3Vic2NyaWJp
bmcgdGhyb3VnaCBvbmUgb2Ygb3VyIG1hcmtldGluZyBwYXJ0bmVycy4gJm5i
c3A7QXMgYSBsZWFkZXIgaW4gZW1haWwgbWFya2V0aW5nLCB3ZSBhcmUgY29t
bWl0dGVkIHRvIGRlbGl2ZXJpbmcgYSBoaWdobHkgcmV3YXJkaW5nIGV4cGVy
aWVuY2UsIHdpdGggb2ZmZXJzIHRoYXQgaW5jbHVkZSBiYXJnYWlucywgDQpl
bnRlcnRhaW5tZW50LCBhbmQgIG1vbmV5LW1ha2luZyBpZGVhcy4gJm5ic3A7
SG93ZXZlciwgaWYgeW91IHdpc2ggdG8gdW5zdWJzY3JpYmUsPEEgaHJlZj0i
aHR0cDovL3d3dy5uZXd0b3BpY3MuY29tL3Rha2VtZW9mZi8iIHRhcmdldD0i
X2JsYW5rIj4gY2xpY2sgaGVyZS48L0E+ICZuYnNwO1RoaXJkLXBhcnR5IG9m
ZmVycyBjb250YWluZWQgaW4gdGhpcyBlbWFpbCBhcmUgdGhlIHNvbGUgcmVz
cG9uc2liaWxpdHkgb2YgdGhlIG9mZmVyIG9yaWdpbmF0b3IuPC9mb250Pjwv
dGQ+DQo8L3RyPjwvdGFibGU+PC90ZD4NCg0KPC90cj48L3RhYmxlPjwvdGQ+
DQoNCjwvdHI+PC90YWJsZT48L2NlbnRlcj48L2JvZHk+PC9odG1sPg0KDQo0
MTI3c0dHTDQtODMyd0dTdDY3MDNjRGdIMi01MTBwVktnMDIxMFZPdUc4LTUy
NmNBdm82ODM5TGJ1UzktMjExQ1BNbDg2ODJscVFoMy00MTBsNzY=

Re: [Hamlib-developer] Re: [Groundstation-developer] Gnome RIG 0.2

[Joop S. <pa...@de...>]

On Tue, 10 Sep 2002 08:41:17 +0200
Stephane Fillod <f8...@fr...> wrote:

> 
> And the answer already exists. Alex would tell you to use his Bonobo
> control, but there is simpler for simple application: the RPC backend.
> Just run rpc.rigd on the localhost, tell xlog and grig to use MODEL_RPC,
> they will share the rig. And voila!
> 


Why didn't I think of this before? Excuse my stupidity...


> This way, no need to put hacks in all the applications around to make them
> live together.
> 
> What do you think?
> 

sudo rpc.rigd -m 210 -v &
Opened rig model 210, 'TS-870S'

rigctl -m 1901

Rig command: f
Frequency: 14026540

Wow!

xlog is unfriendly towards RPC (probably a bug):
/dev/ttyS0: RPC: Unknown host

> 
> Cheers,
> Stephane
> 
> 

Thanks,
Joop

Re: [Hamlib-developer] Re: [Groundstation-developer] Gnome RIG 0.2

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

Hi Joop and Stephane,


> > > know anything about hamlib. Eventually, this widget will become a bonobo control
> > > making it embedable in any Gnome program that can use bonobo controls (Gnumeric,
> > > Abiword, etc. - yes, you will be able to control your RIGs from your spreadsheet
> > > file :-).
> > 
> > Weird stuff....
> 
> You'll see, one day you'll be able to rotate your 32x moon melter array from emacs!
> 

I think you can already do that but you might need some Emacs/Lisp
bindings for Hamlib ;-)


> > I got word from terry, the hamlib maintainer for debian, that he is working on
> > hamlib-1.1.3. I'd really like to test grig, but gnome is quite a mess at the
> > moment in debian/unstable. I would like to wait until the migration to
> > gnome2 is finished.
> 
> hey, that's great news (well, not for gnome :(
> 

I have tried to compile grig on Debian 3.0r0 which comes with Gnome 1.4,
but I have no experience with Debian/unstable.


> > Now that we have a nice program for displaying and controlling the rig's
> > frequency and other things, have you ever thought about possible information
> > exchange between different programs? I am using xlog for logging and when
> > I do, I can't use grig (and vice-versa). It would be nice if there was some
> > kind of way for either of these programs to work together. We could think of
> > message queues or shared memory. This way I can run xlog, have grig displaying
> > the frequency and still use hamlib for my logging information with xlog...
> 
> And the answer already exists. Alex would tell you to use his Bonobo
> control, but there is simpler for simple application: the RPC backend.
> Just run rpc.rigd on the localhost, tell xlog and grig to use MODEL_RPC,
> they will share the rig. And voila!
> 
> This way, no need to put hacks in all the applications around to make them
> live together.
> 
> What do you think?
> 

I probably would have agreed on some shared memory or FIFO, but I think
Stephane is right. If the RPC backend can handle multiple clients, there
is no need to redo that or something similar in the client applications.
Question: Can you have more than one rpc.rigd's running on the same host
but controlling different rigs? If not, can it be done?


Alex

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] Re: [Groundstation-developer] Gnome RIG 0.2

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

Hi Alex and Joop,


On Mon, Sep 09, 2002, Joop Stakenborg wrote:
> > know anything about hamlib. Eventually, this widget will become a bonobo control
> > making it embedable in any Gnome program that can use bonobo controls (Gnumeric,
> > Abiword, etc. - yes, you will be able to control your RIGs from your spreadsheet
> > file :-).
> 
> Weird stuff....

You'll see, one day you'll be able to rotate your 32x moon melter array from emacs!

 
> I got word from terry, the hamlib maintainer for debian, that he is working on
> hamlib-1.1.3. I'd really like to test grig, but gnome is quite a mess at the
> moment in debian/unstable. I would like to wait until the migration to
> gnome2 is finished.

hey, that's great news (well, not for gnome :(

> Now that we have a nice program for displaying and controlling the rig's
> frequency and other things, have you ever thought about possible information
> exchange between different programs? I am using xlog for logging and when
> I do, I can't use grig (and vice-versa). It would be nice if there was some
> kind of way for either of these programs to work together. We could think of
> message queues or shared memory. This way I can run xlog, have grig displaying
> the frequency and still use hamlib for my logging information with xlog...

And the answer already exists. Alex would tell you to use his Bonobo
control, but there is simpler for simple application: the RPC backend.
Just run rpc.rigd on the localhost, tell xlog and grig to use MODEL_RPC,
they will share the rig. And voila!

This way, no need to put hacks in all the applications around to make them
live together.

What do you think?


Cheers,
Stephane

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

[Hamlib-developer] Earn $50,000 part time

[<Bel...@ya...>]

<!-- saved from url=(0022)http://internet.e-mail -->
<HTML><HEAD>
<TITLE></TITLE>
<STYLE>A:link {color:red}</STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<TABLE cellSpacing=0 cellPadding=14 width=600 border=3 bordercolordark=#003366 bordercolorlight=#669999 bordercolor=#003366>
  <TBODY>
	<TR>
	<TD width=200 bgcolor=#4682b4 valign=top><FONT face="Verdana, Arial" color=#ffffff size=4>
		<B>DON'T DREAM TO LIVE! ...<BR><BR>LIVE THE DREAM</B><BR></FONT>
		<FONT face="Verdana, Arial" color=#ffffff size=2><BR><B>
		<LI>Be your own BOSS
		<LI>Work your own HOURS
		<LI>No FIXED overhead
		<LI>High CASH return 
		<LI>INCOME Suppliment
		<LI>Part Time Business</B></FONT></LI>
		<font color=#4682b4>qwertyuioplkj<BR>hgfdsazxcvbnm,.<BR>/0987654321<BR>kdjdjdhfyhsggf<BR>JDHXGDNGDRW<BR>KFOFGJDHDHGS<BR>sazxcvbnm,.<BR>/0987654321<BR>kdjdjdhfyhsggf<BR>JDHXGD<BR>qwertyuioplkj<BR>hgfdsazxcvbnm,.<BR>/0987654321<BR>kdjdjdhfyhsggf<BR>JDHXGDNGDRW<BR>KFOFGJDHDHGS</font>
	</TD>
    <TD  width=400>
		<FONT face="Verdana, Arial" color=#000050 size=3>
		<B>Dear Future Business Owner,</B> 
		<P align=center><FONT face="Verdana, Arial" color=#000050 size=2>
		You can now for the first time, own a business in your area with the most unique, innovative product in America today.<BR><BR>
		Work less than ten hours a week with the potential to earn $50,000 a year.<BR><BR>Here's how!  Over 300 Million people use this product in the U.S.
		daily, that's right, over 300 Million people.<BR><BR>The profit margin with us is an amazing 400%, you will be saying
		to yourself why didn't I think of that!<BR><BR>	Break down the walls and live this life you've only dreamed about.<BR><BR>
		<BR>Availabilty is your area is limited.<BR><A href="http://365.businessonlinenow.com/brush/">
		<B>CLICK HERE NOW</B></A><BR>So you too can receive your free information package today.
		<BR><BR><A href="http://365.businessonlinenow.com/brush/">
		<FONT face="Verdana, Arial" color=#cc3333 size=5><B><I>Don't wait any longer!<BR>Get Started Today!!</I></B></FONT></A></FONT></P>
	</TD></TR></TBODY></TABLE><BR>
<TABLE width=550>
  <TBODY>
  <TR >
    <TD align=center>
		<HR SIZE=1 width="100%" color=indigo>
		<font size="1" face="Verdana, Arial">Your email address was obtained from an opt-in list. Opt-in MRSA List
		<BR>Purchase Code # 312-2412.  If you wish to be unsubscribed from this list, please <A href="http://365.businessonlinenow.com/brush/remove.html" target="_blank">click here</A></font>
		<font color=ffffff>qwertyuioplkjhgfdsazxcvbnm,./0987654321</font>
    </TD></TR></TBODY></TABLE></BODY></HTML>
8736moWF8-347gaay7435l20

[Hamlib-developer] Re: [Groundstation-developer] Gnome RIG 0.2

[Joop S. <pa...@de...>]

On Tue, 20 Aug 2002 02:31:07 +0200 (MEST)
al...@ph... wrote:

> Hi everybody,
> 
> I am happy to announce the first official release of Gnome RIG (grig-0.2). Gnome
> RIG is a graphical user interface to the Ham Radio Control Libraries, written
> using the Gtk+ and GNOME widgets. In the present release only a little subset of
> the full Hamlib API is supported (power, frequency, mode, filter, agc and some
> gain levels) but more widgets will be added along the way.
> 
> The controls are packed into a single Gtk-widget, making it easy to include them
> in any other Gtk/Gnome program. There are wrapper functions for the supported
> hamlib API calls, so a program using this 'hamlib-widget' doesn't even need to
> know anything about hamlib. Eventually, this widget will become a bonobo control
> making it embedable in any Gnome program that can use bonobo controls (Gnumeric,
> Abiword, etc. - yes, you will be able to control your RIGs from your spreadsheet
> file :-).

Weird stuff....

> Gnome RIG works with both version 1.1.2 and 1.1.3 of Hamlib. I have chosen to
> support both versions, because Debian 3.0 comes with hamlib-1.1.2. The only
> difference, as seen from the program, is the lack of rotator support in 1.1.2.
> Although rotator controls are not implemented yet, the program will ask you to
> configure your rotators anyway (just select the dummy backend if you don't have
> any).
> 


Hi Alex,

I got word from terry, the hamlib maintainer for debian, that he is working on
hamlib-1.1.3. I'd really like to test grig, but gnome is quite a mess at the
moment in debian/unstable. I would like to wait until the migration to
gnome2 is finished.

Now that we have a nice program for displaying and controlling the rig's
frequency and other things, have you ever thought about possible information
exchange between different programs? I am using xlog for logging and when
I do, I can't use grig (and vice-versa). It would be nice if there was some
kind of way for either of these programs to work together. We could think of
message queues or shared memory. This way I can run xlog, have grig displaying
the frequency and still use hamlib for my logging information with xlog...

One of the involved hamlib controlling programs, would have to be the hamlib 
master and a simple handshake will tell the slaves to stop controlling
the hamlib port. As far as I'm concerned, grig looks like the best candidate
for the master job....

Any thoughts?

> Oh, by the way, if anyone is going to wonder how to change the frequency, just
> left/right click on any digit of the frequency display. There isn't and will
> never be any 'software tuning knob' as I find them silly and rather useless.
> There will, however, be support for hardware tuning knobs that can be plugged
> into the USB port (http://www.griffintechnology.com/products/powermate).
> 
> Unfortunately, I can only test the program with the dummy backend, so I hope
> that many of you will test it with real radios. You can get the source code from:
> 
> http://sourceforge.net/project/showfiles.php?group_id=25530
> Comments and questions are welcome!
> 
> 
> Alex, OZ9AEC
> 
> 

Regards,
Joop PA4TU

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] IC910 get_freq does not work

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

Hi Luc,

On Sat, Sep 07, 2002, Luc Langehegermann wrote:
> Another problem with the IC910. Here the debug output:
> 
> > TX 6 bytes
> > 0000     fe fe 60 e0 03 fd      ..`...
> > RX 6 characters
> > 0000     fe fe 60 e0 03 fd      ..`...
> > RX 11 characters
> > 0000     fe fe e0 60 03 00 00 00 45 01 fd       ...`....E..
> > icom_get_freq: wrong frame len=5
> > icom: Unsupported VFO 0
> 
> The answer is correct according to the manual!

oops, it looks like the ic910 caps was initialized in 731 mode (freq on
4 bytes). This should be fixed now on the cvs rep.

Stephane

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

[Hamlib-developer] IC910 get_freq does not work

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

Hello,

Another problem with the IC910. Here the debug output:

> TX 6 bytes
> 0000     fe fe 60 e0 03 fd      ..`...
> RX 6 characters
> 0000     fe fe 60 e0 03 fd      ..`...
> RX 11 characters
> 0000     fe fe e0 60 03 00 00 00 45 01 fd       ...`....E..
> icom_get_freq: wrong frame len=3D5
> icom: Unsupported VFO 0

The answer is correct according to the manual!

Luc

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

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

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

[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] Re: Patches for FreeBSD, part I

[Michael S. <jam...@ea...>]

On Mon, 2 Sep 2002 00:20:01 +0200
Stephane Fillod <f8...@fr...> wrote:

> Sorry to be a bit picky, your patches are fine for *BSD, but they could
> be even better for non BSD system that are *BSD like. Besides, this is
> the whole philosophy behind autoconf. Do not test for a system, but
> rather for the existence (or lack thereof) of a feature.

Be picky :) I don' get in a twist that easily. The format for the patches was based on more traditional *BSD methods; I'll come at it more generally. 

> In other words, I would like to get rid of "#if !defined(BSD)".
> For event.c.patch, it looks trivial since it can be done by detecting 
> presence of F_SETSIG.

Basing it off F_SETSIG is fine as well; BSD does not support F_SETSIG. I'll re-do it based on that.

> Does *BSD have both TERMIOS and TERMIO?

Yes. See below:

> May be the right fix would be:
> 
> 	#ifdef HAVE_TERMIOS_H
> 	#include <termios.h> /* POSIX terminal control definitions */
> 	#else
> 	#ifdef HAVE_TERMIO_H
> 	#include <termio.h>
> 	#else  /* sgtty */
> 	#include <sgtty.h>
> 	#endif
> 	#endif

This has the same effect, so by all means please change it. It fixes the issue. And you are correct, it is more general.

 
> NB: added 'else' statement after HAVE_TERMIOS_H
> 
> > I am still working on patches for rpcrig and rpcrot, and will post them as soon as they are ready.
> 
> They'll be very welcome.
> Be careful, for rpcrig and rpcrot, some files are auto-generated.

Or, in the case of the bug I'm looking at, not auto-generated at all. Seeing the recent mail from Joop, this may have gone away anyway.

73s

mike

[Hamlib-developer] Earn $50,000 part time 5845-4

[<Jer...@ya...>]

PCEtLSBzYXZlZCBmcm9tIHVybD0oMDAyMilodHRwOi8vaW50ZXJuZXQuZS1t
YWlsIC0tPg0KPEhUTUw+PEhFQUQ+DQo8VElUTEU+SW5zdGEtQnJ1c2ggRGlz
cG9zYWJsZSBUb290aGJydXNoZXM8L1RJVExFPg0KPFNUWUxFPkE6bGluayB7
Y29sb3I6cmVkfTwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9EWSBiZ0NvbG9yPSNm
ZmZmZmY+DQo8VEFCTEUgY2VsbFNwYWNpbmc9MCBjZWxsUGFkZGluZz0xNCB3
aWR0aD02MDAgYm9yZGVyPTMgYm9yZGVyY29sb3JkYXJrPSMwMDMzNjYgYm9y
ZGVyY29sb3JsaWdodD0jNjY5OTk5IGJvcmRlcmNvbG9yPSMwMDMzNjY+DQog
IDxUQk9EWT4NCgk8VFI+DQoJPFREIHdpZHRoPTIwMCBiZ2NvbG9yPSM0Njgy
YjQgdmFsaWduPXRvcD48Rk9OVCBmYWNlPSJWZXJkYW5hLCBBcmlhbCIgY29s
b3I9I2ZmZmZmZiBzaXplPTQ+DQoJCTxCPkRPTidUIERSRUFNIFRPIExJVkUh
IC4uLjxCUj48QlI+TElWRSBUSEUgRFJFQU08L0I+PEJSPjwvRk9OVD4NCgkJ
PEZPTlQgZmFjZT0iVmVyZGFuYSwgQXJpYWwiIGNvbG9yPSNmZmZmZmYgc2l6
ZT0yPjxCUj48Qj4NCgkJPExJPkJlIHlvdXIgb3duIEJPU1MNCgkJPExJPldv
cmsgeW91ciBvd24gSE9VUlMNCgkJPExJPk5vIEZJWEVEIG92ZXJoZWFkDQoJ
CTxMST5IaWdoIENBU0ggcmV0dXJuIA0KCQk8TEk+SU5DT01FIFN1cHBsZW1l
bnQNCgkJPExJPlBhcnQgVGltZSBCdXNpbmVzczwvQj48L0ZPTlQ+PC9MST4N
CgkJPGZvbnQgY29sb3I9IzQ2ODJiND5xd2VydHl1aW9wbGtqPEJSPmhnZmRz
YXp4Y3Zibm0sLjxCUj4vMDk4NzY1NDMyMTxCUj5rZGpkamRoZnloc2dnZjxC
Uj5KREhYR0ROR0RSVzxCUj5LRk9GR0pESERIR1M8QlI+c2F6eGN2Ym5tLC48
QlI+LzA5ODc2NTQzMjE8QlI+a2RqZGpkaGZ5aHNnZ2Y8QlI+SkRIWEdEPEJS
PnF3ZXJ0eXVpb3Bsa2o8QlI+aGdmZHNhenhjdmJubSwuPEJSPi8wOTg3NjU0
MzIxPEJSPmtkamRqZGhmeWhzZ2dmPEJSPkpESFhHRE5HRFJXPEJSPktGT0ZH
SkRIREhHUzwvZm9udD4NCgk8L1REPg0KICAgIDxURCAgd2lkdGg9NDAwPg0K
CQk8Rk9OVCBmYWNlPSJWZXJkYW5hLCBBcmlhbCIgY29sb3I9IzAwMDA1MCBz
aXplPTM+DQoJCTxCPkRlYXIgRnV0dXJlIEJ1c2luZXNzIE93bmVyLDwvQj4g
DQoJCTxQIGFsaWduPWNlbnRlcj48Rk9OVCBmYWNlPSJWZXJkYW5hLCBBcmlh
bCIgY29sb3I9IzAwMDA1MCBzaXplPTI+DQoJCVlvdSBjYW4gbm93IGZvciB0
aGUgZmlyc3QgdGltZSwgb3duIGEgYnVzaW5lc3MgaW4geW91ciBhcmVhIHdp
dGggdGhlIG1vc3QgdW5pcXVlLCBpbm5vdmF0aXZlIHByb2R1Y3QgaW4gQW1l
cmljYSB0b2RheS48QlI+PEJSPg0KCQlXb3JrIGxlc3MgdGhhbiB0ZW4gaG91
cnMgYSB3ZWVrIHdpdGggdGhlIHBvdGVudGlhbCB0byBlYXJuICQ1MCwwMDAg
YSB5ZWFyLjxCUj48QlI+SGVyZSdzIGhvdyEgIE92ZXIgMzAwIE1pbGxpb24g
cGVvcGxlIHVzZSB0aGlzIHByb2R1Y3QgaW4gdGhlIFUuUy4NCgkJZGFpbHks
IHRoYXQncyByaWdodCwgb3ZlciAzMDAgTWlsbGlvbiBwZW9wbGUuPEJSPjxm
b250IGNvbG9yPSNGRkZGRkY+cXdlcnR5dWlvcGxrampmamhtLC47cG9peXU1
U0hERkpJRkxoZ2Zkc2F6eGN2Ym5tLC48L2ZvbnQ+PEJSPlRoZSBwcm9maXQg
bWFyZ2luIHdpdGggdXMgaXMgYW4gYW1hemluZyA0MDAlLCB5b3Ugd2lsbCBi
ZSBzYXlpbmcNCgkJdG8geW91cnNlbGYgd2h5IGRpZG4ndCBJIHRoaW5rIG9m
IHRoYXQhPEJSPjxmb250IGNvbG9yPSNGRkZGRkY+cXdlcnR5dWlvcGxrampm
amhtLC47cG9peXU1U0hERkpJRkxoZ2Zkc2F6eGN2Ym5tLC48L2ZvbnQ+PEJS
PglCcmVhayBkb3duIHRoZSB3YWxscyBhbmQgbGl2ZSB0aGlzIGxpZmUgeW91
J3ZlIG9ubHkgZHJlYW1lZCBhYm91dC48QlI+PEJSPg0KCQlMZXNzIHRoZW4g
MTBLIHJlcXVpcmVkIHRvIGdldCBzdGFydGVkLjxCUj5BdmFpbGFiaWx0eSBp
cyB5b3VyIGFyZWEgaXMgbGltaXRlZC48QlI+PEEgaHJlZj0iaHR0cDovLzM2
NS5saWFuZ3NoYW5wby5jb20vYnJ1c2gvIj4NCgkJPEI+Q0xJQ0sgSEVSRSBO
T1c8L0I+PC9BPjxCUj5TbyB5b3UgdG9vIGNhbiByZWNlaXZlIHlvdXIgZnJl
ZSBpbmZvcm1hdGlvbiBwYWNrYWdlIHRvZGF5Lg0KCQk8QlI+PEJSPjxBIGhy
ZWY9Imh0dHA6Ly8zNjUubGlhbmdzaGFucG8uY29tL2JydXNoLyI+DQoJCTxG
T05UIGZhY2U9IlZlcmRhbmEsIEFyaWFsIiBjb2xvcj0jY2MzMzMzIHNpemU9
NT48Qj48ST5Eb24ndCB3YWl0IGFueSBsb25nZXIhPEJSPkdldCBTdGFydGVk
IFRvZGF5ISE8L0k+PC9CPjwvRk9OVD48L0E+PC9GT05UPjwvUD4NCgk8L1RE
PjwvVFI+PC9UQk9EWT48L1RBQkxFPjxCUj4NCjxUQUJMRSB3aWR0aD01NTA+
DQogIDxUQk9EWT4NCiAgPFRSID4NCiAgICA8VEQgYWxpZ249Y2VudGVyPg0K
CQk8SFIgU0laRT0xIHdpZHRoPSIxMDAlIiBjb2xvcj1pbmRpZ28+DQoJCTxm
b250IHNpemU9IjEiIGZhY2U9IlZlcmRhbmEsIEFyaWFsIj5Zb3VyIGVtYWls
IGFkZHJlc3Mgd2FzIG9idGFpbmVkIGZyb20gYW4gb3B0LWluIGxpc3QuIE9w
dC1pbiBNUlNBIExpc3QNCgkJPEJSPlB1cmNoYXNlIENvZGUgIyAzMTItMjQx
Mi4gIElmIHlvdSB3aXNoIHRvIGJlIHVuc3Vic2NyaWJlZCBmcm9tIHRoaXMg
bGlzdCwgcGxlYXNlIDxBIGhyZWY9Imh0dHA6Ly8zNjUubGlhbmdzaGFucG8u
Y29tL2JydXNoL3JlbW92ZS5odG1sIiB0YXJnZXQ9Il9ibGFuayI+Y2xpY2sg
aGVyZTwvQT48L2ZvbnQ+DQoJCTxmb250IGNvbG9yPWZmZmZmZj5xd2VydHl1
aW9wbGtqaGdmZHNhenhjdmJubSwuLzA5ODc2NTQzMjE8L2ZvbnQ+DQogICAg
PC9URD48L1RSPjwvVEJPRFk+PC9UQUJMRT48L0JPRFk+PC9IVE1MPg0KODA5
OUJmUXoxLTY4MXdkYVY5NWwxOA==