hamlib-developer

[Hamlib-developer] API outstanding issues

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

Hi all!

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

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

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


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

	rig_set_ctcss
	rig_set_dcs

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

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

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

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

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

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

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


Cheers,

-- 
Stephane

Re: [Hamlib-developer] 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] 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:
> 
> 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...>]

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

[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