hamlib-developer — hamlib developers forum

Re: [Hamlib-developer] preferences

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

I can't get into CVS, so I'll sit on the mail list. :-)

On Mon, Jan 08, 2001 at 08:28:06PM +0100, Stephane Fillod wrote:
> 
>   I have this in mind too. A kind of rigd daemon. Some protocols
>   already exists. We can do bare stream proxying, or we can
>   do rig virtualization by rigd. The second one would incarnate 
>   as a new backend.

This sounds intriguing.

> > 
> > I'm not dismissing the idea entirely, but I do believe its use should
> > likley be as limited as possible.  I guess it comes from my visualizing
> > hamlib as more of a system type library on the order of libc.
> > 
>   My concern is that every single application using Hamlib would have
>   to rewrite its own preference parsing routines, etc.
>   The end user would have to struggle with n different file formats
>   to declare its radio. 
>   libc has /etc/nsswitch.conf et al. and to my mind, Hamlib is a library too,
>   ie. collecting/sharing functions which have a relation with each other.

In most cases, I think most of the apps will already be writing some
sort of preference themselves, so I'm not seeing the problem with the
end user, but I'm likely overlooking something.

>   However, you're right too. Would flexibility be an acceptable answer to your
>   concern? Let's say Hamlib supports preference parsing, but it's not
>   done automatically, it must be explicitly called (rig_read_pref()).
>   This way, programmers using Hamlib have the choice of using the
>   simple preferences facility that comes with Hamlib, or creating
>   a more comprehensive preference system associated with their application
>   or a bigger scheme (eg. registry under Windows).
>   In that case, we have to agree upon API calls that will let them
>   modify the rig parameters (rig_set_serial, rig_set_network, etc.)
>   as rig_read_pref() would do internally.

Perhaps this is an area where we need interest from the direct users of
hamlib, the application authors and let them tell us what they find
necessary (wishlist?).

>   Another issue that may have a solution in preferences, is
>   the location of backend modules. Right now, programmers have
>   to call rig_load_backend() to have support for new rig types.
>   This is painfull, and we don't even know in which directory are
>   located the modules. Could we have a RIGBACKENDPATH variable
>   (or smthg like that), how do we know what files to load?

As I read the API now, a programmer has to call rig_load_backend() and
test for failure to figure out if a radio is supported, which needs
improvement.  Currently hamlib doesn't provide a list of supported
backends and should in the future, either through a static list in a 
prefs file or dynamically by searching each backend in a given directory
and reporting the list back to the caller.

An environment variable or a pref entry for backend location(s?) is a good 
idea.  I did install hamlib 1.1.0 over the weekend and noticed how the 
backend libs were dropped into /usr/local/lib along with hamlib.so.  By 
default I think it would be a good idea to drop them into their own
directory (/usr/local/lib/hamlib?).  Perhaps even hamlib itself could
live there with symlinks (hamlib.so, hamlib.a) being placed in 
/usr/local/lib.

>   A neat feature would be a list of available backends, pretty much
>   like tests/listrigs, but without the explicit rig_load_backend().
>   That'd be handy so you can select your rig from a listbox...

If the list is static in a prefs file, then it should be built when
hamlib is built.  Again this is probably an area that apps writers could
better guide us.

>   As usual, comments are welcome!

Yeah, well I can't get into CVS to start documenting, so...

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] rig not supporting target VFO

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

Frank Singleton wrote:
> >                 if (!rig->caps->set_vfo)
> >                         return -RIG_ENTARGET;
> >                 curr_vfo = rig->state.current_vfo; 
>                               ^
>                               |
>                               +---------  what is initial value ?
> 
> If _set_mode called on a rig that has targetable_vfo = 0, then
> we send #%$ if no VFO has been set.
> 
  Looking at rig_init, rig->state.current_vfo should be correctly
  initialized if get_vfo is implemented in the backend (not very common),
  otherwise it is set to RIG_VFO_CURR.

  The current code should work fine, provided rig->caps->set_vfo ignores
  RIG_VFO_CURR (which is the expected -undocumented- behaviour). 

  And as soon as a rig_set_vfo is done, the question is gone.
  Forcing a rig_set_vfo(RIG_VFO_A) in rig_open has some drawbacks anyway.

> 
>                 curr_vfo = rig->state.current_vfo;
>                 retcode = rig->caps->set_vfo(rig, vfo);
                                                     |
					this one is defined (!= RIG_VFO_CURR)

>                 if (retcode != RIG_OK)
>                                 return retcode;
> 
>                 retcode = rig->caps->set_mode(rig, vfo, mode, width);
>                 rig->caps->set_vfo(rig, curr_vfo);
                                             |
					this may be RIG_VFO_CURR,
					but it doesn't matter.
>                 return retcode;
>     }
> 

> Comments ??
> 
  Actually, you did find a buglet in my code. Consider the following
  app:
	rig_init()

	rig_open()
	rig_set_vfo()
	rig_do_some_stuff()
	...
	rig_close()

	/* VFO manually changed */

	rig_open()	<-- this time current_vfo is not reset!
	rig_do_some_other_stuff()
	...

  well, it's not a big issue and it's easily fixable. We just have to
  take care of the "preferences" that can be initialized on the way..

-- 
Stephane

Re: [Hamlib-developer] LICENSE ChangeLog

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

Frank Singleton wrote:
> touch LICENSE 
> touch ChangeLog
> 
> to get a clean make
> 
  sorry about that

> I guess we should put something useful in thes files.
> 
  I'm commiting the LICENSE file right now. ChangeLog should be filled
  with an (automatic) extract of the CVS comments, with a script
  yet to be written.
  These files among others are recommanded by the GNU style.

-- 
Stephane

Re: [Hamlib-developer] preferences

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

Nate Bargmann wrote:
> talk to.  If the radio doesn't exist or if the communications link is
> severed or if the wrong radio is selected hamlib should gracefully
> report the error and leave it to the user app to prompt the user of the
> error and correct it.
> 
	I agree with you.

> I'm thinking that as hamlib becomes network aware, it maybe possible to
> connect to it from a remote machine and then control a radio connected
> to a third host (yeah, this would be a security hole, but it's too cool
> not to do!).  So in this case a preference file might be a hindrance.

  I have this in mind too. A kind of rigd daemon. Some protocols
  already exists. We can do bare stream proxying, or we can
  do rig virtualization by rigd. The second one would incarnate 
  as a new backend.
> 
> I'm not dismissing the idea entirely, but I do believe its use should
> likley be as limited as possible.  I guess it comes from my visualizing
> hamlib as more of a system type library on the order of libc.
> 
  My concern is that every single application using Hamlib would have
  to rewrite its own preference parsing routines, etc.
  The end user would have to struggle with n different file formats
  to declare its radio. 
  libc has /etc/nsswitch.conf et al. and to my mind, Hamlib is a library too,
  ie. collecting/sharing functions which have a relation with each other.

  However, you're right too. Would flexibility be an acceptable answer to your
  concern? Let's say Hamlib supports preference parsing, but it's not
  done automatically, it must be explicitly called (rig_read_pref()).
  This way, programmers using Hamlib have the choice of using the
  simple preferences facility that comes with Hamlib, or creating
  a more comprehensive preference system associated with their application
  or a bigger scheme (eg. registry under Windows).
  In that case, we have to agree upon API calls that will let them
  modify the rig parameters (rig_set_serial, rig_set_network, etc.)
  as rig_read_pref() would do internally.

  Another issue that may have a solution in preferences, is
  the location of backend modules. Right now, programmers have
  to call rig_load_backend() to have support for new rig types.
  This is painfull, and we don't even know in which directory are
  located the modules. Could we have a RIGBACKENDPATH variable
  (or smthg like that), how do we know what files to load?

  A neat feature would be a list of available backends, pretty much
  like tests/listrigs, but without the explicit rig_load_backend().
  That'd be handy so you can select your rig from a listbox...

  As usual, comments are welcome!

-- 
Stephane

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

[Kai A. <ka...@su...>]

Hello Frank and all others,

On Thu, Jan 04, Frank Singleton wrote:

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

I've got a quite good contact to Kenwood Germany that I could ask 
all available specs for. 

And I've got a copy of the Icom "Communication Interface - V" reference
manual. This covers models:

ic725, ic726, ic728, ic729, ic735, ic737, ic751, ic751a, ic761, ic765,
ic781

ic271a/e/h, ic471a/e/h, ic1271a/e, ic575a, ic275a/e/h, ic375a, ic475a/e/h,
ic1275a/e, ic970a/e/h

icr71a/e/d, icr72, icr7000, ic-r7100, icr9000

For Yaesu I'd have to reactivate my contacts to their german subsidiary.


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 

[Hamlib-developer] LICENSE ChangeLog

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

Hi,

I had to 

touch LICENSE 
touch ChangeLog

to get a clean make

I guess we should put something useful in thes files.


-- 
Cheers / Frank 

73's de vk3fcs & km5ws

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

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

Frank Singleton wrote:

> #if 1
>                 if (rig->state.current_vfo = NULL)
>                         return -RIG_ENCURRVFO;
> #endif
> 

Oops!!

 #if 1
                 if (rig->state.current_vfo == NULL)
                         return -RIG_ENCURRVFO;
 #endif
 



-- 
Cheers / Frank 

73's de vk3fcs & km5ws

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

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

Stephane Fillod wrote:
> 

<snip>

> 
>     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; 
                              ^
                              |
                              +---------  what is initial value ?

If _set_mode called on a rig that has targetable_vfo = 0, then
we send #%$ if no VFO has been set.

TODO: Think of initial values. This was in backend for my FT747,
but now its a frontend responsibility (or app ?)

Should we change it change this to 

    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;

#if 1
                if (rig->state.current_vfo = NULL)  
                        return -RIG_ENCURRVFO;
#endif

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


The frontend initially sets rig->state.current_vfo = ZNULLVFO
during initialsation.

Comments ??


-- 
Cheers / Frank 

73's de vk3fcs & km5ws

Re: [Hamlib-developer] We have a webpage!

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

Nate Bargmann wrote:
> 
> 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 >>

Hi,

Ok, I see the web page is alive !! Can only
get better from here on in :-)

-- 
Cheers / Frank 

73's de vk3fcs & km5ws

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

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

Nate Bargmann wrote:
> 
> On Thu, Jan 04, 2001 at 01:46:51AM -0600, Frank Singleton wrote:
> 
> > GETTING AS MANY BACKENDS AS POSSIBLE WRITTEN !!
> 
> Agreed!
> 
> > 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..
> 
> Would it be possible for the primary SuSE contact to be able to act as an
> agent for the contributors they line up?  Thus you have one or two folks
> from SuSE who, presumably, will be able to be associated with hamlib on
> a long term basis, at least longer than a university term.
> 

Yes this is what I am hinting. Kinda like
setting up say suse1 and suse2 and having say Kai as
our primary point of contact

> Also, a useful bit of code would be to have them actually build
> applications using hamlib to test the API and find the bugs. :)
> In the future they could work on such things as wrappers for other
> languages as well as rig backends, which are the priority now.
> 

What about some GTK apps that can load different rigs and test
the API etc..

In fact setting freq,mode and bandwidth and PTT should be sufficient
for say PSK31 etc..

> BTW, I have been looking at the 747 code the past couple days and I have
> a rather good handle on it, so I'm going to compile hamlib this weekend
> and start testing with my '920.  The basic commands are similar and I'll
> need to careful with a couple of them in testrig.
> 
> Before hacking out a new backend I suppose it would be better to work
> with the CVS code now than the 1.1.0 release?
> 
> 73, de Nate >>


Yes, please use CVS, as I have moved the yaesu rigs into
yaesu/ directory. Place your code in the yaesu
directory. ie yaesu/ft920.[ch]

If you look at the Makefile.am, you can add the '920
in there also.

I have tested the yaesu/ stuff on my FT747 and everything
still works (hi hi..) after the reorg. Dont use
the old style directory ft920/ as I will clean it out
soon. (ft747/ ft847/ ft920/ etc..)



-- 
Cheers / Frank 

73's de vk3fcs & km5ws

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

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

On Thu, Jan 04, 2001 at 01:46:51AM -0600, Frank Singleton wrote:

> GETTING AS MANY BACKENDS AS POSSIBLE WRITTEN !!	

Agreed!

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

Would it be possible for the primary SuSE contact to be able to act as an
agent for the contributors they line up?  Thus you have one or two folks
from SuSE who, presumably, will be able to be associated with hamlib on
a long term basis, at least longer than a university term.

Also, a useful bit of code would be to have them actually build
applications using hamlib to test the API and find the bugs. :)  
In the future they could work on such things as wrappers for other
languages as well as rig backends, which are the priority now.

BTW, I have been looking at the 747 code the past couple days and I have
a rather good handle on it, so I'm going to compile hamlib this weekend
and start testing with my '920.  The basic commands are similar and I'll
need to careful with a couple of them in testrig.

Before hacking out a new backend I suppose it would be better to work
with the CVS code now than the 1.1.0 release?

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

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

On Thu, Jan 04, 2001 at 12:00:32AM +0100, Stephane Fillod wrote:
> 
> 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 :)

Okay, I'm new and I'll admit to tunnel vision here.  I really wonder if
this isn't a function better left to the applications.  In my view
(admittedly flawed :) I see hamlib as being a virtual radio with as
consistent and simple  API as possible given the myriad of radios and other
devices out there.  I'm not so sure that it's hamlib's duty to maintain
and parse a list of connected radios or even the ports/hosts the
radio(s) are connected.  

IMHO, hamlib shouldn't care what radios are connected as it should be 
the user application that prompts for and maintains this information and
uses it to initialize the connected radio(s) it is asked by the user app to
talk to.  If the radio doesn't exist or if the communications link is
severed or if the wrong radio is selected hamlib should gracefully
report the error and leave it to the user app to prompt the user of the
error and correct it.

I'm thinking that as hamlib becomes network aware, it maybe possible to
connect to it from a remote machine and then control a radio connected
to a third host (yeah, this would be a security hole, but it's too cool
not to do!).  So in this case a preference file might be a hindrance.

I'm not dismissing the idea entirely, but I do believe its use should
likley be as limited as possible.  I guess it comes from my visualizing
hamlib as more of a system type library on the order of libc.

In defense of a library having an rc file GTK+ came to mind with its use
of ~/.gtkrc for themes.  

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