[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tlf-devel] Hamlib slows XTLF Wayyyyyy Doooowwwwwwnnnnnnn

From: Rein Couperus PA0R
Subject: Re: [Tlf-devel] Hamlib slows XTLF Wayyyyyy Doooowwwwwwnnnnnnn
Date: Sat, 08 Jul 2006 15:43:05 +0200

See comments below...

On Sat, 2006-07-08 at 07:19 -0500, Nate Bargmann wrote:
> * Rein Couperus PA0R <address@hidden> [2006 Jul 08 03:26 -0500]:
> > I can't imagine ;) I will look into that. It should not have that
> > effect, it just runs rigctl every 10 seconds or so. Problably something
> > else hogging the CPU. 
> I noticed through the ps ax command that rigctl and a shell script were
> running.  Is there a reason the hamlib perl bindings aren't useful? 
> I'm sure Stephane would be interested.  I'd think that for simple TRX
> control that the Perl bindings should be useful.
I have looked at the perl bindings, but did not have the time to find
out how  it worked. Did not find proper documentation or examples 
(I only need get frequency and set frequency).
In C there is a clear description of how to use it, I could not
find one for Perl. (did not look too long though, as you probably know I
have several balls in the air at the same time (always 1 too many)). 

> My CPU load normally runs 0.00 to 0.05 at idle with 91 processes
> running at the moment.  With xtlf running it was around 0.22 or so 
> and didn't increase when TRX control was enabled, but the xtlf gui 
> becomes very slow to respond as does the response sending to cwdeamon.  
> One cwdaemon began sending, I didn't notice any problems so I think 
> cwdaemon can be excused as a source of the trouble.
Maybe the rigctl routine produces too may errors (it does with my
ORION). You could try to start rigctl in a separate window, do an 'f' 
to read the frequency and leave it open. In my case it helps (don't know

> > Oh well, it keeps me busy so I don't get funny idaes :)
> We gotta keep you focused!  :-D
> > Does the effect go away when you stop TRX control?
> Yes.
This looks like rigctl produces an error and waits for a timeout, it is
called in the main (timer watch) loop. I will try adding an ALRM to
limit time if it sits in there too long.

BTW, if you tell me what perl binding stuff to use I will include it (we
are in the middle of testing the 5-band scanning function of pskmail at
the moment).

73, Rein PA0R
> 73, de Nate >>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]