hamlib-developer — hamlib developers forum

[Hamlib-developer] Re: Kenwood backend, etc

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

Quoting Francois Retief <fgr...@su...>:
> Yes. The Kenwood THD7 has a very extensive async reporting system (more
> than the current callbacks in hamlib.) I succeded in getting some of the
> async callbacks to work for THD7.

Great! We'll have to add the new callbacks to the frontend.
However, if I remember well, the "AI" command does not send what has changed 
but the complete status of the rig right after the event happened. 
Is it what you noticed on the THD7?
So the backend would have to remember the previous state, and from the delta,
find and call only the appropriate callbacks. Is it worth the trouble?

> In the process I created the  th_transaction function, replacing the 
> kenwood_transaction.  It supports error checking, can do retries and 
> is tolerant to async messages.  It might also be possible to extend
> it to handle the other kenwood radios.

Yep, and maybe some other ASCII oriented backends may want to clone it..

> > BTW, what is your sourceforge login name so I add you to the developer
> > list. It'll be easier for you to commit directly to the cvs rep.
> 
> I created an account today. login name: fgretief
> Once created I'll commit my latest changes.

okay, you're in. happy hacking! 
There's no written down rules, just common sense. Adding stuff is no problem.
Just ask for discussion on the list if you plan to do major or heavy
changes on the API/frontend.

> I have been playing with a Hamlib binding for Borland's Kylix.
> Should I contribute it to Hamlib? 

Oh yes, sure! please! We have already c++, tcl, and I can see perl
and python bindings which stand out in the horizon.
You can create a separate directory, much like c++ and tcl, coming along 
with a simple sample program illustrating the new binding. This will give 
others (starting from me :) envy and a quick start in Borland's Kylix.

Cheers,
 Stephane

[Hamlib-developer] libhamlibtcl.so

[Ellis W. <k0...@ya...>]

Stephane:

I did a brute force relink of libhamlibtcl.so
to libhamlib.so and discovered that what has been
implemented is as you say "a proof of concept".

I will take a shot at completing what has been
so far implemented for my own puposes. When I 
have something to contribute I'll let you know.


The other obstacle I encountered was accessing the
correct serial port.  It seems that the serial port is
hard coded to "/dev/ttys0"? Is there another way
to specify the device without recompiling the library?
My system uses several serial ports for mouse, 
rig control, keying the transmitter for PSK, 
a TNC for packet ... 

73, K0ELW  Ellis Workman


> Message: 2
> Date: Sun, 6 Jan 2002 18:38:11 +0100
> From: Stephane Fillod <f4...@fr...>
> To: Hamlib developers
> <ham...@li...>
> Subject: Re: [Hamlib-developer] libhamlibtcl.so
> 
> 
> Hi Ellis!
> 
> I'm very pleased you've been successful with Hamlib
> on your Ic706MkIIG.
> Isn't it an interresting rig?
> 
> On Thu, Jan 03, 2002, Ellis Workman wrote:
> > I am interested in using the libhamlibtcl.so
> > to write an interface with Tk. tclsh
> > is unable to load libhamlibtcl.so complaining 
> > of an unknown symbol "hamlib_version". It
> > would appear that it's not finding or linking
> > to libhamlib.so.
> 
> So far, hamlibtcl is just a proof-of-concept.
> Development hasn't gone
> further because nobody was interrested in. But it's
> going to change if I'm
> not mistaken ;-)
> Running the "tcl/tcltest.tcl" script gave me the
> exact error as yours.
> And you're right, the libhamlib.so dependancy was
> missing in the
> Makefile.am!  It's fixed now, commited to cvs and it
> works.
> 
> Right now, hamlibtcl has only support for set_freq
> and get_strength
> (the idea was to do a quick and dirty band scope).
> But the other commands can be added quite easily
> (who said wrappers
> are boring to develop? :)
> Lex and copy/paste from rigctl may help.
> 
> Anyway, let me know if you can test the latest cvs
> version, 
> and how it goes with wish.
> 
> 
> 73,
> Stephane F8CFE


=====
Ellis Workman KØELW  
Grid EN33sx Olmsted County
Rochester, MN

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

Re: [Hamlib-developer] Looking for apps using hamlib

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

Hi John!

On Fri, Jan 04, 2002, John Chubick wrote:
> I've been reading up on hamlib as I've been looking for a radio control program to run on my Linux machine.  I have a development background (mainly Java and some C and VB) but I don't know C++ and I've never developed for Linux.  Before I tackle trying
> to write something from scratch using the hamlib libraries I was looking
for something already written for my Kenwood TS-570.  Can anyone point me in the right direction?
>

If you want something quick to test raw functions of Hamlib, you might
want to try "rigctl -vvvv -m 204" included in Hamlib (latest cvs version).
As a matter of coincidence, the TS-570D capabilities were just entered
last week, but it need some tests! 
Make sure your rig is setup to 57600 bps, or pass "--serial-speed xxx" to
rigctl.
Once the backend of your rig works fine, any application using Hamlib will
work with your rig!

Also, check with Robert or Alexandru if you're looking for a GUI.

BTW, what are you interrested in Hamlib?  Control a rig relocated in the
attic, doppler compensation, or just playing with fun stuff?

Note: Hamlib is supposed to be portable, and should work under Win32 using
cygwin. Anyone interested?


Cheers,

Stephane F8CFE

async messages and Re: [Hamlib-developer] Re: Kenwood TH-D7A(G) patch

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

Hi Francois!

On Fri, Jan 04, 2002, Francois Retief wrote:
> Here is some more. ;-) Should I add the commands to the th.c or thd7.c
> file?   Do you know how similar the TH-F7E/TH-D7 are?

If I know? It's very simple. I have absolutly no documentation
whatsoever on the TH-F7E protocol. Google is dumb on the subject.
So when I tried the table top Kenwood protocol and firgured out it wasn't 
the right one, it turned out the TH-D7 worked. So as long as it works,
I'll assume TH-F7E/TH-D7 are similar :)  So go ahead, add the commands to
the th.c file, and I'll test them on my TH-F7E.

I guess to right solution would be to ask a Kenwood representative to
disclose the procotol specifications..

> I aspect that still bother me is how async messages should be handled.
> How does the callback infrastructure of hamlib work? I don't quite
> follow the Icom implementation.

The async messages works in Hamlib using SIGIO. aoi would be better but
it's not yet mature for Linux (wip).
Have a look in src/event.c
 * add_trn_rig() installs a sig handler dispatcher and setup the file
		descriptor to send SIGIO whenever data arrived.
 * sigiohandler, unfortunately the O_ASYNC/SIGINFO is unable to report the
		associated fd, which is really too bad. So sigiohandler
		has to find it out.
 * search_rig_and_decode() checks if the rig sent async messages and
		then calls the decode_event method associated to the
		backend.
 * decode_event then in turn decode the message and calls any appropriate
		setup rig_callbacks.

In order to support async messages, all a backend needs to have is the
decode_event function, and eventually set_trn/get_trn if available.

Note: there's a race hazard because of the async nature. Async IO has to
be disabled during normal backend transactions, hence the
state.hold_decode field. This acts as a mutex, however, right now, it's
not completly safe because the operation may not be atomic. To be fix one
day, when event decoding becomes more mature (read tested :).

There's a sample user program tests/testtrn.c, and it works with my Ic706.
I know Kenwood protocol is able to report async events. Do you have
the format of the "AI" async message?

> Almost all the Kenwood command are string based. Thus we can work
> with strings instead of buffer/length.  See the read_string
> function I added with the Easycomm patch. It is basically a 
> replacement for the port_transaction function.

Hmmm, the attached patch in your mail is the same one you sent me already
last week (hamlib.kenwood_thd7.20020103.patch). 

BTW, what is your sourceforge login name so I add you to the developer
list. It'll be easier for you to commit directly to the cvs rep.

> btw. Why the difference between read_block and fread_block?

read_block is using read and fread_block is using fread.
The difference is read is non-buffered whereas fread is. 
This means fread tries to read more than you requested, so any subsequent
call to fread will save for system calls.
IOW, this is a performance improvement, esp. when reading bytes one by
one.


Cheers,

Stephane


> diff -u3 -rP --exclude=CVS --exclude='*.in' --exclude=configure --exclude=aclocal.m4 --exclude=autom4te.cache --exclude='*~' hamlib-cvs/kenwood/th.c hamlib-20020103/kenwood/th.c
> --- hamlib-cvs/kenwood/th.c	Fri Dec 21 10:48:40 2001
> +++ hamlib-20020103/kenwood/th.c	Thu Jan  3 19:35:53 2002
> @@ -62,7 +62,7 @@
>  int th_set_vfo(RIG *rig, vfo_t vfo)
>  {

Re: [Hamlib-developer] libhamlibtcl.so

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

Hi Ellis!

I'm very pleased you've been successful with Hamlib on your Ic706MkIIG.
Isn't it an interresting rig?

On Thu, Jan 03, 2002, Ellis Workman wrote:
> I am interested in using the libhamlibtcl.so
> to write an interface with Tk. tclsh
> is unable to load libhamlibtcl.so complaining 
> of an unknown symbol "hamlib_version". It
> would appear that it's not finding or linking
> to libhamlib.so.

So far, hamlibtcl is just a proof-of-concept. Development hasn't gone
further because nobody was interrested in. But it's going to change if I'm
not mistaken ;-)
Running the "tcl/tcltest.tcl" script gave me the exact error as yours.
And you're right, the libhamlib.so dependancy was missing in the
Makefile.am!  It's fixed now, commited to cvs and it works.

Right now, hamlibtcl has only support for set_freq and get_strength
(the idea was to do a quick and dirty band scope).
But the other commands can be added quite easily (who said wrappers
are boring to develop? :)
Lex and copy/paste from rigctl may help.

Anyway, let me know if you can test the latest cvs version, 
and how it goes with wish.


73,
Stephane F8CFE

Re: [Hamlib-developer] Tentec Pegasus application

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

Hi Jim!

On Thu, Jan 03, 2002, James Chance wrote:
> I'm not a developer (but am no Linux newbie either). I'm an amateur who has been using Linux since Slackware v1.0, and who now has a Pegasus I would like to be able to use while running Linux (without resorting to Wine). Has anyone here on the list got 
a Pegasus rig control implementation that needs hammering? If so, I'd love to volunteer.

Ah! The Slackware 1.0 and its huge pile of floppies. The dream of every 
SLS hacker! That's where this 150MB tape came handy.

You own a Pegasus? Great! I have the specs, but no hardware to test it.
A tentec backend already exists, and I just commited the pegasus caps
to the cvs rep. Let me know if you're ready to test Hamlib directly from
cvs checkouts. It's more convenient for me, otherwise, I would have to
make prerelease tar balls.
After build and install, you can test your rig with "rigctl -m 1601 -vvv".
If anything goes wrong (and I'm pretty sure it will), please report with
traces.  A lot of functions are still missing, but set_freq/set_mode
should work though. Patches are welcome, protocol is available at
http://www.tentec.com/550/550prg2.pdf


Happy hammering!

73,
Stephane F8CFE

Re: [Hamlib-developer] TS-870: test 2

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

On Thu, 3 Jan 2002 00:08:14 +0100
Stephane Fillod <f4...@fr...> wrote:

> In the meantime something is
> devised, the workaround I would recommand is to set LD_LIBRARY_PATH
> to the path where your backend modules are installed:
> 
> 	export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/lib"
>

Ok this works.
 
> > Secondly, make install fails in the include directory.
> > include/Makefile.am has lines like:
> > 
> > includedir = @includedir@/hamlib
> > include_HEADERS = hamlib/rig.h hamlib/riglist.h hamlib/rig_dll.h \
> >                 hamlib/rotator.h hamlib/rotlist.h hamlib/rigclass.h
> > 
> > which causes /usr/local/include/hamlib to be created (correct) and
> > header files want to go into /usr/local/include/hamlib/hamlib,
> > which fails. The fix is trivial I guess.
> 
> Huh!? can you send me some traces and also your autoconf/automake version
> numbers? I don't have any header install problems here with
> autoconf-2.52-4 and automake-1.5-1.1 (debian woody).
> 

Maybe it's my stupidity....
It happens when I make a modification to one of the files in the
kenwood directory, save it and do a "make; make install".

Here is the trace:

Making install in include
make[1]: Entering directory `/home/aba/Projects/hamlib/hamlib-test/hamlib.pa4tu/include'
make[2]: Entering directory `/home/aba/Projects/hamlib/hamlib-test/hamlib.pa4tu/include'
make[2]: Nothing to be done for `install-exec-am'.
/bin/sh ../mkinstalldirs /usr/local/include/hamlib
 /usr/bin/install -c -m 644 hamlib/rig.h /usr/local/include/hamlib/hamlib/rig.h
/usr/bin/install: cannot create regular file `/usr/local/include/hamlib/hamlib/rig.h': No such file or directory
.
.
.
/usr/bin/install -c -m 644 hamlib/rigclass.h /usr/local/include/hamlib/hamlib/rigclass.h
/usr/bin/install: cannot create regular file `/usr/local/include/hamlib/hamlib/rigclass.h': No such file or directory
make[2]: *** [install-includeHEADERS] Error 1
make[2]: Leaving directory `/home/aba/Projects/hamlib/hamlib-test/hamlib.pa4tu/include'
make[1]: *** [install-am] Error 2
make[1]: Leaving directory `/home/aba/Projects/hamlib/hamlib-test/hamlib.pa4tu/include'
make: *** [install-recursive] Error 1

versions: automake 1.4-p4, autoconf 2.52 (Debian Sid).

I have checked out the CVS version of January 5th.
set_vfo/get_vfo, set_freq/get_freq, set_mode/get_mode are all OK.

I have attached a simple patch which fixes rig_get_strength and rig_get_level
for the attenuator, RF, SQL, AF and MIC gain. It also displays signal strength
in db now. More later...

Regards, Joop

[Hamlib-developer] Meilleurs Vœux pour 2002 : année de mémoire, de mobilisation, d'action, de justice et de sérénité - Appel au soutien moral et financier

[Habib HAIBI<ha...@fr...>]

Meilleurs Vœux pour 2002 : année de mémoire, de mobilisation, 
d'action, de justice et de sérénité - Appel au soutien moral et 
financier

========================
M. Habib HAIBI,
7, Aguesseau St.
69007 LYON - France
Tél. 00 33 4 72 73 19 08 - Fax 00 33 4 78 61 39 27 
Email : ha...@fr...
http://haibi.free.fr


Je suis qualifié pour exprimer mes voeux pour le Nouvel An à 
tous les survivants et les familles des victimes des attaques 
terroristes, au peuple américain, ses dirigeants, ses institutions, 
son président et tous les combattants de la liberté, loin de leurs 
foyers, tout autour du monde! 

Je suis fier de vous dire avec gratitude combien Les USA sont 
puissants, démocratiques et qualifiés pour défendre la liberté et la 
démocratie avec humanisme et sérénité.

L'ennemi du progrès du genre humain peut encore frapper. La 
liberté et la démocratie peuvent être encore sous attaques!

Personne ne s'imaginait que cela pouvait arriver et c'est arrivé en 
ce jour pacifique du 11 septembre 2001

Personne ne s'imaginait que cela pouvait arriver… en France et 
c'est arrivé le 26 février 2001 quand les magistrats du parquet de 
Lyon, par impulsion suicidaire et préméditée, ont eu recours à 
l'arbitraire pour entraver l'action Publique mise en Mouvement : ils 
ont requis l'expertise psychiatrique de la Partie Civile par l'action 
avant de l'entendre dans ses accusations !

Cette dérive obscurantiste a dépassé tout entendement

C'est arrivé un jour pacifique pour moi et pour les institutions de la 
République en France.

Le réquisitoire aux fins de l'expertise psychiatrique de la partie 
civile par l'action, avant de l'entendre dans ses accusations, 
constitue une atteinte obscurantiste à l'intégrité de la personne 
de la partie civile et surtout un attentat aux valeurs 
fondamentales de la société civilisée et une infamie assénée à la 
République et ses Institutions:
- à tous les martyrs de la liberté qui ont payé de leur vie la 
défense des personnes et des biens et des valeurs 
fondamentales et universelles de la République.

- à tous ceux qui dans l'exercice de leurs fonctions, au nom du 
devoir de servir, exposeraient leurs vies, sans hésitation, pour la 
défense de ces mêmes valeurs

- à tous les hommes ou femmes de bonne volonté, citoyens 
anonymes, élevés sur la foi en une société pacifiée par 
l'avènement de la République, la crainte des lois et l'indéfectibilité 
de l'Etat, de la Justice et des Institutions en Démocratie.

J'étais, longtemps avant le WTC l'autre "point zéro" de la planète 
qui a subit les premières vagues d'attaque contre les institutions 
de la République, la liberté et les droits de l'homme … en France !

Il y a eu trois autres attaques avec la même détermination, 
diabolique et suicidaire, de stopper l'action publique 
régulièrement mise en mouvement !

J'ai fait face à l'adversité en mettant en accusation 15 magistrats, 
saisis par la foudre de l'action publique en colère, 
nominativement impliqués, des deux juridictions de Lyon tout rôle 
et rang confondus pour abus d'autorité aggravé et trafic 
d'influence aggravé. 

Une fois que vous avez pris la mesure de l'attaque contre les 
valeurs universelles de la liberté et la justice en démocratie en 
France… et assimilé la grandeur de la querelle qui m'anime … 
Votre réaction sera vivement souhaitée et sollicitée !

Je recevrai vos contributions morales et financières comme une 
juste consolation pour le grand préjudice moral que je subis dans 
l'attente de la réparation de la faute lourde par la justice et l'Etat.

Souvenez-vous que la paix civile fut conquise au prix de feu, de 
sang et de sacrifices… avec pour objectif le règne absolu et 
égalitaire de la loi.

Imaginez les victimes du 11 septembre 2001 dans un monde 
sans liberté, sans justice et sans démocratie…

Imaginez tous les sacrifices de tous les combattants de la liberté, 
depuis deux siècles et plus, laissés pour compte et discrédités en 
une seule journée d'attaques perpétrées par les forces 
diaboliques de l'arbitraire et de l'obscurantisme dans le pays qui a 
donné naissance au reigne de la loi, l'avènement de la 
République et les droits de l'homme.

Une nouvelle ère a commencé où le grand pays que sont les 
Etats Unis vont guider et pour longtemps l'impulsion de l'alerte et 
de la réaction pour perpétuer la liberté et la justice en 
démocraties. C'est aussi votre combat et le combat de tous les 
hommes libres.

Merci au président des Etats Unis pour son leadership, l'immense 
puissance de son pays et sa sérénité.
Merci à tous d'avoir lu et compris ce message. 
Merci pour vos réactions et vos contributions.
==========================
Ces contributions sont souhaitées à la hauteur de 500 $ ou euros 
et plus pour tous les représentants élus des peuples, sénateurs et 
députés, quelque soit leur pays et quelque soit le moyen utilisé 
pour les alerter des attaques contre la démocratie et de la colère 
de l'action Publique en mouvement : "ma tristesse s'est muée en 
colère et la colère en résolution "!
(ma conviction est que si de tels actes ont pu se produire c'est à 
cause d'un climat de permissivité qui a pu s'installer par l'absence 
du contrôle de l'exécutif par le pouvoir législatif…).
=======
vous pouvez verser directement vos contributions financières sur 
le compte : 
RIP  RELEVE D'IDENTITE BANCAIRE
20041   01007   1112632 F038  69   
IBAN IDENTIFIANT INTERNATIONAL
FR  53  20041  01007  1112632 F 038  69
Ou envoyer un mandat cash à mon nom et à mon adresse.
================================ 
Les contributions seront libres et bienvenues de la part de tout 
autre citoyen sensible à l'idée de vivre dans une société pacifiée 
par la crainte des lois et la crédibilité des institutions 
démocratiques.
============

Mon objectif est de réunir 10 000 réactions à 100 $ ou euros 
chacune : vous pouvez m'aider à atteindre ce but.
Je serai, à coup sûr, un homme riche! 
Mais je ne recouvrerai la paix intérieure avant que justice soit 
faite! 
'J'ai un rêve"! La justice sera faite !

============
Le site où est publié l'ensemble du dossier est en français, vous 
pouvez vous aider pour la traduction par un moteur de traduction 
sur internet.
http://haibi.free.fr
============
Cette mailing liste, non exhaustive, est composée de 30 000 
emails :
des représentants élus, les représentants de l'Etat,  hauts 
fonctionnaires, magistrats, avocats, journalistes, chefs 
d'entreprise, président ou membre d'association, profession 
libérale ou tout autre simple citoyen intéressé par la vie sociale, 
administrative et judiciaire.
=======================
Vous pourrez discuter en circuit interne non publié sur le net en 
vous abonnant au groupe créé pour cet objet "Il n'y a pas 
d'alternative à la justice en république en france"
Coordonnées du groupe :
Email du groupe : lec...@sm... 
Email du gestionnaire : 
lec...@sm... 
Pour devenir membre : 
lec...@sm... 
Pour ne plus être membre : 
lec...@sm... 
Accueil du groupe : 
http://smartgroups.wanadoo.fr/groups/lecitoyen.laloi.larepubliqu
e 
======================
Si vous ne vous sentez pas concerné, vous pouvez demander à 
ce que votre email soit effacer en exprimant votre volonté à 
l'adresse email : ha...@fr...

Merci encore de participer à l'alerte et au suivi de l'action 
publique en mouvement, et au soutien moral et financier de la 
partie civile par l'action.
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================================
===================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
===================================
ceci n'est pas un spam
vous pourrez en recevoir une version en anglais
Merci !
NEVER SEND SPAM. IT IS BAD.

Re: [Hamlib-developer] Looking for apps using hamlib

[<ro...@14...>]

Hello,

On 4 Jan 2002, Alexandru Csete wrote:

> Then there is Kontakt using Qt2/KDE2, but I don't know about it's
> status.

Status is unchanged since the end of my internship one month ago.
Girlfriend and LinKT ( http://1409.org/projects/linkt/ ) are higher
priority right now...

You can select a rig provided by hamlib from a tree view, then set freq
and mode values.

I have had problems generating the Makefiles outside of KDevelop. AND,
inside KDevelop, it always sets --fno-exceptions, which won't let it
compile. I have no idea where to change these things properly, so it's
always ended in a Makefile.am hack.

Homepage is http://kontakt.sf.net.

73, Robert
-- 
Robert Steinhaeusser, DL1NC / N9KBK                        dl...@da...
http://1409.org                                 ro...@st...

[Hamlib-developer] Re: Kenwood TH-D7A(G) patch

[Francois R. <fgr...@su...>]

Hello Stephane,

> Great! I love patches! And yours is now commited to cvs.
> You're right, the TH-D7 is using a protocol similar to the Kenwood table
> top rigs, but with some changes. It turns out I own a TH-F7E, and even
> though I don't have the protocol specs, it looks like the commands are the
> same as the TH-D7, hence the kenwood/th.c file.

Here is some more. ;-) Should I add the commands to the th.c or thd7.c
file?   Do you know how similar the TH-F7E/TH-D7 are?
 
> > It seems that some duplication can be avoided if the
> > kenwood_transaction is responsible for adding the terminating
> > character (either, ';' for older radios and <CR> for TH)
> > based on the radio being used.
> 
> sure! Actualy, I don't like at all kenwood_transaction().
> So feel free to crush it and rewrite it correctly, in the light of the
> different Kenwood protocol variants. If not sure how to do it, we can
> discuss about it. That'd be neat if kenwood_transaction could handle
> rigs error codes without having to pass an ack_buf. Thus when no response
> is expected, ack_buf = NULL would be better than ack_len = 0.

I agree. I have an idea or two.  I will start looking into a better 
transaction routine. 

I aspect that still bother me is how async messages should be handled.
How does the callback infrastructure of hamlib work? I don't quite
follow the Icom implementation.

> > Also, it seems that the *data_len parameter is not returning
> > any value.  I always get zero length, but the buffer contain
> > the correct string.
> 
> okay, time to take a closer look.

Almost all the Kenwood command are string based. Thus we can work
with strings instead of buffer/length.  See the read_string
function I added with the Easycomm patch. It is basically a 
replacement for the port_transaction function.

btw. Why the difference between read_block and fread_block?

Cheers
  Francois Retief

--
---------------------------------------------------------------------
Electronic Systems Laboratory (ESL)
University of Stellenbosch
South Africa
Tel. +27-21-808-4472

** Developers of the SUNSAT micro-satellite **
http://sunsat.ee.sun.ac.za

Re: [Hamlib-developer] Looking for apps using hamlib

[John C. <chu...@a5...>]

Thanks,  I'll take a look.

BTW, if I can help in any way (testing, coding, etc), please let me know.

Regards,

John

----- Original Message ----- 
From: "Alexandru Csete" <al...@if...>
To: "John Chubick" <chu...@a5...>
Cc: "Hamlib Developers" <ham...@li...>
Sent: Friday, January 04, 2002 8:44 AM
Subject: Re: [Hamlib-developer] Looking for apps using hamlib


> We are working on a GUI to hamlib but it is in very early stage. As of
> writing it can turn the power ON/OFF, select the mode, filter and AGC.
> It has only been tested with the "dummy" backend.
> You can get the source code from
> http://sourceforge.net/projects/groundstation but you will have to use
> CVS with module name grig (there is also another module called fms which
> is a more or less complete GUI but it uses the linradio library and
> needs to be ported to hamlib).
> All of the code is written in plain C and uses the Gtk+/Gnome widgets.
> 
> Then there is Kontakt using Qt2/KDE2, but I don't know about it's
> status.
> 
> 
> Alex, OZ9AEC
> 
> 
> On Fri, 2002-01-04 at 14:26, John Chubick wrote:
> > I've been reading up on hamlib as I've been looking for a radio
> > control program to run on my Linux machine.  I have a development
> > background (mainly Java and some C and VB) but I don't know C++ and
> > I've never developed for Linux.  Before I tackle trying to write 
> > something from scratch using the hamlib libraries I was looking for
> > something already written for my Kenwood TS-570.  Can anyone point me
> > in the right direction?
> > 
> > Thanks,
> > 
> > John Chubick - KB9LNS
> -- 
> ------------------------------------------------------------------------
>  Alexandru Csete <al...@if...>       Office : 520-332
>  Institute of Physics and Astronomy      Web    : www.ifa.au.dk/~alexc
>  Ny Munkegade, Building 520              Phone  : (+45) 8942 3622
>  University of Aarhus                    Cell.  : (+45) 2962 4317
>  Denmark                                 HF-CW  : 7010kHz +/- QRM
> ------------------------------------------------------------------------
> 
> 
> 

Re: [Hamlib-developer] Looking for apps using hamlib

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

We are working on a GUI to hamlib but it is in very early stage. As of
writing it can turn the power ON/OFF, select the mode, filter and AGC.
It has only been tested with the "dummy" backend.
You can get the source code from
http://sourceforge.net/projects/groundstation but you will have to use
CVS with module name grig (there is also another module called fms which
is a more or less complete GUI but it uses the linradio library and
needs to be ported to hamlib).
All of the code is written in plain C and uses the Gtk+/Gnome widgets.

Then there is Kontakt using Qt2/KDE2, but I don't know about it's
status.


Alex, OZ9AEC


On Fri, 2002-01-04 at 14:26, John Chubick wrote:
> I've been reading up on hamlib as I've been looking for a radio
> control program to run on my Linux machine.  I have a development
> background (mainly Java and some C and VB) but I don't know C++ and
> I've never developed for Linux.  Before I tackle trying to write 
> something from scratch using the hamlib libraries I was looking for
> something already written for my Kenwood TS-570.  Can anyone point me
> in the right direction?
> 
> Thanks,
> 
> John Chubick - KB9LNS
-- 
------------------------------------------------------------------------
 Alexandru Csete <al...@if...>       Office : 520-332
 Institute of Physics and Astronomy      Web    : www.ifa.au.dk/~alexc
 Ny Munkegade, Building 520              Phone  : (+45) 8942 3622
 University of Aarhus                    Cell.  : (+45) 2962 4317
 Denmark                                 HF-CW  : 7010kHz +/- QRM
------------------------------------------------------------------------

[Hamlib-developer] Looking for apps using hamlib

[John C. <chu...@a5...>]

I've been reading up on hamlib as I've been looking for a radio control =
program to run on my Linux machine.  I have a development background =
(mainly Java and some C and VB) but I don't know C++ and I've never =
developed for Linux.  Before I tackle trying to write something from =
scratch using the hamlib libraries I was looking for something already =
written for my Kenwood TS-570.  Can anyone point me in the right =
direction?

Thanks,

John Chubick - KB9LNS

[Hamlib-developer] libhamlibtcl.so

[Ellis W. <k0...@ya...>]

Greetings I was recently delighted to discover
hamlib. Bravo!

Following the INSTALL instructions,
I have compiled the libraries on a Linux system
and succesfully run the test programs against
my ICOM706MKIIG.


I am interested in using the libhamlibtcl.so
to write an interface with Tk. tclsh
is unable to load libhamlibtcl.so complaining 
of an unknown symbol "hamlib_version". It
would appear that it's not finding or linking
to libhamlib.so.


Ideas?

Thanks,


Ellis Workman, K0ELW


=====
Ellis Workman KØELW  
Grid EN33sx Olmsted County
Rochester, MN

__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com

[Hamlib-developer] Tentec Pegasus application

[James C. <n3...@n3...>]

I'm not a developer (but am no Linux newbie either). I'm an amateur who =
has been using Linux since Slackware v1.0, and who now has a Pegasus I =
would like to be able to use while running Linux (without resorting to =
Wine). Has anyone here on the list got a Pegasus rig control =
implementation that needs hammering? If so, I'd love to volunteer.

73,

Jim
N3TKD/5

Re: [Hamlib-developer] Re: Hamlib and rotators

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

On Mon, Dec 31, 2001, Francois Retief wrote:
> The spec was invented by the author of WiSP. WiSP is a PacSat ground 
> station program (for Windows).   It includes rotator control, radio 
> dopler control and PacSat mailbox functions amongst others.  That is 
> why there is both radio and rotator stuff.

This is going to be troublesome for Hamlib, because the rotator frontend
has strictly no idea of operating frequency. Can we just pass null freq?

> > Some examples of the EASYCOMM II protocol would help also.
> > Maybe you are the right person to implement these backends, and test it
> > while you're at it.
> 
> I will check-out a fresh copy of the CVS and start hacking.  
> Should I create a new directory for rotor backends?

yep. The rule is to have the backend have the same name as the directory
it lives in. So if EASYCOMM I and EASYCOMM II are to be in the same
backend, maybe 'easycomm' could be a good candidate.
There's already a 'dummy' rotator backend, so rotctl has something to
chew.

> I have a problem with the current CVS code.  The test programs in the
> hamlib CVS works fine.  But when I try to link it to a test program 
> (external to hamlib), it complain about:
> /usr/local/lib/libhamlib.so: undefined reference to
> 'lt_preloaded_symbols'

I knew it would happen some day. This lt_preloaded_symbols is useful for
statically linked in hamlib backends. I try to find a seamless solution
that would work shared and static, with easy maintenance.
So let's disable it (comment out LTDL_SET_PRELOADED_SYMBOLS in
src/register.c). cvs rep updated.

> I get the same problem with the AC_LIB_HAMLIB macro.  The problem 
> started after the hamlib-1.1.2 release.

ahem, the AC_LIB_HAMLIB from hamlib.m4 has never been tested, and I'm
quite surprised you managed to run aclocal against it without troubles.
Anyway, lt_preloaded_symbols and AC_LIB_HAMLIB are to be fixed.

Cheers,
Stephane

Re: [Hamlib-developer] Kenwood TH-D7A(G) patch

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

On Mon, Dec 31, 2001, Francois Retief wrote:
> I borrowed a Kenwood TH-D7A(G) to test with Hamlib. Here is a
> patch with that works with that radio.  It seems the TH-D7
> is not using the same protocol as other radios, 
> ie. FQ<CR> compared to FA; for other radios.

Great! I love patches! And yours is now commited to cvs.
You're right, the TH-D7 is using a protocol similar to the Kenwood table
top rigs, but with some changes. It turns out I own a TH-F7E, and even
though I don't have the protocol specs, it looks like the commands are the
same as the TH-D7, hence the kenwood/th.c file.

> It seems that some duplication can be avoided if the
> kenwood_transaction is responsible for adding the terminating
> character (either, ';' for older radios and <CR> for TH) 
> based on the radio being used.

sure! Actualy, I don't like at all kenwood_transaction().
So feel free to crush it and rewrite it correctly, in the light of the
different Kenwood protocol variants. If not sure how to do it, we can
discuss about it. That'd be neat if kenwood_transaction could handle
rigs error codes without having to pass an ack_buf. Thus when no response
is expected, ack_buf = NULL would be better than ack_len = 0.

> Also, it seems that the *data_len parameter is not returning
> any value.  I always get zero length, but the buffer contain 
> the correct string.

okay, time to take a closer look.


Thank you very much for the patch and the help

Cheers,
Stephane

[Hamlib-developer] Re: rigctl fails

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

Joop Stakenborg wrote:

> aba@pc3:~$ rigctl -vvvvv -m 210
> rig:rig_init called 
> rig: loading backend kenwood
> rig: dlsym(initrigs_kenwood) failed (/usr/local/lib/libhamlib-1.1.3-pre2-pa4tu.so.0: undefined symbol: initrigs_kenwood)
> Unknown rig num 210, or initialization error.
> Please check with --list option.
> 
> initrigs_kenwood is in libhamlib-kenwood.so and not in libhamlib-1.1.3-pre2-pa4tu.so.0:

yep, the traces are not that explicit maybe.
Actualy, rigctl tries to open libhamlib-kenwood.so, which fails because 
it only search for in /lib and /usr/lib. At least, this is what told me
"strace rigctl -vvvv -m210 2> syscall_trace" on my system.
So, rigctl falls back to static backend symbols in libhamlib, and fails
because there aren't.

> aba@pc3:~$ nm /usr/local/lib/libhamlib-kenwood.so|grep init
> 000012e4 ? _init
> 00001538 t init_dummy
> 00003154 t init_dummy
> 00002c20 T initrigs_kenwood
> 
> but rigctl is only linked with libhamlib-1.1.3-pre2-pa4tu.so.0:
> 
> aba@pc3:~$ ldd /usr/local/bin/rigctl 
>         libhamlib-1.1.3-pre2-pa4tu.so.0 => /usr/local/lib/libhamlib-1.1.3-pre2-pa4tu.so.0 (0x40016000)
>         libdl.so.2 => /lib/libdl.so.2 (0x40032000)
>         libm.so.6 => /lib/libm.so.6 (0x40036000)
>         libc.so.6 => /lib/libc.so.6 (0x40059000)
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
> 
> Should you not link rigctl with all the libhamlib-<rig>.so files?

No, it would be too painful, and the existence of new backend plugin
should be hidden to rigctl.

Thanks for the traces!
Solution cont'd in next mail.

Stephane

Re: [Hamlib-developer] TS-870: test 2

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

On Tue, Jan 01, 2002, Joop Stakenborg wrote:
> A happy new year to y'all and here is the result for the second kenwood
> TS-870 test, from the snapshot that Stephane has provided, version number
> is 1.1.3-pre2-pa4tu.
> 
> Some remarks:
> 
> Rigctl has to link with all the separate libhamlib-<rig>.so files,
> so I had to change tests/Makefile.am to something like this:

It's a solution, not the simplest. The best solution would be to have
libtool/automake to be fixed so it searches for modules where there were
installed (this seems to be broken in libtool-1.4.2a).
Hamlib can also take care of this. In the meantime something is
devised, the workaround I would recommand is to set LD_LIBRARY_PATH
to the path where your backend modules are installed:

	export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/lib"

> Secondly, make install fails in the include directory.
> include/Makefile.am has lines like:
> 
> includedir = @includedir@/hamlib
> include_HEADERS = hamlib/rig.h hamlib/riglist.h hamlib/rig_dll.h \
>                 hamlib/rotator.h hamlib/rotlist.h hamlib/rigclass.h
> 
> which causes /usr/local/include/hamlib to be created (correct) and
> header files want to go into /usr/local/include/hamlib/hamlib,
> which fails. The fix is trivial I guess.

Huh!? can you send me some traces and also your autoconf/automake version
numbers? I don't have any header install problems here with
autoconf-2.52-4 and automake-1.5-1.1 (debian woody).

> Now for the good news (tests were done with rigctl):
> 
> set_vfo/get_vfo work! I can use commands like: V VFOA, V VFOB and V MEM.
> set_freq/get_freq work!
> set_mode works: commands like M CW, M USB, etc. work!

That's great news!

> get_mode fails to return the correct answer, although the returned
> strings from the rig are OK. Here is a cut&paste from the session, with
> mode set to CW:
> 
> kenwood_get_mode: unsupported mode 77
> get_mode: error = Invalid parameter
> 
> In fact, every string returned from the rig seems to be right,
> but the answer is still the same: kenwood_get_mode: unsupported mode 77.

77 is the ASCII code for 'M'. So you guessed already what was wrong.
Since I never ever played with the Kenwood protocol, I thought the mode
was returned without the 'MD' prefix. This is now fixed in the cvs rep.

> Thanks for your effort Stephane. I hope this helps.

oh yes, this helps a lot! Thanks!

> I will do some more functionality tests with other commands later
> this week.

Functions and levels can be interresting. Please note the complete
protocol is not implemented yet, and memory handling functions may require 
some work on the API side to cover most needs. Feel free to express your
wishes, comments, etc.


Happy and peaceful new year to every one!

Cheers,
Stephane F8CFE

[Hamlib-developer] TS-870: test 2

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

A happy new year to y'all and here is the result for the second kenwood
TS-870 test, from the snapshot that Stephane has provided, version number
is 1.1.3-pre2-pa4tu.

Some remarks:

Rigctl has to link with all the separate libhamlib-<rig>.so files,
so I had to change tests/Makefile.am to something like this:

# all the programs need this
LDADD = ../src/libhamlib.la \
        ../kenwood/libhamlib-kenwood.la \
        ../dummy/libhamlib-dummy.la
DEPENDENCIES = ../src/libhamlib.la \
        ../kenwood/libhamlib-kenwood.la
        ../dummy/libhamlib-dummy.la

Secondly, make install fails in the include directory.
include/Makefile.am has lines like:

includedir = @includedir@/hamlib
include_HEADERS = hamlib/rig.h hamlib/riglist.h hamlib/rig_dll.h \
                hamlib/rotator.h hamlib/rotlist.h hamlib/rigclass.h

which causes /usr/local/include/hamlib to be created (correct) and
header files want to go into /usr/local/include/hamlib/hamlib,
which fails. The fix is trivial I guess.

Now for the good news (tests were done with rigctl):

set_vfo/get_vfo work! I can use commands like: V VFOA, V VFOB and V MEM.
set_freq/get_freq work!
set_mode works: commands like M CW, M USB, etc. work!

get_mode fails to return the correct answer, although the returned
strings from the rig are OK. Here is a cut&paste from the session, with
mode set to CW:

aba@pc3:~/tmp$ rigctl -vvvvv -m 210
rig:rig_init called 
rig: loading backend kenwood
kenwood: _init called
rig_register (203)
rig_register (204)
rig_register (216)
rig_register (210)
rig_register (214)
rig_register (217)
rig_register (220)
rig:rig_open called 
TX 3 bytes
0000     46 52 3b       FR;
RX 1 bytes
0000     46     F
RX 1 bytes
0000     52     R
RX 1 bytes
0000     30     0
RX 1 bytes
0000     3b     ;
Opened rig model 210, 'TS-870S'

Rig command: m
TX 3 bytes
0000     4d 44 3b       MD;
RX 1 bytes
0000     4d     M
RX 1 bytes
0000     44     D
RX 1 bytes
0000     33     3
RX 1 bytes
0000     3b     ;
kenwood_get_mode: unsupported mode 77
get_mode: error = Invalid parameter

In fact, every string returned from the rig seems to be right,
but the answer is still the same: kenwood_get_mode: unsupported mode 77.

Thanks for your effort Stephane. I hope this helps.
I will do some more functionality tests with other commands later
this week.

Regards,

Joop PA4TU

[Hamlib-developer] Re: Hamlib and rotators

[Francois R. <fgr...@su...>]

Hello Stephane,

>
> Hmm, the protocol looks simple, but I don't understand why the hell there
> are frequencies and modes to be specified when controlling the rotator.
> Do you have a clue?

The spec was invented by the author of WiSP. WiSP is a PacSat ground 
station program (for Windows).   It includes rotator control, radio 
dopler control and PacSat mailbox functions amongst others.  That is 
why there is both radio and rotator stuff.
 
> Some examples of the EASYCOMM II protocol would help also.
> Maybe you are the right person to implement these backends, and test it
> while you're at it.

I will check-out a fresh copy of the CVS and start hacking.  
Should I create a new directory for rotor backends?

> > The basic capabilities of a rotator will be:
> >
> > Movement range and mode:  Minimum and maximum values of the two axis,
> >       and also where the turn-around point is.
> >         (0-180, 0-360, 180-0-180 or 360-0-360, etc.)
> 
> Hmm, I'm sorry, I don't understand why we need a turn-around point.
> Let's say we have min_elevation/max_el and min_az/max_az, all
> being angles relative to horizon / north. Shouldn't it be enough?
> Or did I miss something?

On second thought, the min/max should be enough. Let's keep it simple 
for a start.

> Another question. If I'm not mistaken, there are rotator controllers and
> rotators being controlled. And a given rotator model can be controlled by
> different models of controllers. So, do you think Hamlib should have a
> database of rotator capabilities on top of the backends (which are for
> controllers) ?

Hmm, not sure, will think about it.  Will get back to you on this one.

> exactly! I've done some work on the rpcrig. Works better, still not
> complete (esp. caps retrieval). Right now, I'm testing "rpc.rigd -vvv"
> setup for use with dummy backend, and "rigctl -vvvv -m  1901 -r localhost"
> in another window.
> Seems okay, please let me know how it goes on your side.

As soon as I looked at the rotator backend stuff, I will check
the RPC.


I have a problem with the current CVS code.  The test programs in the
hamlib CVS works fine.  But when I try to link it to a test program 
(external to hamlib), it complain about:
/usr/local/lib/libhamlib.so: undefined reference to
'lt_preloaded_symbols'

I get the same problem with the AC_LIB_HAMLIB macro.  The problem 
started after the hamlib-1.1.2 release.


Cheers
  Francois Retief

--
---------------------------------------------------------------------
Electronic Systems Laboratory (ESL)
University of Stellenbosch
South Africa
Tel. +27-21-808-4472

** Developers of the SUNSAT micro-satellite **
http://sunsat.ee.sun.ac.za

[Hamlib-developer] Kenwood TH-D7A(G) patch

[Francois R. <fgr...@su...>]

Hello Stephane,

I borrowed a Kenwood TH-D7A(G) to test with Hamlib. Here is a
patch with that works with that radio.  It seems the TH-D7
is not using the same protocol as other radios, 
ie. FQ<CR> compared to FA; for other radios.

It seems that some duplication can be avoided if the
kenwood_transaction is responsible for adding the terminating
character (either, ';' for older radios and <CR> for TH) 
based on the radio being used.

Also, it seems that the *data_len parameter is not returning
any value.  I always get zero length, but the buffer contain 
the correct string.

Hope it helps.

Cheers
  Francois Retief

--
---------------------------------------------------------------------
Electronic Systems Laboratory (ESL)
University of Stellenbosch
South Africa
Tel. +27-21-808-4472

** Developers of the SUNSAT micro-satellite **
http://sunsat.ee.sun.ac.za

[Hamlib-developer] Hamlib and rotators

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

On Sat, Dec 22, 2001, Francois Retief wrote:
> The Easycom spec can be found at:
> ftp://ftp.amsat.org/amsat/software/win32/wisp/easycomm.txt

Hmm, the protocol looks simple, but I don't understand why the hell there
are frequencies and modes to be specified when controlling the rotator.
Do you have a clue?

Some examples of the EASYCOMM II protocol would help also.
Maybe you are the right person to implement these backends, and test it
while you're at it.

> For a start the basic functions we need to control a rotator is:
> 
> rot_set_position  -  Set the azimuth & elevation position.
> rot_get_position  -  Get the current azimuth & elevation position.
> rot_stop	  -  Stop rotator movement. (either in both axis 
>                      or only one)
> rot_move          -  Move rotator in a spesified direction 
>                      (optional: speed of movement)
> rot_reset	  -  (optional) Reset the rotator before use. 
>                      [warm-up motors, self-calibration, etc.]
> rot_park          -  (optional) Park rotator in safe position after use.

Fine. Work on going, at least on the frontend side (cf. latest cvs
commits)

> The basic capabilities of a rotator will be:
> 
> Movement range and mode:  Minimum and maximum values of the two axis,
> 	and also where the turn-around point is. 
>         (0-180, 0-360, 180-0-180 or 360-0-360, etc.)

Hmm, I'm sorry, I don't understand why we need a turn-around point.
Let's say we have min_elevation/max_el and min_az/max_az, all
being angles relative to horizon / north. Shouldn't it be enough?
Or did I miss something?

Another question. If I'm not mistaken, there are rotator controllers and
rotators being controlled. And a given rotator model can be controlled by
different models of controllers. So, do you think Hamlib should have a
database of rotator capabilities on top of the backends (which are for 
controllers) ?

> I have looked at the RPC stuff.  At the moment the server that it 
> is connecting to, is hard coded.  How would one make the server 
> address and port configurable?  
> 
> Would the 'rig_set_conf' function be a possible solution? 

exactly! I've done some work on the rpcrig. Works better, still not
complete (esp. caps retrieval). Right now, I'm testing "rpc.rigd -vvv"
setup for use with dummy backend, and "rigctl -vvvv -m  1901 -r localhost"
in another window. 
Seems okay, please let me know how it goes on your side.

Cheers 
and best wishes for the new coming year!

Stephane F8CFE

[Hamlib-developer] Re: IC-821H patch

[Francois R. <fgr...@su...>]

Hello Stephane,

Stephane Fillod  wrote:
> 
> ahem, just a sec...     alright, pass --serial-speed <bps>  argument.
> 
Thanks.

> What the Easycom protocol is like? Is it serial? Do you have already
> an library and an API ? Some code, online manual or even the header
> files would be a good starter to design the abstraction layer.
> I may have time to kick start a rotator frontend framework in the
> following days.

The Easycom spec can be found at:
ftp://ftp.amsat.org/amsat/software/win32/wisp/easycomm.txt

For a start the basic functions we need to control a rotator is:

rot_set_position  -  Set the azimuth & elevation position.
rot_get_position  -  Get the current azimuth & elevation position.
rot_stop	  -  Stop rotator movement. (either in both axis 
                     or only one)
rot_move          -  Move rotator in a spesified direction 
                     (optional: speed of movement)
rot_reset	  -  (optional) Reset the rotator before use. 
                     [warm-up motors, self-calibration, etc.]
rot_park          -  (optional) Park rotator in safe position after use.

The basic capabilities of a rotator will be:

Movement range and mode:  Minimum and maximum values of the two axis,
	and also where the turn-around point is. 
        (0-180, 0-360, 180-0-180 or 360-0-360, etc.)

> Hmm, couple of questions:
> * Is it possible to have VFO A on VHF and VFO B on VHF at the same time?
> * Is it possible to listen on VFO A while you transmit on VFO A (full
>   duplex)
> * Do you need both VFO when you want to operate in split mode?

I'll scan the section about the VFOs and send it to you.  
 
> ouch! Indeed, it's rather prehistoric CI-V. Anyway, could you send me
> by e-mail a scanned copy of the "COMMAND TABLE" of the IC-812H manual ?
> That'd help a lot since I don't have any documentation on this rig.

I'll scan the CI-V page. 
 
> > Hmm. The manual is very confusing. No banks. UHF has 80 channels
> > and so has VHF.  Thus UHF can be on channel 2 and VHF on channel 4.
> > But when the radio is in satellite mode, a channel consists of a
> > UHF/VHF frequency pair (UHF and VHF is always on the same channel)
> > I will test this later. :-)
> 
> Do you mean that in satellite mode, if UHF is be on channel 2, VHF
> would be on channel 2 also?

Yes.

I have looked at the RPC stuff.  At the moment the server that it 
is connecting to, is hard coded.  How would one make the server 
address and port configurable?  

Would the 'rig_set_conf' function be a possible solution? 

 
Cheers
  Francois Retief

--
---------------------------------------------------------------------
Electronic Systems Laboratory (ESL)
University of Stellenbosch
South Africa
Tel. +27-21-808-4472

** Developers of the SUNSAT micro-satellite **
http://sunsat.ee.sun.ac.za

Re: [Hamlib-developer] IC-821H patch

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

On Thu, Dec 20, 2001, Francois Retief wrote:
> I agree. The second rig is currently in use, tracking satellites.
> How do you change the baudrate with rigctl ?

ahem, just a sec...     alright, pass --serial-speed <bps>  argument.
 
> > > architecture.  My work have been primarily on antenna control
> > > (a 4.5m dish antenna and a Yaesu G-5400B rotator)
> > 
> > Ha! I'd love to integrate rotator control in Hamlib (even though I don't own
> > any yet). Are you interrested in ? I can help with the frontend work at least.
> > We would have to discuss the rotator capabilities too, and as for the radios,
> > there could be a RPC rotator backend.
> 
> Yes I am interested. This is where my interest is.  My antenna
> controller
> is based on the Easycom I protocol. Very simple. Good place to start.

What the Easycom protocol is like? Is it serial? Do you have already
an library and an API ? Some code, online manual or even the header
files would be a good starter to design the abstraction layer.
I may have time to kick start a rotator frontend framework in the
following days.

> > Anyway, thank you very much for the patch.
> > If you have a ham license on HF, we can arrange for a sked during vacations
> > if needed.
> 
> No HF here. Mostly UHF/VHF to passing satellites. ;-)

I never worked someone through a satellite, just heard R0MIR and decoding
telemetry from P3D when VHF was still alive. Should be cool though.

> ?-) Wel, I think it is 2 independent VFO's. As I said, I don't
> know to much about radio's. Quote from the manual:
> 
> "VFO description:
> The tranceiver has two VFOs for both bands, specially suited for 
> instant selection of 2 frequencies or split frequency operation.
> The VFOs are called VFO A and VFO B.  You can use a desired VFO
> to call up a frequency and operating mode for your operation."

Hmm, couple of questions:
* Is it possible to have VFO A on VHF and VFO B on VHF at the same time?
* Is it possible to listen on VFO A while you transmit on VFO A (full
  duplex)
* Do you need both VFO when you want to operate in split mode?

> There is no mention of the RIT and IFshift in the CIV command list.
> Only the basic stuff.  This radio is not particularly wel suited
> for software control.  The get frequency command (CIV Cn#3) is not
> supported. I will have to remove that feature from the caps.

ouch! Indeed, it's rather prehistoric CI-V. Anyway, could you send me
by e-mail a scanned copy of the "COMMAND TABLE" of the IC-812H manual ?
That'd help a lot since I don't have any documentation on this rig.

> > +chan_list: {
> > +                   {   1,  80, RIG_MTYPE_MEM,   0 },    /* FIXME: Each band
> > has 80 channels (2*80) */
> > 
> > is it like 2 banks?
> 
> Hmm. The manual is very confusing. No banks. UHF has 80 channels 
> and so has VHF.  Thus UHF can be on channel 2 and VHF on channel 4.
> But when the radio is in satellite mode, a channel consists of a 
> UHF/VHF frequency pair (UHF and VHF is always on the same channel)
> I will test this later. :-)

Do you mean that in satellite mode, if UHF is be on channel 2, VHF
would be on channel 2 also?

> > USA,Australia: region 2
> > Europe,Sweden: region 1 (Sweden version will need a rig_set_conf override)
> 
> I will fix the code when the patch is in the CVS.  

It's in!


Cheers,
Stephane