hamlib-developer — hamlib developers forum

[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

[Hamlib-developer] VFO caps

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

Hi there!

It seems like everyone is quite busy, somehow you'll find
a minute or two to comment on my previous "mode" proposal
or this one.

All right, the purpose of this mail is to discuss about VFO capabilities.
Well, actually the subject might be a bit misleading as we should rather talk
about "independantly tunable channels". As Matthew Francey was saying on 
this list so long ago, << A "radio" can actually consist
  of several independent channels.  What people call "VFO's" on many
  radios are actually just glorified memories.  Some radios, however,
  do have 2 or more independently tunable channels. >>

So what is a VFO? Even though a VFO is nothing else than a glorified memory,
Hamlib can consider the difference from a user point of view. The frontier 
could be defined by the M>VFO and VFO>M operations. Therefore, CALL channels
are not VFO. Let's have another example, it is possible to have the same memory channel on two VFOs, but the other way is non sense.
Hmmm, all in all, we do need a definition. Anyone to extend our vocabulary?

Anyway, the goal is to have a mean to target a "VFO" (unique identifier),
and also describe which "VFO" are available in the capabilities
of this rig. The first goal assumes we decided not to provide support for
targetting memories as well (like the 'vfo' arg do in all the Hamlib API 
calls), but rather matching more closely the way most the rigs out there works. And there're still these rig_set_channel/rig_get_channel calls.
The second goal is dealt with the following examples.

Most rigs have only one "tunable channel", which could be represented by:
    |
    `-- MAIN
        |-- VFO A
        `-- VFO B

However, some lucky guys have two "tunable channels" (e.g. FT847, TS2000..):
    |
    |-- MAIN
    |   |-- VFO A
    |   `-- VFO B
    `-- SUB
        `-- VFO C

Which brings the question of whether a rig represented by the following 
figure has ever existed (note the VFO names)?
    |
    |-- MAIN
    |   |-- VFO A
    |   `-- VFO B
    `-- SUB
        |-- VFO A
        `-- VFO B

To my mind, we should number the so-called VFO locally to the "tunable 
channels", and use VFOA, VFOB only as convenient shortcuts (which could 
be wrong on some weird radios BTW).

So enough babling, here's some code:

#define RIG_VFO_CURR    0       /* current "tunable channel"/VFO */

#define RIG_VFO1 (1<<0)
#define RIG_VFO2 (1<<1)
#define RIG_CTRL_MAIN 1
#define RIG_CTRL_SUB 2

/*
 * one byte per "tunable channel":
 *
 *    MSB           LSB
 *     8             1
 *    +-+-+-+-+-+-+-+-+
 *    | |             |
 *    CTL     VFO
 */

/* How to call it? "tunable channel"? Control band? */
#define RIG_CTRL_BAND(band,vfo) ( 1<<(8*((band)-1)) | (vfo)<< (8*((band)-1) )

 /* macros */
#define RIG_VFO_A (RIG_CTRL_BAND(RIG_CTRL_MAIN, RIG_VFO1))
#define RIG_VFO_B (RIG_CTRL_BAND(RIG_CTRL_MAIN, RIG_VFO2))
#define RIG_VFO_C (RIG_CTRL_BAND(RIG_CTRL_SUB, RIG_VFO1))
#define RIG_VFO_MAIN (RIG_CTRL_BAND(RIG_CTRL_MAIN, RIG_VFO_CURR))
#define RIG_VFO_SUB  (RIG_CTRL_BAND(RIG_CTRL_SUB, RIG_VFO_CURR))


As you can see, VFO_A, VFO_B, etc. are unique, which is what Hamlib
was achieving right now, but it is now possible to describe in caps
what "VFOs" the rig is equipped with.

For example, 0x8183 would suit for a TS2000, 0x0083 for an Icom706
and 0x0081 for PCReceiver like the WiNRADiO. As a matter of fact,
0x8081 would be non-sense.

Now do you remember this caps->vfo_list added some times ago? Yes?No?
That doesn't matter as it becomes useless, or should I say misplaced.
If you're following this proposal, we can imagine moving this vfo_list
field in the freq_range_t struct. Therefore, backend developers would
be able to describe which "VFOs" have access to which bands, for
the benefits of the happy final user. For example, on Kenwood TS2000,
VFOC can only do 2m and 70cm bands.

One might want to throw in antenna description in the caps too. Yet
I haven't seen enough antenna output configuration to come up with
a proposal likewise. So anyone comments are welcome!
Let me know what you think of it, and if it's worth to be coded.

I think Hamlib does need a 1.1.1 release very soon ("Release often, release
early"), let's say once an viable solution for mode/filters and VFO 
is commited. And then we can schedule harmonized scan support for 1.1.2,
besides other goodies like Nate's docs!


As usual, feedback most wanted 8-)

-- 
Stephane

[Hamlib-developer] Re: hamlib-1.1.0

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

Matthew Francey wrote:
> a) Networked from day 1.  The "backend" and "frontend" stuff should
> communicate over a cleanly designed, extensible, protocol that runs on
> top of TCP/IP or some other connection mechanism.
> 
  nice, a little bit heavy to my taste. We can achieve the same result
  for half the price. That's what the RIG_PORT_NETWORK is for,
  and there's already some rig protocols around, waiting for someone
  to write a backend for..

> b) Event driven.  This is particularly important, as many radios
> (e.g., PCR-1000) issue events based on what is happening (signal
> strength, etc) on the channel.  Polling is Bad.
> 
	Hamlib has basic event support, and it works, at least with
  my Icom. Even though polling is bad, it IS needed sometimes.
  For example, Icoms CI-V does not notify of VFO changes.
  Work planned.

> c) Capabilities are essential.  Without being able to discover what a
> radio is capable of, you'll end up with a framework that won't be
> too exciting to people 10 years from now.
> 
	We'll be happy if Hamlib is still applicable in 10 years.
  At that moment, perhaps this will be the time for a new generation.
  In the meatime, capabilities are there from the day one, and we
  try to make the API the more generic it can be. But we are lacking
  developers/designers, and I'm sure your input would be very valuable.
  We learned a lot by experimenting (isn't it the OM approach after all?),
  esp. by trying to implement funky rigs, receivers, etc.

> d) Rethink what is being controlled.  A "radio" can actually consist
> of several independent channels.  

  Yup, this is true. The problem we're facing right now is we don't know of
  every breed of rigs out there, and Hamlib may want to control them
  in the future. Hence how one can forsee how much generic the interface
  should be, yet retaining good efficiency ?
  If you have some patchs to control coffee machines, they're welcome :)
  Well, it seems you have thought already a lot about this, so I hope
  you'll join us on the list!

Cheers,
-- 
Stephane

[Hamlib-developer] API list of modes

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

Hi there!

Let's close the issue of modes.
To sum up, we have already CW, AM, USB, LSB, RTTY and FM, and we agreed 
to not create NAM (narrow), WAM (wide), et al. since there can be
several narrow filters, etc.  Hence the filter list will be part
of capabilities, and rig_set_mode will require the desired
filter to be specified (in Hz) as an argument. A value of 0 for this arg
will have to be interpreted by backends as the "normal" passband.
This means the death of RIG_PASSBAND_WIDE, RIG_PASSBAND_NARROW.
If all this does not look very clear, don't worry, I'll come up with
a code samples as soon as all the caps->filters are populated (mandatory).
If you think this proposal sucks or could be improved, well, just let me know.

OK, I'm here today to question about WFM, CW-R, RTTY-R.

(1) WFM, after arguing back-and-forth, I think I'd settle
    with makeing it different thant FM. I'm not an expert in modulation,
    and my understanding is that WFM is NOT just a FM circuitry
    with a huge wide filter. I'm also thinking of it on the end-user
    point of view (e.g. virtual rig GUI). So I'd vote for RIG_MODE_WFM.
    What do you think?

(2) reverse sideband
    Sure, we could add another argument to rig_set_mode (and rig_get_mode)
    to specify a broken-down mode definition. But reverse sideband
    only applies to 2 modes (please confirm), so we might get away
    with RIG_MODE_CWR and RIG_MODE_RTTYR. Any thought?
    Do you known any other funky modes, like SyncAM and stuff like that?
    We have to think about that, because in the future, the API will be
    frozen, and it won't be allowed to create a new argument to rig_set_mode
    to keep compatibility (a new #define is OK though).

Comments?

-- 
Stephane

Re: [Hamlib-developer] Re: New modes (was: Re: Addiions for the R-8500 and 750PRO )

[David HM S. <sp...@ze...>]

Stephane,

I think the filter list is a great idea, and in re-thinking my
position on the default settings issue I realize I am probably barking
up the wrong tree.  Since we're writing back-ends we might as well go
all out and specify all modes completely.

I was looking at things from the angle that by adding new modes into
rig.h as they come up in new rigs, we have the ability to rely on the
rigs own op-codes to set the mode rather than set a generic mode
(i.e., "AM") and then have to specify the filters to get the rig into
a "new" (unlisted in rig.h) mode... 

73,
 David
--------------------------------------------------------------------------------
David HM Spector                   sp...@ze.../sp...@re...
President & CEO                                           voice: +1 631.261.5013
Really Fast Systems, LLC                                    Fax: +1 631.262.7497
				-----
Supercomputer performance to get the job done.
                                         Commodity pricing to make it affordable.

[Hamlib-developer] Re: New modes (was: Re: Addiions for the R-8500 and 750PRO )

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

David HM Spector wrote:
> >
> >int rig_set_mode(RIG *rig, vfo_t vfo, rmode_t mode, pbwidth_t width);
> >
> >Anyway, it looks like we still lack some "modes".
> > * How would you set Synchronous AM (detection only), aka S-AM ?
> > * How would you set reverse sideband modes, like CW-R and RTTY-R ?

	still no clue?
> 
> One of the problems with having to pass the passband info in
> rig_set_mode (as opposed to creating a new mode) implies that we know
> what those values are for all possible modes as defaults (i.e., set
> mode to FM and passband to X == FM-N for rig model Y ).
> 
  yup, that's exactly the point, and I'm gald you raised it!
  Actually, my latest commit add a new field in the caps, called 'filters'.
  This is a zero terminated array of modes/freqwidth tuples.
  Have a look at icom/ic706.c to have a idea of what it should look
  like for other backends.
  This table contains all the installed filters. Provided the table
  is sorted accordingly, we can agree that the first entry of a given
  mode will tell the PASSBAND_NORMAL filter.
  Why would you ask? because I'm dreaming of a rig_set_mode that is able
  to accept a passband in kHz, or a RIG_PASSBAND_NORMAL arg, which
  would be a kind of macro for the PASSBAND_NORMAL filter in 
  the ordered table...  Is it day dreaming?
  Of course, pbwidth_t would have to be redefined, and RIG_PASSBAND_NORMAL
  et al. be rewritten as some sort of macro. I'll make a code proposal,
  and you'll tell me how you it. An example of the result 
  may look like this:

	/* cool! there's a narrow SSB installed! */
	rig_set_mode(my_rig, RIG_MODE_USB, kHz(1.9));

	/* don't bother with filters, just want to hear some ragchewing :) */
	rig_set_mode(my_rig, RIG_MODE_FM, RIG_PASSBAND_NORMAL);


  rig_set_mode is not an easy one. It has to be versatile, yet simple
  to use for the end user, and the call should map as best as it can
  to the myriad of protocols and weirdo modes.

> This command is good for modifying the functionality once in a mode,
> but I think we would have to add new modes so that the rig-specific
> back-ends can invoke the appropriate interface commands to set the
> mode (which would get the passband and other settings for free).
> 
  Well, this was my first approach, and after couple of week, I was
  still not satisfied with it. Imagine you have "n" basic modes,
  each of them can have 3 passbands, maybe more, and on top of that,
  there are reverse modes. No, this is too much complexity for
  RIG_MODE_ handling at the end user level.
  Also, some modes can have serveral "narrow" modes, like NFM
  and Super-NFM (example AR8200). And what about optional filters?
  IMNSHO, filter list should be defined in caps, and shadowed
  in the rig_state struct (hence my latest commit).

  Do you think my proposal could be OK?  Comments?

  In the mean time, there's some caps->filters to populate,
  set let's do it :)


Cheers,
-- 
Stephane / F4CFE

PS: I'll be out next week (more precisely in DE). Maybe we can think of
    a new release (1.1.1) of Hamlib beginning of march.
PS/2: The PCR1000 backend is in preparation, and it has interresting filters!

[Hamlib-developer] Re: New modes (was: Re: Addiions for the R-8500 and 750PRO )

[David HM S. <sp...@ze...>]

Stephane wrote...
>Well, to be more exact rig_set_passband isn't any more, and rig_set_mode
>evolved into a combined function:
>
>int rig_set_mode(RIG *rig, vfo_t vfo, rmode_t mode, pbwidth_t width);
>
>
>Anyway, it looks like we still lack some "modes".
> * How would you set Synchronous AM (detection only), aka S-AM ?
> * How would you set reverse sideband modes, like CW-R and RTTY-R ?
>
>To my mind, these modes belong to rig_set_mode. However, I'm wondering
>if we should create new RIG_MODEs or not.
>Ideas anyone?


One of the problems with having to pass the passband info in
rig_set_mode (as opposed to creating a new mode) implies that we know
what those values are for all possible modes as defaults (i.e., set
mode to FM and passband to X == FM-N for rig model Y ).

This command is good for modifying the functionality once in a mode,
but I think we would have to add new modes so that the rig-specific
back-ends can invoke the appropriate interface commands to set the
mode (which would get the passband and other settings for free).

It doesn't seem there's a down side for adding more modes, it just
implies that there will be modes that are not applicable to every rig
(which is the case right now...)  and don't show up in their mask of
supported modes.  In any event, as above, the back-end for a given rig
will have to invoke the rig-specific op-codes to set the rig to the
given mode anyway.


regards,
  David
--------------------------------------------------------------------------------
David HM Spector                        Network Design & Infrastructure Security
sp...@ze...               -or-                     sp...@sp...
voice: +1 631.261.5013                                       Fax: +1 631.262.7497
Amateur Radio: W2DHM (ARRL life member) GridSquare: FN30hv (40.52'45"N 73.21'21"W) 
-.-. --- -. -. . -.-. -  .-- .. - ....  .- -- .- - . ..- .-.  .-. .- -.. .. ---
Those who will not reason, are bigots, those who cannot, are fools, and those who 
dare not, are slaves.     -George Gordon Noel Byron [a.k.a Lord Byron](1788-1824)

[Hamlib-developer] [Fwd: Re: [Yaesu] FT-1000MP CAT MANUAL]

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

Here is a tidbit gleaned from the Yaesu mailing list at QTH.Net.

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

Re: [Hamlib-developer] problem adding modules (rigs)

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

Frank Singleton wrote:
> 
> David HM Spector wrote:
> > The additions/changes to testrig.c (besides setting the serial port)
> > were:
> > 
> >         retcode = rig_load_backend("r8500");
                                        ^^^^^
> >         my_rig = rig_init(RIG_MODEL_ICR8500);
> 
> For the yaesu rigs (me backend resp ), a dlopen call in  the frontend
> will
> attempt to find   the "specific" backend rig's lib.
> eg the ft747 or the ft847 lib
> 
> This should be the general case for most rigs. 
> Stephane (icom resp) may have decided to generate a general
> libhamlib-icom
> lib to handle the common icom stuff.
> 
  That's true. Almost all controlable Icom rigs support the CI-V protocol,
  including the IC-R8500 (exceptions are the PCR1000, the clonable HTs, etc.)
  Therefore, it make sense to have only one object module sharing code,
  for all these backends.

  So testrig.c should read something like this:

	retcode = rig_load_backend("icom");
	my_rig = rig_init(RIG_MODEL_ICR8500);

  Grab the latest Hamlib from the CVS rep, with a cvs checkout or from
  a snapshot at http://cvs.sourceforge.net/cvstarballs/hamlib-cvsroot.tar.gz
  and give it a shot! Let us know how it works. Also you might consider
  using rigctl for unitary tests. It has a primitive interactive interface,
  and will soon work also from command line (haha, GUIs are history :)
  As well as the icr8500 backend, this is still a WIP..

Cheers,
-- 
Stephane