hamlib-developer — hamlib developers forum

Re: [Hamlib-developer] ./configure; make

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

On Sat, Jun 22, 2002, Dale E. Edmons wrote:
> I believe I found the problem I had with ./configure; make.  Several
> years
> ago I started placing the following make alias in my /etc/profile:
>         alias make='make -j3'
> There hasn't been any problems before that I know of and compiles
> have slowed since I removed it.  Now, however, hamlib fully compiles
> even with perl.
> 
> Has anybody else used 'make -j 3' or similar with success?

AFAIK, the -j is only useful on SMP systems. It determines the number of
make process to be run in parallel. I guess automake/libtool is not 100% 
against that kind of build, espcially regarding dependencies..

73's
Stephane

Re: [Hamlib-developer] rpcrig (howto)

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

On Sun, Jun 16, 2002, Dale E. Edmons wrote:
> Just a quick question.  My laptop is connected to my rig and is slower
> than my main computer.  The two computers are connected via
> ethernet and allows me to do anything on one the other won't do.
> 
> I believe rpcrig is for control via this type of link.  It'd be
> convienient
> (and really cool) if I could run rigctl remotely via rpcrig.  I'm sure

If it can be cool, it's a job for ........ Hamlib! hi.


> that the development status is not what it wants to be but I'd give
> it a go if someone would give the clues I need to run this way.  if
> it is 100% broken, I won't worry about and just copy stuff over and
> use only the laptop.  Much has to be done this way regardless.

The rpc stuff should work, but so far it's undocumented.
Here's a quick start. If you want to play with it and write 
a mini HOWTO, you're more than welcome!

On your laptop, start "rpc.rigd -m 214 -vvvvvv -r /dev/ttySx"
Then on your main computer, start "rigctl -m 1901 -vvvvvv -r <laptopname>"
You should be able to substitute <laptopname> with the IP address of your
laptop.
Note that if you don't specify any '-r' option to rigctl, the client
will use the RPC server on the localhost. This might come handy if
several applications want to share the rig. 
Just imagine having xlog, grig and your best psk program running at the
same time, sharing seamlessly the ressource.


Altough rpc.rigd is generally installed in /usr/sbin,
it should not require root priviledges.

For more info, see man pages  rpc.rigd(8) and rigctl(1).


I hope this will get you on track, and let us know how it works for
you.

Cheers,
Stephane

[Hamlib-developer] Volunteer tester for AOR8200

[Mike L. <mle...@mo...>]

Cheers,
I have just received a new AOR8200 and I am also in the process of
installing Linux on my PC.  I am also in the middle of getting my masters in
computer science and would love to test the hamlib software for the AOR8200.
I also have an ICOM R-7100 and R-71A.  All radios have been previously
controlled by computer.

Looking forward to joining your team, if you want me.
Mike Leary

[Hamlib-developer] RIG_TRN

[Dale E. E. <de...@w-...>]

Hi all.

I'm getting to  the point I'm starting to try and figure out how to code

the exception.  I'm real weak in this area,  and I'd appreciate any
comments.

About all I've figured out is where to enter the function name.  That
is trivial, since it has an entry name like other functions for the
back-
end.  (Stephane, please *don't* write this routine.  I'd appreciate
the chance to take a stab at it.  You can always replace it later it
I botch it.  :)   )  I've glanced at a couple of backends that have one,

but don't quite understand.

Here's how it looks to me:
        1) somebody enables exception handling and the backend
        sends the autoinformation on via myrig_set_trn().  (Is the
        trn parameter like FILE, or RIG?)

        2) somewhere (I forget where) in rig.c signal exception
        handling is enabled and the myrig_decode() is installed
        as the handler.  (Is myrig_decode() supposed to read
        and decode/parse all incoming commands from the
        rig?  What is done with the information?)

        3) An exception occurs and myrig_decode() is called, which
        calls myrig_transaction() to read the command. (?)  Now we
        have the actual command that came from the rig and caused
        an exception, we decode it to find out what command it it.
        Now what do we do with it???

        4) myrig_decode() returns and the code in rig.c handles all
        of the messy cleanup etc.

The big question is in 3).  Taking the most common example from
the ts2k "sm...;" which gives us the current meter value.  This
command comes it, we determine it is a particular "op code"
"sm", it has two parmaters, Sub/Main, and Value.  These are
easily parsed.  Where do we send the data or what do we do with
it?  Is a previous myrig_transaction() on the stack waiting for
any response from the rig, which we provide?  I don't know of
a place in RIG where current values are kept (except vfo_curr).

Or, have I not got a clue what's going on here?  (That's how I
feel at the moment!)  (Oh yea, is the hamlib mechanism pretty
much in place?  I know for a fact that enabling RIG_TRN does
enable the exceptions, but that's all I know.)

I've only spent a couple of hours looking into this.  I'm going to be
busy
this week and would like some pointers if anybody has them.

Thank you and 73's.

Dale
kd7eni

[Hamlib-developer] ./configure; make

[Dale E. E. <de...@w-...>]

Hi all,

I believe I found the problem I had with ./configure; make.  Several
years
ago I started placing the following make alias in my /etc/profile:
        alias make='make -j3'
There hasn't been any problems before that I know of and compiles
have slowed since I removed it.  Now, however, hamlib fully compiles
even with perl.

Has anybody else used 'make -j 3' or similar with success?

73's

Dale
KD7ENI

Re: [Hamlib-developer] [ANN] Hamlib 1.1.3 released

[Matt E. <ma...@et...>]

@localhost.localdomain.ettus.com>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Stephane Fillod <fi...@us...> said:

> On Tue, Jun 18, 2002, Matt Ettus wrote:
> > Any interest in an F1EHN Az-el controller?  EME guys seem to love it.  I found
> > info on the control protocol from some guys who cloned the damned thing...  I
> > think its amazing that somebody put the effort in to copy bad hardware and
> > protocols just to be compatible with closed source control software...
> >
> > Anyway, they have docs on the [primitive] protocol here...
> >
> > http://www.dnai.com/~rexa/Projects/EMEboard.html
>
> Thanks for the URL. If anyone has such an Az-el controller, please let
> me know, so the backend would be tested.

We're installing an EME system at my club which will be using one of these
boards.  I'm doing some mods to make the card work with our rotors, so I'll have
it at home for about a month.

Matt

Re: [Hamlib-developer] [ANN] Hamlib 1.1.3 released

[Stephane F. <fi...@us...>]

On Tue, Jun 18, 2002, Matt Ettus wrote:
> Any interest in an F1EHN Az-el controller?  EME guys seem to love it.  I found
> info on the control protocol from some guys who cloned the damned thing...  I
> think its amazing that somebody put the effort in to copy bad hardware and
> protocols just to be compatible with closed source control software...
> 
> Anyway, they have docs on the [primitive] protocol here...
> 
> http://www.dnai.com/~rexa/Projects/EMEboard.html

Thanks for the URL. If anyone has such an Az-el controller, please let
me know, so the backend would be tested.

> > Plan for 1.1.4:
> > * collaboration with gnuradio project
> 
> Cool.  Did you get a chance to grab the gnuradio code?

yep, but haven't had time to look into it. Maybe this week-end.
I'll keep you in touch.

 
Stephane

Re: [Hamlib-developer] Re: [ANN] Hamlib 1.1.3 released

[Alexandru C. <al...@ph...>]

Hi Nate,
 
> If there is anyone on either list that would like to take over the
> Hamlib webpage maintenance and/or the documentation I started, please
> volunteer!  I had much more free time when I volunteered, but so far no
> one has stepped forward to relieve me, although I only askedi for relief
> once or twice on the Hamlib list.

I'll be glad to help you out with the docs or the website (preferably
not both). I have just taken my final exam and I hope that I will
actually have some spare time in the next six months or so. The bad news
is that I'll be gone to Geneva for the next four weeks and I will
probably not be able to do anything before I'm back. I'll get back to
you then (I will try not to forget it). Of course, I won't be sad if
someone else will "get the job" in the meanwhile.

Alex, OZ9AEC

 
-- 

Re: [Hamlib-developer] Re: [ANN] Hamlib 1.1.3 released

[Riley W. <rh...@In...>]

Hi Alex.

> The home page has probably not been updated yet, but you can
> download the source code from the project page at
> http://sourceforge.net/projects/hamlib

Many thanks, but as the home page appears to have completely skipped
a version, I have to consider it less than reliable...

You've probably seen my email to the coordinator on the HamLib mailing
list (which I'm not on atm) dealing with this though...

Best wishes from Riley.

=======================================================================

> Quoting Riley Williams <rh...@In...>:
> 
> > Hi Stephane.
> > 
> > > Hamlib-1.1.3 has finally been released.
> > > Check it out at http://www.hamlib.org !
> > 
> > This announcement appears to be premature as the download link from the
> > page specified only shows 1.1.1 as being available. Can somebody
> > clarify
> > that please?
> > 
> > > Note: locator calculation is not working right.
> > 
> > What exactly is the problem?
> > 
> > Best wishes from Riley G7GOD / KB8PPG.
> > 
> > 
> > 
> > -------------------------------------------------------
> > Sponsored by:
> > ThinkGeek at http://www.ThinkGeek.com/
> > _______________________________________________
> > Hamlib-developer mailing list
> > Ham...@li...
> > https://lists.sourceforge.net/lists/listinfo/hamlib-developer
> > 
> 

Re: [Hamlib-developer] Re: [ANN] Hamlib 1.1.3 released

[Riley W. <rh...@In...>]

Hi Nate.

>>> Hamlib-1.1.3 has finally been released.
>>> Check it out at http://www.hamlib.org !

>> This announcement appears to be premature as the download link from
>> the page specified only shows 1.1.1 as being available. Can somebody
>> clarify that please?

>>> Note: locator calculation is not working right.

>> What exactly is the problem?

> The problem, it would seem, is me. I quite simply forgot about it as
> I've been rather busy of late and now my $%#$@!!! air conditioner
> quit which makes it a tad miserble in the house. I'll try to get to
> it, but I have a lot of loose ends before Field Day this weekend.

I think we're dealing with different questions here - My question as
quoted above related to the "location calculator" rather than to the
announcement that preceded it.

I have to say that what puzzled me was that the download web page listed
1.1.1 as the latest version, and the announcement referred to 1.1.3 so
either 1.1.2 was never released or the web page was unreliable.

> If there is anyone on either list that would like to take over the
> Hamlib webpage maintenance and/or the documentation I started,
> please volunteer! I had much more free time when I volunteered, but
> so far no one has stepped forward to relieve me, although I only
> asked for relief once or twice on the Hamlib list.

I'm not on the HamLib list at the moment, as I'm rather tied up with
sorting my wife's health out - at the moment, the local hospital is far
too near being a second home for my liking. However, it should be fairly
simple to set it up to auto-update as you make the releases on SF.Net so
that you can forget about it.

Once my wife's health is sorted out, I'd be willing to volunteer, but I
can't even guess when that might be at this stage.

Best wishes from Riley G7GOD / KB8PPG.

Re: [Hamlib-developer] Re: [ANN] Hamlib 1.1.3 released

[Nate B. <n0...@ne...>]

* Riley Williams <rh...@In...> [2002 Jun 20 16:53 -0500]:
> Hi Stephane.
> 
> > Hamlib-1.1.3 has finally been released.
> > Check it out at http://www.hamlib.org !
> 
> This announcement appears to be premature as the download link from the
> page specified only shows 1.1.1 as being available. Can somebody clarify
> that please?
> 
> > Note: locator calculation is not working right.
> 
> What exactly is the problem?

Hi Riley.

The problem, it would seem, is me.  I quite simply forgot about it as
I've been rather busy of late and now my $%#$@!!! air conditioner quit
which makes it a tad miserble in the house.  I'll try to get to it, but
I have a lot of loose ends before Field Day this weekend.

If there is anyone on either list that would like to take over the
Hamlib webpage maintenance and/or the documentation I started, please
volunteer!  I had much more free time when I volunteered, but so far no
one has stepped forward to relieve me, although I only askedi for relief
once or twice on the Hamlib list.

> Best wishes from Riley G7GOD / KB8PPG.

Thank you.

73, de Nate >>

-- 
 Wireless | Amateur Radio Station N0NB          | "We have awakened a
 Internet | n0...@ne...               | sleeping giant and
 Location | Bremen, Kansas USA EM19ov           | have instilled in him
  Amateur radio exams; ham radio; Linux info @  | a terrible resolve".
             http://www.qsl.net/n0nb/           | - Admiral Yamomoto

Re: [Hamlib-developer] Re: [ANN] Hamlib 1.1.3 released

[<al...@ph...>]

Hi Riley,

The home page has probably not been updated yet, but you can download the source
code from the project page at http://sourceforge.net/projects/hamlib

Alex, OZ9AEC

Quoting Riley Williams <rh...@In...>:

> Hi Stephane.
> 
> > Hamlib-1.1.3 has finally been released.
> > Check it out at http://www.hamlib.org !
> 
> This announcement appears to be premature as the download link from the
> page specified only shows 1.1.1 as being available. Can somebody
> clarify
> that please?
> 
> > Note: locator calculation is not working right.
> 
> What exactly is the problem?
> 
> Best wishes from Riley G7GOD / KB8PPG.
> 
> 
> 
> -------------------------------------------------------
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer
> 

[Hamlib-developer] Memory Save/Restore (anyrig to anyrig)

[Dale E. E. <de...@w-...>]

Alex,

My thoughts exactly.  I've got a utility I wrote for the Kenwood TS-2000

that saves the memories, and another that will restore them.
Additionally,
I have one that reads a file of commands and sends them to the rig.   I
manually edit: current.mem, setup.cmd to include the local repeaters,
and my basic setup for my rig.  When I do a full reset, I'm back to
normal
within a couple of minutes.

I've got a version of the hamlib-1.1.3 where I've got the
rig_get_channel()
working (partially).  Hamlib needs very little added to support this.
We
may need: rig_read_channel(RIG *rig, FILE * file, channel_t chan),
rig_write_channel().

Alternatively, a program like rigctl can just use the existing stuff and

read and/or write channels as desired them write them in some generic
file format.

I haven't thought much about the file format except that:
    1) It should be text.
    2) It should be easy to modify to add/delete records.

The scanner and parser should be easy enough depending on how
it's implemented.  As you mentioned, XML may make it very
easy and standard (I need to learn more about XML).

A setup file should even work between two rigs using hamlib
(that's what makes hamlib so interesting!).  Of course, some
fields will get ignored or be slightly different.

73's

Dale
kd7eni

[Hamlib-developer] Re: [ANN] Hamlib 1.1.3 released

[Riley W. <rh...@In...>]

Hi Stephane.

> Hamlib-1.1.3 has finally been released.
> Check it out at http://www.hamlib.org !

This announcement appears to be premature as the download link from the
page specified only shows 1.1.1 as being available. Can somebody clarify
that please?

> Note: locator calculation is not working right.

What exactly is the problem?

Best wishes from Riley G7GOD / KB8PPG.

[Hamlib-developer] TS-2000 issues

[Dale E. E. <de...@w-...>]

Stephane,

I tried replying to your e-mail but just ended up doing
a lot of babling.  (Not uncommon for me.  I'm on
midnight shift and haven't be sleeping well the past
three days.)

1) My ts2k.c with its ts2k_transaction() is now
working quite well.  I've made changes to both
it and the calling routines.  There were one or more
fixes (maybe changes would be a better word.)
The original code obviously has the original problems.
I'm including my current version of ts2k.c so you
can draw your own conclusion.  Send it back with
any modifications you feel like making and I'll re-
check every command on the rigctl help page.

2) The comment about "ai2;" is general.  I haven't
programmed anything to use it.  When I've turned
it on in hamlib I've been able to turn it off again
but rigctl must be restarted afterwards.  I'll try
it again and send you the trace.   My view on "ai2;"
is much like interrupt enable in a hardware driver.
Turn it off when you first enter the routine, and
back on as quickly as possible.  Race type con-
ditions may occur on one hand and loss of info
on the other.  Hamlib will have to balance the
two to minimize each.

I've ran minicom with "ai2;" enabled and viewed
the logs.  At the time I became convinced that
this was the correct way proceed.  Its possible,
if not likely, that I'm wrong.  I am logging "ai2;"
data with my rig on scan right not.  If you are
interested, I can gzip and e-mail it to you.  I'll
send you script of hamlib-1.1.3 doing the same,
as well as my hamlib-1.1.3-kd7eni (didn't know
how else to keep'em separate.)

73's.  (I'm starting to babble again.)

Oh, one more item.  I've typed in the text for
the menus (62+).  I'd like to create:
    rig_menu_init()        read current menu setting
    rig_menu_list()        send string for e.g. menu(55)
    rig_next_menu()
    rig_prev_menu()
    rig_set_menu()
    rig_get_menu()
    rig_menu()                e.g. set menuA/B
These will be needed in some form or
another.  I'd rather call rig_set_menu()
than program "ex05500004;" or whatever!
It is in ts2k_menu.h and available if you want
it.  Its incomplete, but maybe you have ideas?
:)

Dale
kd7eni

[Hamlib-developer] Idea to consider

[A V F. <avf...@at...>]

On the daily drive home today, a topic came up over the local 2m 
repeater, that might fit in with hamlib.

What was being discussed was the possibility of cloning rigs. While it is 
possible to xfer settings from many rigs to another of the same type, but 
what would be handy is if we had a way to transfer memory settings 
between two completely different units.  

If we came up with a common data format (xml perhaps) one could read 
settings from your "Super Whizzo DSP-9000X", swap interface cables and 
transfer to your buddies "Dumb as a Stone Analog 3B"....

Just an idea to kick around


-- 
Alex / KC2IVL 
http://www.qsl.net/kc2ivl
"Good judgment comes from experience, 
  and a lot of that comes from bad judgment"

[Hamlib-developer] rigctl/hamlib errors (sortof hamlib-1.1.3)

[Dale E. E. <de...@w-...>]

With the exception of the six func,level, parameter (get/set)
and vfo_op, I have at least simple functions implemented for
all those listed on the rigctl help page, for the TS-2000.
(Hopefully I'll be able to get them into CVS--Stephan's
looking into it.)  (Stephan had a good many working before
I even heard of hamlib.)   :)

There are 3 or 4 that don't seem to be working in hamlib.  If
anybody has working versions for the following, could you
please let me know the module/function?
            H:    myrig_set_channel()        // not in rigctl yet.
            g:    myrig_scan()                       // nevers gets
called!
            X:    myrig_set_split_mode()  // I'm clueless
            2:     myrig_???_???()       // what's it supposed to do?

Everything else either worked when I started, has been
debugged to at least minimal functionality, or I wrote
new (at least minimally).

I haven't crosschecked this list with src/rig.c for some
time and don't know what else may be missing yet
important.  I'm gettiing there though (and taking
a break)!

Thanks in advance.

Dale
kd7eni

[Hamlib-developer] hamlib-1.1.3.tar.gz

[Dale E. E. <de...@w-...>]

Hi,

hamlib-1.1.3.tar.gz:
./configure; make; make install all worked on my main computer.
make distclean failed (as it has been doing with my CVS sources)

Anybody else have this problem?  It tends to leave things in an
unbuildable state.  Using an empty build directory is a good
workaround but still has its problems:
        cd ../bld; ../hamlib/configure

Thanks all.

Dale
kd7eni

Re: [Hamlib-developer] [ANN] Hamlib 1.1.3 released

[Matt E. <ma...@et...>]

Stephane Fillod <fi...@us...> said:

>  * rotator frontend, new easycomm backend

Any interest in an F1EHN Az-el controller?  EME guys seem to love it.  I found
info on the control protocol from some guys who cloned the damned thing...  I
think its amazing that somebody put the effort in to copy bad hardware and
protocols just to be compatible with closed source control software...

Anyway, they have docs on the [primitive] protocol here...

http://www.dnai.com/~rexa/Projects/EMEboard.html

> Plan for 1.1.4:
> * collaboration with gnuradio project

Cool.  Did you get a chance to grab the gnuradio code?

Matt

[Hamlib-developer] [ANN] Hamlib 1.1.3 released

[Stephane F. <fi...@us...>]

Good news everyone!

Hamlib-1.1.3 has finally been released.
Check it out at http://www.hamlib.org !

New in 1.1.3:
 * new backend: JRC (NRD-545), and many new rig models
 * rotator frontend, new easycomm backend
 * added Kylix and perl bindings and completed tcl/tk support
 * networked (RPC) rig and rotator

Note: locator calculation is not working right.

Download pages are accessible at http://sourceforge.net/projects/hamlib
i386 rpms and .deb coming soon.

Plan for 1.1.4:
* Enter more models of supported backends
* more rotor stuff
* extend perl binding, add Java binding
* collaboration with gnuradio project
* etc. (any wishes?)

Please, test it out and report to ham...@li...
Developers are also invited to join the Hamlib team by subscribing to this
mailing list.

Have fun and let us know!

73's de Stephane Fillod (f8cfe)

[Hamlib-developer] URGENT 25 is too late

[<Ra...@vo...>]

5pm is too late and I don't knownwhere the tech center is call me ASAP.


I will me at the testing site by 6PM definatly

G

[Hamlib-developer] CVS checkin

[Dale E. E. <de...@w-...>]

Nate,

Thanks a lot.  Stephane e-mailed  me a while back an said the "magic
band"
was keeping him pretty busy.  I've sent him some basic files, but now
they
are very obsolete.  At least they will have the two new files inserted
into the
tree and will be buildable (when he gets to it).

My e-mail is strange and I'm just getting set up.  Now that I'm able to
receive
and send on the developer's list I'll keep up on what's going on.

I'd like very much if you'd test out my changes if you'd like.  However,
since
I've made some pretty extensive changes to things like RIG_VFO_* in
rig.h,
rig.c, and rigctl, I'd like the changes to be reviewed before being
checked
directly into CVS.

The gist of the non-ts2k changes are the addition of numerous VFO types.

They are as follows:
           RIG_VFO_AB       // split, RX=VFOA on Main receiver
           RIG_VFO_BA      // split, RX=VFOB on Main receiver
           RIG_VFO_MEM_A    // Memory on Main receiver
           RIG_VFO_MEM_C   // Memory on Sub receiver
           RIG_VFO_CALL_A    // Call channel on Main
           RIG_VFO_CALL_C    // Call channel on Sub
I plan on adding the following:
           RIG_VFO_A_MEM    // split, RX=VFOA, TX=MEMA
           RIG_VFO_B_MEM    // split, RX=VFOB, TX=MEMA
but it requires a little more programming.  (Plus any more that I can.)

The point of these changes is to make it obvious what the exact
state of the rig is.  I can now put the TS-2000 into any of the above
states (first six) plus the normal VFOA, VFOB, VFOC.  Just making
VFOC was a chore without the changes.

A word of caution:  Adding these extra vfo's is really cool in what
you can do, but right now my _get_freq() doesn't work by default.
If this is expected behaviour you could say its broken.  The _get_freq()

now has to do commands to specifically read these other vfo's.
In actuality, it is better since I won't receive VFOA when the rig
is on the sub receiver, or MEMA when MEMC is selected.  Other
developers may have solved this differently or better.

A curious side effect is that treating RIG_VFO_AB as its own VFO,
is that the rig_set_split_freq() doesn't really need to exist, but it
doesn't hurt anything either.  What I'm working towards is being
able to create a rig_set_active( active_t  xcvr ) or similar function
that will set the rig mode (as opposed to transmission mode) such
as satellite, scan,  Main, Sub, etc...  Each 'activated' state the rig
can be in usually has distinct vfo's, transmission modes etc... that
are either required or default.  This is just a higher level of control
than the *_set_vfo() *_set_mode() combinations.  The need for
numerous unique modes for every rig will (hopefully) be elimanted.
Also, software will be able to simulate these modes in some instances.

Finally, if you (or anybody) would like to look at these as I've applied

them to my kenwood/ts2k.c, I'll be happy to make a tarball of the
changes and e-mail them to you directly.  I'd prefer to get a little
more of a consensus before just dropping them into CVS.  Once
I'm a little more confident everybody'll be happy, then they can
get checked into CVS and we'll deal with what happens after
that.

Sorry, I carried on so long.  It would have been easier to say,
"Sure, I'd appreciate it if you'd put them into CVS for me."
but I'd like people to have a chance to yea or nay first.

73's and let me know.  I'm eager to continue on with this stuff.

(By the way, I think I've fixed most, if not all, the problems I've
posted to the group earlier--except the rpcrig which I had to
remove.)

Thank you.

Dale E. Edmons
KD7ENI

[Hamlib-developer] GOV GRANTS, NEVER REPAY!!!!!!!!

[<kx...@ki...>]

<html><body>
<hr width =3D "100%">
<center><font size =3D "+2" color =3D "#44C300"><b>Government Grants E-Boo=
k 2002 edition</font></b><p>
<table><Tr><td> 
<li>You Can Receive The <font color =3D "green"><b>Money</b></font> You Ne=
ed...
<li>Every day <b><font color =3D "green">millions of dollars</font></b> ar=
e given away to people, just like you!!
<li>Your Government spends <b><font color =3D "green">billions</font></b> =
of tax dollars on government grants.
<li>Do you know that private foundations, trust and corporations are
<li>required to give away a portion of theirs assets. It doesn't matter,
<li>where you live (USA ONLY), your employment status, or if you are broke=
, retired
<li>or living on a fixed income. There may be a grant for you!
<hr width =3D "100%">
<li><font color =3D "red"><b>ANYONE</b></font> can apply for a Grant from =
18 years old and up!
<li>We will show you HOW & WHERE to get Grants. <font color =3D "red"><b>T=
HIS BOOK IS NEWLY UPDATED WITH THE MOST CURRENT INFORMATION!!!</b></font>
<li>Grants from $500.00 to $50,000.00 are possible!
<li>GRANTS don't have to be paid back, EVER!
<li>Grants can be ideal for people who are or were bankrupt or just have b=
ad credit.
</td></tr></table>
<br><font size =3D "+1">Please Visit Our Website<p></font>
And Place Your <font color =3D "red"> <b>Order TODAY!</b> </font><a href =3D=
 "http://www153.freeweb-hoster.com/grant/"><b><font size=3D"5">CLICK HERE<=
/font></b> </a><p>&nbsp;<p>
<font size=3D"1">
We apologize for any email you may have inadvertently received.<br>
Please <a href =3D "http://www153.freeweb-hoster.com/remove.htm">CLICK HER=
E</a> to be removed from future mailings.</font><br>

</BODY>
</HTML>

Re: [Hamlib-developer] rpcrig (howto)

[Nate B. <n0...@ne...>]

* Dale E. Edmons <de...@w-...> [2002 Jun 16 07:25 -0500]:
> Hi again,
> 
> Just a quick question.  My laptop is connected to my rig and is slower
> than my main computer.  The two computers are connected via
> ethernet and allows me to do anything on one the other won't do.
> 
> I believe rpcrig is for control via this type of link.  It'd be
> convienient
> (and really cool) if I could run rigctl remotely via rpcrig.  I'm sure
> that the development status is not what it wants to be but I'd give
> it a go if someone would give the clues I need to run this way.  if
> it is 100% broken, I won't worry about and just copy stuff over and
> use only the laptop.  Much has to be done this way regardless.
> 
> Thanks.
> 
> (Is it just me or is it pretty quiet in here?)

Hi Dale.

You're not being ignored, I think Stephane may be on holiday or vacation
the past several days, or buried in other work.  Certainly, you're not
being ignored, I just don't have good answers to your excellent questions.

Look through the archives.  In the past couple of weeks one of the GNU
Radio developers was asking about roughly the same thing but wanting to
use TCP/IP rather than RPC.  So, I think some work is ongoing in that
area too.

BTW, Welcome to the group.  I can't add you to the development list, but
I'd be willing to drop your patches into the tree as I do have CVS
access.  Let me know!

73, de Nate >>

-- 
 Wireless | Amateur Radio Station N0NB          | "We have awakened a
 Internet | n0...@ne...               | sleeping giant and
 Location | Bremen, Kansas USA EM19ov           | have instilled in him
  Amateur radio exams; ham radio; Linux info @  | a terrible resolve".
             http://www.qsl.net/n0nb/           | - Admiral Yamomoto

[Hamlib-developer] Lower Your Merchant Service Rates 3138uLtQ8-465EuYA3569p-21

[<ada...@ao...>]

PGh0bWw+DQo8Zm9udCBjb2xvcj0iZmZmZmZmIj5hbGxteWdpcmxzPC9mb250
Pg0KPGRpdiBhbGlnbj0iY2VudGVyIj4NCiAgPHN0cm9uZz48Zm9udCBmYWNl
PSJDb3BwZXJwbGF0ZSBHb3RoaWMgQm9sZCIgc2l6ZT0iNiI+RG9uJ3QgQmUg
QW5vdGhlcg0KICBFLUNvbW1lcmNlIFN0YXRpc3RpYyE8L2ZvbnQ+PC9zdHJv
bmc+DQo8L2Rpdj4NCjxkaXYgYWxpZ249ImxlZnQiPg0KICAmbmJzcDsNCjwv
ZGl2Pg0KPGRpdiBhbGlnbj0ibGVmdCI+DQogIDxwIGFsaWduPSJjZW50ZXIi
Pjxmb250IGNvbG9yPSIjRkYwMDAwIiBmYWNlPSJQaG90aW5hIENhc3VhbCBC
bGFjayIgc2l6ZT0iNiI+QWNjZXB0IEFsbCBNYWpvciBDcmVkaXQNCiAgQ2Fy
ZHM8L2ZvbnQ+Jm5ic3A7DQo8L2Rpdj4NCjxkaXYgYWxpZ249ImxlZnQiPg0K
ICAmbmJzcDsNCjwvZGl2Pg0KPGRpdiBhbGlnbj0ibGVmdCI+DQogIDxmb250
IGZhY2U9IlRyZWJ1Y2hldCBNUyIgc2l6ZT0iNCIgY29sb3I9IiMwMDAwMDAi
Pkxpa2UgbWFueSBidXNpbmVzc2VzLCB5b3UgaGF2ZQ0KICBwcm9iYWJseSBm
b3VuZCB0aGF0IG5vdCBiZWluZyBhYmxlIHRvIGFjY2VwdCBjcmVkaXQgY2Fy
ZHMgaXMgbWFraW5nIHlvdXINCiAgd2Vic2l0ZSBqdXN0IGFub3RoZXIgcHJl
dHR5IHBpY3R1cmUhPC9mb250Pg0KPC9kaXY+DQo8ZGl2IGFsaWduPSJsZWZ0
Ij4NCiAgPGZvbnQgY29sb3I9IiMwMDAwMDAiIGZhY2U9IlRyZWJ1Y2hldCBN
UyI+DQogICZuYnNwOzwvZm9udD4NCjwvZGl2Pg0KPGRpdiBhbGlnbj0ibGVm
dCI+DQogIDxmb250IGZhY2U9IlRyZWJ1Y2hldCBNUyIgc2l6ZT0iNCIgY29s
b3I9IiMwMDAwMDAiPkxldCdzIGZhY2UgaXQgLS0gYWNjZXB0aW5nIGNyZWRp
dA0KICBjYXJkcyBvbmxpbmUgaXMgbm90IG9ubHkgYSBtb25leS1tYWtlciwg
aXQgaXMgYW4gZXNzZW50aWFsIHBhcnQgb2YgYW55DQogIGludGVybmV0IGNv
bW1lcmNlIGFjdGl2aXR5LiBPdmVyIDk3JSBvZiBhbGwgc2FsZXMgb24gdGhl
IEludGVybmV0IGFyZSBkb25lDQogIHdpdGggQ3JlZGl0IENhcmRzLjwvZm9u
dD4NCjwvZGl2Pg0KPGRpdiBhbGlnbj0ibGVmdCI+DQogIDxmb250IGNvbG9y
PSIjMDAwMDAwIiBmYWNlPSJUcmVidWNoZXQgTVMiPg0KICAmbmJzcDs8L2Zv
bnQ+DQo8L2Rpdj4NCjxkaXYgYWxpZ249ImxlZnQiPg0KICA8Zm9udCBmYWNl
PSJUcmVidWNoZXQgTVMiIHNpemU9IjQiIGNvbG9yPSIjMDAwMDAwIj5BbmQg
LiAuIC4gOTIlIG9mIG1haWwgb3JkZXJzICZhbXA7DQogIHBob25lIG9yZGVy
cyBhcmUgZG9uZSB3aXRoIGNyZWRpdCBjYXJkcy4gVGhlIG51bWJlcnMgZG9u
J3QgbGllLiA5DQogIG91dCBvZiAxMCBwb3RlbnRpYWwgY3VzdG9tZXJzIGNh
bid0IGRvIGJ1c2luZXNzIHdpdGggeW91IGlmIHlvdQ0KICBkb24ndCB0YWtl
IGNyZWRpdCBjYXJkcy48L2ZvbnQ+DQo8L2Rpdj4NCjxwPiZuYnNwOzwvcD4N
CjxkaXYgYWxpZ249ImxlZnQiPg0KICA8cCBhbGlnbj0iY2VudGVyIj4NCiAg
PGZvbnQgc2l6ZT0iNCIgZmFjZT0iRXJhcyBNZWRpdW0iPjxzdHJvbmc+Jm5i
c3A7PC9zdHJvbmc+PC9mb250PjxzdHJvbmc+PGZvbnQgZmFjZT0iQ29wcGVy
cGxhdGUgR290aGljIEJvbGQiIHNpemU9IjQiPllPVQ0KICBDQU4gQkVHSU4g
QUNDRVBUSU5HIENSRURJVCBDQVJEUyBJTiBBUyBMSVRUTEUgQVMgMjQgSE9V
UlMhDQo8UD4NClVTIEJVU0lORVNTRVMgT05MWTwvZm9udD48L3N0cm9uZz4N
CjxQPg0KPC9kaXY+DQo8ZGl2IGFsaWduPSJjZW50ZXIiPg0KICA8Zm9udCBj
b2xvcj0iIzAwMDAwMCI+DQogIChEZXBlbmRpbmcgdXBvbiB0aGUgY3JlZGl0
IGNhcmQgcHJvZ3JhbSB3ZSBnZXQgeW91IHF1YWxpZmllZCBmb3IpPC9mb250
Pg0KPC9kaXY+DQo8ZGl2IGFsaWduPSJjZW50ZXIiPg0KICAmbmJzcDsNCjwv
ZGl2Pg0KPGRpdiBhbGlnbj0iY2VudGVyIj4NCjxmb250IHNpemU9IjQiPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAw
cHQiIGFsaWduPSJjZW50ZXIiPjxzdHJvbmc+PGZvbnQgc2l6ZT0iNSIgZmFj
ZT0iVHcgQ2VuIE1UIiBjb2xvcj0iI0ZGRkZGRiI+PHNwYW4gc3R5bGU9IkZP
TlQtU0laRTogOHB0OyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+PE86
UD4NCjwvc3Bhbj4NCjwvZm9udD48L3N0cm9uZz4NCjwvZm9udD4NCjxzdHJv
bmc+PHNwYW4gc3R5bGU9Im1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0Ij48
Zm9udCBzaXplPSI2IiBmYWNlPSJUdyBDZW4gTVQiIGNvbG9yPSIjRkZGRkZG
Ij4NCjwvZm9udD48L3NwYW4+PC9zdHJvbmc+PGZvbnQgZmFjZT0iVHcgQ2Vu
IE1UIiBzaXplPSI1Ij48Zm9udCBjb2xvcj0iI0ZGMDAwMCI+RXhpc3RpbmcN
Ck1lcmNoYW50czo8L2ZvbnQ+PGZvbnQgZmFjZT0iVHcgQ2VuIE1UIiBzaXpl
PSI1IiBjb2xvcj0iI0ZGRkZGRiI+ICA8L2ZvbnQ+PGZvbnQgY29sb3I9IiMw
MDAwMDAiPiBsb3dlciB5b3VyDQpyYXRlcy1GUkVFIHN0YXRlbWVudCBhbmFs
eXNpczwvZm9udD48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQiIGFsaWduPSJjZW50ZXIiPjwv
cD4NCiAgJm5ic3A7DQo8L2Rpdj4NCjxoMSBzdHlsZT0iTUFSR0lOOiAwaW4g
MGluIDBwdCIgYWxpZ249ImNlbnRlciI+PHNwYW4gc3R5bGU9Im1zby1iaWRp
LWZvbnQtc2l6ZTogMTAuMHB0Ij48Zm9udCBjb2xvcj0iI2ZmMDAwMCIgZmFj
ZT0iVHJhamFuIiBzaXplPSI2Ij5XaHkNCk5vdCBJbmNyZWFzZSBzYWxlcyBi
eSA0MDAlPzwvZm9udD48L3NwYW4+PC9oMT4NCjxmb250IHNpemU9IjQiPg0K
PGgxIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0IiBhbGlnbj0iY2VudGVy
Ij48c3BhbiBzdHlsZT0iRk9OVC1TSVpFOiAxNHB0OyBtc28tYmlkaS1mb250
LXNpemU6IDEwLjBwdCI+PGZvbnQgY29sb3I9IiNmZjAwMDAiIHNpemU9Iisw
Ij48TzpQPg0KPC9POlA+DQo8L2ZvbnQ+PC9zcGFuPjwvaDE+DQo8L2ZvbnQ+
DQo8cCBjbGFzcz0iTXNvQm9keVRleHQiIHN0eWxlPSJNQVJHSU46IDBpbiAw
aW4gMHB0IiBhbGlnbj0iY2VudGVyIj4mbmJzcDs8L3A+DQo8cCBjbGFzcz0i
TXNvQm9keVRleHQiIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0IiBhbGln
bj0iY2VudGVyIj48Zm9udCBmYWNlPSJUdyBDZW4gTVQiIHNpemU9IjUiIGNv
bG9yPSIjMDAwMEZGIj5WaXNhLA0KTWFzdGVyQ2FyZCwgQW1lcmljYW4gRXhw
cmVzcywgRGlzY292ZXIgJmFtcDsgRWxlY3Ryb25pYyBDaGVjazwvZm9udD48
L3A+DQo8Zm9udCBzaXplPSI0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0IiBhbGlnbj0iY2VudGVyIj48Zm9u
dCBzaXplPSI1IiBmYWNlPSJUdyBDZW4gTVQiPjxPOlA+DQo8L086UD4NCjwv
Zm9udD48L3A+DQo8L2ZvbnQ+DQo8aDQgc3R5bGU9Ik1BUkdJTjogMGluIDBp
biAwcHQiIGFsaWduPSJjZW50ZXIiPjxmb250IGZhY2U9IlR3IENlbiBNVCIg
c2l6ZT0iNSI+U2FtZQ0KRGF5IEFwcHJvdmFsIC0gTm8gVHVybiBEb3ducyAt
IEVhc3kgRmF4IEFwcGxpY2F0aW9uPC9mb250PjwvaDQ+DQo8Zm9udCBzaXpl
PSI0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJNQVJHSU46IDBp
biAwaW4gMHB0IiBhbGlnbj0iY2VudGVyIj48Zm9udCBzaXplPSI1IiBmYWNl
PSJUdyBDZW4gTVQiPjxPOlA+DQo8L086UD4NCjwvZm9udD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCIg
YWxpZ249ImNlbnRlciI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPjxzcGFuIHN0
eWxlPSJGT05ULVNJWkU6IDEycHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAu
MHB0Ij48Zm9udCBzaXplPSI1IiBmYWNlPSJUdyBDZW4gTVQiPlJldGFpbA0K
PC9mb250Pg0KPC9zcGFuPg0KPC9mb250Pg0KPC9mb250Pg0KPGZvbnQgY29s
b3I9IiMwMDAwMDAiPg0KPHNwYW4gc3R5bGU9IkZPTlQtU0laRTogMTJwdDsg
bXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQiPg0KPGZvbnQgc2l6ZT0iNSIg
ZmFjZT0iVHcgQ2VuIE1UIiBjb2xvcj0iI0ZGRkZGRiI+ICogV2ViICogVmly
dHVhbCBUZXJtaW5hbCAqIE1haWwNCk9yZGVyICogVGVsZXBob25lIE9yZGVy
PE86UD4NCjwvTzpQPg0KPC9mb250Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGZv
bnQgc2l6ZT0iNCI+DQo8cCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCIg
YWxpZ249ImNlbnRlciI+PC9wPg0KPHAgYWxpZ249ImxlZnQiPg0KPC9mb250
Pg0KPGZvbnQgZmFjZT0iVHcgQ2VuIE1UIiBzaXplPSI1Ij48Zm9udCBjb2xv
cj0iIzAwMDAwMCI+SXQgb25seSB0YWtlcyBhDQpmZXcgc2Vjb25kcyEgPC9m
b250PjwvZm9udD48YSBocmVmPSJodHRwOi8vd3d3LnJlcXVlc3RlZGluZm8u
bmV0L2NnaS1iaW4vbWVyY2hhbnRfc2VydmljZXMuY2dpP2FmZmlsaWF0ZT01
MjAxNzkiPjxmb250IGNvbG9yPSIjMDAwMEZGIiBmYWNlPSJQZXJwZXR1YSIg
c2l6ZT0iNSI+Q2xpY2sgSGVyZSB0byBTdGFydCBBY2NlcHRpbmcgQ3JlZGl0
IENhcmRzIFRvZGF5ITwvZm9udD48L2E+PC9wPg0KPHAgYWxpZ249ImxlZnQi
Pjxmb250IGZhY2U9IlR3IENlbiBNVCIgc2l6ZT0iNSIgY29sb3I9IiMwMDAw
MDAiPlBsZWFzZQ0KaW5jbHVkZSB5b3VyIGJ1c2luZXNzIG5hbWUsIGNvbnRh
Y3QgbmFtZSwgcGhvbmUgbnVtYmVyLCBhbmQgdGhlIGJlc3QgdGltZSB0bw0K
cmVhY2ggeW91LjwvZm9udD48L3A+DQo8Zm9udCBzaXplPSI0Ij4NCjxwIHN0
eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0IiBhbGlnbj0ibGVmdCI+PGZvbnQg
Y29sb3I9IiMwMDAwMDAiPiZuYnNwO1lvdSBjYW4gYWx3YXlzIGdldCB5b3Vy
IGFkZHJlc3Mgb3V0IG9mIG91ciBkYXRhYmFzZSBieSBzdG9wcGluZyBieSBv
dXIgd2Vic2l0ZSBhbmQgZW50ZXJpbmcgaW50byB0aGUgY29tcGxldGUgZGF0
YWJhc2UgZGVsZXRpb24gc3lzdGVtLg0KPC9mb250Pg0KPENFTlRFUj48Rk9O
VCBzaXplPSszPg0KPEhSPg0KPC9GT05UPjxmb250IGNvbG9yPSIjRkYwMDAw
IiBzaXplPSI2IiBmYWNlPSJUcmVidWNoZXQgTVMiPjxzdHJvbmc+PGJsaW5r
PjxzcGFuIHN0eWxlPSJmb250LXZhcmlhbnQ6IHNtYWxsLWNhcHMiPmNhcGl0
YWxpemUNCm9uIG92ZXIgYSBiaWxsaW9uIGRvbGxhcnMgaW4gcHJvY2Vzc2lu
ZyBwb3dlciE8L3NwYW4+PC9ibGluaz48L3N0cm9uZz48L2ZvbnQ+DQo8cD48
c3Ryb25nPjxibGluaz48c3BhbiBzdHlsZT0iZm9udC12YXJpYW50OiBzbWFs
bC1jYXBzIj48Zm9udCBmYWNlPSJUcmVidWNoZXQgTVMiIGNvbG9yPSIjMDAw
MDAwIiBzaXplPSI1Ij5nZXQNCnRoZSBpbmZvcm1hdGlvbiBvbiB0aGUgbG93
ZXN0IHJhdGVzIGluIHRoZSBpbmR1c3RyeSE8L2ZvbnQ+PC9zcGFuPjwvYmxp
bms+PC9zdHJvbmc+PC9wPg0KPC9DRU5URVI+DQo8UD4NCjxDRU5URVI+DQo8
SFI+DQo8L0NFTlRFUj4NCjxwIGFsaWduPSJsZWZ0Ij48L3A+DQo8cD4gPC9w
Pg0KPHA+IDwvcD4NCjwvSFRNTD4NCjg5ODRUZ3NqNi05MzJJa2wxNA==