hamlib-developer — hamlib developers forum

[Hamlib-developer] Newbie Questions

[Aaron M. <tu...@am...>]

Hi,

I've just taken delivery of a nice Yaesu FT-8900R (quad band) and was loo=
king=20
for bits on the net when I stumbled upon your site.=20

I downloaded and (successfully!) installed the 1.1.3 version, but am miss=
ing a=20
cable to try anything with.  I will have to make one up soon.

While I have limited Linux experience, I have done some programming / web=
=20
stuff and am keen to help where I can.

* My radio does not support the "CAT" software that Yaesu has with some o=
f=20
their radios, and the Yaesu AMDS system does not yet support the FT8900 (=
I=20
suspect it will eventually.)  So, am I wasting my time without the CAT st=
uff,=20
or can the ham-libs talk to my radio?=20

Cheers, 73
Aaron ZL3UAR

Re: [Hamlib-developer] Licensing

[<si...@al...>]

Hi Stephane,

Yes, no problem with LGPL on the ft817 backend.. this is the only one I
did... not sure about the others :)

best,
-Chris
----- Original Message -----
> Message: 1
> Date: Sun, 17 Nov 2002 17:11:11 +0100
> From: Stephane Fillod <f8...@fr...>
> To: Hamlib developers <ham...@li...>
> Subject: Re: [Hamlib-developer] Licensing
>
> On Wed, Nov 13, 2002, Nate Bargmann wrote:
> > If I recall, Frank had agreed to the LGPL change and these files were
> > likely just an oversight.  I want to be sure until I change my files.
> > Perhaps we should carefully go through the remaining files and be sure
> > they are all LGPL before the 1.1.4 release.
>
> (fillods@charybde:hamlib)$ grep '"GPL"' */*.c
> gnuradio/gr.c:  .copyright =     "GPL",
> yaesu/ft100.c:  .copyright =            "GPL",
> yaesu/ft817.c:  .copyright =            "GPL",
> yaesu/ft920.c:  .copyright =          "GPL",
>
> - gnuradio is GPL, on library constraint.
> - IIRC, ft100 and ft817 were written by Chris AA1VL, cloning Frank's work
> before the licensing change.  I hope he'll be okay to relicense
> accordingly.
> - ft920: Nate, you decide :)
>
> > Some GPL and som LGPL code could cause projects such as Debian
> > heartburn.
>
> It should be fine, since the frontend library is LGPL, and backends
> are plugins, i.e. the end user is reponsible to load them or not,
> according to their license.
> Maybe it should also be possible to compile selectively backends.
>
>
> 73
> Stephane
>
>
>
> --__--__--
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer
>
>
> End of Hamlib-developer Digest

Re: [Hamlib-developer] Licensing

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

On Wed, Nov 13, 2002, Nate Bargmann wrote:
> If I recall, Frank had agreed to the LGPL change and these files were
> likely just an oversight.  I want to be sure until I change my files.
> Perhaps we should carefully go through the remaining files and be sure
> they are all LGPL before the 1.1.4 release.

	(fillods@charybde:hamlib)$ grep '"GPL"' */*.c
	gnuradio/gr.c:  .copyright =     "GPL",
	yaesu/ft100.c:  .copyright =            "GPL",
	yaesu/ft817.c:  .copyright =            "GPL",
	yaesu/ft920.c:  .copyright =          "GPL",

- gnuradio is GPL, on library constraint.
- IIRC, ft100 and ft817 were written by Chris AA1VL, cloning Frank's work
before the licensing change.  I hope he'll be okay to relicense
accordingly.
- ft920: Nate, you decide :)

> Some GPL and som LGPL code could cause projects such as Debian
> heartburn.

It should be fine, since the frontend library is LGPL, and backends
are plugins, i.e. the end user is reponsible to load them or not,
according to their license.
Maybe it should also be possible to compile selectively backends.


73
Stephane

Re: [Hamlib-developer] CI-V Standard for Icom radios

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

Hi!

On Thu, Nov 14, 2002, CONDOR wrote:
> I have a copy of this document.
> 
> It is about 10 years old, but the scheme is the same for the newer stuff.

Yeah, I think I have it already, thanks to the fine folks at SuSE.de.
Anyway, thank for proposing.

 
> Also, I noticed that an Icom R7000 would do things its not supposed to (from 
> time to time) over a control interface I have (old Dos program).
> 
> That is to say, it would suddenly go into modes and scanning that were not
> ostensibly available on the port.

Do you mean there's some hidden commands and features?
Have you tested already your IC R7000 with Hamlib? We'd be happy to
validate existing support.

> Let me know if you need it.. I can fax it someplace (after I dig it out of the 
> filing cabinet) -I also have the technical command specs for the Racal 
> RA6790/GM.

I'll take it. Thanks for the offer. Either fax or scanned pages.
Let me know when you're done tunneling :)


Cheers,
Stephane

Re: [Hamlib-developer] IC737 ?

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

On Sat, Nov 16, 2002, Sid Boyce wrote:
> 	I have an interface and grig up and running, but there is no ID for
> this rig. I can see stuff going back and forth on the interface and
> trace gives me the following:-
> read_string: timed out without reading a character
> TX 6 bytes
> 0000 fe fe 50 e0 03 fd
> RX 6 characters
> 0000 fe fe 50 e0 03 fd
> Also messages about not being able to get states.
> I presume this is because there is no valid ID for the IC737.

right.
However, I just checked in support for it in the CVS repository.
Have a look at the README.developer file if you're interested in
testing the development version.

In the mean time, you can still try to pass "-Ccivaddr=0x3c" to rigctl with
model I735 or better.


73
Stephane

[Hamlib-developer] IC737 ?

[Sid B. <sb...@bl...>]

	I have an interface and grig up and running, but there is no ID for
this rig. I can see stuff going back and forth on the interface and
trace gives me the following:-
read_string: timed out without reading a character
TX 6 bytes
0000 fe fe 50 e0 03 fd
RX 6 characters
0000 fe fe 50 e0 03 fd
Also messages about not being able to get states.
I presume this is because there is no valid ID for the IC737.
Sid.
-- 
Sid Boyce ... hamradio G3VBV ... Cessna/Warrior Pilot
Linux only shop

[Hamlib-developer] CI-V Standard for Icom radios

[CONDOR <si...@wo...>]

I have a copy of this document.

It is about 10 years old, but the scheme is the same for the newer stuff.

As you must know, they sort of treat their devices like they are on a net=
work.
Different hex addresses on the "bus" get their own messages.

Also, I noticed that an Icom R7000 would do things its not supposed to (f=
rom=20
time to time) over a control interface I have (old Dos program).

That is to say, it would suddenly go into modes and scanning that were no=
t
ostensibly available on the port.

Let me know if you need it.. I can fax it someplace (after I dig it out o=
f the=20
filing cabinet) -I also have the technical command specs for the Racal=20
RA6790/GM.

[Hamlib-developer] bring in morè - work less than

[<ghh...@em...>]

=

Dear, hamlib-developer
=


=

MAKE UP TO $100,000 EVERY YEAR
=

AND WORK LESS THAN 10 HOURS A WEEK
=


=

We know it sounds impossible, but it's happening today and here's where.
=


=

In the merchant business- What's that?? You know those little black boxes 
=

where businesses swipe your credit cards! That's called P.O.S. Point of 
=

Sale Technology! These numbers are verifiable.
=


=

repetentique
=


=

This multi-trillion dollar industry in which our business will supply 
=

credit cards, debit cards, check verification, funds transfer, prepaid 
=

cell phone, prepaid phone cards, bill payment and many other services 
=

for the consumer in the retail environment with plenty of growth ahead.
=


=

We will assist you in finding the ideal location in your area to maximize 
=

your profit potential. All you have to do is collect your earnings.
=


=

To find out how you can work less than 10 hours a week and make up 
=

to $100,000 each year with a relatively small investment.
=


=

CONTACT US NOW! HURRY LIMITED TERRITORIES ARE AVAILABLE.
=


=

http://new-biz-opportunities.com/Multi-Trillion-$$$-industry/index.htm
=


=

Merchant Services Business!
=

CLICK HERE FOR YOUR FREE INFORMATION
=


=

http://new-biz-opportunities.com/Multi-Trillion-$$$-industry/index.htm
=


=

YOU MUST BE 21 OR OLDER TO QUALIFY
=


=

8CB75687B6628BF5183EFB25D40639D304073CE110C675EE20CC0D3BDB0326D80933D742F519C2
=

XFDEQYEFMGUHWLBFVCGDQO
=


=

http://new-biz-opportunities.com/Multi-Trillion-$$$-industry/Opt-Out/index.htm

[Hamlib-developer] Licensing

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

Hi Stephane.

I see you updated the README.developer file and added:

! 8. Coding guidelines                                                          
!    Your code must be LGPL.                                                    
!                                                                               

which I have no problem with.  However, this is a question I was going
to bring up sooner or later.  Some of the files written by Frank
Singleton in the yaesu directory still have the GPL preamble and not the
LGPL preamble.

I was going to make this change in the ft920.c/.h files, but since I had
borrowed so heavily from Frank's ft747.c/.h files I was reluctant to do
so until I had discussed this matter.

If I recall, Frank had agreed to the LGPL change and these files were
likely just an oversight.  I want to be sure until I change my files.
Perhaps we should carefully go through the remaining files and be sure
they are all LGPL before the 1.1.4 release.

Some GPL and som LGPL code could cause projects such as Debian
heartburn.

I'm willing to make sure the yaesu subdirectory is up to snuff as I seem
to be the one working in it currently.

73, de Nate >>

-- 
 Wireless | Amateur Radio Station N0NB          | "We have awakened a
 Internet | n0...@ne...               | sleeping giant and
 Location | Bremen, Kansas USA EM19ov           | have instilled in him
  Amateur radio exams; ham radio; Linux info @  | a terrible resolve".
             http://www.qsl.net/n0nb/           | - Admiral Yamomoto

Re: [Hamlib-developer] @LTLIBOBJS@

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

On Wed, Nov 13, 2002, Robert Steinhäußer wrote:
> Nothing has changed here since a couple of months... I am running SuSE 8.0. 
> Versions are:
> 
> 	autoconf (GNU Autoconf) 2.52
> 	automake (GNU automake) 1.5
                                ^^^

I remember having problems with LTLIBOBJS on some automake 1.5 versions,
which was known btw to be, hmm, development work. Even 1.6 is considered
so. It looks like the 1.7 is a lot more stable, with features working as
expected. 
Okay, on some system this might be a pain to upgrade to a more recent
automake, but this what I would suggest you. I've just tested to compile
a fresh checkout, and got no problem at all (autoconf-2.54-1 and
automake1.7.1-1).

Note, --config-cache was needed with some unstable automake versions.
Since I'm not using it any more, some I'm going to update the README file.

Let me know if you're still stuck.

Stephane

Re: [Hamlib-developer] @LTLIBOBJS@

[Robert <ro...@st...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Nate.

> Looking at Robert's output, I'm curious as to whether you ran the
> configure script after autogen.sh?  I checked out a clean copy at 0311z
> Nov 13 and had no problems.  Here's what I did:
>=20
> chmod +x autogen.sh
> ./autogen.sh --disable-static --prefix=3D/usr/local
> ./configure --enable-maintainer-mode
> make
> su
> make uninstall
> make install

If you have a look inside autogen.sh you'll see that=20

=09$srcdir/configure --enable-maintainer-mode "$@"

is called at the end. It's not neccessary to run configure again manually=
=2E=20

BTW, when you run configure a second time, the flags you handed over the =
first=20
fime (with autogen.sh) get lost. That's why you still get the static libs=
=20
(/usr/local is default, so you won't notice that at all).

The `make uninstall` shouldn't be neccessary either. If you want to remov=
e the=20
old installation before installing the new one, call `make uninstall` in =
the=20
old tree (before checking out the new copy). But I never did so and had n=
o=20
problems so far.

73, Robert
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQE90lLxo4a8ramwUd8RAnqVAJ9xLurl2BCKS/0hAedEHrqInee0pQCghWHt
uxJFBaGmrMQvVSOVk7Ot9l4=3D
=3DLI34
-----END PGP SIGNATURE-----

Re: [Hamlib-developer] @LTLIBOBJS@

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

* Michael Smith <jam...@ea...> [2002 Nov 13 05:42 -0600]:
> 
> 
> I am having the same problem, and I have checked out a fresh tree (having rm'd the old) as of 0600 AM EST 11-13-2002.
> 

Hi Michael.

Looking at Robert's output, I'm curious as to whether you ran the
configure script after autogen.sh?  I checked out a clean copy at 0311z
Nov 13 and had no problems.  Here's what I did:

chmod +x autogen.sh
./autogen.sh --disable-static --prefix=/usr/local
./configure --enable-maintainer-mode
make
su
make uninstall
make install

I think the configure step accidentally was left out of the
README.developer file, but its use is implied in the text.  Will have to
fix that!

Incidentally, even passing --disable-static to ./autogen.sh the static
libs were still built here.  Perhaps this option should be passed to
./configure.  The --config-cache option causes an error on my system
(Debian Sarge) when passed to either autogen.sh or configure so I don't 
use it.

73, de Nate >>

-- 
 Wireless | Amateur Radio Station N0NB          | "We have awakened a
 Internet | n0...@ne...               | sleeping giant and
 Location | Bremen, Kansas USA EM19ov           | have instilled in him
  Amateur radio exams; ham radio; Linux info @  | a terrible resolve".
             http://www.qsl.net/n0nb/           | - Admiral Yamomoto

Re: [Hamlib-developer] @LTLIBOBJS@

[Michael S. <jam...@ea...>]

I am having the same problem, and I have checked out a fresh tree (having rm'd the old) as of 0600 AM EST 11-13-2002.


On Tue, 12 Nov 2002 15:44:51 +0100
Robert Steinhäußer <ro...@st...> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> since my cvs update yesterday, hamlib doesn't compile.
> 
> ./autogen is ok, then make says:
> 
> Making all in macros
> make[1]: Entering directory `/usr/src/hamlib/macros'
> make[1]: Nothing to be done for `all'.
> make[1]: Leaving directory `/usr/src/hamlib/macros'
> Making all in include
> make[1]: Entering directory `/usr/src/hamlib/include'
> cd .. \
>   && CONFIG_FILES= CONFIG_HEADERS=include/config.h \
>      /bin/sh ./config.status
> config.status: creating include/config.h
> config.status: include/config.h is unchanged
> make  all-am
> make[2]: Entering directory `/usr/src/hamlib/include'
> make[2]: Leaving directory `/usr/src/hamlib/include'
> make[1]: Leaving directory `/usr/src/hamlib/include'
> Making all in lib
> make[1]: Entering directory `/usr/src/hamlib/lib'
> make[1]: *** No rule to make target `@LTLIBOBJS@', needed by `libmisc.la'.  
> Stop.
> make[1]: Leaving directory `/usr/src/hamlib/lib'
> make: *** [all-recursive] Error 1
> 
> What's wrong?
> 
> 73, Robert DL1NC
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.0 (GNU/Linux)
> 
> iD8DBQE90RPmo4a8ramwUd8RAu6VAJ9NsG9zf0oBDvqFb8V0lrVf7vQIBACfaL1k
> B+X+2AWYqf2O59R9gQfQ0vo=
> =Kogh
> -----END PGP SIGNATURE-----
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

Re: Hamlib API docs (was: Re: [Hamlib-developer] Filter list)

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

Thanks for the documentation updates guys!

You don't know how much the new docs ease my finding things like the
proper constants to pass back to the frontend functions.

Keep up the great work!

73, de Nate >>

P.S. my ft920 backend work continues and I'm making good progress.

-- 
 Wireless | Amateur Radio Station N0NB          | "We have awakened a
 Internet | n0...@ne...               | sleeping giant and
 Location | Bremen, Kansas USA EM19ov           | have instilled in him
  Amateur radio exams; ham radio; Linux info @  | a terrible resolve".
             http://www.qsl.net/n0nb/           | - Admiral Yamomoto

Re: [Hamlib-developer] @LTLIBOBJS@

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

At times like this I save off any files I've been working on in the
anonymous CVS tree (anything I haven't commited or a test program I've
modified) and then blow away everything but the CVS directory under
hamlib.  I then run:

cvs -z3 update -Pd

to restore the tree.  It seems that major changes to the configuration
system causes all manner of problems so it seems best to start out
fresh.

The CVS manual doesn't say so explicitly, but as I read it I got the
impression it was best to delete the tree at the end of the day and
check out a new tree at the start of each day.

Since I'm no autoconf expert, this seems to work.  :-)

73, de Nate >>

-- 
 Wireless | Amateur Radio Station N0NB          | "We have awakened a
 Internet | n0...@ne...               | sleeping giant and
 Location | Bremen, Kansas USA EM19ov           | have instilled in him
  Amateur radio exams; ham radio; Linux info @  | a terrible resolve".
             http://www.qsl.net/n0nb/           | - Admiral Yamomoto

Re: [Hamlib-developer] @LTLIBOBJS@

[Robert <ro...@st...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephane Fillod schrieb:
> On Tue, Nov 12, 2002, Robert Steinh=E4u=DFer wrote:
> > since my cvs update yesterday, hamlib doesn't compile.
>
> Do you mean since my commit of yesterday?
> When was it last time before you ran autogen.sh ?

I ran `cvs update` on monday (many files had changed) and on tuesday (few=
=20
files had changed). Before that, I ran an update a week ago at most. I ha=
ve=20
this problem since monday. After an update, I always copy the tree and ru=
n an=20
`autogen.sh` and `make` and `make install` there.

> by any chance, what does "autoconf --version" and "automake --version"
> output?

Nothing has changed here since a couple of months... I am running SuSE 8.=
0.=20
Versions are:

=09autoconf (GNU Autoconf) 2.52
=09automake (GNU automake) 1.5

Any ideas?

73, Robert
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQE90ZMdo4a8ramwUd8RAvxkAKCXUC0xBhJFeyfoWj8q23XXcQHOZgCcCOQM
Bylfy+zUojyh7STfW7NJ7QM=3D
=3DARVv
-----END PGP SIGNATURE-----

Re: [Hamlib-developer] @LTLIBOBJS@

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

On Tue, Nov 12, 2002, Robert Steinhäußer wrote:
 
> since my cvs update yesterday, hamlib doesn't compile.

Do you mean since my commit of yesterday?
When was it last time before you ran autogen.sh ?

> 
> ./autogen is ok, then make says:
> 
> Making all in macros
> make[1]: Entering directory `/usr/src/hamlib/macros'
> make[1]: Nothing to be done for `all'.
> make[1]: Leaving directory `/usr/src/hamlib/macros'
> Making all in include
> make[1]: Entering directory `/usr/src/hamlib/include'
> cd .. \
>   && CONFIG_FILES= CONFIG_HEADERS=include/config.h \
>      /bin/sh ./config.status
> config.status: creating include/config.h
> config.status: include/config.h is unchanged
> make  all-am
> make[2]: Entering directory `/usr/src/hamlib/include'
> make[2]: Leaving directory `/usr/src/hamlib/include'
> make[1]: Leaving directory `/usr/src/hamlib/include'
> Making all in lib
> make[1]: Entering directory `/usr/src/hamlib/lib'
> make[1]: *** No rule to make target `@LTLIBOBJS@', needed by `libmisc.la'.  

by any chance, what does "autoconf --version" and "automake --version"
output?
Does any one else experience the same problem?


Stephane

Re: Hamlib API docs (was: Re: [Hamlib-developer] Filter list)

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

On Sat, Nov 09, 2002, Alexandru Csete wrote:
> I have now added some doxygen comments to rotator.h and rotlist.h. It
> basically doubled the file sizes, but I guess there's not much to do
> about that. For me it looks quite all right, except that structure
> members are denoted as class members, ie. rot_caps::cfgparams. I hope
> there is a sensible way to change that at some point. I also hope, that
> someone who has written the code, will check the contents to make sure,
> that I have not misunderstood or missed anything.

Good job Alex.
I've copy pasted what you've done to document the rig API. It's not complete
yet, but it's a start. I still have to sort out the grouping, because
browsing by file is not the better approach.

If something is not in the documentation, it's time to ask for it!

Cheers,
Stephane

[Hamlib-developer] @LTLIBOBJS@

[Robert <ro...@st...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

since my cvs update yesterday, hamlib doesn't compile.

=2E/autogen is ok, then make says:

Making all in macros
make[1]: Entering directory `/usr/src/hamlib/macros'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/usr/src/hamlib/macros'
Making all in include
make[1]: Entering directory `/usr/src/hamlib/include'
cd .. \
  && CONFIG_FILES=3D CONFIG_HEADERS=3Dinclude/config.h \
     /bin/sh ./config.status
config.status: creating include/config.h
config.status: include/config.h is unchanged
make  all-am
make[2]: Entering directory `/usr/src/hamlib/include'
make[2]: Leaving directory `/usr/src/hamlib/include'
make[1]: Leaving directory `/usr/src/hamlib/include'
Making all in lib
make[1]: Entering directory `/usr/src/hamlib/lib'
make[1]: *** No rule to make target `@LTLIBOBJS@', needed by `libmisc.la'=
=2E =20
Stop.
make[1]: Leaving directory `/usr/src/hamlib/lib'
make: *** [all-recursive] Error 1

What's wrong?

73, Robert DL1NC
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQE90RPmo4a8ramwUd8RAu6VAJ9NsG9zf0oBDvqFb8V0lrVf7vQIBACfaL1k
B+X+2AWYqf2O59R9gQfQ0vo=3D
=3DKogh
-----END PGP SIGNATURE-----

[Hamlib-developer] Mapping the FT-920 to vfo_t

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

I'm having a bit of trouble trying to map the various VFO combinations
in the FT-920 to Hamlib's set of defined VFOs.  Compared to the '920,
Hamlib's set of defined VFOs in rig.h are quite limited.  Here's my
problem.

The '920 has the appearance of a main band and a sub band.  However, the
sub band display isn't really a sub band as there is no dual receive 
capability in the radio.  The sub band always acts as the VFO B
frequency display.

The main band will display the frequency of VFO A, when the VFO icon is
displayed.  It will also display the selected memory channel when the
MEM icon is displayed and will automatically update the display and jump
into MEM TUNE mode when an action is taken to change the frequency on
the radio.

There are two CAT commands that return similar data.  0x10 P1 = 02 will
return 2 14 byte records that contain the current frequency and mode data 
for each display, main and sub whether in VFO, MEM, or MEM TUNE modes.
The other command, 0x10 P1 = 03, explicitly returns the data for VFO A
and VFO B.  Now keep in mind that with either command the frequency in
the second 14 byte record is considered VFO B by the radio regardless of
whether it was a VFO, MEM, or MEM TUNE frequency in the main display
before the A<>B button was pressed (or the set VFO B command was sent to
the rig--more on that later).

So my first question is, how do I label the current frequency display
mode in Hamlib so an application has an idea whether it is looking at a
VFO, MEM, or MEM TUNE frequency?  I can test the status flags for these
three values plus QMB (Quick Memory Bank) and General Coverage Reception
to learn what the frequency display is related to.  This is required as
one can change the VFO A frequency via the CAT command without changing 
the displayed frequency if the main band is in anything but VFO mode.

Confused yet?

I think the solution is the addition of a few more VFO #define constants
in rig.h, something applications can test to properly associate the 
display frequency.

On a related note, there is a peculiarity with the '920 and the set_vfo
command.  Any time 920_set_vfo is called and the vfo variable is set to
VFOB (which I only found after digging through the rigctl source leading
me to misc.c where this constant is defined...grrrrr) and the associate
command is sent to the radio, the '920 will swap main and sub displays.
A successive call with VFOA passed will not change any state in the
radio, but will change Hamlib's idea of the current VFO.

So, using rigctl, if I wish to query VFO B's frequency I must set the
VFO to B which now swaps the main and sub displays in order to get
Hamlib (or is it rigctl) to pass VFOB to 920_set_vfo.  But now, instead
of VFO B, I'm reading the former main band frequency.  I can do one of
two things here.  Either call 920_set_vfo with VFOB again to swap the
frequency back or jump back to reading VFO A by calling 920_set_vfo with
VFOA.

Ready to delete this mail yet?

Somehow, 920_get_freq needs to be told what VFO frequency to read
without resorting to 920_set_vfo first.  So the application needs to be
able to set the vfo variable it passes to Hamlib.  Am I confused?

I gotta go to work...

73, de Nate >>

-- 
 Wireless | Amateur Radio Station N0NB          | "We have awakened a
 Internet | n0...@ne...               | sleeping giant and
 Location | Bremen, Kansas USA EM19ov           | have instilled in him
  Amateur radio exams; ham radio; Linux info @  | a terrible resolve".
             http://www.qsl.net/n0nb/           | - Admiral Yamomoto

[Hamlib-developer] Information hamlib-developer

[Michell A. <Sha...@sv...>]

PEhUTUw+PFAgQUxJR049Q0VOVEVSPjxGT05UICBTSVpFPTYgUFRTSVpFPTI0PjxCPmhhbWxp
Yi1kZXZlbG9wZXIsPEJSPg0KPC9GT05UPjxGT05UICBDT0xPUj0iI2ZmMDAwMCIgQkFDSz0i
I2ZmZmZmZiIgc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6ICNmZmZmZmYiIFNJWkU9NiBQVFNJ
WkU9MjQgRkFNSUxZPSJTQU5TU0VSSUYiIEZBQ0U9IkFyaWFsIiBMQU5HPSIwIj48VT5Zb3Ug
aGF2ZSBiZWVuIGFwcHJvdmVkLjxCUj4NCjwvRk9OVD48Rk9OVCAgQ09MT1I9IiNmZjAwMDAi
IEJBQ0s9IiNmZmZmZmYiIHN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiAjZmZmZmZmIiBTSVpF
PTUgUFRTSVpFPTE4IEZBTUlMWT0iU0FOU1NFUklGIiBGQUNFPSJBcmlhbCIgTEFORz0iMCI+
PC9VPkNhc2ggR3JhbnQgQW1vdW50OjxCUj4NCjwvRk9OVD48Rk9OVCAgQ09MT1I9IiMwMDAw
ZmYiIEJBQ0s9IiNmZmZmZmYiIHN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiAjZmZmZmZmIiBT
SVpFPTcgUFRTSVpFPTM2IEZBTUlMWT0iU0FOU1NFUklGIiBGQUNFPSJBcmlhbCIgTEFORz0i
MCI+JDEwLDAwMC0kNSwwMDAsMDAwPEJSPg0KPC9GT05UPjxGT05UICBDT0xPUj0iIzAwMDAw
MCIgQkFDSz0iI2ZmZmZmZiIgc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6ICNmZmZmZmYiIFNJ
WkU9NiBQVFNJWkU9MjQgRkFNSUxZPSJTQU5TU0VSSUYiIEZBQ0U9IkFyaWFsIiBMQU5HPSIw
Ij48ST48VT5EaWQgWW91IEtub3c/PEJSPg0KPC9GT05UPjxGT05UICBDT0xPUj0iIzAwMDAw
MCIgQkFDSz0iI2ZmZmZmZiIgc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6ICNmZmZmZmYiIFNJ
WkU9NSBQVFNJWkU9MTggRkFNSUxZPSJTQU5TU0VSSUYiIEZBQ0U9IkFyaWFsIiBMQU5HPSIw
Ij48L0I+PC9JPjwvVT4tRWFjaCBZZWFyIHRoZSBVLlMuIEdvdmVybWVudCBHaXZlcyBhd2F5
IEJJTExJT05TIGluIGNhc2ggZ3JhbnRzPzxCUj4NCi1UaGVyZSZuYnNwOyBhcmUgTm8gc3Bl
Y2lhbCByZXF1aXJlbWVudHMgdG8gb2J0YWluIHRoZXNlIGdyYW50cy48QlI+DQotVGhlc2Ug
YXJlIEZyZWUgQ2FzaCBHcmFudHMgVGhhdCB5b3UgTkVWRVIgaGF2ZSB0byByZXBheSE8QlI+
DQo8QlI+DQo8L0ZPTlQ+PEZPTlQgIENPTE9SPSIjMDAwMDAwIiBCQUNLPSIjZmZmZmZmIiBz
dHlsZT0iQkFDS0dST1VORC1DT0xPUjogI2ZmZmZmZiIgU0laRT02IFBUU0laRT0yNCBGQU1J
TFk9IlNBTlNTRVJJRiIgRkFDRT0iQXJpYWwiIExBTkc9IjAiPmhhbWxpYi1kZXZlbG9wZXIs
WW91IFF1YWxpZnkhPEJSPg0KPC9GT05UPjxGT05UICBDT0xPUj0iIzAwMDBmZiIgQkFDSz0i
I2ZmZmZmZiIgc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6ICNmZmZmZmYiIFNJWkU9NyBQVFNJ
WkU9MzYgRkFNSUxZPSJTQU5TU0VSSUYiIEZBQ0U9IkFyaWFsIiBMQU5HPSIwIj48QSBIUkVG
PSJodHRwOi8vcmQueWFob28uY29tLzU0NjU0Ni8qaHR0cDovL3d3dy5zdXBlcmZyZWVtYWls
LmNvbS9ncmFudC9zaGVsbHltZS9pbmRleC5hc3A/Y3ZuPSRkelNbT1o5Rk5GU3N8RkFpU1s9
Mz0wPXNuQSxGX3NBIEYwOEYzIj5DbGljayBIZXJlPC9BPjwvRk9OVD48Rk9OVCAgQ09MT1I9
IiMwMDAwMDAiIEJBQ0s9IiNmZmZmZmYiIHN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiAjZmZm
ZmZmIiBTSVpFPTUgUFRTSVpFPTE4IEZBTUlMWT0iU0FOU1NFUklGIiBGQUNFPSJBcmlhbCIg
TEFORz0iMCI+PEJSPg0KPC9GT05UPjxGT05UICBDT0xPUj0iI2ZmMDAwMCIgQkFDSz0iI2Zm
ZmZmZiIgc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6ICNmZmZmZmYiIFNJWkU9NyBQVFNJWkU9
MzYgRkFNSUxZPSJTQU5TU0VSSUYiIEZBQ0U9IkFyaWFsIiBMQU5HPSIwIj48Qj5MaW1pdGVk
IFRpbWUgT2ZmZXI8L0ZPTlQ+PEZPTlQgIENPTE9SPSIjMDAwMGZmIiBCQUNLPSIjZmZmZmZm
IiBzdHlsZT0iQkFDS0dST1VORC1DT0xPUjogI2ZmZmZmZiIgU0laRT03IFBUU0laRT0zNiBG
QU1JTFk9IlNBTlNTRVJJRiIgRkFDRT0iQXJpYWwiIExBTkc9IjAiPjxCUj4NCjwvRk9OVD48
Rk9OVCAgQ09MT1I9IiNmZjAwMDAiIEJBQ0s9IiNmZmZmZmYiIHN0eWxlPSJCQUNLR1JPVU5E
LUNPTE9SOiAjZmZmZmZmIiBTSVpFPTYgUFRTSVpFPTI0IEZBTUlMWT0iU0FOU1NFUklGIiBG
QUNFPSJBcmlhbCIgTEFORz0iMCI+PC9CPjxCUj4NCjxCUj4NCjwvUD48L0ZPTlQ+PC9IVE1M
PiAgICAgDQogICAgICAgICAgICAgICAgICAgIA==

Re: Hamlib API docs (was: Re: [Hamlib-developer] Filter list)

[Alexandru C. <al...@ph...>]

Greetings,

I have now added some doxygen comments to rotator.h and rotlist.h. It
basically doubled the file sizes, but I guess there's not much to do
about that. For me it looks quite all right, except that structure
members are denoted as class members, ie. rot_caps::cfgparams. I hope
there is a sensible way to change that at some point. I also hope, that
someone who has written the code, will check the contents to make sure,
that I have not misunderstood or missed anything.

Alex

On Fri, 2002-11-08 at 22:32, Stephane Fillod wrote:
> 
> On Fri, Nov 08, 2002, Alexandru Csete wrote:
> > I've ben playing a little with doxygen to see how it works with data
> > structures. I could begin with the smaller files, like rotator.h and
> > rotlist.h, and, if everything goes well, go on with rig.h.
> > 
> > What do you think?
> 
> Oh yes! please go ahead! Actually, I have already some notes for rig.h,
> but not in doxygen format. I'll see how you proceed for rotator.h, and
> do the same for rig.h. Some data struct can be tricky (but common sense),
> we have to explain how to use them, from a lib user point of view, 
> and also from a backend implementer point of view.
> 
> 73
> Stephane
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm 
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer
> 

Re: [Hamlib-developer] Problems with Perl language interface ... and Debian

[Joop S. <pa...@de...>]

On Fri, 8 Nov 2002 22:55:46 +0100
Stephane Fillod <f8...@fr...> wrote:

> On Fri, Nov 08, 2002, Joop Stakenborg wrote:
> > So the FAQ would be something like:
> > 
> > - Where are the perl and tcl bindings?
> > 
> > (Does anyone know a better word for binding?)
> > 
> > And the answer would explain what swig is and what versions you need.
> > This only relates to the CVS version of course.
> 
> Okay. Acutally, I expected to fix the installation in the coming weeks.
> And fix the binding plugin names also. For this matter, I may have to
> create subdirs because perl and tcl want to name it the same way
> 'hamlib.so'.
> 

Okay, I will add the question when the swig stuff works.

> > Ehm, I still see perl/Makefile.PL and perl/Makefile.am, they need to
> > be kicked ....
> 
> yep, but before doing that, I'd like to reuse the Makefile.PL and part
> of Makefile.am to let perl handle the plugin installation directory itself.
> It might change from one version of perl to another. 
> Anyone has advices to how to handle the plugin name clash and the
> installation destination?
> 
>  
> > I couldn't resist, have fixed the debian build stuff.
> > You need to 'apt-get install fakeroot debhelper dpkg-dev autoconf automake1.7 libtool doxygen'
> > and then 'fakeroot debian/rules binary'.
> 
> great!
> FYI, Ernie has made a .deb for 1.1.3 already, and it's in the
> download page on sourceforge. I've heard Terry was about to update 
> the debian unstable. That'd good to merge all the build scripts.
> Note: assuming you have a tar.gz obtained by a "make dist", there
> shouln't be any need for autoconf, automake1.7 and libtool. And we can
> even arrange to generate doxygen/dockbook documentation at "make dist"
> time (I've heard sh and hurd platforms don't have doxygen yet).
>  

Fixed in CVS, I will try to keep track of the hamlib changes and adapt
the debian tree when needed. Doxygen will be removed from debian/control
lateron.

> Thanks for the commits
> Stephane
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm 
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer
> 

Re: [Hamlib-developer] Problems with Perl language interface ... and Debian

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

On Fri, Nov 08, 2002, Joop Stakenborg wrote:
> So the FAQ would be something like:
> 
> - Where are the perl and tcl bindings?
> 
> (Does anyone know a better word for binding?)
> 
> And the answer would explain what swig is and what versions you need.
> This only relates to the CVS version of course.

Okay. Acutally, I expected to fix the installation in the coming weeks.
And fix the binding plugin names also. For this matter, I may have to
create subdirs because perl and tcl want to name it the same way
'hamlib.so'.

> Ehm, I still see perl/Makefile.PL and perl/Makefile.am, they need to
> be kicked ....

yep, but before doing that, I'd like to reuse the Makefile.PL and part
of Makefile.am to let perl handle the plugin installation directory itself.
It might change from one version of perl to another. 
Anyone has advices to how to handle the plugin name clash and the
installation destination?

 
> I couldn't resist, have fixed the debian build stuff.
> You need to 'apt-get install fakeroot debhelper dpkg-dev autoconf automake1.7 libtool doxygen'
> and then 'fakeroot debian/rules binary'.

great!
FYI, Ernie has made a .deb for 1.1.3 already, and it's in the
download page on sourceforge. I've heard Terry was about to update 
the debian unstable. That'd good to merge all the build scripts.
Note: assuming you have a tar.gz obtained by a "make dist", there
shouln't be any need for autoconf, automake1.7 and libtool. And we can
even arrange to generate doxygen/dockbook documentation at "make dist"
time (I've heard sh and hurd platforms don't have doxygen yet).
 
Thanks for the commits
Stephane

Re: Hamlib API docs (was: Re: [Hamlib-developer] Filter list)

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

On Fri, Nov 08, 2002, Alexandru Csete wrote:
> I've ben playing a little with doxygen to see how it works with data
> structures. I could begin with the smaller files, like rotator.h and
> rotlist.h, and, if everything goes well, go on with rig.h.
> 
> What do you think?

Oh yes! please go ahead! Actually, I have already some notes for rig.h,
but not in doxygen format. I'll see how you proceed for rotator.h, and
do the same for rig.h. Some data struct can be tricky (but common sense),
we have to explain how to use them, from a lib user point of view, 
and also from a backend implementer point of view.

73
Stephane