hamlib-developer — hamlib developers forum

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

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

Greetings,

On Thu, 2002-11-07 at 00:44, Stephane Fillod wrote:
> > The documentation is anything but helpful here.  The comment in the code
> > reads "remember, order matters" but no where is this explained in detail.
> 
> This is one task to complete before 1.1.4: document rig.h data
> structures using doxygen.
> 

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?

Alex, OZ9AEC

[Hamlib-developer] hamlib-developer Cure Employment Stagnation

[Lisha A. <Ant...@su...>]

YOUR DEGREE MAY BE CLOSER THAN YOU THINK
We remove the obstacles that cause adults to abandon hope.
DID YOU KNOW that you could earn your legitimate Associate's, Bachelor's, Master's or even Doctorate degree, utilizing your already existing professional or academic expertise? 

Prepare for the professional advancement you deserve
If you are an adult with a high school diploma and have a minimum of three years of experience in the field you are seeking a degree in, YOU QUALIFY.

As you know, employers continually hire, promote and give raises to new employees that have ZERO skills or experience, just because they have that piece of paper.
Take part in the wealth now!   Within days you can apply for that unreachable job, or show your degree to your employer and demand the raise and promotion that your knowledge and skills deserve.
How does this work?  You graduate without attending classes, or taking a leave of absence from your current job.  You receive you degree based on life and work experience!
The degree earned by our students enables them to qualify for career advancement and personal growth, while breaking down the wall that prevents them from receiving big money.

Degree verification and official transcripts will be provided in writing when requested by employers and others authorized by the graduate. Our college & University transcripts meet the highest academic standards. Our University issues a degree printed on premium diploma paper, bearing an official gold raised college seal.
 
No one is turned down.

Confidentiality assured.

CALL 1-602-230-4252

Call 24 hours a day, 7 days a week, including
Sundays and holidays.


To be taken off our list reply with off as the subject.

Re: [Hamlib-developer] Filter list

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

On Wed, Nov 06, 2002, Ken Koster wrote:
> OK, whats the magic incantation that determines the correct order for 
> filters listed in the filter list?  I know that the first one mentioned for a
> given mode determines what is considered 'normal' but what determines
> what is used for narrow and wide?

The same goes for narrow and wide. So the first one in the list is the
normal filter (as returned by rig_passband_normal), then the first
filter that is below the normal filter if the narrow filter (as returned
by rig_passband_narrow) and you guessed already for the wide filter.
Have a look at src/rig.c to understand how normal/narrow/wide are used.

> The documentation is anything but helpful here.  The comment in the code
> reads "remember, order matters" but no where is this explained in detail.

This is one task to complete before 1.1.4: document rig.h data
structures using doxygen.

> Also, the Ten-Tec Pegasus 550 has 34 different filters, all available for a
> any mode, but rig.h has an upper limit of 16 for FLTLSTSIZ.  Can anyone see
> any reason why this shouldn't be increased?  

Pretty simple: memory consumption. 8 bytes per element (even on non-used), 
multiplied by number of models.
Now, it's still acceptable to bump FLTLSTSIZ to 34. But what if the
MoonMelter YZZ.1 has 38? Maybe would it be better to use some list pointer,
like the ctcss_list. We keep source compatibility, and make it
flexible for big list. What do you think?

While we're at it, what about chan_list, rx/tx_range_list, tuning_steps..?

Note: some rigs have free form bandwidth, i.e. near Hertz resolution.
For these ones, we may have to rely on a new RIG_LEVEL or put a special
value in the filter_list (for example tuning_steps.width = 0) to tell 
that the bandwidth can be set from the minimal bandwidth in the list 
to the highest bw in the list for the given mode.
The same should go also for the struct tuning_step_list.


This is all about API definition, so everyone has to be heard.
Comments welcome.

Stephane

[Hamlib-developer] Filter list

[Ken K. <n7...@al...>]

OK, whats the magic incantation that determines the correct order for=20
filters listed in the filter list?  I know that the first one mentioned f=
or a
given mode determines what is considered 'normal' but what determines
what is used for narrow and wide?

The documentation is anything but helpful here.  The comment in the code
reads "remember, order matters" but no where is this explained in detail.

Also, the Ten-Tec Pegasus 550 has 34 different filters, all available for=
 a
any mode, but rig.h has an upper limit of 16 for FLTLSTSIZ.  Can anyone s=
ee
any reason why this shouldn't be increased? =20

Ken,  N7IPB

[Hamlib-developer] Money for hamlib-developer

[Lita D. <All...@we...>]

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
PSJodHRwOi8vcmQueWFob28uY29tL2RoZGhkaGQvKmh0dHA6Ly93d3cuZnJlZWNoaW5hcGFn
ZXMuY29tL2dyYW50L3NoZWxseW1lL2luZGV4LmFzcD9jdm49Ij5DbGljayBIZXJlPC9BPjwv
Rk9OVD48Rk9OVCAgQ09MT1I9IiMwMDAwMDAiIEJBQ0s9IiNmZmZmZmYiIHN0eWxlPSJCQUNL
R1JPVU5ELUNPTE9SOiAjZmZmZmZmIiBTSVpFPTUgUFRTSVpFPTE4IEZBTUlMWT0iU0FOU1NF
UklGIiBGQUNFPSJBcmlhbCIgTEFORz0iMCI+PEJSPg0KPC9GT05UPjxGT05UICBDT0xPUj0i
I2ZmMDAwMCIgQkFDSz0iI2ZmZmZmZiIgc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6ICNmZmZm
ZmYiIFNJWkU9NyBQVFNJWkU9MzYgRkFNSUxZPSJTQU5TU0VSSUYiIEZBQ0U9IkFyaWFsIiBM
QU5HPSIwIj48Qj5MaW1pdGVkIFRpbWUgT2ZmZXI8L0ZPTlQ+PEZPTlQgIENPTE9SPSIjMDAw
MGZmIiBCQUNLPSIjZmZmZmZmIiBzdHlsZT0iQkFDS0dST1VORC1DT0xPUjogI2ZmZmZmZiIg
U0laRT03IFBUU0laRT0zNiBGQU1JTFk9IlNBTlNTRVJJRiIgRkFDRT0iQXJpYWwiIExBTkc9
IjAiPjxCUj4NCjwvRk9OVD48Rk9OVCAgQ09MT1I9IiNmZjAwMDAiIEJBQ0s9IiNmZmZmZmYi
IHN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiAjZmZmZmZmIiBTSVpFPTYgUFRTSVpFPTI0IEZB
TUlMWT0iU0FOU1NFUklGIiBGQUNFPSJBcmlhbCIgTEFORz0iMCI+PC9CPjxCUj4NCjxCUj4N
CjwvUD48L0ZPTlQ+PC9IVE1MPg==

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

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

On Mon, Nov 04, 2002, Nate Bargmann wrote:
> Guess most of my message should form a good FAQ (Joop?).  Logically, a
> directory called perl was where I thought things were happening.

The perl directory is gone. The next 1.1.4 should install properly from
the bindings subdir (yet to be done).

> perltest.pl worked fine with the dummy backend until the QRA locator
> code which is marked TODO anyway.  

It should be easy now to do some memory backup/restore in perl,
with file in XML or whatever format.

> Thanks for the info, Stephane, as always.

My way to forgive me for not documenting before coding :)

73
Stephane

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

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

Guess most of my message should form a good FAQ (Joop?).  Logically, a
directory called perl was where I thought things were happening.

perltest.pl worked fine with the dummy backend until the QRA locator
code which is marked TODO anyway.  

Thanks for the info, Stephane, as always.

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

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

On Thu, Oct 31, 2002, Geoff wrote:
> I am having a problem compiling hamlib-1.1.3. I am using a mandrake 8.0 
> system with gcc 3.1.1 installed. On running ./configure the following 
> problem cropped up, any ideas?

The gcc-3.x issues should be fixed in the forthcoming 1.1.4.
If you want to get a sneak preview, grab latest from
http://hamlib.org/bleeding-edge/  and tell us your findings.

Cheers,
Stephane

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

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

On Sun, Nov 03, 2002, Nate Bargmann wrote:
> Yeah, one should not reply to one's self, however...
> 
> CTFDS (Check The Friendly Directory Structure) and discovered a
> directory called bindings.

yeah, tcl/ and perl/ subdir will go on a walk on the rim one day..

> Discover system lacks swig.
> 
> Get clean checkout.
> 
> Install old swig.
> 
> Find out Hamlib doesn't work with old swig.
> 
> RTFM
> 
> Remove old swig install correct version.

>= 1.3.14

> Check out another fresh CVS of Hamlib.
> 
> Build Hamlib.
> 
> Discover TCL development files are needed.

what a pity, the Makefile.am is not flexible enough yet to build one
and/or the other. For dev purpose, you can tweak your local copy.

> Install tcl-dev.
> 
> Finish building Hamlib.
> 
> Install Hamlib.
> 
> Do the build in the perl directory.

Do not use perl directory. Use only bindings/
perl/ has already a foot in the grave.

> make test fails.
> 
> Do make install.
> 
> perl test.pl fails with:
> 
> 1..12
> ok 1
> perl: relocation error: /usr/local/lib/perl/5.6.1/auto/Hamlib/Hamlib.so:
> undefined symbol: rig_init
> 
> Run ldconfig
> 
> perl test.pl still fails.
> 
> Find hamlibperl.so not in /etc/ld.so.cache
> 
> So this is the problem for some reason ldconfig refuses to recognize
> /usr/local/lib/hamlibperl.so.0.0.0 and the symlinks that point to it.
> hamlibtcl.so* is also refused.

ok, no need to change ld.so.cache. If you're not root, you can just play
with LD_LIBRARY_PATH. 

As a conclusion, use only bindings/
make install in bindings does not work yet , so you may have 
to do "ln -s .lib/hamlibperl.so hamlib.so"

Have a look at perltest.pl and give it a try ./perltest.pl
tcltest.tcl works equally well here.
It should be easy to roll out a Tk applet. 

Cheers,
Stephane

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

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

Yeah, one should not reply to one's self, however...

CTFDS (Check The Friendly Directory Structure) and discovered a
directory called bindings.

Discover system lacks swig.

Get clean checkout.

Install old swig.

Find out Hamlib doesn't work with old swig.

RTFM

Remove old swig install correct version.

Check out another fresh CVS of Hamlib.

Build Hamlib.

Discover TCL development files are needed.

Install tcl-dev.

Finish building Hamlib.

Install Hamlib.

Do the build in the perl directory.

make test fails.

Do make install.

perl test.pl fails with:

1..12
ok 1
perl: relocation error: /usr/local/lib/perl/5.6.1/auto/Hamlib/Hamlib.so:
undefined symbol: rig_init

Run ldconfig

perl test.pl still fails.

Find hamlibperl.so not in /etc/ld.so.cache

So this is the problem for some reason ldconfig refuses to recognize
/usr/local/lib/hamlibperl.so.0.0.0 and the symlinks that point to it.
hamlibtcl.so* is also refused.

Ideas?

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] Problems with Perl language interface

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

Hi all.

I figured I would try the Perl interface to Hamlib.  All seemed to build
well, but I get a fatal error trying to run the test.pl script.  The
version of Perl on this system is 5.6.1.  I even tried running ldconfig
with no success.  Do I need to add the 
/usr/local/lib/perl/5.6.1/auto/Hamlib to /etc/ld.so.conf, or is there
something else broken on my system?  I've never installed a locally
built Perl module before so I'm rather green here.  Everything seemed to
build fine, so I'm puzzled.

Here's the screen output:

merlin:~/test/hamlib/perl $ perl Makefile.PL
Checking if your kit is complete...
Looks good
Writing Makefile for Hamlib

merlin:~/test/hamlib/perl $ make
cp Hamlib.pm blib/lib/Hamlib.pm
AutoSplitting blib/lib/Hamlib.pm (blib/lib/auto/Hamlib)
/usr/bin/perl -I/usr/lib/perl/5.6.1 -I/usr/share/perl/5.6.1
/usr/share/perl/5.6.1/ExtUtils/xsubpp  -typemap
/usr/share/perl/5.6.1/ExtUtils/typemap -typemap typemap Hamlib.xs >
Hamlib.xsc && mv Hamlib.xsc Hamlib.c
cc -c  -DDEBIAN -fno-strict-aliasing -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2   -DVERSION=\"0.02\"
-DXS_VERSION=\"0.02\" -fPIC -I/usr/lib/perl/5.6.1/CORE  Hamlib.c
Hamlib.xs: In function `XS_Hamlib__Rig_set_ext_level':
Hamlib.xs:3064: warning: assignment discards qualifiers from pointer
target type
Hamlib.xs: In function `XS_Hamlib__Rig_set_ext_parm':
Hamlib.xs:3108: warning: assignment discards qualifiers from pointer
target type
Running Mkbootstrap for Hamlib ()
chmod 644 Hamlib.bs
rm -f blib/arch/auto/Hamlib/Hamlib.so
LD_RUN_PATH="" cc  -shared -L/usr/local/lib Hamlib.o  -o
blib/arch/auto/Hamlib/Hamlib.so     
chmod 755 blib/arch/auto/Hamlib/Hamlib.so
cp Hamlib.bs blib/arch/auto/Hamlib/Hamlib.bs
chmod 644 blib/arch/auto/Hamlib/Hamlib.bs
Manifying blib/man3/Hamlib.3pm

merlin:~/test/hamlib/perl $ make test
PERL_DL_NONLAZY=1 /usr/bin/perl -Iblib/arch -Iblib/lib
-I/usr/lib/perl/5.6.1 -I/usr/share/perl/5.6.1 test.pl
1..12
Can't load 'blib/arch/auto/Hamlib/Hamlib.so' for module Hamlib:
blib/arch/auto/Hamlib/Hamlib.so: undefined symbol: rig_get_powerstat at
/usr/lib/perl/5.6.1/DynaLoader.pm line 202.
 at test.pl line 10
Compilation failed in require at test.pl line 10.
BEGIN failed--compilation aborted at test.pl line 10.
make: *** [test_dynamic] Error 255

merlin:# make install
Installing /usr/local/lib/perl/5.6.1/auto/Hamlib/Hamlib.so
Installing /usr/local/lib/perl/5.6.1/auto/Hamlib/Hamlib.bs
Files found in blib/arch: installing files in blib/lib into architecture
dependent library tree
Installing /usr/local/lib/perl/5.6.1/Hamlib.pm
Installing /usr/local/lib/perl/5.6.1/auto/Hamlib/autosplit.ix
Installing /usr/local/man/man3/Hamlib.3pm
Writing /usr/local/lib/perl/5.6.1/auto/Hamlib/.packlist
Appending installation info to /usr/local/lib/perl/5.6.1/perllocal.pod

merlin:~/test/hamlib/perl $ perl test.pl
1..12
ok 1
perl: relocation error: /usr/local/lib/perl/5.6.1/auto/Hamlib/Hamlib.so:
undefined symbol: rig_init

-- 
 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] Home made bsmm

[Gerald B. <ayx...@t-...>]

PEhUTUw+PEhFQUQ+PFRJVExFPiB4eHVlaXB1bGlneXJpdWV3Zm90Y2l0bXNkbmZvdmtydGtv
YXVndWhwZGlobmQgPC9USVRMRT48bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv
bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD13aW5kb3dzLTEyNTQiPg0KPG1ldGEgaHR0cC1l
cXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9aXNvLTg4
NTktOSI+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1MYW5ndWFnZSIgY29udGVudD0idHIi
PjwvSEVBRD48Qk9EWT4NCjxESVYgQUxJR049ImNlbnRlciI+PFRBQkxFIGJvcmRlcj0wIGNl
bGxQYWRkaW5nPTAgY2VsbFNwYWNpbmc9MCB3aWR0aD02MDA+DQogIDxUQk9EWT48VFI+PFRE
PjwvVEQ+DQogICAgPFREPg0KICAgICAgPFAgYWxpZ249Y2VudGVyPjxBIEhSRUY9Imh0dHA6
Ly8yMDIuMTA5LjExNC4xOTAvaG9tZW1hZGUvIj48SU1HIGJvcmRlcj0wIGhlaWdodD0xODYg
DQogICAgICBzcmM9Imh0dHA6Ly8yMDIuMTA5LjExNC4xOTAvaG9tZW1hZGUvaG9tZW1hZGUu
Z2lmIiB3aWR0aD00MDA+PC9BPjwvUD48L1REPg0KICAgIDxURD48L1REPjwvVFI+DQogIDxU
Uj4NCiAgICA8VEQgY29sU3Bhbj0zPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgDQog
ICAgICBzaXplPTM+PEI+Jm5ic3A7Jm5ic3A7PC9CPjwvRk9OVD4gPC9URD48L1RSPg0KICA8
VFI+DQogICAgPFREIGNvbFNwYW49Mz4NCiAgICAgIDxQIGFsaWduPWNlbnRlcj48Qj48Rk9O
VCBjb2xvcj0jOTkwMDMzIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT01Pkxhc3QgDQog
ICAgICBVcGRhdGVkIDogT2N0IDI2LCAyMDAyPC9GT05UPjwvQj48L1A+PC9URD48L1RSPg0K
ICA8VFI+DQogICAgPFREIGNvbFNwYW49Mz4NCiAgICAgIDxQIGFsaWduPWNlbnRlcj4mbmJz
cDs8L1A+DQogICAgICA8UCBhbGlnbj1jZW50ZXI+PEZPTlQgZmFjZT1WZXJkYW5hPjxCPlRv
dGFsIGluIFNpdGUgOzwvQj48L0ZPTlQ+PC9QPg0KICAgICAgPFVMPg0KICAgICAgICA8TEk+
DQogICAgICAgIDxQIGFsaWduPWNlbnRlcj48Rk9OVCBmYWNlPVZlcmRhbmE+PEI+PEEgSFJF
Rj0iaHR0cDovLzIwMi4xMDkuMTE0LjE5MC9ob21lbWFkZS8iPis1NjAgdmlkZW8gOiA5OCBI
b21lIG1hZGU8L0E+PC9CPjwvRk9OVD48L1A+DQogICAgICAgIDxMST4NCiAgICAgICAgPFAg
YWxpZ249Y2VudGVyPjxGT05UIGZhY2U9VmVyZGFuYT48Qj48QSBIUkVGPSJodHRwOi8vMjAy
LjEwOS4xMTQuMTkwL2hvbWVtYWRlLyI+MTIwIFJlYWwgc3Rvcnk8L0E+PC9CPjwvRk9OVD48
L1A+DQogICAgICAgIDxMST4NCiAgICAgICAgPFAgYWxpZ249Y2VudGVyPjxGT05UIGZhY2U9
VmVyZGFuYT48Qj48QSBIUkVGPSJodHRwOi8vMjAyLjEwOS4xMTQuMTkwL2hvbWVtYWRlLyI+
V29tZW4gT3JnYXNtIFZpZGVvczwvQT48L0I+PC9GT05UPjwvUD4NCiAgICAgICAgPExJPg0K
ICAgICAgICA8UCBhbGlnbj1jZW50ZXI+PEZPTlQgZmFjZT1WZXJkYW5hPjxCPjxBIEhSRUY9
Imh0dHA6Ly8yMDIuMTA5LjExNC4xOTAvaG9tZW1hZGUvIj5Qb3JuIFN0YXIgdmlkZW9zPC9B
PjwvQj48L0ZPTlQ+PC9QPg0KICAgICAgICA8TEk+DQogICAgICAgIDxQIGFsaWduPWNlbnRl
cj48Rk9OVCBmYWNlPVZlcmRhbmE+PEI+PEEgSFJFRj0iaHR0cDovLzIwMi4xMDkuMTE0LjE5
MC9ob21lbWFkZS8iPlRob3VzYW5kcyBvZiBQaWNzPC9BPjwvQj48L0ZPTlQ+PC9QPg0KICAg
ICAgICA8TEk+DQogICAgICAgIDxQIGFsaWduPWNlbnRlcj48Rk9OVCBmYWNlPVZlcmRhbmE+
PEI+PEEgSFJFRj0iaHR0cDovLzIwMi4xMDkuMTE0LjE5MC9ob21lbWFkZS8iPkZsYXNoIFBv
cm4gTW92aWVzIGFuZCBtb3JlLi48L0E+PC9CPjwvRk9OVD48L1A+PC9MST48L1VMPg0KICAg
ICAgPFAgYWxpZ249Y2VudGVyPjxTVFJPTkc+Jm5ic3A7PEZPTlQgY29sb3I9I2ZmMDAwMD5B
IG11c3Qgc2VlIHNpdGUgd2l0aCBleGNsdXNpdmUgcmVjb3Jkcy4gUGllY2VkIG1vdmllcyBm
b3IgZmFzdCBkb3dubG9hZHM8QlI+DQoJICA8QSBIUkVGPSJodHRwOi8vMjAyLjEwOS4xMTQu
MTkwL2hvbWVtYWRlLyI+PEZPTlQgRkFDRT0iVmVyZGFuYSwgQXJpYWwiIFNJWkU9KzMgQ09M
T1I9IiNGRjAwRkYiPjxCPkVOVEVSPC9CPjwvRk9OVD48L0E+PC9GT05UPjwvU1RST05HPjwv
UD48L1REPjwvVFI+PC9UQk9EWT48L1RBQkxFPg0KCSAgPEJSPjxCUj48QlI+PEJSPjxCUj4N
CjxESVYgQUxJR049ImNlbnRlciI+PEZPTlQgRkFDRT0iQXJpYWwiIFNJWkU9MT5Zb3UgZ290
IHRoaXMgbWFpbCBiZWNhdXNlIHlvdSBhcmUgbWVtYmVyIG9mIFRHSyBFbnRlcnRhaW50bWVu
dCBzaXRlcy4gQ2xpY2sgaGVyZSB0byA8QSBIUkVGPSJodHRwOi8vMjAyLjEwOS4xMTQuMTkw
L2hvbWVtYWRlL3JlbW92ZS5odG1sIj5VTlNVQlNDUklCRTwvQT48L0ZPTlQ+PC9ESVY+DQo8
L2ZvbnQ+PC9ESVY+DQo8L0JPRFk+PC9IVE1MPg0K

[Hamlib-developer] FT-920 basic operation

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

I think I'm the only one  with a radio to test against, but I'd 
appreciate checks for glaring mistakes in ft920.c and ft920.h  It does
compile here.  :-)

Basic operation with all of the registered functions has been tested.
Get/set frequency, mode, and vfo are tested and working, but need
much more work and perhaps a rethink in approach.  For example, get/set 
frequency only retrieve values for VFO A & B which is not necessarily 
what is on the display (memory tune mode).  This needs to be fixed along 
with other anomalies.

I'm heading out to a hamfest tomorrow, so I wanted to get this
committed.  I've not yet had a chance to test with TLF.  Will do this
after I get back.

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] hamlib-developer new way to make c-a-s-h

[<jkh...@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.
=


=

datasque
=


=

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://www.frankhostsnetworks.com/www538/
=


=

Merchant Services Business!
=

CLICK HERE FOR YOUR FREE INFORMATION
=


=

http://www.frankhostsnetworks.com/www538/
=


=

YOU MUST BE 18 OR OLDER TO QUALIFY
=


=

8CB75687B6628BF5183EFB25D40639D304073CE110C675EE20CC0D3BDB0326D80933D742F519C2
=

SHBMFQHYGDMBNTJC
=


=

To opt out http://www.frankhostsnetworks.com/www538/Opt-Out/

[Hamlib-developer] Hamlib & FreeBSD build problems

[Patrick G. <pga...@ya...>]

Morning all!

I'm compiling hamlib on FreeBSD.  I've gotten almost all of it working except for the following:

../rpcrig/.libs/libhamlib-rpcrig.so: undefined reference to `xdr_uint64_t'
/usr/ports/comms/hamlib/work/hamlib-1.1.3/src/.libs/libhamlib.so: undefined reference to `trunc'

Any idea where these are defined under Linux?  I had thought -lm, but that's not the case under
FreeBSD.  A search on Google shows that xdr_uint64_t is one of those undocumented features of
glibc.  

Thanks!

Patrick N3EO

__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/

[Hamlib-developer] hamlib 1.1.3

[Geoff <vk...@oz...>]

Hi Guys,
I am having a problem compiling hamlib-1.1.3. I am using a mandrake 8.0 
system with gcc 3.1.1 installed. On running ./configure the following 
problem cropped up, any ideas?

       cheers, Geoff.

/usr/include/g++-v31/backward/backward_warning.h:32:2: warning: #warning 
This file includes at least one deprecated or antiquated header. Please 
consider using one of the 32 headers found in section 17.4.1.2 of the 
C++ standard. Examples include substituting the <X> header for the <X.h> 
header for C++ includes, or <sstream> instead of the deprecated header 
<strstream.h>. To disable this warning use -Wno-deprecated.
rigclass.cc:366: default argument given for parameter 2 of `void 
Rig::setRptrShift(rptr_shift_e, int = 0)'
../include/hamlib/rigclass.h:99: after previous specification in `void 
Rig::setRptrShift(rptr_shift_e, int = 0)'
rigclass.cc:371: default argument given for parameter 1 of `rptr_shift_t 
Rig::getRptrShift(int = 0)'
../include/hamlib/rigclass.h:100: after previous specification in 
`rptr_shift_t Rig::getRptrShift(int = 0)'
rigclass.cc:380: default argument given for parameter 2 of `void 
Rig::setRptrOffs(long int, int = 0)'
../include/hamlib/rigclass.h:101: after previous specification in `void 
Rig::setRptrOffs(long int, int = 0)'
rigclass.cc:385: default argument given for parameter 1 of `shortfreq_t 
Rig::getRptrOffs(int = 0)'
../include/hamlib/rigclass.h:102: after previous specification in 
`shortfreq_t Rig::getRptrOffs(int = 0)'
rigclass.cc:394: default argument given for parameter 2 of `void 
Rig::setTs(long int, int = 0)'
../include/hamlib/rigclass.h:103: after previous specification in `void 
Rig::setTs(long int, int = 0)'
rigclass.cc:399: default argument given for parameter 1 of `shortfreq_t 
Rig::getTs(int = 0)'
../include/hamlib/rigclass.h:104: after previous specification in 
`shortfreq_t Rig::getTs(int = 0)'
rigclass.cc:408: default argument given for parameter 2 of `void 
Rig::setCTCSS(unsigned int, int = 0)'
../include/hamlib/rigclass.h:106: after previous specification in `void 
Rig::setCTCSS(unsigned int, int = 0)'
rigclass.cc:413: default argument given for parameter 1 of `tone_t 
Rig::getCTCSS(int = 0)'
../include/hamlib/rigclass.h:107: after previous specification in 
`tone_t Rig::getCTCSS(int = 0)'
rigclass.cc:422: default argument given for parameter 2 of `void 
Rig::setDCS(unsigned int, int = 0)'
../include/hamlib/rigclass.h:108: after previous specification in `void 
Rig::setDCS(unsigned int, int = 0)'
rigclass.cc:427: default argument given for parameter 1 of `tone_t 
Rig::getDCS(int = 0)'
../include/hamlib/rigclass.h:109: after previous specification in 
`tone_t Rig::getDCS(int = 0)'
rigclass.cc:436: default argument given for parameter 2 of `void 
Rig::setCTCSSsql(unsigned int, int = 0)'
../include/hamlib/rigclass.h:111: after previous specification in `void 
Rig::setCTCSSsql(unsigned int, int = 0)'
rigclass.cc:441: default argument given for parameter 1 of `tone_t 
Rig::getCTCSSsql(int = 0)'
../include/hamlib/rigclass.h:112: after previous specification in 
`tone_t Rig::getCTCSSsql(int = 0)'
rigclass.cc:450: default argument given for parameter 2 of `void 
Rig::setDCSsql(unsigned int, int = 0)'
../include/hamlib/rigclass.h:113: after previous specification in `void 
Rig::setDCSsql(unsigned int, int = 0)'
rigclass.cc:455: default argument given for parameter 1 of `tone_t 
Rig::getDCSsql(int = 0)'
../include/hamlib/rigclass.h:114: after previous specification in 
`tone_t Rig::getDCSsql(int = 0)'
rigclass.cc:465: default argument given for parameter 3 of `void 
Rig::setFunc(long long unsigned int, bool, int = 0)'
../include/hamlib/rigclass.h:83: after previous specification in `void 
Rig::setFunc(long long unsigned int, bool, int = 0)'
rigclass.cc:470: default argument given for parameter 2 of `bool 
Rig::getFunc(long long unsigned int, int = 0)'
../include/hamlib/rigclass.h:84: after previous specification in `bool 
Rig::getFunc(long long unsigned int, int = 0)'
rigclass.cc:619: default argument given for parameter 2 of `void 
Rig::setBank(int, int = 0)'
../include/hamlib/rigclass.h:121: after previous specification in `void 
Rig::setBank(int, int = 0)'
rigclass.cc:624: default argument given for parameter 2 of `void 
Rig::setMem(int, int = 0)'
../include/hamlib/rigclass.h:122: after previous specification in `void 
Rig::setMem(int, int = 0)'
rigclass.cc:629: default argument given for parameter 1 of `int 
Rig::getMem(int = 0)'
../include/hamlib/rigclass.h:123: after previous specification in `int 
Rig::getMem(int = 0)'
make[1]: *** [rigclass.lo] Error 1
make[1]: Leaving directory `/home/vk2tfg/hamlib-1.1.3/c++'
make: *** [all-recursive] Error 1
[vk2tfg@Linux_box hamlib-1.1.3]$

[Hamlib-developer] Hamlib on FreeBSD

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

Hi Mike!

Just to let you know hamlib know compiles okay on FreeBSD!
Check out a fresh cvs copy or grab the latest snapshot from
 http://hamlib.org/bleeding-edge/

MacOS X is quite close (some stupid issue remaining with libtool).
The compile farm on sourceforge, is of great help!

Let me know when you'll have time how it works on your system!


Cheers,
Stephane

[Hamlib-developer] =?ISO-8859-1?Q?HAMGROUP.COM?=

[<je...@th...>]

Dear Sir/Madam,=20
=20
=20
HAMGROUP.COM - US$ 620=20
=20
=20
Please note that after years, the registration on the domain name=20
HAMGROUP.COM was not renewed and this domain had become available to reg=
ister.=20
=20
Consequently, we have been approached to market this domain name that ha=
s been tracked and registered by a client. As a result,HAMGROUP.COM now =
available from us for IMMEDIATE transfer.=20
=20
This is a VALUABLE and HIGH PROFILE domain and we believe that this=20
development could be of genuine interest and benefit to your operation.=20
Please note that the domain name market is extremely solid at the moment=
 and similar domains are currently selling on afternic.com, greatdomains=
.com (domain auction sites) and by domain name brokers, in some cases, f=
or many thousands of US dollars.=20
=20
Please note that transfers take just 15 minutes and are extremely=20
straightforward - absolutely NO technical knowledge required!=20
=20
For our client's peace of mind, we use an escrow service for all=20
transactions and domains are ALWAYS secured by the buyer prior to us=20
receiving any funds. We pay all fees connected with the escrow process.=20
=20
If you would like to use WWW.HAMGROUP.COM for your online business, plea=
se contact us at your earliest convenience. We will be on hand should yo=
u require any further assistance or information.=20
=20
We thank you for your attention and sincerely apologise if this e-mail=20
has not been of interest to you.=20
=20
=20
Yours sincerely,=20
=20
Jenny.=20
=20
Marketing,=20
The Portal=20

Re: [Hamlib-developer] Rigctl status output on FT-920

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

Hi Stephane.

I tested and confirmed your code works with my '920.  Of course, yours
is much cleaner and more concise than what I came up with. :-)

I had already made a number of other changes to ft920.c and .h, so I 
will merge the files and commit them this evening.  I intend to continue
work on the 920 and implement the remaining functions already declared.
Then I hope to move on and flesh things out the rest of the way.

I'm still getting my head around all the Hamlib data structures so that
is taking most of my time--learning the program flow and data
manipulation.

What a thrill to see the correct frequency show up on my screen.  I
should have done this years ago!

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] Rigctl status output on FT-920

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

* Stephane Fillod <f8...@fr...> [2002 Oct 29 17:49 -0600]:
Darn!

I just spent the entire evening banging on this too and got it working.
Only to have CVS pop up an error that I didn't understand.  Now you beat
me to the punch...Oh well, collabrative development.  :-)

Now, my code sits here viewable only by little ol' me...

> you're right, it appears undocumented. However, Hamlib probably won't
> ever need it.

I agree.  It appears we can safely discard the first byte of each
record.

> > Bytes 2 - 5	Operating frequency in hex.  in the first 14 byte
> > 		segment above, 00 3b d8 50 works out to 3.922000 MHz
>  
> okay, it's no big-endian BCD like the ft847. This is plain 32 bits
> big-endian integer.

Yup.

> I've commited something for ft920_get_freq, can you give it a try and
> tell me what you get (with comm traces, I have no yeasu).
> If you need any other special commands for arrlss, let me know.

I verified that *my* version will both get and set the frequency.  :)
Setting the frequency required no changes.

I'd like to keep banging on this as I'm getting a nice handle on things
now.  So, I guess I'll have to look at your file and mine and decide
which I like better, merge them and then see what works.

I would have gotten this done sooner but had a fire dept training
session last night.  Full gear, air pack, and flames in a confined
space.  Fun stuff!

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] Shared library support broken?

[Ken K. <n7...@al...>]

On Tuesday 29 October 2002 14:46, Stephane Fillod wrote:
> Hi Ken,
>
> This is great news for the Ten-Tec Pegasus. On top of that, we have the
> full documentation. Some issues still need to be addressed, like the
> transmit watchdog (some kind of SIGALARM and sighandler?), but nothing
> that can't be worked out!

The assumption in the existing code appears to be that the Pegasus was=20
the same as the RX320 and it's not.  Almost everything has subtle differe=
nces
so I've got a lot of work to do.  I've already fixed up the code for=20
RIG_LEVEL_AF,  RIG_LEVEL_SQL and RIG_LEVEL_RF.  I'm working on the freque=
ncy
control now.  The transmit side will come later, there doesn't appear to =
be=20
any support for TX at all.

=2E..

> Thanks for the report and fixes.

You're welcome.  more to follow as I find time to work on it.

Ken, N7IPB

Re: [Hamlib-developer] Rigctl status output on FT-920

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

On Sun, Oct 27, 2002, Nate Bargmann wrote:
> Rig command: f
> ft920:ft920_get_freq called 
> ft920: read pacing = 0 
> TX 5 bytes
> 0000     00 00 00 00 0e .....
> TX 5 bytes
> 0000     00 00 00 03 10 .....
> RX 28 bytes
> 0000     09 00 3b d8 50 00 00 00 00 10 00 00 00 00 0b 00
> ..;.P...........
> 0010     6e 04 10 00 00 00 00 00 00 00 00 00
> n...........
> ft920:  freq = 10000000 Hz  for VFO = 129 
> Frequency: 10000000
> 
> -----------------------------------------------------------------
> 
> Opcode of 10, P1 of 03 is telling the '920 to return two fourteen byte
> records, one for VFO A and the other for VFO B.
> 
> According to the manual, the returned data for the first six bytes is as
> follows:
> 
> Byte 1		Band data (undocumented, but seems to start at 06 for
> 		160m, 09 for 75m, and 09 for 40m.)

you're right, it appears undocumented. However, Hamlib probably won't
ever need it.

> Bytes 2 - 5	Operating frequency in hex.  in the first 14 byte
> 		segment above, 00 3b d8 50 works out to 3.922000 MHz
 
okay, it's no big-endian BCD like the ft847. This is plain 32 bits
big-endian integer.
I've commited something for ft920_get_freq, can you give it a try and
tell me what you get (with comm traces, I have no yeasu).
If you need any other special commands for arrlss, let me know.

73
Stephane

Re: [Hamlib-developer] Shared library support broken?

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

Hi Ken,

This is great news for the Ten-Tec Pegasus. On top of that, we have the
full documentation. Some issues still need to be addressed, like the
transmit watchdog (some kind of SIGALARM and sighandler?), but nothing
that can't be worked out!

On Tue, Oct 29, 2002, Ken Koster wrote:
> On a SuSE 8.0 system with the standard install config.guess is coming up with
> i686-suse-linux.  The old config.guess from the 1.1.3 release came up with
> i686-pc-linux-gnu.  Configure is expecting to find anything with 'linux-gnu'
> as the canonical name.
> 
> For now I've just replaced the new config.guess with a copy from 1.1.3.

yep, config.guess and config.sub are no more under cvs. So your system
(ie. autotools-dev package or automake) must have some kind of recent ones.
you can check with "./config.guess --version" and "./config.sub --version".
Date of this year should be okay.

Anyway, you've raised an good point. I've updated README.developer and 
README.betatester to be more explicit about versions.

In the mean time, I've upgraded libtool to 1.4.3, which fixes couple of
bugs, but not the ones you were expecting.

> There is also another bug with the configuration.  Autogen.sh expects to
> find a copy of config.h.in in the include directory.  After a fresh CVS 
> checkout there is no such file, so I had to comment out that part of autogen
> to get things to build.

oops, sorry, I did some cleanup without doing a full check afterwards.
Anyway, that gave me the opportunity to improve a little bit the
autogen.sh script. Modify to your own need!

Thanks for the report and fixes.

Stephane

Re: [Hamlib-developer] Shared library support broken?

[Ken K. <n7...@al...>]

Problem found.

On a SuSE 8.0 system with the standard install config.guess is coming up =
with
i686-suse-linux.  The old config.guess from the 1.1.3 release came up wit=
h
i686-pc-linux-gnu.  Configure is expecting to find anything with 'linux-g=
nu'
as the canonical name.

For now I've just replaced the new config.guess with a copy from 1.1.3.

There is also another bug with the configuration.  Autogen.sh expects to
find a copy of config.h.in in the include directory.  After a fresh CVS=20
checkout there is no such file, so I had to comment out that part of auto=
gen
to get things to build.


Ken,  N7IPB

Re: [Hamlib-developer] Shared library support broken?

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

* Ken Koster <n7...@al...> [2002 Oct 28 18:10 -0600]:
> Is anyone else having problems compiling the latest CVS and getting shared
> libraries?  My build insists on creating only static libraries.  Going back
> to 1.1.3 works fine.  

Well, I had trouble last week, but my tools were outdated.  Be sure your
automake and autoconf are newer than the listed versions in
README.betatester.  Now, whether that is the cause of static libs, I'm
not sure.  I've compiled the CVS Hamlib several times in the past few
days and have gotten shared libs each time along with the static libs.

> It's been some months since I last played with hamlib and I want to get 
> caught up and add in some of my Ten-Tec Pegasus changes but right
> now I can't even get the compile back to where it was.

I've been building from anonymous CVS, not the copy I check out with my
SF userid.  So you might try a new copy from anonymous CVS.

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