hamlib-developer — hamlib developers forum

Re: [Hamlib-developer] backend lib loading strategy.

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

Frank Singleton wrote:
> 
> 1. frontend should load appropriate backend lib
>    at say, rig_init or similar.

	nope, rig_init is already in use. init_rig isn't ;-)
> 
> 2. multiple instances of same RIG type should not 
>    cause multiple dl_open requests ??
> 
	sure not. Actually, the backend won't be loaded
  by rig type, but by backend lib!
  using something like rig_load_backend("ft847");
  which would load libhamlib-ft847.so and register it.

> 3. Must have way of resolving symbol names for
>    dlsym(handle, "symbol_name"); stuff.
> 
    We need to call dlsym() only once, ie. when the frontend
    resolves the init_rig symbol. Then, the init_rig function
    will register the capabilities in the frontend rig list.
    And that's it! Thanks to the cool API design.

> 4. A whole lot more to come, but you see the idea.
> 
	Well, very much. The registering and rig_load_backend()
  are coded, and are working fine! There's only a couple of
  lines to add in a backend to support it!
  I haven't commited this code yet, just to let you some time
  to catch up with the last commit. I will do on monday.

> 5. GNU libtool ??
> 
	done already with autoconf/automake stuff

> 6. Lots of other stuff to follow...
> 
	yup, sure!

-- 
Stephane Fillod					F4CFE

[Hamlib-developer] important commit: dir reorganized, autoconf added

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

Hi,

I can't tell you for the Olympics, I don't have TV.
However, I heard on the radio that the french basket ball 
team made his way to final, beating you know who during
their previous game ;-)  Besides that, I don't think we
have a chance with the USA..

Okay, enough noise, let have some signal:

I've finaly reorganized a bit the Hamlib directories,
please see my previous mail for an idea of the new tree.
The common/ directory is to be removed very soon
(-> Attic), all the sources moved to src/

Next, I've played a bit with automake/autoconf. Now, the whole
Hamlib module is ruled by these handy applications.
Once you have the configure.in, and Makfile.am's files,
here is what you need to do in the hamlib dir the first time:

	$ aclocal
	$ autoheader
	$ automake --add-missing --copy --include-deps
	$ autoconf

If the main Makefile is already generated (by ./configure),
then the sub Makfile will be automatically generated
(ie. no need to re-issue all these commands! make and that's it!).
This is pretty cool, the only thing I've haven't figured
out is the shared lib directory setting.
Right now, these files are located in src/.libs/, icom/.libs/,
ft847/.libs/, and so on.
So if you want to run any of the tests/ dir apps, you will have
to set your LD_LIBRARY_PATH to all these dirs. This is only a quick
work around until we have the backend registering interface.

  $ export LD_LIBRARY_PATH=`pwd`/src/.libs:`pwd`/ft847/.libs:`pwd`/ft747/.libs:`pwd`/icom/.libs

The good news is all of this compile, link, run, and do what 
it is supposed to do! Yesterday, I grabbed a MAX232, a handfull of caps
to make a V.24<->CI-V converter, and I am now able to control
my IC706MKIIG using hamlib!!! yipeee :-)
Well, I still have a bunch of API calls to implement, but that should
be fairly easy with the generic layout.

Meanwhile, I've added couple of simple features, like convenient
debugging, generic bcd functions, and a printcaps program that dumps
in a human readable form the capabilities of a rig.
There must other changes I forget to mention here, but they're
listed in the CVS rep (BTW, maybe a cvs-commit-digest mailing list would help)

Next on the TODO list: the backend registering stuff with dynamic loading..
Big time!

-- 
Stephane Fillod					F4CFE

Re: [Hamlib-developer] common reorganise and Makefile updates

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

Stephane Fillod wrote:
> 
>  Frank Singleton wrote:
> >
> > And , libhamlib.so.1.0.1 is born !! I feel like a proud dad ;-()
> >
>   Hold on, I just broke it again. Nah, just kidding ;-)
>   Good work on the Makefiles!

Thanks ..

> 
> > Made common/include and common/lib where lib headers and hamlib.so
> > can be stored.

> >
>   Hmm, IMO, this is not the best approach.
>   According to most GNU projects, the directory hierarchy should
>   look like something as following(not exhaustive):

This was just to start compiling the frontend lib for verification
of what we had done so far ... 


<snip>

Lets do it ..

> If you agree with this organisation, I'll do that tomorrow,
> along with the autoconf setup.

Yep, sounds good to me :-)

> 
> We should definitely clean up the source tree, make a compilable/linkable/
> runnable release (hamlib-1.1.0), and then summon for help/advices/wishes
> from other linux-hams.


Yes, lets get directory organized.  A hamlib release done, and then
we have something to show and attract others :-)


> Also it would be good to make it clear that hamlib is not CAT specific
> (as one might understand from sourceforge summary or radio.linux.org.au),
> nor linux specific (it should be developped to run on any UNIX flavors,
> and also on Win32/etc.)

Check the updated summary.. (limited to 255 characters)

I think it would be good to get the reorg done, and then I will
post to various groups about our project, its goals, status,
and request for help.


> 
> Have fun..
> 
> PS: have you checked out http://google.com page lately? I'm sure
>     you'll like it ;-)

Yeah, talented little kangaroo :-)

Cheers / Frank

-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com

[Hamlib-developer] libhamlib frontend ok

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

Hi,

Some activity, when not watching Olympics... :)

I have successfully built testrig.c and linked it
against libhamlib frontend , and run part of it 
successfully - cool !!!!!!!!!

rig.c
-----

Removed rig_caps references for the time being, and replaced with
a more generic declaration. At least now I can build "libhamlib.0.0.1"
ok, and link testrig against it, and run it !! yippeee :-)


#if 0
static const struct rig_caps *rig_base[] = { 
	&ft747_caps, &ic706_caps, &ic706mkiig_caps, /* ... */ NULL, };

#endif

/*
 * removed references to xxx_caps for testing. perhaps we should use
 * the declaration below, an dthnk about populating it another way -- FS
 *
 */


#define MAXRIGSIZE  10		/* put this in .h later */
static const struct rig_caps *rig_base[MAXRIGSIZE];


Also,

Added a few printf's to verify rig_xxx is being called ok.


Makefile.testrig
----------------

Created this make file to allow compiling and linking
of testrig.c against "libhamlib"

make -f Makefile.testrig
make -f Makefile.testrig runtest
make -f Makefile.testrig cleanlocal


Some output as follows, we are getting closer !!

[frank@kirk common]$ make -f Makefile.testrig runtest
LD_LIBRARY_PATH="./lib" ./testrig ; ldd ./testrig
testrig:main() has been called
rig:rig_init called
        libm.so.6 => /lib/libm.so.6 (0x4001a000)
        libhamlib.so.0 => ./lib/libhamlib.so.0 (0x40037000)
        libc.so.6 => /lib/libc.so.6 (0x4003c000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
[frank@kirk common]$                                         


Outstanding
-----------

1. Get a good way of populating rig_base[] array.
2. Test drive a backend lib after frontend dlopens the
   approriate backend.
3. Symbol resolution - needs a generic approach here..

Cheers / Frank..

-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com

Re: [Hamlib-developer] common reorganise and Makefile updates

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

Frank Singleton wrote:
> 
> And , libhamlib.so.1.0.1 is born !! I feel like a proud dad ;-()
> 
  Hold on, I just broke it again. Nah, just kidding ;-)
  Good work on the Makefiles!

> Made common/include and common/lib where lib headers and hamlib.so
> can be stored.
> 
  Hmm, IMO, this is not the best approach.
  According to most GNU projects, the directory hierarchy should
  look like something as following(not exhaustive):

hamlib
 |-- README
 |-- INSTALL
 |-- Makefile.in
 |-- configure
 |-- LICENSE
 |-- any other all-uppercase file
 |-- include				# exported includes
 |   |-- rig.h				# API interface
 |   `-- riglist.h
 |-- lib				# compiled libs
 |   |-- backend
 |   |   |-- libft747.so
 |   |   `-- libicom.so
 |   |-- libhamlib.so -> libhamlib.so.1
 |   |-- libhamlib.so.1 -> libhamlib.so.1.0.1
 |   `-- libhamlib.so.1.0.1
 |-- etc
 |   `-- hamlib.conf			# pref file locating backend.so list
 |-- src				# used to be common/
 |   |-- rig.c
 |   |-- register.c			# backend registering
 |   |-- misc.c				# hex_dump, BCD stuff, etc.
 |   |-- serial.c
 |   |-- serial.h
 |   `-- any other frontend sources
 |-- test
 |   |-- testrig.c			# sample test program
 |   `-- any regression test suite?
 |-- docs
 |   |-- html
 |   |-- man
 |   `-- well documented API in various formats
 |-- mybackendrig
 |   |-- mybackendrig.h
 |   `-- mybackendrig.c
 `-- myotherbackendrig
     `-- myotherbackendrig.c

What do you think of it?
If you agree with this organisation, I'll do that tomorrow (well today),
along with the autoconf setup.

We should definitely clean up the source tree, make a compilable/linkable/
runnable release (hamlib-1.1.0), and then summon for help/advices/wishes
from other linux-hams.
Also it would be good to make it clear that hamlib is not CAT specific
(as one might understand from sourceforge summary or radio.linux.org.au),
nor linux specific (it should be developped to run on any UNIX flavors,
and also on Win32/etc.)

Have fun..


PS: have you checked out http://google.com page lately? I'm sure 
    you'll like it ;-)

-- 
Stephane Fillod					F4CFE

Re: [Hamlib-developer] common reorganise and Makefile updates

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

 Frank Singleton wrote:
> 
> And , libhamlib.so.1.0.1 is born !! I feel like a proud dad ;-()
> 
  Hold on, I just broke it again. Nah, just kidding ;-)
  Good work on the Makefiles!

> Made common/include and common/lib where lib headers and hamlib.so
> can be stored.
> 
  Hmm, IMO, this is not the best approach.
  According to most GNU projects, the directory hierarchy should
  look like something as following(not exhaustive):

hamlib
 |-- README
 |-- INSTALL
 |-- Makefile.in
 |-- configure
 |-- LICENSE
 |-- any other all-uppercase file
 |-- include				# exported includes
 |   |-- rig.h				# API interface
 |   `-- riglist.h
 |-- lib				# compiled libs
 |   |-- backend
 |   |   |-- libft747.so
 |   |   `-- libicom.so
 |   |-- libhamlib.so -> libhamlib.so.1
 |   |-- libhamlib.so.1 -> libhamlib.so.1.0.1
 |   `-- libhamlib.so.1.0.1
 |-- etc
 |   `-- hamlib.conf			# pref file locating backend.so list
 |-- src				# used to be common/
 |   |-- rig.c
 |   |-- register.c			# backend registering
 |   |-- misc.c				# hex_dump, BCD stuff, etc.
 |   |-- serial.c
 |   |-- serial.h
 |   `-- any other frontend sources
 |-- test
 |   |-- testrig.c			# sample test program
 |   `-- any regression test suite?
 |-- docs
 |   |-- html
 |   |-- man
 |   `-- well documented API in various formats
 |-- mybackendrig
 |   |-- mybackendrig.h
 |   `-- mybackendrig.c
 `-- myotherbackendrig
     `-- myotherbackendrig.c

What do you think of it?
If you agree with this organisation, I'll do that tomorrow,
along with the autoconf setup.

We should definitely clean up the source tree, make a compilable/linkable/
runnable release (hamlib-1.1.0), and then summon for help/advices/wishes
from other linux-hams.
Also it would be good to make it clear that hamlib is not CAT specific
(as one might understand from sourceforge summary or radio.linux.org.au),
nor linux specific (it should be developped to run on any UNIX flavors,
and also on Win32/etc.)

Have fun..


PS: have you checked out http://google.com page lately? I'm sure 
    you'll like it ;-)

-- 
Stephane Fillod					F4CFE

[Hamlib-developer] backend lib loading strategy.

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

Hi,

In between the Olympic events I had some thoughts
on loading strategies, and share them below.

After browsing man page for dl_open etc... :-)

Reference Example.

<snip>
       Load the math library, and print the cosine of 2.0:
              #include <dlfcn.h>
 
              int main(int argc, char **argv) {
                  void *handle = dlopen ("/lib/libm.so", RTLD_LAZY);
                  double (*cosine)(double) = dlsym(handle, "cos");
                  printf ("%f\n", (*cosine)(2.0));
                  dlclose(handle);
              }
 <snip>

1. frontend should load appropriate backend lib
   at say, rig_init or similar.

2. multiple instances of same RIG type should not 
   cause multiple dl_open requests ??

3. Must have way of resolving symbol names for
   dlsym(handle, "symbol_name"); stuff.

  eg: for things like ..
  void *handle = dlopen ("libft747.so", RTLD_LAZY);
  int (*cmd_set_vfo)(vfo_t vfo)= dlsym(handle, "rig_set_vfo");
   (*cmd_set_vfo)(RIg_MAIN_VFO)

etc..	

4. A whole lot more to come, but you see the idea.

5. GNU libtool ??

6. Lots of other stuff to follow...

/Frank
        
-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com

[Hamlib-developer] common reorganise and Makefile updates

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

Hi,

Made some updates to common/Makefile so "make", "make install"
and "make clean" work as expected. Still some things to sort out
but at least it gives us some framework..

And , libhamlib.so.1.0.1 is born !! I feel like a proud dad ;-()

Made common/include and common/lib where lib headers and hamlib.so
can be stored.

Here is the common/ tree after doing "make" and "make install" from
common/ directory. This is the same structure as backend
libs for consistency.


[frank@kirk common]$ tree
.
|-- API_Candidates
|-- CVS
|   |-- Entries
|   |-- Repository
|   `-- Root
|-- Makefile
|-- include
|   |-- CVS
|   |   |-- Entries
|   |   |-- Repository
|   |   `-- Root
|   |-- rig.h
|   |-- riglist.h
|   `-- serial.h
|-- lib
|   |-- CVS
|   |   |-- Entries
|   |   |-- Repository
|   |   `-- Root
|   |-- libhamlib.so -> libhamlib.so.1
|   |-- libhamlib.so.1 -> libhamlib.so.1.0.1
|   `-- libhamlib.so.1.0.1
|-- rig.c
|-- rig.h
|-- rig.o
|-- riglist.h
|-- serial.c
|-- serial.h
|-- serial.o
`-- testrig.c            


Cheers / Frank..

-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com

Re: [Hamlib-developer] API suggestions

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

Stephane Fillod wrote:
> 
...
> Just a word about the {cmd,backend}_get_* functions. IMO, it's not a good
> idea to have them return the data immediately, because we may loose
> the return code in case of failure. So I would stick with something like
> this:
>         int cmd_get_freq(RIG *rig, freq_t *freq);
> 

I like this format, set passes freq, get passes *freq etc..
and returning "int" covers return code..

> Your struct channel looks fine, we need also to support splits:
> So instead of having only one "freq_t freq" field,
> maybe we ought to have
> 
>   freq_t rxfreq;
>   freq_t txfreq;
> 
> and also:
> 
>   unsigned long func; /* bitwise OR'ed RIG_FUNC_AGC, NB, et al. */
>   unsigned long tuning_step; /* freq_t is not needed here */
>   rig_rptr_shift_t rptr_shift; /* repeater shift is not (cross)split */
> 
> Not to mention the Preamp/Att state (expressed in dB?), and the selected
> antenna too (provided the rig supports it of course).
> 
> Correct me if I'm wrong, the purpose of the "struct channel" is designed
> to manage freq memories, right? 

Yep..

>Oh, yeah, it can be convenient
> to use it to get the state of the current vfo, all at once! is what
> you intended with get_channel/set_channel or is it for memory managment
> exclusively?  maybe both if the memory number is not defined (eg. -1)?
> 

Hopefully we can  use it for both ..

> Comments?

frontend starting to look good.

Perhaps a "general.c" file for stuff like hex_dump(), bcd conversions,
dBm <-> milliwatts, whatever
etc so I can rip them out of serial.[ch] 

Comments ??


/Frank

-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com

[Hamlib-developer] updates

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

Hi,

ft747.[ch] / ft847.[ch]
------------------------

Updated caps structures

testrig.c
---------

Examples of set/get with simple error checking

common/Makefile
----------------

simple hack to allow "make hamlib" as a target.
Still lots to do, includign autoconf one day :0

What do you think about making a lib and include
directory under common where the frontend lib
can be "make install'd", similar to backend
directory structure. also, a  common/test
diretory also.

eg:
common/lib
common/include
common/test

Also testrig can use these directories to find
libhamlib frontend and include file to match and
link against when testing.

serial.c
--------
updated read_sleep to use usleep

Cheers / Frank

-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com

Re: [Hamlib-developer] API suggestions

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

Frank Singleton wrote:
> 
> So if frontend API says
> 
>     int (*set_freq)(RIG *rig, freq_t freq);
>     int (*set_mode)(RIG *rig, rig_mode_t mode);
>     int (*set_vfo)(RIG *rig, rig_vfo_t vfo);
> 
> backend equivalents for ft747
> 
>    int ft747_set_freq(RIG *rig, freq_t freq);
>    int ft747_set_mode(RIG *rig, rig_mode_t mode);
     int ft747_set_vfo(RIG *rig, rig_vfo_t vfo);
[...]
> etc..
> 
> What do you think ??

 make sense!

freq_t cmd_get_freq(RIG *rig);

Just a word about the {cmd,backend}_get_* functions. IMO, it's not a good
idea to have them return the data immediately, because we may loose
the return code in case of failure. So I would stick with something like 
this:
	int cmd_get_freq(RIG *rig, freq_t *freq);


Your struct channel looks fine, we need also to support splits:
So instead of having only one "freq_t freq" field,
maybe we ought to have

  freq_t rxfreq;
  freq_t txfreq;

and also:

  unsigned long func; /* bitwise OR'ed RIG_FUNC_AGC, NB, et al. */
  unsigned long tuning_step; /* freq_t is not needed here */
  rig_rptr_shift_t rptr_shift; /* repeater shift is not (cross)split */

Not to mention the Preamp/Att state (expressed in dB?), and the selected
antenna too (provided the rig supports it of course).

Correct me if I'm wrong, the purpose of the "struct channel" is designed
to manage freq memories, right? Oh, yeah, it can be convenient
to use it to get the state of the current vfo, all at once! is what
you intended with get_channel/set_channel or is it for memory managment 
exclusively?  maybe both if the memory number is not defined (eg. -1)?

Comments?

-- 
Stephane					F4CFE

Re: [Hamlib-developer] rig_caps_register

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

Frank Singleton wrote:
> 
> In order for rig.c to populate the  rig_caps array automagically,as
> suggested
> 
[..]
> We could have backend call a frontend rig_caps_register function that
> simple passes an address of their own cap structure into
> the rig_caps array in rig.c
> 
> ie:
> 
> int rig_caps_register(RIG *rig) {
> 
you mean	int rig_caps_register(const struct rig_caps *my_backend_caps)

> .... insert cap ptr into rig_base[]
> .... and return result to caller
> 
> }
> 
> This way,  frontend can init all backends via a rig_backend_poll()
> function. backends must respond by registering their caps,
> rig_caps_register() and
> any other things we may add in future :-)
> 
  So if I understand correctly, the rig_backend_poll() function
  (called by who?) would call some backend initializer function
  (constructor?) that would in term call rig_caps_register().
  Well, this is not too far fetched, especially if you consider
  the dlopen/_init facility (in case of external loadable modules).

> This way 
> 
> rig_caps *rig_base[MAX_RIG_CAPS]  will be 
> dynamically populated.
> 
> eg:
> 
> frontend                   backend
> --------                   -------
> 
> for all rigs do

   gotcha! there you still have to have a backend array with pointer to
   functions, or at least explicitly reference all the backend
   constructors.
> 
>       rig_backend_poll
>     --------------------->
> 
>          rig_caps_regisyter
>      <---------------------  ft747_caps
> 
>       rig_backend_poll
>     --------------------->
> 
[...]

> rig_base[] is now populated ...
> 
> 
> The rig_backend_poll could be done at
> loading of the frontend libhamlib library that
> can access all the backends.
> 
  This idea needs some maturation, let's think about it,
  see how we can work it out.


> Also, should we have 1 lib "libhamlib"
> that contains the frontend and all the backends (easy), or
> should we load frontend "libhamlib" and he can
> dynamically load backend libraries on demand.
> This second option is probably more 
> professional ;-)

  and also more fun :-) 
  As usual, I think both are good, like in SANE (no pun here :)

-- 
Stephane Fillod					F4CFE

Re: [Hamlib-developer] Re: API suggestions

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

Stephane Fillod wrote:


<snip>

> REM: the problem with xxxx_t cmd_get_xxx(RIG *rig) would be the
>      unability to check the return code.

I have seen in some circumstances the  use  of stuff like

struct ret_val {
	return_value;
	int validity_indicator;
}

struct ret_val *get_whatever(..)

So when you get a ptr to ret_val when returning
from the function, you can always check the
"data valid indicator" to see if there is a 
proper return_value, or if the indicator says,
an error occurred. 

Could we use this for setting and getting data ??

Or, pass &result into functions so that it may be set like

int rig_get_mode(RIG *rig, mode_t mode, int *result)

ie: rig_get_mode updates mode and result.

Comments ??

> 
> BTW, is the "_" in "cmd_set_xxx_" a typo ?

TYPO !! :-()

> 
> Also, I'm thinking that the "cmd_" prefix can generate some namespace
> clashes (well, no if the other objects is not dealing with vfo's
> and ham specific stuff :). Anyway, would it be better to have this:
> 
>         rig_set_mode(RIG *rig, rig_mode_t mode)
>         rig_set_vfo(RIG *rig, vfo_t vfo)
>         rig_set_freq(RIG *rig, freq_t freq)
>         rig_set_filter(RIG *rig, filter_t filter)
> 

Thats fine, I am glad we can agree before the API gets too big :-)

> Talking about namespace, I'd prefer to have mode_t instead of rig_mode_t.
> Should you see any concern?

mode_t looks good to me

> 
> About convenience functions like:
> >
> > cmd_set_channel_(RIG *rig,freq_t freq, rig_mode_t mode, vfo_t vfo
> > ....,,,, filter_t filter..)
> >
> > is some frontend convenience function that backend libs can handle
> > either directly as is toward the rig if the rig can handle it that way,
> > or the backend lib breaks it into the simpler functions shown above if
> > the rig needs it that way. We dont care up the front how its done
> > int the back of course (apart from efficiency issues of course)!
> >
> 
> In your previous mail, you were proposing that we can pass NULL
> parameters into the cmd_set for those things you
> dont want to change since previos command. Well, it depends
> on what your understanding of NULL. For instance, 0 can be meaningfull
> for the vfo_t type, etc.  (anyway, we can use -1)

I guess we should have a value that has no meaning in any other
context than indicating PARAM_NULL (-1 is a candidate of course).

But, using rig_set_mode(rig,mode) is maybe cleaner than
rig_set_channel(rig,NULL_PARAM, mode, NULL_PARAM, NULL_PARAM ..)


> > Ok, now I sleep better !!
> >
> 
> Sometimes, coding is like certain ham bands,
> it's only open at night :-)
> 

Yeah, I sometimes have bit too much D-layer absorbption
in the neural net sometimes.. :)

> --
> Stephane                                        F4CFE
>

Also, many times I get the following errors from your mail


    **********************************************
    **      THIS IS A WARNING MESSAGE ONLY      **
    **  YOU DO NOT NEED TO RESEND YOUR MESSAGE  **
    **********************************************

The original message was received at Mon, 18 Sep 2000 11:18:14 +0200
from cismrelais.univ-lyon1.fr [134.214.101.250]

   ----- The following addresses had transient non-fatal errors -----
ste...@en...
    (expanded from: <ste...@in...>)


OR


    **********************************************
    **      THIS IS A WARNING MESSAGE ONLY      **
    **  YOU DO NOT NEED TO RESEND YOUR MESSAGE  **
    **********************************************

The original message was received at Mon, 18 Sep 2000 07:59:37 +0200
from cismrelais.univ-lyon1.fr [134.214.101.250]

   ----- The following addresses had transient non-fatal errors -----
ste...@en...
    (expanded from: <ste...@in...>)

   ----- Transcript of session follows -----
... while talking to hotu.ens.insa-rennes.fr.:
>>> MAIL From:<vk...@ix...> SIZE=1811
<<< 451 <vk...@ix...>... Go away!
ste...@en...... Deferred: 451
<vk...@ix...>... Go away!
Warning: message still undelivered after 4 hours
Will keep trying until message is 5 days old

So, you may have to check hamlib-developer instead ??

/Frank..
-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com

[Hamlib-developer] Re: API suggestions

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

Frank Singleton wrote:
> 
> Actually now that I think about it, the cleanest approach
> is probably for the frontend API to provide as a minimum functions
> like 
> 
> cmd_set_mode(RIG *rig, rig_mode_t mode)
> cmd_set_vfo(RIG *rig, vfo_t vfo)
> cmd_set_freq_(RIG *rig, freq_t freq)
> cmd_set_filter_(RIG *rig, filter_t filter)
> 
> and in general
> cmd_set_xxx_(RIG *rig, xxx_t xxx)

and cmd_get_xxx(RIG *rig, xxx_t *xxx)
REM: the problem with xxxx_t cmd_get_xxx(RIG *rig) would be the
     unability to check the return code.

BTW, is the "_" in "cmd_set_xxx_" a typo ?

Also, I'm thinking that the "cmd_" prefix can generate some namespace
clashes (well, no if the other objects is not dealing with vfo's 
and ham specific stuff :). Anyway, would it be better to have this:

	rig_set_mode(RIG *rig, rig_mode_t mode)
	rig_set_vfo(RIG *rig, vfo_t vfo)
	rig_set_freq(RIG *rig, freq_t freq)
	rig_set_filter(RIG *rig, filter_t filter)

Talking about namespace, I'd prefer to have mode_t instead of rig_mode_t.
Should you see any concern?

About convenience functions like:
> 
> cmd_set_channel_(RIG *rig,freq_t freq, rig_mode_t mode, vfo_t vfo
> ....,,,, filter_t filter..)
> 
> is some frontend convenience function that backend libs can handle
> either directly as is toward the rig if the rig can handle it that way, 
> or the backend lib breaks it into the simpler functions shown above if 
> the rig needs it that way. We dont care up the front how its done
> int the back of course (apart from efficiency issues of course)!
> 

In your previous mail, you were proposing that we can pass NULL
parameters into the cmd_set for those things you
dont want to change since previos command. Well, it depends
on what your understanding of NULL. For instance, 0 can be meaningfull 
for the vfo_t type, etc.  (anyway, we can use -1)

> 
> Ok, now I sleep better !!
> 

Sometimes, coding is like certain ham bands, 
it's only open at night :-)


-- 
Stephane					F4CFE

[Hamlib-developer] API Updates

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

Hi,

Started to think about  API  set/get functions.

rig.h
-----


Added  channel struct for mem handling and possible convenience
functions.

struct channel {
  int channel_num;
  freq_t freq;
  mode_t mode;
  vfo_t vfo;
  char channel_desc[MAXCHANDESC];
};

Added set/get pairs for API in rig_caps struct

<snip>

  /*
   *  General API commands, from most primitive to least.. :()
   *  List Set/Get functions pairs
   */
  
  int (*set_freq)(RIG *rig, freq_t freq); /* select freq */
  struct freq_t (*get_freq)(RIG *rig); /* get freq */

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

  int (*set_vfo)(RIG *rig, rig_vfo_t vfo); /* select vfo */
  struct rig_vfo_t (*get_vfo)(RIG *rig); /* get vfo */

  int (*set_ptt)(RIG *rig, rig_ptt_t ptt); /* ptt on/off */
  struct rig_ptt_t (*get_ptt)(RIG *rig); /* get ptt status */

  int (*set_rpt_shift)(RIG *rig, rig_rptr_shift_t rig_rptr_shift ); /*
set repeater shift */
  struct rig_rptr_shift_t (*get_rpt_shift)(RIG *rig); /* get repeater
shift */

/* etc */
  
/*
 * Convenience Functions
 * 
 */

  int (*set_channel)(RIG *rig, struct channel ch);
  int (*get_channel)(RIG *rig, freq_t freq, rig_mode_t mode, rig_vfo_t
vfo);


<snip>

rig.c
------

Added 3 commands to rig.c for examples
cmd_set_freq
cmd_set_mode
cmd_set_vfo

Compiles ok (no linking) with 
 gcc -c rig.c -I.   


testrig.c
----------
Updated testrig.c with 3 examples also

Compiles ok (no linking) with 
 gcc -c testrig.c -I.   


Cheers / Frank..


    

-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com

[Hamlib-developer] rig_caps_register

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

Hi,

In order for rig.c to populate the  rig_caps array automagically,as
suggested



<snip>
/*
 * It would be nice to have an automatic way of referencing all the
backends
 * supported by hamlib. Maybe this array should be placed in a separate
file..
 * 
 * The rig_base is a variable length rig_caps* array, NULL terminated
 */

static const struct rig_caps *rig_base[] = { 
	&ft747_caps, &ic706_caps, &ic706mkiig_caps, /* ... */ NULL, };


We could have backend call a frontend rig_caps_register function that
simple passes an address of their own cap structure into
the rig_caps array in rig.c

ie:

int rig_caps_register(RIG *rig) {

.... insert cap ptr into rig_base[]
.... and return result to caller

}


This way,  frontend can init all backends via a rig_backend_poll()
function. backends must respond by registering their caps,
rig_caps_register() and
any other things we may add in future :-)

This way 

rig_caps *rig_base[MAX_RIG_CAPS]  will be 
dynamically populated.

eg:

frontend                   backend
--------                   -------

for all rigs do

      rig_backend_poll
    --------------------->

         rig_caps_regisyter
     <---------------------  ft747_caps

      rig_backend_poll
    --------------------->

         rig_caps_regisyter
     <---------------------  ft847_caps

                  ...

  
      rig_backend_poll
    --------------------->

         rig_caps_regisyter
     <---------------------  icom_caps


rig_base[] is now populated ...


The rig_backend_poll could be done at
loading of the frontend libhamlib library that
can access all the backends.

Question:

Also, should we have 1 lib "libhamlib"
that contains the frontend and all the backends (easy), or
should we load frontend "libhamlib" and he can
dynamically load backend libraries on demand.
This second option is probably more 
professional ;-)


Comments ??


-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com

Re: [Hamlib-developer] API suggestions

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

Hi,

Thinking about naming convention for maintenance :0
when we have all these functions in the backend 
mapping (via pointers )onto the frontend declarations..

frontend prototype says...

<snip> from rig.h

struct rig_caps {
	rig_model_t rig_model; /* eg. RIG_MODEL_FT847 */
	unsigned char model_name[RIGNAMSIZ]; /* eg "ft847" */
	unsigned char mfg_name[RIGNAMSIZ]; /* eg "Yeasu" */
	char version[RIGVERSIZ]; /* driver version, eg "0.5" */
	enum rig_status_e status; /* among ALPHA, BETA, STABLE, NEW  */
	enum rig_type_e rig_type;
	int serial_rate_min; /* eg 4800 */
	int serial_rate_max; /* eg 9600 */
	int serial_data_bits; /* eg 8 */
	int serial_stop_bits; /* eg 2 */
	enum serial_parity_e serial_parity; /* */
	enum serial_handshake_e serial_handshake; /* */
	int write_delay;		/* delay in ms between each byte sent out */
	int timeout;	/* in ms */
	int retry;		/* maximum number of retries, 0 to disable */
	struct freq_range_list rx_range_list[FRQRANGESIZ];
	struct freq_range_list tx_range_list[FRQRANGESIZ];

	int (*rig_init)(RIG *rig);	/* setup *priv */
	int (*rig_cleanup)(RIG *rig);
	int (*rig_open)(RIG *rig);	/* called when port just opened */
	int (*rig_close)(RIG *rig);	/* called before port is to close */
	int (*rig_probe)(RIG *rig); /* Experimental: may work.. */
  
       /* cmd API below */
	int (*set_freq_main_vfo_hz)(RIG *rig, freq_t freq, rig_mode_t mode);

  /*
    int (*set_freq)(RIG *rig, freq_t freq);
    int (*set_mode)(RIG *rig, rig_mode_t mode);
    int (*set_vfo)(RIG *rig, rig_vfo_t vfo);
  */


<snip>

So if frontend API says

    int (*set_freq)(RIG *rig, freq_t freq);
    int (*set_mode)(RIG *rig, rig_mode_t mode);
    int (*set_vfo)(RIG *rig, rig_vfo_t vfo);



backend equivalents for ft747

   int ft747_set_freq(RIG *rig, freq_t freq);
   int ft747_set_mode(RIG *rig, rig_mode_t mode);
   int ft747_(RIG *rig, rig_vfo_t vfo);

backend equivalents for ft847

   int ft847_set_freq(RIG *rig, freq_t freq);
   int ft847_set_mode(RIG *rig, rig_mode_t mode);
   int ft847_(RIG *rig, rig_vfo_t vfo);

etc..

What do you think ??


-- Frank

[Hamlib-developer] API suggestions

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

Hi,

previously, on this channel.....
> 
> > > cmd_set_freq(RIG *rig,freq_t freq, rig_mode_t mode, vfo_t vfo )
> > > long int cmd_get_freq_mode_status(RIG *rig, unsigned char *mode, vfo_t
> > > vfo);
> > >
> >   Looks definitely better this way!
> >   Just a question: what if the application just wants to change
> >   the mode only? It might be troublesome in certain case to have
> >   to remember the current frequency or having to query it.
> 
> true, I guess we have some options...
> 
> API provides
> cmd_set_freq_(RIG *rig,freq_t freq, rig_mode_t mode, vfo_t vfo )
> 
> and possibly
> cmd_set_mode(RIG *rig, rig_mode_t mode)
> cmd_set_vfo(RIG *rig, vfo_t vfo)


I must have had too many beers during the Olympic opening
ceremony :-)


Actually now that I think about it, the cleanest approach
is probably for the frontend API to provide as a minimum functions
like 

cmd_set_mode(RIG *rig, rig_mode_t mode)
cmd_set_vfo(RIG *rig, vfo_t vfo)
cmd_set_freq_(RIG *rig, freq_t freq)
cmd_set_filter_(RIG *rig, filter_t filter)

and in general
cmd_set_xxx_(RIG *rig, xxx_t xxx)

and that optional  convenience functions like 

cmd_set_channel_(RIG *rig,freq_t freq, rig_mode_t mode, vfo_t vfo
....,,,, filter_t filter..)

is some frontend convenience function that backend libs can handle
either directly as is toward the rig if the rig can handle it that way, 
or the backend lib breaks it into the simpler functions shown above if 
the rig needs it that way. We dont care up the front how its done
int the back of course (apart from efficiency issues of course)!


So, 1 frontend convenience functions may cause multiple backend
calls to the rig as it iterates through the convenience functions
argumant list and  calls individual "primitives" towards the rig.

Ok, now I sleep better !!

Should be no state issues to deal with..

just trying to avoid long function names like
cmd_set_freq_mode_vfo_filter_power_this_that_whatever(....)

Comments ??

/Frank..

Re: [Hamlib-developer] frontend API function reduction

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

Stephane Fillod wrote:

> 
>   ..provided we have the specs. May be we can sumon some help
>   by sending an announce on lin...@vg...
>   and lin...@de... mailing lists.
> 

Yep, let me fix ft747 and ft847 asap, and we can announce for help
and show some partly working stuff ;-)


> > cmd_set_freq(RIG *rig,freq_t freq, rig_mode_t mode, vfo_t vfo )
> > long int cmd_get_freq_mode_status(RIG *rig, unsigned char *mode, vfo_t
> > vfo);
> >
>   Looks definitely better this way!
>   Just a question: what if the application just wants to change
>   the mode only? It might be troublesome in certain case to have
>   to remember the current frequency or having to query it.

true, I guess we have some options...


API provides
cmd_set_freq_(RIG *rig,freq_t freq, rig_mode_t mode, vfo_t vfo ) 

and possibly 
cmd_set_mode(RIG *rig, rig_mode_t mode)
cmd_set_vfo(RIG *rig, vfo_t vfo)

and allow backend to 


if an app calls the generic function
cmd_set_freq_mode_vfo(RIG *rig,freq_t freq, rig_mode_t mode, vfo_t vfo ) 

then if rig later sends
cmd_set_mode(RIG *rig, rig_mode_t mode), we could..

2.  preserve last command params sent in the backend libs.
    this way a cmd_set_mode(rig_mode_t mode) can
    call a cmd_set_freq( ..freq,mode) if that rigs
    opcode command require all aparameters. Otherwise the backend just
sends the
    cmd_set_mode() change.A small overhead, but covers both cases.
    (less yuck !)
     ps: my 2 yaesu can  handle a mode change independant of other stuff

3. Pass NULL parameters into the cmd_set for those things you
    dont want to change since previos command ??

comments ?????


> serial.c
> --------
> serial_open()   open and setup a serial port, fully RIG* aware,
>                 cloned from open_port2()

great !

> write_block2() handles optional write_delay
> read_block() does passive blocking(select), and have timeout handling

> open_port2() has been busted (outdated refs to rig_caps), use serial_open()?
> 

yep, we can kill this.

> Question: What do you think of write_block2() ? Would you agree
>                 to replace write_block() by write_block2() ?
> 

yep, that way it covers all rig types, I had to start somewhere :-)


> Next stage: the linking  ;-)

ahh lovely stuff !
> 
> I'm sorry Frank, with the new API and frontend/backend, you'll have
> to modify your ft847 code. 

will update this weekend, its Olympics in vk3 land (actually vk2)
but I live and watch from texas USA.

BTW, do all the Yeasu rigs have the same
> "CAT" protocol as Icoms do with "CI-V" ? In this case, may be it will
> be easier for you to factorize some code.

so far the 2 yaesus have same 5 block cmd, but no commonality
between opcodes and freq packing into BCD etc..


/ Frank..

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

-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com

Re: [Hamlib-developer] frontend API function reduction

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

On Fri, Sep 15, 2000, Frank Singleton wrote:
> 
> Well nothing compiles now (sob), so lets get the
> general API and interwork API firmed up...
> 
Sorry about that, I forgot to let you know in my previous mail...
Acutally, I was so eager to show off the new frontend/backend approach!

Usually, we don't write the software specifications after the development :-)
The same goes for an API implementation. 
So it doesn't matter much if the code is broken if the API is not yet
specified! We're still in ALPHA stage, after all. Clean compiles is yet BETA
(and considered stable for MS :).

> I am keen to get a good general (extensible) infrastructure in place.
> 
good! let's do it!

> eg: If previous co compiles, and your or my next ci is known
> to break this, we should think about tagging it in CVS.
> 
	Agree with you! To me, the hamlib-1.0.3 is the latest
  clean compile. Also about version numbers, would it be better
  to have odd numbers for development phases, and even number
  for stable code, ala Linux kernel? With 1.0.3, people
  might think that the library is already ready to use (which is not!)

>
> backend must implement all opcodes (of course)

  ..provided we have the specs. May be we can sumon some help
  by sending an announce on lin...@vg...
  and lin...@de... mailing lists.

> This creates a large function namespace, this is ok as there
> shall be wrappers for them up front anyway. Also, bakend must test
> all opcodes anyway.
> 
> However, frontend should have reduced namespace for function calls.
> 
> eg result, 2 functions up front ....
> 
> cmd_set_freq(RIG *rig,freq_t freq, rig_mode_t mode, vfo_t vfo )
> long int cmd_get_freq_mode_status(RIG *rig, unsigned char *mode, vfo_t
> vfo);
> 
  Looks definitely better this way!
  Just a question: what if the application just wants to change
  the mode only? It might be troublesome in certain case to have
  to remember the current frequency or having to query it.

> 
> so, lets create some enums
> 

allright! more to come I'm sure.


new stuff I've checked in:

serial.c
--------
serial_open()	open and setup a serial port, fully RIG* aware,
		cloned from open_port2()
write_block2() handles optional write_delay
read_block() does passive blocking(select), and have timeout handling
open_port2() has been busted (outdated refs to rig_caps), use serial_open()?

Question: What do you think of write_block2() ? Would you agree 
		to replace write_block() by write_block2() ?

frontend:
--------
rigcaps.h has been cut and pasted into rig.h in order to fix the cyclic
forward references. Updated some data struct, added flow_control/retry/timeout
See the testrig.c example to see how to use the frontend lib.
Note: the Makefiles are still broken..

testrig.c
---------
modified to use rig_init/rig_open. Should work with an operating backend..


Conclusion:
----------
The good news is hamlib now compiles OK back again.
Next stage: the linking  ;-)

I'm sorry Frank, with the new API and frontend/backend, you'll have
to modify your ft847 code. BTW, do all the Yeasu rigs have the same
"CAT" protocol as Icoms do with "CI-V" ? In this case, may be it will
be easier for you to factorize some code.

-- 
Stephane Fillod					F4CFE

[Hamlib-developer] frontend API function reduction

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

Hi,

Well nothing compiles now (sob), so lets get the
general API and interwork API firmed up...

I am keen to get a good general (extensible) infrastructure in place.

Also, just a note,, CVS checkins that impact clean compiles
(and there will be many , I am sure) during later project stages
we should flag.

eg: If previous co compiles, and your or my next ci is known
to break this, we should think about tagging it in CVS.

Comments ??


Anyway Some  API thoughts ....

<snip>

/*
 *  
 * API Notes -- FS
 *
 */


I think it is more intuitive  to code things as follows...

backend must implement all opcodes (of course)
this may infer function names like thus (at least according
to yaesu docs not passing vfo as a parameter  - aaarrrgh).


eg 6 functions in backend ..

int cmd_set_freq_main_vfo_hz(RIG *rig,freq_t freq, rig_mode_t mode);
int cmd_set_freq_sat_rx_vfo_hz(RIG *rig,freq_t freq, rig_mode_t mode);
int cmd_set_freq_sat_tx_vfo_hz(RIG *rig,freq_t freq, rig_mode_t mode);

long int cmd_get_freq_mode_status_main_vfo(RIG *rig, unsigned char
*mode);
long int cmd_get_freq_mode_status_sat_rx_vfo(RIG *rig, unsigned char
*mode);
long int cmd_get_freq_mode_status_sat_tx_vfo(RIG *rig, unsigned char
*mode);

This creates a large function namespace, this is ok as there
shall be wrappers for them up front anyway. Also, bakend must test
all opcodes anyway.

However, frontend should have reduced namespace for function calls.

eg result, 2 functions up front ....

cmd_set_freq(RIG *rig,freq_t freq, rig_mode_t mode, vfo_t vfo )
long int cmd_get_freq_mode_status(RIG *rig, unsigned char *mode, vfo_t
vfo);

ie: 3 to 1 reduction, and an emphasis on what parameters
you are setting on the rig, driven more by the parameter
list, than extending function names.

so, lets create some enums

enum rig_vfo_e {
	RIG_VFO_MAIN = 0,
	RIG_VFO_RX,
	RIG_VFO_TX,
	RIG_VFO_SUB,

	/* etc */

}

typedef enum rig_vfo_e rig_vfo_t;

enum rig_rptr_shift_e {
	RIG_RPT_SHIFT_NONE = 0,
	RIG_RPT_SHIFT_MINUS,
	RIG_RPT_SHIFT_PLUS,
	/* etc */

}
<snip>

/Frank.. (yawn...)

-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com

[Hamlib-developer] Re: GUI for FT-847

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

Jim Jerzycke wrote:
> 
>     Hi, Frank.
>  Well.....I went and did it. I bought several books on programming on
> Tcl/Tk, and I'm amazed how easy it is. I've already started on a
> "Virtual Front Panel" for the FT-847, and I've got some functionality as
> far as turning knobs, recording the counts, and also button pushes. As
> soon as I get something presentable, I'll send you a sample!
> 73, Jim

Hi Jim,

Ok, glad to see soemone starting at the other end (GUI).

We are in a shakeup of the code at the moment, outlining
some generic frontend API for applications to use, so
latest CVS tree does not compile too well ;-(

However please feel free to play with the 1.0.3 release
to brush up on your coding  skills. Eventually we will
have wrapper functions for the frontend that will
support Java, Python, Tcl/Tk etc...

Eventually you will tie a widget or component event (eg button pressed)
to a function in our API, but try the libft847 as I know
you have a ft847.

try cmd_set_cat_on()  and cmd_set_cat_off() for fun.

Let us know how you go :-)

Cheers / Frank..



-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com

Re: [Hamlib-developer] cvs tree structure

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

 Frank Singleton wrote:
> 
> I was thinking of adding a new directory to the
> cvs tree eg: "generic" or "frontend" to     hold
> the generic front end code. I will place it at
> the same level as "common". ie: just under "hamlib".

	Ok, let's go for a "frontend" directory.
  You'll see on the CVS rep I started an implementation
  of the frontend/backend scheme. There's a backend
  example in ic706/ (still wip), and a simple test
  program using the frontend (testrig.c).

  The sources doesn't compile fine right now because
  of various forward references I can't fix now.
  Also, It'd be nice to define a nice generic interface
  for port management (serial, network, etc.)
  The code is not clean, and some field names are 
  not well chosen. Feel free to fix them.

  I have other questions/ideas in mind, but I'll keep
  them for tomorrow :-)

  have fun!

--
Stephane			F4CFE

[Hamlib-developer] cvs tree structure

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

Hi,

I was thinking of adding a new directory to the
cvs tree eg: "generic" or "frontend" to     hold
the generic front end code. I will place it at
the same level as "common". ie: just under "hamlib".


Comments ??

/Frank
-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com

Re: [Hamlib-developer] hamlib design?

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

Hi,


Welcome aboard, its no fun sending emails to myself ;-)

See comments below...

/Frank

Stephane Fillod wrote:
> 
> Okay, I started to code a generic rig API layer (kinf of frontend),
> based on Frank's code and ideas in the air. This will lead to a generic
> framework, making it even easier to develop rig backend seamlessly.
> However, I have a few questions:
> 
> 1) Should we assume any rig has no more than 2 VFOs ? Do you have examples?

**
should get from hardware capability structure -- see below
yaesu have at least 3 in some cases

**
Rig lib should return actual and symbolic info.

eg: no. of VFO's and their symbolic
meaning. ie: generic VFO-0 is Main or VFO-A or Sub VFO on rig xxx

eg: 3rd RX is sattelite RX ?


> 
> 2) Is a rig able to notify asynchronously the "host" any event (like a key has been depressed on the panel, main VFO freq changed, etc.) ? Examples?

**
Hmmm, rig callbacks, lets start an api for it anyway - event based, 

hmmm.. rig deamon  (server) send a IP packet to client for example 

I am not aware of yaesu doing it, but we should code for it.  


> 
> 3) Should cmd_set_freq_main_vfo_hz() set both freq and mode or should we split in two separate functions?

**
Some rigs may behave differently,  lets cover both !!


> 
> Here is a non-exhaustive list of things IMO to keep in mind when
> developping the hamlib library.
> 
> Plan:
> ----
> o develop the library as a shared/static library   * yes
> o portable (not only Linux, but UN*X, Win32 using cygwin,etc.  -> autoconf?) - * yes, gtk for GUI 
> o generic (any rig made, any model) - yes
> o wrappable (Java, perl module, Python module, etc.) - * yes java wrappers and some jni stuff ok
> o support serial ports, IrDA ports, USB ports, network ports (w/ a daemon) - * yes, and  client / server also
> o thread safe (reentrant) would be a must - * yep, posix threads here we come !!
> o support preference file (eg. /etc/hamlibrc, ~/.hamlibrc ) - * yes, read from /etc then home
> o written in C (C++ would have been more appropriate, but C is okay) - * i kind of like C and java :-)
> o support more than one rig per application (ie. generic code) - * ok
> o support more than one rig per serial port (ie. Icoms) - *ok
> o handle serial retransmission and timeouts would be nice - * yep, threaded read/writes are good
> o i18n support if applicable - ok
> o software compensation for the actual radio oscillator frequency errors
> o if avail., support events sent by the rig (eg. main freq has been changed,..) - event notifaction
> o maybe add some misc functions like PTT signaling (through serial/parallel..)
> o ...


****
A few more functions / addons

- software scanning (and huristics)
- s/w squelch
- real time spectral analysis and digital modes ( I have written some
working code for this)
  it does 40 frames / sec and no load, really cool to see time and
spectral info !!
  I have based it on generic data engine and plugins !! output also to
small gtk window.
  ie: DSP API


- doppler compensation in tracking mode
- ie: let real time signal analysis drive freq/modes/etc....
- software controlled hopping (poor mans GSM frequency hopping)
   also, must output hopping sequence to other rig to be useful

- networked rigs, provides realtime (global) spectral analysis to
  find (a common) quiet part of the band for a qso between 2 parties

- 

> 
> -> Christmas is in sight, time for whishlists!
> 
> Good inspiration:
> ----------------
> o SANE, with frontend/backend scheme, dynamic loading, autoconf, etc.
> o struct net_device (Linux kernel) for the void *priv idea
> o any rigctrl sources out there ?
> 
> Capabilities:   - ** this is definitely the challenge
> ------------
> We have to find a way to code capabilities in the hamlib in order
> to let the application know what this rig is able to do (before
> attempting to do it and crash :).
> I think some features can be coded using bit fields and masking.
> 
> Maybe we can distinguish between 3 states :
>   - Don't have this feature,
>   - Have it,
>   - Have it and can control (r/w) it remotly using the backend in hamlib
> 
> o freq ranges supported: rx/mode?, tx/modes/power ?  ->How to code this??
> o number of VFO, operations (set VFO separately, VFO A=B, switch, ..)
> o freq granularity (resolution), tuning steps
> o SCAN functions (start, stop, ..)

> o Split (cross band, duplex, ...)
> o RIT (+- KHz)
> o Memory scheme, what is stored in, quantity, call channels, scan edges
> o ATT, P.AMP, AGC, NB, TONE, TSQL, COMP, VOX, BK-IN, ...
> o Tuner control (internal, external, can control)
> o Meter indication: Squelch condition, S-meter level, ALC, SWR
> o Number of antennas (which band ?) and selection
> o available "set mode" items (ie. rig setup), and provide a way to modify them
> o DSP ? - one of my favorite areas, see comments above
> 
> any other ideas?


Many of above fall into a general "rig function capability structure"


Could be internal data structures populated inside each lib, 
and requested by the app.
Note generic <-> symbolic transforms


any app      generic  (front)       rig lib (backend)
-------      -------                -------

   ----------->
    get caps for 
     rig xxxx

                    get caps
                 -------------->    { internal data structure }


                  caps struct populated
                <--------------

apps knows rigs
capability. now
do something useful.


Also frontend can request 2 modes of commands

- acknowledged / unacknowledged mode

unack
------

eg:

set freq to xxx
--------------->
returns -1 if error
assume ok otherwise


OR

acked mode

set freq to xxx
--------------->
                 set freq
              ------------------------->
                get freq
              ------------------------->
                 freq retuerned
             <-------------------------

            compare requested 
            with actual 

  result
<--------------




I think we are forced to bite the bullet so to speak,
and start some rig capabilities stuff. I have only
scratched the surface with rig.h and rig_caps structure.


Also, each backend must provide a  rigxxx_read and rigxxx_write etc..
inside serial.c. 

frontend only sees read/write


Also, returned data must be uniform accross all rigs.


eg: TX power in dbm, not  0-15 units on yaesu and 0 - 23 units on icom


.... more to come I am sure...



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


Cheers / Frank..

-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com