hamlib-developer

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

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

[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

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

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

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

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

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

what do you think? any drawback in mind?

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

Greetings,
-- 
Stephane

Re: [Hamlib-developer] Proposal

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

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

I'll take a look at it.

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

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

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

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

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

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

> Greetings,

-- 
Greetings, Luc, LX2GT