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 _______________________________________________ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
