Hello Thomas, and everyone, On Mon, Dec 30, 2013 at 07:42:41PM +0100, Thomas Beierlein wrote: > Am Mon, 30 Dec 2013 11:40:02 +0100 > schrieb Ervin Hegedüs - HA2OS <airw...@gmail.com>: > > > Tlf has a config directive: CWBANDWIDTH. If that setting up, > > Tlf always set the RIG filter to that value, which is a bit > > confusing. > > Why do find it confusing? If you request a bandwidth you get it (if > supported). Can you plaese tell about your problem here? > > > But if it doesn't set, the Tlf through Hamlib always > > set the filter to the lowest value, that means in my case 270Hz > > (TS850 is a triple conversion superheterodyne, and it has a > > filter on 2nd and 3rd circle. In my RIG there is a 270Hz filter > > on 8.83 MHz IF, and Tlf switch to there _always_). So, if I > > switched band, my RIG always going to use the lowest filter... > > > > Now if CWBANDWIDTH isn't set, Tlf reads the value of filter by > > VFO, and keeps them always: switch between the VFO's (if the > > filters settings are different on VFO's, those keeps theirs > > values), change bands... > > I am not sure about these idea. Normally you use some bandwidth setting > for a contest as you find it useful. Sometimes you have a situation on > some bands where you temporarily want to widen (or narrowing) the > bandwidth. If you finally change the band you get your default settings > again. > What do others think about that feature? > > Maybe we should add the possibility to switch off that automatic > bandwidth resetting at all (e.g. with CW_BANDWIDTH=0). Than tlf would > accept whatever bandwidth you had set up at the rig itself.
so, a few days ago I've checked the hamlib source, and I think I found the problem. Tlf uses this function and its arguments: rig_set_mode(my_rig, RIG_VFO_CURR, RIG_MODE_LSB, RIG_PASSBAND_NORMAL) The TIG_PASSPBAND_NORMAL is a Hamlib macro, it's defined as this way: include/hamlib/rig.h: 369 #define RIG_PASSBAND_NORMAL s_Hz(0) 370 /** 371 * \brief Passband width, in Hz 372 * \sa rig_passband_normal, rig_passband_narrow, rig_passband_wide 373 */ 374 typedef shortfreq_t pbwidth_t; That means the function get it 0 as its 4th argument. In case of Yaesu rigs, that functions calls the rig_passband_normal() function, but the RIG_PASSBAND_NORMAL argument has been passed as mode, instead if frequency: src/rig.c: 1015 pbwidth_t HAMLIB_API rig_passband_normal(RIG *rig, rmode_t mode) 1016 { 1017 const struct rig_state *rs; 1018 int i; 1019 1020 if (!rig) 1021 return RIG_PASSBAND_NORMAL; /* huhu! */ 1022 1023 rs = &rig->state; 1024 1025 for (i=0; i<FLTLSTSIZ && rs->filters[i].modes; i++) { 1026 if (rs->filters[i].modes & mode) { 1027 return rs->filters[i].width; 1028 } 1029 } 1030 1031 return RIG_PASSBAND_NORMAL; 1032 } that means, there is a cycle, which search the desired mode, and set it up. (The filters structures had been declared in yeasu/ft950.c, from line 145 to 182. In Kenwood TS850, the argument passed the final function as frequency, and that handled as is: kenwood/kenwood.c: 935 static int kenwood_set_filter(RIG *rig, pbwidth_t width) 936 { 937 rig_debug(RIG_DEBUG_VERBOSE, "%s called\n", __func__); 938 939 if (!rig) 940 return -RIG_EINVAL; 941 942 char *cmd; 943 944 if (width <= Hz(250)) 945 cmd = "FL010009"; 946 else if(width <= Hz(500)) 947 cmd = "FL009009"; 948 else if(width <= kHz(2.7)) 949 cmd = "FL007007"; 950 else if(width <= kHz(6)) 951 cmd = "FL005005"; 952 else 953 cmd = "FL002002"; 954 955 return kenwood_simple_cmd(rig, cmd); 956 } 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. 73, Ervin HA2OS -- I � UTF-8 _______________________________________________ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel