hamlib-developer — hamlib developers forum

[Hamlib-developer] rig not supporting target VFO

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

Hi there,

Remember the issue with target VFO?
Let's say the current VFO of the rig is VFO A. But for example, you want
to change the frequency of *VFO B*, while keeping VFO A active.
Some rigs can do that (Kenwoods, some Yeasus, etc.)
My concern here is for rigs that are not able to do that,
hence the following scenario:

	set_vfo VFO_B
	set_freq
	set_vfo VFO_A	/* or whatever it was */

In order to factorize some code, this could be done by the frontend.
I've coded it, but before commiting, I'd like to have your comments.

Backends will have to specify a new caps->targetable_vfo capability.
Also, the current VFO of the rig will be stored in state.current_vfo.
Then wrappers will look like the following:


    int rig_set_mode(RIG *rig, vfo_t vfo, rmode_t mode, pbwidth_t width)
    {
                int retcode;
                vfo_t curr_vfo;

                if (!rig || !rig->caps)
                        return -RIG_EINVAL;

                if (rig->caps->set_mode == NULL)
                        return -RIG_ENAVAIL;

                if (rig->caps->targetable_vfo || vfo == RIG_VFO_CURR ||
						vfo == rig->state.current_vfo)
                        return rig->caps->set_mode(rig, vfo, mode, width);

                if (!rig->caps->set_vfo)
                        return -RIG_ENTARGET;
                curr_vfo = rig->state.current_vfo;
                retcode = rig->caps->set_vfo(rig, vfo);
                if (retcode != RIG_OK)
                                return retcode;

                retcode = rig->caps->set_mode(rig, vfo, mode, width);
                rig->caps->set_vfo(rig, curr_vfo);
                return retcode;
    }


And so on. It's pretty much copy/paste for every Hamlib API calls that
accept a VFO target.

Any comments? Maybe the code needs some :-)

-- 
Stephane

[Hamlib-developer] Documentation plan

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

Okay, I've been going over things the past day or so and would like to
get started by creating an introductory homepage for hamlib.  Some
things I'd like to include are an overview of the library's purpose and
its implementation.  After that is in place I'd like to expand that by
documenting the version 1.1.0 API.  As this becomes complete it should
probably be included in the next stable release.  Far into the future
come things like HOWTO guides and radio command indexes and such.

Is there a preferred style for the web pages?  I don't plan on using
frames or a lot of fancy gizmos.

Finally, I installed the ssh (OpenSSH) 1.2.3-9.1 debian package
yesterday, but cannot log into hamlib.sourceforge.net as the Sourceforge
documentation indicates.  Is this reserved for the project owner, or is
there some other reason (Frank?).  Or will I need to contact Sourceforge
to get this resolved?

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] Greetings!

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

On Mon, Jan 01, 2001 at 09:24:54PM -0600, Frank Singleton wrote:
> 
> Documentation help always welcome. !! A web page for our site
> would be cool..

I noticed the project didn't have one, so I guess that's why I
volunteered.  The web pages could contain hamlib's API along with items
like rig capabilities along with command syntax for each rig so it would
be in one place.  They could also serve as a starting point for formal
documentation included in the library distribution.

> Good, I am rationalising the yeasu code at the moment, and
> it would be good to see the CAT docs etc.. 
> 
> You would be most welcome to join us. The fun part is to tweek
> some code, then make sure you can still talk to your rig :-)

Of course!

> I am moving yaesu stuff to table driven functionality.
> see ft747 and ft847 for examples. I am in transit with this
> code, but I am sure you get the idea :^)

I looked at both the 747 and 847.c files and it looks rather
straightforward(!) when comparing them to the CAT info I have.
Hopefully, I can begin to work on this for the '920 later in the week.

> CAT docs are needed, but the FIF-232 could be replaced with
> a cheaper kit based on max232 chip.
> 
> Normally this just converts between TTL levels and RS232
> levels.

I built one for a TS-850 I no longer have, but the rig acted flaky with
it, so I'm not sure if the problem was in the interface or the '850.

> 2 points.
> 
> 1. The API is WIP this why we need comments by
>    people other than the 2 current members. We should
>     have a standard API as a minimum and get it out there
>    in WIDE use. .... and ...
>    
> 2. Yep, some generic way of broadcasting "extra" capabilities and
>    using some enhancements is always possible.

I can always comment. :-O

> That why we want people on the list, to chew through these 
> ideas ..

ditto!

> Yep thats ok, I promise not to jump to v7.0 (hi hi)

Harr!  One thing, and I think this was in the archive, I think should be
followed is the Linux kernel example of an odd minor version number
indicating a development version as it has become common convention for
open source projects.

> Again, you would be most welcome, and the extra rigs we could
> test and develop against is most valuable in getting a wider
> audience for both hamlib development, and end user developers
> using hamlib to create cool stuff (see our wishlist).
> 
> So, just to clarify, I understand you  can help us with
> web and docs, THANKS. Are you willing to code up some backends
> for your rigs. I can provide some help if required.

Yes, I can pitch in.  Time is always a precious commodity, but I usually
have a few hours each evening available to do things.  I enjoy HTML and
CSS and prefer to write my pages from scratch conformant to the W3C HTML
4.01 Transitional DTD.

> You can use FT747 code as example, to map frontend
> API function calls onto backend rig specific CAT
> sequences. see yaesu.h and ft747.[ch]

I will definitely look those over.  I've looked at the '920 CAT commands
in the owner's manual, so this should be interesting.

> Can you join the sourceforge community, then I will add
> you to our project.

No problem.  I'll have to poke around there and see what needs to be
done.

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] Greetings!

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

Nate Bargmann wrote:
> 
> Hello hamlib developers.
> 
> First off, I am very intrigued about this project as I believe it fills
> a need.  Second, I am a total novice at coding as I have a basic
> understanding of C, but have had no formal training.  So, I've been
> looking at the hamlib source code over the past week trying to figure it
> out (I have a long way to go!).

Still work in progress (WIP) but thats the fun part ...

> 
> With that in mind, I'd be willing to lend what help I can to
> documentation and such.  I've written a bit of HTML (link in my sig) and
> have been tinkering with other stuff from time to time.  Unfortunately,
> I'm no graphics designer, so I'm pretty much limited to text.
> 

Documentation help always welcome. !! A web page for our site
would be cool..

> As for being able to test things, I am running Debian 2.2r2 Linux and
> have access to the following radios:
> 
> FT-920
> FT-890
> FT-212
> FT-5100  (not sure if it supports CAT)
> 

Good, I am rationalising the yeasu code at the moment, and
it would be good to see the CAT docs etc.. 

You would be most welcome to join us. The fun part is to tweek
some code, then make sure you can still talk to your rig :-)

I am moving yaesu stuff to table driven functionality.
see ft747 and ft847 for examples. I am in transit with this
code, but I am sure you get the idea :^)

> I would have to procure an FIF-232 to test any but the '920.  Is CAT
> command documentation needed for any of these radios?

CAT docs are needed, but the FIF-232 could be replaced with
a cheaper kit based on max232 chip.

Normally this just converts between TTL levels and RS232
levels.

> 
> Finally, I had some thoughts on hmalib itself.
> 
> I read through the developer list archive and was able to track the
> recent changes to the API.  I realize hamlib's goal is to present a
> consistent API to a program no matter the radio it is talking to.
> However, with the myriad of rigs out there it certainly seems difficult
> to support every feature of these radios with (what seems to me at
> least) a restricted API.  

2 points.

1. The API is WIP this why we need comments by
   people other than the 2 current members. We should
    have a standard API as a minimum and get it out there
   in WIDE use. .... and ...
   
2. Yep, some generic way of broadcasting "extra" capabilities and
   using some enhancements is always possible.


Is there a possibility of providing a sort of
> "pass-through" function that would allow an application to access a
> specialized function of a given radio?  I suppose an application's
> author could always load a given rig's library directly, but that would
> be messy and outside the design of hamlib.  Just a thought I had.
> 

That why we want people on the list, to chew through these 
ideas ..

> I must admit that as a long time user of Free/open source software I was
> initially confused by its 1.1.0 ALPHA version, which, to me at least,
> seems a bit high for this stage of development.  Of course, the version
> number is simply a reference for the developer and user and can be
> anything (witness the shrinkwrap insanity over the past years) the
> developer chooses.  I mention this simply because it will likely get
> mentioned again by others. :-)
> 

Yep thats ok, I promise not to jump to v7.0 (hi hi)

> All in all, I am pleased this project exists.  Anything that helps
> introduce Linux to hams or make Linux more attractive is a plus in my
> books.
> 
> 73, de Nate >>

Again, you would be most welcome, and the extra rigs we could
test and develop against is most valuable in getting a wider
audience for both hamlib development, and end user developers
using hamlib to create cool stuff (see our wishlist).

So, just to clarify, I understand you  can help us with
web and docs, THANKS. Are you willing to code up some backends
for your rigs. I can provide some help if required.

You can use FT747 code as example, to map frontend
API function calls onto backend rig specific CAT
sequences. see yaesu.h and ft747.[ch]

Can you join the sourceforge community, then I will add
you to our project.

73's de vk3fcs/km5ws

[Hamlib-developer] Greetings!

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

Hello hamlib developers.

First off, I am very intrigued about this project as I believe it fills
a need.  Second, I am a total novice at coding as I have a basic
understanding of C, but have had no formal training.  So, I've been
looking at the hamlib source code over the past week trying to figure it
out (I have a long way to go!).

With that in mind, I'd be willing to lend what help I can to
documentation and such.  I've written a bit of HTML (link in my sig) and
have been tinkering with other stuff from time to time.  Unfortunately,
I'm no graphics designer, so I'm pretty much limited to text.

As for being able to test things, I am running Debian 2.2r2 Linux and
have access to the following radios:

FT-920
FT-890
FT-212
FT-5100  (not sure if it supports CAT)

I would have to procure an FIF-232 to test any but the '920.  Is CAT
command documentation needed for any of these radios?

Finally, I had some thoughts on hmalib itself.

I read through the developer list archive and was able to track the
recent changes to the API.  I realize hamlib's goal is to present a
consistent API to a program no matter the radio it is talking to.
However, with the myriad of rigs out there it certainly seems difficult
to support every feature of these radios with (what seems to me at
least) a restricted API.  Is there a possibility of providing a sort of
"pass-through" function that would allow an application to access a
specialized function of a given radio?  I suppose an application's
author could always load a given rig's library directly, but that would
be messy and outside the design of hamlib.  Just a thought I had.

I must admit that as a long time user of Free/open source software I was
initially confused by its 1.1.0 ALPHA version, which, to me at least,
seems a bit high for this stage of development.  Of course, the version
number is simply a reference for the developer and user and can be
anything (witness the shrinkwrap insanity over the past years) the
developer chooses.  I mention this simply because it will likely get
mentioned again by others. :-)

All in all, I am pleased this project exists.  Anything that helps
introduce Linux to hams or make Linux more attractive is a plus in my
books.

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] hamlib-1.1.0 release note

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

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)

[Hamlib-developer] Merry XMAS and happy new year

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

Hi hamlib crew,

Just wanted to wish you all a very nice holiday
season and great 2001 .

Looking forward to improving hamlib beyond
our expectations :-)

73's de Frank (vk3fcs/km5ws).

[Hamlib-developer] Re: hamlib-1.1.0 release note

[Egon Z. <Eg...@ho...>]

[Hamlib-developer] Re: hamlib-1.1.0 release note

[Egon Z. <Eg...@ho...>]

r 22

[Hamlib-developer] hamlib-1.1.0 release note

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

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)

[Hamlib-developer] CVS syncmail

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

Hi,

I opened a ticket on syncmail. It no longer complains
when doing "cvs ci",but for some reason mail is not 
ending up on the list.

But, there is definitely activity in the CVS archives :-)

Be patient ;-)

Cheers / Frank

[Hamlib-developer] target VFO [was Re: Hamlib-cvs-digest digest, Vol 1 #29 - 1 msg]

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

On Thu, Dec 07, 2000, on hamlib-cvs-digest, Frank Singleton patched:
> Index: ft747.c
> ===================================================================
> RCS file: /cvsroot/hamlib/hamlib/ft747/ft747.c,v
> retrieving revision 1.21
> retrieving revision 1.22
> diff -C2 -r1.21 -r1.22
> ***************
> *** 278,281 ****
> --- 278,283 ----
>     rig_debug(RIG_DEBUG_VERBOSE,"ft747: requested freq = %Li Hz \n", freq);
>   
> +   ft747_set_vfo(rig, vfo);	/* select VFO first , new API */
> + 
>     to_bcd(bcd,freq,8);
>   
[...]
> ***************
> *** 504,507 ****
> --- 554,559 ----
>     rig_s = &rig->state;
>   
> +   ft747_set_vfo(rig,vfo);	/* select VFO first */
> + 
>     switch(ptt) {
>     case RIG_PTT_OFF:


  Actually, the <backend>_set_vfo() could be done in a generic way
  at the frontend level in rig.c, provided Hamlib knows through
  capabilities the rig can't address directly the different VFOs.
  The behaviour of Hamlib we still have to agree upon should assume
  IMO that whichever API function is called, the VFO selected by
  the previous rig_set_vfo must stay still. Here is an illustration:

	rig_set_vfo(VFO_A)
	...
	rig_set_freq(VFO_B,GHz(10.450))	/* geez, air-plane scatter! */
	...
	rig_get_vfo() -> VFO_A

  This means that for rigs that cannot address VFOs directly, the frontend
  (not the user application) should translate the previous sequence
  to this:

	rig_set_vfo(VFO_A)
	...
	if (!has_targetable_vfo) {
	  <backend>_set_vfo(VFO_B)
	  <backend>_set_freq(VFO_B,GHz(10.450))	/* VFO target useless here */
	  <backend>_set_vfo(VFO_A)
	}
	...
	rig_get_vfo() -> VFO_A

  Eventually, the frontend can "cache" which VFO is currently active,
  saving for some needless _set_vfo, but we have to take extra care that
  someone hasn't changed the VFO *manually* on the rig panel (however,
  having to do _get_vfo repeatedly would be a real pain).
  
  Anyway, I know you already have had this idea previously. The purpose of
  this mail is just to stress the "sharability" of such a piece of code
  (good feature to add for hamlib-1.1.1), and also to urge you 
  to release hamlib-1.1.0 now ;-)
  (remember "the release early, release often" rule of Linux)
  After all, hamlib-1.1.0 IS alpha quality, there's no shame about it,
  just lust for contributors.


  Cheers,

-- 
Stéphane

Re: [Hamlib-developer] API outstanding issues

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

On Sun, Dec 03, 2000, Frank Singleton wrote:
> 
> If you patch the frontend, I will update ft747 and ft847 to
> accept the new API. Then we RELEASE !!
  
all right, I've checked in the set_mode and the target VFO
modifications. I'm ready for the release!

Cheers,

-- 
Stephane

Re: [Hamlib-developer] API outstanding issues

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

Stephane Fillod wrote:
> 
> Frank Singleton wrote:

<snip >

> > int rig_set_vfo_params(RIG *rig, vfo_t vfo, rmode_t mode, fresp_t fresp)
> > ??
> > int rig_get_vfo_params(RIG *rig, vfo_t vfo, rmode_t *mode, fresp_t
> > *fresp) ??
> >
> >
> > Also, the pbwidth_t is a subset of a general freq response type
> >
> > struct freqresp {
> >       filter_path_t fpt;  /* filter location */
> >       filter_mode_t fmt;  /* filter mode, eg: NORMAL,WIDE etc or CUSTOM */
> >                             /* CUSTOM must provide flower,fupper,fcenter
> > etc */
> >                             /* depending on CUSTOM type */
> > };
> >
> > typedef freqresp fresp_t;
> >
> [...]
> 
>   Your proposal looks comprehensive, however, I don't have such features
>   on my rig, and since I'm not very knowledged in this field, well I
>   cannot say much.
>   In an effort to try to map the Hamlib API to the way rigs work,
>   I would rather argue for two set of functions.
> 
> > >  int rig_set_mode(RIG *rig, vfo_t vfo, rmode_t mode, pbwidth_t width);
> > >  int rig_get_mode(RIG *rig, vfo_t vfo, rmode_t *mode, pbwidth_t *width);
> 
>   This would cover basic VFO support, ie. probably more than 80% of the
>   rigs out there, which don't have filters.
> 
>   And then, another set of functions, yet to specify, to fine tune
>   the filters of the mode:
> 
>         int rig_set_filter(RIG *rig, vfo_t vfo, fresp_t fresp)
>         int rig_get_filter(RIG *rig, vfo_t vfo, fresp_t, *fresp)
> 
>   Let me know what you think of the rig_set_mode/rig_get_mode approach
>   at least, if we have time to implement it before the forthcoming 1.1.0
>   release.

Ok, at least both approaches should cover everyone's requirements.

If you patch the frontend, I will update ft747 and ft847 to
accept the new API. Then we RELEASE !!

Cheers / Frank..

Re: [Hamlib-developer] API outstanding issues

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

Frank Singleton wrote:
> 
> Some raw thoughts here.. maybe wishlists but anyway ...
> 
> I see a VFO as "the" basic communication resource that can 
> have particular "parameters" associated with it.
> 
> ie: Normally to use the VFO for some communications purposes,
> then vfo,freq,mode and filter selections need to be made,
> as a minimum.
> 
> So what about.
> 
> int rig_set_vfo_params(RIG *rig, vfo_t vfo, rmode_t mode, fresp_t fresp)
> ??
> int rig_get_vfo_params(RIG *rig, vfo_t vfo, rmode_t *mode, fresp_t
> *fresp) ??
> 
> 
> Also, the pbwidth_t is a subset of a general freq response type
> 
> struct freqresp {
> 	filter_path_t fpt;  /* filter location */
> 	filter_mode_t fmt;  /* filter mode, eg: NORMAL,WIDE etc or CUSTOM */
>                             /* CUSTOM must provide flower,fupper,fcenter
> etc */
>                             /* depending on CUSTOM type */
> };
> 
> typedef freqresp fresp_t;
>
[...] 

  Your proposal looks comprehensive, however, I don't have such features 
  on my rig, and since I'm not very knowledged in this field, well I
  cannot say much.
  In an effort to try to map the Hamlib API to the way rigs work,
  I would rather argue for two set of functions.

> >  int rig_set_mode(RIG *rig, vfo_t vfo, rmode_t mode, pbwidth_t width);
> >  int rig_get_mode(RIG *rig, vfo_t vfo, rmode_t *mode, pbwidth_t *width);

  This would cover basic VFO support, ie. probably more than 80% of the
  rigs out there, which don't have filters.
  
  And then, another set of functions, yet to specify, to fine tune 
  the filters of the mode:

	int rig_set_filter(RIG *rig, vfo_t vfo, fresp_t fresp)
	int rig_get_filter(RIG *rig, vfo_t vfo, fresp_t, *fresp)


  Let me know what you think of the rig_set_mode/rig_get_mode approach
  at least, if we have time to implement it before the forthcoming 1.1.0 
  release.


Cheers,

-- 
Stephane

Re: [Hamlib-developer] API outstanding issues

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

Stephane Fillod wrote:

<snip>

> * I'm still not happy with the rig_set_mode/rig_get_mode.
>   Frank, what do you think of getting rid of set_passband/get_passband
>   in favor of the following?
> 
>  int rig_set_mode(RIG *rig, rmode_t mode, pbwidth_t width);
>  int rig_get_mode(RIG *rig, rmode_t *mode, pbwidth_t *width);

<snip>

hmmm, of course we need our VFO in there as well.. :-)

>  int rig_set_mode(RIG *rig, vfo_t vfo, rmode_t mode, pbwidth_t width);
>  int rig_get_mode(RIG *rig, vfo_t vfo, rmode_t *mode, pbwidth_t *width);



Some raw thoughts here.. maybe wishlists but anyway ...

I see a VFO as "the" basic communication resource that can 
have particular "parameters" associated with it.

ie: Normally to use the VFO for some communications purposes,
then vfo,freq,mode and filter selections need to be made,
as a minimum.

So what about.

int rig_set_vfo_params(RIG *rig, vfo_t vfo, rmode_t mode, fresp_t fresp)
??
int rig_get_vfo_params(RIG *rig, vfo_t vfo, rmode_t *mode, fresp_t
*fresp) ??


Also, the pbwidth_t is a subset of a general freq response type

struct freqresp {
	filter_path_t fpt;  /* filter location */
	filter_mode_t fmt;  /* filter mode, eg: NORMAL,WIDE etc or CUSTOM */
                            /* CUSTOM must provide flower,fupper,fcenter
etc */
                            /* depending on CUSTOM type */
};

typedef freqresp fresp_t;

where filter path (location) is for example..

enum filter_path_e { 
        RIG_FILT_RF = 0,
	RIG_FILT_IF,
        RIG_FILT_AF,
        RIG_FILT_RF_EXTERNAL,
        RIG_FILT_IF_EXTERNAL,
        RIG_FILT_AF_EXTERNAL,
}

typedef filter_path_e filter_path_t


and.. filter_mode_t consists   for example,

enum filter_resp_e { 
        RIG_FILTER_WIDE,   /* ie: provided by rig buttons ? */
        RIG_FILTER_NARROW,
        RIG_FILTER_BPASS,
        RIG_FILTER_BREJECT,
        RIG_FILTER_HPF,
        RIG_FILTER_LPF,
	RIG_FILTER_CUSTOM_BPF,   /* custom options ?? */
	RIG_FILTER_CUSTOM_BREJ,
	RIG_FILTER_CUSTOM_LPF,
	RIG_FILTER_CUSTOM_HPF,

   ..etc
}

typedef filter_resp_e filter_resp_t;

So we can chose a filter with either the plain vanilla
wide/narrow etc or if use CUSTOM, then provide flower,
fupper, or fcenter and fbw etc..

struct filt_mode {
	filter_resp_t frt;
	freq_t flower;
	freq_t fupper;
	freq_t fcenter;
	freq_t fbw;  /* bandwidth*/

 etc..
}

typedef filt_mode filt_mode_t;


Any thoughts or comments. (I'm sure :-) )

I guess the main thing I try to say is
filter type (inbuilt or custom) and filter location (RF,IF,AF,EXT).

Cheers / Frank..

Re: [Hamlib-developer] target VFO proposal

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

On Mon, Nov 27, 2000, Frank Singleton wrote:
<snip>
> 
> Hmm, how does ths look??
> 
> int rig_set_mode(RIG *rig, vfo_t vfo, rmode_t mode); /* select mode */
> int rig_get_mode(RIG *rig, vfo_t vfo, rmode_t *mode); /* get mode */
> 
> int rig_set_freq(RIG *rig, vfo_t vfo, freq_t freq);
> int rig_get_freq(RIG *rig, vfo_t vfo, freq_t *freq);
> 
	looks good to me
>
[...]
> 
> ps: I want to fix this before our first release unless
> you have other reasons :-)

	not a problem, let's do it before the 1.1.0 release!

  BTW, can you have a look at one of my previous email on the list

   http://www.geocrawler.com/lists/3/SourceForge/5198/0/4591360/

  especially about passband width/mode setting, and tell what do you
  think of it.

  I've made some pending commits tonight, also once the passband/mode
  is solved, I'll let you know when it's OK for me to issue
  the last update/"make dist" of the 1.1.0 release.

Cheers,
-- 
Stephane

Re: [Hamlib-developer] target VFO proposal

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

Stephane Fillod wrote:
> 
> On Sat, Nov 25, 2000, Frank Singleton wrote:
> >
> > Looking at the latest API in rig.h,
> > I have come to the conclusion we are missing
> > something of great importance.
> >
> > We have not provided a target VFO in the set/get cmd's
> >
>   arg, you're darn right!

<snip>

> > int rig_set_mode(RIG *rig, rmode_t mode, vfo_t vfo); /* select mode */
> > int rig_get_mode(RIG *rig, rmode_t *mode,vfo_t vfo); /* get mode */
> >
> I would prefer like this (which is the same of course):
>  int rig_set_mode(RIG *rig, vfo_t vfo, rmode_t mode); /* select mode */

> 
> maybe we can extend vfo_e with defines like RIG_VFO_CURR,etc.
> and add some macros:
> 
>   #define rig_set_mode_c(rig,more)  rig_set_mode((rig),RIG_VFO_CURR,(mode))


yes or ... see below


<snip>

>   In that case, we would need also to implement option (1), just
>   to reduce some set_vfo/get_vfo calls.
> 
>   I'm not sure if we have a good solution yet, but at least we have
>   a good question to chew!!

crunch crunch !!

> 
> any ideas? comments?


Hmm, how does ths look??

int rig_set_mode(RIG *rig, vfo_t vfo, rmode_t mode); /* select mode */
int rig_get_mode(RIG *rig, vfo_t vfo, rmode_t *mode); /* get mode */

int rig_set_freq(RIG *rig, vfo_t vfo, freq_t freq);
int rig_get_freq(RIG *rig, vfo_t vfo, freq_t *freq);


I think it is a good thing for the application to always
be VERY specific in what is wants done, and I have no problems
with this.

Perhaps we can define define some NullVFO or CurrentVFO etc 
that could indicate that the backend should use the active
VFO (and mode ?) if the App choses to pass args like..

rig_set_freq(rig, CurrentVFO, freq_t freq); /* set freq */
rig_get_freq(rig, CurrentVFO, freq_t *freq); /* set freq */

etc..
 
Comments ?? / Frank..

ps: I want to fix this before our first release unless
you have other reasons :-)

[Hamlib-developer] threaded thoughts !!

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

Stephane Fillod wrote:

> > --- ft747.c   2000/11/25 21:49:34     1.21
> >    *
> > !  * 1. Rentrant code, handle static stuff  <--- ie: get rid of this stuff
> >    * 2. rationalise code, more helper functions.
> >
> > --- 262,317 ----
> >
> >   int ft747_set_freq(RIG *rig, freq_t freq) {
> > +   struct rig_state *rig_s;
> > +   struct ft747_priv_data *p;
> > +
> > +   static unsigned char bcd[] = { 0,0,0,0 }; /* set freq */
> 
>   static local variables (kindof "restricted" global variables) were
>   not well suited for reentrant code. And the p_cmd are not either, since
>   the struct would be shared in the data section. Most of the time,
>   reentrant mutexless solutions would make use of variables on the stack
>   (eventually alloca) or dynamic memory allocated on a per thread basis.
>   Anyway, reentrancy is not the primary focus right now :)

True, as my comments suggest, I need to handle this static 
stuff properly. ie: Remove it.

Can we not have instance data in priv_ and mutex locks
on API function level.

eg:

pthread_mutex_lock(&shared.mutex);
....do stuff
pthread_mutex_unlock(&shared.mutex);

Do we consider function call level (eg: rig_set..() ) the right
size of thread "granularity" ?

Its probably a good starting point.

Anyway, not an immediate problem, but
something to think about :-()

/Frank :-)

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

Re: [Hamlib-developer] target VFO proposal

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

On Sat, Nov 25, 2000, Frank Singleton wrote:
> 
> Looking at the latest API in rig.h,
> I have come to the conclusion we are missing
> something of great importance.
> 
> We have not provided a target VFO in the set/get cmd's
> 
  arg, you're darn right!

> For example...should we have this instead..
> 
> int rig_set_freq(RIG *rig, freq_t freq, vfo_t vfo);
> int rig_get_freq(RIG *rig, freq_t *freq, vfo_t *vfo);
                                                 ^-------- typo
> int rig_set_mode(RIG *rig, rmode_t mode, vfo_t vfo); /* select mode */
> int rig_get_mode(RIG *rig, rmode_t *mode,vfo_t vfo); /* get mode */
> 
I would prefer like this (which is the same of course):
 int rig_set_mode(RIG *rig, vfo_t vfo, rmode_t mode); /* select mode */

maybe we can extend vfo_e with defines like RIG_VFO_CURR,etc.
and add some macros:

  #define rig_set_mode_c(rig,more)  rig_set_mode((rig),RIG_VFO_CURR,(mode))

> etc..
> 
> It seems silly, but without this, we dont have a solid
> "target VFO" for the existing commands.
> 
	hmmm, embarassing indeed.

> ie: set freq/mode could apply to any VFO, so which
> one gets the command.??   Is it really the towards
> the  VFO specified in previous last set_vfo() 
> 
	right now, this is the last vfo set, which is
	tricky with multithreaded apps, see below.

> So, some decisions.
> 
> 1. backend must "remember".  This could be part of private data
>    This is no big change to frontend API.
> 
[...]

> 2. Frontend API provide API with target VFO as
>    an argument shown above.
> 
> I think I prefer option (1), otherwise we may
> be adding VFO to everything.
> 
  Well, we might end up by havign to choose both, sigh.
  Unfortunately, it looks clear that we'll have to add the target VFO
  to everything in fact.  Just look at it, reentrancy-wise.
  
  Thread A				Thread B

/* not thread safe */

  rig_set_vfo(my_rig,MAIN_VFO);
  .					rig_set_vfo(my_rig,SUB_VFO);
  .					rig_set_freq(my_rig,MHz(435));
  .
  rig_set_freq(my_rig,MHz(28)); /* !!! */


/* thread safe, with some mutex around read/writes :^) */

  rig_set_freq(my_rig,MAIN_VFO,MHz(28));
  .					rig_set_freq(my_rig,SUB_VFO,MHZ(435));

  This CAN happen (and it will!). So we need to pass the vfo along
  to all the rig functions :(. That does not mean the death
  of the rig_set_vfo function though. However, on some rigs,
  the backend will have to explicitly change the vfo to update
  stuff (freq, etc.). At this point, the question is whether
  the backend should save and restore the current VFO when
  setting values.
  In that case, we would need also to implement option (1), just
  to reduce some set_vfo/get_vfo calls.

  I'm not sure if we have a good solution yet, but at least we have
  a good question to chew!!


any ideas? comments?

-- 
Stephane

[Hamlib-developer] Re: Hamlib-cvs-digest digest, Vol 1 #23 - 2 msgs

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

On Sun, Nov 26, 2000 at 12:33:28PM -0800, ham...@li... wrote:
> Date: Sat, 25 Nov 2000 13:49:40 -0800
> From: Frank Singleton <jav...@us...>
> To: ham...@li...
> 
[...]
> --- ft747.c	2000/11/25 21:49:34	1.21
>    *
> !  * 1. Rentrant code, handle static stuff
>    * 2. rationalise code, more helper functions.
>   
> --- 262,317 ----
>   
>   int ft747_set_freq(RIG *rig, freq_t freq) {
> +   struct rig_state *rig_s;
> +   struct ft747_priv_data *p;
> + 
> +   static unsigned char bcd[] = { 0,0,0,0 }; /* set freq */

  static local variables (kindof "restricted" global variables) were
  not well suited for reentrant code. And the p_cmd are not either, since
  the struct would be shared in the data section. Most of the time,
  reentrant mutexless solutions would make use of variables on the stack 
  (eventually alloca) or dynamic memory allocated on a per thread basis.
  Anyway, reentrancy is not the primary focus right now :)

> --- 130,135 ----
>   struct ft747_priv_data {
>     unsigned char pacing;		/* pacing value */
> !   unsigned int read_update_delay;	 /* depends on pacing value */
> !   unsigned char p_cmd[FT747_CMD_LENGTH]; /* private copy of constructed CAT cmd */
>     unsigned char update_data[FT747_STATUS_UPDATE_DATA_LENGTH]; /* returned data */
>   };

[Hamlib-developer] target VFO proposal

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

Hi,


Finally got PC and rig powered up after the
house move (phew ..)


Looking at the latest API in rig.h,
I have come to the conclusion we are missing
something of great importance.

We have not provided a target VFO in the set/get cmd's

For example...should we have this instead..

int rig_set_freq(RIG *rig, freq_t freq, vfo_t vfo);
int rig_get_freq(RIG *rig, freq_t *freq, vfo_t *vfo);

int rig_set_mode(RIG *rig, rmode_t mode, vfo_t vfo); /* select mode */
int rig_get_mode(RIG *rig, rmode_t *mode,vfo_t vfo); /* get mode */

etc..

It seems silly, but without this, we dont have a solid
"target VFO" for the existing commands.

  int (*set_freq)(RIG *rig, freq_t freq); /* select freq */
  int (*get_freq)(RIG *rig, freq_t *freq); /* get freq */

  int (*set_mode)(RIG *rig, rmode_t mode); /* select mode */
  int (*get_mode)(RIG *rig, rmode_t *mode); /* get mode */

etc..

ie: set freq/mode could apply to any VFO, so which
one gets the command.??   Is it really the towards
the  VFO specified in previous last set_vfo() 

For example, my FT747 has separate set_freq and set_vfo cmd's
but the FT847 and others always pass VFO along with
the parameter that is being changed.

It is not good for the frontend end "app" to be
guessing about what VFO the last cmd will target.

This also, requires the backend to "remember"  the
VFO used in the last set_vfo cmd.


So, some decisions.

1. backend must "remember".  This could be part of private data
   This is no big change to frontend API.

/*
 * ft847 - private data
 *
 */

struct ft847_priv_data {
        ..
 	unsigned char active_vfo;
	..
 etc
};

  

2. Frontend API provide API with target VFO as
   an argument shown above.

I think I prefer option (1), otherwise we may
be adding VFO to everything.



Comments please / FS

[Hamlib-developer] API outstanding issues

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

Hi all!

Frank, I know you're moving, that's why I tried to not
bother you too much. Let me know when you will have a rest,
so we can eventually release a 1.1.0 hamlib version, and
advertise for it (as an alpha version, of course).
Anyway, hope everything's going well with your installation
in your new house, that must be a lot of work!

Lately, I've been playing with various bits of hamlib.
I tend to substitute the CVS reports to any more human readable ones,
sorry about my lazyness :)
* Well, after some tweakings, "make distcheck" works, so does "make dist".
It is very handy to create a clean release, with all the tagged files
to be distributed in the tar ball, in the right directory and 
correctly named. Check out the Makefile.am files if your favorite file
is missing from the dist.

* Besides misc updates, the API changed significantly on the way
radio levels are set and retrieved. See rig_set_level and rig_get_level
for more information. In a nutshell, a bunch of get/set distinct
functions have been multiplexed in one set_level/get_level pair.
Hope that won't complicate too much the backend implementation.


* As you may noticed, rig_set_tone functions are gone.
They have been replaced by the following functions:

	rig_set_ctcss
	rig_set_dcs

However, Hamlib is still lacking their squelched counterpart.
What do you think of creating these?

extern int rig_set_ctcss_sql(RIG *rig, unsigned int tone);
extern int rig_get_ctcss_sql(RIG *rig, unsigned int *tone);
extern int rig_set_dcs_sql(RIG *rig, unsigned int code);
extern int rig_get_dcs_sql(RIG *rig, unsigned int *code);

A tone/code of 0 would turn off the CTCSS/DCS squelch,
any other value would turn it on.

* I'm still not happy with the rig_set_mode/rig_get_mode.
  Frank, what do you think of getting rid of set_passband/get_passband
  in favor of the following?

 int rig_set_mode(RIG *rig, rmode_t mode, pbwidth_t width);
 int rig_get_mode(RIG *rig, rmode_t *mode, pbwidth_t *width);

* Testing the rig_set_mem and rig_get_freq, I realized that rig_get_freq
  would not handle the case where the freq was undefined (ie. blank channel).
  How can we solve this problem? so far, I can see two solutions.
  The first one consists in assigning a negative value in the freq variable
  in order to tell it is undefined. The second solution I would rather prefer,
  relies on the RIG_Error code returned by the function.
  What do you think?  Do you see another solution?

* News:
	- new AOR backend for the AR8200 scanner, far from complete.
	Written from specs, untested since I don't own such a toy. 
	- rigctl, a new test program, to test any Hamlib function.
	It runs interactively now, but will work from command line soon!
	- rigmatrix, a new combined list/dump program, that creates
	a table of supported radios in HTML format, with png pics
	for the rx/tx ranges (thanks to GD lib).
	The HTML output is rather ugly, but at least you got the
	information :) Any improvement is welcome! You can check
	it out at the following URL:
		http://f4cfe.free.fr/ham/hamlib/rigmatrix.html


Cheers,

-- 
Stephane

Re: [Hamlib-developer] Proposal

[Luc L. <lx...@qs...>]

On Tuesday 24 October 2000 06:57, Stephane Fillod wrote:
> On Mon, Oct 09, 2000, Luc Langehegermann wrote:
> > I just took a look at the rig.h file, and was a bit suprised to read how
> > you use the mode. Is it not easier use an rig_mode_t and an
> > rig_bandwidth_t? At
>
> Have you seen how the rmode_t has been simplified? It makes much more

I'll take a look at it.

> sense (ie. simpler) like this, with a separate bandwidth type.
> However, I'm not happy with the proposal I've coded, that is have
> rig_set_mode(rig, rmode_t mode) and rig_set_passband(rig, pbwidth_t width)
> that would set RIG_PASSBAND_NORMAL/RIG_PASSBAND_NARROW/RIG_PASSBAND_WIDE.
>
> The main reason is because you'll always want to set the passband width
> when you set a mode. And that's why most rig control protocols let you

Not really always. As you know I will use the hamlib to control the 
transceiver from my own psk31 program. Usually you will have the transceiver 
in the wide/normal mode to see nearly all signals in the up to 4kHz wide 
waterfall. But if you have qrm you will switch to an smaller filter (and the 
frequency of the tronsceiver should be changed so that the wanted signal is 
in the biddle of the bandwidth, but thats is not a problem of the hamlib hihi)

> change both with only one command. Therefore, it makes backend
> implementation troublesome. So here's another idea: forget about
> rig_set_passband and have rig_set_mode do it all like this:
>
> int rig_set_mode(RIG *rig, rmode_t mode, pbwidth_t width);
> int rig_get_mode(RIG *rig, rmode_t *mode, pbwidth_t *width);
>
> what do you think? any drawback in mind?
>

Hmm... I only know the FT-920 and he has different opcodes for band and 
bandwidth. But why not thos way?

> > least for the USB/LSB modes? I also thing that RTTY is not really clear
> > enough... Some rigs make afsk, others afsk or fsk... Ans how to know if
> > they
>
> I'm no RTTY guy, anyone is free to make a proposal!
>

Here I also only know the FT-920.. he has the modes DATA-USB and DATA-LSB. 
What about naming the modes this way? AFSK/FSK switching is done here a small 
switch on the rear panel

> Greetings,

-- 
Greetings, Luc, LX2GT

Re: [Hamlib-developer] Proposal

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

On Mon, Oct 09, 2000, Luc Langehegermann wrote:
> 
> I just took a look at the rig.h file, and was a bit suprised to read how you 
> use the mode. Is it not easier use an rig_mode_t and an rig_bandwidth_t? At 

Have you seen how the rmode_t has been simplified? It makes much more
sense (ie. simpler) like this, with a separate bandwidth type.
However, I'm not happy with the proposal I've coded, that is have
rig_set_mode(rig, rmode_t mode) and rig_set_passband(rig, pbwidth_t width)
that would set RIG_PASSBAND_NORMAL/RIG_PASSBAND_NARROW/RIG_PASSBAND_WIDE.

The main reason is because you'll always want to set the passband width
when you set a mode. And that's why most rig control protocols let you
change both with only one command. Therefore, it makes backend 
implementation troublesome. So here's another idea: forget about
rig_set_passband and have rig_set_mode do it all like this:

int rig_set_mode(RIG *rig, rmode_t mode, pbwidth_t width);
int rig_get_mode(RIG *rig, rmode_t *mode, pbwidth_t *width);

what do you think? any drawback in mind?

> least for the USB/LSB modes? I also thing that RTTY is not really clear 
> enough... Some rigs make afsk, others afsk or fsk... Ans how to know if they 
> 
I'm no RTTY guy, anyone is free to make a proposal!

Greetings,
-- 
Stephane