Thread: [Hamlib-developer] hamlib-1.1.0 release note
Library to control radio transceivers and receivers
Brought to you by:
n0nb
Menu
▾
▴
hamlib-developer
|
From: Frank S. <vk...@ix...> - 2000-12-23 18:17:31
|
Hamlib 1.1.0 Project Release ============================ Introduction ------------ Application programmers: Do you dream for a common API to control any type of HAM Radio equipment that has a control port? Are you waiting to build the next cool GUI program to really drive all that HAM gear you or others have? Well, this project is here to help you get there :-) hamlib-1.1.0 finally released (alpha). The purpose of this project is to develop stable, flexible, shared libraries that enable quicker development of Amateur Radio Equipment Control Applications. It will (eventually) run on various flavors of Unix, Linux, and Windows. It is based on a shared library frontend abstraction layer/backend approach. Application programmers will see a common frontend (abstraction layer) API, and backend shared libs can be loaded on demand when an application wishes to control a certain radio type. Seeking contributor help for a really cool project. Although alpha code, proof of concept has been tested against FT747, FT847 and IC706 rigs. It has gone through a major rework since its inception and testing on my poor old FT747 (smoke test :) Where to find it ---------------- Here is the main page and links to CVS, major releases and links to news groups. See http://sourceforge.net/projects/hamlib for details. There exists a mailing list for developers at ham...@li... Example code: ------------ This "C" code snippet sets any rig to 21,235.175 Mhz USB, Normal bandwidth. /* 15m USB */ retcode = rig_set_freq(my_rig, RIG_VFO_CURR, 21235175); /* 15m */ retcode = rig_set_mode(my_rig, RIG_VFO_CURR, RIG_MODE_USB,RIG_PASSBAND_NORMAL); see hamlib/tests/testrig.c for an example. Help Wanted ----------- Get on board and help us write the frontend and backend libs for all the rigs out there. If we can talk to it, we want to control it !! If you have a rig to test with thats cool, but not essential. I currently develop on Linux 2.2 kernel, but keen to get cross compilation via autoconf to most OS's out there . Status ------ Although considered alpha code, it does work for the few backends we have written so far. Not all API is implemented, but just enough to prove our design, and to select VFO and frequencies etc.. API Documentation is kind of sparse (contributors welcome) but dont let that throw you :-) Currently there is no web site, apart from project site on source forge at http://sourceforge.net/projects/hamlib But there is always help on the mailing list :) Our aim is to firm up our API, and get some more backends underway. 73's de Frank Singleton (vk3fcs/km5ws) and Stephane Fillod (f4cfe) |
|
From: Frank S. <vk...@ix...> - 2001-01-02 01:36:31
|
Hi fellow linux fans, Not sure if you got htis or not, so here goes :-) 73's de vk3fcs/km5ws Hamlib 1.1.0 Project Release ============================ Introduction ------------ Application programmers: Do you dream for a common API to control any type of HAM Radio equipment that has a control port? Are you waiting to build the next cool GUI program to really drive all that HAM gear you or others have? Well, this project is here to help you get there :-) hamlib-1.1.0 finally released (alpha). The purpose of this project is to develop stable, flexible, shared libraries that enable quicker development of Amateur Radio Equipment Control Applications. It will (eventually) run on various flavors of Unix, Linux, and Windows. It is based on a shared library frontend abstraction layer/backend approach. Application programmers will see a common frontend (abstraction layer) API, and backend shared libs can be loaded on demand when an application wishes to control a certain radio type. Seeking contributor help for a really cool project. Although alpha code, proof of concept has been tested against FT747, FT847 and IC706 rigs. It has gone through a major rework since its inception and testing on my poor old FT747 (smoke test :) Where to find it ---------------- Here is the main page and links to CVS, major releases and links to news groups. See http://sourceforge.net/projects/hamlib for details. There exists a mailing list for developers at ham...@li... Example code: ------------ This "C" code snippet sets any rig to 21,235.175 Mhz USB, Normal bandwidth. /* 15m USB */ retcode = rig_set_freq(my_rig, RIG_VFO_CURR, 21235175); /* 15m */ retcode = rig_set_mode(my_rig, RIG_VFO_CURR, RIG_MODE_USB,RIG_PASSBAND_NORMAL); see hamlib/tests/testrig.c for an example. Help Wanted ----------- Get on board and help us write the frontend and backend libs for all the rigs out there. If we can talk to it, we want to control it !! If you have a rig to test with thats cool, but not essential. I currently develop on Linux 2.2 kernel, but keen to get cross compilation via autoconf to most OS's out there . Status ------ Although considered alpha code, it does work for the few backends we have written so far. Not all API is implemented, but just enough to prove our design, and to select VFO and frequencies etc.. API Documentation is kind of sparse (contributors welcome) but dont let that throw you :-) Currently there is no web site, apart from project site on source forge at http://sourceforge.net/projects/hamlib But there is always help on the mailing list :) Our aim is to firm up our API, and get some more backends underway. 73's de Frank Singleton (vk3fcs/km5ws) and Stephane Fillod (f4cfe) |
|
From: Frank S. <vk...@ix...> - 2001-01-04 07:42:45
|
Kai Altenfelder wrote:
>
> Hello Frank,
>
> On Mon, Jan 01, Frank Singleton wrote:
>
> > Hi fellow linux fans,
> >
> > Not sure if you got htis or not, so here goes :-)
> >
> > 73's de vk3fcs/km5ws
> >
> >
> >
> > Hamlib 1.1.0 Project Release
> > ============================
>
> I'd like to offer you SuSE's help for this project. Since a few months we
> have a program to offer university students Linux and Ham related projects
> for their study works or diploma thesises (sp?). If you have modular tasks
> within your project that are large enough to work 3 to 6 months on it I
> would be very interested.
>
> 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 PGP public key available
Hi hamlib developers (cc: Kai, Suse)
I have taken the liberty of forwading Kai's (Suse)
offer for assistance with our cool project.
I have done this for 2 reasons.
1. Its good to see someone else with some resources
taking note of our COOL project.
2. I would like us to think about what we can request
from him (Suse), in the resource dept.
For hamlib, I see many things we can tackle, but
one that comes foremost is
GETTING AS MANY BACKENDS AS POSSIBLE WRITTEN !!
Of course the API is a moving target as we firm
up the frontend API, but I would personally be
most happy if we can get MANY backend libs started.
ie: Freq,mode and vfo handling for 20-30 rigs
would be a good start.
Even if the API is only partially implemented, it is
great advertising to say we have (partial) support
of 20-30 types of ham radios.
There are of course many other issues, so I would
ask for you feedback.
Some that I see are.
1. Getting RIG control specs (eg: CAT documents etc) for
all the rigs that we dont have covered yet.
2. Do we setup 1 or 2 accounts that allow Suse
participants to contribute. This would be better
than me trying to manage 30 people as they come and
go from Suse's program.
3. Long term maintenance issues etc..
There are more I am sure, so please comment.
In closing, I think it would be generally beneficial
to our project getting this involvement.
Its 2am here, so time to close (snore...) :-o
--
Cheers / Frank
73's de vk3fcs & km5ws
|
|
From: Nate B. <n0...@ne...> - 2001-01-06 02:33:35
|
On Thu, Jan 04, 2001 at 01:46:51AM -0600, Frank Singleton wrote:
> GETTING AS MANY BACKENDS AS POSSIBLE WRITTEN !!
Agreed!
> 2. Do we setup 1 or 2 accounts that allow Suse
> participants to contribute. This would be better
> than me trying to manage 30 people as they come and
> go from Suse's program.
>
> 3. Long term maintenance issues etc..
Would it be possible for the primary SuSE contact to be able to act as an
agent for the contributors they line up? Thus you have one or two folks
from SuSE who, presumably, will be able to be associated with hamlib on
a long term basis, at least longer than a university term.
Also, a useful bit of code would be to have them actually build
applications using hamlib to test the API and find the bugs. :)
In the future they could work on such things as wrappers for other
languages as well as rig backends, which are the priority now.
BTW, I have been looking at the 747 code the past couple days and I have
a rather good handle on it, so I'm going to compile hamlib this weekend
and start testing with my '920. The basic commands are similar and I'll
need to careful with a couple of them in testrig.
Before hacking out a new backend I suppose it would be better to work
with the CVS code now than the 1.1.0 release?
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
|
|
From: Frank S. <vk...@ix...> - 2001-01-06 05:33:59
|
Nate Bargmann wrote: > > On Thu, Jan 04, 2001 at 01:46:51AM -0600, Frank Singleton wrote: > > > GETTING AS MANY BACKENDS AS POSSIBLE WRITTEN !! > > Agreed! > > > 2. Do we setup 1 or 2 accounts that allow Suse > > participants to contribute. This would be better > > than me trying to manage 30 people as they come and > > go from Suse's program. > > > > 3. Long term maintenance issues etc.. > > Would it be possible for the primary SuSE contact to be able to act as an > agent for the contributors they line up? Thus you have one or two folks > from SuSE who, presumably, will be able to be associated with hamlib on > a long term basis, at least longer than a university term. > Yes this is what I am hinting. Kinda like setting up say suse1 and suse2 and having say Kai as our primary point of contact > Also, a useful bit of code would be to have them actually build > applications using hamlib to test the API and find the bugs. :) > In the future they could work on such things as wrappers for other > languages as well as rig backends, which are the priority now. > What about some GTK apps that can load different rigs and test the API etc.. In fact setting freq,mode and bandwidth and PTT should be sufficient for say PSK31 etc.. > BTW, I have been looking at the 747 code the past couple days and I have > a rather good handle on it, so I'm going to compile hamlib this weekend > and start testing with my '920. The basic commands are similar and I'll > need to careful with a couple of them in testrig. > > Before hacking out a new backend I suppose it would be better to work > with the CVS code now than the 1.1.0 release? > > 73, de Nate >> Yes, please use CVS, as I have moved the yaesu rigs into yaesu/ directory. Place your code in the yaesu directory. ie yaesu/ft920.[ch] If you look at the Makefile.am, you can add the '920 in there also. I have tested the yaesu/ stuff on my FT747 and everything still works (hi hi..) after the reorg. Dont use the old style directory ft920/ as I will clean it out soon. (ft747/ ft847/ ft920/ etc..) -- Cheers / Frank 73's de vk3fcs & km5ws |
|
From: Kai A. <ka...@su...> - 2001-01-08 11:04:10
|
Hello Frank and all others, On Thu, Jan 04, Frank Singleton wrote: > GETTING AS MANY BACKENDS AS POSSIBLE WRITTEN !! > > Of course the API is a moving target as we firm > up the frontend API, but I would personally be > most happy if we can get MANY backend libs started. > > ie: Freq,mode and vfo handling for 20-30 rigs > would be a good start. > > Even if the API is only partially implemented, it is > great advertising to say we have (partial) support > of 20-30 types of ham radios. > > There are of course many other issues, so I would > ask for you feedback. > > Some that I see are. > > 1. Getting RIG control specs (eg: CAT documents etc) for > all the rigs that we dont have covered yet. I've got a quite good contact to Kenwood Germany that I could ask all available specs for. And I've got a copy of the Icom "Communication Interface - V" reference manual. This covers models: ic725, ic726, ic728, ic729, ic735, ic737, ic751, ic751a, ic761, ic765, ic781 ic271a/e/h, ic471a/e/h, ic1271a/e, ic575a, ic275a/e/h, ic375a, ic475a/e/h, ic1275a/e, ic970a/e/h icr71a/e/d, icr72, icr7000, ic-r7100, icr9000 For Yaesu I'd have to reactivate my contacts to their german subsidiary. 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 PGP public key available |
|
From: Frank S. <vk...@ix...> - 2001-01-09 03:05:22
|
Kai Altenfelder wrote: > > Hello Frank and all others, > > On Thu, Jan 04, Frank Singleton wrote: > > > GETTING AS MANY BACKENDS AS POSSIBLE WRITTEN !! > > > > Of course the API is a moving target as we firm > > up the frontend API, but I would personally be > > most happy if we can get MANY backend libs started. > > > > ie: Freq,mode and vfo handling for 20-30 rigs > > would be a good start. > > > > Even if the API is only partially implemented, it is > > great advertising to say we have (partial) support > > of 20-30 types of ham radios. > > > > There are of course many other issues, so I would > > ask for you feedback. > > > > Some that I see are. > > > > 1. Getting RIG control specs (eg: CAT documents etc) for > > all the rigs that we dont have covered yet. > > I've got a quite good contact to Kenwood Germany that I could ask > all available specs for. > > And I've got a copy of the Icom "Communication Interface - V" reference > manual. This covers models: > > For Yaesu I'd have to reactivate my contacts to their german subsidiary. > All rig info welcome Kai :-) Well I tossed it round our little (but expanding) group, and here is workable strategy. 1. I would like 1 person (you?) as a Suse rep for this involvement with Uni students. Makes it easier on us for maintenance issues etc, even after the Uni project. 2. You organize some (1 or 2?) generic Suse userids on sourceforge for this purpose, and be responsible for usage. 3. I add them to the project. 4 Possible Project examples (in descending order of importance ?). - Backends for other rigs !! - Some GUI apps (eg GTK )to test our growing API - PSK31 app - wrappers for other languages - etc - Please let me know if this is suitable with you. I think backends and GUI Apps would enhance the VISIBILITY of hamlib a lot. You can definitely assist us in this area Kai. On another issue... What is the possibility of getting permission from kenwood/yaesu/icom etc to keep a electronic copy of their rig control docs on our project (web) page? This means people without those docs could contribute code also. Good PR for these companies also :^) Comments ? -- Cheers / Frank 73's de vk3fcs & km5ws |
|
From: Nate B. <n0...@ne...> - 2001-01-09 13:51:53
|
On Mon, Jan 08, 2001 at 09:09:37PM -0600, Frank Singleton wrote:
>
> On another issue...
>
> What is the possibility of getting permission from kenwood/yaesu/icom
> etc to keep a electronic copy of their rig control docs
> on our project (web) page?
Hmmm, this caused a bunch of thought (not good!).
If the docs in question are produced in electronic form and produced by
the manufacturer (say a .pdf), then permission is likely necessary. If,
on the other hand, we're talking about needing permission to transcribe
the commands and their parameters from the rig docs into a format of our
own electronic design, then I think we have a problem.
I am not a lawyer or GPL expert, but if we'd need permission to post a
transcription of what exists in hamlib source code, then we could be in
a very gray area with regard to the GPL. If a manufacturer requires NDA
or permission (which to my knowledge none of them do once the radio is on
the market) to use the command set, then that radio probably cannot be
supported by hamlib.
Even though the manuals themselves are probably published under
copyright (in fact I could find no specific copyright information on my
Yaesu FT-890 manual), the command API is likely considered to be public
information. Even under the terms of fair use we can utilize the
information in the manual to control the radios and publish what we've
done to the web or in the hamlib docs.
Likewise, even though the commands are used in a GPL'ed program, there
is no guarantee that someone won't read the source and use the command
sets in a proprietary program. We can't prevent that from happening,
common information isn't controlled by the GPL. What is controlled is
someone copying and pasting hamlib code into a program that is incompatible
with the GPL (I'm probably not as clear on all this as I think I am).
To summarize, since the rig commands are specific to the controlled
device, they are public knowledge. Since they are public knowledge (as
the manuals say nothing about preventing the command information from
being disclosed), permission should be necessary to publish the command
sets in documentation of our creation so long as its clear that those
commands are a designed part of the radio, and not an original work of
the hamlib authors.
So far much software has been written to control radios, both
proprietary and free and I know of no case where a manufacturer raised
an issue with regard to use of the radio command sets as they cannot be
considered trade secrets either.
> This means people without those docs could contribute code also.
> Good PR for these companies also :^)
This would be a good thing to use the web space for...
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
|
|
From: Kai A. <ka...@su...> - 2001-01-11 15:02:20
|
Hi, On Mon, Jan 08, Frank Singleton wrote: > Well I tossed it round our little (but expanding) > group, and here is workable strategy. > > 1. I would like 1 person (you?) as a Suse rep for this > involvement with Uni students. Makes it easier on us > for maintenance issues etc, even after the Uni project. I've subscribed myself to this list. > 2. You organize some (1 or 2?) generic Suse userids on > sourceforge for this purpose, and be responsible for > usage. I'll do that as soon as we have some new students. > 3. I add them to the project. > > 4 Possible Project examples (in descending order of > importance ?). > > - Backends for other rigs !! > - Some GUI apps (eg GTK )to test our growing API > - PSK31 app > - wrappers for other languages > - etc > - > > Please let me know if this is suitable with you. > I think backends and GUI Apps would enhance the VISIBILITY > of hamlib a lot. You can definitely assist us in this > area Kai. I'll do my best. ;) > On another issue... > > What is the possibility of getting permission from kenwood/yaesu/icom > etc to keep a electronic copy of their rig control docs > on our project (web) page? I've contacted a person at Icom whom I met at HAM Radio '99 but got no answer until now. For Kenwood I'll do the same within the next few days. My contact at Yaesu's left the company so I'll have to find someone else suitable. Regards, Kai |
|
From: Stephane F. <f4...@fr...> - 2001-01-09 08:10:11
|
Hi Kai! > And I've got a copy of the Icom "Communication Interface - V" reference > manual. This covers models: > Do you know where I can find a copy of this manual? Maybe you have it in electronic format, in which case, I'd really appreciate to receive it, since I'm the current maintainer of the Icom backend. Thanks for your support, Cheers, -- Stephane F4CFE |
|
From: Kai A. <ka...@su...> - 2001-01-11 15:03:42
|
On Mon, Jan 08, Stephane Fillod wrote: > > Hi Kai! > > > And I've got a copy of the Icom "Communication Interface - V" reference > > manual. This covers models: > > > Do you know where I can find a copy of this manual? Maybe you have > it in electronic format, in which case, I'd really appreciate > to receive it, since I'm the current maintainer of the Icom backend. No, unfortunately I only have a printed copy. As I wrote in the mail before I contacted Icom for this and still wait for an answer. 73, Kai |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X