hamlib-developer — hamlib developers forum

Re: [Hamlib-developer] CVS Updates via email

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

Frank Singleton wrote:

> 
> I have  added syncmail to CVSROOT and sent a request to
> have it activated.

Done

> 
> Should be up in 48 hrs hopefully.
> I need to configure a few things once the sourceforge
> lads have activated it for me.
> 
Done

> Then we will have some
> "very pretty" automatic cvs emails indeed :-)

Well its up and running!! I updated TODO as a test, and
the email automagically came as expected 
to ham...@li...

Note: Its more efficient if you have a daily
digest instead of 1 mail per update when you
receive the emails. This is set in your "email
preferences " on the hamlib site.

ie: "Set Digest Mode" 


Enjoy / Frank.. :)

-- 
Frank Singleton				VK3FCS

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

[Hamlib-developer] CVS Updates via email

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

> From: Stephane Fillod <f4...@fr...>
> To: ham...@li...
> Subject: [Hamlib-cvs-digest] automatic Hamlib-cvs-digest?
> 
> Frank,
> 
> Your commit reports are great, 

<blush>

>I'm wondering if I would have the time
> to do as well each time I commit. Anyway, I was more expecting this
> mailing list to *automatically* post the -m messages of the commits
> of the day.
> 
> Is it possible? Or is it something we have to add in a space cron tab
> with a script of ours?
> "Your asking the moon, please hold on...."
> 
> Cheers,
> 
> --
> Stephane                                        F4CFE

Hi hamlib crew,

Yeah this is a cross-post, but it affects us all ;-)

I have  added syncmail to CVSROOT and sent a request to
have it activated. 

Should be up in 48 hrs hopefully.
I need to configure a few things once the sourceforge
lads have activated it for me.

Then we will have some 
"very pretty" automatic cvs emails indeed :-)

Cheers..

-- 
Frank Singleton				VK3FCS

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

Re: [Hamlib-developer] API completion

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

Frank Singleton wrote:

> 
> PSk users prefers centre freq and BW, whereas removing lowend crud
> is a LPF for example.


Oops, removing lowend crud is using a HPF function :-)


-- 
Frank Singleton				VK3FCS

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

Re: [Hamlib-developer] API completion

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

Hi,

See my comments (***) below.

/Frank..


Stephane Fillod wrote:
> 
> Here is a (long) list of pending issues I try to work out, if we want to see
> the Hamlib API complete one day.
> Let me know if you agree or disagree on the ideas, on the implementation,
> etc. Part of it is already coded. However it's not written in stone though.
> If you think the API names are not well chosen, you might be right!
> Give a better name in that case, english is not my mother tongue!
> 
> Duplex and split operation:
> ---------------------------
> 
> Until now, we have *duplex* support with the following enum:
> 
> enum rptr_shift_e {
>         RIG_RPT_SHIFT_NONE = 0,
>         RIG_RPT_SHIFT_MINUS,
>         RIG_RPT_SHIFT_PLUS
>         }
> 
> Adding the following two capabilities, we can set the duplex offset,
> thus the duplex support is complete.
> 
>   int (*set_rpt_offs)(RIG *rig, freq_t offs); /* set duplex offset freq */
>   int (*get_rpt_offs)(RIG *rig, freq_t *offs); /* get duplex offset freq */
> 
> Do you see anything else needed?
> 

***

Reverse to listen for example repeater input frequencies.
Is this just a toggle of the current (ie: remember state) RIG_RPT_SHIFT
?
If so, then is this backend "instance data"

> Well, now let's talk about *split* support.
> On most radios (all ?), the split mode is implemented using 2 VFOs.
> ie. VFO A holds the receive frequency while VFO B holds the transmit freq.
> 
> enum split_e {
>                 RIG_SPLIT_OFF = 0,
>                 RIG_SPLIT_ON
>                 };
> int (*set_split_freq)(RIG *rig, freq_t rx_freq, freq_t tx_freq);
> int (*get_split_freq)(RIG *rig, freq_t *rx_freq, freq_t *tx_freq);
> int (*set_split)(RIG *rig, split_t split);
> int (*get_split)(RIG *rig, split_t *split);
> 
> set_split_freq would set VFO A and VFO B accordingly, or whatever else
> the rig is using. Breaking set_split_freq down in set_split_rxfreq and
> set_split_txfreq would have been better, but hey, being smart
> has a cost!
> Concerning set_split(), we could have reuse set_rpt_shift(), but the
> name could be misleading.
> 
> What do you think of this proposal? Can I check it in?
> 

> Clarification on enum vfo_e
> ---------------------------

> So my proposal would be:
> 
> {   RIG_VFO_MAIN = 0,
>     RIG_VFO_SUB,
>     RIG_VFO_SAT,
>     RIG_VFO_A = RIG_VFO_MAIN,
>     RIG_VFO_B = RIG_VFO_SUB,
>     RIG_VFO_C = RIG_VFO_SAT
> }
> 
> Is it OK with you?


***

Really we are simply aliasing "n" VFO's to something tangibile
for humans to understand. This is OK with me.

> 
> rmode_t
> -------
> Luc is right, we have to rework this type. WE should remove all the wide
> and narrow combinations, in order to keep it simple.
> Then, we can add some rig_set_filter() that would support, not only
> "builtin" narrow and wide filter, but also added filters (ie. can have
> more that one narrow filter installed).
> 


***
Yes, a rationalising of modes is good.

ie: mode and bandwidth are different settings on our virtual radio model
(aka API)

also, bandwidth applies to RF frontend, IF, AF and offrig DSP bandwidth.
eg: IF filtering, AF filtering, Off rig filtering + squelch (DSP on
computer)


ie: location(s) and response(s)


location:
---------
enum filter_path_e { 
	RIG_BW_RF = 0,
  	RIG_BW_IF,
  	RIG_BW_AF,
  	RIG_BW_RF_EXTERNAL,
	RIG_BW_IF_EXTERNAL,
	RIG_BW_AF_EXTERNAL,
}

typedef filter_path_e filter_path_t



response
---------
Also, bandwidth may be too restrictive

should not we model it as 
types like bandpass, band reject  high pass, low pass, etc

enum filter_resp { 
  	RIG_FILTER_BPASS,
  	RIG_FILTER_BREJECT,
  	RIG_FILTER_HPF,
  	RIG_FILTER_LPF,
   ..etc
}


or 

enum filter_width { 
  	RIG_FILTER_NARROW,
  	RIG_FILTER_NORMAL,
  	RIG_FILTER_WIDE
   ..etc
}

typedef filter_width_e filter_width_t

These above generally equate to buttons on the rig.

However we may need a general filter decription for that done
at IF and AF etc.. especially when DSP is involved.

I am not (yet) saying 15 pole chebyshev with such and such
charactersitics.  It would be nice to pass a bode plot
to the rig (one day !!). But we do need to set cutoff frequencies
etc. eg: 3db cutoff for BPF, HPF,LPF, etc.. if the rig can handle
it.



An API suggestion would be 

rig_set_filter(RIG *rig, filter_path_t fp, freq_resp_t fres)


Note also thet BPF can be modelled as HPF/LPF combo 
or as BPF with center freq and BW etc..

PSk users prefers centre freq and BW, whereas removing lowend crud
is a LPF for example.

hmmm... geeting late so I move on :-)


> Misc functions
> --------------
>   int (*set_ant)(RIG *rig, int ant); /* set antenna number */
>   int (*get_ant)(RIG *rig, int *ant); /* get antenna */
> 
>   int (*set_att)(RIG *rig, int att); /* set attenuator, in db */
>   int (*get_att)(RIG *rig, int *att); /* set attenuator, in db */
> 
> and preamp as well? any proposal?
> We'll need to support filters too. Can you see a generic approach on this?
> 
> Memory:
> ------
> 
>   int rig_set_mem(RIG *rig, int ch);
>   int rig_get_mem(RIG *rig, int *ch);
>   int rig_mem_clear(RIG *rig);
>   int rig_mem_to_vfo(RIG *rig);
>   int rig_vfo_to_mem(RIG *rig);  /* memory write */
> 
>   We need also VFO A=B, Switch VFO A and B, set to VFO mode, set to MEM mode
> 
>   int rig_vfo_copy(RIG *rig);
>   int rig_vfo_xchg(RIG *rig);
>   int rig_vfo_mode(RIG *rig);
>   int rig_mem_mode(RIG *rig);
> 
> OR
> 
>   int rig_vfo_mem(RIG *rig, vfo_mem_t op);
> 
> where op can have the following values:
>         * RIG_VM_VFOAB
>         * RIG_VM_VFO_XCHG
>         * RIG_VM_VFO_MODE
>         * RIG_VM_MEM_MODE
>         etc.
> we could even have:
>         * RIG_VM_MCL
>         * RIG_VM_MEM2VFO
>         * RIG_VM_VFO2MEM
> 
> This would cut down the number of functions in the API.
> What do you think ? What about the names?
> 



> about freq range:
> ----------------
>         Just something to keep in mind. Some rigs, with the same model number,
>         are manufactured for ITU region 1 and ITU region 2.
>         So what's the matter? Well the frequency ranges vary from one region
>         to another one. This will be a great handicap for the capabilities.
>         Keep thinking of it, how we could solve this problem...
>         and let me know!
> 
> Scan functions:
> --------------
>         rig_scan(my_rig, RIG_SCAN_START);
>         rig_scan(my_rig, RIG_SCAN_STOP);
> 
> Is that enough? Do we need more control?




I see a couple of things here.

1. Rig onboard scanning capability
2. Backend soft scanning, and asynchronous handling
   of "stop scanning" requests etc..
3. Frontend soft scanning requests.


> 
> About sql:
> ---------
> We need 3 functions:
> 
>         set squelch level:  0.0 .. 1.0
>         get squelch level-> 0.0 .. 1.0
>         read squelch status: open/closed


Offrig squelch , tone detection (DSP on PC) ??

> 
> misc:
> ----
> A function to get firmware string, ITU region, trx ID, etc.
> someting that can be displayed in an 'About ...' GUI popup window.
> 
> level settings:
> ---------------


> 
> For all the ON/OFF settings, what do you think of using the rig_set_func()
> call that would take care of it? And what about the rest? One set/get
> function per paramter or something more generic like this:
> 
>         rig_set_setting(RIG *rig, setting_t setting, int value);
>         rig_get_setting(RIG *rig, setting_t setting, int *value);
> 

***

This is prefereable, otherwise my 300 button rig is going to create
a lots of API functions.

> Needless to say, that could be a mess if the setting is not an integer
> but a float or a string, etc.
> I'm waiting for your thoughts on this.


***
It seems to me that the API models a virtual Radio with particular
capability ranges
for each setting.

I think we should standardise up front the acceptable range settings for
the virtual radio and let the backend take care of necessary scaling.
I expect that most level settings can be implemented via "int" quite
acceptably. 

> 
> Let's complete the API (or at least close to it) so we can release it,
> after we've documented it....
> 
> Thanks for reading :-)
> --
> Stephane                                                        F4CFE
> _______________________________________________
> 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

[Hamlib-developer] API completion

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

Here is a (long) list of pending issues I try to work out, if we want to see
the Hamlib API complete one day.
Let me know if you agree or disagree on the ideas, on the implementation,
etc. Part of it is already coded. However it's not written in stone though.
If you think the API names are not well chosen, you might be right!
Give a better name in that case, english is not my mother tongue!

Duplex and split operation:
---------------------------

Until now, we have *duplex* support with the following enum:

enum rptr_shift_e {
        RIG_RPT_SHIFT_NONE = 0,
        RIG_RPT_SHIFT_MINUS,
        RIG_RPT_SHIFT_PLUS
	}

Adding the following two capabilities, we can set the duplex offset,
thus the duplex support is complete.

  int (*set_rpt_offs)(RIG *rig, freq_t offs); /* set duplex offset freq */
  int (*get_rpt_offs)(RIG *rig, freq_t *offs); /* get duplex offset freq */

Do you see anything else needed?


Well, now let's talk about *split* support.
On most radios (all ?), the split mode is implemented using 2 VFOs.
ie. VFO A holds the receive frequency while VFO B holds the transmit freq.

enum split_e {
		RIG_SPLIT_OFF = 0,
		RIG_SPLIT_ON
		};
int (*set_split_freq)(RIG *rig, freq_t rx_freq, freq_t tx_freq);
int (*get_split_freq)(RIG *rig, freq_t *rx_freq, freq_t *tx_freq);
int (*set_split)(RIG *rig, split_t split);
int (*get_split)(RIG *rig, split_t *split);

set_split_freq would set VFO A and VFO B accordingly, or whatever else
the rig is using. Breaking set_split_freq down in set_split_rxfreq and
set_split_txfreq would have been better, but hey, being smart
has a cost!
Concerning set_split(), we could have reuse set_rpt_shift(), but the
name could be misleading.

What do you think of this proposal? Can I check it in?


Clarification on enum vfo_e
---------------------------

Ok, the enum vfo_e is kind of over crowded, I'm not sure
of what is what:

    RIG_VFO_MAIN = 0,
    RIG_VFO_RX,
    RIG_VFO_TX,
    RIG_VFO_SUB,
    RIG_VFO_SAT_RX,
    RIG_VFO_SAT_TX,
    RIG_VFO_A,
    RIG_VFO_B,
    RIG_VFO_C

RIG_VFO_A,RIG_VFO_B and RIG_VFO_C are fine :)
Is RIG_VFO_MAIN an alias for RIG_VFO_A and RIG_VFO_SUB for RIG_VFO_B?
Allright, now, what I don't understand is how we can have (from an
operating point of vue of course) a VFO for RX and another one for TX.
To my mind, they would be the same VFO, but if you want RX freq different
than TX freq, then you activate split mode.
So my proposal would be:

{   RIG_VFO_MAIN = 0,
    RIG_VFO_SUB,
    RIG_VFO_SAT,
    RIG_VFO_A = RIG_VFO_MAIN,
    RIG_VFO_B = RIG_VFO_SUB,
    RIG_VFO_C = RIG_VFO_SAT
}

Is it OK with you?

rmode_t
-------
Luc is right, we have to rework this type. WE should remove all the wide
and narrow combinations, in order to keep it simple.
Then, we can add some rig_set_filter() that would support, not only
"builtin" narrow and wide filter, but also added filters (ie. can have
more that one narrow filter installed).
 
Misc functions
--------------
  int (*set_ant)(RIG *rig, int ant); /* set antenna number */
  int (*get_ant)(RIG *rig, int *ant); /* get antenna */

  int (*set_att)(RIG *rig, int att); /* set attenuator, in db */
  int (*get_att)(RIG *rig, int *att); /* set attenuator, in db */

and preamp as well? any proposal?
We'll need to support filters too. Can you see a generic approach on this?


Memory:
------

  int rig_set_mem(RIG *rig, int ch);
  int rig_get_mem(RIG *rig, int *ch);
  int rig_mem_clear(RIG *rig);
  int rig_mem_to_vfo(RIG *rig);
  int rig_vfo_to_mem(RIG *rig);  /* memory write */

  We need also VFO A=B, Switch VFO A and B, set to VFO mode, set to MEM mode

  int rig_vfo_copy(RIG *rig);
  int rig_vfo_xchg(RIG *rig);
  int rig_vfo_mode(RIG *rig);
  int rig_mem_mode(RIG *rig);

OR

  int rig_vfo_mem(RIG *rig, vfo_mem_t op);

where op can have the following values:
	* RIG_VM_VFOAB
	* RIG_VM_VFO_XCHG
	* RIG_VM_VFO_MODE
	* RIG_VM_MEM_MODE
	etc.
we could even have:
	* RIG_VM_MCL
	* RIG_VM_MEM2VFO
	* RIG_VM_VFO2MEM

This would cut down the number of functions in the API.
What do you think ? What about the names?



about freq range:
----------------
	Just something to keep in mind. Some rigs, with the same model number,
	are manufactured for ITU region 1 and ITU region 2.
	So what's the matter? Well the frequency ranges vary from one region
	to another one. This will be a great handicap for the capabilities.
	Keep thinking of it, how we could solve this problem...
	and let me know!

Scan functions:
--------------
	rig_scan(my_rig, RIG_SCAN_START);
	rig_scan(my_rig, RIG_SCAN_STOP);

Is that enough? Do we need more control?


About sql:
---------
We need 3 functions:

	set squelch level:  0.0 .. 1.0
	get squelch level-> 0.0 .. 1.0
	read squelch status: open/closed

misc:
----
A function to get firmware string, ITU region, trx ID, etc.
someting that can be displayed in an 'About ...' GUI popup window.


level settings:
---------------

Ah! The big chunk. Idealy, we would have to be able to set/adjust
all the following settings:

   AF level setting				rig_[sg]et_volume
   RF level setting
   SQL level setting			rig_[sg]et_squelch
   IF shift setting
   APF level setting
   NR level setting
   Twin PBT setting (inside)
   Twin PBT setting (outside)
   CW pitch setting
   sets RF power				rig_[sg]et_power
   sets MIC Gain
   sets Key Speed
   sets Notch Freq.
   sets Compressor level
   sets BKin Delay
   sets Balance (Dual Watch)
   Preamp Setting
   AGC setting: off, super-fast, fast, slow
   NB ON/OFF
   APF ON/OFF
   Set (optional) noise reduction off/on
   Set (optional) auto notch off/on
   Repeater tone setting
   TSQL setting
   Monitor setting
   VOX setting
   BKin setting
   Manual Notch
   RTTY Filter Notch
   Signal centered


For all the ON/OFF settings, what do you think of using the rig_set_func()
call that would take care of it? And what about the rest? One set/get
function per paramter or something more generic like this:

	rig_set_setting(RIG *rig, setting_t setting, int value);
	rig_get_setting(RIG *rig, setting_t setting, int *value);

Needless to say, that could be a mess if the setting is not an integer
but a float or a string, etc.
I'm waiting for your thoughts on this.


Let's complete the API (or at least close to it) so we can release it,
after we've documented it....

Thanks for reading :-)
-- 
Stephane							F4CFE

Re: [Hamlib-developer] Proposal

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

Luc Langehegermann wrote:
> 
> Hi Folks,
> 
> On Mon, 09 Oct 2000, Stephane Fillod wrote:
> >   Well, I've already asked myself if glib would be of any
> >   help for Hamlib. In some cases yes, in other cases not.
> >   If you ask me for a answer right now, I would say
> >   no to glib. I know it would make things easier for us,
> >   but do we need all these gizmos to have a real lib?
> >   I mean It's so good to have something selfcontained,
> >   that does not require you to install xx .DLL^H^H^H^H
> >   shared libraries to run.
> 
> I fully agree with you, Stephane
> 
> >   REM: I do recognize glib has plenty of cool stuff, and is very
> >       portable.
> >
> >   Ok, that's my answer today. It could change, especially if
> >   we need more and more of this kind of reusable code.
> >   Actually, this is a point where I'd love to see other
> >   developpers (other than you and me) debate upon...

Hmm, have to agree to disagree on glib for the moment :-(


> >
> > So what do you think of what we got? Can we make a hamlib-1.1.0
> > release and call for help? We DO need help to finalize the API,
> > choose the function names and semantics, etc.
> > Potential Hamlib users are already knocking at the door!
> >
> > Cheers,


Yep lets do it !! There is only 24 hours in a day, and I am running
at 110 % already <:)
Lets make a cvs tagged relase (1.1.0) and pop it in the "Latest File
Releases"
area first.

Some things for the announcement to *.ham.* etc are:

1. Nice project summary/aims.
2. Outline design architecture
3. sample code snippet ( a few lines)
4. refs to hamlib links, and discussion groups.
5. Current project status (early :-))
6. Platform operability.
7. DEVELOPERS WANTED, LOTS OF WORK (LIBS) TODO

etc..


Comments / Frank..

-- 
Frank Singleton				VK3FCS

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

Re: [Hamlib-developer] Proposal

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

Hi Folks,

On Mon, 09 Oct 2000, Stephane Fillod wrote:
>   Well, I've already asked myself if glib would be of any
>   help for Hamlib. In some cases yes, in other cases not.
>   If you ask me for a answer right now, I would say
>   no to glib. I know it would make things easier for us,
>   but do we need all these gizmos to have a real lib?
>   I mean It's so good to have something selfcontained,
>   that does not require you to install xx .DLL^H^H^H^H
>   shared libraries to run.

I fully agree with you, Stephane

>   REM: I do recognize glib has plenty of cool stuff, and is very
> 	portable.
>
>   Ok, that's my answer today. It could change, especially if
>   we need more and more of this kind of reusable code.
>   Actually, this is a point where I'd love to see other
>   developpers (other than you and me) debate upon...
>
>
> Fresh news:
> ----------
> * added dynamic backend loading (still need the LD_LIBRARY_PATH though)
> * a new listcaps to list all known caps
> * include/rig.h moved to include/hamlib/rig.h
> * file buffered access, this works in parallel with unbuffered.
> 	It lets you do read 1 byte at a time, at no IO penalty.
> * added transceive mode, ie. asynchronous rig notificication handling
> 	It works quite nice with SIGIO and sigaction. see testtrn
> * More icom stuff
>
> For details, please see cvs-digest
>
> So what do you think of what we got? Can we make a hamlib-1.1.0
> release and call for help? We DO need help to finalize the API,
> choose the function names and semantics, etc.
> Potential Hamlib users are already knocking at the door!
>
> Cheers,

I just took a look at the rig.h file, and was a bit suprised to read how you 
use the mode. Is it not easier use an rig_mode_t and an rig_bandwidth_t? At 
least for the USB/LSB modes? I also thing that RTTY is not really clear 
enough... Some rigs make afsk, others afsk or fsk... Ans how to know if they 
do the acually USB or LSB? (Especially if I think on my psk31 project thats 
important to know)


-- 
Greetings, Luc

Re: [Hamlib-developer] Proposal

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

On Sun, Oct 08, 2000 at 04:08:56PM -0500, Frank Singleton wrote:
> 
> I have been writing some dissectors for a cool opensource
> project called "ethereal". see http://www.ethereal.com/
> 
	I'll give it a look tomorrow.

> Anyway, we use glib and gtk, and that goes a long way
> to helping support multiple platforms. Ethereal
> compiles and runs on Unix (+flavors), Linux, window$ etc..
> 
  Well, I've already asked myself if glib would be of any
  help for Hamlib. In some cases yes, in other cases not.
  If you ask me for a answer right now, I would say
  no to glib. I know it would make things easier for us,
  but do we need all these gizmos to have a real lib?
  I mean It's so good to have something selfcontained,
  that does not require you to install xx .DLL^H^H^H^H
  shared libraries to run.
  REM: I do recognize glib has plenty of cool stuff, and is very
	portable.

  Ok, that's my answer today. It could change, especially if
  we need more and more of this kind of reusable code.
  Actually, this is a point where I'd love to see other
  developpers (other than you and me) debate upon...


Fresh news:
----------
* added dynamic backend loading (still need the LD_LIBRARY_PATH though)
* a new listcaps to list all known caps
* include/rig.h moved to include/hamlib/rig.h
* file buffered access, this works in parallel with unbuffered.
	It lets you do read 1 byte at a time, at no IO penalty.
* added transceive mode, ie. asynchronous rig notificication handling
	It works quite nice with SIGIO and sigaction. see testtrn
* More icom stuff

For details, please see cvs-digest

So what do you think of what we got? Can we make a hamlib-1.1.0
release and call for help? We DO need help to finalize the API,
choose the function names and semantics, etc.
Potential Hamlib users are already knocking at the door!

Cheers,
-- 
Stephane Fillod				F4CFE

[Hamlib-developer] Proposal

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

Hi,

I have been writing some dissectors for a cool opensource
project called "ethereal". see http://www.ethereal.com/

Anyway, we use glib and gtk, and that goes a long way
to helping support multiple platforms. Ethereal
compiles and runs on Unix (+flavors), Linux, window$ etc..

I have been thinking about the long term project
goals for hamlib, and I think that ease of
development accross platforms is probably one
of the most important goals.

So, I would like to propose that we use glib
also in our project. It provides a variety
of nice (data types (eg: guint8), functions like hashes, 
mem allocation , trees, etc and is supported (like gtk)
across many platforms.


eg: guint8 is an unsigned 8 bit int.
eg: guint16 is an unsigned 16 bit int.
etc..

It provides a nice abstraction from the basic C types, a plus
for portability.

See http://developer.gnome.org/doc/API/glib/index.html
for some examples.

Also http://gtk.org/ for some gtk stuff.

I think with hamlib/glib/gtk, we could do some seriously
cool stuff !

It would not take much effort now to "glibify" the codebase
we have, before it gets too large.

Comments ??

/ Frank

-- 
Frank Singleton				VK3FCS

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

Re: [Hamlib-developer] FT-920

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

Luc Langehegermann wrote:
> 

> 
> No Problem... Wat exactly do you need? Or can I simply scan the description
> and Mail it to the list?
>

I sent you a private mail outlining what I need. Please take
a look at that. ;-)

> 
> I find your project really interesting. But at a first time, I need 'only' a
> way to provide transceiver control in my PSK31 Application. But maybe if I
> find the time I will begin in writing an cool KDE2 frontend for your libs :)

That would be most excellent, nothing like a screenshot or two of a cool
GUI to spice up a project :-)

> 
> The problem I have is, that I cannot access the cvs directly from here... It
> there a way to get snapshots over HTTP?
>

You should be able to get nightly cvs tarballs from

http://cvs.sourceforge.net/cvstarballs/hamlib-cvsroot.tar.gz

Let me know how you go.

/Frank

-- 
Frank Singleton				VK3FCS

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

[Hamlib-developer] FT-920

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

Hi Folks,

>   Hi,
>   Welcome to the hamlib site. Initially I started this
>   site with 2 shared libs (now potential backends) for the FT747
>   and FT847, and they worked ok. I was thinking about
>   some generic frontend when Stephane joined the project
>   and helped implement the frontend code and generic API
>   structure. I think this is definitely a good thing :-)
>   Just to follow up with your yaesu question, I am updating
>   backends for the FT747 and FT847. I would be most pleased
>   if we could see what commonality there is in the command
>   set for the FT-920 and the others (eg: FT847).
>   This could help a to reduce a lot of common code.
>   eg: we could have eg: yaesu.[ch] etc that contain common
>   stuff. Luc, is it possible to get a copy of the command
>   set details, so we can check this

No Problem... Wat exactly do you need? Or can I simply scan the description 
and Mail it to the list? 

>   examples are: 5 byte command set , this is true for FT747
>   and FT847.
>   Once again welcome, and let me us know if you want to
>   join the crew. We have LOTS to do !

I find your project really interesting. But at a first time, I need 'only' a 
way to provide transceiver control in my PSK31 Application. But maybe if I 
find the time I will begin in writing an cool KDE2 frontend for your libs :) 

The problem I have is, that I cannot access the cvs directly from here... It 
there a way to get snapshots over HTTP?

>   Cheers / Frank
>   vk3fcs/km5ws

-- 
Greetings, Luc

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

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

Stephane Fillod wrote:

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

Ok,

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


Useful info,
Lets put this in in the INSTALL or README file..


> 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 :-)

go hamlib !!

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

Done, see 
                        
ham...@li...

SHould be visible soon...

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

Yup, sounds good to me.

I am in the middle of building a house at the moment, and plan to move
in
in 4 weeks, so I am VERY BUSY !!!!
But I will try and have at least weekly visit and updates ..

Cheers / Frank..

-- 
Frank Singleton				VK3FCS

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

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