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

[Ervin Hegedüs - HA2OS]

Hello Thomas,

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>:
> 
> > Note, these are just proposals, may be these aren't bugs.
> > 
> > * point calculating
> >   At last weekend I made the RAC. On RAC all VE/VA station worth
> >   10 points, any other does 2 points. My config was:
> > 
> >   COUNTRYLIST=VE
> >   TWO_POINTS
> >   COUNTRY_LIST_POINTS=10
> >   (and there is a file with name VE, which contains all canadian
> >   prefixes)
> > 
> >   but Tlf count 2 points for all stations. So I modified the
> >   src/score.c: now if COUNTRY_LIST_POINTS set up, the affected
> >   stations worth really that points, any other does what operator
> >   set it up (depends ONE_POINT, TWO_POINTS or THREE_POINTS).
> > 
> >   see 02d35a8ccb:
> >   
> > https://github.com/airween/tlf/commit/02d35a8ccb2a10144a9a0e4463258bdf5babe030
> > 
> that will need a serious look into it. The scoring logic
> (especially with COUNTRY_LIST set) is complex and somewhat fragile. The
> whole score.c needs a serious overhaul. My main concern is to get some
> test cases to make sure we do not break other contests scoring. 

well, I have seen in the source :)

My concept was very simple: if any pre-defined contest is used
(eg: cqww, arrl-dx), the one|two|three_points aren't used. I cut
that part and put it to after all of the "named" contests, and I put
it after a statement, as you can see:

   321      if (points == 0) {
   322          if (one_point == 1) {
   323              points = 1;
   324          }
   325          if (two_point == 1) {
   326              points = 2;
   327          }
   328          if (three_point == 1) {
   329              points = 3;
   330          }
   331      }

and then just the return keyword from function.

But you're right, it need to test.

Anybody can help us?

> > * getting TRX freq
> >   may be this isn't Tlf "bug", rather it affects the Hamlib. That
> > would be very good if anybody could to test it. My TRX is a Kenwood
> >   TS-850SAT, it has 2 VFO. When I start the Tlf, it reads the
> >   current freq from TRX, and shows it. If I switch the another
> >   VFO, Tlf doesn't follow that, still shows the freq of another
> >   VFO, which was the current when Tlf started.
> > 
> >   Now I modified the source, Tlf always get the actually VFO,
> >   which really the current in TRX, and get that freq.
> > 
> Very well. That was on my todo list for some time also but not with
> priority. I will pick it up for the master branch shortly.

thanks,
 
> By the way did you find out why VFO_CURR did not use the current vfo
> but the one who was active when tlf started?

no, I didn't found - I've tried it with a standalone source, I
test it only this feature, but my rig produced this result.

Therefore I asked you (Tlf users), please check this on other
rigs. May be it's a hamlib bug, but first we have to check with
others.
 
> > * handling bandwith
> >   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?

* setting up CWBANDWIDTH to an explicit value, eg 500:
  I start Tlf, working on contest, but the value which had set up
  isn't good for me; I change the filter on the rig, eg 2700 Hz. Ok,
  that's good, I'm working on. If I switch band, the filter
  switch back to 500Hz always, but I would like to use it still
  on 2700 Hz

* skip CWBANDWIDTH settings (Tlf set it up 0 as implicit):
  I start Tlf, the rig filter switched to the lower bandwith,
  which is 270Hz in my case. I switch to that which is good for me,
  eg 500Hz, or 2700Hz. Every time when I change band, the filter
  switches to 270Hz.

That's a little bit annoying, there isn't any option to keep the
choice to operator, which filter should use.
 
> >   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.

That's no problem, therefore raised this problem and solution :)

> Normally you use some bandwidth setting for a contest as you find it
> useful.

How? Set it up in logcfg.dat? Then Tlf always switch to back to
that value, if you change band (and important: if the detection
of VFO is working, and you change the VFO, Tlf also switch back
to the value which had been set).

Or skip the CWBANDWIDTH settings? Then Tlf (or hamlib?) set the
lowest bandwidth filter (on my rig).

> 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?

To keep the decision which bandwidth should use. You wrote
"sometimes", but I would like to keep it with me. :)

> 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.

yes, you absolutely right. But now the 0 has a special meaning
(in source there is RIG_PASSBAND_NORMAL macro, but in hamlib it's
defined as "s_Hz(0)", so I think that mean the lowest value of
filters), so I didn't know how do I handle.

The problem is with this solution, the hamlib's rig_set_mode()
function need the bandwith value, you can't ignore it, and you
can't pass it any free value which does not have effect.

If you take a look the file src/gettxinfo.c:

   174                  if (trxmode == SSBMODE) {
   175                      if (freq < 14000.0)
   176                          retval =
   177                              rig_set_mode(my_rig, vfo,
   178                                           RIG_MODE_LSB,
   179                                           RIG_PASSBAND_NORMAL);

and that's used in many lines (totally 18).

As you can see, the rig_set_mode() is used to switch the RIG
mode, eg. CW to USB/LSB, or back, because Tlf check the band, and
looking the mode which had been set by the operator.

How should you handle in that case, that you describe above
(CWBANDWIDTH=0), which value should be passed to rig_set_mode()?

If you skip the using of rig_set_mode() in case of CWBANDWIDTH=0, you
will drop that feature above.

Hope this can help to clear my problem, or we can find together any
solution :)


Thanks, 73:


Ervin
HA2OS


> 
> 73, de Tom DL1JBE
> 
> > 
> >   see ae60e8e44c:
> >   
> > https://github.com/airween/tlf/commit/ae60e8e44cf2b2a2ae9b027dc90c6566f4370f91
> > 
> > 
> > So, that's all currently, please check it out, especially the VFO
> > swith problem - may be other rig isn't affected. And may be all
> > of the above is just my reasoning :)
> > 
> > 
> > 73,
> > 
> > 
> > Ervin
> > HA2OS
> > 
> > 
> 
> 
> 
> -- 
> "Do what is needful!"
> Ursula LeGuin: Earthsea
> --
> 
> 
> _______________________________________________
> Tlf-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/tlf-devel

-- 
I � UTF-8