Hello Thomas, hello Nate, a few days ago I sent a patch to Nate (through this list) for hamlib, to fix this bug in case of Kenwood rigs. May be he will merge...
But I think the original problem will not solved with this, namely I would like to keep untouched my filter state, when I switch band/VFO. You _must_ to pass an explicit value to rig_set_mode() as 4th argument, which is the filter width value. That mean if you call that function, that set the state of filter - except if you pass that value what actually set up. 73, Ervin HA2OS On Sun, Jan 05, 2014 at 01:54:33PM +0100, Thomas Beierlein wrote: > Hi Ervin, hi Nate, > > I think you both have your points.... > > > RIG_PASSBAND_NORMAL is defined as a special coded width value. Every > rig should interpret that value as 'use the defined _normal_ bandwidth > for that mode. As it seems that there are backends which misses these > behavior I think the problem could be solved at a higher layer, namely > in src/rig.c. > > In the code for the rig_set_mode function the width parameter should be > checked against 'RIG_PASSBAND_NORMAL' and then replaced by the value > from rig_passband_normal() before calling the back end code. What do you > think? > > > > Am Fri, 3 Jan 2014 11:06:54 +0100 > schrieb Ervin Hegedüs - HA2OS <airw...@gmail.com>: > > > > > 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. :) > > > Right you are. By design hamlib is not able to simply switch mode > without requesting a bandwidth setting. We could not even ask the > actual bandwidth with a rig_get_mode() before as the rig may be in an > different mode (say SSB) when asked and then we want to switch to CW > but not width the SSB bandwidth. > > > Btw Nate, from our problems here I would suggest for the new API v3 to > have function calls to get/set the mode and the bandwidth separately. > > 73, de Tom DL1JBE > > > -- > "Do what is needful!" > Ursula LeGuin: Earthsea > -- > -- I � UTF-8 _______________________________________________ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
