hamlib-developer — hamlib developers forum

[Hamlib-developer] We have a webpage!

[Nate B. <n0...@ne...>]

Well, the gods smiled and I'm now able to ssh into sourceforge and scp
files into the hamlib web directory.  So, I placed a modest effort of a
webpage onto the site and everything seems to be working (I had to
resolve a permissions problem on one file :).  Give it a go and let me
know any problems.  Now, that I have the procedure down, I can move
forward.

73, de Nate >>

-- 
 Wireless | Amateur Radio Station N0NB          | "None can love freedom
 Internet | n0...@ne...               | heartily, but good
 Location | Wichita, Kansas USA EM17hs          | men; the rest love not
   Wichita area exams; ham radio; Linux info @  | freedom, but license."
             http://www.qsl.net/n0nb/           | -- John Milton

[Hamlib-developer] Re: hamlib-1.1.0 release note

[Frank S. <vk...@ix...>]

Kai Altenfelder wrote:
> 
> Hello Frank,
> 
> On Mon, Jan 01, Frank Singleton wrote:
> 
> > Hi fellow linux fans,
> >
> > Not sure if you got htis or not, so here goes :-)
> >
> > 73's de vk3fcs/km5ws
> >
> >
> >
> > Hamlib 1.1.0 Project Release
> > ============================
> 
> I'd like to offer you SuSE's help for this project. Since a few months we
> have a program to offer university students Linux and Ham related projects
> for their study works or diploma thesises (sp?). If you have modular tasks
> within your project that are large enough to work 3 to 6 months on it I
> would be very interested.
> 
> Regards, Kai
> --
> Kai Altenfelder, SuSE GmbH, Schanzaeckerstr. 10, D-90443 Nuernberg
> Tel.: +49-911-74053-0, Fax:  +49-911-74053-489,  EMail: ka...@su...
> Ham: DL3LBA / DK0TUX / DN1TUX             PGP public key available

Hi hamlib developers (cc: Kai, Suse)

I have taken the liberty of forwading Kai's (Suse)
offer for assistance with our cool project.

I have done this for 2 reasons.

1. Its good to see someone else with some resources
   taking note of our COOL project.

2. I would like us to think about what we can request   
    from him (Suse), in the resource dept.


For hamlib, I see many things we can tackle, but
one that comes foremost is

GETTING AS MANY BACKENDS AS POSSIBLE WRITTEN !!	

Of course the API is a moving target as we firm
up the frontend API, but I would personally be
most happy if we can get MANY backend libs started.

ie: Freq,mode and vfo handling for 20-30 rigs
would be a good start.

Even if the API is only partially implemented, it is
great advertising to say we have (partial) support
of 20-30 types of ham radios.
	
There are of course many other issues, so I would
ask for you feedback.

Some that I see are.

1. Getting RIG control specs (eg: CAT documents etc) for
   all the rigs that we dont have covered yet. 


2.  Do we setup 1 or 2  accounts that allow Suse
    participants to  contribute. This would be better
    than me trying to manage 30 people as they come and 
    go from Suse's program.

3. Long term maintenance issues etc..


There are more I am sure, so please comment.

In closing, I think it would be generally beneficial
to our project getting this involvement.


Its 2am here, so time to close (snore...) :-o

-- 
Cheers / Frank 

73's de vk3fcs & km5ws

[Hamlib-developer] List of terms for hamlib

[Frank S. <vk...@ix...>]

Hi,

Lets start a list of terms etc , to save my fingers etc
in future correspondance, and to help newbies (aren't we
all)
 
This belongs in our documentation.

I will start...

FE - Front end 
	Refers to the frontend library. This is the library that 
	applications link against, if they require hamlib's 
	functionality.
BE - Back end 
	Backend libraries that handle rig-specific communication
	Not (normally) visible to applications.
RIG - Rig
	Refers to a piece of radio equipment that we can
	control via hamlib.
CAPS - Capabilities 
	Normally refers to radio equipments transmitting (TX)
	and receiving (RX) capabilities etc.

 etc..

-- 
Cheers / Frank 

73's de vk3fcs & km5ws

Re: [Hamlib-developer] Documentation plan

[Frank S. <vk...@ix...>]

Nate Bargmann wrote:

> I was trying to use ssh to log into the server to get access to
> uploading web pages.  Frank said something about needing to upload a
> public key to sourceforge, but I saw nothing mentioned in their
> quickstart docs.
> 

Take a look at 

http://sourceforge.net/docman/display_doc.php?docid=765&group_id=1

and 

http://sourceforge.net/docman/display_doc.php?docid=763&group_id=1


-- 
Cheers / Frank 

73's de vk3fcs & km5ws

Re: [Hamlib-developer] rig not supporting target VFO

[Frank S. <vk...@ix...>]

Stephane Fillod wrote:
> 
> Hi there,
> 
> Remember the issue with target VFO?

Yep,

> Backends will have to specify a new caps->targetable_vfo capability.
> Also, the current VFO of the rig will be stored in state.current_vfo.

Yes, I was doing this in the FT-xxx backends, but it does belong
up front .


> Then wrappers will look like the following:
> 
>     int rig_set_mode(RIG *rig, vfo_t vfo, rmode_t mode, pbwidth_t width)
>     {
>                 int retcode;
>                 vfo_t curr_vfo;
> 
>                 if (!rig || !rig->caps)
>                         return -RIG_EINVAL;
> 
>                 if (rig->caps->set_mode == NULL)
>                         return -RIG_ENAVAIL;
> 
>                 if (rig->caps->targetable_vfo || vfo == RIG_VFO_CURR ||
>                                                 vfo == rig->state.current_vfo)
>                         return rig->caps->set_mode(rig, vfo, mode, width);
>

>                 if (!rig->caps->set_vfo)
>                         return -RIG_ENTARGET;
>                 curr_vfo = rig->state.current_vfo;
>                 retcode = rig->caps->set_vfo(rig, vfo);
>                 if (retcode != RIG_OK)
>                                 return retcode;
> 
>                 retcode = rig->caps->set_mode(rig, vfo, mode, width);
>                 rig->caps->set_vfo(rig, curr_vfo);
>                 return retcode;
>     }
> 


Looks ok :)

TODO: Handle retcode properly when we fail. 
As 1 frontend call now maps to "n" backend (BE) calls, we need
to know which BE call fails.

> And so on. It's pretty much copy/paste for every Hamlib API calls that
> accept a VFO target.

Good.
> 
> Any comments? Maybe the code needs some :-)
> 

Well the hamlib project is bigger now, so there's hope :)

-- 
Cheers / Frank 

73's de vk3fcs & km5ws

Re: [Hamlib-developer] Documentation plan

[Nate B. <n0...@ne...>]

Hi Stephane!

On Wed, Jan 03, 2001 at 11:22:58PM +0100, Stephane Fillod wrote:
> 
>   The problem with API documentation is doco isn't updated when
>   code changes. That's why hamlib have hamlib-doc, a clone from kernel-doc,
>   which is actually a clone of gnome-doc, ...., a clone of java-doc, etc.
>   Ok, the fact is it's in doc/ directory, and API calls are documented
>   in the source file, mainly src/rig.c
>   Output can be done in html, text, anything (sgml/docbook), and man pages.
>   For the man pages, you will have to split them with:
> 
> 	./hamlib-doc -man ../src/rig.c  | ./split-man.pl man
> 
>   Even if you're not a core coder, you can still document the code,
>   ask question if something looks obscure to you (it might be obscure 
>   to someone else, and even to the coder who forgot his ugly tricks :).

Thanks for the tip.  I had glanced at hamlib-doc and now I'll give it a
go.  Right now I'm going to concentrate on the Web pages and I'll dig
deeper into the code afterward.

>   sounds a good plan to me. http://hamlib.sourceforge.net is as much needed
>   as code!
> 
>   Here's an ugly gizmos, that leave plenty of space for improvements,
>   I named rigmatrix. This is a combined list/dump program, that creates
>   a table of supported radios in HTML format, with dynamically generated
>   PNG pics for the rx/tx ranges (thanks to GD lib).
>   Not fancy stuff yet, but at least you got the meat :) 
>   If you want a different format and don't know how to change the code,
>   just ask me (a sample of the output you'd like will help).
>   You can check it out at the following URL:
>                 http://f4cfe.free.fr/ham/hamlib/rigmatrix.html

I looked at that page a week ago and it looks quite promising.  I did
glance at rigmatrix.c and will also investigate it further.

>   Something simple will do, to begin with. I like the style
>   of the Linux IEEE1394 project. The URL should be something like
>   http://ieee1394.sourceforge.net  (I'm offline line right now)

I found it at linux1394.sourceforge.net and it is a nice looking page.

>   Very import too, I think we need a logo. You know, like a small
>   picture to identify Hamlib. I have no good ideas yet. 
>   This can be a simple PNG showing a rig linked to a computer.
>   Or this can be a serial cable, ala Icom (however Hamlib is not
>   serial specific, it will run on network connections, and others)
>   This might be also a cute animal, like a kangaroo, recalling
>   a certain country (Did you remember the google.com during 
>   the Olympics games?). Do you have any other idea ?
>   Artists and gimp experts, this is time to show off!

Okay as I stated earlier, I'm no artist :-O  Volunteers??

>   nope, the ssh has a different name, something like ssh1.sourceforge.net
>   or shell1.sourceforge.net. Have a look at the SSH FAQ on sourceforge,
>   it's well explained.
>   Unless you have a good low-latency ISP service, I'd recommend you
>   to work offline and then use cvs update/commit or scp.

I was trying to use ssh to log into the server to get access to
uploading web pages.  Frank said something about needing to upload a
public key to sourceforge, but I saw nothing mentioned in their
quickstart docs.

>   Anyay, It's good to see the Hamlib team growing!
> 
> 
> Have fun,

If it helps ham radio and Linux, I'm pleased to be able to take part.

Also, I have uploaded a preliminary page for hamlib on my personal
webspace with my ISP.  You can look at it at:

http://www.networksplus.net/n0n/index.html

73, de Nate >>

-- 
 Wireless | Amateur Radio Station N0NB          | "None can love freedom
 Internet | n0...@ne...               | heartily, but good
 Location | Wichita, Kansas USA EM17hs          | men; the rest love not
   Wichita area exams; ham radio; Linux info @  | freedom, but license."
             http://www.qsl.net/n0nb/           | -- John Milton

Re: [Hamlib-developer] Documentation plan

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

On Wed, Jan 03, 2001, Nate Bargmann wrote:
> Okay, I've been going over things the past day or so and would like to
> get started by creating an introductory homepage for hamlib.  Some
> things I'd like to include are an overview of the library's purpose and
> its implementation.  After that is in place I'd like to expand that by

  Excellent idea!
  List of supported features (planed or future ones from the whish list)
  might have its place here. see PLAN file (from CVS, or tarball),
  which is rather coder scratch notes, almost human readable :)

> documenting the version 1.1.0 API.  As this becomes complete it should

  The problem with API documentation is doco isn't updated when
  code changes. That's why hamlib have hamlib-doc, a clone from kernel-do=
c,
  which is actually a clone of gnome-doc, ...., a clone of java-doc, etc.
  Ok, the fact is it's in doc/ directory, and API calls are documented
  in the source file, mainly src/rig.c
  Output can be done in html, text, anything (sgml/docbook), and man page=
s.
  For the man pages, you will have to split them with:

	./hamlib-doc -man ../src/rig.c  | ./split-man.pl man

  Even if you're not a core coder, you can still document the code,
  ask question if something looks obscure to you (it might be obscure=20
  to someone else, and even to the coder who forgot his ugly tricks :).

> probably be included in the next stable release.  Far into the future
> come things like HOWTO guides and radio command indexes and such.
>=20
  sounds a good plan to me. http://hamlib.sourceforge.net is as much need=
ed
  as code!

  Here's an ugly gizmos, that leave plenty of space for improvements,
  I named rigmatrix. This is a combined list/dump program, that creates
  a table of supported radios in HTML format, with dynamically generated
  PNG pics for the rx/tx ranges (thanks to GD lib).
  Not fancy stuff yet, but at least you got the meat :)=20
  If you want a different format and don't know how to change the code,
  just ask me (a sample of the output you'd like will help).
  You can check it out at the following URL:
                http://f4cfe.free.fr/ham/hamlib/rigmatrix.html


> Is there a preferred style for the web pages?  I don't plan on using
> frames or a lot of fancy gizmos.
>=20
  Something simple will do, to begin with. I like the style
  of the Linux IEEE1394 project. The URL should be something like
  http://ieee1394.sourceforge.net  (I'm offline line right now)

  Very import too, I think we need a logo. You know, like a small
  picture to identify Hamlib. I have no good ideas yet.=20
  This can be a simple PNG showing a rig linked to a computer.
  Or this can be a serial cable, ala Icom (however Hamlib is not
  serial specific, it will run on network connections, and others)
  This might be also a cute animal, like a kangaroo, recalling
  a certain country (Did you remember the google.com during=20
  the Olympics games?). Do you have any other idea ?
  Artists and gimp experts, this is time to show off!

> Finally, I installed the ssh (OpenSSH) 1.2.3-9.1 debian package
> yesterday, but cannot log into hamlib.sourceforge.net as the Sourceforg=
e
> documentation indicates.  Is this reserved for the project owner, or is
> there some other reason (Frank?).  Or will I need to contact Sourceforg=
e
> to get this resolved?
>=20
  nope, the ssh has a different name, something like ssh1.sourceforge.net
  or shell1.sourceforge.net. Have a look at the SSH FAQ on sourceforge,
  it's well explained.
  Unless you have a good low-latency ISP service, I'd recommend you
  to work offline and then use cvs update/commit or scp.

  Anyay, It's good to see the Hamlib team growing!


Have fun,

--=20
St=E9phane

[Hamlib-developer] preferences

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

Let's dust off the drawing board once again: this time, the preference file.

It's almost obvious, we need a ~/.hamlibrc or /etc/hamlibrc where
to store preferences on the connected rigs, like rig type, serial port
parameters, override values (rig modified),etc.
This way, it's easier for different user application to control rigs,
ie use Hamlib, off-the-shelf :)

First, we need to agree upon a preference file format.

* windows style:
  -------------

	; this is a comment
	[Hamlib]
	Backend Path=/usr/local/hamlib/lib

	[my rig name1]
	Serial Path=/dev/ttyS1

	[my rig name2]
	Serial speed=1200


* UNIX style:
  ----------

	# this is a comment
	backend-path=/usr/local/hamlib/lib

	rig "my rig name1"
	serial-path=/dev/ttyS1

	rig "my rig name2"
	serial-speed=1200


Then, we have to agree upon parameters name, at least upon which
that will be shared among backends in the frontend (eg. serial path, etc.).

You've notice the "my rig name1" and "my rig name2". Well, this is to
differentiate from different rigs attached to the system. Let's say
this is a logical name. From this point, I think that the rig_init
API call needs to be modified, as following:

    RIG* rig_init(rig_model_t rig_model, const char *logical_name);

where logical_name refers to a section in the preference file.
Eventually, the model_type can be defined in the hamlibrc file,
and DEFAULT value would be passed to rig_init.
A "logical_name" field would then be added in the rig->state struct.
The parsing of the hamlibrc file would be done by the first call
to rig_init(), all definitions stored in an internal table.
rig_init() would also override default capability with values from
preference file in the state struct (much internal API specification
to be done here).

Since this is a bit tricky with text files, saving preferencies from
Hamlib would not be available, at least from the beginning.


Eventhough Hamlib is coded in C, it's good to have as much as applicable
an OO approach. For instance, messing directly with rig->state.rig_path 
is not very clean, nor flexible for the future.
To my mind, some new API calls should be created:

	int rig_set_serial(RIG *rig, const char *path, int speed, etc.)
	int rig_set_network(RIG *rig, const char *host, int port, etc.)
	int rig_set_whatever(RIG *rig, const char *path, etc.)

The behaviour would be:
* use values from the function arguments
* if args are set to an undefined value, use the ones from hamlibrc
* if none defined in preferences, use capabilities default
* as a last ressort, if the variable has no default value in caps,
  then the function call should fail, returning appropriate error code.


Okay, this is only some thoughts to start up with. I don't mean to impose 
anything. Let me know what you think of it, stuff I omitted,
if you dream of preferences another way (I hear you gnome afficionados :) ...

Thanks for your inputs,

-- 
Stephane

[Hamlib-developer] Re: CVS tag [Re: Hamlib-1.1.0 released , last check]

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

On Thu, Dec 21, 2000, Frank Singleton wrote:
> 
> Also, will create a yaesu directory and move 
> my common yaesu stuff stuff in there. I am starting to get
> some good structure on common code now, want to leverage
> it as much as possible.
> 
> How does that affect the Makefile stuff (not being an

Looks like a new-backend-HOWTO is on preparation...

Allright, if you want to add the yeasu/ directory,
you'll have to go through the following steps:

* create the yeasu/ directory, if not done already...

* in configure.in, at the very bottom of the file,
  add yeasu/Makefile in the AC_OUTPUT directive so 
  your Makefile will be autogenerated (using automake)

* add the directory name in the Makefile.am to SUBDIRS,
  in the root directory of hamlib. This is needed by the master
  Makefile to know where to recurse into.

* create yeasu/Makefile.am, the easiest way is to clone it from
  an existing backend. Some explanations on the content may be
  interresting. Ask if you want some.

* running make from the hamlib root dir should rebuild configure
  and rerun it. If not, just issue "autoconf", followed by "./configure"
  and that should be it.

> Also, I think there is a missing dependancy on .h
> files. When I edit one , say ft747.h and re-run make
> from the top dir, then he does not see any changes.
> 
  well, it looks like no mkdep is ran automatically.
  you might end up adding it by hand in the Makefile.am,
  while I'm figuring out how to activate automatic dependencies
  (any help welcome!).

-- 
Stephane

Re: [Hamlib-developer] Documentation plan

[Frank S. <vk...@ix...>]

Nate Bargmann wrote:
> 
> Okay, I've been going over things the past day or so and would like to
> get started by creating an introductory homepage for hamlib.  Some
> things I'd like to include are an overview of the library's purpose and
> its implementation. 

Yes, lets tell people what its about, its goals, status, ambition,
world domination  ... :)

Our empty web space is not that eye-catching !!

A little diagram showing frontend API and the backends
would also help visualisation of the project.

Also some site navigation, status, FAQ, "latest news" areas 
etc would be good.

> After that is in place I'd like to expand that by
> documenting the version 1.1.0 API.  As this becomes complete it should
> probably be included in the next stable release.  Far into the future
> come things like HOWTO guides and radio command indexes and such.
> 

The frontend API has some markups to assist documentation.
Stephane, comments. Also the rig capabilities matrix would
be nice... :)

> Is there a preferred style for the web pages?  I don't plan on using
> frames or a lot of fancy gizmos.

Good, there are still a lot of us with low bandwidth 
connections (sigh..). Mostly I am not a frames fan,
although they occasionally provide some navigational 
use. I could live without them :^)

> 
> Finally, I installed the ssh (OpenSSH) 1.2.3-9.1 debian package
> yesterday, but cannot log into hamlib.sourceforge.net as the Sourceforge
> documentation indicates.  Is this reserved for the project owner, or is
> there some other reason (Frank?).  Or will I need to contact Sourceforge
> to get this resolved?
> 

Hmm, let me check, I just uploaded my pub ssh key and waited 24
hours, from memory...

I know there have been some problems with the sourceforge 
re-shuffle. eg: Our CVS commits are normally emailed our cvs-devel
list, but that stopped recently. I have a ticket open on it.


Welcome onboard Nate.

Cheers / Frank 

73's de vk3fcs & km5ws

[Hamlib-developer] rig not supporting target VFO

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

Hi there,

Remember the issue with target VFO?
Let's say the current VFO of the rig is VFO A. But for example, you want
to change the frequency of *VFO B*, while keeping VFO A active.
Some rigs can do that (Kenwoods, some Yeasus, etc.)
My concern here is for rigs that are not able to do that,
hence the following scenario:

	set_vfo VFO_B
	set_freq
	set_vfo VFO_A	/* or whatever it was */

In order to factorize some code, this could be done by the frontend.
I've coded it, but before commiting, I'd like to have your comments.

Backends will have to specify a new caps->targetable_vfo capability.
Also, the current VFO of the rig will be stored in state.current_vfo.
Then wrappers will look like the following:


    int rig_set_mode(RIG *rig, vfo_t vfo, rmode_t mode, pbwidth_t width)
    {
                int retcode;
                vfo_t curr_vfo;

                if (!rig || !rig->caps)
                        return -RIG_EINVAL;

                if (rig->caps->set_mode == NULL)
                        return -RIG_ENAVAIL;

                if (rig->caps->targetable_vfo || vfo == RIG_VFO_CURR ||
						vfo == rig->state.current_vfo)
                        return rig->caps->set_mode(rig, vfo, mode, width);

                if (!rig->caps->set_vfo)
                        return -RIG_ENTARGET;
                curr_vfo = rig->state.current_vfo;
                retcode = rig->caps->set_vfo(rig, vfo);
                if (retcode != RIG_OK)
                                return retcode;

                retcode = rig->caps->set_mode(rig, vfo, mode, width);
                rig->caps->set_vfo(rig, curr_vfo);
                return retcode;
    }


And so on. It's pretty much copy/paste for every Hamlib API calls that
accept a VFO target.

Any comments? Maybe the code needs some :-)

-- 
Stephane

[Hamlib-developer] Documentation plan

[Nate B. <n0...@ne...>]

Okay, I've been going over things the past day or so and would like to
get started by creating an introductory homepage for hamlib.  Some
things I'd like to include are an overview of the library's purpose and
its implementation.  After that is in place I'd like to expand that by
documenting the version 1.1.0 API.  As this becomes complete it should
probably be included in the next stable release.  Far into the future
come things like HOWTO guides and radio command indexes and such.

Is there a preferred style for the web pages?  I don't plan on using
frames or a lot of fancy gizmos.

Finally, I installed the ssh (OpenSSH) 1.2.3-9.1 debian package
yesterday, but cannot log into hamlib.sourceforge.net as the Sourceforge
documentation indicates.  Is this reserved for the project owner, or is
there some other reason (Frank?).  Or will I need to contact Sourceforge
to get this resolved?

73, de Nate >>

-- 
 Wireless | Amateur Radio Station N0NB          | "None can love freedom
 Internet | n0...@ne...               | heartily, but good
 Location | Wichita, Kansas USA EM17hs          | men; the rest love not
   Wichita area exams; ham radio; Linux info @  | freedom, but license."
             http://www.qsl.net/n0nb/           | -- John Milton

Re: [Hamlib-developer] Greetings!

[Nate B. <n0...@ne...>]

On Mon, Jan 01, 2001 at 09:24:54PM -0600, Frank Singleton wrote:
> 
> Documentation help always welcome. !! A web page for our site
> would be cool..

I noticed the project didn't have one, so I guess that's why I
volunteered.  The web pages could contain hamlib's API along with items
like rig capabilities along with command syntax for each rig so it would
be in one place.  They could also serve as a starting point for formal
documentation included in the library distribution.

> Good, I am rationalising the yeasu code at the moment, and
> it would be good to see the CAT docs etc.. 
> 
> You would be most welcome to join us. The fun part is to tweek
> some code, then make sure you can still talk to your rig :-)

Of course!

> I am moving yaesu stuff to table driven functionality.
> see ft747 and ft847 for examples. I am in transit with this
> code, but I am sure you get the idea :^)

I looked at both the 747 and 847.c files and it looks rather
straightforward(!) when comparing them to the CAT info I have.
Hopefully, I can begin to work on this for the '920 later in the week.

> CAT docs are needed, but the FIF-232 could be replaced with
> a cheaper kit based on max232 chip.
> 
> Normally this just converts between TTL levels and RS232
> levels.

I built one for a TS-850 I no longer have, but the rig acted flaky with
it, so I'm not sure if the problem was in the interface or the '850.

> 2 points.
> 
> 1. The API is WIP this why we need comments by
>    people other than the 2 current members. We should
>     have a standard API as a minimum and get it out there
>    in WIDE use. .... and ...
>    
> 2. Yep, some generic way of broadcasting "extra" capabilities and
>    using some enhancements is always possible.

I can always comment. :-O

> That why we want people on the list, to chew through these 
> ideas ..

ditto!

> Yep thats ok, I promise not to jump to v7.0 (hi hi)

Harr!  One thing, and I think this was in the archive, I think should be
followed is the Linux kernel example of an odd minor version number
indicating a development version as it has become common convention for
open source projects.

> Again, you would be most welcome, and the extra rigs we could
> test and develop against is most valuable in getting a wider
> audience for both hamlib development, and end user developers
> using hamlib to create cool stuff (see our wishlist).
> 
> So, just to clarify, I understand you  can help us with
> web and docs, THANKS. Are you willing to code up some backends
> for your rigs. I can provide some help if required.

Yes, I can pitch in.  Time is always a precious commodity, but I usually
have a few hours each evening available to do things.  I enjoy HTML and
CSS and prefer to write my pages from scratch conformant to the W3C HTML
4.01 Transitional DTD.

> You can use FT747 code as example, to map frontend
> API function calls onto backend rig specific CAT
> sequences. see yaesu.h and ft747.[ch]

I will definitely look those over.  I've looked at the '920 CAT commands
in the owner's manual, so this should be interesting.

> Can you join the sourceforge community, then I will add
> you to our project.

No problem.  I'll have to poke around there and see what needs to be
done.

73, de Nate >>

-- 
 Wireless | Amateur Radio Station N0NB          | "None can love freedom
 Internet | n0...@ne...               | heartily, but good
 Location | Wichita, Kansas USA EM17hs          | men; the rest love not
   Wichita area exams; ham radio; Linux info @  | freedom, but license."
             http://www.qsl.net/n0nb/           | -- John Milton

Re: [Hamlib-developer] Greetings!

[Frank S. <vk...@ix...>]

Nate Bargmann wrote:
> 
> Hello hamlib developers.
> 
> First off, I am very intrigued about this project as I believe it fills
> a need.  Second, I am a total novice at coding as I have a basic
> understanding of C, but have had no formal training.  So, I've been
> looking at the hamlib source code over the past week trying to figure it
> out (I have a long way to go!).

Still work in progress (WIP) but thats the fun part ...

> 
> With that in mind, I'd be willing to lend what help I can to
> documentation and such.  I've written a bit of HTML (link in my sig) and
> have been tinkering with other stuff from time to time.  Unfortunately,
> I'm no graphics designer, so I'm pretty much limited to text.
> 

Documentation help always welcome. !! A web page for our site
would be cool..

> As for being able to test things, I am running Debian 2.2r2 Linux and
> have access to the following radios:
> 
> FT-920
> FT-890
> FT-212
> FT-5100  (not sure if it supports CAT)
> 

Good, I am rationalising the yeasu code at the moment, and
it would be good to see the CAT docs etc.. 

You would be most welcome to join us. The fun part is to tweek
some code, then make sure you can still talk to your rig :-)

I am moving yaesu stuff to table driven functionality.
see ft747 and ft847 for examples. I am in transit with this
code, but I am sure you get the idea :^)

> I would have to procure an FIF-232 to test any but the '920.  Is CAT
> command documentation needed for any of these radios?

CAT docs are needed, but the FIF-232 could be replaced with
a cheaper kit based on max232 chip.

Normally this just converts between TTL levels and RS232
levels.

> 
> Finally, I had some thoughts on hmalib itself.
> 
> I read through the developer list archive and was able to track the
> recent changes to the API.  I realize hamlib's goal is to present a
> consistent API to a program no matter the radio it is talking to.
> However, with the myriad of rigs out there it certainly seems difficult
> to support every feature of these radios with (what seems to me at
> least) a restricted API.  

2 points.

1. The API is WIP this why we need comments by
   people other than the 2 current members. We should
    have a standard API as a minimum and get it out there
   in WIDE use. .... and ...
   
2. Yep, some generic way of broadcasting "extra" capabilities and
   using some enhancements is always possible.


Is there a possibility of providing a sort of
> "pass-through" function that would allow an application to access a
> specialized function of a given radio?  I suppose an application's
> author could always load a given rig's library directly, but that would
> be messy and outside the design of hamlib.  Just a thought I had.
> 

That why we want people on the list, to chew through these 
ideas ..

> I must admit that as a long time user of Free/open source software I was
> initially confused by its 1.1.0 ALPHA version, which, to me at least,
> seems a bit high for this stage of development.  Of course, the version
> number is simply a reference for the developer and user and can be
> anything (witness the shrinkwrap insanity over the past years) the
> developer chooses.  I mention this simply because it will likely get
> mentioned again by others. :-)
> 

Yep thats ok, I promise not to jump to v7.0 (hi hi)

> All in all, I am pleased this project exists.  Anything that helps
> introduce Linux to hams or make Linux more attractive is a plus in my
> books.
> 
> 73, de Nate >>

Again, you would be most welcome, and the extra rigs we could
test and develop against is most valuable in getting a wider
audience for both hamlib development, and end user developers
using hamlib to create cool stuff (see our wishlist).

So, just to clarify, I understand you  can help us with
web and docs, THANKS. Are you willing to code up some backends
for your rigs. I can provide some help if required.

You can use FT747 code as example, to map frontend
API function calls onto backend rig specific CAT
sequences. see yaesu.h and ft747.[ch]

Can you join the sourceforge community, then I will add
you to our project.

73's de vk3fcs/km5ws

[Hamlib-developer] Greetings!

[Nate B. <n0...@ne...>]

Hello hamlib developers.

First off, I am very intrigued about this project as I believe it fills
a need.  Second, I am a total novice at coding as I have a basic
understanding of C, but have had no formal training.  So, I've been
looking at the hamlib source code over the past week trying to figure it
out (I have a long way to go!).

With that in mind, I'd be willing to lend what help I can to
documentation and such.  I've written a bit of HTML (link in my sig) and
have been tinkering with other stuff from time to time.  Unfortunately,
I'm no graphics designer, so I'm pretty much limited to text.

As for being able to test things, I am running Debian 2.2r2 Linux and
have access to the following radios:

FT-920
FT-890
FT-212
FT-5100  (not sure if it supports CAT)

I would have to procure an FIF-232 to test any but the '920.  Is CAT
command documentation needed for any of these radios?

Finally, I had some thoughts on hmalib itself.

I read through the developer list archive and was able to track the
recent changes to the API.  I realize hamlib's goal is to present a
consistent API to a program no matter the radio it is talking to.
However, with the myriad of rigs out there it certainly seems difficult
to support every feature of these radios with (what seems to me at
least) a restricted API.  Is there a possibility of providing a sort of
"pass-through" function that would allow an application to access a
specialized function of a given radio?  I suppose an application's
author could always load a given rig's library directly, but that would
be messy and outside the design of hamlib.  Just a thought I had.

I must admit that as a long time user of Free/open source software I was
initially confused by its 1.1.0 ALPHA version, which, to me at least,
seems a bit high for this stage of development.  Of course, the version
number is simply a reference for the developer and user and can be
anything (witness the shrinkwrap insanity over the past years) the
developer chooses.  I mention this simply because it will likely get
mentioned again by others. :-)

All in all, I am pleased this project exists.  Anything that helps
introduce Linux to hams or make Linux more attractive is a plus in my
books.

73, de Nate >>

-- 
 Wireless | Amateur Radio Station N0NB          | "None can love freedom
 Internet | n0...@ne...               | heartily, but good
 Location | Wichita, Kansas USA EM17hs          | men; the rest love not
   Wichita area exams; ham radio; Linux info @  | freedom, but license."
             http://www.qsl.net/n0nb/           | -- John Milton

[Hamlib-developer] hamlib-1.1.0 release note

[Frank S. <vk...@ix...>]

Hi fellow linux fans,

Not sure if you got htis or not, so here goes :-)

73's de vk3fcs/km5ws



Hamlib 1.1.0 Project Release
============================

Introduction
------------

Application programmers: Do you dream for a common API to
control any type of HAM Radio equipment that has a control
port?

Are you waiting to build the next cool GUI program to
really drive all that HAM gear you or others have?

Well, this project is here to help you get there :-)

hamlib-1.1.0 finally released (alpha). The purpose of this project 
is to develop stable, flexible, shared libraries that enable 
quicker development of Amateur Radio Equipment Control 
Applications. It will (eventually) run on various flavors 
of Unix, Linux, and Windows. It is based on a shared library 
frontend abstraction layer/backend approach. 

Application programmers will see a common frontend (abstraction
layer) API, and backend shared libs can be loaded on demand when
an application wishes to control a certain radio type. Seeking 
contributor help for a really cool project. 

Although alpha code, proof of concept has been tested 
against FT747, FT847 and IC706 rigs. 

It has gone through a major rework since its inception and
testing on my poor old FT747 (smoke test :)

Where to find it
----------------

Here is the main page and links to CVS, major releases
and links to news groups.

See http://sourceforge.net/projects/hamlib 

for details. 

There exists a mailing list for developers at

 ham...@li...


Example code:
------------

This "C" code snippet sets any rig to 21,235.175 Mhz USB, 
Normal bandwidth.

/* 15m USB */

retcode = rig_set_freq(my_rig, RIG_VFO_CURR, 21235175); /* 15m  */
retcode = rig_set_mode(my_rig, RIG_VFO_CURR,
RIG_MODE_USB,RIG_PASSBAND_NORMAL);

see hamlib/tests/testrig.c for an example.


Help Wanted
-----------

Get on board and help us write the frontend and backend 
libs for all the rigs out there. If we can talk to it, 
we want to control it !! 

If you have a rig to test with thats cool, but not
essential. I currently develop on Linux 2.2 kernel,
but keen to get cross compilation via autoconf to
most OS's out there .

Status
------

Although considered alpha code, it does work for the few
backends we have written so far. Not all API is
implemented, but just enough to prove our design, and
to select VFO and frequencies etc..

API Documentation is kind of sparse (contributors welcome) but
dont let that throw you :-) Currently there is no web site, apart
from project site on source forge at

http://sourceforge.net/projects/hamlib

But there is always help on the mailing list :)

Our aim is to firm up our API, and get some more backends
underway.

73's de Frank Singleton (vk3fcs/km5ws)
   and  Stephane Fillod (f4cfe)

[Hamlib-developer] Merry XMAS and happy new year

[Frank S. <vk...@ix...>]

Hi hamlib crew,

Just wanted to wish you all a very nice holiday
season and great 2001 .

Looking forward to improving hamlib beyond
our expectations :-)

73's de Frank (vk3fcs/km5ws).

[Hamlib-developer] Re: hamlib-1.1.0 release note

[Egon Z. <Eg...@ho...>]

[Hamlib-developer] Re: hamlib-1.1.0 release note

[Egon Z. <Eg...@ho...>]

r 22

[Hamlib-developer] hamlib-1.1.0 release note

[Frank S. <vk...@ix...>]

Hamlib 1.1.0 Project Release
============================

Introduction
------------

Application programmers: Do you dream for a common API to
control any type of HAM Radio equipment that has a control
port?

Are you waiting to build the next cool GUI program to
really drive all that HAM gear you or others have?

Well, this project is here to help you get there :-)

hamlib-1.1.0 finally released (alpha). The purpose of this project 
is to develop stable, flexible, shared libraries that enable 
quicker development of Amateur Radio Equipment Control 
Applications. It will (eventually) run on various flavors 
of Unix, Linux, and Windows. It is based on a shared library 
frontend abstraction layer/backend approach. 

Application programmers will see a common frontend (abstraction
layer) API, and backend shared libs can be loaded on demand when
an application wishes to control a certain radio type. Seeking 
contributor help for a really cool project. 

Although alpha code, proof of concept has been tested 
against FT747, FT847 and IC706 rigs. 

It has gone through a major rework since its inception and
testing on my poor old FT747 (smoke test :)

Where to find it
----------------

Here is the main page and links to CVS, major releases
and links to news groups.

See http://sourceforge.net/projects/hamlib 

for details. 

There exists a mailing list for developers at

 ham...@li...


Example code:
------------

This "C" code snippet sets any rig to 21,235.175 Mhz USB, 
Normal bandwidth.

/* 15m USB */

retcode = rig_set_freq(my_rig, RIG_VFO_CURR, 21235175); /* 15m  */
retcode = rig_set_mode(my_rig, RIG_VFO_CURR,
RIG_MODE_USB,RIG_PASSBAND_NORMAL);

see hamlib/tests/testrig.c for an example.


Help Wanted
-----------

Get on board and help us write the frontend and backend 
libs for all the rigs out there. If we can talk to it, 
we want to control it !! 

If you have a rig to test with thats cool, but not
essential. I currently develop on Linux 2.2 kernel,
but keen to get cross compilation via autoconf to
most OS's out there .

Status
------

Although considered alpha code, it does work for the few
backends we have written so far. Not all API is
implemented, but just enough to prove our design, and
to select VFO and frequencies etc..

API Documentation is kind of sparse (contributors welcome) but
dont let that throw you :-) Currently there is no web site, apart
from project site on source forge at

http://sourceforge.net/projects/hamlib

But there is always help on the mailing list :)

Our aim is to firm up our API, and get some more backends
underway.

73's de Frank Singleton (vk3fcs/km5ws)
   and  Stephane Fillod (f4cfe)

[Hamlib-developer] CVS syncmail

[Frank S. <vk...@ix...>]

Hi,

I opened a ticket on syncmail. It no longer complains
when doing "cvs ci",but for some reason mail is not 
ending up on the list.

But, there is definitely activity in the CVS archives :-)

Be patient ;-)

Cheers / Frank

[Hamlib-developer] target VFO [was Re: Hamlib-cvs-digest digest, Vol 1 #29 - 1 msg]

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

On Thu, Dec 07, 2000, on hamlib-cvs-digest, Frank Singleton patched:
> Index: ft747.c
> ===================================================================
> RCS file: /cvsroot/hamlib/hamlib/ft747/ft747.c,v
> retrieving revision 1.21
> retrieving revision 1.22
> diff -C2 -r1.21 -r1.22
> ***************
> *** 278,281 ****
> --- 278,283 ----
>     rig_debug(RIG_DEBUG_VERBOSE,"ft747: requested freq = %Li Hz \n", freq);
>   
> +   ft747_set_vfo(rig, vfo);	/* select VFO first , new API */
> + 
>     to_bcd(bcd,freq,8);
>   
[...]
> ***************
> *** 504,507 ****
> --- 554,559 ----
>     rig_s = &rig->state;
>   
> +   ft747_set_vfo(rig,vfo);	/* select VFO first */
> + 
>     switch(ptt) {
>     case RIG_PTT_OFF:


  Actually, the <backend>_set_vfo() could be done in a generic way
  at the frontend level in rig.c, provided Hamlib knows through
  capabilities the rig can't address directly the different VFOs.
  The behaviour of Hamlib we still have to agree upon should assume
  IMO that whichever API function is called, the VFO selected by
  the previous rig_set_vfo must stay still. Here is an illustration:

	rig_set_vfo(VFO_A)
	...
	rig_set_freq(VFO_B,GHz(10.450))	/* geez, air-plane scatter! */
	...
	rig_get_vfo() -> VFO_A

  This means that for rigs that cannot address VFOs directly, the frontend
  (not the user application) should translate the previous sequence
  to this:

	rig_set_vfo(VFO_A)
	...
	if (!has_targetable_vfo) {
	  <backend>_set_vfo(VFO_B)
	  <backend>_set_freq(VFO_B,GHz(10.450))	/* VFO target useless here */
	  <backend>_set_vfo(VFO_A)
	}
	...
	rig_get_vfo() -> VFO_A

  Eventually, the frontend can "cache" which VFO is currently active,
  saving for some needless _set_vfo, but we have to take extra care that
  someone hasn't changed the VFO *manually* on the rig panel (however,
  having to do _get_vfo repeatedly would be a real pain).
  
  Anyway, I know you already have had this idea previously. The purpose of
  this mail is just to stress the "sharability" of such a piece of code
  (good feature to add for hamlib-1.1.1), and also to urge you 
  to release hamlib-1.1.0 now ;-)
  (remember "the release early, release often" rule of Linux)
  After all, hamlib-1.1.0 IS alpha quality, there's no shame about it,
  just lust for contributors.


  Cheers,

-- 
Stéphane

Re: [Hamlib-developer] API outstanding issues

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

On Sun, Dec 03, 2000, Frank Singleton wrote:
> 
> If you patch the frontend, I will update ft747 and ft847 to
> accept the new API. Then we RELEASE !!
  
all right, I've checked in the set_mode and the target VFO
modifications. I'm ready for the release!

Cheers,

-- 
Stephane

Re: [Hamlib-developer] API outstanding issues

[Frank S. <vk...@ix...>]

Stephane Fillod wrote:
> 
> Frank Singleton wrote:

<snip >

> > int rig_set_vfo_params(RIG *rig, vfo_t vfo, rmode_t mode, fresp_t fresp)
> > ??
> > int rig_get_vfo_params(RIG *rig, vfo_t vfo, rmode_t *mode, fresp_t
> > *fresp) ??
> >
> >
> > Also, the pbwidth_t is a subset of a general freq response type
> >
> > struct freqresp {
> >       filter_path_t fpt;  /* filter location */
> >       filter_mode_t fmt;  /* filter mode, eg: NORMAL,WIDE etc or CUSTOM */
> >                             /* CUSTOM must provide flower,fupper,fcenter
> > etc */
> >                             /* depending on CUSTOM type */
> > };
> >
> > typedef freqresp fresp_t;
> >
> [...]
> 
>   Your proposal looks comprehensive, however, I don't have such features
>   on my rig, and since I'm not very knowledged in this field, well I
>   cannot say much.
>   In an effort to try to map the Hamlib API to the way rigs work,
>   I would rather argue for two set of functions.
> 
> > >  int rig_set_mode(RIG *rig, vfo_t vfo, rmode_t mode, pbwidth_t width);
> > >  int rig_get_mode(RIG *rig, vfo_t vfo, rmode_t *mode, pbwidth_t *width);
> 
>   This would cover basic VFO support, ie. probably more than 80% of the
>   rigs out there, which don't have filters.
> 
>   And then, another set of functions, yet to specify, to fine tune
>   the filters of the mode:
> 
>         int rig_set_filter(RIG *rig, vfo_t vfo, fresp_t fresp)
>         int rig_get_filter(RIG *rig, vfo_t vfo, fresp_t, *fresp)
> 
>   Let me know what you think of the rig_set_mode/rig_get_mode approach
>   at least, if we have time to implement it before the forthcoming 1.1.0
>   release.

Ok, at least both approaches should cover everyone's requirements.

If you patch the frontend, I will update ft747 and ft847 to
accept the new API. Then we RELEASE !!

Cheers / Frank..

Re: [Hamlib-developer] API outstanding issues

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

Frank Singleton wrote:
> 
> Some raw thoughts here.. maybe wishlists but anyway ...
> 
> I see a VFO as "the" basic communication resource that can 
> have particular "parameters" associated with it.
> 
> ie: Normally to use the VFO for some communications purposes,
> then vfo,freq,mode and filter selections need to be made,
> as a minimum.
> 
> So what about.
> 
> int rig_set_vfo_params(RIG *rig, vfo_t vfo, rmode_t mode, fresp_t fresp)
> ??
> int rig_get_vfo_params(RIG *rig, vfo_t vfo, rmode_t *mode, fresp_t
> *fresp) ??
> 
> 
> Also, the pbwidth_t is a subset of a general freq response type
> 
> struct freqresp {
> 	filter_path_t fpt;  /* filter location */
> 	filter_mode_t fmt;  /* filter mode, eg: NORMAL,WIDE etc or CUSTOM */
>                             /* CUSTOM must provide flower,fupper,fcenter
> etc */
>                             /* depending on CUSTOM type */
> };
> 
> typedef freqresp fresp_t;
>
[...] 

  Your proposal looks comprehensive, however, I don't have such features 
  on my rig, and since I'm not very knowledged in this field, well I
  cannot say much.
  In an effort to try to map the Hamlib API to the way rigs work,
  I would rather argue for two set of functions.

> >  int rig_set_mode(RIG *rig, vfo_t vfo, rmode_t mode, pbwidth_t width);
> >  int rig_get_mode(RIG *rig, vfo_t vfo, rmode_t *mode, pbwidth_t *width);

  This would cover basic VFO support, ie. probably more than 80% of the
  rigs out there, which don't have filters.
  
  And then, another set of functions, yet to specify, to fine tune 
  the filters of the mode:

	int rig_set_filter(RIG *rig, vfo_t vfo, fresp_t fresp)
	int rig_get_filter(RIG *rig, vfo_t vfo, fresp_t, *fresp)


  Let me know what you think of the rig_set_mode/rig_get_mode approach
  at least, if we have time to implement it before the forthcoming 1.1.0 
  release.


Cheers,

-- 
Stephane