hamlib-developer — hamlib developers forum

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

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

On Mon, Jan 08, Stephane Fillod wrote:

> 
> Hi Kai!
> 
> > And I've got a copy of the Icom "Communication Interface - V" reference
> > manual. This covers models:
> > 
>   Do you know where I can find a copy of this manual? Maybe you have
>   it in electronic format, in which case, I'd really appreciate
>   to receive it, since I'm the current maintainer of the Icom backend.

No, unfortunately I only have a printed copy. As I wrote in the mail
before I contacted Icom for this and still wait for an answer.

73, Kai

[Hamlib-developer] Re: Suse Id's

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

Hi,

On Mon, Jan 08, Frank Singleton wrote:

> Well I tossed it round our little (but expanding)
> group, and here is workable strategy.
> 
> 1. I would like 1 person (you?) as a Suse rep for this
>    involvement with Uni students. Makes it easier  on us
>    for maintenance issues etc, even after the Uni project.

I've subscribed myself to this list.


> 2. You organize some (1 or 2?) generic Suse userids on 
>    sourceforge for this purpose, and  be responsible for 
>    usage.

I'll do that as soon as we have some new students.

> 3. I add them to the project. 
> 
> 4 Possible Project examples (in descending order of 
>   importance ?).
> 
>    - Backends for other rigs !!
>    - Some GUI apps (eg GTK )to test our growing API
>    - PSK31 app
>    - wrappers for other languages
>    - etc
>    - 
> 
> Please let me know if this is suitable with you.
> I think backends and GUI Apps would enhance the VISIBILITY
> of hamlib a lot. You can definitely assist us in this
> area Kai.

I'll do my best. ;)

> On another issue...
> 
> What is the possibility of getting permission from kenwood/yaesu/icom
> etc to keep a electronic copy of their rig control docs
> on our project (web) page?

I've contacted a person at Icom whom I met at HAM Radio '99 but got no
answer until now.

For Kenwood I'll do the same within the next few days. My contact at
Yaesu's left the company so I'll have to find someone else suitable.


Regards, Kai

[Hamlib-developer] ChangeLog

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

Hi,

I will see if we can use cvs2cl.pl for our 
ChangeLog entries.

ala http://www.red-bean.com/cvs2cl/

-- 
Cheers / Frank 

73's de vk3fcs & km5ws

Re: [Hamlib-developer] Suse Id's

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

On Mon, Jan 08, 2001 at 09:09:37PM -0600, Frank Singleton wrote:
> 
> On another issue...
> 
> What is the possibility of getting permission from kenwood/yaesu/icom
> etc to keep a electronic copy of their rig control docs
> on our project (web) page?

Hmmm, this caused a bunch of thought (not good!).

If the docs in question are produced in electronic form and produced by
the manufacturer (say a .pdf), then permission is likely necessary.  If,
on the other hand, we're talking about needing permission to transcribe
the commands and their parameters from the rig docs into a format of our
own electronic design, then I think we have a problem.

I am not a lawyer or GPL expert, but if we'd need permission to post a
transcription of what exists in hamlib source code, then we could be in
a very gray area with regard to the GPL.  If a manufacturer requires NDA
or permission (which to my knowledge none of them do once the radio is on
the market) to use the command set, then that radio probably cannot be
supported by hamlib.

Even though the manuals themselves are probably published under
copyright (in fact I could find no specific copyright information on my
Yaesu FT-890 manual), the command API is likely considered to be public
information.  Even under the terms of fair use we can utilize the
information in the manual to control the radios and publish what we've
done to the web or in the hamlib docs.

Likewise, even though the commands are used in a GPL'ed program, there
is no guarantee that someone won't read the source and use the command
sets in a proprietary program.  We can't prevent that from happening,
common information isn't controlled by the GPL.  What is controlled is
someone copying and pasting hamlib code into a program that is incompatible
with the GPL (I'm probably not as clear on all this as I think I am).

To summarize, since the rig commands are specific to the controlled
device, they are public knowledge.  Since they are public knowledge (as
the manuals say nothing about preventing the command information from
being disclosed), permission should be necessary to publish the command
sets in documentation of our creation so long as its clear that those
commands are a designed part of the radio, and not an original work of
the hamlib authors.

So far much software has been written to control radios, both
proprietary and free and I know of no case where a manufacturer raised
an issue with regard to use of the radio command sets as they cannot be
considered trade secrets either.

> This means people without those docs could contribute code also.
> Good PR for these companies also :^)

This would be a good thing to use the web space for...

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] Re: hamlib-1.1.0 release note

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

Hi Kai!

> And I've got a copy of the Icom "Communication Interface - V" reference
> manual. This covers models:
> 
  Do you know where I can find a copy of this manual? Maybe you have
  it in electronic format, in which case, I'd really appreciate
  to receive it, since I'm the current maintainer of the Icom backend.

Thanks for your support,

Cheers,
-- 
Stephane					F4CFE

[Hamlib-developer] Suse Id's

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

Kai Altenfelder wrote:
> 
> 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:
> 

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

All rig info welcome Kai :-)

Well I tossed it round our little (but expanding)
group, and here is workable strategy.

1. I would like 1 person (you?) as a Suse rep for this
   involvement with Uni students. Makes it easier  on us
   for maintenance issues etc, even after the Uni project.

2. You organize some (1 or 2?) generic Suse userids on 
   sourceforge for this purpose, and  be responsible for 
   usage.

3. I add them to the project. 

4 Possible Project examples (in descending order of 
  importance ?).

   - Backends for other rigs !!
   - Some GUI apps (eg GTK )to test our growing API
   - PSK31 app
   - wrappers for other languages
   - etc
   - 

Please let me know if this is suitable with you.
I think backends and GUI Apps would enhance the VISIBILITY
of hamlib a lot. You can definitely assist us in this
area Kai.

On another issue...

What is the possibility of getting permission from kenwood/yaesu/icom
etc to keep a electronic copy of their rig control docs
on our project (web) page?

This means people without those docs could contribute code also.
Good PR for these companies also :^)

Comments ?
   
-- 
Cheers / Frank 

73's de vk3fcs & km5ws

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