hamlib-developer

[Hamlib-developer] Kenwood TH-D7A(G) patch

[Francois R. <fgr...@su...>]

Hello Stephane,

I borrowed a Kenwood TH-D7A(G) to test with Hamlib. Here is a
patch with that works with that radio.  It seems the TH-D7
is not using the same protocol as other radios, 
ie. FQ<CR> compared to FA; for other radios.

It seems that some duplication can be avoided if the
kenwood_transaction is responsible for adding the terminating
character (either, ';' for older radios and <CR> for TH) 
based on the radio being used.

Also, it seems that the *data_len parameter is not returning
any value.  I always get zero length, but the buffer contain 
the correct string.

Hope it helps.

Cheers
  Francois Retief

--
---------------------------------------------------------------------
Electronic Systems Laboratory (ESL)
University of Stellenbosch
South Africa
Tel. +27-21-808-4472

** Developers of the SUNSAT micro-satellite **
http://sunsat.ee.sun.ac.za

[Hamlib-developer] Re: Hamlib and rotators

[Francois R. <fgr...@su...>]

Hello Stephane,

>
> Hmm, the protocol looks simple, but I don't understand why the hell there
> are frequencies and modes to be specified when controlling the rotator.
> Do you have a clue?

The spec was invented by the author of WiSP. WiSP is a PacSat ground 
station program (for Windows).   It includes rotator control, radio 
dopler control and PacSat mailbox functions amongst others.  That is 
why there is both radio and rotator stuff.
 
> Some examples of the EASYCOMM II protocol would help also.
> Maybe you are the right person to implement these backends, and test it
> while you're at it.

I will check-out a fresh copy of the CVS and start hacking.  
Should I create a new directory for rotor backends?

> > The basic capabilities of a rotator will be:
> >
> > Movement range and mode:  Minimum and maximum values of the two axis,
> >       and also where the turn-around point is.
> >         (0-180, 0-360, 180-0-180 or 360-0-360, etc.)
> 
> Hmm, I'm sorry, I don't understand why we need a turn-around point.
> Let's say we have min_elevation/max_el and min_az/max_az, all
> being angles relative to horizon / north. Shouldn't it be enough?
> Or did I miss something?

On second thought, the min/max should be enough. Let's keep it simple 
for a start.

> Another question. If I'm not mistaken, there are rotator controllers and
> rotators being controlled. And a given rotator model can be controlled by
> different models of controllers. So, do you think Hamlib should have a
> database of rotator capabilities on top of the backends (which are for
> controllers) ?

Hmm, not sure, will think about it.  Will get back to you on this one.

> exactly! I've done some work on the rpcrig. Works better, still not
> complete (esp. caps retrieval). Right now, I'm testing "rpc.rigd -vvv"
> setup for use with dummy backend, and "rigctl -vvvv -m  1901 -r localhost"
> in another window.
> Seems okay, please let me know how it goes on your side.

As soon as I looked at the rotator backend stuff, I will check
the RPC.


I have a problem with the current CVS code.  The test programs in the
hamlib CVS works fine.  But when I try to link it to a test program 
(external to hamlib), it complain about:
/usr/local/lib/libhamlib.so: undefined reference to
'lt_preloaded_symbols'

I get the same problem with the AC_LIB_HAMLIB macro.  The problem 
started after the hamlib-1.1.2 release.


Cheers
  Francois Retief

--
---------------------------------------------------------------------
Electronic Systems Laboratory (ESL)
University of Stellenbosch
South Africa
Tel. +27-21-808-4472

** Developers of the SUNSAT micro-satellite **
http://sunsat.ee.sun.ac.za

Re: [Hamlib-developer] Re: Hamlib and rotators

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

On Mon, Dec 31, 2001, Francois Retief wrote:
> The spec was invented by the author of WiSP. WiSP is a PacSat ground 
> station program (for Windows).   It includes rotator control, radio 
> dopler control and PacSat mailbox functions amongst others.  That is 
> why there is both radio and rotator stuff.

This is going to be troublesome for Hamlib, because the rotator frontend
has strictly no idea of operating frequency. Can we just pass null freq?

> > Some examples of the EASYCOMM II protocol would help also.
> > Maybe you are the right person to implement these backends, and test it
> > while you're at it.
> 
> I will check-out a fresh copy of the CVS and start hacking.  
> Should I create a new directory for rotor backends?

yep. The rule is to have the backend have the same name as the directory
it lives in. So if EASYCOMM I and EASYCOMM II are to be in the same
backend, maybe 'easycomm' could be a good candidate.
There's already a 'dummy' rotator backend, so rotctl has something to
chew.

> I have a problem with the current CVS code.  The test programs in the
> hamlib CVS works fine.  But when I try to link it to a test program 
> (external to hamlib), it complain about:
> /usr/local/lib/libhamlib.so: undefined reference to
> 'lt_preloaded_symbols'

I knew it would happen some day. This lt_preloaded_symbols is useful for
statically linked in hamlib backends. I try to find a seamless solution
that would work shared and static, with easy maintenance.
So let's disable it (comment out LTDL_SET_PRELOADED_SYMBOLS in
src/register.c). cvs rep updated.

> I get the same problem with the AC_LIB_HAMLIB macro.  The problem 
> started after the hamlib-1.1.2 release.

ahem, the AC_LIB_HAMLIB from hamlib.m4 has never been tested, and I'm
quite surprised you managed to run aclocal against it without troubles.
Anyway, lt_preloaded_symbols and AC_LIB_HAMLIB are to be fixed.

Cheers,
Stephane

Re: [Hamlib-developer] Kenwood TH-D7A(G) patch

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

On Mon, Dec 31, 2001, Francois Retief wrote:
> I borrowed a Kenwood TH-D7A(G) to test with Hamlib. Here is a
> patch with that works with that radio.  It seems the TH-D7
> is not using the same protocol as other radios, 
> ie. FQ<CR> compared to FA; for other radios.

Great! I love patches! And yours is now commited to cvs.
You're right, the TH-D7 is using a protocol similar to the Kenwood table
top rigs, but with some changes. It turns out I own a TH-F7E, and even
though I don't have the protocol specs, it looks like the commands are the
same as the TH-D7, hence the kenwood/th.c file.

> It seems that some duplication can be avoided if the
> kenwood_transaction is responsible for adding the terminating
> character (either, ';' for older radios and <CR> for TH) 
> based on the radio being used.

sure! Actualy, I don't like at all kenwood_transaction().
So feel free to crush it and rewrite it correctly, in the light of the
different Kenwood protocol variants. If not sure how to do it, we can
discuss about it. That'd be neat if kenwood_transaction could handle
rigs error codes without having to pass an ack_buf. Thus when no response
is expected, ack_buf = NULL would be better than ack_len = 0.

> Also, it seems that the *data_len parameter is not returning
> any value.  I always get zero length, but the buffer contain 
> the correct string.

okay, time to take a closer look.


Thank you very much for the patch and the help

Cheers,
Stephane