hamlib-developer — hamlib developers forum

[Hamlib-developer] preferences

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

Let's dust off the drawing board once again: this time, the preference file.

It's almost obvious, we need a ~/.hamlibrc or /etc/hamlibrc where
to store preferences on the connected rigs, like rig type, serial port
parameters, override values (rig modified),etc.
This way, it's easier for different user application to control rigs,
ie use Hamlib, off-the-shelf :)

First, we need to agree upon a preference file format.

* windows style:
  -------------

	; this is a comment
	[Hamlib]
	Backend Path=/usr/local/hamlib/lib

	[my rig name1]
	Serial Path=/dev/ttyS1

	[my rig name2]
	Serial speed=1200


* UNIX style:
  ----------

	# this is a comment
	backend-path=/usr/local/hamlib/lib

	rig "my rig name1"
	serial-path=/dev/ttyS1

	rig "my rig name2"
	serial-speed=1200


Then, we have to agree upon parameters name, at least upon which
that will be shared among backends in the frontend (eg. serial path, etc.).

You've notice the "my rig name1" and "my rig name2". Well, this is to
differentiate from different rigs attached to the system. Let's say
this is a logical name. From this point, I think that the rig_init
API call needs to be modified, as following:

    RIG* rig_init(rig_model_t rig_model, const char *logical_name);

where logical_name refers to a section in the preference file.
Eventually, the model_type can be defined in the hamlibrc file,
and DEFAULT value would be passed to rig_init.
A "logical_name" field would then be added in the rig->state struct.
The parsing of the hamlibrc file would be done by the first call
to rig_init(), all definitions stored in an internal table.
rig_init() would also override default capability with values from
preference file in the state struct (much internal API specification
to be done here).

Since this is a bit tricky with text files, saving preferencies from
Hamlib would not be available, at least from the beginning.


Eventhough Hamlib is coded in C, it's good to have as much as applicable
an OO approach. For instance, messing directly with rig->state.rig_path 
is not very clean, nor flexible for the future.
To my mind, some new API calls should be created:

	int rig_set_serial(RIG *rig, const char *path, int speed, etc.)
	int rig_set_network(RIG *rig, const char *host, int port, etc.)
	int rig_set_whatever(RIG *rig, const char *path, etc.)

The behaviour would be:
* use values from the function arguments
* if args are set to an undefined value, use the ones from hamlibrc
* if none defined in preferences, use capabilities default
* as a last ressort, if the variable has no default value in caps,
  then the function call should fail, returning appropriate error code.


Okay, this is only some thoughts to start up with. I don't mean to impose 
anything. Let me know what you think of it, stuff I omitted,
if you dream of preferences another way (I hear you gnome afficionados :) ...

Thanks for your inputs,

-- 
Stephane

[Hamlib-developer] Re: CVS tag [Re: Hamlib-1.1.0 released , last check]

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

On Thu, Dec 21, 2000, Frank Singleton wrote:
> 
> Also, will create a yaesu directory and move 
> my common yaesu stuff stuff in there. I am starting to get
> some good structure on common code now, want to leverage
> it as much as possible.
> 
> How does that affect the Makefile stuff (not being an

Looks like a new-backend-HOWTO is on preparation...

Allright, if you want to add the yeasu/ directory,
you'll have to go through the following steps:

* create the yeasu/ directory, if not done already...

* in configure.in, at the very bottom of the file,
  add yeasu/Makefile in the AC_OUTPUT directive so 
  your Makefile will be autogenerated (using automake)

* add the directory name in the Makefile.am to SUBDIRS,
  in the root directory of hamlib. This is needed by the master
  Makefile to know where to recurse into.

* create yeasu/Makefile.am, the easiest way is to clone it from
  an existing backend. Some explanations on the content may be
  interresting. Ask if you want some.

* running make from the hamlib root dir should rebuild configure
  and rerun it. If not, just issue "autoconf", followed by "./configure"
  and that should be it.

> Also, I think there is a missing dependancy on .h
> files. When I edit one , say ft747.h and re-run make
> from the top dir, then he does not see any changes.
> 
  well, it looks like no mkdep is ran automatically.
  you might end up adding it by hand in the Makefile.am,
  while I'm figuring out how to activate automatic dependencies
  (any help welcome!).

-- 
Stephane

Re: [Hamlib-developer] Documentation plan

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

Nate Bargmann wrote:
> 
> 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. 

Yes, lets tell people what its about, its goals, status, ambition,
world domination  ... :)

Our empty web space is not that eye-catching !!

A little diagram showing frontend API and the backends
would also help visualisation of the project.

Also some site navigation, status, FAQ, "latest news" areas 
etc would be good.

> 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.
> 

The frontend API has some markups to assist documentation.
Stephane, comments. Also the rig capabilities matrix would
be nice... :)

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

Good, there are still a lot of us with low bandwidth 
connections (sigh..). Mostly I am not a frames fan,
although they occasionally provide some navigational 
use. I could live without them :^)

> 
> 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?
> 

Hmm, let me check, I just uploaded my pub ssh key and waited 24
hours, from memory...

I know there have been some problems with the sourceforge 
re-shuffle. eg: Our CVS commits are normally emailed our cvs-devel
list, but that stopped recently. I have a ticket open on it.


Welcome onboard Nate.

Cheers / Frank 

73's de vk3fcs & km5ws

[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