hamlib-developer — hamlib developers forum

Re: [Hamlib-developer] How to link in binary

[John R. <js...@ho...>]

Here is the script I'm using to compile:

rm -f testrig testrig.o

export HAMLIB=../hamlib-1.1.2/
export LD_LIBRARY_PATH=${HAMLIB}/.libs/:${HAMLIB}/icom/.libs:.

gcc -DHAVE_CONFIG_H -I${HAMLIB}/tests -I${HAMLIB}/include -I${HAMLIB}/src  
-D_GNU_SOURCE  -g -O2 -Wall -c testrig.c
gcc -g -O2 -Wall -o testrig testrig.o -L${HAMLIB}/src -lhamlib

When I run this script I get a .o file, but I can't produce a binary:

jroberts@geiswd44ab(~/src/setfreq) 1029$ ./m2
../hamlib-1.1.2//src/libhamlib.a(register.o): In function 
`rig_load_backend':
/home/jroberts/src/hamlib-1.1.2/src/register.c:288: undefined reference to 
`lt_dlinit'
/home/jroberts/src/hamlib-1.1.2/src/register.c:302: undefined reference to 
`lt_dlopen'
/home/jroberts/src/hamlib-1.1.2/src/register.c:305: undefined reference to 
`lt_dlerror'
/home/jroberts/src/hamlib-1.1.2/src/register.c:312: undefined reference to 
`lt_dlsym'
/home/jroberts/src/hamlib-1.1.2/src/register.c:314: undefined reference to 
`lt_dlerror'
/home/jroberts/src/hamlib-1.1.2/src/register.c:316: undefined reference to 
`lt_dlclose'
/home/jroberts/src/hamlib-1.1.2/src/register.c:329: undefined reference to 
`lt_dlsym'
collect2: ld returned 1 exit status
./m2: ./testrig: No such file or directory
jroberts@geiswd44ab(~/src/setfreq) 1030$


What am I doing wrong?

John


>From: Stephane Fillod <f4...@fr...>
>To: Ham...@li...
>Subject: Re: [Hamlib-developer] How to link in binary
>Date: Mon, 26 Nov 2001 18:39:02 +0100 (MET)
>
>
>En réponse à John Roberts <js...@ho...>:
> > How do I link my binary with hamlib? Do I have to use libtool and do all 
>the
> > DLL stuff? Or can I just link the .a for my radio into the binary? [I 
>can't
> > get the latter to work -- it complains about calls to dl_open...]
>
>hmm, some output traces would help in that case. I'm suspecting Hamlib
>is unable to load the backend (i.e. the .so or .la module).
>Linking against Hamlib is be pretty straight forward. No need to worry
>about libtool, it is there to be transparent.
>
>         gcc myapp.o -lhamlib -o myapp
>
>Add -L/usr/local/lib if needed. Statically linking with .a if okay too.
>If linking is fine, "ldd myapp" should report no unmet dependencies.
>
>When does the problem appear? at link time or at run time?
>Are you using the RPM release? Does rigctl works for you?
>
>My guess is your application is not able to find the backend module.
>This should not happen with the RPMs (unless there's a bug waiting for a 
>fix :)
>In the other cases, you may have to play with LD_LIBRARY_PATH.
>
> > BTW, I still can't read sig strength or freq from my Icom 756Pro. Is 
>that
> > right? I'm using 1.1.2.
>
>Same question, are you using rigctl to query freq and sig strength?
>What are the error message (add -vvvv for verbose mode) ?
>
>
>73, Stephane
>
>_______________________________________________
>Hamlib-developer mailing list
>Ham...@li...
>https://lists.sourceforge.net/lists/listinfo/hamlib-developer


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Re: [Hamlib-developer] How to link in binary

[<rs...@su...>]

Hi John,

On Tue, 27 Nov 2001, John Roberts wrote:

> What I want to do next is write a GUI for hamlib. Has anyone done this
> already? I'm thinking that it's best to do it Java so I'm going to use JNI
> to call Hamlib and use RMI to allow the GUI to live in a web-browser on a
> remote machine. Should be pretty neat. Obviously all this code will be GPL
> under the same terms as Hamlib. Cool?
>
> Has anyone already done this?

I'm workung on a GUI written with Qt2/KDE2. But my internship here at SuSE
is almost completed, so I will have to work on it during my spare time.
Also, I don't have an FT-847 at home, and the IC-275/475 and FT990 aren't
supported yet. But we'll manage that ;-)

73, Robert
-- 
Robert Steinhaeusser, DL1NC / N9KBK                         rs...@su...
http://1409.org                                   ro...@st...

Re: [Hamlib-developer] How to link in binary

[John R. <js...@ho...>]

>From: Stephane Fillod <f4...@fr...>
>To: Ham...@li...
>Subject: Re: [Hamlib-developer] How to link in binary
>Date: Mon, 26 Nov 2001 18:39:02 +0100 (MET)
>
>
>En réponse à John Roberts <js...@ho...>:
> > How do I link my binary with hamlib? Do I have to use libtool and do all 
>the
> > DLL stuff? Or can I just link the .a for my radio into the binary? [I 
>can't
> > get the latter to work -- it complains about calls to dl_open...]
>
>hmm, some output traces would help in that case. I'm suspecting Hamlib
>is unable to load the backend (i.e. the .so or .la module).
>Linking against Hamlib is be pretty straight forward. No need to worry
>about libtool, it is there to be transparent.
>
>         gcc myapp.o -lhamlib -o myapp
>
>Add -L/usr/local/lib if needed. Statically linking with .a if okay too.
>If linking is fine, "ldd myapp" should report no unmet dependencies.

I'll give that a shot. Thanks!

>
>When does the problem appear? at link time or at run time?
>Are you using the RPM release? Does rigctl works for you?

Run time. If it continues I'll post sessions. rigctl and testrig both work. 
I'm using testrig as the starting point for my application. When you compile 
testrig you use libtool and a really funking link-line so I'm trying to 
extract the code from that build process and simplify it.


>
>My guess is your application is not able to find the backend module.
>This should not happen with the RPMs (unless there's a bug waiting for a 
>fix :)

I might try and load the RPMs so I can easily link the library in.

>In the other cases, you may have to play with LD_LIBRARY_PATH.
>
> > BTW, I still can't read sig strength or freq from my Icom 756Pro. Is 
>that
> > right? I'm using 1.1.2.
>
>Same question, are you using rigctl to query freq and sig strength?
>What are the error message (add -vvvv for verbose mode) ?

No, I'm using testrig and it says something like "Feature not supported"

BTW, here's what I'm up to:

I have a "product" that collects and processes signals in the HF spectrum. 
In order to test my product I have an Icom 756Pro and some special modems 
that I use to transmit test signals into a dummy load to see if my product 
can detect them.

Hamlib is saving me SOOO much time because with it I will be able to 
automate most of my testing. I can use hamlib to move the transmitter around 
the bands and see how my product performs.

What I want to do next is write a GUI for hamlib. Has anyone done this 
already? I'm thinking that it's best to do it Java so I'm going to use JNI 
to call Hamlib and use RMI to allow the GUI to live in a web-browser on a 
remote machine. Should be pretty neat. Obviously all this code will be GPL 
under the same terms as Hamlib. Cool?

Has anyone already done this?

John

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Re: [Hamlib-developer] How to link in binary

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

En réponse à John Roberts <js...@ho...>:
> How do I link my binary with hamlib? Do I have to use libtool and do all the 
> DLL stuff? Or can I just link the .a for my radio into the binary? [I can't 
> get the latter to work -- it complains about calls to dl_open...]

hmm, some output traces would help in that case. I'm suspecting Hamlib 
is unable to load the backend (i.e. the .so or .la module).
Linking against Hamlib is be pretty straight forward. No need to worry 
about libtool, it is there to be transparent. 

        gcc myapp.o -lhamlib -o myapp

Add -L/usr/local/lib if needed. Statically linking with .a if okay too.
If linking is fine, "ldd myapp" should report no unmet dependencies. 

When does the problem appear? at link time or at run time?
Are you using the RPM release? Does rigctl works for you?

My guess is your application is not able to find the backend module.
This should not happen with the RPMs (unless there's a bug waiting for a fix :)
In the other cases, you may have to play with LD_LIBRARY_PATH.

> BTW, I still can't read sig strength or freq from my Icom 756Pro. Is that 
> right? I'm using 1.1.2.

Same question, are you using rigctl to query freq and sig strength?
What are the error message (add -vvvv for verbose mode) ? 


73, Stephane

[Hamlib-developer] How to link in binary

[John R. <js...@ho...>]

Hi,

For starters I'd like to create a command-line binary that will change the 
freq of the radio.

How do I link my binary with hamlib? Do I have to use libtool and do all the 
DLL stuff? Or can I just link the .a for my radio into the binary? [I can't 
get the latter to work -- it complains about calls to dl_open...]

BTW, I still can't read sig strength or freq from my Icom 756Pro. Is that 
right? I'm using 1.1.2.

Thanks!
John

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

[Hamlib-developer] Re: Modes again...

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

On Mon, Nov 19, 2001, Robert Steinhäußer wrote:
> The *x_range_list in the ft847.c is wrong.
> 
> The #define FT847_ALL_RX_MODES and _TX_MODES should have the RIG_MODE_RTTY
> removed.

okay, done.

> The other FT847-specific data seems correct.
> 
> Since the last change of the CVS, selecting USB or LSB with the FT847
> gives an exception (which is caught). I haven't found out yet, where it
> comes from (hamlib changed something or Kontakt broken).
 
Sorry, I cannot debug this from here cause I don't own a FT847 myself. 
Could it be because of the new ft847_get_freq and ft847_get_mode?

73, Stephane

Re: [Hamlib-developer] Re: Dummy backend

[<rs...@su...>]

On Sun, 18 Nov 2001, Stephane Fillod wrote:

> Okay, I've implemented basic support for freq/more/passband.
> Since it's kind of boring, the rest will come later. Let me know
> if you need specific ones. Patches also welcome :)

Yeah, just saw it. Great! Thanks!

Sure, the dummy backend isn't very interesting out in the field and quite
stupid, but good for tests. I'll send you a note or patch, if I need more.


73, Robert
-- 
Robert Steinhaeusser, DL1NC / N9KBK                         rs...@su...
http://1409.org                                   ro...@st...

[Hamlib-developer] Re: Dummy backend

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

On Thu, Nov 15, 2001, Robert Steinhäußer wrote:
> I was just wondering why the dummy backend gives me some strange results,
> then had a look at the hamlib dummy.c file.
> 
> All dummy_get_* functions don't set the returned pointers! So they all
> return uninitalized values when queried! Could you please just return any
> valid data?
> 
Okay, I've implemented basic support for freq/more/passband.
Since it's kind of boring, the rest will come later. Let me know
if you need specific ones. Patches also welcome :)

73, Stephane

Re: [Hamlib-developer] Re: mac os x libtool problem

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

Hi Jim!

I hope your trip went well, away from all the troubles and bad luck
you guys have over there.

Anyway, I did some work on the Max OS X port. Thanks to the sourceforge
compile farm, I've been able to get hold of a G4 to play with.
After some hacking, I am able to build everything but the test applications
(problem in the symbol extracting, not investigated yet).
Even though I haven't tried it, straight linking should be possible
without using libtool (the culprit).
libtool porting on Mac OS X is explained at 
  http://fink.sourceforge.net/doc/porting/libtool.php
and the following link talks about a hack with does not work completely.
  http://mail.gnu.org/pipermail/libtool/2001-October/005616.html

<<
libtool 1.4: Long in the works and recently released as the new stable
version, this branch has better autoconf integration. Unfortunately that
makes migrating packages from 1.3 non-trivial. It supports Darwin 1.3 / Mac
OS X 10.0 out of the box and needs a small patch to work on Mac OS X 10.1.
It can be recognized by the absence of ltconfig. Versions that identify
themselves as 1.3b or 1.3d are actually development snapshots of 1.4 and
must be treated with caution
Side note: The libltdl library included with all libtool versions will only
work on Darwin when dlcompat is installed
>>

But there's hope. Lately, one fellow on the libtool mailing list offered 
to work on fixing libtool on Mac OS X. Darwin rule rules :)

In the mean time, I also bought a Kenwood TH-F7E (the european version 
of the TH-F6A). It has a PC connection, and I've made it to work
under Hamlib! So the kenwood backend is on a good way!

Let me know how it goes on your side.

73,
Stephane - F8CFE

[Hamlib-developer] ft847: get_freq() and get_mode()

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

Hi there!

Robert Steinhaeusser wrote:
> The FT847 didn't have rig_get_freq() last time I looked, but Kontakt
> should really display the correct value it upon start (it doesn't yet).

To me, Hamlib should at least provide rig_set_freq/rig_set_mode/rig_set_vfo.
And of course, even if the protocol has no provision for their retrieval
counterparts, they should be emulated by the backend.

However, I just implemented the ft847_get_freq and ft847_get_mode,
totally from specs, blind, without testing. This will be checked in
on wednesday morning (GMT+1). Feedback welcome!

BTW, it looks like this feature is only available with models starting 
from serial# 8G05. Ask your Yaesu rep for an upgrade (disclaimer: I haven't
verified it myself)
For more information, check out the following site:
	http://my.en.com/~rayd/ft-847/FAQ/page4.htm#pollingcodes

> Kontakt has to remember which frequency was last used, anyhow -> I can
> write a function rmode_t avail_modes = modes( freq_t currentFreq ) for
> Kontakt, but it would be nice to have this in the Rig-class (what modes
> can I set when on frequency f?).

Are you looking for rmode_t Rig::RngRxModes(freq_t) and 
rmode_t Rig::RngTxModes(freq_t) ?


73, Stephane

Re: [Hamlib-developer] Re: mac os x libtool problem

[Jim W. <jwe...@nc...>]

Hi Stephan:

take a look at this:

http://fink.sourceforge.net/doc/porting/shared.php

I'm gonna grab snapshots of these pages and study them while
I'm away.

catch you later.

73,
jim.
n4rse

[Hamlib-developer] Re: mac os x libtool problem

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

[message Cc: on hamlib-developer mailing list]

Hi Jim!

> I think we have a problem with libtool:

yep, I know. You were waiting for the new version of mac os x to stabilize.
Let's see what we can do.

> lapdog(beast)/Users/beast %cd CVS/hamlib/hamlib                  
> [/Users/beast]

I guess this is the latest CVS version.

> lapdog(beast)/Users/beast/CVS/hamlib/hamlib %make
[snip]
> /bin/sh ../libtool --mode=link cc  -g -O2 -Wall   -o libhamlib.la -rpath
          ^^^^^^^^^^
All right, so this is indeed the hamlib libtool version which is used,
and not the old system one. good.

> /usr/local/lib -no-undefined -release 1.1.2 rig.lo serial.lo misc.lo 
> register.lo event.lo cal.lo conf.lo ../libltdl/libltdlc.la
> rm -fr .libs/libhamlib.la .libs/libhamlib.* .libs/libhamlib-1.1.2.*
> ../libtool: parse error: condition expected: xno = [3183]
              ^^^^^^^^^^^^
arrg! here it is. I saw couple of weeks ago on the libtool mailing list,
that this is a known bug, related to zsh. Are you running zsh as your
system shell? IOW, is /bin/sh a link to zsh ? 
The workaround would be to have bash installed (or some other bourne shell),
and rebuild hamlib with it.
I'll try to browse the libtool mailing list in the hope of finding a fix
for mac os x, until next version of libtool releases.

> 
> Is there something in the makefile that is not available with the
> version of libtool I have?

Everything should be there. Actualy, libtool is generated by ./configure.
The "old" libtool on your system is not used.

Disabling dynamic loading won't help much. You may try it by passing 
"--disable-shared" to configure, and then "make clean all".
But I think the problem is in the libtool script.
Hmm, if neither tricks work, perhaps you could try to replace, once the 
configure
is ran, the hamlib libtool by the "old" libtool script of your system
(copy the script over, or use a link). It may resolve the parse error
problem, but may broke other stuff since it's not the latest version.

Anyway, let me know how it goes. I'd love to see Hamlib running on Mac OS X,
and also with a Kenwood rig (never tested!).

73,
Stephane

Re: [Hamlib-developer] Re: compile

[<rs...@su...>]

On Thu, 25 Oct 2001, Stephane Fillod wrote:

> Be careful, rpcrig is rather shallow right now. There's only rig_set_freq
> and reading caps is not implemented yet (you would get anything but
> expected values).

OK, it was only an example. I am testing here by switching from one device
to another. Maybe I should leave out all alpha-state devices.

> > #3  <signal handler called>
> > #4  0x413ab2f1 in rpcrig_close (rig=0x8110810) at rpcrig_backend.c:170
> > #5  0x4002b06c in rig_close (rig=0x8110810) at rig.c:497
> > #6  0x4001b4b3 in Rig::close (this=0x812e308) at rigclass.cc:70
>
> Maybe related to the double close issue? Or is it peculiar to some backends?
> Could you try again with the new fix?

Only certain backends (such as the rpc rig) still crash on close() without
an open(). Still happens here with the new version.

> > Then I am trying to figure out which radio modes (AM, ...) are currently
> > available. I suppose I will have to parse the freq_range_list array. But
> > still one thing shouldn't happen: Select FT847, Kontakt finds out
> > "everything except WFM is ok". Then select RTTY -> RigException. Every

>    very simple, RIG_MODE_WFM is not declared in caps :*)

Of course, but this is not the problem. This button gets correctly
disabled (that's why I wrote "everything except WFM is ok").

>    Anyone has protocol specs handy? Frank?

Yes, me. The FT847 protocol supports LSB, USB, CW, CW-R, AM, FM, CW(N),
CW-R(N), AM(N), FM(N).


> RTTY is not supported (yet) by ft847_set_mode. BTW, is this mode
> available on the rig?

Not explicitely, but a myRig->caps->tx_range_list2[something].modes &
RIG_MODE_RTTY returned true, otherwise this button would not have been
available and no RigException would have been produced. Does the backend
internally note the last set frequency somehow? That might cause this
problem here. I still have to work on the detection of available modes.

> > Now rig_close (+ft847_close) is called twice, it seems.
>
> good point! rig_close was missing a rig->state.comm_state update...
> I've commited a fix, it should now be safe to call rig_close() twice.

This is fixed now.

73, Robert
-- 
Robert Steinhaeusser, DL1NC / N9KBK                         rs...@su...
http://1409.org                                   ro...@st...

[Hamlib-developer] Re: compile

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

[ this mail is Cc: to hamlib-developer ]

On Thu, Oct 25, 2001, Robert Steinhäußer wrote:
> Still some drivers segfault when a close() is done without a preceding
> open()... here RPC rig:

Be careful, rpcrig is rather shallow right now. There's only rig_set_freq
and reading caps is not implemented yet (you would get anything but 
expected values).

> #3  <signal handler called>
> #4  0x413ab2f1 in rpcrig_close (rig=0x8110810) at rpcrig_backend.c:170
> #5  0x4002b06c in rig_close (rig=0x8110810) at rig.c:497
> #6  0x4001b4b3 in Rig::close (this=0x812e308) at rigclass.cc:70
 
Maybe related to the double close issue? Or is it peculiar to some backends?
Could you try again with the new fix?

> Then I am trying to figure out which radio modes (AM, ...) are currently
> available. I suppose I will have to parse the freq_range_list array. But
> still one thing shouldn't happen: Select FT847, Kontakt finds out
> "everything except WFM is ok". Then select RTTY -> RigException. Every

   very simple, RIG_MODE_WFM is not declared in caps :*)
   Are you sure the FT847 supports WFM ? If so, it's just one commit away!
   However, rig_set_mode does not seems to implemented it. 
   Or maybe MODE_MAIN_FM is actually WFM, and MODE_MAIN_NFM FM ?
   Anyone has protocol specs handy? Frank?
   The filter section is missing too (bandpass at -6dB). Anyone has it?

> other mode works fine. OK, the RTTY button is hard-coded to "16" (not
> RIG_MODE_RTTY, as I would prefer it, I'm working on it).

RTTY is not supported (yet) by ft847_set_mode. BTW, is this mode 
available on the rig?

> rig:rig_close called
> ft847:ft847_close called
> TX 5 bytes
> 0000	 00 00 00 00 80	.....
> rig:rig_cleanup called
> rig:rig_close called
> ft847:ft847_close called
> write_block() failed - Ungültiger Dateideskriptor
> ft847:ft847_cleanup called
> 
>                        ^^^^^^^^^^^^^^^^^^^^^^^^^^ invalid file descriptor
> 
> Now rig_close (+ft847_close) is called twice, it seems.

good point! rig_close was missing a rig->state.comm_state update...
I've commited a fix, it should now be safe to call rig_close() twice.

73 Stephane

Re: [Hamlib-developer] segfaults...

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

On Mon, Oct 15, 2001, Robert Steinhäußer wrote:
> My program segfaults sometimes.

You mean Hamlib :-)

> It seems like some drivers cannot handle it when a Rig::close() is called
> without a preceding Rig::open().

Oops, good point!

> How about a public method bool isOpen()? The setXxx/getXxx methods could
> throw an exception if !isOpen(). close() should just be tolerant and do
> nothing.
> 
> BTW: Does ~Rig() automatically call close()? I believe it should.
 
okay, this has to be fixed in Hamlib, not Hamlib++.
I've added a comm_state field to rig_state, and I protected rig_open(),
rig_close() and rig_cleanup() using it. Also, if rig_cleanup() is called
while the rig is still open, it will also close it as you suggested.
Now, every single Hamlib function has to be protected. Next time!

Cheers,
Stephane - F8CFE

[Hamlib-developer] segfaults...

[<rs...@su...>]

Hi!

My program segfaults sometimes.

One time (AOR):

#4  0x40d544e6 in fileno_unlocked () from /lib/libc.so.6
#5  0x4001e4b1 in fread_block (p=0x80e809c,
    rxbuffer=0xbfffe44c "\230\200\016\b", count=1) at serial.c:548
#6  0x415c9bc6 in aor_transaction (rig=0x80e8098, cmd=0x415ca182 "EX",
    cmd_len=2, data=0xbfffe44c "\230\200\016\b", data_len=0xbfffe448)
    at aor.c:102
#7  0x415c9c20 in aor_close (rig=0x80e8098) at aor.c:125
#8  0x4001a043 in rig_close (rig=0x80e8098) at rig.c:520
#9  0x4002c473 in Rig::close (this=0x8113750) at rigclass.cc:70

Another (RPC):

#4  0x00000010 in ?? ()
#5  0x4001a043 in rig_close (rig=0x80e8098) at rig.c:520
#6  0x4002c473 in Rig::close (this=0x80fcc00) at rigclass.cc:70

It seems like some drivers cannot handle it when a Rig::close() is called
without a preceding Rig::open().

How about a public method bool isOpen()? The setXxx/getXxx methods could
throw an exception if !isOpen(). close() should just be tolerant and do
nothing.

BTW: Does ~Rig() automatically call close()? I believe it should.

73, Robert

PS: I have created a very small page at http://kontakt.sf.net and linked
    it to the hamlib pages.

-- 
Robert Steinhaeusser, DL1NC / N9KBK                         rs...@su...
http://1409.org                                   ro...@st...

Re: [Hamlib-developer] what's up?

[<rs...@su...>]

On Fri, 12 Oct 2001, Stephane Fillod wrote:

> On Thu, Oct 11, 2001, Robert Steinhäußer wrote:
> > > > Sorry, but I still haven't tested our IC275 and 475 at home. Have to find
> > > > the old self-built interface first and then visit mom (DK3XJ) :)
>
> Yes it is. CI-V id $10 and $14. However, I still have to find the specs,
> brochures, whatever, to fill in the caps..

Oh, ok, so I'll search for the manual first.

> > I am trying to figure out why kdevelop wants to have -fno-exceptions in
> > the CXXFLAGS. Any ideas? I removed it manually from configure, so now I
> > can at least compile with <hamlib/rigclass.h> included.
>
> no clue. I'm not an expert in C++. Anyone?

Not a C++ problem. It seems like KDevelop sets this when compiling with
debug symbols. Don't know why. Adding "-fexceptions" to "own options"
doesn't help, as they are put on the command line before KDevleop's flags.
But without debug symbols it works.

> Or at least, Hamlib should offer all the primitives to manage configuration
> file?

Now if i exactly knew what a primitive is...

KDE has an own class KConfig, just do a config->SetGroup("xy"); and a
config->WriteEntry("name", value); and you get a
~/.kde2/share/config/prognamerc with:

  [xy]
  name=value

in it. I just have to know what to put there besides the rig numerical (as
below).

> > How do I find out which device need which specific settings? Like
> > baudrate, target IP address, etc. What is the struct confparams in rig.h?
> > I am focussing completely on the <hamlib/*.h> includes and not really
> > reading the hamlib source much (stupid app writers shouldn't have to
> > anyway :))
>
> I agree with you, and that's the point of having documentation.
> On this regard, the in-source documenting should be more verbose
> in the set_conf/get_conf section. In the meantime, have a look
> at src/conf.c. Right now, only "rig_pathname", "write_delay" and alike
> are available. Baud rate and such should be added in there...

I have some time to read it at my grandparents' on Saturday. The regional
ham club meeting (Distriktsversammlung) is on Sunday, so the weekend is
already filled up

> BTW, I'm going right now /P out-door (friday off, thanks to french "35 hours").
> >From time to time, I'll be calling CQ Hamlib on 21.250MHz..

OK, I have to leave now and catch my train home. We have our monthly local
ham meeting at 20:00.

73, Robert
-- 
Robert Steinhaeusser, DL1NC / N9KBK                         rs...@su...
http://1409.org                                   ro...@st...

Re: [Hamlib-developer] what's up?

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

On Thu, Oct 11, 2001, Robert Steinhäußer wrote:
> > > Sorry, but I still haven't tested our IC275 and 475 at home. Have to find
> > > the old self-built interface first and then visit mom (DK3XJ) :)
> > >
> >   Great! She will be happy to see you, but first wait IC275 and 475
> >   are added..
> 
> Oops... isn't it a C-IV device as well? I really have to get that stuff
> out of the box on the shelf :-)
 
Yes it is. CI-V id $10 and $14. However, I still have to find the specs,
brochures, whatever, to fill in the caps..

> > 	Let me know if some functions are missing in Hamlib, or if you
> >   think the design is not appropriate. Accessing the caps/state directly is
> >   recommanded, instead set_conf/get_conf should be used, provided more
> >   parameters are declared (yet to be done). Maybe there should be some
> >   config data file support in Hamlib, regardless the application.
> >   What do you think?
> 
> I am trying to figure out why kdevelop wants to have -fno-exceptions in
> the CXXFLAGS. Any ideas? I removed it manually from configure, so now I
> can at least compile with <hamlib/rigclass.h> included.

no clue. I'm not an expert in C++. Anyone?

> Kontakt has an own static class RigCaps with member functions that do a
> get_rig_caps(rig_model_t) and return one specific value: A few
> things I need to show the user before selecting a device: mfg_name,
> model_name, rig_type, and a QString containing a textual representation of
> the status (alpha, ...). Or does hamlib(++) already supply this and I
> missed it?

I don't think so. But it would sure make others happy if such facilities
were present in hamlib(++). IMO, the textual representation
of status/mode/etc. should be in hamlib, no doubt. For the other functions,
let me have a look at your class RigCaps, and I'll see where it belongs.
Anyone is free to patch too.

> Config file in hamlib: I think the user would get too much "involved" with
> the lib, which should only be a background thing for the "real app". The
> user should be able to install a new rpm at any time without having to
> look for some config file somewhere. And, he has to do some settings in
> the application anyway, so put it all in there, even though he will have
> to enter the same data once(!) in each app.

Or at least, Hamlib should offer all the primitives to manage configuration
file?

> How do I find out which device need which specific settings? Like
> baudrate, target IP address, etc. What is the struct confparams in rig.h?
> I am focussing completely on the <hamlib/*.h> includes and not really
> reading the hamlib source much (stupid app writers shouldn't have to
> anyway :))

I agree with you, and that's the point of having documentation. 
On this regard, the in-source documenting should be more verbose
in the set_conf/get_conf section. In the meantime, have a look
at src/conf.c. Right now, only "rig_pathname", "write_delay" and alike
are available. Baud rate and such should be added in there...
 
> >   Yep, as soon as I have downloaded the 8MB+ for the qt upgrade...
> 
> Which upgrade? This is Qt2-stuff, I'm not using Qt3 here.

The libqt-dev package depends on a newer libqt2, and a zillon of other
libraries. This will be done this week-end.

BTW, I'm going right now /P out-door (friday off, thanks to french "35 hours").
From time to time, I'll be calling CQ Hamlib on 21.250MHz..

73, Stephane - F8CFE

Re: [Hamlib-developer] what's up?

[<rs...@su...>]

On Thu, 11 Oct 2001, Stephane Fillod wrote:

> 	You'll need automake 1.5. Otherwise, you may have a chance
>  in regenerating all the .in files.

automake && ./configure && make install
works. Strange.

> > Sorry, but I still haven't tested our IC275 and 475 at home. Have to find
> > the old self-built interface first and then visit mom (DK3XJ) :)
> >
>   Great! She will be happy to see you, but first wait IC275 and 475
>   are added..

Oops... isn't it a C-IV device as well? I really have to get that stuff
out of the box on the shelf :-)

> 	Let me know if some functions are missing in Hamlib, or if you
>   think the design is not appropriate. Accessing the caps/state directly is
>   recommanded, instead set_conf/get_conf should be used, provided more
>   parameters are declared (yet to be done). Maybe there should be some
>   config data file support in Hamlib, regardless the application.
>   What do you think?

I am trying to figure out why kdevelop wants to have -fno-exceptions in
the CXXFLAGS. Any ideas? I removed it manually from configure, so now I
can at least compile with <hamlib/rigclass.h> included.

Kontakt has an own static class RigCaps with member functions that do a
get_rig_caps(rig_model_t) and return one specific value: A few
things I need to show the user before selecting a device: mfg_name,
model_name, rig_type, and a QString containing a textual representation of
the status (alpha, ...). Or does hamlib(++) already supply this and I
missed it?

Config file in hamlib: I think the user would get too much "involved" with
the lib, which should only be a background thing for the "real app". The
user should be able to install a new rpm at any time without having to
look for some config file somewhere. And, he has to do some settings in
the application anyway, so put it all in there, even though he will have
to enter the same data once(!) in each app.

How do I find out which device need which specific settings? Like
baudrate, target IP address, etc. What is the struct confparams in rig.h?
I am focussing completely on the <hamlib/*.h> includes and not really
reading the hamlib source much (stupid app writers shouldn't have to
anyway :))

>   Yep, as soon as I have downloaded the 8MB+ for the qt upgrade...

Which upgrade? This is Qt2-stuff, I'm not using Qt3 here.

Enough for today, more tmrw.

73, Robert
-- 
Robert Steinhaeusser, DL1NC / N9KBK                         rs...@su...
http://1409.org                                   ro...@st...

Re: [Hamlib-developer] what's up?

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

On Wed, Oct 10, 2001, Robert Steinhäußer wrote:
> My today's copy from the CVS doesn't, though. After some disk scratching,
> it says:
> 
> Making all in lib
> make[1]: Entering directory `/usr/src/hamlib/lib'
> Makefile:166: *** missing separator.  Stop.
> make[1]: Leaving directory `/usr/src/hamlib/lib'
> make: *** [all-recursive] Error 1
> 
> I'm using autoconf 2.52, automake 1.4-p5 and libtool 1.4.1.
> 
	You'll need automake 1.5. Otherwise, you may have a chance
 in regenerating all the .in files.

> Sorry, but I still haven't tested our IC275 and 475 at home. Have to find
> the old self-built interface first and then visit mom (DK3XJ) :)
> 
  Great! She will be happy to see you, but first wait IC275 and 475 
  are added..

> I'm working on my 'Kontakt' project (a GUI frontend for hamlib). Well, now
> I know a lot more about C++ (and differences to C, like using member
> functions for callback purposes... brrr!) and can actually give you a tree
> view of all devices supported by hamlib. A rig can be selected in the list
> (a subclass of QListViewItem now stores the rig_model_t entry), but that's
> about it right now. No actual controls yet, first I want to have the
> config data saved to/retrieved from the config file (hopefully this week).
 
	Let me know if some functions are missing in Hamlib, or if you
  think the design is not appropriate. Accessing the caps/state directly is
  recommanded, instead set_conf/get_conf should be used, provided more
  parameters are declared (yet to be done). Maybe there should be some
  config data file support in Hamlib, regardless the application.
  What do you think?

> If you *really* want to try it: http://sf.net/projects/kontakt -> cvs
> instructions. But please give me some feedback.

  Yep, as soon as I have downloaded the 8MB+ for the qt upgrade...

Cheers,
Stephane - F8CFE

Re: [Hamlib-developer] new to project--want to help

[<rs...@su...>]

On Wed, 10 Oct 2001, Stephane Fillod wrote:

> I've made a quick search about the ICOM T81A, and it turns out that
> this rig has only the ability to be cloned, in other words, it can
> only be memory programmed. It's not possible to control the rig,
> like changing VFOs, setting functions, get signal strength.
> But I might me wrong. Do you have some kind of documentation available
> in the manual?

I have a Yaesu FT51R. I also can only be cloned, via the 3.5mm jack on
top. I just checked the BBS, OM8ACE had some info on the technique
(9600Bd 3V/0V, ca. 3000 bytes of data). I asked him to mail me any other
info he's got :-)

73, Robert
-- 
Robert Steinhaeusser, DL1NC / N9KBK                         rs...@su...
http://1409.org                                   ro...@st...

Re: [Hamlib-developer] what's up?

[<rs...@su...>]

Hello out there,

On Mon, 8 Oct 2001, Stephane Fillod wrote:

> I haven't heard about you since the release of hamlib-1.1.2. I hope
> everything's fine on your side. I hardly believe 1.1.2 is so stable
> that you haven't had to report bugs :)

Well, it compiles without problems :-)

My today's copy from the CVS doesn't, though. After some disk scratching,
it says:

Making all in lib
make[1]: Entering directory `/usr/src/hamlib/lib'
Makefile:166: *** missing separator.  Stop.
make[1]: Leaving directory `/usr/src/hamlib/lib'
make: *** [all-recursive] Error 1

I'm using autoconf 2.52, automake 1.4-p5 and libtool 1.4.1.

> Also, I'd love to hear from people succeeding in (or not) to run Hamlib
> with any rig except the IC706 and FT847 (the only truly tested),
> like the Kenwoods, the various receives, etc.

Sorry, but I still haven't tested our IC275 and 475 at home. Have to find
the old self-built interface first and then visit mom (DK3XJ) :)

> Any wishes? Comments? Feedback welcome!

I'm working on my 'Kontakt' project (a GUI frontend for hamlib). Well, now
I know a lot more about C++ (and differences to C, like using member
functions for callback purposes... brrr!) and can actually give you a tree
view of all devices supported by hamlib. A rig can be selected in the list
(a subclass of QListViewItem now stores the rig_model_t entry), but that's
about it right now. No actual controls yet, first I want to have the
config data saved to/retrieved from the config file (hopefully this week).

If you *really* want to try it: http://sf.net/projects/kontakt -> cvs
instructions. But please give me some feedback.

73, Robert
-- 
Robert Steinhaeusser, DL1NC / N9KBK                         rs...@su...
http://1409.org                                   ro...@st...

Re: [Hamlib-developer] new to project--want to help

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

Hi Larry,


Welcome in the Hamlib team!

> My motivation in subscribing to the list come from owning an ICOM T81A and 
> finding the software/hardware necessary for programming the radio a bit 

I've made a quick search about the ICOM T81A, and it turns out that
this rig has only the ability to be cloned, in other words, it can
only be memory programmed. It's not possible to control the rig,
like changing VFOs, setting functions, get signal strength.
But I might me wrong. Do you have some kind of documentation available
in the manual?

> the radio, imho which would more than outweigh offering necessary items as 
> accesories for additional payment.

If only they would make the protocol specifications available.. 
However, some manufacturers do.

> My background is in information technology.  My radio interests are 
> homebrewing, both with tubes and silicon,  and 6 meter band communications.

The magic band is fun, and quite exciting for the least!
 
> I am not sure, at this point, if the control codes for the ICOM T81A are 
> available or how they compare to the HF rigs this company makes.  I realize 

Well, it looks like the ICOM T81A is not using the CI-V protocol.
Do you have some protocol specifications coming along with your manual?
Hamlib is not supporting any "clonable" rig yet, but through 
the rig_set_channel() and rig_get_channel(), this would be quite easy.
Maybe some rig_mem_sync() to cope with whole memory only bank transfer
would help. To be designed..

> the control codes in a case by case fashion.  So this project is a 
> commendable example of putting the horse before the cart, in my opinion.

Well, thank you. The Hamlib team is pleased to hear that, even though
there's still lot of work to be done (esp. testing on different rigs). 
We hope to see plenty of user applications using Hamlib. Some of them
are already working on it: kontakt, groundstation, etc.

Cheers,
Stephane / F8CFE

Re: [Hamlib-developer] new to project--want to help

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

On Tue, Oct 09, 2001 at 10:16:29AM -0400, Larry Braden wrote:
> Hello,
> 
> My name is Larry Braden.
> 
> I would like to help with this project, however I am not sure at this point 
> in what capacity.  I will be looking over the work that is done so far.

Hi Larry.

Welcome to Hamlib!  I'm sure Stephane has a number of things to be done,
not all of which require knowledge of C programming.  Just testing and
trying to get things going on your radio is often a big help.

> My motivation in subscribing to the list come from owning an ICOM T81A and 
> finding the software/hardware necessary for programming the radio a bit 
> expensive and, to say the least, I am a bit miffed that the software, at 
> least, is not offered free by the company.  When one buys a radio that is 
> capable of being controlled and/or programmed by a computer --almost a 
> necessity given the features in some cases-- then it should be included.  To 
> include the software and/or programming cables would help sell more units of 
> the radio, imho which would more than outweigh offering necessary items as 
> accesories for additional payment.
> 
> Additionally, I believe that linux--in particular--offers users of ham radios 
> and computer hardware a great deal of freedom to come up with new, more 
> convenient and powerful, means to do high performance radio.  What hams 
> actually do with radios is not always anticipated by radio manufacturers.

Ahhh, we of like minds.  Welcome to the world of Free Software--an
often loud and somewhat intimidating place (if judged by sites like
Slahsdot).  However, the noise is often passion expressed and in the end 
the code speaks for itself.

> My background is in information technology.  My radio interests are 
> homebrewing, both with tubes and silicon,  and 6 meter band communications.

I have a similar background although different ham interests, such as a
bit of contesting, public service, digital, and FM/repeaters to name a
few.

> I am not sure, at this point, if the control codes for the ICOM T81A are 
> available or how they compare to the HF rigs this company makes.  I realize 
> that this project is dealing primarily with creating a user interface library 
> for developing rig control applications, and that the rig control codes sent 
> to the radio are at another level of an application.   These control codes 
> are accessed as needed and appropriate by the application and the user 
> interface, and thus by switching the codes a generalized user interface 
> library can be used to control almost any radio device.  Very good idea for a 
> number of reasons, and I can see that this would make the development of 
> applications go much faster rather than trying to hang the user interface off 
> the control codes in a case by case fashion.  So this project is a 
> commendable example of putting the horse before the cart, in my opinion.

Actually, this project is focusing on communicating directly with the
radio (or other controllable hardware, rotors, etc.) and providing an 
abstracted rig API.  So, whatever command info you can provide on your 
radio (providing Stephane needs it!) is most welcome.  This isn't a 
flashy project.  Rather it is low level backend type stuff, but for 
folks who like tinkering with hardware too, it's an interesting
project.

I jumped in and volunteered to work on the Web pages and the Hamlib
reference docs.  The Web pages are reasonably up-to-date, but the manual
is a couple of versions behind.  Your feedback to me on these items
would be most helpful, especially the part about getting Hamlib from
CVS in Chapter 1.

Stephane has been doing most of the coding of late.  We haven't heard
from Frank in a while and understand he is quite busy.  Terry has done a
nice job with the Debian packages.  I'm quite busy right now, but the 
weather is supposed to be a bit rainy around here which may give me 
some extra time the next few days to work on the manual.  

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
   Wichita area exams; ham radio; Linux info @  | a terrible resolve".
             http://www.qsl.net/n0nb/           | - Admiral Yamomoto

[Hamlib-developer] new to project--want to help

[Larry B. <lb...@ho...>]

Hello,

My name is Larry Braden.

I would like to help with this project, however I am not sure at this point 
in what capacity.  I will be looking over the work that is done so far.

My motivation in subscribing to the list come from owning an ICOM T81A and 
finding the software/hardware necessary for programming the radio a bit 
expensive and, to say the least, I am a bit miffed that the software, at 
least, is not offered free by the company.  When one buys a radio that is 
capable of being controlled and/or programmed by a computer --almost a 
necessity given the features in some cases-- then it should be included.  To 
include the software and/or programming cables would help sell more units of 
the radio, imho which would more than outweigh offering necessary items as 
accesories for additional payment.

Additionally, I believe that linux--in particular--offers users of ham radios 
and computer hardware a great deal of freedom to come up with new, more 
convenient and powerful, means to do high performance radio.  What hams 
actually do with radios is not always anticipated by radio manufacturers.

My background is in information technology.  My radio interests are 
homebrewing, both with tubes and silicon,  and 6 meter band communications.

I am not sure, at this point, if the control codes for the ICOM T81A are 
available or how they compare to the HF rigs this company makes.  I realize 
that this project is dealing primarily with creating a user interface library 
for developing rig control applications, and that the rig control codes sent 
to the radio are at another level of an application.   These control codes 
are accessed as needed and appropriate by the application and the user 
interface, and thus by switching the codes a generalized user interface 
library can be used to control almost any radio device.  Very good idea for a 
number of reasons, and I can see that this would make the development of 
applications go much faster rather than trying to hang the user interface off 
the control codes in a case by case fashion.  So this project is a 
commendable example of putting the horse before the cart, in my opinion.

Best wishes,

Larry Braden
KC5CWG
Catonsville, Maryland