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

[Hegedüs Ervin]

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 <address@hidden>:
> 
> >   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