hamlib-developer — hamlib developers forum

Re: [Hamlib-developer] ICOM 735 and other radios .... can I help?

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

On Wed, Sep 12, 2001, dar...@bt... wrote:
> I have just joined the forum and am interested in testing the libs on a
> variety of other radios. 

Welcome Darren. Hamlib was just expecting hams like you!
Sorry for the late answer, I was in vacation. What sad news are coming
from USA :(  Our friends over there know already how we stand together.

> I am interested in starting with the Icom 735 for the development of an open
> source Web-based radio control project (which doesn't seem to exist). I have
> access to the following HF radios which may help the team. They are: 
> 
> FT1000D 
> FT1000MP 
> FT990 
> IC775 
> 
> With work I can get others (HF and VHF) but if I can get the IC735 going
> that will be a start. 

Wow! That's terrific. Actually, what's lacking to Hamlib is testing.
That's going to be of great help. Have you access to a Kenwood rig?
BTW, the Web-based radio control project looks quite interresting too.
We'll discuss that later. If it's a sourceforge project, don't forget
to give us its name on this forum.

> I have already started using the libs on a development platform, but haven't
> found much on how to "add a new radio" to the sources. Has anyone got a
> "dummy" guide to adding a new radio in? I'd guess my skill level is beginner
> to intermediate in terms of C/C++, Linux but am always prepared to read. 

So you're ready to go. I have some internal notes on how to add a new backend,
and how to add a new rig to an existing backend. Yeah, I should clean that
up a bit, format in HTML and release it in the Documentation corner..
In the mean time, I've commited of the IC-735 and IC-775 
to the CVS repository. Let me know how the IC-735 works with Hamlib, 
this is the oldest CI-V rig from Icom, and it has some particularities.

Cheers,

73, Stephane - F8CFE

[Hamlib-developer] ICOM 735 and other radios .... can I help?

[<dar...@bt...>]

Hi All! 

I have just joined the forum and am interested in testing the libs on a
variety of other radios. 

I am interested in starting with the Icom 735 for the development of an open
source Web-based radio control project (which doesn't seem to exist). I have
access to the following HF radios which may help the team. They are: 

FT1000D 
FT1000MP 
FT990 
IC775 

With work I can get others (HF and VHF) but if I can get the IC735 going
that will be a start. 

I have already started using the libs on a development platform, but haven't
found much on how to "add a new radio" to the sources. Has anyone got a
"dummy" guide to adding a new radio in? I'd guess my skill level is beginner
to intermediate in terms of C/C++, Linux but am always prepared to read. 

Thoughts appreciated, and thanks again to the team for starting this one off
- it looks good! 

Regards, 

Darren - G0WCW 
(<http://193.113.176.62/mdxcg>) 

(This is a copy of the forum posting I put up earlier)

[Hamlib-developer] Re: hamlib development

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

Ah, perhaps I have found the problem: a "cvs update" instead of "cvs co".
The "co" now also got me the new directories. The ./configure now works,
but "make" fails again:

---
cd . && aclocal
aclocal: couldn't open `configure.in': No such file or directory
make: *** [aclocal.m4] Error 2
---

On Fri, 24 Aug 2001 f4...@fr... wrote:

> My guess is that's related to the version of autoconf/automake/libtool.
> see below.
>
> Okay, here we go. Hamlib-1.1.1 has been developped using autoconf 2.13,
> automake-1.4 and libtool-1.3.5 as far as I remember. Well, the big change
> with the CVS rep is we're now using autoconf 2.52, automake-1.4p4(waiting
> for automake-1.5) and libtool-1.4b. Bleeding edges can get really bloody
> sometimes.
> So, the biggest change is between autoconf-2.13 to >2.50. configure.in is
> no more. Since some macros have been redesigned, autoconf maintainers
> decided to rename this file to autoconf.ac, which clears up at the same time
> the ambiguity with Makefile.in and anything.in different purpose extension.

With these tools, I am an absolute beginner. I have been using autoconf
2.13, automake 1.4 and libtool 1.3.5.

> My quick work around consists in creating shell scripts in hamlib root
> directory, with names automake,autoconf,aclocal,autoheader containing
> something like this:
>
>         #!/bin/sh
>         exec ./missing `basename $0` $*

I have tried this, but it makes no difference. For me first tests, I will
stay with the 1.1.1 release. Perhaps I can change that soon.

> I hope we'll see better days soon. Actually, this is my first time
> using autotools, and I'm still learning the arcanes of these very powerful
> tools. In the end, it's worth it: portability of Hamlib to *any* system!

This *will be* the first time for me :-)

Let's set the range of my project first.

We said that I should code a GUI for hamlib? So what would that require?
Some C (ok), Qt, auto-*, what else? What should this GUI be capable of? If
we get that all together, then Kai and me can start making a time schedule
for planning/coding/testing/... (after all, I should learn that here as
well :-).

> > I just read the FT847 manual and found out it only needs a nullmodem
> > cable
> > for CAT operations. I might be lucky and have a ready cable in the
> > shack;
> > I'll go and test it
>
> Fine business Robert, as would say our dear GB friends. If you don't manage to
> to build the CVS version, and still want to do a  quick test,
> hamlib-1.1.1 should be okay with the FT847. Frank has tested it.
> You may run rigtest and rigctl in the tests/ subdir. Note with 1.1.1,
> you have to modify the C file to specify you rig number.
> Also, if you wanna test without installing Hamlib, you'll have to
> set your LD_LIBRARY_PATH accordingly. Provided topsrc is an env variable
> holding the path of the Hamlib source dir, add
> $(topsrc)/src/.libs:$(topsrc)/yaesu/.libs:$(topsrc)/anyrig/.libs to it.
> Hopefully, this LD_LIBRARY_PATH trick won't be needed in future versions of
> automake/libtool.

On Friday I got our TNC to work :-) Today I'll get to that cable.

> Let me know how far you get. I'll be out of town this week-end, so we'll
> have to postpone the (still unsuccessful)sked to next monday. I'm not very
> used to HF bands, but I'm learning. With my poor conditions (end-fed antenna),
> I've made QSO with 4X this week, and KA1 in CW yesterday night (too bad this
> guy didn't know what QRS means). Exciting sure, but there's room for
> improvements. Once I have work out this, maybe we can establish
> a weekly Hamlib net!

Antenna here at DK0TUX is almost the same as yours with no room on the
roof for improvements.

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

[Hamlib-developer] Re: hamlib development

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

[message Cc: to hamlib-developer for insight on autoconf]

Robert Steinhaeusser wrote:
> The hamlib-1.1.1-release compiles fine, but I've had problems with the
> current CVS version. configure stopps:
> > config.status: error: cannot find input file:
> winradio/linradio/Makefile.in

That's really weird. Can you check, right after a fresh check out, 
if winradio/linradio/Makefile.in and kachina.Makefile.in are missing?

My guess is that's related to the version of autoconf/automake/libtool.
see below.

> > reiner:/usr/src/hamlib # make
> > cd . && automake --gnu Makefile
> > automake: couldn't open `configure.in': No such file or directory
> > make: *** [Makefile.in] Error 2
> > reiner:/usr/src/hamlib #

Okay, here we go. Hamlib-1.1.1 has been developped using autoconf 2.13,
automake-1.4 and libtool-1.3.5 as far as I remember. Well, the big change
with the CVS rep is we're now using autoconf 2.52, automake-1.4p4(waiting
for automake-1.5) and libtool-1.4b. Bleeding edges can get really bloody 
sometimes.
So, the biggest change is between autoconf-2.13 to >2.50. configure.in is
no more. Since some macros have been redesigned, autoconf maintainers
decided to rename this file to autoconf.ac, which clears up at the same time
the ambiguity with Makefile.in and anything.in different purpose extension.

So if you'd like to tinker with configure.ac or any Makefile.am files,
you have to upgrade to these latest versions. Now, for those who are
not interrested in Hamlib maintenance, just testing, I have no easy
solution for you yet (sorry). The best one would be to have an option 
to pass to configure, and generate Makefiles which won't try to run
autoconf/automake on their own (kind of --no-recheck). Please, if you 
know how to do this, let me know. My quick work around consists in creating 
shell scripts in hamlib root directory, with names 
automake,autoconf,aclocal,autoheader
containing something like this:

        #!/bin/sh
        exec ./missing `basename $0` $*

NB: libtool-1.4b-3 (debian) works fine under Linux, but appears to break
compilation under other systems (OS X, cygwin). Error is "LT_EMALLOC used with
wrong number of args". Hopefully libtool-1.5 will come out before hamlib-1.1.2. 
In the meantime, help is more than welcome!

I hope we'll see better days soon. Actually, this is my first time
using autotools, and I'm still learning the arcanes of these very powerful
tools. In the end, it's worth it: portability of Hamlib to *any* system!

> I just read the FT847 manual and found out it only needs a nullmodem
> cable
> for CAT operations. I might be lucky and have a ready cable in the
> shack;
> I'll go and test it

Fine business Robert, as would say our dear GB friends. If you don't manage to
to build the CVS version, and still want to do a  quick test, 
hamlib-1.1.1 should be okay with the FT847. Frank has tested it.
You may run rigtest and rigctl in the tests/ subdir. Note with 1.1.1,
you have to modify the C file to specify you rig number.
Also, if you wanna test without installing Hamlib, you'll have to
set your LD_LIBRARY_PATH accordingly. Provided topsrc is an env variable
holding the path of the Hamlib source dir, add 
$(topsrc)/src/.libs:$(topsrc)/yaesu/.libs:$(topsrc)/anyrig/.libs to it.
Hopefully, this LD_LIBRARY_PATH trick won't be needed in future versions of 
automake/libtool.

Let me know how far you get. I'll be out of town this week-end, so we'll
have to postpone the (still unsuccessful)sked to next monday. I'm not very
used to HF bands, but I'm learning. With my poor conditions (end-fed antenna),
I've made QSO with 4X this week, and KA1 in CW yesterday night (too bad this
guy didn't know what QRS means). Exciting sure, but there's room for 
improvements. Once I have work out this, maybe we can establish
a weekly Hamlib net!


73, Stephane

Re: [Hamlib-developer] Project state?

[Kai A. <ka...@su...>]

Hi Stephane!

On Wed, Aug 08, 12:03, Stephane Fillod wrote:
 
> Sorry for being quiet those past days, I had to do one last effort
> to get my "general" license (I was a "tech no-code" beforehand).
> And yes, I got it! By picking correctly at 12wpm, my call sign
> went up from F4CFE to F8CFE! That's going to be cool for the skeds..

Congrats! How about a sked in the near future?

> On Thu, Aug 02, 2001, Kai Altenfelder wrote:
> > how is the actual state of hamlib? Are there any sub-projects that could
> > be worked on by our current student apprentice?
>  
> I can see some sub-projects that an apprentice could take care of.
> Of course, he/she would have to be familiar with Ham radio or SWL.

He is an active ham, of course.

> One task could be backend development/testing, provided the apprentice
> owns or has access to a rig. If it's not the case, he/she could

He could use our club station's trx here in the company, a FT-847.

> eventually work on the development of a rig GUI. To be defined.

That sounds interesting.

> And the Hamlib web site would need a good refresh too.

Nope, it needs to be a programming project that is adequate for a student
of computer science. Maintaining a website is not what we thought of. ;-)
 

Regards, Kai
-- 
Kai Altenfelder, SuSE GmbH, Schanzaeckerstr. 10, D-90443 Nuernberg
Tel.: +49-911-74053-0, Fax:  +49-911-74053-489,  EMail: ka...@su...
Ham: DL3LBA / DK0TUX / DN1TUX           GnuPG public key available 

Re: [Hamlib-developer] Project state?

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

On Wed, Aug 08, 2001 at 09:04:45AM +0200, Stephane Fillod wrote:
> And the Hamlib web site would need a good refresh too.

Certainly!

I had hopes that I could devote more to that than I have and this summer
has been particularly hectic.  So if someone wishes to step forward and
grab the web pages, that would suit me.  Also, I have some preliminary
docs in DocBook SGML format that someone could expand on and develop
further.  So these projects are available for further development if
anyone is interested.

I do hope to contribute to hamlib, but right now I don't have the free
time I did last winter.

73, de Nate >>

P.S. Congrats on the upgrade, Stephane!

-- 
 Wireless | Amateur Radio Station N0NB          | "None can love freedom
 Internet | n0...@ne...               | heartily, but good
 Location | Bremen, Kansas USA EM19ov           | men; the rest love not
   Wichita area exams; ham radio; Linux info @  | freedom, but license."
             http://www.qsl.net/n0nb/           | -- John Milton

Re: [Hamlib-developer] Project state?

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

Hi Kai,

Sorry for being quiet those past days, I had to do one last effort
to get my "general" license (I was a "tech no-code" beforehand).
And yes, I got it! By picking correctly at 12wpm, my call sign
went up from F4CFE to F8CFE! That's going to be cool for the skeds..

On Thu, Aug 02, 2001, Kai Altenfelder wrote:
> how is the actual state of hamlib? Are there any sub-projects that could
> be worked on by our current student apprentice?
 
I can see some sub-projects that an apprentice could take care of.
Of course, he/she would have to be familiar with Ham radio or SWL.
One task could be backend development/testing, provided the apprentice
owns or has access to a rig. If it's not the case, he/she could
eventually work on the development of a rig GUI. To be defined.
And the Hamlib web site would need a good refresh too.

Does anyone else has another idea? What do you think?


Cheers,
-- 
Stephane

Re: [Hamlib-developer] MAC OS X port

[Stephane F. <ste...@in...>]

Hi Jim!

On Tue, Aug 07, 2001, Jim Weathers wrote:
> I have been searching for a good project to get me started programming 
> on this beastie,
> something to go with the ham hobby.   And hamlib looks like it will have 
> a lot of potential
> for some really useful software for the Mac ham community.
 
That's great idea! I've been waiting for this moment for so long,
first to have someone porting hamlib to something other than Linux
(we're not Linux centric after all), and give it a go on a rig other
than ic706 or yaesu (untested on kenwood!).

> My first thought was to get it to build, but I ran immediately into a 
> curious gotcha:
> Apple has used an old version of FreeBSD as a base, so signal.h is 
> pre-Posix.
 
Hmmm, could you show us an excerpt of the compilation errors?
And maybe attaching your signal.h file would help for us to help you.
And don't worry, the signal stuff is only useful for the asynchronous
event hanlding (i.e. transceive mode).
Do you have a /dev/ttyS0 on Mac OS X? Are you already able, using
a terminal emulation program, to send commands to your rig?

> Finally, the idea is to use rigclass.cpp as a model for creating similar 
> objects
> callable (messageable?) from Objective C.   Then the real fun can begin: 
> making
> a gui for a rig (my TS-450) or two.
 
rigclass.cpp is far from complete yet, but if you're familiar with OOP,
that's the best way to bring your knownledge in designing the hamlib++ API
(and making it more Objective C friendly at the same time).

In the mean time, I'm going to create a backend for the TS-450 so it's more
confortable for you to play with it. However, I'll need the id of that rig.
As you may know, every Kenwood model return a unique id to the "ID"
remote command. For example TS870S has 15. Don't worry if you can't find it,
it's not vital for the backend to work.

I have to admit I am a bit excited at the idea to see if Hamlib is really
portable (seems not right now because of signal handling, hi), see it run
on Mac OS X which is a cool system, and check if the stuff I wrote for the
Kenwood backend is complete rubish (never tested!).
Let me know if you are using the CVS repository, it's very handy for
beta testing. Anyway Hamlib 1.1.2 is not so far now (1 week or so).

Welcome on board Jim, and feel free to ask any question, and post any remark.
If you have an account on Sourceforge, I can add you to the developer
team. It's not well paid, but very rewarding in fun!

Cheers
-- 
73 de F8CFE / Stephane


PS: Did I told you dear Hamlib fellows I got my "general" license last Friday?
    In France, we have only "tech no-code" and "general" license, so I went up
    from F4CFE to F8CFE, and by succeeding the 12wpm test I've been granted 
    the use of the HF bands. I'm not QRV yet, but that gonna be nice 
    for some skeds soon..

[Hamlib-developer] MAC OS X port

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

Hi:

I have been searching for a good project to get me started programming 
on this beastie,
something to go with the ham hobby.   And hamlib looks like it will have 
a lot of potential
for some really useful software for the Mac ham community.

My first thought was to get it to build, but I ran immediately into a 
curious gotcha:
Apple has used an old version of FreeBSD as a base, so signal.h is 
pre-Posix.

I'm going to get with some of my Unix mentors and see if we can get 
around this
issue, unless someone here can provide a Q&D solution.

Once we get past this point, with any luck, I'll get some libraries 
built and be able
to verify the functionality.  I'm currently not sure about the serial 
interface for OS X,
and that's a bridge I'll just have to burn when I get to it.

Finally, the idea is to use rigclass.cpp as a model for creating similar 
objects
callable (messageable?) from Objective C.   Then the real fun can begin: 
making
a gui for a rig (my TS-450) or two.

Comments and suggestions on any of this would be welcome.

73, de N4RSE.

jim.

[Hamlib-developer] Project state?

[Kai A. <ka...@su...>]

All,

how is the actual state of hamlib? Are there any sub-projects that could
be worked on by our current student apprentice?

Regards, Kai
-- 
Kai Altenfelder, SuSE GmbH, Schanzaeckerstr. 10, D-90443 Nuernberg
Tel.: +49-911-74053-0, Fax:  +49-911-74053-489,  EMail: ka...@su...
Ham: DL3LBA / DK0TUX / DN1TUX           GnuPG public key available 

[Hamlib-developer] Re: [Orsd-discuss] What about Hamlib?

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

[message crossposted to hamlib-developer mailing list]

On Thu, Jul 05, 2001, Terje Elde wrote:
> 
> > Looks like you're about to develop something already existing. Have you
> > checked out Hamlib lately? We're just neighbors on sourceforge! 
> > 
> > 	http://sourceforge.net/projects/hamlib
> > 
> > We have abstracted ports (serial, net, etc.), a frontend/backend approach,
> > capability aware, loadable on demand with dlopen, works under Linux/POSIX
> > and Win32 DLL as well (yes, you read it right, module loading works under
> > Win32 with libtool magic!). 
> > BTW, we're not Ham centric, besides Icom/Kenwood/Yeasu.. support, backends
> > already exist for pcr1k, Winradio, AOR, etc. Our design is Open, as is our
> > code (GPL/LGPL). 
> 
> Impressive driver-range.  I'd be very interested in hearing more about how
> you're doing this.  One of the things we have specific focus on is to provide
> abstraction between the driver and the applications, allowing the applications
> to work any radio without caring about driver-specific issues.
  
Surprisingly enough, we have quite the same focus, i.e. to provide
abstraction between the driver and the applications. 

Let's take an example: your application wants to change the frequency 
of the current VFO of the radio, and set it to 88.9MHz.
In the application, whatever radio you use, you will call Hamlib function:

	rig_set_freq(my_rig, RIG_VFO_CURR, 88900000);

where 'my_rig' is a handle of type RIG* for your opened radio, much like FILE*
type arguments are to file buffered functions (fopen/fread/fwrite/etc.).
In fact, Hamlib relies on a frontend/backend approach. The frontend
provide the Hamlib API, and can be recognized by the rig_ prefix to
all the symbols. Hidden behind these wrappers are the backends,
which actualy implements the driver-specific stuff. 

So, in our example, my_rig would have been initialized (rig_init) and opened
(rig_open) in order to attach the handle to a backend, and then open the port
(whatever it could be, serial, net,..) and communication to the radio.
If you have a look at 'struct rig' (in hamlib/rig.h), you'll see 
a pointer to a 'struct rig_caps', which gather the capabilities of the rig
("herited" from backend).
So, the rig_set_freq function looks pretty much like this:

  int rig_set_freq(RIG *rig, vfo_t vfo, freq_t freq)
  {
	if (!rig || !rig->caps)
		return -RIG_EINVAL;	/* invalid arg */
	if (!rig->caps->set_freq == NULL)
		return -RIG_ENAVAIL;	/* capability not available */

	return rig->caps->set_freq(rig, vfo, freq);
  }

Actualy, it's a bit more complex because of rig that cannot target
a VFO, and other details. But I think you get the point.

> > The core library is written in C for portability/interoperability (esp. when
> > it comes to dlopening), but there's already C++ bindings available for
> > user/GUI development. And there's still a lot to do, the API are not carved
> > in stone yet! Comments are very welcome. 
> > 
> > Maybe we could share our ideas in a single and fun project, for the benefits
> > of all. What do you think? 
> 
> Well, C is my preferred language, though some of us are C++ users.
> 
> Then there's the issue of licensing.  I for one would like to see commercial
> vendors being able to take advantage of the software, and integrate it into
> their own products and solutions.  That's often not possible with GPL/LGPL,
> and I'd really rather prefer a BSD license...
 
I for one too, would to see commercial vendors interrested in Hamlib.
And there's no need to abandon software with a BSD license. Starting 
from Hamlib-1.1.2, all the libraries will be converted to LGPL'ed, which grant
user applications the right to be released under any license of their choice.
As as matter of fact, I think that no _GPL_'ed code will remain in Hamlib.

> Other than that I think it would it be great if we could put all of our heads
> together and see what we can come up with.

yeah! great! the more, the merrier!

> Let me warn you though, we're definitively in the earlier stages.
> 
 so are we. untested stuff (esp. backends), still outlining the API,
 but since there's no user-apps yet, we're free to fiddle it!

> Thanks, and sorry for the late reply,
> Terje

No problem, we too are doing this on our free time, 
so this has to be fun!

Cheers,
-- 
Stephane

[Hamlib-developer] LGPL and other stuff

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

Hello there,

As the subject says it, I think we should consider changing the license
Hamlib is released under, from GPL to LGPL. This would make more sense
to the library, I mean the frontend, at least. Each backend would
remain free to be released under whatever license the owner decide
to choose. Personaly, all the backend I wrote will be changed to LGPL
in the next commits.
This is to ensure more acceptance and availability in the various
Ham applications out there.
Let me know what is your feeling on the subject.

Also, some of you may have noticed looking at the cvs-log, Hamlib gained 
some new cool features. Application writers will be happy to hear
the birth of C++ and tcl/tk bindings. I need help on API design, so
tell me how you want it to be or better, join devlopment!
Well, the new port_t type ensure more flexibility, esp. when supporting
RIG/DCD/PTT serial comms. Hamlib is has now primitives to probe a rig
and try to guess its model number, more testing need though (other than Icom).
Besides other API updates, the big news is here: Hamlib works under Win32,
I means with backend DLL dlopen'ing! There're still some rough corners,
but hey, that's cool to benefit from both worlds!
Documentation has not been forgotten, hamlib-doc style comments have
been converted to doxygen style (http://www.doxygen.org). This will allow
us more flexible and powerful API documenting. Contribution welcome!

Well, hope to hear from you soon, may you not be too busy.
I think 1.1.2 is close now, as soon as I have some .spec file ready
to be able to generate RPMs. deb would be cool too, but I don't know yet
how this works (shame on me who runs on debian!).

As usual, comments/feedback/ideas/etc. are very welcome!

Cheers,
-- 
Stephane

[Hamlib-developer] Hamlib 1.1.1 released

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

Good news everyone!

Hamlib-1.1.1 has been released. This version controls more radios,
with an extended API to cover the capabilities commonly found on latest
rigs.

Event though it's still alpha, various applications can already make use of it 
(e.g. band scope, psk31 AFC, doppler compensation, early memory mgmt, etc.)
See <http://sourceforge.net/projects/hamlib> for details. 

The library has been tested against FT747, FT847 (Yaesu CAT) and IC706MkIIG
(CI-V) rigs. Backends exists for TS-870S (Kenwood CAT), AR-8200 (AOR), 
WR-1550 (LiNRADiO) and PCR-1000 (PCR).
Current status can be found at http://hamlib.sourceforge.net/hamlibsupport.html

Plan for 1.1.2:
* Enter every models of supported backends: Icom, Kenwood, AOR, WiNRADiO, PCR
* start support for new backends where doc available (Alinco, TenTec, ...)
* shared module rework: simpler and better portability among OSes
* extend API as needed
* tcl/tk wrapper, Python? Perl?

Please, test it out and report to ham...@li...
Developers are also invited to join the Hamlib team by subscribing to this
mailing list.

Have fun and let us know!

73's de Frank Singleton (vk3fcs/km5ws) 
     and Stephane Fillod (f4cfe) 

Re: [Hamlib-developer] new release?

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

On Mon, May 21, 2001, Frank Singleton wrote:
> 
> > Frank, I think it's time for a new release. You seem to run out
> > of time, so let me know if you want me to convert the ft847 caps
> > to the new style. 
> 
> Yes please !!!!!!!! I got through the FT747 but work has me
> burning some serious hours at the moment.
> 
 consider it done! double check it if you have time..

> >Once this is done, we can give birth to hamlib-1.1.1.
> 
> I was thinking on a release this week, say Fri/Sat. 25th or 26th.
> 
  Sounds great!

> Are make dist and make distcheck working still ?
> 
  so far, it is working here.

> Have we thought about a spec file for our rpm buddies ?
> 
  I have already some .spec and deb rules, but I reserve them
  for the 1.1.2, with a much simpler backend modules handling 
  (no more explicit rig_load_backend).


BTW, here couple of action to do for the release:

* regenerate ChangeLog
* update NEWS (I'll do it)
* tag the CVS rep with version 'HAMLIB-x-y-z' once we're done with commits
* notify Sourceforge/news, Freshmeat, linux.radio.au
	and mailing list: hamlib-announce, linux-ham, Ham...@qs...

* Update project on sourceforge:
        - Intended Audience: Devloper +Beta testers
        - OS: Posix
* linux.radio.au Linux Hamradio App:
	Hamlib should be listed in the 'rigctl' category, besides 'programming'


To advertise:
- list the rigs supported so far,
- what was major work achieved,
- where we're heading,
- what kind of support we need

> /Frank 
> 

Cheers,
-- 
Stephane

Re: [Hamlib-developer] new release?

[Frank S. <vk...@ix...>]

> Frank, I think it's time for a new release. You seem to run out
> of time, so let me know if you want me to convert the ft847 caps
> to the new style. 

Yes please !!!!!!!! I got through the FT747 but work has me
burning some serious hours at the moment.

>Once this is done, we can give birth to hamlib-1.1.1.

I was thinking on a release this week, say Fri/Sat. 25th or 26th.

Are make dist and make distcheck working still ?

Have we thought about a spec file for our rpm buddies ?

/Frank..

-- 
Cheers / Frank 

73's de vk3fcs & km5ws

[Hamlib-developer] new release?

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

Hi!

Such a long time we haven't seen a release, I'm not sure all the curious hams
out there feel confident enough to use CVS to test our stuff in development.
As a reminder, here is how this can be done:

# Retrieve the sources
  cvs -d:pserver:ano...@cv...:/cvsroot/hamlib login
  cvs -z3 -d:pserver:ano...@cv...:/cvsroot/hamlib co hamlib

# If your firewall block the CVS port, this can be done also this way:
  wget http://cvs.sourceforge.net/cvstarballs/hamlib-cvsroot.tar.gz
  tar zxvf hamlib-cvsroot.tar.gz
  mv hamlib hamlibroot
  CVSROOT=`pwd`/hamlibroot cvs co hamlib

# Then, compile the package
  cd hamlib
  ./configure
  make

Then have a look at programs in the tests directory and please report
on this mailing list how it's working for you.

Frank, I think it's time for a new release. You seem to run out
of time, so let me know if you want me to convert the ft847 caps
to the new style. Once this is done, we can give birth to hamlib-1.1.1.
I have plenty of new stuff waiting to be integrated in hamlib,
like the sparse model ids and seamless backend loading, scan support,
tcl/tk wrapper, rig prober, new port data type, etc.
In the next release, I'd like also to add the support for the 40 or so of
the Icom CI-V models, plus the 10 of AOR, WinRADiO, PCRs, and make progress
on Kenwood. This is needed to make people interrested in Hamlib.
But meanwhile we need an intermediate release.

Nate, I wrote an HTML page (cloned from the USB SANE page) to summarize
the list of supported radios. If you get time, it would be nice to 
integrate it in the set of your already existing HTML pages.
Here is the URL:

	http://f4cfe.free.fr/ham/hamlib/hamlibsupport.html

and the old (to be enhanced):

	http://f4cfe.free.fr/ham/hamlib/rigmatrix.html


Let me know if there's anything wrong, or any quirks in theses.


Cheers,

-- 
Stephane

Re: [Hamlib-developer] CQ CQ hamlib-developers..

[Frank S. <vk...@ix...>]

Stephane Fillod wrote:
> 
> On Sun, Apr 22, 2001, Frank Singleton wrote:
> > >
> > > > Does my yaesu stuff still compile  ok ?
> >
> > Actually, I ran it against my FT747 anf FT847 and it all looked
> > ok .
> 
> Did you ran the last commited version (sunday)?

Hmm  I used the latest CVS prior to sending this original email
response.


> It got the new VFO id design (that can be OR'ed), and pbwidth_t is now
> the filter width in Hz passed to set_mode et al. Grep RIG_PASSBAND_OLDTIME
> and FIXME in the code to see where to update.
> 
> >
> > Yes I agree. But I have an intersting idea .............
> >
>   Sounds like there's some CORBA or RPC in the air....
> 

I have been thinking about that also ....... :-)
Stay tuned !

> [snip]
> > This  way, I dont go blind trying to fill the correct line in the
> > rig_caps struct
> > for a certain function pointer,or freq range list, and I dont care what
> > order they are listed.
> 
> hmm, but it makes code harder to write (type castings, etc.), slowing
> down your app because of lookups, loosing type checking, etc.
> 

lookups probably not too bad (cache hits ) but the type checking
is definitely good to keep , I agree..

> > This way, I dont have to jump over "NULL" entries etc..
> 
> If this is all what's worring you, just follow the winradio/wr1500.c
> example. It makes the code a lot easier to read!
> 

> So what else do we need for an 1.1.1 release?
> Add a couple of set_split_mode and get_split_mode, rig_send_cw,
> remove chan_qty, dtmf_digits, ..
> Any idea?

Let me check it this weekend ..

/Frank..


-- 
Cheers / Frank 

73's de vk3fcs & km5ws

Re: [Hamlib-developer] CQ CQ hamlib-developers..

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

On Sun, Apr 22, 2001, Frank Singleton wrote:
> > 
> > > Does my yaesu stuff still compile  ok ?
> 
> Actually, I ran it against my FT747 anf FT847 and it all looked
> ok .

Did you ran the last commited version (sunday)?
It got the new VFO id design (that can be OR'ed), and pbwidth_t is now
the filter width in Hz passed to set_mode et al. Grep RIG_PASSBAND_OLDTIME
and FIXME in the code to see where to update.

> 
> Yes I agree. But I have an intersting idea .............
> 
  Sounds like there's some CORBA or RPC in the air....
  
[snip]
> This  way, I dont go blind trying to fill the correct line in the
> rig_caps struct
> for a certain function pointer,or freq range list, and I dont care what
> order they are listed.
  
hmm, but it makes code harder to write (type castings, etc.), slowing
down your app because of lookups, loosing type checking, etc.

> This way, I dont have to jump over "NULL" entries etc..
  
If this is all what's worring you, just follow the winradio/wr1500.c
example. It makes the code a lot easier to read!

So what else do we need for an 1.1.1 release?
Add a couple of set_split_mode and get_split_mode, rig_send_cw,
remove chan_qty, dtmf_digits, ..
Any idea?

-- 
Stephane

Re: [Hamlib-developer] CQ CQ hamlib-developers..

[Frank S. <vk...@ix...>]

Stephane Fillod wrote:
> 
> Frank Singleton wrote:
> >
> > I hate excuses, but, I am in the middle of a humungous project at work,
> > for at least the next 2 months or so.
> >
>   we all know what it is.
> 
> > I have CORBA running out of my ears :O
> >
>   Hopefully you will tame the beast :)
> 
>   I envision distributed hamlib applications, interacting
>   through CORBA...
>   no, just kidding (would be cool though with Bonobo :-)


> 
> > Does my yaesu stuff still compile  ok ?

Actually, I ran it against my FT747 anf FT847 and it all looked
ok .


> >
> yep, every time I modify the front-end, I try to keep the CVS rep
> in a compilable state (this is all about total quality ethic, hi).
> Even if backends may not have implementation of the newest features, they
> still support the simple commands (set_freq, set_mode, etc.)
> 
> BTW, I have a batch of frontend updates I've proposed recently on the list.
> Do you think they're OK, and I can go ahead modifying backend ends
> accordingly and commiting in?
> A new version of Hamlib definitely needs to be released soon too!


Yes I agree. But I have an intersting idea .............


Here we are populating an ever growing rig_caps struct, with some
cababilities and function pointers to our API.

Why dont we modify this a little?

Create a list (enum?) of capabilities funtion codes,
and then when we populate our rigg_caps, it actually
consists of a list tuples, appropriately terminated.


The tuple is a function dode, and matching data (or fn pointer).

enum function_capability {
  FC_INIT,
  FC_CLEANUP,
  ..
  FC_RX_LIST,
   ..

  FC_TX_LIST,

  ..
 
   etc..

}


Then ...............

eg:

 Instead of 

<snip>

  ft747_init, 
  ft747_cleanup, 
  ft747_open,				/* port opened */
  ft747_close,				/* port closed */
  NULL,				/* probe not supported yet */

  ft747_set_freq,		/* set freq */
  ft747_get_freq,		/* get freq */
  ft747_set_mode,		/* set mode */
  ft747_get_mode,		/* get mode */
  ft747_set_vfo,		/* set vfo */
  ft747_get_vfo,		/* get vfo */
  ft747_set_ptt,		/* set ptt */
  ft747_get_ptt,		/* get ptt */

  NULL,				/* add later */
  NULL,				/* add later */




<snip>


we have


{ {FC_INIT, ft747_init}, 
  {FC_SET_PTT, ft747_get_ptt,},
  {FC_CLEANUP, ft747_cleanup,}

 .... etc

  {FC_RX_LIST, { { {1500000,1999900,FT747_OTHER_TX_MODES,5000,100000},
/* 100W class */ 
    {1500000,1999900,FT747_AM_TX_MODES,2000,25000},	/* 25W class */
    
    <snip>
    
    {24500000,24999900,FT747_OTHER_TX_MODES,5000,100000},
    {24500000,24999900,FT747_AM_TX_MODES,2000,25000},
    
    {28000000,29999900,FT747_OTHER_TX_MODES,5000,100000},
    {28000000,29999900,FT747_AM_TX_MODES,2000,25000},
    
    RIG_FRNG_END, }}

  }

  { FC_WHATEVER, .. }

   etc..

}


This  way, I dont go blind trying to fill the correct line in the
rig_caps struct
for a certain function pointer,or freq range list, and I dont care what
order they are listed.

This way, I dont have to jump over "NULL" entries etc..

Just some minor tweaks for the backends, and a little for the front
end. :)


Coments ??

Cheers / Frank..

> 
> Cheers,
> --
> Stephane
> 
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> http://lists.sourceforge.net/lists/listinfo/hamlib-developer

-- 
Cheers / Frank 

73's de vk3fcs & km5ws

Re: [Hamlib-developer] CQ CQ hamlib-developers..

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

Frank Singleton wrote:
> 
> I hate excuses, but, I am in the middle of a humungous project at work,
> for at least the next 2 months or so.
> 
  we all know what it is.

> I have CORBA running out of my ears :O
> 
  Hopefully you will tame the beast :)

  I envision distributed hamlib applications, interacting 
  through CORBA... 
  no, just kidding (would be cool though with Bonobo :-)

> Does my yaesu stuff still compile  ok ?
> 
yep, every time I modify the front-end, I try to keep the CVS rep
in a compilable state (this is all about total quality ethic, hi).
Even if backends may not have implementation of the newest features, they
still support the simple commands (set_freq, set_mode, etc.)

BTW, I have a batch of frontend updates I've proposed recently on the list.
Do you think they're OK, and I can go ahead modifying backend ends
accordingly and commiting in?
A new version of Hamlib definitely needs to be released soon too!

Cheers,
-- 
Stephane

Re: [Hamlib-developer] CQ CQ hamlib-developers..

[Frank S. <vk...@ix...>]

Stephane Fillod wrote:
> 
> Hi there!
> 
> I've sent couple of proposals for Hamlib, but received no sign of life.
> Is there anyone left on this list or just running out of time?


Hi Hamlib,

I hate excuses, but, I am in the middle of a humungous project at work,
for at least the next 2 months or so.

I have CORBA running out of my ears :O

Does my yaesu stuff still compile  ok ?

-- 
Cheers / Frank 

73's de vk3fcs & km5ws

Re: [Hamlib-developer] CQ CQ hamlib-developers..

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

Hi Nate,

On Wed, Mar 28, 2001, Nate Bargmann wrote:
> 
> I'm in the middle of moving and am working at a new location.  Even

Hamlib's members all know moving isn't an easy task, and I wish you'll
be doing fine, especially with those biggo aerials :)

Acutualy, your ALPHA version is great. Why don't we make it available
on sourceforge? or at least add a pointer to it?
I know I have some documentation to write, for example about the API,
data structures, etc.. What format would you recommand? which sgml tool set
are you using?


Good luck for your moving, and don't worry, 
there's no hurry for Hamlib!

-- 
Stephane / F4CFE

[Hamlib-developer] riglist.h numbers

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

Hi,

Managing rig numbers in riglist.h with an enum is going to be a mess,
if we don't take an action soon. The problem arise each time someone
insert a new rig number on top of the list (Yeasu, Icom, etc.), 
hence shifting the number of latter ones.
Hamlib needs unique and stable rig IDs among riglist.h revisions.

So I've got the idea of sparse number allocation. 
I think 8 bits for models within a brand class should cover our future
needs. Higher significant bits will then be used to code the brand.
Sorry, enums have to be banned in favor of #define.

Here's a proposal:

	#define MAKE_RIG(c,m) (((c)<<8)|(m))
	
	/* class 0 reserved for dummy */
	
	#define RIG_MODEL_DUMMY MAKE_RIG(0,0)
	
	/* Yeasu */
	#define RIG_BRAND_YEASU 1
	
	#define RIG_MODEL_FT847  MAKE_RIG(RIG_BRAND_YEASU,1)
	#define RIG_MODEL_FT747  MAKE_RIG(RIG_BRAND_YEASU,2)
	#define RIG_MODEL_FT1000 MAKE_RIG(RIG_BRAND_YEASU,3)
	/* etc. */
	
	/* Icom */
	#define RIG_BRAND_ICOM 2
	
	#define RIG_MODEL_IC706  MAKE_RIG(RIG_BRAND_ICOM,1)
	#define RIG_MODEL_IC746  MAKE_RIG(RIG_BRAND_ICOM,2)
	/* and so on. */
	

This change won't affect current Hamlib code, however it would
make maintenance of riglist.h and derivated utilities some much easier!

Comments??

-- 
Stephane

Re: [Hamlib-developer] CQ CQ hamlib-developers..

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

On Wed, Mar 28, 2001 at 10:39:32PM +0200, Stephane Fillod wrote:
> 
> Hi there!
> 
> I've sent couple of proposals for Hamlib, but received no sign of life.
> Is there anyone left on this list or just running out of time?

Hi Stephane.

I'm in the middle of moving and am working at a new location.  Even
though I have some time here and there, I haven't managed to update the
web pages even though I completed the first draft of the manual for the
ALPHA release back in December.  I hope to get back to that once things
settle down.

Keep up the good work and I have tried to steer interested parties to
the project.

73, de Nate >>

-- 
 Wireless | Amateur Radio Station N0NB          | "None can love freedom
 Internet | n0...@ne...               | heartily, but good
 Location | Wichita, Kansas USA EM17hs          | men; the rest love not
   Wichita area exams; ham radio; Linux info @  | freedom, but license."
             http://www.qsl.net/n0nb/           | -- John Milton

[Hamlib-developer] CQ CQ hamlib-developers..

[Stephane F. <ste...@in...>]

Hi there!

I've sent couple of proposals for Hamlib, but received no sign of life.
Is there anyone left on this list or just running out of time?

-- 
73! de Stephane