tlf-devel
[Top][All Lists]
Advanced

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

Re: [Tlf-devel] Few modifications in Tlf core


From: Ervin Hegedüs - HA2OS
Subject: Re: [Tlf-devel] Few modifications in Tlf core
Date: Fri, 3 Jan 2014 11:06:54 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

Hello Nate,

On Thu, Jan 02, 2014 at 04:44:36PM -0600, Nate Bargmann wrote:
> * On 2014 02 Jan 12:34 -0600, Hegedüs Ervin wrote:
> > If that function got 0 as 'width', then that set the filter the
> > lower value... :(
> > 
> > That mean the using of RIG_PASSBAND_NORMAL is not that what the
> > author wanted.
> > 
> > 
> > I don't know, what should be the solution.
> 
> At first glance, I will say the Yaesu backend is likely doing things
> "correctly" only because it was written first.  ;)

that's what you know best :)
 
> As I see it, the backends should handle RIG_PASSBAND_NORMAL through the
> function rather than in some arbitrary method.

That's true. I looked up the source of hamlib once again, and I
think I found the way, how does hamlib handle the
RIG_PASSBAND_NORMAL value.

In case of Yaesu, the code checks the value of 'width' argument,
and if its equal to RIG_PASSBAND_NORMAL, then goes to make a
lookup to find the correct bandwidth (as Thomas wrote in his
previous e-mail, and show the dump_caps output), and set it up.

In case of Kenwood, this lookup is missing, the 'width' argument
passed as directly to kenwood_set_filter().

Now I made a fork on Github from Hamlib, and made a patch to
correct it. I checked with my TS850, and now it works
"correctly": the RIG had been switched to that bandwidth, which
is the output of rigctl dump_caps. See the patch:
https://github.com/airween/hamlib/commit/e4e7388b6dadbb8b54ba282a3f890cc3774a8ca3

(I know this isn't the hamlib list, but I ask you: the Hamlib
current source tarball is come from Github, or other place? As I
remember, I send a solution for GCC warning messages:
../include/hamlib/rig.h:535: Warning 451: Setting a const char * variable may 
leak memory.

but seems that still exists - should I send a patch for that?)


Btw: I think all of these meditation will NOT solve my
problem, namely I don't want the Tlf modify the state of filters
if I change band and/or VFO. :)


73,

Ervin
HA2OS


-- 
I � UTF-8



reply via email to

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