hamlib-developer — hamlib developers forum

Re: [Hamlib-developer] hamlib and TS870

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

On Sun, Dec 09, 2001, Joop Stakenborg wrote:
> aba@pc3:~$ rigctl -vvvvv -m 210 
> TX 3 bytes
> 0000	 46 52 3b	FR;
> RX 1 bytes
> 0000	 d2	.
> RX 1 bytes
> 0000	 fb	.
> fread_block: timedout after 0 chars
> Opened rig model 210, 'TS-870S'
> 

FR; command should retrieve current VFO (kenwood/kenwood.c:kenwood_get_vfo)
However, the kenwood protocol does not use 8 bits characters, which
is rather suspect. Anyway, it seems to receive something since it tries
to reply (certainly an error code, but with wrong speed?).

> I have tried to talk to my transceiver with minicom, but I never get
> anything back, whatever communication parameter I try.

Maybe trying with some other known-to-work CAT program would help.
Easy to find under DOS/win32, not so easy under Linux...

> >From the tests I get the impression that serial line speeds do not match
> the communication paramaters of the transceiver.
> is this correct?

This could be the most reasonable explanation. Have you tried playing
with speed/handshake/parity/number of data and stop bits/ etc. ?
Reading kenwood/ts870s.c, it looks like Hamlib is setting up the serial
port to 57600bps, 8N1, no parity.
Maybe the TS-870 cannot cope with too high speed?

Note: whatever speed value you setup the port, Hamlib reconfigures it.
So the TS-870 should be setup to 57600bps.

> Maybe I should give kontakt a try.....

I'm afraid you won't have more luck since kontakt is based on Hamlib.
However, I'm almost sure Robert would be happy to have some feedback
on his development.

Please, let me know if the speed setup can help in solving your problem.

73, 
Stephane F8CFE

Re: [Hamlib-developer] hamlib and TS870

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

On Sun, 9 Dec 2001 14:58:55 +0100
Stephane Fillod <f4...@fr...> wrote:

> On Sun, Dec 09, 2001, Joop Stakenborg wrote:
> 
> Can you run rigctl with "-vvvvv" option and report the traces please?
> This will tell us what's Hamlib is doing, and what characters are
> exchanged on the serial line. 
> 

aba@pc3:~$ rigctl -vvvvv -m 210 
rig:rig_init called 
rig: loading backend kenwood
kenwood: _init called
rig_register (203)
rig_register (204)
rig_register (216)
rig_register (210)
rig:rig_open called 
TX 3 bytes
0000	 46 52 3b	FR;
RX 1 bytes
0000	 d2	.
RX 1 bytes
0000	 fb	.
fread_block: timedout after 0 chars
Opened rig model 210, 'TS-870S'

Rig command: f
TX 3 bytes
0000	 46 52 3b	FR;
RX 1 bytes
0000	 d3	.
RX 1 bytes
0000	 fb	.
fread_block: timedout after 0 chars
Frequency: 4611874313014867991get_freq: error = Communication timed out

Rig command: F 14.000
TX 3 bytes
0000	 46 52 3b	FR;
Frequency: RX 1 bytes
0000	 92	.
RX 1 bytes
0000	 fb	.
fread_block: timedout after 0 chars
set_freq: error = Communication timed out

Rig command: q
rig:rig_close called 
rig:rig_cleanup called 
aba@pc3:~$


> Eventually, if you suspect a problem with the serial cable, you may try to
> talk directly to the rig with minicom, and issue simple commands like 
> 'ID'.
> 

The serial line is OK, I have tested it with a modem. It is a 9 wire
cable to a 9 pin connector at both ends.
I have tried to talk to my transceiver with minicom, but I never get
anything back, whatever communication parameter I try.
From the tests I get the impression that serial line speeds do not match
the communication paramaters of the transceiver.
is this correct?

Maybe I should give kontakt a try.....

Joop

Re: [Hamlib-developer] hamlib and TS870

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

On Sun, Dec 09, 2001, Joop Stakenborg wrote:
> Hello Stephane and others,
> 

Hi Joop,

> I have tried to use rigctl with my TS-870. According to the menu on
> the TS-870, communication is set to 9600 bps with 1 stopbit. I have
> tried with the default com-port settings on my linux-box and with
> 'setserial /dev/ttyS0 baud_base 9600'. Both with the same results:
> 
> aba@pc3:~$ rigctl -m 210
> fread_block: timedout after 0 chars
> 

Can you run rigctl with "-vvvvv" option and report the traces please?
This will tell us what's Hamlib is doing, and what characters are
exchanged on the serial line. 

Eventually, if you suspect a problem with the serial cable, you may try to
talk directly to the rig with minicom, and issue simple commands like 
'ID'.

> [ctrl led on the rig switches on]
> 
This is a goood sign anyway.

> Do I need to dive into the source code? Did I overlook something?

Not necessarily. This is just this backend has never been tested :-)

Cheers,

Stephane F8CFE

[Hamlib-developer] hamlib and TS870

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

Hello Stephane and others,

I have tried to use rigctl with my TS-870. According to the menu on
the TS-870, communication is set to 9600 bps with 1 stopbit. I have
tried with the default com-port settings on my linux-box and with
'setserial /dev/ttyS0 baud_base 9600'. Both with the same results:

aba@pc3:~$ rigctl -m 210
fread_block: timedout after 0 chars

[ctrl led on the rig switches on]

Rig command: f
fread_block: timedout after 0 chars
Frequency: 4611874313014867991get_freq: error = Communication timed out

Rig command: F 14.023
Frequency: fread_block: timedout after 0 chars
set_freq: error = Communication timed out

Rig command: q
aba@pc3:~$


Do I need to dive into the source code? Did I overlook something?
Thanks,

Joop PA4TU

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

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

On Wed, 28 Nov 2001, Stephane Fillod wrote:

> Let's consider the IC-275/475 are now supported... well yet to be tested!

Whoa, that was fast. Now I have to find out what hardware I need for the
interface.

> Any taker for the FT990?

After I've had a look why the FT847 get_* stuff doesn't work here, I might
as well get into the rest ;-) But no promise yet. I'll have to check for
the interface, too.

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

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

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

On Tue, Nov 27, 2001, Robert Steinhäußer wrote:
> 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 ;-)

Let's consider the IC-275/475 are now supported... well yet to be tested!
Any taker for the FT990?

73 de Stephane

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

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

Stephane,

Thanks! That worked.

I did a configure with --prefix as you suggested, then a make install.

I shouldn't have been trying to avoid doing that.

John

rm -f testrig testrig.o

export HAMLIB=/usr/local/hamlib/
export LD_LIBRARY_PATH=${HAMLIB}/lib:.

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

./testrig


>From: Stephane Fillod <f4...@fr...>
>To: Ham...@li...
>Subject: Re: [Hamlib-developer] How to link in binary
>Date: Tue, 27 Nov 2001 19:12:27 +0100 (MET)
>
>John Roberts wrote:
> >
> > 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
>                                         ^^^^^^^^^^^^^^^^
>If you're not using hamlib-devel RPM, then use "-L${HAMLIB}/.libs"
>instead of -L${HAMLIB}/src. This is what libtool would do for rigctl.
>
>Anyway, I strongly recommends using the hamlib-devel RPM in your case,
>unless you want to help in bleeding edge Hamlib development. Nevertheless,
>with the cvs version, it's still better to configure hamlib with
>--prefix=/usr/local or whatever (and set -L/usr/local/lib accordingly)
>and then "make install".
>
>Let me know how it goes. If bands are still open, we can have a sked.
>
>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

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

John Roberts wrote:
>
> 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
                                        ^^^^^^^^^^^^^^^^
If you're not using hamlib-devel RPM, then use "-L${HAMLIB}/.libs"
instead of -L${HAMLIB}/src. This is what libtool would do for rigctl.

Anyway, I strongly recommends using the hamlib-devel RPM in your case,
unless you want to help in bleeding edge Hamlib development. Nevertheless,
with the cvs version, it's still better to configure hamlib with 
--prefix=/usr/local or whatever (and set -L/usr/local/lib accordingly) 
and then "make install".

Let me know how it goes. If bands are still open, we can have a sked.

73, Stephane

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