[Hamlib-developer] Re: hamlib++

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

[this reply has been Cc: to hamlib-developer]

Hi Robert!

> Finally I am running the CVS version of the lib. In my opinion, there are
> many improvements to the lib. You should think of releasing 1.1.2 (or even

I would love to. Unfortunately, libtool seems borken (1.4b2, 1.4.1).
Symptoms are strange.
On my system, during test phase, I do not issue a make install. 
Actually, I'm just setting up LD_LIBRARY_PATH to the various .libs 
subdirectory of each backend and that used to do it. 
However, with recent version of libtool, libltdl does not find 
the .so modules. It looks like I need to provide 2 times the same path
in LD_LIBRARY_PATH to make it work. Well, after all, this must be
the *bleeding* edge of the unstable dist of Debian.

Let's say if libtool is not fixed by next week, I'll downgrade it to 1.4,
loosing temporarly the win32 portability, and make things going on.

> 1.2.0) soon. I am basing my work on hamlib++, which is much more like the
> things I have learned at university (we only do oop on Java there). The
> class-encapsulation should make things a lot easier for application
> programmers (like me :-)).

Like everyone!  hamlib++ is far from complete though..

> Actually, it got on my nerves having to hard-code all backends (1.1.1) and
> calling them in a for loop, then rig_init() the device.
> rig_load_all_backends() was a first step, but I still prefer just creating
> an instance of the desired Rig. Let the lib to the dirty job :-)

yeah, Hamlib 1.1.2 is supposed to take care of that, with automagical
loading (at the cost of riglist.h maintainance).

> There is one thing I have not found out yet: How can I get a list of
> _currently_ supported rigs? I would like to let the user choose his rig
> from a runtime-generated list of available rigs. A list of int values
> should be enough, then I could run through the list and retrieve the
> description strings (but if would be nice to get both at once :-)

Just imagine you dream comes true! Have a look at tests/listrigs.c
This is quite simple. You need to load all the backends, then
rig_list_foreach() will call one of your function for each registered
cap. Simple, effective. (at the cost of loading every backend).

> As far as I could see, the ft847 backend only supports writing to
> the trx. I cannot retrieve data from it. The handbook says how it works,
> but I have not looked at the code that much.

Frank hasn't had enough time to complete the ft847 backend.
He was in the middle of the process of making the backend more generic.
You're more than welcome to get it further. I can help you if you'd like to.

> Last weekend I have spoken with some hams who work with the
> "Funkmessdienst" (those guys who drive around and scan for
> RF troublemakers). He heard of the hamlib and maybe can get me
> access to some Rohde&Schwarz equipment (it has a TCP/IP interface).

That's great! Before having access to the equipment itself, is there
any kind of documentation or a manual about the protocol used 
by these beasts?
 
> How generic do you want the hamlib to become? Rigs, antenna rotors
> planned. I remembered a multimeter of a friend of mine. It has an RS232
> interface. Not sure what it is capable of, though. Perhaps a digi sysop
> wants to read some pins of his serial port. Is that possible? Is it
> desired? Just thinking...

Well, that's for sure I'd like to see Hamlib generic. However, there's no
point in supporting coffee machines in this lib (even though this would
be fun if not useful). So, to my mind, rigs, antenna, frequency counters
like the ones from Optoelectronics, are fine. There's already a freegps
project, so that's all I can see for now. If you have any other idea,
please let us know. But rigs are already dense enough...
 
> 73, Robert
> -- 
> Robert Steinhaeusser, DL1NC / N9KBK                         rs...@su...
> http://1409.org                                   ro...@st...


73, Stephane