hamlib-developer — hamlib developers forum

[Hamlib-developer] CI-V

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

Hi all,

finally I've got a response from Icom Europe (Germany) but only
"unofficially"...

They don't have any problems with giving away copies of their CI-V
spec to developers but won't give us a written permission to use it
under GPL. The reason for that is the somehow strange attitude of
Icom Japan (they fear some legally exotic issues).

However, I was pointed to their website where is a link to 

	http://www.plicht.de/

where you'll find documentation of CI-V in english language.

Additionally my Icom contact told me about an article in the german
ham magazine "cq DL" 10/1990, pp. 634-638 which was about a reference
implementation of a rig control for an Icom receiver.

What does that mean for us?
On the one hand for legal reasons Icom Japan won't give anybody written
permission for the use of their copyrighted documentation. On the other
hand there are at least two independent sources of this spec to which we
can refer to. So from my point of view I have no problem of using the
original spec but "officiallly" refer to the past publications.

Comments?

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 

Re: [Hamlib-developer] CVS = no joy...

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

On Thu, Jan 25, 2001 at 06:17:50PM -0600, Frank Singleton wrote:
> What problems are you having ?? 

Getting an error that cvs couldn't chdir to /home/users/n0nb

> This should work for you if you have setup and stored your ssh key
> 
> export CVS_RSH=ssh
> cvs -z3 -d...@cv...:/cvsroot/hamlib co hamlib

Gave it a try and received the same error:

nomad:~/src $ cvs -z3 -d...@cv...:/cvsroot/hamlib
co hamlib
n0...@cv...'s password: 
Could not chdir to home directory /home/users/n0nb: No such file or
directory
cvs [server aborted]: can't chdir(/home/users/n0nb): No such file or
directory

Ordinarily, I've tried the more automatic method with the env variables
set and the short checkout command:

nomad:~/src $ echo $CVSROOT
:ext:n0...@cv...:/cvsroot/hamlib
nomad:~/src $ echo $CVS_RSH
ssh
nomad:~/src $ cvs co hamlib
n0...@cv...'s password: 
Could not chdir to home directory /home/users/n0nb: No such file or
directory
cvs [server aborted]: can't chdir(/home/users/n0nb): No such file or
directory
nomad:~/src $ 

One clue is the continued prompting for the password even though
~/.ssh/authorized_keys exists on the sourceforge home directory server
and an ssh login works with no password prompt.  I think the problem
lies in the fact that when my home directory was created it was created
with a group of n0nb rather than users.  The majority of the users
directories have a group of users including yours and Stephane's.

So until, and unless, someone over there can take an interest in my real
problem, I'm locked out.

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

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

Hi,

I have been using this bash script
for a while now, thought I would pass
it on. May not need all of it, but
nothing breaks as far as I know :-)

Just run it in the hamlib dir after
your cvs co ..then type make !


<snip>

#!/bin/sh
# To setup a new environment after
# CVS download from "hamlib".

aclocal
autoheader
automake  --add-missing --copy --include-deps
autoconf
./configure

<snip>

-- 
Cheers / Frank 

73's de vk3fcs & km5ws

Re: [Hamlib-developer] CVS = no joy...

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

Nate Bargmann wrote:
> 
> Hi All.
> 
> I apologize for not getting any updates to the web page lately.  I
> haven't forgotten about it, I've just had a bunch of stuff come up
> lately.  I am in the process of relocating and have been getting the
> house ready for sale and will (hopefully) be moving in a few weeks.  Of
> course during this time I may not get as much done as I'd like, but I
> hope to keep on developing the documentation.

I know the feeling, I have just moved  !!
> 
> Also, I cannot access CVS.  For three weeks now I have tried with no
> success.  I just entered my fourth request for support, but my enthusiam
> that the problem will be fixed rather than just receiving a form letter
> is waning.

What problems are you having ?? 

This should work for you if you have setup and stored your ssh key

export CVS_RSH=ssh
cvs -z3 -d...@cv...:/cvsroot/hamlib co hamlib

-- 
Cheers / Frank 

73's de vk3fcs & km5ws

[Hamlib-developer] CVS = no joy...

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

Hi All.

I apologize for not getting any updates to the web page lately.  I
haven't forgotten about it, I've just had a bunch of stuff come up
lately.  I am in the process of relocating and have been getting the
house ready for sale and will (hopefully) be moving in a few weeks.  Of
course during this time I may not get as much done as I'd like, but I
hope to keep on developing the documentation.

Also, I cannot access CVS.  For three weeks now I have tried with no
success.  I just entered my fourth request for support, but my enthusiam
that the problem will be fixed rather than just receiving a form letter
is waning.

Sorry for the lack of good cheer, but I wanted to let you know I hadn't
yet lost interest in the hamlib project.

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-cvs-digest digest, Vol 1 #41 - 1 msg

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

> From: Frank Singleton <jav...@us...>
> Date: Sat, 13 Jan 2001 17:10:16 -0800
[..]
> 
> Modified Files:
> 	ChangeLog 
> Log Message:
> ChangeLog history started
> 

  Good stuff Frank! Would it be possible also to commit the cvs2cl.pl
  script (or whatever it is called), it would be nice to group
  ChangeLog entries by developer/day.

Cheers,

-- 
Stephane / F4CFE

Re: [Hamlib-developer] Suse Id's

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

Hi Nate,

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

I will check this with the manufacturers I'll contact.

73, Kai

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