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

[Thomas Beierlein]

Hi Ervin,


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. 

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

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?


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

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

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