tlf-devel
[Top][All Lists]
Advanced

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

Re: [Tlf-devel] WARC bands - fixed


From: Ervin Hegedüs
Subject: Re: [Tlf-devel] WARC bands - fixed
Date: Sun, 2 Mar 2014 08:37:22 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Hello Zilvinas,

On Sat, Mar 01, 2014 at 11:38:52PM +0200, Zilvinas, AUGMA wrote:
>  1.2.0
> 
> Here's rigctld -vvvvv  after running tlf -v -d (otherwise I can't
> force tlf to use hamlib)
> After setting 1400000 (tlf diagnostic?)

yes, now I just checked the code, and if you start Tlf with "-d",
then a routine is called, which set the freq to 1400000.

>  tlf tries to get currVFO ?

yes, Tlf, tries to determine the current used VFO on RIG.
 
> Connection opened from 127.0.0.1:46843

which version are you using?

I'm using this:
address@hidden:~$ rigctl -V
rigctl, Hamlib 3.0~git

> rigctl(d): 'currVFO' '' '' ''
> rigctl(d): v 'currVFO' '' '' ''
> rigctl(d): v 'currVFO' '' '' ''
> rigctl(d): f 'currVFO' '' '' ''
> ft857: cache timed out (111633 ms)
> write_block(): TX 5 bytes

here is my output through rigctlD(!):

Opened rig model 209, 'TS-850'
Backend version: 0.8.1, Status: Beta
Connection opened from 127.0.0.1:58289
rigctl(d):  'currVFO' '' '' ''
rigctl(d): v 'currVFO' '' '' ''
kenwood_get_vfo_if called
kenwood_get_if called
kenwood_safe_transaction called
kenwood_transaction called
kenwood_transaction: cmdstr = IF
write_block(): TX 3 bytes
0000    49 46 3b                                            IF;            

there isn't any timeout.

I get this result through rigctlD and Tlf directly too.

I think in this case the problem is in hamlib code (hamlib handle
the different requests by different codes, there are many
modell-specific function - a few weeks ago I found a bug in TS850
code (it affects some other Kenwood models), so, it can be
easily...)

> ***************************this is the place where's tlf IMHO opens
> main screen********************
> rigctl(d): v 'currVFO' '' '' ''
> rigctl(d): v 'currVFO' '' '' ''
> rigctl(d): v 'currVFO' '' '' ''
> rigctl(d): v 'currVFO' '' '' ''
> rigctl(d): v 'currVFO' '' '' ''
> rigctl(d): v 'currVFO' '' '' ''
> rigctl(d): v 'currVFO' '' '' ''
> rigctl(d): v 'currVFO' '' '' ''
> rigctl(d): v 'currVFO' '' '' ''
> 
> So no 'f's and hence no FREQ on tlf....

hmm...
 
> If I try to connecto to rigctld
> rigctl -m 2
> Rig command: v
> get_vfo: error = Feature not available

here is my result (rigctl with model 2 through rigctld):

address@hidden:~$ rigctl -m 2 -r localhost 

Rig command: v
VFO: VFOB

Rig command: f
Frequency: 21367000


> Maybe this the answer why tlf at first run tries to get vfo - get's
> 'Feature not available' and quits at once.

yes, it's very likely - but that's not Tlf bug. 

I'll try to see the hamlib's code, but I'm not sure I can fix
that. May be you have to try to upgrade the hamlib's code to the
newest version.

So, usually that codes what I help to develop, I'm using that
from source, not from the maintainer's package. I don't know
which hamlib version is in Mint 13, but may be you could try the
hamlib SF's version:

http://n0nb.users.sourceforge.net/

Then you need to recompile all of that applications, which uses
hamlib. If that's just one (Tlf), may be that's not too
unpleasant, but if you use other hamlib depend codes, that's not
a good solution...



73,

Ervin
HA2OS

-- 
I � UTF-8



reply via email to

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