Thread: [Hamlib-developer] CQ CQ hamlib-developers..

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi there!

I've sent couple of proposals for Hamlib, but received no sign of life.
Is there anyone left on this list or just running out of time?

-- 
73! de Stephane

On Wed, Mar 28, 2001 at 10:39:32PM +0200, Stephane Fillod wrote:
> 
> Hi there!
> 
> I've sent couple of proposals for Hamlib, but received no sign of life.
> Is there anyone left on this list or just running out of time?

Hi Stephane.

I'm in the middle of moving and am working at a new location.  Even
though I have some time here and there, I haven't managed to update the
web pages even though I completed the first draft of the manual for the
ALPHA release back in December.  I hope to get back to that once things
settle down.

Keep up the good work and I have tried to steer interested parties to
the project.

73, de Nate >>

-- 
 Wireless | Amateur Radio Station N0NB          | "None can love freedom
 Internet | n0...@ne...               | heartily, but good
 Location | Wichita, Kansas USA EM17hs          | men; the rest love not
   Wichita area exams; ham radio; Linux info @  | freedom, but license."
             http://www.qsl.net/n0nb/           | -- John Milton

Hi Nate,

On Wed, Mar 28, 2001, Nate Bargmann wrote:
> 
> I'm in the middle of moving and am working at a new location.  Even

Hamlib's members all know moving isn't an easy task, and I wish you'll
be doing fine, especially with those biggo aerials :)

Acutualy, your ALPHA version is great. Why don't we make it available
on sourceforge? or at least add a pointer to it?
I know I have some documentation to write, for example about the API,
data structures, etc.. What format would you recommand? which sgml tool set
are you using?

Good luck for your moving, and don't worry, 
there's no hurry for Hamlib!

-- 
Stephane / F4CFE

Stephane Fillod wrote:
> 
> Hi there!
> 
> I've sent couple of proposals for Hamlib, but received no sign of life.
> Is there anyone left on this list or just running out of time?

Hi Hamlib,

I hate excuses, but, I am in the middle of a humungous project at work,
for at least the next 2 months or so.

I have CORBA running out of my ears :O

Does my yaesu stuff still compile  ok ?

-- 
Cheers / Frank 

73's de vk3fcs & km5ws

Frank Singleton wrote:
> 
> I hate excuses, but, I am in the middle of a humungous project at work,
> for at least the next 2 months or so.
> 
  we all know what it is.

> I have CORBA running out of my ears :O
> 
  Hopefully you will tame the beast :)

  I envision distributed hamlib applications, interacting 
  through CORBA... 
  no, just kidding (would be cool though with Bonobo :-)

> Does my yaesu stuff still compile  ok ?
> 
yep, every time I modify the front-end, I try to keep the CVS rep
in a compilable state (this is all about total quality ethic, hi).
Even if backends may not have implementation of the newest features, they
still support the simple commands (set_freq, set_mode, etc.)

BTW, I have a batch of frontend updates I've proposed recently on the list.
Do you think they're OK, and I can go ahead modifying backend ends
accordingly and commiting in?
A new version of Hamlib definitely needs to be released soon too!

Cheers,
-- 
Stephane

Stephane Fillod wrote:
> 
> Frank Singleton wrote:
> >
> > I hate excuses, but, I am in the middle of a humungous project at work,
> > for at least the next 2 months or so.
> >
>   we all know what it is.
> 
> > I have CORBA running out of my ears :O
> >
>   Hopefully you will tame the beast :)
> 
>   I envision distributed hamlib applications, interacting
>   through CORBA...
>   no, just kidding (would be cool though with Bonobo :-)

> 
> > Does my yaesu stuff still compile  ok ?

Actually, I ran it against my FT747 anf FT847 and it all looked
ok .

> >
> yep, every time I modify the front-end, I try to keep the CVS rep
> in a compilable state (this is all about total quality ethic, hi).
> Even if backends may not have implementation of the newest features, they
> still support the simple commands (set_freq, set_mode, etc.)
> 
> BTW, I have a batch of frontend updates I've proposed recently on the list.
> Do you think they're OK, and I can go ahead modifying backend ends
> accordingly and commiting in?
> A new version of Hamlib definitely needs to be released soon too!

Yes I agree. But I have an intersting idea .............

Here we are populating an ever growing rig_caps struct, with some
cababilities and function pointers to our API.

Why dont we modify this a little?

Create a list (enum?) of capabilities funtion codes,
and then when we populate our rigg_caps, it actually
consists of a list tuples, appropriately terminated.

The tuple is a function dode, and matching data (or fn pointer).

enum function_capability {
  FC_INIT,
  FC_CLEANUP,
  ..
  FC_RX_LIST,
   ..

  FC_TX_LIST,

  ..

   etc..

}

Then ...............

eg:

 Instead of 

<snip>

  ft747_init, 
  ft747_cleanup, 
  ft747_open,				/* port opened */
  ft747_close,				/* port closed */
  NULL,				/* probe not supported yet */

  ft747_set_freq,		/* set freq */
  ft747_get_freq,		/* get freq */
  ft747_set_mode,		/* set mode */
  ft747_get_mode,		/* get mode */
  ft747_set_vfo,		/* set vfo */
  ft747_get_vfo,		/* get vfo */
  ft747_set_ptt,		/* set ptt */
  ft747_get_ptt,		/* get ptt */

  NULL,				/* add later */
  NULL,				/* add later */

<snip>

we have

{ {FC_INIT, ft747_init}, 
  {FC_SET_PTT, ft747_get_ptt,},
  {FC_CLEANUP, ft747_cleanup,}

 .... etc

  {FC_RX_LIST, { { {1500000,1999900,FT747_OTHER_TX_MODES,5000,100000},
/* 100W class */ 
    {1500000,1999900,FT747_AM_TX_MODES,2000,25000},	/* 25W class */

    <snip>

    {24500000,24999900,FT747_OTHER_TX_MODES,5000,100000},
    {24500000,24999900,FT747_AM_TX_MODES,2000,25000},

    {28000000,29999900,FT747_OTHER_TX_MODES,5000,100000},
    {28000000,29999900,FT747_AM_TX_MODES,2000,25000},

    RIG_FRNG_END, }}

  }

  { FC_WHATEVER, .. }

   etc..

}

This  way, I dont go blind trying to fill the correct line in the
rig_caps struct
for a certain function pointer,or freq range list, and I dont care what
order they are listed.

This way, I dont have to jump over "NULL" entries etc..

Just some minor tweaks for the backends, and a little for the front
end. :)

Coments ??

Cheers / Frank..

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

-- 
Cheers / Frank 

73's de vk3fcs & km5ws

On Sun, Apr 22, 2001, Frank Singleton wrote:
> > 
> > > Does my yaesu stuff still compile  ok ?
> 
> Actually, I ran it against my FT747 anf FT847 and it all looked
> ok .

Did you ran the last commited version (sunday)?
It got the new VFO id design (that can be OR'ed), and pbwidth_t is now
the filter width in Hz passed to set_mode et al. Grep RIG_PASSBAND_OLDTIME
and FIXME in the code to see where to update.

> 
> Yes I agree. But I have an intersting idea .............
> 
  Sounds like there's some CORBA or RPC in the air....

[snip]
> This  way, I dont go blind trying to fill the correct line in the
> rig_caps struct
> for a certain function pointer,or freq range list, and I dont care what
> order they are listed.

hmm, but it makes code harder to write (type castings, etc.), slowing
down your app because of lookups, loosing type checking, etc.

> This way, I dont have to jump over "NULL" entries etc..

If this is all what's worring you, just follow the winradio/wr1500.c
example. It makes the code a lot easier to read!

So what else do we need for an 1.1.1 release?
Add a couple of set_split_mode and get_split_mode, rig_send_cw,
remove chan_qty, dtmf_digits, ..
Any idea?

-- 
Stephane

Stephane Fillod wrote:
> 
> On Sun, Apr 22, 2001, Frank Singleton wrote:
> > >
> > > > Does my yaesu stuff still compile  ok ?
> >
> > Actually, I ran it against my FT747 anf FT847 and it all looked
> > ok .
> 
> Did you ran the last commited version (sunday)?

Hmm  I used the latest CVS prior to sending this original email
response.

> It got the new VFO id design (that can be OR'ed), and pbwidth_t is now
> the filter width in Hz passed to set_mode et al. Grep RIG_PASSBAND_OLDTIME
> and FIXME in the code to see where to update.
> 
> >
> > Yes I agree. But I have an intersting idea .............
> >
>   Sounds like there's some CORBA or RPC in the air....
> 

I have been thinking about that also ....... :-)
Stay tuned !

> [snip]
> > This  way, I dont go blind trying to fill the correct line in the
> > rig_caps struct
> > for a certain function pointer,or freq range list, and I dont care what
> > order they are listed.
> 
> hmm, but it makes code harder to write (type castings, etc.), slowing
> down your app because of lookups, loosing type checking, etc.
> 

lookups probably not too bad (cache hits ) but the type checking
is definitely good to keep , I agree..

> > This way, I dont have to jump over "NULL" entries etc..
> 
> If this is all what's worring you, just follow the winradio/wr1500.c
> example. It makes the code a lot easier to read!
> 

> So what else do we need for an 1.1.1 release?
> Add a couple of set_split_mode and get_split_mode, rig_send_cw,
> remove chan_qty, dtmf_digits, ..
> Any idea?

Let me check it this weekend ..

/Frank..

-- 
Cheers / Frank 

73's de vk3fcs & km5ws

Thread: [Hamlib-developer] CQ CQ hamlib-developers..

Library to control radio transceivers and receivers

hamlib-developer