Re: [Hamlib-developer] TS-870: test 2

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

On Tue, Jan 01, 2002, Joop Stakenborg wrote:
> A happy new year to y'all and here is the result for the second kenwood
> TS-870 test, from the snapshot that Stephane has provided, version number
> is 1.1.3-pre2-pa4tu.
> 
> Some remarks:
> 
> Rigctl has to link with all the separate libhamlib-<rig>.so files,
> so I had to change tests/Makefile.am to something like this:

It's a solution, not the simplest. The best solution would be to have
libtool/automake to be fixed so it searches for modules where there were
installed (this seems to be broken in libtool-1.4.2a).
Hamlib can also take care of this. In the meantime something is
devised, the workaround I would recommand is to set LD_LIBRARY_PATH
to the path where your backend modules are installed:

	export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/lib"

> Secondly, make install fails in the include directory.
> include/Makefile.am has lines like:
> 
> includedir = @includedir@/hamlib
> include_HEADERS = hamlib/rig.h hamlib/riglist.h hamlib/rig_dll.h \
>                 hamlib/rotator.h hamlib/rotlist.h hamlib/rigclass.h
> 
> which causes /usr/local/include/hamlib to be created (correct) and
> header files want to go into /usr/local/include/hamlib/hamlib,
> which fails. The fix is trivial I guess.

Huh!? can you send me some traces and also your autoconf/automake version
numbers? I don't have any header install problems here with
autoconf-2.52-4 and automake-1.5-1.1 (debian woody).

> Now for the good news (tests were done with rigctl):
> 
> set_vfo/get_vfo work! I can use commands like: V VFOA, V VFOB and V MEM.
> set_freq/get_freq work!
> set_mode works: commands like M CW, M USB, etc. work!

That's great news!

> get_mode fails to return the correct answer, although the returned
> strings from the rig are OK. Here is a cut&paste from the session, with
> mode set to CW:
> 
> kenwood_get_mode: unsupported mode 77
> get_mode: error = Invalid parameter
> 
> In fact, every string returned from the rig seems to be right,
> but the answer is still the same: kenwood_get_mode: unsupported mode 77.

77 is the ASCII code for 'M'. So you guessed already what was wrong.
Since I never ever played with the Kenwood protocol, I thought the mode
was returned without the 'MD' prefix. This is now fixed in the cvs rep.

> Thanks for your effort Stephane. I hope this helps.

oh yes, this helps a lot! Thanks!

> I will do some more functionality tests with other commands later
> this week.

Functions and levels can be interresting. Please note the complete
protocol is not implemented yet, and memory handling functions may require 
some work on the API side to cover most needs. Feel free to express your
wishes, comments, etc.


Happy and peaceful new year to every one!

Cheers,
Stephane F8CFE