hamlib-developer — hamlib developers forum

Re: [Hamlib-developer] Re: Addiions for the R-8500 and 750PRO

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

Frank Singleton wrote:
> David HM Spector wrote:
> > 
> > There are several modes that are present on the R-8500 that don't seem
> > to be present on other Icom rigs and which don't seem to be defined in
> > the current hamlib includes.
[...]
> 
> Diffs are welcome, but come join us as a developer :-)
> Just sign up at sourceforge.
> 
  welcome on board David!

> We have left the basic mode types, and introduced
> bandwidth parameters.
> 
[...]
> enum passband_width_e {
> 	RIG_PASSBAND_NORMAL = 0,
> 	RIG_PASSBAND_NARROW,
> 	RIG_PASSBAND_WIDE
> };
> 
> typedef enum passband_width_e pbwidth_t;
> 
> eg:
> 
> rig_set_mode(RIG *rig, rmode_t mode); /* select mode */
> rig_set_passband(RIG *rig, pbwidth_t width); /* select width */
  
Well, to be more exact rig_set_passband isn't any more, and rig_set_mode
evolved into a combined function:

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


Anyway, it looks like we still lack some "modes".
 * How would you set Synchronous AM (detection only), aka S-AM ?
 * How would you set reverse sideband modes, like CW-R and RTTY-R ?

To my mind, these modes belong to rig_set_mode. However, I'm wondering
if we should create new RIG_MODEs or not.
Ideas anyone?


-- 
Stephane

Re: [Hamlib-developer] Hamlib-1.1.0 Manual rough draft online

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

Nate Bargmann wrote:
> 
> Hello all.
> 
> No longer vapor, there is actually a rough draft of what I hope will
> become the Hamlib manual. 

Glad to see its underway... good documentation really will
help our project a lot.

> The delay was caused by 1) learning Docbook/SGML, 2) getting the flu bug
> in the middle of January, 3) due to a job relocation getting the house
> in a salable condition, and 4) getting along with the relocation
> process.  Hopefully time will return in a month or so as tax time is
> here, bleah!

Phew, its all behind you now :-)

> 
> BTW, the URL for the manual is:
> 
> http://www.networksplus.net/n0nb/
> 

Good start Nate, I am sure it will look most excellent
with the API description in there.

Shall we set it out like the glib folks at

http://developer.gnome.org/doc/API/2.0/glib/index.html

Seems fairly easy to navigate :-)

Comments ??
-- 
Cheers / Frank 

73's de vk3fcs & km5ws

Re: [Hamlib-developer] Icom CI-V Trancieve issue...

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

David HM Spector wrote:
> 
> Here's an interesting issue (and potential problem):
> 
  very interesting indeed. and a limitation of the CI-V protocol on Icoms :(

> The CI-V trancieve mode setting is defined in the manuals for my
> 756PRO and R-8500 to be a mode that will change the operating
> frequency of all Icom radios connected to the CI-V bus if one of them
> is changed; however the trancieve function is mentioned in rig.h as:
> 
> 	"tranceive mode, ie. the rig notify the host of any event,like freq 
> 	 changed, mode changed, etc."
> 
	well, the rig.h comment is referring to event notification
  (ie. not only Icom mode)

> Having had trancieve mode turned on on both these rigs connected to
> the same bus, I can vouche for the fact that it will indeed cause
> freq/modes to change in all rigs connected if you change the freq/mode
> on one of them.
> 
  There must be a solution using a couple of components on a PCB.
  I'm thinking of diodes isolating rigs when they are transmitting 
  (ie. the Host is not Transmitting).
  Could it be feasible with async comm ? (I'm not an expert in electronics)

> Perhaps there needs to be a polling API defined (I don't know if this
> is an Icom specific "feature") that will allow things like GUIs get
> the state of a rig rather than depend upon the tranceive mode which
> clearly doesn't do what one needs here...
> 
  Funny enough, there's a RIG_TRN_POLL constant defined recently
  in rig.h. Actualy, I was thinking of implementing this feature
  at the frontend level, since some rigs are not able to do this
  (Yaesu, Kenwood, ..). Please note that some Icoms do not support
  notification for all possible events. Thus emulation would be interesting.

  One last thought on the subject. This feature is a must for GUIs.
  Hamlib developers COULD decide to not implement it in their library and
  let the GUI's developer struggle with it. IMO, this is not a good approach.
  Since Hamlib aims to standardize radio control, event notification
  MUST be done in Hamlib, hiding communication details (originating from rig, 
  or by polling).

  Right now, Hamlib has only proof of concept code for event notification.
  It works (at least with my IC706). However, it's only a hack, so let's
  rework(ie. rewrite) it. We have to design a nice interface for this purpose. 
  Ideas anyone?!

Cheers,
-- 
Stephane / F4CFE

Re: [Hamlib-developer] problem adding modules (rigs)

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

Hi David!

David HM Spector wrote:
> I'm working on adding support for the Icom R-8500 and the 750PRO to
> hamlib (and a set of nice GUIs to make'em useful), but I'm running in

    Good to see people interested in CI-V! Have you noticed there's
  already some basic IC-R8500 support in the current CVS repository?
  REM: Always use CVS for now, as we're still in alpha stage.

  It would be great if you own, or at least are able to test Hamlib
  on the Icom R-8500 and the 750PRO. I wrote part of the CI-V support
  that is used by most Icoms (~75% opcodes done), but we still have
  to find a nice way to handle the CSMA/CD nature of the CI-V bus,
  and the sharing of serial ports, including the transceive mode.

> to a prtty basic problem:  After adding the modules (i.e., "r8500.c")
> to the Makefile.am file in the icom directory, and rebuilding the
> entire package, I never see the new rig(s) listed when I invoke
> listrigs in the tests directory.

  This should really be explained in a new-backend-mini-HOWTO..
  Very simple. New backends need to be registered to be known by Hamlib.
  For instance, at the very bottom of icom.c, there's a init_icom() function
  (the initialization function called right after the backend is loaded) 
  that should register the R-8500 with "rig_register(&icr8500_caps);"
  (as done currently in the CVS rep, see cvsweb or cvs snapshot).
  Then, as long as rig_load_backend("icom") is called in listrig,
  it should show up:

(fillods@charybde:hamlib)$ tests/listrigs
Rig#    Mfg     Model           Vers.   Status  Type
0       Yaesu   FT-847          0.1     Alpha   Transceiver
4       Yaesu   FT-747GX        0.1     Alpha   Mobile
40      Icom    IC-706          0.2     Untested        Mobile
73      Icom    ICR-8500        0.2     Untested        Receiver
41      Icom    IC-706MKII      0.2     Untested        Mobile
42      Icom    IC-706MKIIG     0.2     Alpha   Mobile
27      Kenwood TS-870S         0.1     Untested        Transceiver
79      AOR     AR8200          0.1     Untested        Scanner


  Anyway, feel free to ask any question if my code looks odd or whatever.
  Also you are more than welcome to join the Hamlib development team, and
  gain CVS access. I'd be pleased also to hear your comments about 
  the CI-V layer design in Hamlib, which is far from perfect and complete.

Cheers,

-- 
Stephane / F4CFE

[Hamlib-developer] Re: Addiions for the R-8500 and 750PRO

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

David HM Spector wrote:
> 
> Hi Frank,
> 
> There are several modes that are present on the R-8500 that don't seem
> to be present on other Icom rigs and which don't seem to be defined in
> the current hamlib includes.
> 
> Included is the diff for rig.h ... please let me know if this is the
> correct way one should be defining new modes (it didn't appear to me
> that the bits themselves were meant to map into rig control codes, so
> adding new modes at the end seems "safe").
> 
> RCS file: RCS/rig.h,v
> retrieving revision 1.1
> retrieving revision 1.2
> diff -r1.1 -r1.2
> 8c8
> <  *    $Id: rig.h,v 1.1 2001/01/26 14:18:22 spector Exp $       *
> ---
> >  *    $Id: rig.h,v 1.2 2001/02/03 20:12:29 spector Exp $       *
> 303a304,306
> > #define RIG_MODE_WFM          (1<<6)  /* R8500: Wide FM */
> > #define RIG_MODE_NCW          (1<<7)  /* R8500: Narrow CW */
> > #define RIG_MODE_NAM          (1<<8)  /* R8500: Narrow AM */
> 313d315
> <

Hi,


Diffs are welcome, but come join us as a developer :-)
Just sign up at sourceforge.

Somewhere along our API trail, we thought about
splitting mode and bandwidth .

ie: avoid things like AMN,AMW, etc.

We have left the basic mode types, and introduced
bandwidth parameters.

So if you wanted AMN, then you would use the
fronteneds API rig_set_mode to set AM, and then set the
bandwidth with rig_set_passband .

enum passband_width_e {
	RIG_PASSBAND_NORMAL = 0,
	RIG_PASSBAND_NARROW,
	RIG_PASSBAND_WIDE
};

typedef enum passband_width_e pbwidth_t;


eg:

rig_set_mode(RIG *rig, rmode_t mode); /* select mode */
rig_set_passband(RIG *rig, pbwidth_t width); /* select width */


-- 
Cheers / Frank 

73's de vk3fcs & km5ws

Re: [Hamlib-developer] problem adding modules (rigs)

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

David HM Spector wrote:
>=20
> Hi Frank,
>=20
> The additions/changes to testrig.c (besides setting the serial port)
> were:
>=20
>         retcode =3D rig_load_backend("r8500");
>=20
>         my_rig =3D rig_init(RIG_MODEL_ICR8500);
>=20
> The file I added to the icom directrory was a modified version of the
> ic706.c file which I called "r8500.c" and there are r8500.{a|o|lo}
> files in the icom directory.
>=20
> After rebuilding everything and doing a "make install" , when I run tes=
trig I get:

>=20
> [root@wuzzle tests]# ./testrig
> testrig:hello, I am your main() !
> rig: loading backend r8500
> rig: dlopen() failed (=FF=BF =CE: cannot open shared object file: No su=
ch file or directory)
> rig_load_backend: error =3D Invalid parameter
>=20

Hmm, I just do make and skip the "make install", that way the
libs are local to my cvs directory  when I test stuff.

ie:

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

then=20

./tests/testrig=20


And things work ok.


>=20
> Am I correct in presuming that the dlopen is trying to open the
> specific rig's library module..?  Or, should it be opening "icom"
> since all of the icom-specific libraries for each individual rig
> are archived in the libhamlib-icom.a file.

For the yaesu rigs (me backend resp ), a dlopen call in  the frontend
will
attempt to find   the "specific" backend rig's lib.
eg the ft747 or the ft847 lib

This should be the general case for most rigs.=20
Stephane (icom resp) may have decided to generate a general
libhamlib-icom
lib to handle the common icom stuff.

I will forward this onto the hamlib devel list and see
what he says :-)

--=20
Cheers / Frank=20

73's de vk3fcs & km5ws

[Hamlib-developer] Hamlib-1.1.0 Manual rough draft online

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

Hello all.

No longer vapor, there is actually a rough draft of what I hope will
become the Hamlib manual.  Right now the Preface and Chapter 1 are
reasonably fleshed out.  Please take a look and offer your corrections
and suggestions for improvement (there are many I'm sure).  I ran out of
time to add in the API reference from rig.c.  Hopefully I can get around
to that during the next week.  While I won't be able to rebuild the
document, edits will continue.

The delay was caused by 1) learning Docbook/SGML, 2) getting the flu bug
in the middle of January, 3) due to a job relocation getting the house
in a salable condition, and 4) getting along with the relocation
process.  Hopefully time will return in a month or so as tax time is
here, bleah!

BTW, the URL for the manual is:

http://www.networksplus.net/n0nb/

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] Icom CI-V Trancieve issue...

[David HM S. <sp...@ze...>]

Here's an interesting issue (and potential problem):

The CI-V trancieve mode setting is defined in the manuals for my
756PRO and R-8500 to be a mode that will change the operating
frequency of all Icom radios connected to the CI-V bus if one of them
is changed; however the trancieve function is mentioned in rig.h as:

	"tranceive mode, ie. the rig notify the host of any event,like freq 
	 changed, mode changed, etc."

Having had trancieve mode turned on on both these rigs connected to
the same bus, I can vouche for the fact that it will indeed cause
freq/modes to change in all rigs connected if you change the freq/mode
on one of them.

This is a real problem if you, as I do, have one rig performing a
specific task while using another for another task, it will also be a
problem for any GUI or other control program written where more than
one Icom rig is turned on.  

Perhaps there needs to be a polling API defined (I don't know if this
is an Icom specific "feature") that will allow things like GUIs get
the state of a rig rather than depend upon the tranceive mode which
clearly doesn't do what one needs here...


73,
 David
--------------------------------------------------------------------------------
David HM Spector                        Network Design & Infrastructure Security
sp...@ze...               -or-                     sp...@sp...
voice: +1 631.261.5013                                       Fax: +1 631.262.7497
Amateur Radio: W2DHM (ARRL life member) GridSquare: FN30hv (40.52'45"N 73.21'21"W) 
-.-. --- -. -. . -.-. -  .-- .. - ....  .- -- .- - . ..- .-.  .-. .- -.. .. ---
Those who will not reason, are bigots, those who cannot, are fools, and those who 
dare not, are slaves.     -George Gordon Noel Byron [a.k.a Lord Byron](1788-1824)

Re: [Hamlib-developer] problem adding modules (rigs)

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

David HM Spector wrote:
> 
> Hi all,
> 
> I'm working on adding support for the Icom R-8500 and the 750PRO to
> hamlib (and a set of nice GUIs to make'em useful), but I'm running in
> to a prtty basic problem:  After adding the modules (i.e., "r8500.c")
> to the Makefile.am file in the icom directory, and rebuilding the
> entire package, I never see the new rig(s) listed when I invoke
> listrigs in the tests directory.
> 
> If I get a listing of the contents of the icom.a library (with ar -t)
> I see that my modules are indeed in the library, they just don't ever
> seem to be called.  Any ideas..?


First,  welcome :-)

The GUI's would be most welcome !!

Second, if you put your rig in the testrig.c file
with the correct port and compile, do you see
communication with the rig at all.




ie:

#define SERIAL_PORT "/dev/ttyS0"   <----------- your port here

<snip>

 	/*
	 * allocate memory, setup & open port 
	 */

	retcode = rig_load_backend("ft747"); <---------  your rig here

	if (retcode != RIG_OK ) {
		printf("rig_load_backend: error = %s \n", rigerror(retcode));
		exit(3);
	}

	my_rig = rig_init(RIG_MODEL_FT747); <------and here

ie: replace the "ft747" with your rig type

Just trying to establish if its a listrig thing
or something else.

-- 
Cheers / Frank 

73's de vk3fcs & km5ws

[Hamlib-developer] problem adding modules (rigs)

[David HM S. <sp...@ze...>]

Hi all,

I'm working on adding support for the Icom R-8500 and the 750PRO to
hamlib (and a set of nice GUIs to make'em useful), but I'm running in
to a prtty basic problem:  After adding the modules (i.e., "r8500.c")
to the Makefile.am file in the icom directory, and rebuilding the
entire package, I never see the new rig(s) listed when I invoke
listrigs in the tests directory.

If I get a listing of the contents of the icom.a library (with ar -t)
I see that my modules are indeed in the library, they just don't ever
seem to be called.  Any ideas..?

73,  
  David
  W2DHM

-- 
--------------------------------------------------------------------------------
David HM Spector                        Network Design & Infrastructure Security
sp...@ze...               -or-                     sp...@sp...
voice: +1 631.261.5013                                       Fax: +1 631.262.7497
Amateur Radio: W2DHM (ARRL life member) GridSquare: FN30hv (40.52'45"N 73.21'21"W) 
-.-. --- -. -. . -.-. -  .-- .. - ....  .- -- .- - . ..- .-.  .-. .- -.. .. ---
Those who will not reason, are bigots, those who cannot, are fools, and those who 
dare not, are slaves.     -George Gordon Noel Byron [a.k.a Lord Byron](1788-1824)

Re: [Hamlib-developer] CI-V

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

On Tue, Jan 30, 2001 at 10:17:03PM +0100, Stephane Fillod wrote:
> >
> > I second this. Provide me with your postal address(es) and I will send 
> > you a copy of my CI-V.
> > 
> 
> If Nate doesn't mind, I'd love to receive a copy of your CI-V too. Thanks.

Actually, if Kai forwards the copies to you, Stephane, it would be more
useful as you're working on the actual code.  I'm working on a docbook 
manual this week and I'm going to try to have a couple of chapters
available for critique by week's end.

Right now I have no plans to include individual radio commands in the
Hamlib manual, however it might be a nice reference to have from the Web
pages, though.  However, I think some material is already on the Web so
links would suffice.  So I think Kai should refrain from sending me anything
by surface mail and contact you instead.  Thanks for the offer, Kai!

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

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

Kai Altenfelder wrote:
> 
> On Fri, Jan 26, Nate Bargmann wrote:
> 
> > > 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).
> > 
> > That's somewhat of a puzzling position to me.  I guess what you're
> > refering to is documentation already developed by Icom in electronic
> > form.  In that light their position is understandable.  If what they
> > mean is that we can't create our own documentation based on their spec
> > and release that under the GPL, then we have a problem.
> 
> No, the latter is not what I understood from my phone call. What they
> won't give us is a written permission to use their documentation neither
> as a printout nor electronically. But they provide us with printouts, if
> we wan't to have those.
> 
  I'm not sure about what are their fears. Did they understand that our
  goal is NOT to release their documentation under GPL (which would be
  a copyright violation), but only use a "printout" (electronically forms
  may leak) so we can develop the code controlling the radios they sell?
  And BTW, they already released somehow such documention for the PCR1000,
  available at http://www.philtered.net/icomlib.phtml

> > > 	http://www.plicht.de/
> > > 
> > > where you'll find documentation of CI-V in english language.
> > > 
	The Ekki's site (DF4OR) is a golden mine! Actually, I'm using it
	since I started to work on the Icom backend. The command list
	looks complete, but we still have no clue which rig supports
	which one of those. Also, the Hamlib project is referenced on Ekki's
	site.

> > So here is how I understand the situation.
> > 
> > Radio manufacturers publish the control command specifications and make
> > them public.
> > 
> > The radio manuals and/or the computer control specification documents
> > are likely copyrighted by the manufacturer.
> > 
> > We are allowed to create our own software under the GPL which uses these
> > commands (typically hex values with arguments sent over a serial line).
> > 
> > We should be able to document these commands and how our software
> > references them under the same license as our software, GPL.
> > 
> > We cannot use directly the copyrighted work of the manufacturer's
> > documentation in a GPL document unless they specifically allow that work
> > to be distributed under the GPL.
> 
> Agreed.
[snip]
> 

Agreed too. A mail is definitely less confusing than a phone call.

> Agreed. Additionally, every RX/TX comes with a printed manual that
> describes the protocol of its CAT interface (at least this applies for all
> my Yaesu radios).
> 
  Lucky you ;-)  mine is pretty scarce (Icom).

>
> > I think so long as we abide by the rules of "fair use" and give
> > attribution when we quote some published reference manual, we should be
> > fine with using the GPL.
>
> I second this. Provide me with your postal address(es) and I will send 
> you a copy of my CI-V.
> 

If Nate doesn't mind, I'd love to receive a copy of your CI-V too. Thanks.

Regards,
-- 
Stephane / F4CFE

Re: [Hamlib-developer] helper acript location

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

Frank Singleton wrote:
> I'll poke it in somewhere 
> Whats the GNU standard for "helper script" placement ?
> 

  I'd say the hamlib root directory or the doc/ subdir.
In fact, it doesn't matter much as this script would not be distributed.

Cheers,
-- 
Stephane / F4CFE

Re: [Hamlib-developer] CI-V

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

Sorry for the delay, I have been on a biz trip for two days.

On Fri, Jan 26, Nate Bargmann wrote:

> > 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).
> 
> That's somewhat of a puzzling position to me.  I guess what you're
> refering to is documentation already developed by Icom in electronic
> form.  In that light their position is understandable.  If what they
> mean is that we can't create our own documentation based on their spec
> and release that under the GPL, then we have a problem.

No, the latter is not what I understood from my phone call. What they
won't give us is a written permission to use their documentation neither
as a printout nor electronically. But they provide us with printouts, if
we wan't to have those.

> > 	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.
> 
> Clearly, then, they don't have a problem with independently produced
> documentation being made publicly available.

Right, that was my impression, too.


> So here is how I understand the situation.
> 
> Radio manufacturers publish the control command specifications and make
> them public.
> 
> The radio manuals and/or the computer control specification documents
> are likely copyrighted by the manufacturer.
> 
> We are allowed to create our own software under the GPL which uses these
> commands (typically hex values with arguments sent over a serial line).
> 
> We should be able to document these commands and how our software
> references them under the same license as our software, GPL.
> 
> We cannot use directly the copyrighted work of the manufacturer's
> documentation in a GPL document unless they specifically allow that work
> to be distributed under the GPL.

Agreed.

> The commands and their format are not themselves copyrighted (please
> correct me if I'm wrong), so our independent use of those commands and
> our independent documentation of those commands should be legal under
> "fair use."

Agreed, as we also could have re-engineered the command's protocol.

> Other radio control software has been released under the GPL and as far
> as I know, no one has been sued or threatened by the manufacturers as a
> result.

Agreed.

> We are not delving into the firmware of the radio, thus we don't violate
> any copyright the manufacturer holds to the code in the ROM.

Agreed. Additionally, every RX/TX comes with a printed manual that
describes the protocol of its CAT interface (at least this applies for all
my Yaesu radios).

> hamlib adds value to the existing base of radios out there as well as to
> those yet to be produced, so I don't foresee the manufacturers getting
> bent out of shape with this project or its documentation.
> 
> I think so long as we abide by the rules of "fair use" and give
> attribution when we quote some published reference manual, we should be
> fine with using the GPL.

I second this. Provide me with your postal address(es) and I will send 
you a copy of my CI-V.

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] RFC: API changes

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

Stephane Fillod wrote:

> So let's do it. Here's a non-exhaustive list of modification
> I'd like to see happening. Let me know what you think about it.
> 
> (1) Preamp & Attenuator ability:
> 
>     Goal: Describe what preamp and att levels are available. This is not
>           mandatory for rig control, but rather useful for a GUI.
>     Mod: add the following in caps:
> 
>         #define MAXDBLSTSIZ 8
> 
>         char preamp[MAXDBLSTSIZ];               /* in db, 0 terminated */
>         char attenuator[MAXDBLSTSIZ];           /* in db, 0 terminated */
> 
>     and for example, a backend having 6db, 10db and 20db support
>     would initialize this way:
> 
>         .... { 6, 10, 20, 0, }, ....
> 

Looks ok 

> (2) Announce and Antenna may not be set with rig_set_level.
>     I propose to create rig_set_ann/rig_get_ann and rig_set_ant/rig_get_ant,
>     which would be less confusing.
> 
> (3) VFO resolution
>     Goal: tell the resolution of set_freq. Most rigs have 10Hz, some
>     can do 1Hz. Question: does it depend on mode?
>     Mod: add the following field in caps:
> 
>         shortfreq_t resolution;         /* in Hz */
> 


A definite must !! Yes it is [can be] mode dependant.
Some sort of mode/min_res structure is applicable here..

perhaps something like..


struct fres_mode {
	mode_t mode,
	shortfreq_t fres,
}

typedef fres_mode fres_mode_t;


The we can ahve a list of these structs to handle
the various modes for example.

Then somewhere (in caps?) we put an array of
fres_mode_t

ala

{MODE_AM, 10},{MODE_CW, 1 },{MODE_FMN, 12.5}

If need finer resolution, just add band to the fres_mode
struct, or maybe freq range.

etc..


> (4) has_func, has_set_func
>     Goal: as for has_level/has_set_level, add a new field has_set_func
>           to tell what function is controlable.
>           Question: would has_get_func/has_set_func be better ?
>     Mod: add the following field in caps:
> 
>         setting_t has_set_func;
> 

> (5) Bank setting
>     Goal: add a few new API calls to handle memory banks
>     Mod: add new API calls plus their counterparts in the caps struct.
>          Question: what should be the type of bank_t ? Is it always
>          a number? We will need also a bank_qty field to tell how many
>          banks are availables.
> 
>         rig_get_bank(RIG *rig, vfo_t vfo, bank_t *bank);
>         rig_set_bank_name(RIG *rig, vfo_t vfo, bank_t bank, const char *name);
>         rig_get_bank_name(RIG *rig, vfo_t vfo, bank_t bank, char *name);
> 

Yep , need bank handling, fo a number of reasons

banks - freq ranges, avoid wearing out relays during scanning,


> (6) Frequency ranges and ITU regions
>     Goal: do you remember my mail on different ITU region support
>           pertaining to the rx_range_list and esp. the tx_range_list fields?
>           Let's have an example. In ITU region 1 (eg. Europe), the 2m band
>           is 144MHz to 146MHz, whereas in region 2, this is 144MHz to 148MHz.
>           Given a rig model, manufacturers would sell 2 different versions
>           in these regions. That's why I propose to add in the caps
>           the frequency ranges for all ITU regions.
>     Mod: I can see 2 solutions:
> 
>         /* first solution: */
>           freq_range_t rx_range_list1[FRQRANGESIZ];     /* region 1 */
>           freq_range_t tx_range_list1[FRQRANGESIZ];
>           freq_range_t rx_range_list2[FRQRANGESIZ];     /* region 2 */
>           freq_range_t tx_range_list2[FRQRANGESIZ];
> 
>         /* second solution: */
>           freq_range_t rx_range_list[FRQRANGESIZ][2];   /* 0->region 1, */
>           freq_range_t tx_range_list[FRQRANGESIZ][2];   /* 1->region 2  */
> 
>         and add a 'itu_region' field in rig_state. Actualy, we should
>         add frequency ranges in rig_state too, since one might want to
>         override the defaults (eg. a modified rig).
>         Ideas? Comments?

Option 2 looks ok to me.

> 
> (x) Scanning
>         We still haven't specified something for scan support.
>         I'll try to come up with a proposal soon. Any ideas/requirements
>         on the subject?


A few things to consider..

Scanning to know about bank definitions, (poor relays).
Frontend scanning, backend scanning (better).

scan_stop/start/status/pause/restart

scan rates,


Comments welcome :-)

-- 
Cheers / Frank 

73's de vk3fcs & km5ws

[Hamlib-developer] RFC: API changes

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

Hi there,

Adding new backends is an important task, but more important is 
the completion of the API specification. Actually, I'm ready
to add definition for ~40 Icom rigs, but maintenance in this
condition is a pain when a new field appears in the caps.
So let's do it. Here's a non-exhaustive list of modification
I'd like to see happening. Let me know what you think about it.


(1) Preamp & Attenuator ability:

    Goal: Describe what preamp and att levels are available. This is not
	  mandatory for rig control, but rather useful for a GUI.
    Mod: add the following in caps:

	#define MAXDBLSTSIZ 8

	char preamp[MAXDBLSTSIZ];		/* in db, 0 terminated */
	char attenuator[MAXDBLSTSIZ];		/* in db, 0 terminated */

    and for example, a backend having 6db, 10db and 20db support
    would initialize this way:

	.... { 6, 10, 20, 0, }, ....

(2) Announce and Antenna may not be set with rig_set_level.
    I propose to create rig_set_ann/rig_get_ann and rig_set_ant/rig_get_ant,
    which would be less confusing.

(3) VFO resolution
    Goal: tell the resolution of set_freq. Most rigs have 10Hz, some
    can do 1Hz. Question: does it depend on mode?
    Mod: add the following field in caps:

	shortfreq_t resolution;		/* in Hz */

(4) has_func, has_set_func
    Goal: as for has_level/has_set_level, add a new field has_set_func
	  to tell what function is controlable.
	  Question: would has_get_func/has_set_func be better ?
    Mod: add the following field in caps:

	setting_t has_set_func;

(5) Bank setting
    Goal: add a few new API calls to handle memory banks
    Mod: add new API calls plus their counterparts in the caps struct.
	 Question: what should be the type of bank_t ? Is it always
	 a number? We will need also a bank_qty field to tell how many
	 banks are availables.

	rig_get_bank(RIG *rig, vfo_t vfo, bank_t *bank);
	rig_set_bank_name(RIG *rig, vfo_t vfo, bank_t bank, const char *name);
	rig_get_bank_name(RIG *rig, vfo_t vfo, bank_t bank, char *name);

(6) Frequency ranges and ITU regions
    Goal: do you remember my mail on different ITU region support 
	  pertaining to the rx_range_list and esp. the tx_range_list fields?
	  Let's have an example. In ITU region 1 (eg. Europe), the 2m band
	  is 144MHz to 146MHz, whereas in region 2, this is 144MHz to 148MHz.
	  Given a rig model, manufacturers would sell 2 different versions
	  in these regions. That's why I propose to add in the caps
	  the frequency ranges for all ITU regions.
    Mod: I can see 2 solutions:

	/* first solution: */
	  freq_range_t rx_range_list1[FRQRANGESIZ];	/* region 1 */
  	  freq_range_t tx_range_list1[FRQRANGESIZ];
	  freq_range_t rx_range_list2[FRQRANGESIZ];	/* region 2 */
  	  freq_range_t tx_range_list2[FRQRANGESIZ];

	/* second solution: */
	  freq_range_t rx_range_list[FRQRANGESIZ][2];	/* 0->region 1, */
  	  freq_range_t tx_range_list[FRQRANGESIZ][2];	/* 1->region 2  */

	and add a 'itu_region' field in rig_state. Actualy, we should
	add frequency ranges in rig_state too, since one might want to
	override the defaults (eg. a modified rig).
	Ideas? Comments?

(x) Scanning
	We still haven't specified something for scan support.
	I'll try to come up with a proposal soon. Any ideas/requirements
	on the subject?


Feedback more than welcome!

Cheers,
-- 
Stephane / F4CFE

[Hamlib-developer] helper acript location

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

Stephane Fillod wrote:
> 
> > 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.
> 
I'll poke it in somewhere 
Whats the GNU standard for "helper script" placement ?

-- 
Cheers / Frank 

73's de vk3fcs & km5ws

Re: [Hamlib-developer] CI-V

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

On Fri, Jan 26, 2001 at 01:35:42PM +0100, Kai Altenfelder wrote:
> 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).

That's somewhat of a puzzling position to me.  I guess what you're
refering to is documentation already developed by Icom in electronic
form.  In that light their position is understandable.  If what they
mean is that we can't create our own documentation based on their spec
and release that under the GPL, then we have a problem.

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

Clearly, then, they don't have a problem with independently produced
documentation being made publicly available.

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

That's my interpretation.  Or we can produce our own documentation if
the previously referenced authors won't allow us to distribute their
work under the GPL with our project.

So here is how I understand the situation.

Radio manufacturers publish the control command specifications and make
them public.

The radio manuals and/or the computer control specification documents
are likely copyrighted by the manufacturer.

We are allowed to create our own software under the GPL which uses these
commands (typically hex values with arguments sent over a serial line).

We should be able to document these commands and how our software
references them under the same license as our software, GPL.

We cannot use directly the copyrighted work of the manufacturer's
documentation in a GPL document unless they specifically allow that work
to be distributed under the GPL.

The commands and their format are not themselves copyrighted (please
correct me if I'm wrong), so our independent use of those commands and
our independent documentation of those commands should be legal under
"fair use."

Other radio control software has been released under the GPL and as far
as I know, no one has been sued or threatened by the manufacturers as a
result.

We are not delving into the firmware of the radio, thus we don't violate
any copyright the manufacturer holds to the code in the ROM.

hamlib adds value to the existing base of radios out there as well as to
those yet to be produced, so I don't foresee the manufacturers getting
bent out of shape with this project or its documentation.

I think so long as we abide by the rules of "fair use" and give
attribution when we quote some published reference manual, we should be
fine with using the GPL.

Comments?

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] 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 -dn...@cv...:/cvsroot/hamlib co hamlib

Gave it a try and received the same error:

nomad:~/src $ cvs -z3 -dn...@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 -dn...@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