Re: ToDo item: switch logfile to database

[Thomas Beierlein]

Hi, see below:

Am Fri, 29 Dec 2023 03:20:05 +
schrieb Drew Arnett :

> tangent:  Variable length fields are handled easily with line
> separators delimiting records and space, comma, tab delimiting fields
> in a record.  It may be the UI (especially a TUI) where expected max
> field length may have value.  

Variable field length results in variable length of qso record.
That makes editing/updating old entries more complex. As soon as you
get a longer entry you need to make room in the file. That requires a
lot more disk activity (and a higher chance of corruption) than just do
a modification 'in place' and that is what we do at the moment.

A database has the same problem but there was much more done to
keep the data save in case of a crash.

> For example, what's the maximum length
> callsign 

TLF supports 12 or 13 characters if I remember correctly.
 
> I might expect to encounter in a contest or operating event
> where I'd use tlf?  Is there a safe maximum length to use for callsign
> length?  Prefixes and suffixes and some of those special event
> callsigns make me wonder.  Does ITU have anything to say, or is there
> no upper bound to possible callsign length?
> 

> tangent:  Internationalization... unicode text file for log certainly
> would work.  ASCII would suffice for the contests I participate in
> including CQ WW.  However, if not difficult, internationalization may
> be a nice to have for folks who would want it, but perhaps not high
> priority.  

I agree that it has no high priority for actual contesting.

The interesting part may not be the call but that someone would like
to add some comments in its non ascii language.

73, de Tom DL1JBE



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: ToDo item: switch logfile to database

[Thomas Beierlein]

 Am Thu,  28 Dec 2023 20:06:42 +0100 schrieb Christoph Berg
 :

> Re: Thomas Beierlein
> > Two points here:
> > 
> > - Journaling is easy, but to be honest TLF provides quite some
> >   robustness in that sense too. I have not heard any complies about
> >   lost data in all the years.  
> 
> Some time last year, I was auditing (well, reading) the tlf source to
> check that. There are sync() and fsync() calls in there, so it's
> probably mostly safe, but since calls that write to disk are spread
> over the code, data safety looks quite ad-hoc. If power goes out while
> the log is just being written, I'd bet there will be problems.
> 
> Switching to sqlite would get us crash safety for free since that's a
> library specifically written for that.


Sure, bad things can happen anytime. I just said 'quite robust' and not
'problem free'.

Besides the sync() calls there are some more points to make data losses
unlikely:

- The log is always kept on disk. Only a copy of it is in memory.
- The file is kept closed most of the times and opened only when adding
  a contact or correcting an entry.
- Actual file systems are often using journaling which helps also to
  some degree.

But I agree with you that using a database would make the situation
better. 

73, de Tom DL1JBE

-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: ToDo item: switch logfile to database

[Thomas Beierlein]

See answers inline.

Am Thu, 28 Dec 2023 15:39:54 +
schrieb Drew Arnett :

> Would a database store offer any useful utility?  Journaling or ? for
> robustness?  

Two points here:

- Journaling is easy, but to be honest TLF provides quite some
  robustness in that sense too. I have not heard any complies about
  lost data in all the years.

- 'useful utilites'? Sure. A database provides an extensive set of
  tools for sorting, filtering and altering datasets. Without it you
  have to write extra code for it.

  After our restructuring of the internal data representation that is
  much easier now. So the advantage of a database in that relation is
  not so big any more.

- The former discussion about a use of a database was also connected to
  the problem of the fixed log file format we inherit from TR log. 
  Main problem is the fixed size and position of all QSO fields.
  A switch to another format (e.g. a database) allows 

  a) internationalization (not sure if needed) and
  b) variable length fields (mainly for call and exchange)


> Does it implement whatever is needed for multi-logging computer
> contesting?
> 
For that you would need a distributed database. But that seems really
to be a can of worms.

73, de Tom

> Knowing the answers to questions like that for me is a homework task
> as it gets into topics I haven't studied, yet.
> 
> Drew
> n7da
> 
> On Thu, Dec 28, 2023 at 2:57 PM Alan Dove  wrote:
> >
> > Hey, folks:
> >
> > I'm opposed to having TLF rely on a database. It adds complexity and
> > failure points, and shouldn't be necessary for any forseeable
> > contest log.
> >
> > Users who want a tool to collect QSOs from multiple contests for
> > analysis, DXCC tracking, and so forth should use a separate
> > application. CQRLog does all that and more, and also exemplifies the
> > kinds of support problems a database can add - just browse through
> > the CQRLog forums for tales of woe from users who can't get the
> > database connection working properly.
> >
> > Networking should definitely be a higher priority.
> >
> > --
> >  --Alan
> >
> > Alan Dove, Ph.D.
> > alandove.com
> > 917.273.0544
> >
> >
> >  
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: ToDo item: switch logfile to database

[Thomas Beierlein]

It is true that the mentioned use of an external database adds some
complexity and problems. These data bases are well equipment for
handling LARGE number of data elements (e.g. your whole qso history as
in case of CQRLog).

What we discussed for TLF was mostly the use of an sqlite database
which would be an integral part of TLF. That makes maintenance much
easier. Additionally a contest log has much less number of database
elements - as long as you do store only a single contest in each of it.

As an interesting sidenote you will also find a database at the heart
of the widely used N1MM logger. Here it seems not a problem for anyone.

Anyway I agree with Alans remark about using a separate tool for doing
statistics on your contest data. 

73, de Tom

Am Thu, 28 Dec 2023 09:56:44 -0500
schrieb Alan Dove :

> Hey, folks:
> 
> I'm opposed to having TLF rely on a database. It adds complexity and
> failure points, and shouldn't be necessary for any forseeable contest
> log.
> 
> Users who want a tool to collect QSOs from multiple contests for
> analysis, DXCC tracking, and so forth should use a separate
> application. CQRLog does all that and more, and also exemplifies the
> kinds of support problems a database can add - just browse through the
> CQRLog forums for tales of woe from users who can't get the database
> connection working properly.
> 
> Networking should definitely be a higher priority.
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: ToDo item: switch logfile to database

[Thomas Beierlein]

Hi Marcin,

the move to a database representation of the log file was discussed
some month ago. It got some pro and con arguments. 

Therefore there was no final decision to implement it. For the time
being we will stay with the actual log file format.

Seems we missed to drop it from the ToDo list. Sorry.

73, de Tom DL1JBE

Am Wed, 27 Dec 2023 17:20:59 +
schrieb Marcin SP6MI :

> Hi,
> does anyone already started this todo item? If not then I think I can
> start at least some work on database structure and basic db
> operations. From my perspective sqlite is all what we need. As
> starting point I can add creation of database file, create table if
> not exists, adding, removing and editing records in db. Of course
> opening existing db is on the list
> 
> Thanks
> Br
> Marcin SP6MI
> 
> Wysłano z bezpiecznej poczty e-mail [Proton Mail](https://proton.me/).


-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Trouble building on Slackware64-15.0

[Thomas Beierlein]

Hi Brian,

Hamlib changed the name of the macro around hamlib-4.3 od 4.4.
You have to replace FILPATHLEN by HAMLIB_FILPATHLEN.

Afterwards tlf-1.4.1 should compile fine.

But better have a look at https://github.com/Tlf/tlf and pick up the
actual development version. There is quite a lot of new features and
solved bugs in the master branch there.

Make sure to read the INSTALLATION hints.

73, de Tom DL1JBE


 Am Sun, 15 Oct 2023 11:51:57
-0400 (EDT) schrieb kb3...@comcast.net:

> Hello,
>  
> I am attempting to build tlf-1.4.1 on Slackware64-15.0 with Hamlib
> 4.5.4 and get the below error: 
>  CC   sendqrg.o
> sendqrg.c: In function ‘init_tlf_rig’:
> sendqrg.c:103:13: error: ‘FILPATHLEN’ undeclared (first use in this
> function) 103 | FILPATHLEN - 1);
>  | ^~
> sendqrg.c:103:13: note: each undeclared identifier is reported only
> once for each function it appears in make[2]: *** [Makefile:647:
> sendqrg.o] Error 1 
>  
> I believe I have all of the dependencies installed:
>  
> autoconf-2.69
> glib2-2.70.3
> hamlib-4.5.4
> ncurses-6.3 (libtinfo)
> xmlrpc-c-1.33.16
>  
> I installed Debian 12 in VM and can build successfully so I am trying
> to figure out what I am missing on Slackware64-15.0.  Debian 12 has
> some newer versions of the autoconf, glib2, and ncurses packages than
> Slackware64-15.0. Thank you for any assistance that can be provided
> to resolve the compile issue! -Brian, KB3ORR



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Color changes

[Thomas Beierlein]

Am Tue, 11 Apr 2023 20:04:24 +0200
schrieb Martin Kratoska :

> Yes, I played a lot with Xresources but there is not a solution. For
> the better visibility to my old eyes I need simply to replace the
> "bright" cyan color with bright red color. That's all. I am looking
> into the source code where to change this single color. Cyan sucks!
> Otherwise the color scheme is excellent, ensuring low fatigue to my
> eyes, the cyan color is the ONLY problem...

See src/bandmap.c function 'colorize_spot()' around line 550.
The actual colors for the CB_... color pairs gets initialized in
'bm_init()' in the same file around line 193.

73, Tom DL1JBE
> 
> Unfortunately I am not a programmer. (Interested who I am? See 
> https://www.qrz.com/db/ok1rr). I don't find any joy in the sources
> etc. I go there if I must, if there is no other possibility. I am
> just an operator, I highly enjoy the ease to operate the tlf (the
> best of all contesting software overall!). I use tlf where I can,
> also where I don't need to observe my score, mults etc. online, so I
> can use tlf in most contests, although I have more painful work with
> the adjudicating if the contest has no direct support in tlf.
> 
> I see this list is one of low attendance. I posted my comments on the 
> color scheme on Mar. 31, first response came from Zoltan on Apr. 10.
> Can I do something for faster response? Some of my requests remained 
> unanswered which indicated that tlf is a matter of low importance to 
> most list members.
> ---
> My sincere apologies for my previous criticism. It is a result of 
> "fatal" lack of Linux contesting software. Thank you for your
> friendly tollerance of my impatience, TNX!
> 
> 73,
> Martin, OK1RR
> 
> 
> Dne 11. 04. 23 v 4:32 Nate Bargmann napsal(a):
> > Terminals are set up in interesting ways.  If you're using Xterm or
> > rxvt, then there is an X Resources file in the TLF repository that
> > sets the colors to mimic those of the Linux console withe a VGA
> > color scheme.
> > 
> > Perhaps this post will help:
> > 
> > https://www.n0nb.us/blog/2020/02/coping-with-color-on-the-linux-console-and-xterm-and-friends/
> > 
> > If you're using the terminal from a desktop environment, then
> > setting the actual colors will vary with the terminal at hand.  I
> > use Xterm (UXterm, actually for UTF-8) with the VGA color palette.
> > 
> > 73, Nate
> >   
> 
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: TLF 1.5~git - BUG in FOC Marathon

[Thomas Beierlein]

Hi Martin,

just found time to check your observations. I can not confirm
your problems.

Can you please double check that you downloaded and installed the code
from the link below?

https://github.com/dl1jbe/tlf/tree/fix_focm

The main repo still contains the bug.

I just just did some tests. See the log below:

marathon.log:
 20CW  15-Feb-23 11:55 0001  DF2IC  599  599  1624  1  14025.0
 40CW  15-Feb-23 11:55 0002  DJ5ZN  599  599  1145  1   7010.0
 40CW  15-Feb-23 11:55 0003  OK1RR  599  599  1437  1   7010.0
 20CW  15-Feb-23 11:55 0004  DF2IC  599  599  1624  0  14025.0

I stopped TLF and restarted it after the third entry. So you can see
that the exchange is kept.

The cabrillo file looks as follows (and should be as expected).

DL1JBE.cbr
START-OF-LOG: 3.0
CREATED-BY: tlf-1.5~git
X-CREATED-ON: 15-Feb-23 at 11:57z
CONTEST: focmarathon
CALLSIGN: DL1JBE
CATEGORY-ASSISTED: assisted
CATEGORY-BAND: all
CATEGORY-MODE: cw
CATEGORY-OPERATOR: single-op
CATEGORY-POWER: high
CATEGORY-STATION: fixed
CLAIMED-SCORE: 12
LOCATION: DX
NAME: 
ADDRESS: 
OPERATORS: 
QSO: 14025 CW 2023-02-15 1155 DL1JBE599    DF2IC 599 1624  
QSO:  7010 CW 2023-02-15 1155 DL1JBE599    DJ5ZN 599 1145  
QSO:  7010 CW 2023-02-15 1155 DL1JBE599    OK1RR 599 1437  
QSO: 14025 CW 2023-02-15 1155 DL1JBE599    DF2IC 599 1624  
END-OF-LOG:

So please double check and try again.

73, de Tom DL1JBE

 Am Sat, 11 Feb 2023 22:32:17
+0100 schrieb Martin Kratoska :

> The tlf behaviour for FOC Marathon is still suspicious. Log seems now
> OK: 10CW  11-Feb-23 18:48 0001  G5VZ   599  599  2191  1
> 28025.0 15CW  11-Feb-23 18:49 0002  G5VZ   599  599  2191
>  1  21025.0 20CW  11-Feb-23 18:49 0003  G5VZ   599  599  2191
>  1  14025.0 40CW  11-Feb-23 18:49 0004  G5VZ   599  599
> 2191  1   7010.0 80CW  11-Feb-23 18:50 0005  G5VZ   599
> 599  2191  1   3525.0
> 
> but the resulting Cabrillo not - the membership numbers not present.
> 
> START-OF-LOG: 3.0
> CREATED-BY: tlf-1.5~git
> X-CREATED-ON: 11-Feb-23 at 18:59z
> CONTEST: CWT
> CALLSIGN: OK1RR
> CATEGORY-ASSISTED: ASSISTED
> CATEGORY-BAND: ALL
> CATEGORY-MODE: CW
> CATEGORY-OPERATOR: SINGLE-OP
> CATEGORY-POWER: HIGH
> CATEGORY-STATION: FIXED
> CATEGORY-TRANSMITTER: ONE
> CATEGORY-OVERLAY: TB-WIRES
> CERTIFICATE: DX
> CLAIMED-SCORE: 55
> GRID-LOCATOR: JO70FB
> NAME:
> ADDRESS:
> OPERATORS:
> QSO: 28025 CW 2023-02-11 1848 OK1RR 599 0001   G5VZ 
>  599
> QSO: 21025 CW 2023-02-11 1849 OK1RR 599 0002   G5VZ 
>  599
> QSO: 14025 CW 2023-02-11 1849 OK1RR 599 0003   G5VZ 
>  599
> 
> Such file is useless.
> 
> Also he program itself shows that after leaving and new start the 
> membership numbers disappearing.
> 
> The bug is still present.
> 
> 73,
> Martin, OK1RR



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: TLF 1.5~git - BUG in FOC Marathon

[Thomas Beierlein]

Problem found. Due to a missing width for the exchange field the former
entries got ignored after restart.

You can test the corrected code from 
https://github.com/dl1jbe/tlf/tree/fix_focm

I set the input field width to 5 characters max. If there is more room
needed please say so.

73, de Tom DL1JBE


 Am Sat, 4 Feb 2023 11:32:18 +0100
schrieb Thomas Beierlein :

> Thanks for the report. We will look into it.
> 
> Checking my old test logs from 2014 the old log file is correct. So it
> seems something happened in meantime.
> 
> 73, de Tom DL1JBE
> 
> Am Fri, 3 Feb 2023 10:51:12 +0100
> schrieb Martin Kratoska :
> 
> > Just before the event I found a bad bug - when I leave the program
> > and start it again, the exchange (FOC number) disappears. It is also
> > not in the resulting ADIF file, not in the log file.
> > 
> > The log file looks so:
> > 
> >   40CW  03-Feb-23 09:39 0001  DJ5CW  599  599 
> >   1   7030.0
> >   20CW  03-Feb-23 09:39 0002  DJ5CW  599  599 
> >   1  14025.0
> >   15CW  03-Feb-23 09:39 0003  DJ5CW  599  599 
> >   1  21025.0
> >   10CW  03-Feb-23 09:40 0004  DJ5CW  599  599 
> >   1  28025.0
> >   80CW  03-Feb-23 09:40 0005  DJ5CW  599  599 
> >   1   3525.0
> > 160CW  03-Feb-23 09:40 0006  DJ5CW  599  599 
> >  1   1830.0
> > 
> > which is insufficient.
> > 
> > I must use TR4W in wine this year...
> > 
> > 73,
> > Martin, OK1RR
> >   
> 
> 
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: TLF 1.5~git - BUG in FOC Marathon

[Thomas Beierlein]

Thanks for the report. We will look into it.

Checking my old test logs from 2014 the old log file is correct. So it
seems something happened in meantime.

73, de Tom DL1JBE

Am Fri, 3 Feb 2023 10:51:12 +0100
schrieb Martin Kratoska :

> Just before the event I found a bad bug - when I leave the program
> and start it again, the exchange (FOC number) disappears. It is also
> not in the resulting ADIF file, not in the log file.
> 
> The log file looks so:
> 
>   40CW  03-Feb-23 09:39 0001  DJ5CW  599  599 
>   1   7030.0
>   20CW  03-Feb-23 09:39 0002  DJ5CW  599  599 
>   1  14025.0
>   15CW  03-Feb-23 09:39 0003  DJ5CW  599  599 
>   1  21025.0
>   10CW  03-Feb-23 09:40 0004  DJ5CW  599  599 
>   1  28025.0
>   80CW  03-Feb-23 09:40 0005  DJ5CW  599  599 
>   1   3525.0
> 160CW  03-Feb-23 09:40 0006  DJ5CW  599  599 
>  1   1830.0
> 
> which is insufficient.
> 
> I must use TR4W in wine this year...
> 
> 73,
> Martin, OK1RR
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: tlf wrong keying

[Thomas Beierlein]

Hi dear OM,

it looks like you use the standard rules for CQWW but need a
personalized rule file.

The default rules for CQWW are defined in  /usr/share/tlf/rules/cqww (or
/usr/local/share/tlf/cqww depending on your installation).

Please prepare a directory for the contest (e.g. 'cqww2023') with
another 'rules' directory inside. Copy into that 'rule'-directory the
mentioned cqww file and edit it to your need. You should especially
look for a line

F3=@ ++5NN-14

and change the '-14' into a '-16'. Write the file to disk and start TLF
again from the 'cqww2023' directory. That should do it.

73, de Tom DL1JBE


Am Tue, 03 Jan 2023 21:09:47 +0300
schrieb Alexej :

> Hello!
>  
> just searching soft for contest and look on tlf
> but…
> tld cqww simulation
> my callsign is R2DEX 
> when i type it as receive — tlf wrote to me CQzone 16
> when i transmit — cwdaemon keying 14! 
>  
> this is copy part of .paras from cqww-test folder
> R2DEX
> # Messages  F1...F12 -
> CQ DE % TEST
> @ DE %
> @ ++5NN–14
>  
> BUT! when tlf is starting all looks good!
>  
> Log file not found, creating new one
> CW-Keyer is cwdaemon
> Reading logfile... 
>      Call = R2DEX
>      My Zone = 16     My Continent = EU
>  
>  
> cty.dat cty.csv up to date! 
>  
> best 73! 
>  
> ---
> R2DEX
> rk3...@mail.ru
> JID: z...@jabber.ru
> --... ...--


-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: What is the tlf future?

[Thomas Beierlein]

Hi Nate and others,

let me fill in some minor notes from my side,

Am Fri, 14 Oct 2022 13:14:11 -0500
schrieb Nate Bargmann :


snip

> 
> Having dabbled with porting a GTK program from GTK 2 to GTK 3 I have
> come to appreciate that GUI toolkits are not not for the faint of
> heart. 
Similar experience here.

> So, for a general cross-platform GUI
> toolkit there are really just two choices that I am aware of, Qt and
> Fltk.  Both are C++ libraries so writing code in C is pretty much out
> of the question (perhaps I am wrong here) and so coding must happen
> in C++.  Is it possible for a mortal hobbyist programmer to work in
> C++ effectively? With its templates and other additions to its more
> recent standards, I decided that my time was better spent in code
> much more simple.

For the point of using FLTK or Qt for GUI that is doable. There are
ways to mix C++ and C code. 


snip


> 
> The code in TLF is difficult to understand and follow in part because
> of NCurses calls scattered throughout the code.  Historically TLF has
> not been implemented in an MVC design, as I understand MVC which may
> be wrong.  

True. We have invested quite some time to untangle the tight web and I
think it got better in last time. But sure, there is still quite some
work to do.


> Most programmer hams have probably taken a look at the TLF
> code base and been scarred for life!  No, it's not that bad but it is
> typical of hobbyist projects where the primary object is writing code
> and adding features.  

From a technical point of view there is not only the Ncurses TUI which
makes the code difficult to handle. Further points are:

- Internal information was (and still is) stored in a lot of global
  variables which are accessed from everywhere without no encapsulation.
  As the historical naming of some of them is not really intuitive it
  takes some time to got an understanding what a variable is used for
  and where it is used (and changed).
 
- Quite a lot of information was handled as strings and gets converted
  back and forth. As C is no good in safe string handling that was a
  source of a lot of run time errors ( It even led to the point that
  Tlf could no longer be build in around 2008 because of buffer
  overruns everywhere).

While the problems are not solved completely there was a lot of work
in the last years to add data structures, pass data by parameter to and
from functions and to move away from and/or to safer string handling.

So TLF has a much more manageable code base now compared to some years
ago. But let us not forget - part of the complexity comes also from the
broad range of functionality TLF has to handle.

> While I have contributed to TLF I am just a
> small contributor compared to Tom, Zoli, and others who understand it
> much better than me.

And thanks again for all that contributions.

73, de Tom





-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: How to add a contest?

[Thomas Beierlein]

FOC MARATHON got added on your request back in 2014.
Just set 'RULES=focmarathon' in logcfg.dat. See also 'focmarathon' file
in rules directory.

73,
de Tom DL1JBE

Am Sat, 8 Oct 2022 05:52:34 +0200
schrieb Martin Kratoska :

> Some contests can't be added simply by modifying the GENERAL QSO 
> configuration. There are two as an example:
> 
> Memorial OK1WC (MWC) - a very fast, 1 hour CW event which is highly 
> popular here in EU. It uses mults last character of worked station
> call suffix.
> 
> FOC MARATHON - no mults but a bonus based on bands where the station
> was worked.
> 
> How and where can be these contests added?
> 
> 73,
> Martin, OK1RR
> 
> 
> 
> 
> ==
> 
> Detailed rules
> 
> ==
> Memorial OK1WC (MWC)
> 
> Mode:CW
> Bands:80, 40m
> Classes:Single Op All Band (QRP/Low)
> Single Op Single Band (QRP/Low)
> Max power:LP: 100 watts
> QRP: 5 watts
> Exchange:RST + Serial No.
> Work stations:Once per band
> QSO Points:1 point per QSO
> Multipliers: Each last character of worked station call suffix once
> per band
> Score Calculation:Total score = total QSO points x total mults
> 
> ==
> FOC MARATHON
> 
> BANDS:  160, 80, 40, 20, 15, 10m.
> 
> SECTIONS:
> 
> QRO Open: Full licenced power on all bands with no antenna
> restrictions. Low Restricted: Output power limited to 100w, simple
> wire and vertical antenna only (no  beams).
> QRP Open: Output power limited to 5w with no antenna restrictions.
> QRP Restricted:  Output power limited to 5w with simple wire and 
> vertical antennas only (no beams).
> 
> EXCHANGE:  RST and membership number.
> 
> CONTACTS:  One QSO point for each member worked per band.
> 
> NO MULTIPLIERS!
> 
> BONUS POINTS:
> 
> Five points for the first contact with each continent - AF, AS, EU,
> OC, NA, SA. (30 max)
> Two points for the first contact with each country (DXCC).
> Ten points for contacts on five bands with a member.
> Five additional points for a contact on a sixth band with that member.
> The UK based HQ station - G4FOC (GM4FOC, GD4FOC etc.) or an
> alternative notified call, scores double points for contacts and
> five/six band bonus points.
> 
> TOTAL SCORE =
> 
> Total members worked plus...
> Total entities worked X 2 plus...
> Total continents worked X 5 plus...
> Total 5 band contacts X 10
> Total 6 band contacts X 5
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Re-sending a serial in S&P mode

[Thomas Beierlein]

Just added an issue on https://github.com/Tlf/tlf/issues/332
to keep track of the problem.

73, de Tom

Am Mon, 23 May 2022 21:23:59 +0200
schrieb Csahok Zoltan :

> Yes, underscore (_) is unfortunately hardcoded to send
>
> no matter how F3 or S&P_TU_MSG is configured.
> One more issue to be fixed...
> 
> Maybe sending the last F3/S&P_TU_MSG except its first word (normally
> @ or TU) could work.
> 
> 73,
> Zoli
> 
> On Sat, May 21, 2022 at 11:00:25PM +0100, Nick Craig-Wood wrote:
> >Press underscore _ is the thing to do.
> >I haven't figured out how to configure this though. It always
> > sends 5NN serial even if the exchange is more complicated, eg 5NN
> > serial name.  
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Fix sending cluster spots

[Thomas Beierlein]

Koos, Alan,

thanks for the feedback so far.

73, de Tom

Am Fri, 25 Mar 2022 21:41:56 +0100
schrieb Koos van den Hout PE4KH :

> On 3/25/22 20:22, Thomas Beierlein wrote:
> 
> > I would further suggest the following behavior:
> > 
> > * TLF prepares the string 'DX freq call ' and allows to add an
> > comment. That is the standard cluster message you have to send.  
> 
> Would it be an idea to have an optional default comment like the name
> of the contest?
> 
> While thinking about this I'm pondering whether this would make
> spotting everything you work 'too easy', leading to loads of spots
> from one station (although the dx clusters can be quite busy during
> contests anyway).
> 
> > * Ctrl-B should mainly work from 'S&P' mode. I think it will not
> > make much sense when in 'Run'.  
> 
> Logical choice.
> 
> > * If call input field is set and transceiver online it should send
> > out the DX spot based on teh actual data, but keep the call input
> > field filled.
> > * If call input field is empty (because you just had worked the
> >station) Ctrl-B will use the last logged QSO data.  
> 
> Also logical.
> 
> > Open questions:  
> 
> > * Should Ctrl-B work from call input and from exchange field?  
> 
> I'd say yes, due to the following scenario: you hear a rare station
> and that station doesn't hear your reply even after a number of
> tries, so your cursor is on the exchange field. You hope others can
> work that station so you want to spot it.
> 
> Koos PE4KH
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Fix sending cluster spots

[Thomas Beierlein]

Hi all,

I would like to continue with the discussion how to fix the non
working Ctrl-B (send spot to cluster) function.

Some first feedback went in favor of the following:

 Am Tue, 1 Mar 2022 19:31:02 +0100
schrieb Thomas Beierlein :

> c) Let Ctrl-B format the cluster message, but show it to the user and
>   allow editing before the message gets send (Flexible but would need
> at least a second key press - enter - besides Ctrl-B for just sending
> the spot.)

I would further suggest the following behavior:

* TLF prepares the string 'DX freq call ' and allows to add an comment.
  That is the standard cluster message you have to send.
* You can stop the sending of the cluster message by pressing ESC
  instead of the Enter key above.
* Ctrl-B should mainly work from 'S&P' mode. I think it will not make
  much sense when in 'Run'.
* If call input field is set and transceiver online it should send out
  the DX spot based on teh actual data, but keep the call input field
  filled. 
* If call input field is empty (because you just had worked the
  station) Ctrl-B will use the last logged QSO data.

Open questions:

* Shall we support entering frequency by hand if no rig is active like
  we do it for Ctrl-A?
* Should Ctrl-B work from call input and from exchange field?

Please give feedback if I overlooked something or if you like a
different behavior. I will try to prepare a first working version in
next days.

73, de Tom DL1JBE

-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: TLF logger, countrylist file format?

[Thomas Beierlein]

Hi Gerard,

just some words before I am away:

Am Fri, 4 Mar 2022 07:02:21 +
schrieb Gerard van Antwerpen :

> Hi Tom,
> I tried to add the beru: to the start of the file, and it gets read
> now (I also think it needs to be in the main contest directory, not
> the one with the rules in it), however I am getting the following
> error message:
> 
> +++
>Welcome to tlf-1.4.0 by PA0R!!
> 
...
> Reading contest rules file: rules/beru*** buffer overflow detected
> ***: terminated Aborted
> +++

That is a bug we have to fix and it is thanks to the long line which
TLF does not handle properly.

> It is a long list of countries, but trimming it back doesn't help.
> Putting a short country list in the rules file does get read, but
> doesn't seem to affect scoring, all contacts are given 5 points (as I
> set with CWPOINTS=5), and also points for my call area while I set
> MY_COUNTRY_POINTS=0
> 
Please drop the CWPOINTS and SSBPOINTS setting and use
COUNTRY_LIST_POINTS=5 instead.

73, de Tom DL1JBE

> 
> No panic, as I'm not relying on it for scoring points, it'd be nice
> to get it working though. Thanks,
> Gerard, ZL2GVA
> 
> 
> 
> From: Thomas Beierlein 
> Sent: Friday, March 4, 2022 10:14 AM
> To: Gerard van Antwerpen 
> Subject: Re: TLF logger, countrylist file format?
> 
> Hi Gerard,
> 
> I think there is one piece of information missing from the
> documentation:
> 
> You have to start the line of countries with the name of the actual
> contest. That means if you have a line
> 
> CONTEST=beru
> 
> in your logcfg.dat than the countrylist line should read
> 
> beru:,,.
> 
> You can put the line in a file and use
> 
> COUNTRYLIST=
> 
> or you can put the line directly into the COUNTRYLIST definition
> 
> COUNTRYLIST=beru:..
> 
> If that does not help, please send us a copy of your logcfg.dat and
> the countrylist file.
> 
> 73, de Tom
> 
> P.S. I will be away for some days starting on Saturday. So if above
> suggestions do not work please contact the other OMs at TLFs
> mailing list (tlf-devel@nongnu.org). They will be glad to give some
> more advice.
> 
> Am Thu, 3 Mar 2022 06:53:33 +
> schrieb Gerard van Antwerpen :
> 
> > Hi,
> > I haven't used TLF for logging, but trying it out to see if I could
> > use if for the upcomming BERU contest. There is a long list of
> > eligible country prefixes that are valid for getting points. It
> > doesn't fit in the config file, so I tried to make a separate
> > countrylist file. (called berucountries no extension). I used the
> > list, all on one line, comma separated, starting with colon (and
> > also tried without this). However the program doesn't seem to read
> > the list and allocates points to any call I enter. Then I tried the
> > pre-fixes each on their own line in the file, same result.
> >
> > I have got USE_COUNTRYLIST_ONLY SET, and also
> > COUNTRYLIST=berucounties
> >
> > What am I doing wrong?
> > Appreciate your help.
> > Thanks,
> > Gerard ZL2GVA
> > Gerard van Antwerpen, Blenheim, NZ
> 
> 
> 
> --
> "Do what is needful!"
> Ursula LeGuin: Earthsea
> --
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Spots Posting as "DX de TLF-A"

[Thomas Beierlein]

Hi Alan and Zoli,

Am Tue, 1 Mar 2022 19:07:34 +0100
schrieb Csahok Zoltan :

> Hi Alan,
> 
> Ctrl-A sends the spot only to other networked TLF nodes,
> hence the "de TLF-A" where "A" is the node id (1st node).
> 
> man page says:
>  Ctrl-A Add a spot to bandmap and broadcast it on the local network.

I just double checked it to be sure. That message from Ctrl-A goes only
into the internal network, but gets displayed in the cluster message
list.

The idea behind Ctrl-A is to use it either as a reminder for yourself
if you work without an external cluster or have a second station
scanning the bands while only listening and providing spots for the
main operator.

> To send to the actual cluster network Ctrl-B can be used.
> For actual spotting purpose IMO it's practically unusable as one has
> to type in a correctly formatted (raw) spot.
> On the other hand one can post with it any other kind of message,
> provided the cluster accepts it...
> 

I see three possible ways to fix that:

a) Let Ctrl-B format the cluster message and send it (we loose the
  ability for quick general cluster messages; we can still send them via
  <:packet>message<:>)
b) Have a key for sending a spot message and a key for a general
  cluster message (not sure if another key is a good idea).
c) Let Ctrl-B format the cluster message, but show it to the user and
  allow editing before the message gets send (Flexible but would need at
  least a second key press - enter - besides Ctrl-B for just sending the
  spot.)

73, de Tom





-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Documentation Updating

[Thomas Beierlein]

Hi Alan and all others,

good summary from your side. 

Am Thu, 24 Feb 2022 08:49:52 -0500
schrieb Alan Dove :

> Hey, folks:
> 
> That's an excellent point, Ervin; users coming from N1MM+ on Windows
> or Skookum on Mac may have trouble understanding the logic of TLF. It
> also fits in with something I was thinking about how we should
> organize the documentation. It seems to fall naturally into different
> categories for users in different situations:
> 
> 1. The front page (tlf.github.io): People probably land here from an
> internet search such as "linux ham contest logger." It should focus on
> TLF's main features, show what the interface looks like, and direct
> those folks to the next step. It already does this pretty well. The
> only changes I'd suggest would be a few minor edits in the top section
> and cutting most of the content from "Download and installation"
> onward
> - that information should go in the next step.

Feel free to make a pull request.

We should also replace the top image of TLF in contest by an actual
one. 
> 
> 2. The README.md for the repository (https://github.com/Tlf/tlf): This
> should be linked prominently from the front page, as the next step for
> people who want to try TLF. I'm already working on this, and intend to
> make it into a single page that covers installation, basic principles,
> and a Quick Start example. That should get newcomers up and running
> with a minimum of fuss.
> 
> 3. The Manual.md file: This will explain TLF's operation in more
> detail, and delve into detailed setup instructions for CW, RTTY, and
> SSB contests. It will also direct people to the man page and the wiki
> for answers to specific questions.
> 
> 4. The man page: When people type `man tlf`, they've already installed
> the program, probably used it a bit, and now have some specific
> question. The current man page does an excellent job answering those
> questions, and I presume it will continue to do that in future
> updates.
> 
Maybe we should think about how to keep man page and manual.md in sync
in the long run. 

> 5. The wiki: We could use the Github wiki feature to duplicate some of
> the functions of the man page, for people who haven't installed TLF
> yet or who don't like scrolling through man pages in a terminal. An
> easy place to start would be to dump the current man page into a text
> file and upload it to the wiki.

An additional use could be to use it as a place to collect user
provided contest rules, initial exchange or multiplier files. 

73, de Tom


-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Documentation Updating

[Thomas Beierlein]

Seems the ball is rolling :-). Fine.

Having the main documentation distributed with TLf in the main repo
seems sensible.

Regards Ervins idea of an additional repo I would recommend the
existing tlf.github.io for any web page related documents. These
documents are easily rendered as GH pages by github.

While the discussion at the moment goes in the direction of using
markdown I learned that asciidoc is an alternative which has a little
bit more features which may be helpful. It can just as easily converted
to text, PDF files or html pages (and can even be used to produce man
pages :-) ). See for instance the WSJT-X suite - they generate their
whole documentation that way.

Just my 2 c. But anyway, I am fine with both.
 
73, de Tom

Am Wed, 23 Feb 2022 15:12:58 -0500
schrieb Alan Dove :

> Hey, folks:
> 
> Ervin, I can't read a word of Hungarian, but I'll trust that you've
> done fine work there. I don't favor splitting the documentation into a
> separate project. Let's keep it in the main Github repository and try
> to stick with (or move things into) Markdown for the reasons already
> outlined. I'm fine with keeping the man pages separate from the
> Markdown documentation, as it does make some sense to expect people to
> use the two types of references differently.
> 
> My focus so far has been to consolidate as much of the information as
> possible into as few files as seems sensible. I've overhauled the main
> README.md and INSTALL.md, and have now created doc/Manual.md, where
> I've pasted the text from the separate files that used to be in that
> directory. I'll hold off filing a pull request until I've done at
> least one more editing pass through everything.
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Documentation Updating

[Thomas Beierlein]

Hi Alan,

Am Wed, 23 Feb 2022 09:20:52 -0500
schrieb Alan Dove :
> Hey, folks:
> 
> As a recent convert to Linux-based ham radio and TLF, I'd like to help
> a bit with the project if I can. My coding is rudimentary at best, but
> I've worked as a technical writer for over 20 years and feel I could
> probably put those skills to use on the documentation.

welcome on board. Especially with regards to documentation we could use
quite some help. Your offer is gladly accepted and highly welcomed.

Maybe I should give some starters from my point of view:

* Besides the INSTALL and README file in the project root directory
  there are some files in the doc sub directory. The most out of date
  file seems to be the doc/README file which is quite dated. Maybe we
  should drop it completely in favor of the README in the base
  directory.

* At the moment the documentation is quite scattered over the files in 
  the doc directory, the information on https://tlf.github.io and the
  copy of the old original web side at the end of that page. 

* The most actual and correct description of the different aspects of
  TLFs configuration is the man page, which should be in a good shape.

* Maybe you should fork also https://github.com/Tlf/tlf.github.com .
  It contains the source for the above mentioned web page
  (tlf.github.io) and furthermore (in 'oldmanual' subdirectory) a copy
  of the old original web page converted to asciidoc. 

Maybe that can serve as some starting points. Feel free to ask here.
Zoli, Nate and Ervin as well as others can surely give additional
information.

73, de Tom


> 
> I've forked the project on Github so I can edit the documentation and
> submit pull requests. I'm planning to start with the /doc/README file
> and work my way down from there. Please let me know if there's some
> more pressing need in the docs, or some other approach the developers
> would prefer I take. I don't want to step on any toes.
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Cabrillo Export Error

[Thomas Beierlein]

Hi Alan,

during preparation of the cabrillo file (:write) there is a first
question about the exchange you gave. What did you enter here?

It should only be the specific part without the report - that would be
'MA' in your case. 

Please check.

73, de Tom

Am Mon, 21 Feb 2022
18:37:02 -0500 schrieb Alan Dove :

> Zoli:
> 
> It's TLF 1.4.1 (I downloaded the tarball and just followed the
> instructions on the site).
> 
> > Is this the expected format?
> > QSO: 14038 CW 2022-02-19 1732 AB1XW599 MAHA8VV599 KW
> >   
> 
> Yes, that was what the ARRL bot wanted.
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: DX Cluster Setup Help

[Thomas Beierlein]

Hi Alan,

besides Ervins ideas some more information could be helpful.

- Which version of TLF?
- Maybe you could post your logcfg.dat.
- How do you start TLF?

73, de Tom

Am Thu, 17 Feb 2022 17:35:48 +0100
schrieb Ervin Hegedüs :

> Hi Alan,
> 
> On Thu, Feb 17, 2022 at 11:21:30AM -0500, Alan Dove wrote:
> > Having recently switched to Linux (from Mac) for my ham computing,
> > I'm setting up TLF and really liking it. This weekend's ARRL DX CW
> > contest should provide a good test run of it. I think I've got
> > everything working except the DX Cluster. I've tried putting a few
> > different telnet cluster addresses that I know work (I can telnet
> > into them from another terminal window) in my logcfg.dat file, but
> > none of the spots seem to show up. The :pac and : commands
> > do nothing, and :cluster brings up a frame with nothing in it.  
> 
> you should try press "." (dot) and then the "O". Is there any
> changes?
>  
> > Can someone provide a snippet of a known good logcfg.dat file, with
> > cluster configuration parameters that definitely work? I'm on Ubuntu
> > 20.04, by the way.  
> 
> I'm using dx.hu with these settings:
> 
> TELNETHOST=dx.hu
> TELNETPORT=9000
> 
> Feel free to replace the host and the port. I must work.
> 
> 
> Regards,
> 
> Ervin
> HA2OS
> 
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Xplanet works for a while then quits

[Thomas Beierlein]

Hi Jack, hi Zoli,

I agree with Zoli that you should drop the '--output
xplanet_image.jpeg' part of your command. That way you will no longer
create the massive load of old data in your Trash folder. 

By the way find below the command I use to start xplanet here:

xplanet -window -config default  -wait 4 -longitude 13
-latitude 51 -projection azimutal

73, de Tom 


Am Sat, 18 Dec 2021 09:09:31 +0100
schrieb Csahok Zoltan :

> Hi Jack,
> 
> Tlf surely does not create or move any files into a trash folder.
> Where is your trash folder located? Could you give the list of most
> recent files from it?
> (I mean "ls -ltr trash | tail")
> 
> The way Xplanet is called saves the current view in a JPG file.
> I think the typical use case would be no to save the view but rather
> to show it live on screen, i.e. omitting the -output option.
> 
> Your Xplanet command overwrites xplanet_image.jpeg each 10 second
> > xplanet -latitude 35.0 -longitude -120.00 -wait 10 -output
> > xplanet_image.jpeg -fontsize 16 -config config-TLF -geometry
> > 1200x600 -projection peters  
> unless there are further relevant options in config-TLF file.
> What is the content of config-TLF?
> 
> 
> 73,
> Zoli
> 
> 
> On Fri, Dec 17, 2021 at 09:41:33PM -0800, John Lindley wrote:
> > Tom-
> >
> > Thanks for looking at the code. Here is the xplanet command kine:
> >
> > xplanet -latitude 35.0 -longitude -120.00 -wait 10 -output
> > xplanet_image.jpeg -fontsize 16 -config config-TLF -geometry
> > 1200x600 -projection peters
> >
> > I think neither TLF or Xplanet are the problem.
> >
> > I am running Ubuntu 18.04. I start Xplanet from the gnome terminal
> > and run TLF from Xterm, and the old files from both go to trash.
> >
> > In looking at the contents of the trash folder, There are all types
> > of text files there (like logs, cabillo files, etc,) from many
> > months ago. I only use this computer in the shack. The text files
> > are small, and do not use much space. However, the xplanet images
> > are large and a new one every 10 seconds rapidly filled the folder.
> > It looks as if files have been going to trash for quite some time,
> > but were not a problem until I had lots of large files
> >
> > As I have time, I have been reviewing all the config and setup
> > files I can find but have not identified the trouble maker yet. TLF
> > works fine without xplanet, so this is not a 1st priority task.
> > Just annoying.
> >
> > Thanks for your help!
> > Jack W6YOY
> >  
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Xplanet works for a while then quits

[Thomas Beierlein]

Hi Jack,

I just had a second look how TLF handles the marker file.

There is no special magic on the work here. TLF just opens the
existing file and replaces its content - the old file gets not deleted,
no new file created.

Can you please provide the command you use to start xplanet? Maybe
anything special here.

Otherwise the only idea may be some sort of backup mechanism from the
operating system or distribution (time machine or similar). By the way
what distribution do you use?

73, de Tom DL1JBE


Am Wed, 15 Dec 2021 15:45:38 -0800 schrieb John Lindley
:

> I set up Xplanet on TLF with help from the previous entries here -
> thank you!. It works as expected for an hour or two then stops and
> will not restart. I know what is wrong, but I don't know how to fix
> it. When TLF writes a marker file or when Xplanet writes a new map
> image, the old file or image is being saved in the 'trash' folder. If
> the band is active, lots of files are written, and it eventually uses
> all the 'trash' space. I can delete these files from the trash
> directory, and Xplanet will work again for a while. I am running
> Ubuntu 18, TLF-1.4.1 and xplanet-1.3.0 I assume archiving old files
> is a 'feature' that is enabled in some set-up file, but I have been
> unable to find a file on the computer or any reference to this
> problem or such a set-up file on the web. Any help would be
> appreciated. I really like TLF. The Xplanet display is not essential
> to my use, but I like to have everything working.
> Jack W6YOY



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Hamlib keying

[Thomas Beierlein]

Hi Chris,


Am Tue, 30 Nov 2021 20:28:10 +0100
schrieb Thomas Beierlein :
> 
> > > - Sending Fx-messages does not work at all and gives no error or
> > >   warning.
> > 
> > That shouldn't make a difference and is probably a followup error
> > from the above. Do the Fx keys start by issuing a stop morse
> > command? That would explain the trouble.
> >   
> No, not really. There are also no error messages at all. Maybe it is a
> problem with my rig (TS590), so I will dig a little bit deeper myself.
> 
I just had a look into it.

1. I have to correct myself as there are error messages, but after only
after the time the message  should need for sending

2. It shows that the message strings are '\n' terminated. Seems Kenwood
does not accept that character in hamlib_send_morse() but cwdaemon and
other rigs just ignores them.

Tested with '\n' removed and the message gets send.

Let me look how to handle it best (drop newline from the message body
or filter it out during message send).

73, Tom


-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Hamlib keying

[Thomas Beierlein]

Hi Chris,

after CQWW is finished now, back to your PR. Thanks for driving it
forward.

 Am Fri, 26 Nov 2021 21:22:11 +0100
schrieb Christoph Berg :

> I finally found the time to finish this. Thanks to Nick Craig-Wood
> (@ncw) for merging his patch with this one!
> 
> Pull request: https://github.com/Tlf/tlf/pull/294
> 
> Re: Thomas Beierlein
> > > The general feature (calling stop_morse) already works, only the
> > > support in rigctld was missing.
> > >   
> > Just made some first tests (TS590S + Hamlib-4.3.1) with mixed
> > results:
> > 
> > - Sending CW per keyer window works as expected.
> > 
> > - Leaving keyer window (ESC) gives me a messsage about missing
> >   supported for stopping - first time with the default error colors
> >   (white on blue), after that only black on white.   
> 
> Hmm. Either I didn't understand the way Tlf reports errors correctly,
> or this is generally a problem. Part of the pull request is one commit
> that attempts to print better Hamlib errors.
> 
I will look into the color problem wrt TLF_INFO and friends.

> Generally, only few rigs support stopping morse sending. Mine does, so
> it wasn't a problem for me, but possibly we should catch that on
> startup, print a warning, and then just not do anything at runtime.
> 
Right, I just commented the problem on the PR with teh same suggestion. 
Just saw your mail to late :-(.

May be good to add a warning about the stop support in the man page.

> > - The delay after the message maybe a little bit long.  
> 
> That's the default delay in TLF_LOG_WARN.
> 
Should be no problem, as soon as we change as above.

> > - Sending Fx-messages does not work at all and gives no error or
> >   warning.  
> 
> That shouldn't make a difference and is probably a followup error from
> the above. Do the Fx keys start by issuing a stop morse command? That
> would explain the trouble.
> 
No, not really. There are also no error messages at all. Maybe it is a
problem with my rig (TS590), so I will dig a little bit deeper myself.

> > > Earlier this evening I used the patch in the MWC contest both in
> > > S&P and running mode, and everything seemed ok.  
> > 
> > Fine. I think it could need some more tests from different rigs. I
> > can imagine a period of time during which not all rigs will support
> > stopping CW. That should be handled more graceful.  
> 
> Agreed.
> 
> > > I guess that means I have to write some documentation now :)
> > >   
> > At least the keyword needs to be documented in the man page.   
> 
> The feature is documented now.

Looks good.

73, Tom


-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Bug fix for SEND-DE available

[Thomas Beierlein]

Hi,

If you picked up the latest code from github in last two days, there is
the chance of unwanted behavior of TLF.

The SEND-DE keyword will automatically be activated without a chance to
deactivate it. I just pushed up a fix for that.

So. If you got the actual version in last two days please update again
and recompile. Any former versions are not affected.

Sorry for the inconvenience,

73 Tom DL1JBE

-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

New exchange checking in TLF

[Thomas Beierlein]

Hi all,

TLF just got an overhaul of the code to check and parse the qso
exchange. It should make the logic to recognize your exchange input
more robust. Thanks to Zoli HA5CQZ. 

In preparation for the ARRL SS coming next weekend we recommend to
give the new implementation a thorough test before starting the
contest. Please report back any problems or success stories.

Just keep a copy of your working source code to allow a reinstall in
case of severe problems.

73, 

-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Hamlib keying

[Thomas Beierlein]

Am Mon, 1 Nov 2021 22:36:08 +0100
schrieb Christoph Berg :

> Re: Thomas Beierlein
> > Am Fri, 29 Oct 2021 22:40:10 +0200
> > schrieb Christoph Berg :
...
> > > 
> > > \stop_morse was simply not implemented in rigctld yet, but the
> > > patch has already been merged:
> > > 
> > > https://github.com/Hamlib/Hamlib/commit/8cba9d7ee939b47dffbf057284d70aefafd65b41
> > > 
> > > Christoph
> > >   
> > 
> > That means the feature will be implemented in coming hamlib version
> > starting from 4.4? So I think we should have it ready for TLF around
> > that time.  
> 
> The general feature (calling stop_morse) already works, only the
> support in rigctld was missing.
> 
Just made some first tests (TS590S + Hamlib-4.3.1) with mixed results:

- Sending CW per keyer window works as expected.

- Leaving keyer window (ESC) gives me a messsage about missing
  supported for stopping - first time with the default error colors
  (white on blue), after that only black on white. 

- The delay after the message maybe a little bit long.

- Sending Fx-messages does not work at all and gives no error or
  warning.


> 
> Earlier this evening I used the patch in the MWC contest both in S&P
> and running mode, and everything seemed ok.

Fine. I think it could need some more tests from different rigs. I can
imagine a period of time during which not all rigs will support
stopping CW. That should be handled more graceful.
> 
> I guess that means I have to write some documentation now :)
> 
At least the keyword needs to be documented in the man page. 

73, Tom



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Moving the bandmap.

[Thomas Beierlein]

Hi Zoli, Hi Lukasz,

how about adding it to the FAQ?

73, de Tom

Am Mon, 1 Nov 2021 08:11:48 +0100
schrieb Csahok Zoltan :

> Hi Lukasz,
> 
> Even though Tlf can be started without rig control but some of its
> functionality will be limited as you have exprienced it.
> To overcome this you can use rigctld in dummy mode.
> Here is how:
> 1) start rigctld for Dummy radio (ignore the warnings)
> $ rigctld -m 1 &
> 2) check if it works by reading freq and mode (default is 2m FM)
> $ rigctl -m 2 f m
> 14500
> FM
> 15000
> 3) set your real radio's freq+mode for dummy rigctld (freq unit
> is Hz) $ rigctl -m 2 F 2120 M USB 0
> 4) configure Tlf to use rigctld
> RIGMODEL=2
> RIGPORT=127.0.0.1
> 5) from Tlf freq can be changed either by
> a) Ctrl-F or
> b) direct freq entry on call field: enter a kHz value (no
> fraction, e.g. 21195) as call and press enter or
> c) moving around on bandmap by Ctrl-G (grab) / Ctrl-V
> (direction).
> 
> 
> Hope this helps.
> 
> 73,
> Zoli
> 
> 
> 
> On Sun, Oct 31, 2021 at 07:17:15PM +0100, Lukasz Olszewski wrote:
> >Hi,
> >I apologise if this is a trivial question, but I've read the man
> > page multiple times and I cannot figure out how to move the bandmap
> > display. I have no rig control. My frequency is simply logged as
> > 15m for example. Today I was on 15m and the bandmap window was
> > showing spots from 21.200 to 21.300. I needed to see ones below
> > 21.200. I tried ctrl-f (it did nothing.
> >- probably because it requires rig control).
> >However, somehow later the bandmap shifted to display range
> > 21.100 to 21.200 just when I needed 21.200~21.300...
> >Can someone help me, please by telling me how to navigate the
> > bandmap window?
> >Many thanks, 
> >Lukasz   
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Hamlib keying

[Thomas Beierlein]

Am Fri, 29 Oct 2021 22:40:10 +0200
schrieb Christoph Berg :

> Re: To tlf-devel@nongnu.org
> > In fact aborting the message does work, but rigctld isn't properly
> > forwarding the request through for the IC-7610 here.  
> 
> \stop_morse was simply not implemented in rigctld yet, but the patch
> has already been merged:
> 
> https://github.com/Hamlib/Hamlib/commit/8cba9d7ee939b47dffbf057284d70aefafd65b41
> 
> Christoph
> 

That means the feature will be implemented in coming hamlib version
starting from 4.4? So I think we should have it ready for TLF around
that time.

Tom

-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Can you prevent mode switching?

[Thomas Beierlein]

Am Thu, 28 Oct 2021 05:03:06 -0500
schrieb Nate Bargmann :

> * On 2021 28 Oct 01:01 -0500, Thomas Beierlein wrote:
> > - Add a new keyword as suggested above.
> > - On bandswitch record not only the old frequency but also the
> > mode. So TLF may start with turning the rig to CW on first start
> > but remember later any changes made directly at the trx.  
> 
> I would ask that even this setting not be performed when the new
> keyword is present.  With the keyword present, Tlf should be
> "passive", only changing its logging mode but not sending any mode
> change to the radio.
> 
> 73, Nate
> 

From my point of view it makes no sense to have both. Either have a
keyword or remember the last mode.

We can put it on the ToDO list.

73, de Tom

-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Can you prevent mode switching?

[Thomas Beierlein]

Am Thu, 28 Oct 2021 10:22:13 +0800
schrieb Onno VK6FLAB :

> The mode change is still being populated on band change, even if I
> comment out the band-change rig_set_mode call at the bottom of
> src/gettxinfo.c.
> 
The change mode happens actually in handle_trx_bandswitch in gettxinfo.c
It is called in the same file around line 205. Just comment the call
out. That should help.

> I suspect that the mode change is secretly being sent with the
> frequency change and have been trying to investigate filtering out
> mode changes in the TCP connection to rigctld, but that's a two-way
> stream and using grep/sed on a bidirectional stream is a challenge :-)
> 
No. The frequency change is sent separately. But in the next frequency
reading cycle TLF sees the change in band (bandinx != oldbandinx) and
triggers the mode switch.


In the long term I see two ways to handle it:

- Add a new keyword as suggested above.
- On bandswitch record not only the old frequency but also the mode. So
  TLF may start with turning the rig to CW on first start but remember
  later any changes made directly at the trx.

73, de Tom

> I agree that it needs a config option. I think it should be called
> something like IGNORE_RADIO_MODE to make it explicit.
> 
> o
> 
> On Thu, 28 Oct 2021 at 10:00, Nate Bargmann  wrote:
> 
> > * On 2021 27 Oct 18:23 -0500, Onno VK6FLAB wrote:  
> > > I've just removed (commented out) all rig_set_mode calls in  
> > src/gettxinfo.c  
> > > and the behaviour persists. Not sure where else to look.  
> >
> > Hi Onno,
> >
> > Follow the logic from the parsing of logcfg.dat with the SSBMODE and
> > RTTYMODE keywords.  That should lead you to where the mode is set on
> > startup, at least.
> >  
> > > I agree with Nate, TLF should follow the mode, not set it unless
> > > specifically instructed to do so.  
> >
> > I'm sure some prefer the current behavior (working a single mode
> > event, I can see this preference and would likely use it).  I'd
> > like to see a similar keyword, perhaps RIGMODE is to close to the
> > existing RIGMODEL keyword, maybe FOLLOW_MODE would work, that could
> > be added for Tlf following the radio mode until instructed to
> > change mode.
> >
> > 73, Nate
> >
> > --
> > "The optimist proclaims that we live in the best of all
> > possible worlds.  The pessimist fears this is true."
> > Web: https://www.n0nb.us
> > Projects: https://github.com/N0NB
> > GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819
> >
> >  
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Can you prevent mode switching?

[Thomas Beierlein]

Am Wed, 27 Oct 2021 09:54:38 +0800
schrieb Onno VK6FLAB :

> When I change bands, TLF automatically changes the mode (CW/LSB/USB),
> even if I don't want it to do that. Can I decouple the TLF mode from
> the radio mode without losing rig control?
> 
> Specifically I want to leave TLF in CW mode, but have the radio in SSB
> (LSB/USB per band as appropriate).
> 
> 

Hi Onno,

If I remember correctly these question came out some years ago. I do
not remember the solution - (if there was one at all). I have to look up
the code for details.

73, de Tom DL1JBE


-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Hamlib keying

[Thomas Beierlein]

Hi Christoph,

there were some request for that feature from time to time. Iirc the
last time someone told us there was some cwdaemon like program talking
to the rig via hamlib.

But anyway - your work looks promising. What most users will miss is
the ability to abort the message. It would be good to have a
solution for that problem before merging it in.

> One problem I have is the baroque handing of CW speed in Tlf:
> 
> #define CW_SPEEDS   "06121416182022242628303234363840424446485060"
> /*< speed string with 2 chars each (in WPM) */

I did some search in historic versions of TLF (0.9.10, 0.9.38). The
code above is an ancient left over from former times. (Maybe original
author Rein was a BASIC fan - quite a lot of operations were done as
string manipulations). See it as just a weird coded table.

Having the speed settings as a table allows for a nonlinear stepping -
heavily used in 0.9.10, now only seen on both ends. A plain up/dwn 
by +/- 2wpm would loose that ability. 

Maybe we should extend here and allow the user to set its own speed
stepping. Any thoughts on that?

73, de Tom DL1JBE



 Am Mon, 25 Oct 2021 00:05:19 +0200
schrieb Christoph Berg :

> Hi,
> 
> I've been poking around with adding support for CW keying via Hamlib
> to Tlf. I have it somewhat working. :)
> 
> https://github.com/df7cb/tlf/tree/hamlib-cw
> 
> Basically the status is:
> 
> Working:
> * Hamlib keyer is activated by HAMLIB_KEYER keyword
> * CW sending works
> * setting CW speed works
> * reading CW speed from rig (when adjusted via knob or menu) works
> 
> TODO:
> * rig CW support is detected by rig type, but should be queried
> from the actual rig (makes a difference with rigctld)
> * aborting CW doesn't work yet
> * less than ideal interaction with the cw speed stepping in Tlf
> * no other keyer commands (pitch etc) supported yet
> 
> I've been reading through
> 
> https://www.mail-archive.com/tlf-devel@nongnu.org/msg02341.html
> 
> and I don't have a solution for implementing in-message speed changes
> yet (+++TEST---), but if it turns out not to be feasible, I'd think
> having the general feature would still be nice - less cables, and the
> ability to turn the keyer speed knob on my IC7610 and having Tlf pick
> that up is already nice.
> 
> One problem I have is the baroque handing of CW speed in Tlf:
> 
> #define CW_SPEEDS   "06121416182022242628303234363840424446485060"
> /*< speed string with 2 chars each (in WPM) */
> 
> What's the reasoning behind that? Storing the desired WPM in a plain
> integer would be much cleaner, and PgUp/PgDn could still adjust the
> speed in 2-wpm steps instead of doing string mangling all the time.
> 
> Christoph DF7CB
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: How do you disable bands?

[Thomas Beierlein]

Am Wed, 27 Oct 2021 08:14:43 +0800
schrieb Onno VK6FLAB :

> My station is only capable of operating on a selected set of bands, I
> cannot operate on 160m or 20m. How do I disable these bands, so my
> arrow keys switch from 10m to 80m and from 40m to 15m?
> 
> 

Hi Onno,
 
there is no way to disable selected bands, sorry.

You have three ways to handle the situation:

- Skip them by using the arrow key twice
- Switch the band on the radio - TLF will follow
- enter a frequency from the band to go into input field and press
  enter.


73, de Tom DL1JBE

-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: The state QSO Party thread

[Thomas Beierlein]

Hi Nate,

Am Fri, 3 Sep 2021 21:08:50 -0500
schrieb Nate Bargmann :

>
> For some of these events it may be necessary to simply use Tlf as a
> logger as anything resembling accurate scoring may not be possible
> given the notion that stations are usually worked once or once per
> band/mode. State QSO parties often have mobile operators that move
> from county to county and the rules allow outstate participants to
> work those mobiles again for point and multiplier credit when they
> move to a new county. Some rules also permit working such a station
> once but logging it twice when it is on a county line or at the
> junction of multiple counties.  So far as I'm aware, Tlf would treat
> additional such contacts on a given band/mode as a dupe.
> 

Please have a look at IGNOREDUPES in the man page for that.

73, de Tom

-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: No luck trying to pkill play_vk with escape

[Thomas Beierlein]

Am Sat, 28 Aug 2021 17:33:46 -0500
schrieb Nate Bargmann :

> Removing the '&' from play_vk eliminates the auto_cq confusion, but
> then Escape does nothing except cancel auto_cq.
> 
> 73, Nate
> 

That is understandable. 

With the '&' attached play_vk starts playing the soundfile but returns
immediately. Without it waits until the sound is played before
returning.

So on one side the auto_cq timing is shorter (missing the time to play
the sound) and on the other side tlf will not accept keyboard input as
long as the script is waiting unti the sound is played.

I think we have to go the way you suggested in one of your other mails:
playing the sound in another process after a fork. I will experiment in
that direction.

73, de Tom



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: No luck trying to pkill play_vk with escape

[Thomas Beierlein]

Am Sat, 28 Aug 2021 07:40:40 -0500
schrieb Nate Bargmann :

> Hi Tom.
> 
> A quick test shows that it works to some degree but may still leave
> the radio in TX mode.  I'll test further this weekend but it's a
> critical first step.
> 
> 73, Nate
> 

Hi Nate,
thanks for the test. I overlooked the needed logic for PTT control. My
solution can only work if you use VOX-keying, but I fear it is not very
applicable during contest.

Btw, if you control PTT by the PPT code you can copy the PTT-off logic
from play_file() to stoptx().

Anyway seems it needs quite some more work here.

73, de Tom

-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: No luck trying to pkill play_vk with escape

[Thomas Beierlein]

Am Fri, 27 Aug 2021 21:25:05 -0500
schrieb Nate Bargmann :

> A thought I just had, is I wonder if threading has anything to do with
> this?  While pgrep only returns one PID when Tlf is running, htop
> shows two PIDs.
> 
> Oddly, I figured calling pkill via system() would as the same method
> is used to kill rec from the sound recorder menu.
> 
> I've seen mention that this might require fork() and exec() to start
> the call to play_vk manually so that the PID is known and then use
> kill() on it.  I doubt I'll get to it before tomorrow morning!
> 
> 73, Nate
> 

Hi all, 

as a quick fix do the following:

- Add an '&' to the 'play $1 ...' line in play_vk.sh
- Keep your proposed changes for stoptx, but do not kill play_vk.sh but
  'play' itself:
IGNORE(system("pkill -SIGTERM play"));

That should work better. There may be side effects. We need to have a
deeper look into it.

73, de Tom

-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Rules for french "Coupe du REF"

[Thomas Beierlein]

Hi Stephane,

I am just looking into your code. 

The idea of your changes is clear to me. There are some problems and
questions so far:

- Any existing contest rules for ARRL10M and ARRL160m seems to be
  affected. They do set dx_arrlsections via DX_&_SECTIONS but are not
  recognized via the CONTEST_IS_ARRLDX macro. And they have similar
  rules in not accepting W/VE country as a multiplier.
  Worked sections are counted and shown in the remaining sections list
  but not recorded in the logline. 

- There are some related questions to the problem. There are some other
  contests with sections and DX countries as multipliers. Some of them
  count the own country as mult AND a possible section, some (like
  ARRLDX) only the section OR foreign DX countries. We need a way to
  express that difference.

- A second question comes from the change from strstr to strcmp in
  changepars(). Is it really needed that we have an exact match? Is it
  possible for sections with 2 characters to be a substring of a longer
  one?

Anyway, your problem needs to be solved. I will make a branch for
experimentation and discussion on github from your patch and add an
issue. The DX_&_SECTION problem needs to be sorted out.

73, de Tom DL1JBE


Am Sun, 28 Feb 2021 23:07:17 +0100
schrieb Stephane Fillod :

> Hi,
> 
> I've been participating into the french contest "Coupe du REF" this 
> weekend, a lot of fun.
> Even though I've been using TLF since long time, only this week-end I 
> took the time
> to write a fully working rule file, well sort-of.
> 
> Let's start first in this mail with multipliers/section. I wanted to 
> track wanted sections.
> Using TLF freshly built from git tree, I've been unable to configure 
> this rule :
> /Multiplier is DXCC country or section from multiplier file,
> basically a list of french departments./
> This should be covered by these statements :
> 
> DX_&_SECTIONS
> SERIAL_OR_SECTION
> MULT_LIST=ref_deptmults
> 
> Loading an existing logfile would leave the "Sect" line flat, the
> "Show multipliers" screen
> would be empty. However, logging new QSO would increment the Section 
> stats and multi screen.
> 
> Diving into the source code, it looks like the statement
> DX_&_SECTIONS is very tied to ARRL contests,
> certainly for historical reasons. This is what is revealed by the 
> variable dx_arrlsections
> set by cfg_dx_n_sections(). I've made a quick fix, please see
> attached file tlf_dx_sections_quick_fix.patch
> I tried to not break existing contest rules, however I haven't tested
> them. I can make a fork for that, but IMO it'd be better to split the 
> dx_arrlsections variable as
> something like one variable dx_arrl_contest and one dx_and_sections.
> What do you think about it ?
> 
> The fixes in src/changepars.c would enable the "Show multipliers"
> screen, and also not misinterpret serial numbers as section (a test
> has to be done to not break existing contest rules).
> 
> The issue #235[2] might benefit from this fix.
> 
> [1]
> https://concours.r-e-f.org/reglements/actuels/reg_cdfhf_fr_202011.pdf
> [2] https://github.com/Tlf/tlf/issues/235 (Mults on bandmap with
> custom rules)
> 
> Anyway, thanks for maintaining and improving TLF over the years.
> Last year, TLF was merely crashing (stack smashing,..) at moment,
> I see a lot of work has been done since. It's much appreciated!
> 
> 73
> Stephane, F8CFE
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Rules for french "Coupe du REF"

[Thomas Beierlein]

Hi Stephane,

thanks for your report and also the suggestions. We will kook into it.
The problem with mixed country/section scoring was also apparent in the
EUDX contest some weeks ago.

Am Sun, 28 Feb 2021 23:07:17 +0100
schrieb Stephane Fillod :
> Let's start first in this mail with multipliers/section. I wanted to 
> track wanted sections.
> Using TLF freshly built from git tree, I've been unable to configure 
> this rule :
> /Multiplier is DXCC country or section from multiplier file,
> basically a list of french departments./
> This should be covered by these statements :
> 
> DX_&_SECTIONS
> SERIAL_OR_SECTION
> MULT_LIST=ref_deptmults
> 
Ok. That is normally the right start for the mentioned rules.

> Loading an existing logfile would leave the "Sect" line flat, 

At the moment it only counts sections which are correctly scored during
the last run. 

> "Show multipliers" screen
> would be empty. However, logging new QSO would increment the Section 
> stats and multi screen.
> 
> Diving into the source code, it looks like the statement
> DX_&_SECTIONS is very tied to ARRL contests,
> certainly for historical reasons. 

You are correct. That is one of the points which needs fixing ,
especially as it excludes W/VE contacts.

> This is what is revealed by the 
> variable dx_arrlsections
> set by cfg_dx_n_sections(). I've made a quick fix, please see
> attached file tlf_dx_sections_quick_fix.patch
> I tried to not break existing contest rules, however I haven't tested
> them. I can make a fork for that, but IMO it'd be better to split the 
> dx_arrlsections variable as
> something like one variable dx_arrl_contest and one dx_and_sections.
> What do you think about it ?

I will have a look into it in the evening. 

73 for now,

Tom DL1JBE

> The fixes in src/changepars.c would enable the "Show multipliers"
> screen, and also not misinterpret serial numbers as section (a test
> has to be done to not break existing contest rules).
> 
> The issue #235[2] might benefit from this fix.
> 
> [1]
> https://concours.r-e-f.org/reglements/actuels/reg_cdfhf_fr_202011.pdf
> [2] https://github.com/Tlf/tlf/issues/235 (Mults on bandmap with
> custom rules)
> 
> Anyway, thanks for maintaining and improving TLF over the years.
> Last year, TLF was merely crashing (stack smashing,..) at moment,
> I see a lot of work has been done since. It's much appreciated!
> 
> 73
> Stephane, F8CFE
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: why 25 rows?

[Thomas Beierlein]

Hi Drew, hi Christoph,

Am Thu, 25 Feb 2021 17:04:52 +0100
schrieb Christoph Berg :

> Re: Drew Arnett
> > Dumb question:  why 25 rows?  Sorry for asking first, before
> > examining code.  
> 
> I think you can start with more rows and then resize to 20 rows and it
> still works. The restriction seems to remain from the time where
> resizing the window wasn't supported. (With less rows things start to
> overwrite each other.)
> 
> Christoph
> 

Totally correct. Old display code was optimized for a fixed 25 line
layout. You would loose the bottom line with a 24 line display.

For a year or so we support vertical resizing and the bottom line is
always shown. So the warning about 25 lines should go in next release.

At the moment the only negative point with less than 25 lines is the
smaller space for the bandmap. 

73, de Tom


-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: [Tlf/tlf] Bandmap improvements (#31)

[Thomas Beierlein]

Hi Fred,

the problem should be fixed in
https://github.com/dl1jbe/tlf/tree/fix_bandmap

I runs now stable with N8NOEs 7373 port with around 600 active spots.

73, de Tom DL1JBE

Am Tue, 2 Feb 2021 22:19:01 +0100
schrieb Fred Siegmund :

> Hi Tom, I will test at the weekend in EUDX contest with 'gdb'.
> 
> 73 Fred
> 
> Am 02.02.21 um 21:18 schrieb Thomas Beierlein:
> > Hi Fred,
> >
> > Just saw Zolis test results for the RBN. Normally bandmap seems to
> > be very stable even during large contests (at least with normal DX
> > cluster).
> >
> > There is one possible variation to test during next major contest.
> >
> > Prepare and build  tlf as follows and make sure to have the 'gdb'
> > debugger installed.
> >
> > CFLAGS="-g" ./configure --prefix=
> >
> > That will build tlf with debug information built in. Install the
> > program like normal and than start tlf with
> >
> > gdb path/to/tlf 
> >
> > Tlf should work like before but in case of a segmentation fault
> > stop in gdb's command line.
> >
> > Just do a 'bt' command for getting backtrack information and send us
> > the output. you can quit gdb afterwards with 'q'.
> >
> > 73, de Tom
> >
> >
> > Am Sun, 31 Jan 2021 13:40:10 +0100
> > schrieb Fred Siegmund :
> >  
> >> Also something I see from time to time (repeatedly):
> >>
> >> 73 Fred
> >>
> >> Am 31.01.21 um 12:58 schrieb Fred Siegmund:  
> >>> Hi Tom, i install always with --prefix option and start from /bin.
> >>> But its acually easier now to edit logcfg.dat, only that it is at
> >>> 2 locations was confusing (for me).
> >>>
> >>> For the bandmap crashes its kind of hard to reproduce, I always
> >>> use ARcluster like N8NOE, because of the great filtering options
> >>> (much better than with DXspider). I just notice that with high
> >>> load (like in major contests) it happens quite often. Right now
> >>> just dawdling in REF contest its no problem, I have no crashes.
> >>> Maybe there is some way to instrument the code, I just see
> >>> segmentation fault if it happens.
> >>>
> >>> 73 Fred
> >>>
> >>> Am 30.01.21 um 17:01 schrieb Thomas Beierlein:  
> >>>> Hi Fred,
> >>>>
> >>>> Am Sat, 30 Jan 2021 14:19:59 +0100
> >>>> schrieb Fred Siegmund :
> >>>> 
> >>>>> Also I noticed that logcfg.dat gets copied to the /bin directory
> >>>>> and used from there. Seems to be new.
> >>>>> 
> >>>> maybe by accident TLf got started there?
> >>>>
> >>>> It normally assumes to be started from a contest working
> >>>> directory. If there is no logcfg.dat in that directory old
> >>>> versions used the default (readonly) version
> >>>> (/usr/(local)/share/tlf/logcfg.dat). Newer version copies the
> >>>> default file into the actual directory so you can adapt it to
> >>>> your needs.
> >>>>
> >>>> 73, Tom
> >>>>
> >>>> P.S. How do you connect to the reverse beacon server? Maybe we
> >>>> can reproduce your problems
> >>>> 
> >>>>> 73 Fred
> >>>>>
> >>>>> Am 27.01.21 um 20:04 schrieb Zoltan Csahok:  
> >>>>>> @dh5fs <https://github.com/dh5fs> I suggest closing this issue
> >>>>>> (if the solution is OK) and opening a new one on further
> >>>>>> improvement options.
> >>>>>>
> >>>>>> —
> >>>>>> You are receiving this because you were mentioned.  
> >>>> 
> >
> >  
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: [Tlf/tlf] Bandmap improvements (#31)

[Thomas Beierlein]

Hi Fred,

I think you can stop that tests. I can now reproduce the problem here
myself.

I am just looking for the problem. But it may take some time. So please
do not expect a quick solution.

73, de Tom DL1JBE

 Am Tue, 2 Feb 2021 22:19:01 +0100
schrieb Fred Siegmund :

> Hi Tom, I will test at the weekend in EUDX contest with 'gdb'.
> 
> 73 Fred
> 
> Am 02.02.21 um 21:18 schrieb Thomas Beierlein:
> > Hi Fred,
> >
> > Just saw Zolis test results for the RBN. Normally bandmap seems to
> > be very stable even during large contests (at least with normal DX
> > cluster).
> >
> > There is one possible variation to test during next major contest.
> >
> > Prepare and build  tlf as follows and make sure to have the 'gdb'
> > debugger installed.
> >
> > CFLAGS="-g" ./configure --prefix=
> >
> > That will build tlf with debug information built in. Install the
> > program like normal and than start tlf with
> >
> > gdb path/to/tlf 
> >
> > Tlf should work like before but in case of a segmentation fault
> > stop in gdb's command line.
> >
> > Just do a 'bt' command for getting backtrack information and send us
> > the output. you can quit gdb afterwards with 'q'.
> >
> > 73, de Tom
> >
> >
> > Am Sun, 31 Jan 2021 13:40:10 +0100
> > schrieb Fred Siegmund :
> >  
> >> Also something I see from time to time (repeatedly):
> >>
> >> 73 Fred
> >>
> >> Am 31.01.21 um 12:58 schrieb Fred Siegmund:  
> >>> Hi Tom, i install always with --prefix option and start from /bin.
> >>> But its acually easier now to edit logcfg.dat, only that it is at
> >>> 2 locations was confusing (for me).
> >>>
> >>> For the bandmap crashes its kind of hard to reproduce, I always
> >>> use ARcluster like N8NOE, because of the great filtering options
> >>> (much better than with DXspider). I just notice that with high
> >>> load (like in major contests) it happens quite often. Right now
> >>> just dawdling in REF contest its no problem, I have no crashes.
> >>> Maybe there is some way to instrument the code, I just see
> >>> segmentation fault if it happens.
> >>>
> >>> 73 Fred
> >>>
> >>> Am 30.01.21 um 17:01 schrieb Thomas Beierlein:  
> >>>> Hi Fred,
> >>>>
> >>>> Am Sat, 30 Jan 2021 14:19:59 +0100
> >>>> schrieb Fred Siegmund :
> >>>> 
> >>>>> Also I noticed that logcfg.dat gets copied to the /bin directory
> >>>>> and used from there. Seems to be new.
> >>>>> 
> >>>> maybe by accident TLf got started there?
> >>>>
> >>>> It normally assumes to be started from a contest working
> >>>> directory. If there is no logcfg.dat in that directory old
> >>>> versions used the default (readonly) version
> >>>> (/usr/(local)/share/tlf/logcfg.dat). Newer version copies the
> >>>> default file into the actual directory so you can adapt it to
> >>>> your needs.
> >>>>
> >>>> 73, Tom
> >>>>
> >>>> P.S. How do you connect to the reverse beacon server? Maybe we
> >>>> can reproduce your problems
> >>>> 
> >>>>> 73 Fred
> >>>>>
> >>>>> Am 27.01.21 um 20:04 schrieb Zoltan Csahok:  
> >>>>>> @dh5fs <https://github.com/dh5fs> I suggest closing this issue
> >>>>>> (if the solution is OK) and opening a new one on further
> >>>>>> improvement options.
> >>>>>>
> >>>>>> —
> >>>>>> You are receiving this because you were mentioned.  
> >>>> 
> >
> >  
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: graphical bandmap view

[Thomas Beierlein]

Am Thu, 4 Feb 2021 20:19:22 +0100
schrieb Zoltan Csahok :

> In case one is interested in a non-curses bandmap for Tlf:
> https://github.com/zcsahok/tlf_bandmap
> 
> 73,
> Zoli
> 
> 

Looks nice. Especially as you can have more than one running for each
band.

As I see it is limited to CW at the moment. Is that be intention?


73, de Tom

-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: [Tlf/tlf] Bandmap improvements (#31)

[Thomas Beierlein]

Hi Fred,

Just saw Zolis test results for the RBN. Normally bandmap seems to be
very stable even during large contests (at least with normal DX
cluster).

There is one possible variation to test during next major contest. 

Prepare and build  tlf as follows and make sure to have the 'gdb'
debugger installed.

CFLAGS="-g" ./configure --prefix= 

That will build tlf with debug information built in. Install the
program like normal and than start tlf with

gdb path/to/tlf 

Tlf should work like before but in case of a segmentation fault stop in
gdb's command line.

Just do a 'bt' command for getting backtrack information and send us
the output. you can quit gdb afterwards with 'q'.

73, de Tom


Am Sun, 31 Jan 2021 13:40:10 +0100
schrieb Fred Siegmund :

> Also something I see from time to time (repeatedly):
> 
> 73 Fred
> 
> Am 31.01.21 um 12:58 schrieb Fred Siegmund:
> > Hi Tom, i install always with --prefix option and start from /bin.
> > But its acually easier now to edit logcfg.dat, only that it is at 2 
> > locations was confusing (for me).
> >
> > For the bandmap crashes its kind of hard to reproduce, I always use 
> > ARcluster like N8NOE, because of the great filtering options (much 
> > better than with DXspider). I just notice that with high load (like
> > in major contests) it happens quite often. Right now just dawdling
> > in REF contest its no problem, I have no crashes. Maybe there is
> > some way to instrument the code, I just see segmentation fault if
> > it happens.
> >
> > 73 Fred
> >
> > Am 30.01.21 um 17:01 schrieb Thomas Beierlein:  
> >> Hi Fred,
> >>
> >> Am Sat, 30 Jan 2021 14:19:59 +0100
> >> schrieb Fred Siegmund :
> >>  
> >>> Also I noticed that logcfg.dat gets copied to the /bin directory
> >>> and used from there. Seems to be new.
> >>>  
> >> maybe by accident TLf got started there?
> >>
> >> It normally assumes to be started from a contest working
> >> directory. If there is no logcfg.dat in that directory old
> >> versions used the default (readonly) version
> >> (/usr/(local)/share/tlf/logcfg.dat). Newer version copies the
> >> default file into the actual directory so you can adapt it to your
> >> needs.
> >>
> >> 73, Tom
> >>
> >> P.S. How do you connect to the reverse beacon server? Maybe we can
> >> reproduce your problems
> >>  
> >>> 73 Fred
> >>>
> >>> Am 27.01.21 um 20:04 schrieb Zoltan Csahok:  
> >>>> @dh5fs <https://github.com/dh5fs> I suggest closing this issue
> >>>> (if the solution is OK) and opening a new one on further
> >>>> improvement options.
> >>>>
> >>>> —
> >>>> You are receiving this because you were mentioned.  
> >>
> >>  



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: [Tlf/tlf] Bandmap improvements (#31)

[Thomas Beierlein]

Hi Fred,

Am Sat, 30 Jan 2021 14:19:59 +0100
schrieb Fred Siegmund :

> Also I noticed that logcfg.dat gets copied to the /bin directory and 
> used from there. Seems to be new.
> 
maybe by accident TLf got started there?

It normally assumes to be started from a contest working directory. If
there is no logcfg.dat in that directory old versions used the default
(readonly) version (/usr/(local)/share/tlf/logcfg.dat). Newer version
copies the default file into the actual directory so you can adapt it to
your needs.

73, Tom

P.S. How do you connect to the reverse beacon server? Maybe we can
reproduce your problems

> 73 Fred
> 
> Am 27.01.21 um 20:04 schrieb Zoltan Csahok:
> >
> > @dh5fs  I suggest closing this issue (if
> > the solution is OK) and opening a new one on further improvement
> > options.
> >
> > —
> > You are receiving this because you were mentioned.
> >  



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Anyone else compiling with GCC 10.2 on Debian Testing?

[Thomas Beierlein]

Am Sun, 17 Jan 2021 21:31:08 +0100
schrieb Thomas Beierlein :

> Am Sun, 17 Jan 2021 14:11:13 -0600
> schrieb Nate Bargmann :
> 
> > As Tom points out, Hamlib up to version 3.3 had rig_model_t as type
> > int. Since 4.0 it is now of type uint32_t so this probably needs
> > version checking for Hamlib 4.0 so Tlf users with older Hamlib
> > versions aren't left out.
> > 
> > 73, Nate
> >   
> 
> Yes, I fear that is what we have to do.
> 
> 73, de Tom
> 

Just saw Zoli's solution - move the variable to int type. That is a
better way to fix the problem as it does not force us to differentiate
between the hamlib versions.

73, de Tom

-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--



pgpTEb62Rv_2z.pgp
Description: Digitale Signatur von OpenPGP

Re: Anyone else compiling with GCC 10.2 on Debian Testing?

[Thomas Beierlein]

Am Sun, 17 Jan 2021 14:11:13 -0600
schrieb Nate Bargmann :

> As Tom points out, Hamlib up to version 3.3 had rig_model_t as type
> int. Since 4.0 it is now of type uint32_t so this probably needs
> version checking for Hamlib 4.0 so Tlf users with older Hamlib
> versions aren't left out.
> 
> 73, Nate
> 

Yes, I fear that is what we have to do.

73, de Tom

-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--



pgpTyiIMWEOUs.pgp
Description: Digitale Signatur von OpenPGP

Re: Anyone else compiling with GCC 10.2 on Debian Testing?

[Thomas Beierlein]

Am Sun, 17 Jan 2021 19:07:28 +0100
schrieb Thomas Beierlein :

> I am not sure. I had a look into the definition of rig_model_t (the
> type of myrig_model). As far as I could tell it is typedef'd to an
> int. But then I do not understand the warning. Seem I must look a
> little bit more thoroughly.
> 
Found the problem. I have not only different compilers installed but
also different hamlib versions.

rig_model_t is int in Hamlib3 and unsigned int in Hamlib4. 

73, de Tom


-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--



pgp7GegfOJGn4.pgp
Description: Digitale Signatur von OpenPGP

Re: Anyone else compiling with GCC 10.2 on Debian Testing?

[Thomas Beierlein]

Am Sun, 17 Jan 2021 09:59:47 -0600
schrieb Nate Bargmann :

> Is the pointer warning this one:
> 
> In file included from ../../tlf/src/parse_logcfg.c:46:
> ../../tlf/src/parse_logcfg.h:102:28: warning: pointer targets in
> initialization of ‘int *’ from ‘rig_model_t *’ {aka ‘unsigned int *’}
> differ in signedness [-Wpointer-sign] 102 |
> (cfg_arg_t){.int_p=&var, .min=minval, .max=maxval} |
>   ^ ../../tlf/src/parse_logcfg.c:1121:25: note: in expansion
> of macro ‘CFG_INT’ 1121 | {"RIGMODEL",
> CFG_INT(myrig_model, 0, )}, | ^~~
> ../../tlf/src/parse_logcfg.h:102:28: note: (near initialization for
> ‘(anonymous)..int_p’) 102 |
> (cfg_arg_t){.int_p=&var, .min=minval, .max=maxval} |
>   ^ ../../tlf/src/parse_logcfg.c:1121:25: note: in expansion
> of macro ‘CFG_INT’ 1121 | {"RIGMODEL",
> CFG_INT(myrig_model, 0, )}, | ^~~
> 
Right. That is the one in question.

> I was looking that over last night and is it a case that the macro and
> function need to be duplicated for the unsigned int?

I am not sure. I had a look into the definition of rig_model_t (the
type of myrig_model). As far as I could tell it is typedef'd to an int. 
But then I do not understand the warning. Seem I must look a little bit
more thoroughly.

> > Anyhow it would be good to get rid of them.  
> 
> Yeah, it makes it a bit more difficult to find the warnings and errors
> when trying to break things intentionally!
> 
Then just stay away from that evil doing :-).

73, de Tom



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--



pgp39ajO7tksT.pgp
Description: Digitale Signatur von OpenPGP

Re: Anyone else compiling with GCC 10.2 on Debian Testing?

[Thomas Beierlein]

Am Sat, 16 Jan 2021 20:47:06 -0600
schrieb Nate Bargmann :

> I am asking as I'm seeing a number of compiler warnings that could be
> harmless but should probably be looked at.  It looks like GCC 10.2.1
> or maybe a slightly later version will be the default in the
> forthcoming Debian 11.
> 
> If deemed useful I can open an issue on GitHub.

Thanks for the hint Nate.

I am not on Debian, but do check with GCC 10.2.0 regularly. (And from
time to time with clang and its tools).

We are aware of the warnings. They are mostly false positives about
string operations and one about a pointer initialization.

Anyhow it would be good to get rid of them.

73, de Tom DL1JBE

-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--



pgpqdO4GgVLTh.pgp
Description: Digitale Signatur von OpenPGP

Re: TLF and Hamlib 4 - things to look for

[Thomas Beierlein]

Yes and no.

For the 'yes' part:

You can point tlf to use the daemon (as Slave wrote) but it is
activated via the normal hamlib library call (with rig model number
2).

That means in these case it goes directly to the hamlib library and talk
to rig model 2 which results in hamlib library making a TCP connection
to rigctld (model number 2)  (which talks to the hamlib library, which
talks to the radio rigctld is configured for). (Sounds like overkill
and make my head spinning).

And for the first part of the game - talking to the hamlib library - it
has to be adapted to the correct API.

For the 'no' part:

To use rigctld directly TLF has to be changed to use a direct TCP
connection to rigctld. But that is not how TLF works at the moment. 


Summary: At the time being you have to recompile during the switch
between Hamlib 3 and 4.

73, de Tom DL1JBE


 Am Wed, 16
Dec 2020 14:51:02 + schrieb Drew Arnett :

> Dumb question:  Can some of this be avoided by running rigctld and
> then pointing tlf to the daemon?  They didn't change the network
> protocol for rigctld, did they?
> 
> Best regards,
> 
> Drew
> n7da
> 
> On Wed, Dec 16, 2020 at 5:48 AM Thomas Beierlein 
> wrote:
> >
> > Hi all,
> >
> > if you want to play with the new Hamlib 4 release candidates for
> > TLF there are some points to remember:
> >
> > 1. Hamlib 4 has changed the scheme for rig numbers to make room for
> > more new rigs. Please have a look with 'rigctl -l', find your new
> > rig number and adapt logcfg.dat accordingly.
> >
> > 2. IMPORTANT! Hamlib 4 has a different program API than the versions
> >   before. So any time you switch from Hamlib 3 to 4 (or maybe back)
> > you have to recompile TLF to adapt to the other API.
> >
> > Afterwards TLF should be able to work with your rig as before.
> >
> > 73, de Tom DL1JBE
> >
> > --
> > "Do what is needful!"
> > Ursula LeGuin: Earthsea
> > --
> >
> >  



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

TLF and Hamlib 4 - things to look for

[Thomas Beierlein]

Hi all,

if you want to play with the new Hamlib 4 release candidates for 
TLF there are some points to remember:

1. Hamlib 4 has changed the scheme for rig numbers to make room for more
  new rigs. Please have a look with 'rigctl -l', find your new rig
  number and adapt logcfg.dat accordingly.

2. IMPORTANT! Hamlib 4 has a different program API than the versions
  before. So any time you switch from Hamlib 3 to 4 (or maybe back) you
  have to recompile TLF to adapt to the other API.

Afterwards TLF should be able to work with your rig as before.

73, de Tom DL1JBE

-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: mode switchs not working

[Thomas Beierlein]

Am Tue, 24 Nov 2020 12:17:25 -0800
schrieb glenn biagioni :

> hello developers of tlf great logging software i love it.
> only problem however is not able to change band mode ie
> :ssb. the program opens in cw. when i make an ssb contact,
> i end up logging it in cw mode. i was using linux mint software at
> first, im now running raspberry pi for pc based on debian
> with the same resulits. can you please help.
> Glenn biagioni ve7beh
> vancouver 
> canada
> 

Hi Glenn,

maybe you can give some more information about what you observe:

- Do you have a tranceiver coupled?
- What does it do when you command ':ssb'? Here it switches to SSB and
  tlf shows ssb mode.
- Can you please try to add SSBMODE as keyword in the logcfg.dat file
  and start tlf? What happens?
- What version of tlf do you have?

If nothing helps please send my your logcfg.dat per privat mail. 

73, de Tom DL1JBE

-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Country/Continent Scoring - Request for Comment

[Thomas Beierlein]

Hi all,

the actual country/continent scoring logic in TLf is quite complex.

There are some ideas to make it more robust and easier to use. Please
have a look at https://github.com/Tlf/tlf/issues/178

I would like to ask for any comments, especially for potential problems
you are aware of.

73, de Tom DL1JBE

-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Rules file for SAC contest

[Thomas Beierlein]

Hi Pontus,

the keywords are documented in the man page. 

What is missing is a detailed description of possible combinations and
internal precedences. At the moment I am working on such a
documentation but it will take a littel more time.

73, de Tom


Am Sat, 29 Aug 2020 15:16:36 +0200
schrieb Pontus Falk :

> Hi,
> 
> I will try to use tlf in Scandinavian Activity Contest.
> 
> To understand how to make the rule file for both Scandinavian stations
> as well as for non-Scandinavians I would like to know if there are a
> place where all the keywords for the rule files are explained?
> 
> Best 73's de SM0RUX Pontus
> 
> 


-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: STAYHOME Contest

[Thomas Beierlein]

Am Fri, 5 Jun 2020 10:29:57 -0300
schrieb Carlos Alberto :

> Hello Rein and friends... 73 ...
> How can I add a list of multipliers
>  for the COVID contest, from STAYHOME stations?
> Thank you.
> RULES:
> https://www.dropbox.com/s/t8sj9o6ms90bc0c/COVID%20RULES%20FINAL%2007%20rev7_rules.pdf?dl=0
> 
> 

Hi Carlos,

I fear there is no way to support it directly with TLF.
As the additional multiplier depends on the partners call sign TLF
has no mechanism to base the mult on that field.

I would suggest to simply use COUNTRY_MULT and prepare your macros to
send your age. That way you have at least the country mults right.

As the rules state:

"Since none of the existing software can score the logs, leave it up to
the organizers to do this:"

73, de Tom DL1JBE
-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: A unified color scheme?

[Thomas Beierlein]

Am Sun, 24 May 2020 07:38:35 -0500
schrieb Nate Bargmann :

> * On 2020 24 May 02:46 -0500, Thomas Beierlein wrote:
>  
> > it is as soon as TLF does not know the TERM setting. Atm it
> > recognizes 'xterm', 'xterm-256color' and 'rxvt' (with
> > 'rxvct-unicode' added in next days). All other settings will
> > respect TLFCOLORS.  
> 
> I'd like to think we could maintain the current palette with those
> TERM types but also respect TLFCOLORSn.
> 
Feel free to experiment in that direction. The relevant parts are in
main.c, function ui_init() which parses the TERM variable,
ui_color_init() which sets the colors and in parse_logcfg.c the parsing
of the TLFCOLOR settings (it seems we have 8 colors but TLFCOLOR allows
only to change 6 of them - another long standing bug).

There is one additional function modify_attr() in ui_utils.c which adds 
BOLD if not in xterm or urxvt. I think that is the place where the
additional highlighting for linux console takes place.

> > As handling of STANDOUT, BOLD and other attributes are inconsistent
> > between the emulators I could check I fear that we will not be able
> > to reach that goal.   
> 
> At the risk of being critical, as I see it, the real culprit is the
> general use of STANDOUT for many screen elements.  Yet, I do see its
> value and why Rein originally chose to go this route.  At that time
> the default VGA console screen was often not as bright as the GUI
> screen owing to each being different hardware, as I understand it, and
> especially with portable operations outdoors the use of STANDOUT gave
> text that was readable under such conditions.  The Linux console
> appears to be unique in its ability to display bright text on a bright
> background.  This has carried forward now where the framebuffer is
> used for the console.
> 
Hmm. I always got the idea that the extensive use of STANDOUT was
prompted by the wish to get a white background for the program. Without
it you will get only gray and that does not look so good in the linux
console. The other colors were chosen for a good contrast.

But anyway I spent a lot of time in last years trying to get a
consistent color experience - I assume quite a bit of my gray hairs are
coming from that direction. So any ideas and contributions are welcome.

73 for now,
Tom DL1JBE

> The problem is that the GUI terminals lack this ability with STANDOUT.
> I'm not sure if the reason is a technical limitation of X or a design
> decision.  Regardless, these are the things to consider.  One thing
> that might get close to unity is not using STANDOUT but BOLD on a
> normal background on GUI terminals.
> 
> > Just my 2 cents.  
> 
> Valued, as always.
> 
> 73, Nate
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--



pgpIaEQOHD8aO.pgp
Description: Digitale Signatur von OpenPGP

Re: A unified color scheme?

[Thomas Beierlein]

Hi to all of you,

Am Sat, 23 May 2020 20:52:00 -0500
schrieb Nate Bargmann :

> Hi Matthew and Jim.  Thanks for sharing your screenshots and thoughts!
> 
> Are either of you customizing the colors through the respective
> terminal settings (Konsole)/Xresources (Rxvt) or through LOGCFG.DAT?
> 
> I don't want to break existing setups if at all possible.  Tom made
> mention that TLFCOLORn only works if the TERM variable is not set, or
> is it only if it is "linux"?  

it is as soon as TLF does not know the TERM setting. Atm it recognizes
'xterm', 'xterm-256color' and 'rxvt' (with 'rxvct-unicode' added in
next days). All other settings will respect TLFCOLORS.

> As I see it, the user should be able to
> set TLFCOLORn regardless of the setting of TERM.  The manual page is
> rather light on details for this setting.  At the least I should
> probably document the default colors available from ncurses.
> 
> One of my thoughts was to encourage users, especially newcomers to
> Xterm/Rxvt, to start from the common VGA palette so a reasonable color
> scheme is the starting point.  Still the ability for advanced users to
> customize the scheme must be preserved.
> 
> Ideally, it would be possible for the user to manage all the color
> scheme through Tlf regardless of the setting of TERM or the terminal
> color palette.  It remains to be seen if this ideal can be reached.
>
As handling of STANDOUT, BOLD and other attributes are inconsistent
between the emulators I could check I fear that we will not be able to
reach that goal. 

Just my 2 cents.

73, de Tom DL1JBE

> Thanks for the food for thought.
> 
> 73, Nate
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--



pgp9xJAMnS2w3.pgp
Description: Digitale Signatur von OpenPGP

Re: A unified color scheme?

[Thomas Beierlein]

Am Sat, 23 May 2020 13:01:38 -0500
schrieb Nate Bargmann :

> 
> > The screenshots are coming through. I guess forst screen shot is
> > from pure Linux console, second one from xterm with your Xresource
> > file and the last from urxvt?
> > 
> > The problem with the different shades of white in the last
> > screenshot may be solved by setting a pure TERM=xterm. I had
> > similar problems in the past with the introduction of
> > xterm-256color not handled properly.  
> 
> I'll attach a shot of URxvt where I started Tlf as:
> 
>   TERM=xterm-256color tlf
> 
> it is not much different, if at all.

I did some experiments in meantime. Old urxvt (some years ago) had
TERM=rxvt set, which is recognized by TLF. Newer version seems to use
TERM=rxvt-unicode, but that is not recognized.

You can verify by setting TERM back to 'rxvt'. 

I will add a fix to the code to recognize both TERM settings.

> 
> What I see of the UI code in Tlf is that rxvt is handled such that it
> tries to play the part of the Linux console.
> 
The actual (simplified) logic is as follows:

* If a TERM setting is not known, we assume a pure linux console and
  respect the TLFCOLOR variables.

* For TERM in 'xterm', 'xterm-256color', 'rxvt' and (shortly in)
  'rxvt-unicode' we use fixed color settings according to the choosen
  TERM value.


> > > Instead, I think that simply unifying Xterm and URxvt and leaving
> > > the console alone is a better idea.  
> 
> > For the time being I think it may be a good decision.   
> 
> I did get private feedback from a user that prefers the console so I
> think it should be left well enough alone.
> 
ok, thanks for the feedback.

> As for Xterm and URxvt, I think if Tlf just treats them the same as
> far as colors are concerned and recommend using our Xresources, then
> I think we'll have a good level of consistency.  Actually, I am
> unsure of people choosing URxvt instead of Xterm these days but some
> may.  Plus, this has become a bit of an interesting subproject of
> mine.
> 
I will add an entry to the FAQ recommending these settings.

> 
> The reason I am promoting Xterm is due to it not consuming the key
> combinations that other terminals consume.  Keys like F11 and
> Ctl-PgUp/PgDn come to mind.  Xterm also supports anti-aliasing with
> TrueType fonts these days so it can look quite nice on the modern
> desktop (I'm using Gnome these days).
> 
There is also F1 which is used in some desktop environments for
invoking help. xterm is quite a good choice here.


73, de Tom DL1JBE


-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--



pgpxhnda4afGi.pgp
Description: Digitale Signatur von OpenPGP

Re: Rethinking the need for CT compatible mode

[Thomas Beierlein]

Am Thu, 21 May 2020 07:19:00 -0500
schrieb Nate Bargmann :

> What's the thinking on this?  I'd like to simplify the code page and
> the man page, if possible.
> 
> 73, Nate
> 

Hi Nate,

thanks you brought it on the table again.

The last comments from Fred DH5FS questioned the use of the
Enter-send-message scheme for QSO input. Thinking about it we should
make sure that we can log a QSO via ESM and also without. 

Correct me if I am wrong: Atm the only way is using ESM or working in
CT mode?

I for myself see no need to keep the CT mode but We should strongly
check that you can enter a QSO without ESM.

73, de Tom

-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--



pgp98mxDhtyTU.pgp
Description: Digitale Signatur von OpenPGP

Re: A unified color scheme?

[Thomas Beierlein]

Hi Nate,

these are really good and valid points. From my experience in last
years I can confirm that color handling via ncurses is quite some
nightmare especially when you use a terminal emulator under X. 

So thanks for the link below with some thorough discussion about the
problems. 

Am Fri, 22 May 2020 06:14:19
-0500 schrieb Nate Bargmann :

> I've long kind of poked at the color scheme in Tlf but really haven't
> done much about it.  As it is currently coded there are checks of the
> TERM environment variable for the values of 'rxvt', 'xterm' and
> 'xterm-256color'.  I see no explicit test for a TERM value of 'linux'
> but yet such a setting has an effect.
> 
> The Linux console generally features the classic VGA color palette
> though it can be changed and I have found the Ubuntu releases to be
> guilty of doing so.  In fact, I delved into this over this past winter
> and came away with some understanding and wrote about it on my blog:
> 
> https://www.n0nb.us/blog/2020/02/coping-with-color-on-the-linux-console-and-xterm-and-friends/
> 
> The first half of the post concerns the console and the second half
> Xterm and RXvt.
> 
> As the man page has carried mention that Tlf is a console program for
> a long time, it appears the color scheme has been crafted for the
> console. However, I suspect most of us run Tlf in a terminal emulator
> in a GUI desktop and the colors don't match the console.  The
> difference is not serious but it does show many inconsistencies.  For
> example, on the console the header line is bright yellow text on a
> bright green background.  In my experiments the terminal emulators
> simply cannot display this combination.  

Right most emulators allow only bright foreground but no bright
background. I think that was the reason for using inverted color
pairs in TLF from the beginning.

If you look to other programs using ncurses few uses a white/gray
background. Better combinations results from having blue as background
and using white of yellow letters. But I think that is to much to
change now.

> A heavier weight of brown
> text on a bright green background can be shown that is visually quite
> different from the console.  This has to do with using the ncurses
> A_STANDOUT attribute on the color pair that also inverts the color
> pair.
> 
> I've submitted a pull request that provides a sample Xresources file
> for Xterm and URxvt to use a VGA color palette.  I've also attached
> screenshots (I hope they make it through) that show Tlf on the
> console, in an Xterm, and finally in URxvt.

As I wrote on the PR I like that settings. It is nearly the same as
xterm or xterm-256 on Xfce's terminal emulator. It gives a good
contrast but without being strenuous to the eyes.

The screenshots are coming through. I guess forst screen shot is from
pure Linux console, second one from xterm with your Xresource file and
the last from urxvt?

The problem with the different shades of white in the last  screenshot
may be solved by setting a pure TERM=xterm. I had similar problems in
the past with the introduction of xterm-256color not handled properly.

> I've tried invoking Tlf as 'TERM=xterm tlf' (TERM=xterm-256color works
> too) on all three terminals and it appears to be the most consistent
> color scheme.  Is this something we should aim for to simplify the
> code a little bit, although I'll admit it may not be the most
> readable on the console.  Instead, I think that simply unifying Xterm
> and URxvt and leaving the console alone is a better idea.
> 
For the time being I think it may be a good decision. 
As a reminder: If TERM is NOT set to xterm or rxvt TLF assumes you are
using plain linux console and allows you to set the colors via TLFCOLOR=

73, de Tom DL1JBE


-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--



pgpXy_7YijEV7.pgp
Description: Digitale Signatur von OpenPGP

Re: Problems with CQ-M contest / a 3rd way -- correction

[Thomas Beierlein]

Sorry there was something worng in my last mail.


Am Fri, 8 May 2020 10:21:43 +0200
schrieb Thomas Beierlein :

> Write all countries from AS into an file and use it for COUNTRYLIST.
> Set COUTNRY_LIST_POINTS to 2.
> 
> The format of the file should be:
> 
> contestname: cty1, cty2, cty3, 
> 
> The line HAS to start with the contest name (CONTEST=) and should
> be no longer than 250 characters. 

The following sentence is wrong. All countries must be on ONE line only.

> If needed use additional lines (all
> starting with the contestname).
> 

73, Tom


-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Problems with CQ-M contest / a 3rd way

[Thomas Beierlein]

There is another way to fix the problem but needs quite more work.

Write all countries from AS into an file and use it for COUNTRYLIST.
Set COUTNRY_LIST_POINTS to 2.

The format of the file should be:

contestname: cty1, cty2, cty3, 

The line HAS to start with the contest name (CONTEST=) and should
be no longer than 250 characters. If needed use additional lines (all
starting with the contestname).

Further set MY_COUNTRY_POINTS and MY_CONTINENT_POINTS to 2 and
DX_POINTS to 3.

That should work with the current implementation.

73, de Tom

Am Fri, 8 May 2020 09:56:55 +0200
schrieb Thomas Beierlein :

> Hi,
> 
> you are right. After CQM changed their scoring rules we got a problem.
> Thanks for pointing it out. 
> 
> I did a quick check of the code. As it looks the CONTINENTLIST
> features is not well thoughed out. It is used to control acceptance
> of countries as multi and also to control the given points (but only
> if USE_CONTINENTLIST_ONLY is set). There seems to be still some more
> problems.
> 
> If USE_CONTINENTLIST_ONLY is set you have to give points to your own
> continent with MY_CONTINENT_POINTS even if it is in the list (that
> fixes the -1 for european stations).
> But the downside is that other continents not in list will not scored
> at all, neither for multi nor for points.
> 
> That means in current version there is no workable configuration for
> the problem.
> 
> As for the coming contest:
> 
> - you can just set TWO_POINTS in the rules and accept that stations
>   from continents beside EU and AS are counted wrong
> 
> - I will try to prepare a quickfix, but am not sure if I can make it
> in time.
> 
> 73, de Tom DL1JBE
> 
> Am Thu, 7 May 2020 23:48:38 +0100
> schrieb SP3RXO :
> 
> > Hi all,
> > I'm trying to set tlf 1.4.1 for CQ-M Contest and either I'm doing 
> > something wrong or tlf.
> > In this contest both Asia and Europe as Eurasia giving 2 points per
> > QSO. So in my rules file:
> > 
> > CONTINENTLIST=EU,AS
> > CONTINENT_LIST_POINTS=2
> > SHORT_SERIAL
> > COUNTRY_MULT
> > SERIAL_EXCHANGE
> > 
> > Efect: Tlf giving for both EU and AS stations 0 (zero) points. Bad.
> > 
> > I went on playing with rules file and I added
> > USE_CONTINENT_LIST_ONLY just for check:
> > 
> > CONTINENTLIST=EU,AS
> > CONTINENT_LIST_POINTS=2
> > USE_CONTINENT_LIST_ONLY
> > SHORT_SERIAL
> > COUNTRY_MULT
> > SERIAL_EXCHANGE
> > 
> > Now AS stations are worth 2 points (correct), but EU stations... -1 
> > (minus 1 point).
> > 
> > Screen shot1 https://www.dropbox.com/s/rnbhzpnq1wdnqq2/cqm.png?dl=0
> > Screen shot2 https://www.dropbox.com/s/f59lr2c1y51ox3e/log.png?dl=0
> > 
> > Any ideas whats going wrong?
> > 
> > Thanks,  
> 
> 
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Problems with CQ-M contest

[Thomas Beierlein]

Hi,

you are right. After CQM changed their scoring rules we got a problem.
Thanks for pointing it out. 

I did a quick check of the code. As it looks the CONTINENTLIST features
is not well thoughed out. It is used to control acceptance of countries
as multi and also to control the given points (but only if
USE_CONTINENTLIST_ONLY is set). There seems to be still some more
problems.

If USE_CONTINENTLIST_ONLY is set you have to give points to your own
continent with MY_CONTINENT_POINTS even if it is in the list (that
fixes the -1 for european stations).
But the downside is that other continents not in list will not scored
at all, neither for multi nor for points.

That means in current version there is no workable configuration for the
problem.

As for the coming contest:

- you can just set TWO_POINTS in the rules and accept that stations
  from continents beside EU and AS are counted wrong

- I will try to prepare a quickfix, but am not sure if I can make it in
  time.

73, de Tom DL1JBE

Am Thu, 7 May 2020 23:48:38 +0100
schrieb SP3RXO :

> Hi all,
> I'm trying to set tlf 1.4.1 for CQ-M Contest and either I'm doing 
> something wrong or tlf.
> In this contest both Asia and Europe as Eurasia giving 2 points per
> QSO. So in my rules file:
> 
> CONTINENTLIST=EU,AS
> CONTINENT_LIST_POINTS=2
> SHORT_SERIAL
> COUNTRY_MULT
> SERIAL_EXCHANGE
> 
> Efect: Tlf giving for both EU and AS stations 0 (zero) points. Bad.
> 
> I went on playing with rules file and I added USE_CONTINENT_LIST_ONLY 
> just for check:
> 
> CONTINENTLIST=EU,AS
> CONTINENT_LIST_POINTS=2
> USE_CONTINENT_LIST_ONLY
> SHORT_SERIAL
> COUNTRY_MULT
> SERIAL_EXCHANGE
> 
> Now AS stations are worth 2 points (correct), but EU stations... -1 
> (minus 1 point).
> 
> Screen shot1 https://www.dropbox.com/s/rnbhzpnq1wdnqq2/cqm.png?dl=0
> Screen shot2 https://www.dropbox.com/s/f59lr2c1y51ox3e/log.png?dl=0
> 
> Any ideas whats going wrong?
> 
> Thanks,



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

TLF-1.4.1 maintenance and bugfix release

[Thomas Beierlein]

After a lot of work by all people contributing to TLF I would like to
announce the release of the new TLF-1.4.1 version.

You can find it at 

https://www.hs-mittweida.de/tb/tlf-1.4.1.tar.gz or at
https://github.com/Tlf/tlf/releases/download/tlf-1.4.1/tlf-1.4.1.tar.gz

Fixed bugs:

- Fix compile error with new GCC-10.

- There are two major fixes for bugs in the scoring logic:
  - For US/VE stations runnin ARRLDX contest intra W/VE qso were counted
which was wrong. New code correctly scores these contacts with 0
points and does not count it as multi.
  - If you running TLF in CQWW 2 TX mode QSO from other stations on LAN
would be counted wrong. Fixed.

Besides some internal improvements there are numerous changes and new
features:

- Thanks to the work of W8BSD from TLF-1.3.1 on TLF could use the CT9
  cty.dat files with full call sign exceptions (marked by =).
  As that version in meantime is widely available, I asked Jim Reiser
  AD1C to provide the CT9 format as default cty.dat file format for
  TLF. That change came in use in the beginning of 2020. If you use
  TLF-1.3.0 or an older version you should look for the old format
  file, which are still available.

- Jim informed further that he would like to switch his server in
  next time to provide these files only via secured access. So please 
  use https://www.country-files.com to download actual cty.dat files.

- Zoli HA5CQZ did some work to make switch back from a grabbed station
  much more easy. His work enables to just grab a needed station from
  the bandmap while running CQ mode and to come back to your running
  frequency and mode after it with only one key press. Read the details
  on https://github.com/Tlf/tlf/pull/155 and the man page. 

- If you have to correct your log file by deleting the last entry TLF
  will now automatically reread your log - no need to request an
  ':rescore' anymore.

- We got a better (and more informational) display of partials and an
  improved handling of WCY/WWV messages (both thanks to Zolis work).

- You can now use any editor for editing the log. If you do not set any
  in the logcfg.dat TLF uses the one from the EDITOR environment
  variable. Be aware that there may be some small problems when using a
  graphical editor - if they go into the background when started you
  have to reload the logfile after edit by hand.

- The ADIF write function supports now V3.10 of the specification.

- Thanks to numerous users there are new contest rules, multiplier
  files and initial exchange lists for the OK/OM contest and CWOPS
  minicontest.

Thanks to all contributors and testers.

For a more detailed discussion of the new features please read the
NEWS file and the man page. 

As always reports about problems (or success) are welcome.


73 es gd DX,  de Tom DL1JBE.


-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: 1.5 release plan

[Thomas Beierlein]

Hi Juanjo,

it is not TLF that produces that beeps. It is coming from your dx
cluster connection. On most of these cluster systems you can configure
to get a beep on DX or not.

See for something like 'UNSET/BEEP' or similar. Most cluster software
does remember your settings. So you have to turn the beeps off yourself.

Please try it and report back.

73, de Tom DL1JBE




 Am
Mon, 20 Apr 2020 01:12:20 +0100 schrieb Juanjo EA8BGO
:

> Hello everyone.
> 
> I would like or appreciate that in the next revision it is not heard
> every time a DX station is announced in the Cluster. It is annoying
> and I end up turning off the speakers.
> 
> Best regards,
> Juanjo
> EA8BGO
> 
> El dom., 19 abr. 2020 a las 18:42, Ervin Hegedüs ()
> escribió:
> 
> > Hi Thomas,
> >
> > On Sun, Apr 19, 2020 at 06:28:01PM +0200, Thomas Beierlein wrote:  
> > > Am Sat, 18 Apr 2020 20:59:20 +0200
> > > schrieb Ervin Hegedüs :
> > >  
> > > > Hi there,
> > > >
> > > > is there any plan to release the version 1.5?
> > > >  
> > > I think an 1.5 is not quite ready. But besides the GCC-10 fixes
> > > there are some useful things in the actual code.
> > >
> > > I think best would be a tlf-1.4.1 version with the actual code.
> > > That should be doable in the coming one or two weeks.  
> >
> > ah - sorry, I just checked the current master version, and I saw
> > it's 1.5-git. It doesn't count the exact version number :).
> >  
> > > Would that fit in Debian time frame?  
> >
> > I think that would - I'll write to reporter.
> >
> >
> > 73, Ervin
> >
> >
> >
> >  



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: 1.5 release plan

[Thomas Beierlein]

Hi Ervin,

Am Sat, 18 Apr 2020 20:59:20 +0200
schrieb Ervin Hegedüs :

> Hi there,
> 
> is there any plan to release the version 1.5?
> 
thanks for the question. 

I think an 1.5 is not quite ready. But besides the GCC-10 fixes there
are some useful things in the actual code. 

I think best would be a tlf-1.4.1 version with the actual code. 
That should be doable in the coming one or two weeks.

Would that fit in Debian time frame?

73, de Tom DL1JBE

> The Debian has an ftbfs (fails to build from source) issue:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=957876
> 
> I checked the build log, but looks like all affected part of code
> had fixed in current master, so the version 1.5 builds as well
> with gcc10.
> 
> If the new version will come, we don't need to make any backport
> patch (this affects only the Debian Sid, if the new version will
> released, we can upload it and problem will solved).
> 
> 
> 
> Thanks, 73:
> Ervin
> 
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Using a Different Configuration File

[Thomas Beierlein]

Hi Austin,

I had a look at the Arch repository. From there I think you have
a tlf-1.3.0 version.

You have two ways to solve your problem:

1. Drop the space between '-f' and the filename, e.g.

$ tlf -fqrpfoxhunt.dat

2. Use a separate directory, name the config file there just
'logcfg.dat' and call tlf without '-f'

$ mkdir ~/tlf/contestdir
$ cp logcfg.dat ~/tlf/contestdir
$ cd ~/tlf/contestdir

  adapt logcfg.dat as you like and finally just call

$ tlf

Hope that solves the problem.

73, de Tom DL1JBE


 Am Tue, 18 Feb 2020 23:32:50 -0500
schrieb "Austin Seraphin, KA3TTT" :

> I installed TLF from the Arch User Repository. The first time I ran
> it, it created ~/tlf, and copied a working file structure into it,
> including rules, a logcfg.dat, and other files. I successfully edited
> the logcfg.dat and began using it, but I can't seem to figure out how
> to use another log file. I tried the obvious way of copying
> logcfg.dat to a new file, say qrpfoxhunt.dat, and invoking with
> 
> tlf -f qrpfoxhunt.dat
> 
> I then read the older documentation, which suggested setting up a
> directory structure. I created ~/tlf/qrpfoxhunt and moved the
> qrpfoxhunt.dat to ~/tlf/qrpfoxhunt/logcfg.dat. I also copied in
> rules/contest. I then tried a number of invocations:
> 
> tlf -f qrpfoxhunt
> 
> tlf -f ~/tlf/qrpfoxhunt
> 
> tlf -f ~/tlf/qrpfoxhunt/logcfg.dat
> 
> but nothing works. What have I missed?
> 
> 
> I use a screen reader for the blind, and think this program would work
> well for me.
> 
> Thanks for your help.
> 
> 
> 
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

TLF - some news

[Thomas Beierlein]

Hi all,

there were some changes and improvements on TLF in last weeks. These
mail tries to summarize the main points:

- Thanks to the work of W8BSD from TLF-1.3.1 on TLF could use the CT9
  cty.dat files with full call sign exceptions (marked by =).
  As that version in meantime is widely available, I asked Jim Reiser
  AD1C to provide the CT9 format as default cty.dat file format for
  TLF. That change came in use in the beginning of 2020. If you use
  TLF-1.3.0 or an older version you should look for the old format
  file, which are still available.

- In last days Jim informed that he would like to switch his server in
  next time to provide these files only via secured access. So from now
  on please use https://www.country-files.com to download actual
  cty.dat files.

- Zoli HA5CQZ did some work to make switch back from a grabbed station
  much more easy. His work enables to just grab a needed station from
  the bandmap while running CQ mode and to come back to your running
  frequency and mode after it with only one key press. Read the details
  on https://github.com/Tlf/tlf/pull/155. Please test and report back if
  you like it.

- If you have to correct your log file by deleting the last entry TLF
  will now automatically reread your log - no need to request an
  ':rescore' anymore.

- We got a better (and more informational) display of partials and an
  improved handling of WCY/WWV messages (both thanks to Zolis work).

- You can now use any editor for editing the log. If you do not set any
  in the logcfg.dat TLF uses the one from the EDITOR environment
  variable. Be aware that there may be some small problems when using a
  graphical editor - if they go into the background when started you
  have to reload the logfile after edit by hand.

There were also some bug fixes for ARRLDX contest and CQWW in 2 TX mode.

There are some more things to do, so I think a new version (maybe
1.4.1) will still have to wait some weeks.

So far for now.

73, de Tom DL1JBE

-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: micromuf

[Thomas Beierlein]

Am Mon, 10 Feb 2020 21:28:18 +0100
schrieb Csahok Zoltan :

> While working on improving the handling of WWV messages
> I did some digital archeology and found that the propagation
> display (Ctrl-P) is a straight port of MICROMUF.PAS, a MUF/LUF tool
> from the 80s. It was originally written in Basic then translated
> to Pascal. Here one can still find both:
> Xs://archives.scovetta.com/pub/simtelnet/msdos/hamradio/
> (replace X with http. I'm unable to post mails with links...)
> 
> I suggest to include the original credits to our source.

Good idea. As you have the details can you please provide a proposal
for it.

> 
> The Pascal version compiles on a 3.7 MHz Z-80 board in 8 seconds
> and drawing the chart takes ~45 seconds. Not that what you'd want
> to do during a contest. Those were different days...
> 
I myself started with an 2MHZ Z-80 homemade system with 2 kB ROM and 2kB
RAM doing assembly by hand. What times

73, de Tom

> For those interested in seeing CP/M and Turbo Pascal 3.01A in action
> here is a 2 min screen recording:
> X://ha5cqz.info.tm/Screencast_micromuf.mp4
> At the end I swithed to TLF's Ctrl-P screen with the same settings
> for comparison.
> 
> This page gives a good review of propagation prediction programs
> X://www.astrosurf.com/luxorion/qsl-review-propagation-software-dos.htm
> 
> 
> 73,
> Zoli
> 
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

BUGFIX for TLF users from W/VE for coming ARRLDX contest

[Thomas Beierlein]

Hi all,

TLF-1.4.0 and older versions are containing a bug in scoring qsos for
the ARRLDX contest. The bug is only effective for stations working from
US and Canada. So all other stations can ignore these mail.

According to the contest rules intra W/VE qsos should not
count as multi and should get 0 points. All released TLF versions does
handle that not correctly.

The problem got fixed in last days. If you want to avoid the problem
you can pick up the latest code from https://github.com/Tlf/tlf and
compile your own actual version. See INSTALL file for instructions and
keep an eye to the needed steps to build the program from the github
repo.

Good luck in coming ARRL DX contest,

Tom DL1JBE
-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Real RST possible?

[Thomas Beierlein]

Am Tue, 28 Jan 2020 16:47:05 -0600
schrieb jim smith :

> On Tue, 28 Jan 2020 20:13:04 +0100
> Thomas Beierlein  wrote:
>   
> > Ok, That would only extend the functionality of CHANGE_RST. If
> > changing only the first two numbers are enough that would be the
> > most easy solution. If key auto repeat does also work for PgUp/PgDn
> > (needs to be tested) you need not to much key presses to sweep over
> > the range. 
> > 
> > Jim, would that solve your needs? If so it can be implemented in
> > next weeks.  
> 
> I think so.  And in any case, I think defer to "make it easiest for
> the 'Run' operator.  If the S&P op has to make a few more keypresses
> to get things done, that's fine.  Also, that final 9 can alwasy be 9
> in RST, IMO.

OK, we will add it to the ToDO list then.

> 
> > > Probably the reason this hasn't been requested before is that
> > > major contest sponsors mostly ignore the signal report for log
> > > checking.
> > 
> > And in contest we ignore the 'real' RST value from the band and stay
> > with 5nn to make more contacts per time.
> > 
> > 73, de Tom  
> 
> I agree with that -- in most contests the RS(T) is a given.  But for
> QRP and especially SOTA operations (where I would *really* like to use
> tlf), it would be most helpful to be able to type in the R and S of
> RST.
> 
> Thanks to all for considering this.  I used tlf in last weekend's
> CQ160m contest, and it never missed a beat.  *I* did, but it did not.

Good to hear :-).

73, de Tom


-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Real RST possible?

[Thomas Beierlein]

Am Tue, 28 Jan 2020 21:42:06 +0100
schrieb Csahok Zoltan :

> > > Tap Page-Dn until '1' is reached and then like an odometer the
> > > first numeral rolls down to '4', the next tap rolls the first
> > > numeral down to '3' and so on while leaving the second numeral at
> > > '1', then tap Page-Up to set the second numeral.  That would
> > > require a few taps of Page-Up until the report of 459 is reached.
> > >   
> > Ok, That would only extend the functionality of CHANGE_RST. If
> > changing only the first two numbers are enough that would be the
> > most easy solution. If key auto repeat does also work for PgUp/PgDn
> > (needs to be tested) you need not to much key presses to sweep over
> > the range.   
> 
> One option could be to let the user configure the preferred reports
> (say 599,559,339) and PgUp/Dn would cycle through them.
> This would save a bunch of keystrokes for a user not needing too
> precise RST.

Sounds good. 
So a possible scheme could be:

CHANGE_RST 
  cycle through all values 599, 589, ..., 539, 499, .., 439,
  399, .., 339

or
CHANGE_RST=599, 559, 339
  to cycle through the named RST values.

> 
> The sequential rolling with PgUp/Dn is not too practical when it comes
> to give someone 338. My feeling is that with a handful configured
> reports one could effectively cover the requirement for sent RST.
> 
Right.

> For received RST direct entry would be better. But that could be done
> with a wider exchange field.

Maybe we should start with using CHANGE_RST here also and add
additional the possibility for a direct change via the comment field if
needed.

One idea is to allow a 'r579' or similar in the comment field
to override the received RST. 'r' makes clear that is it no exchange,
 accepts it and clears the comment field afterwards. That way we
avoid the need to navigate between RST and real comment in the extended
comment field.

73, de Tom

-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Real RST possible?

[Thomas Beierlein]

Am Tue, 28 Jan 2020 07:55:47 -0600
schrieb Nate Bargmann :

> * On 2020 28 Jan 00:29 -0600, Thomas Beierlein wrote:
> > Hi Jim, Nate and Zoli,
> > 
> > we should keep in mind to integrate it in the flow of the qso,
> > especially in contests. 
> > 
> > What I mean is running in CQ mode I need the RST of the other
> > station *before* answering his call and will get his RST in his
> > reply. Running in S&P I would first get my RST from him and only
> > *afterwards* need his RST for my reply. 
> > 
> > Another question is if the operator uses ESM or not.  
> 
> To be honest, Tom, I don't see the way I described changing the
> behavior of Enter or Space.  It would merely modify the RST fields to
> be entry boxes but would be prepopulated with 59[9] as now and Enter
> and Space would skip them.  Tab would move into each in turn from
> Call --> RX RST --> TX RST --> Exchange --> Call (CQWW example).  

You are right. There are some chances in changing the handling of input
fields, but to be honest it would be quite difficult. Reason is that
the code to pick up the call sign and exchange is quite a tangled mess
consisting of three main functions: callinput(), getexchange() and
logit() - the last one tying all different modes (S&P, CQ, dxped and Qso
mode) together. Before we sort that out it would be difficult to make
major changes.

> Your musing of Run vs S&P is a good one.  For the most part, I think
> this is a rather specific use case where the '5' is to be replaced by
> another numeral.  Most of us probably won't use this feature.  ;-)
> 
> Another option is to leave all keys as-is and only modify
> Page-Up/Page-Dn so that they work this way:
> 
> Tap Page-Dn until '1' is reached and then like an odometer the first
> numeral rolls down to '4', the next tap rolls the first numeral down
> to '3' and so on while leaving the second numeral at '1', then tap
> Page-Up to set the second numeral.  That would require a few taps of
> Page-Up until the report of 459 is reached.
> 
Ok, That would only extend the functionality of CHANGE_RST. If changing
only the first two numbers are enough that would be the most easy
solution. If key auto repeat does also work for PgUp/PgDn (needs to be
tested) you need not to much key presses to sweep over the range. 

Jim, would that solve your needs? If so it can be implemented in next
weeks.

> Probably the reason this hasn't been requested before is that major
> contest sponsors mostly ignore the signal report for log checking.

And in contest we ignore the 'real' RST value from the band and stay
with 5nn to make more contacts per time.

73, de Tom





-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Anyone using TLF for ARRLDX contest from W or VE?

[Thomas Beierlein]

Hi all,

I am in the process to rework and check scoring in TLF. Reading the
code it seems that the 'arrldx_usa' rules implementation is broken for
a long time:

For US/VE stations it should score any country out of W/VE as Multi and
score 3 points per qso. Any QSOs to other W/VE stations should give no
points and no multi.

It seems that TLF ignores the last rule and scores intra W/VE contacts
like any other qso.

Can someone confirm that behaviour? 

73, de Tom

-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Real RST possible?

[Thomas Beierlein]

Hi Jim, Nate and Zoli,

we should keep in mind to integrate it in the flow of the qso,
especially in contests. 

What I mean is running in CQ mode I need the RST of the other
station *before* answering his call and will get his RST in his reply.
Running in S&P I would first get my RST from him and only *afterwards*
need his RST for my reply. 

Another question is if the operator uses ESM or not.

73, Tom




Am Mon, 27 Jan 2020 20:52:46 +0100
schrieb Csahok Zoltan :

> Hi Nate,
> 
> Everything is possible. :-)
> 
> An option I see could be making the exchange box wider to span the
> RST fields and let the user input the values. Optionally pre-fill
> with 599/59. Then upon storing the qso we would parse the first 2
> words and store them as RSTs.
> 
> A bit tedious for the user to fill and navigate within the exchange
> field, but I assume these use cases are not focused on high Q rates.
> 
> 
> 73,
> Zoli
> 
> 
> On Sun, Jan 26, 2020 at 06:26:36PM -0600, Nate Bargmann wrote:
> > * On 2020 26 Jan 15:45 -0600, jim smith wrote:  
> > > First, I know there is the CHANGE_RST directive, but for QRP
> > > contests (at least in the states), many times ops send an actual
> > > RST -- 33N, 439, etc.  Is there any way to incorporate this in
> > > both the received stations data (I imagine it would be in the
> > > exchange field, like a serial number) and for  the sending
> > > station?
> > > 
> > > It would be helpful the above mentioned QRP contests, general
> > > ragchews and for SOTA operations as well.  
> > 
> > I have seen other loggers handle this so that in the case of Tlf,
> > Space would move the cursor from Call to the Exchange/Comment field
> > and Tab would cycle through all fields, i.e., Call-->RX RST-->TX
> > RST-->Exch-->Call, etc.
> > 
> > As it is now, Space jumps from Call to Exch and then Tab must be
> > used to go back to Call as Exch can contain spaces to separate
> > exchange elements in some events.  Loggers such as N1MM+ create
> > additional field entry boxes depending on the event and Space is
> > not allowed in any of them so it can be used as a "smart tab" that
> > jumps over RST fields, if present, and through all the other fields.
> > 
> > The way Tlf is structured, it would take a lot to have separate
> > exchange fields, but it seems as though having Tab cycle through
> > all the fields could be doable.  As I see it, when Tab enters an
> > RST field it could place the cursor under the first '9' and from
> > there the field edited as needed.  I'm afraid I don't have the time
> > to code it for some months so maybe someone else can pick up the
> > idea if it is thought to be a good one and add it.
> > 
> > 73, Nate
> >   



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Rethinking the need for CT compatible mode

[Thomas Beierlein]

Hi Fred,

some time ago Ervin provided a SPRINTMODE keyword for that kind of
contests. Did you had a chance to check if it is what you need?

73, de Tom

Am Sun, 12
Jan 2020 23:14:36 +0100 schrieb Fred Siegmund :

> I use it for the german XMAS contest. As this is a sprint, where you 
> have to leave QRG after CQ, I don't like ESM (and changing between CQ 
> and S&P all the time).
> 
> 73 Fred
> 
> Am 12.01.20 um 19:48 schrieb Thomas Beierlein:
> > Hi Nate and Zoli,
> >
> > in last days I checked the mailing list archive and my personal
> > remarks. As far as I found Nate you were the first one to ask about
> > the CT mode compatibility in last 5 years.
> >
> > So it seems that there is not so much interest in it.
> >
> >  From my point of view I am open for removal.
> >
> > 73, de Tom DL1JBE
> >
> > Am Fri, 10 Jan 2020 10:39:54
> > +0100 schrieb Csahok Zoltan :
> >  
> >> Hi Nate,
> >>
> >> Personally I always use the default TLF mode and quite happy with
> >> it. Removing CT compatibility is fine with me.
> >> I didn't quite get the difference between the current and the
> >> optional new mode, though. (I'm not a regular N1MM user)
> >>
> >> 73,
> >> Zoli
> >>
> >>
> >> On Tue, Jan 07, 2020 at 08:27:55PM -0600, Nate Bargmann wrote:  
> >>> I recently did a bit of fixup to the CT compatible mode but I find
> >>> that its original choice of keystrokes to not be optimal.  As I
> >>> added support for some keys used in N1MM+ when ESM is disabled,
> >>> the code became even more convoluted and opaque.
> >>>
> >>> I realized that CT compatible mode had been broken for so long
> >>> that there really must not be anyone using it, so why keep it?
> >>>
> >>> Removing it would simplify the code in several places.
> >>>
> >>> In its place I would consider adding support for the apostrophe "
> >>> ' " to send the CQ_TU_MSG or S&P_TU_MSG.
> >>>
> >>> I would consider providing a :CFG keyword or keystroke combination
> >>> to toggle Enter from ESM to a mode where with the call field empty
> >>> Enter sends MYCALL and otherwise would only log a QSO when both
> >>> the call and exchange fields are populated depending on
> >>> validation.
> >>>
> >>> Thoughts?
> >>>
> >>> 73, Nate
> >>>  
> >
> >  



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Rethinking the need for CT compatible mode

[Thomas Beierlein]

Hi Nate and Zoli,

in last days I checked the mailing list archive and my personal
remarks. As far as I found Nate you were the first one to ask about
the CT mode compatibility in last 5 years. 

So it seems that there is not so much interest in it.

From my point of view I am open for removal. 

73, de Tom DL1JBE

Am Fri, 10 Jan 2020 10:39:54
+0100 schrieb Csahok Zoltan :

> Hi Nate,
> 
> Personally I always use the default TLF mode and quite happy with it.
> Removing CT compatibility is fine with me.
> I didn't quite get the difference between the current and the
> optional new mode, though. (I'm not a regular N1MM user)
> 
> 73,
> Zoli
> 
> 
> On Tue, Jan 07, 2020 at 08:27:55PM -0600, Nate Bargmann wrote:
> > I recently did a bit of fixup to the CT compatible mode but I find
> > that its original choice of keystrokes to not be optimal.  As I
> > added support for some keys used in N1MM+ when ESM is disabled, the
> > code became even more convoluted and opaque.
> > 
> > I realized that CT compatible mode had been broken for so long that
> > there really must not be anyone using it, so why keep it?
> > 
> > Removing it would simplify the code in several places.
> > 
> > In its place I would consider adding support for the apostrophe " '
> > " to send the CQ_TU_MSG or S&P_TU_MSG.
> > 
> > I would consider providing a :CFG keyword or keystroke combination
> > to toggle Enter from ESM to a mode where with the call field empty
> > Enter sends MYCALL and otherwise would only log a QSO when both the
> > call and exchange fields are populated depending on validation.
> > 
> > Thoughts?
> > 
> > 73, Nate
> >   



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: padding in cwdaemon packets

[Thomas Beierlein]

Hi Drew and Zoli,

Am Sun, 8 Dec 2019 17:51:12 +0100
schrieb Csahok Zoltan :

> Hi Drew,
> 
> Trailing zero and newline have most likely historical origin.
> 
> The zero was introduced abt 9 years ago in this commit:
> https://github.com/Tlf/tlf/commit/5a2be34d01b296bc8b8d8b362407cc3077e3c6d8#diff-8be0c8c50997da170641d3392ba81b5a

At that time it was unclear if cwdaemon needed a the send message as a
zero terminated string or not, so I added it to be sure.

Actual it seems that it is not needed. We can revert that commit.

73, de Tom


> Apparently cwdaemon needed it. Now it does not for sure, neither any
> newline. It actually removes NL:
> https://github.com/acerion/cwdaemon/blob/master/src/cwdaemon.c
> (line 1140)
> 
> winkeydaemon as a defensive measure silently ignores non-processable
> characters. Probably cwdaemon (libcw) does the same.
> 
> Technically the trailing NL is a result of not chopping it after
> fgets(). While for CW it is irrelevant, it might make sense for
> digital modes. Not sure, though, as digital keyer code could add NL
> on its own.
> 
> So all in all I think we could get rid of both trailing chars without
> issues.
> 
> 73,
> Zoli
> 
> 
> On Sat, Dec 07, 2019 at 04:35:28PM +, Drew Arnett wrote:
> > Doing some debugging and cleanup of my pywinkerdaemon implementation
> > of cwdaemon.  (I introduced some bugs with recent feature
> > introduction.)
> > 
> > A few years ago, I looked at the UDP packets several different
> > cwdaemon clients sent.  Some, like TLF, send a single trailing null
> > character which is not needed.  Some sent quite a lot.  (Allocated a
> > max UDP data structure, wrote nulls, then wrote the message to the
> > beginning.  Still, should have not bothered transmitting all that
> > padding.)
> > 
> > Looking at tlf as included in debian 10.2 today, I see it also has a
> > \n (0x0a) character between the end of the CW message and the single
> > null character.
> > 
> > I recommend that tlf doesn't transmit either the 0x0a or the 0x00
> > trailing characters.  Unless this would break other independent
> > cwdaemon implementations.  Anybody know?
> > 
> > Best regards,
> > 
> > Drew
> > n7da  



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Preparations for TLF-1.4.0 release

[Thomas Beierlein]

Hi Slav,

ok, it seems you found the real way how it works.

After reading the ADIF spec I see one problem here. The contest name
itself is defined as an enumeration of predefined contest IDs (see
https://adif.org/310/ADIF_310.htm#Contest_ID for reference).
So we can not just use our own contest name from logcfg.dat for itbut
have to use one of the predefined. That will result in an non standard
ADIF format. 

I see two ways to work around the problem:

a) Just ask the operator for the contest name to use and insert it into
each qso record. Leave it out if the operator does not enter a name.

or

b) just leave the file format as it is. Post process the ADIF-file with
a tool like 'adifmerg' from oh7bf to insert the contest_id into the ADIF
records if needed. E.g. a command like 
'adifmerg -f qso.adi -A CONTEST_ID=ContestName -o > file.adi'
should do.

If not needed regularly I would like to stay with the second version.
What do others think about it?

73, de Tom



Am Sun, 1 Dec 2019 18:17:36 +
schrieb SP3RXO :

> Hi Tom,
> Thanks for adding Contest Name to ADIF file, but it is not giving the
> same result as after import ADIF from N1MM to general logging program,
> in my case CQRLOG.
> I've checked ADIF produced by N1MM today and I found that each QSO
> record (each logged QSO) has a field CONTEST_ID:9 which contains
> exactly the same string like in CONTEST NAME.  IMHO it will do the
> job. See below:
> 
> > ADIF Export from N1MMLogger.net - Version 1.0.8018.0
> > Built: 26.11.2019 13:57:32
> > EI2IDB logs generated @ 2019-12-01 11:49:56Z
> > Contest Name: RUS-WW-MM - 2019-11-30
> > 
> >  UR7GO 20191130 120534
> > 120534 20M EI2IDB
> > 14.01095 RUS-WW-MM 14.01095
> > CW 599 599 100
> > EI2IDB 6 16 1
> > 6 3 1
> > EU 1
> > 1 True
> > DESKTOP-2OSIL1H 0
> >   
> 
> ADIF Specification:
> https://adif.org/306/ADIF_306.htm#QSO_Field_CONTEST_ID
> 
> Thanks,
> 
> 73! de
> Slav, SP3RXO & EI2IDB
> FISTS #19019
> SOC #1251
> SP CW Club #UNKNOWN
> 
> W dniu 01.12.2019 o 08:56, Thomas Beierlein pisze:
> > Hi Slav,
> > 
> > please have a look at
> > https://github.com/dl1jbe/tlf/tree/adif_with_contest_name
> > 
> > I added the contest name from logcfg.dat to the ADIF file.
> > There could be more information given, but it should do for the
> > moment.
> > 
> > Can you please test and report back?
> > 
> > 73, de Tom 
> > 
> >  Am Mon, 4 Nov
> > 2019 20:11:12 + schrieb SP3RXO :
> >   
> >> Hi, Tom
> >> Here is few lines from n2mm's log showing Contest name line. As
> >> general logger I am using cqrlog and contest name is fine imported
> >> to cqrlog.
> >>
> >> ADIF Export from N1MMLogger.net - Version 1.0.7983.0
> >> Built: 29.10.2019 13:15:00
> >> EI2IDB logs generated @ 2019-11-03 11:42:45Z
> >> Contest Name: UKRAINDX - 2019-11-02
> >> 
> >>  UY5ZZ 20191102 120343
> >> 120343 KO 20M
> >> EI2IDB 14.02500
> >> UKRAINIAN-DX 14.02500 CW
> >> 599 599 100 EI2IDB
> >> 16 1 KO 10
> >> 1 EU
> >> 1 1
> >> True
> >> DESKTOP-2OSIL1H 0
> >> 
> >>
> >> 73!
> >> Slav, SP3RXO & EI2IDB
> >> FISTS #19019
> >>
> >> W dniu 04.11.2019 o 19:06, Thomas Beierlein pisze:  
> >>> Hi Slav,
> >>>
> >>> reading through the ADIF specification at
> >>> http://adif.org.uk/310/ADIF_310.htm
> >>> I can find only a reference to a CONTEST_ID but no 'contest name'
> >>> entry.
> >>>
> >>> Can you please post some lines from an example ADIF log from N1MM
> >>> showing the proposed entry?
> >>>
> >>> It is a litlle bit late for TLF-1.4.0 but we can add it to the
> >>> ToDo list.
> >>>
> >>> 73, de Tom DL1JBE
> >>>
> >>>
> >>>
> >>>  Am Mon, 4 Nov 2019 10:24:07 +
> >>> schrieb SP3RXO :
> >>> 
> >>>> Hi all,
> >>>> Can the "Contest name:" line be added to the header of the
> >>>> exported adif file?
> >>>> Example:
> >>>> Contest Name: UKRAINDX - 2019-11-02
> >>>> It's is in n1mm logger and quite useful.
> >>>>
> >>>> 73!
> >>>> Slav, SP3RXO & EI2IDB
> >>>> FISTS #19019
> >>>>
> >>>> W dniu 28.10.2019 o 06:09, Thomas Beierlein pisze:
> >>>>> Hi all,
> >>>>>
> >>>>> time for a new TLF-1.4.0 release is overdue. I plan to do finish
> >>>>> it in next days. If there are some late contributions please let
> >>>>> me know.
> >>>>>
> >>>>> 73, de Tom DL1JBE
> >>>>>   
> >>>
> >>>
> >>> 
> > 
> > 
> >   



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Preparations for TLF-1.4.0 release

[Thomas Beierlein]

Hi Slav,

please have a look at
https://github.com/dl1jbe/tlf/tree/adif_with_contest_name

I added the contest name from logcfg.dat to the ADIF file.
There could be more information given, but it should do for the moment.

Can you please test and report back?

73, de Tom 

 Am Mon, 4 Nov
2019 20:11:12 + schrieb SP3RXO :

> Hi, Tom
> Here is few lines from n2mm's log showing Contest name line. As
> general logger I am using cqrlog and contest name is fine imported to
> cqrlog.
> 
> ADIF Export from N1MMLogger.net - Version 1.0.7983.0
> Built: 29.10.2019 13:15:00
> EI2IDB logs generated @ 2019-11-03 11:42:45Z
> Contest Name: UKRAINDX - 2019-11-02
> 
>  UY5ZZ 20191102 120343
> 120343 KO 20M
> EI2IDB 14.02500
> UKRAINIAN-DX 14.02500 CW
> 599 599 100 EI2IDB
> 16 1 KO 10
> 1 EU
> 1 1
> True DESKTOP-2OSIL1H
> 0 
> 
> 73!
> Slav, SP3RXO & EI2IDB
> FISTS #19019
> 
> W dniu 04.11.2019 o 19:06, Thomas Beierlein pisze:
> > Hi Slav,
> > 
> > reading through the ADIF specification at
> > http://adif.org.uk/310/ADIF_310.htm
> > I can find only a reference to a CONTEST_ID but no 'contest name'
> > entry.
> > 
> > Can you please post some lines from an example ADIF log from N1MM
> > showing the proposed entry?
> > 
> > It is a litlle bit late for TLF-1.4.0 but we can add it to the ToDo
> > list.
> > 
> > 73, de Tom DL1JBE
> > 
> > 
> > 
> >  Am Mon, 4 Nov 2019 10:24:07 +
> > schrieb SP3RXO :
> >   
> >> Hi all,
> >> Can the "Contest name:" line be added to the header of the exported
> >> adif file?
> >> Example:
> >> Contest Name: UKRAINDX - 2019-11-02
> >> It's is in n1mm logger and quite useful.
> >>
> >> 73!
> >> Slav, SP3RXO & EI2IDB
> >> FISTS #19019
> >>
> >> W dniu 28.10.2019 o 06:09, Thomas Beierlein pisze:  
> >>> Hi all,
> >>>
> >>> time for a new TLF-1.4.0 release is overdue. I plan to do finish
> >>> it in next days. If there are some late contributions please let
> >>> me know.
> >>>
> >>> 73, de Tom DL1JBE
> >>> 
> > 
> > 
> >   



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: TLF-1.4.0 release

[Thomas Beierlein]

Am Sat, 23 Nov 2019 18:30:01 -0600
schrieb Nate Bargmann :

> * On 2019 23 Nov 08:14 -0600, Drew Arnett wrote:
> > Resize is fine, but please continue to support 80x25 long term.  I
> > don't see classic TUI losing value anytime soon.  
> 
> Do you mean that Tlf should enforce a minimum 80x25 terminal size as
> it has in the past?  Personally, I've no problem with that.

'Enforcing' is a little bit difficult as (as far as I know) we can not
force a minimum size on any xwindow. But I will leave the warning in
place that you should have at least 25 lines in your terminal. 
> 
> > What about a 2nd application, tlf-config or easy-tlf-config, which
> > would have the pulldown menus etc for setting up config files.  Keep
> > the pulldown menus out of tlf.  Once you add menus, you'll add a
> > bunch of hotkeys.  One of the nice things about TLF is that there
> > aren't a bunch of live keys, especially if run out of a console or
> > terminal rather than a windows manager.  
> 
> That's actually a very good idea, Drew.  If such a program were to
> gain good enough coverage then the :SET and :CFG commands could just
> call it instead of an editor.  As for hot keys, Tlf does have quite a
> few assigned already.
> 
Ok, I really like these idea. I will add it as an alternative to
the ToDo entry for the configuration menu.

73, de Tom



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--



pgpE6moQk532b.pgp
Description: Digitale Signatur von OpenPGP

Re: tlf and the nano editor

[Thomas Beierlein]

Very nice. Glad to hear it.

So it seems the new editor feature is running well. I will wait two or
three more days. If no one has problems with it, I will merge the patch
into the master version.

73, de Tom 

Am Mon, 25 Nov 2019 12:35:25 -0600 schrieb Nate
Bargmann :

> * On 2019 25 Nov 07:46 -0600, Joop Stakenborg wrote:
> > Hi Tom,
> > 
> > 
> > It works okay with 'nano' now, thanks!
> > 
> > The weekend was, fun. Made mores than 800 Q's in the CQWWCW with
> > tlf and winkeydaemon using the nanokeyer.  
> 
> Good to hear everything worked well, Joop.
> 
> 73, Nate
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--



pgpUluh0O7F0b.pgp
Description: Digitale Signatur von OpenPGP

Re: Support for K3NG Arduino keyer

[Thomas Beierlein]

Hi Andy,

there are some UDP clients controlling K1EL like keyers (and also the
K3NG). See the mailing archive from just last week. There was a
discussion about it.

From memory:

- There is Winkeydaemon at Nate's N0NB github account
  https://github.com/N0NB/winkeydaemon and

- a second one is the Winkeyer USB server (see
  https://www.cqrlog.com/node/149)

I have a K3NG like nanoKeyer myself and use it with Winkeydaemon.

73, de Tom DL1JBE

Am Sun, 24 Nov 2019 20:33:13 +0500
schrieb Andy :

> Hi everyone,
> 
> Can I configure TLF to use K3NG Arduino keyer or cwdaemon is only 
> available cw keying device?
> 
> Thanks,
> 
> 73,
> 
> Andy 9a3jh
> 
> On 11/23/19 10:00 PM, tlf-devel-requ...@nongnu.org wrote:
> > Send Tlf-devel mailing list submissions to
> > tlf-devel@nongnu.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://lists.nongnu.org/mailman/listinfo/tlf-devel
> > or, via email, send a message with subject or body 'help' to
> > tlf-devel-requ...@nongnu.org
> >
> > You can reach the person managing the list at
> > tlf-devel-ow...@nongnu.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Tlf-devel digest..."
> >
> >
> > Today's Topics:
> >
> > 1. Re: tlf and the nano editor (Drew Arnett)
> >
> >
> > --
> >
> > Message: 1
> > Date: Sat, 23 Nov 2019 14:32:53 +
> > From: Drew Arnett 
> > To: tlf-devel@nongnu.org
> > Subject: Re: tlf and the nano editor
> > Message-ID:
> > 
> > Content-Type: text/plain; charset="UTF-8"
> >
> > Zoli's idea is the first thing I thought of, too.  But the suggested
> > method of using EDITOR from tlf config as first priority, then
> > falling back on the shell environmental variable as 2nd priority I
> > think would be better.  I could image someone preferring some
> > editor for most of their usual work, but wanting a different one
> > for use from tlf.  For example, I might usually use gvim, but want
> > to use vim from tlf.  So, EDITOR=gvim in the shell, and EDITOR=vim
> > in the tlf config file.
> >
> > Best regards,
> >
> > Drew
> > n7da
> >
> > On Sat, Nov 23, 2019 at 2:30 PM Nate Bargmann 
> > wrote:  
> >> * On 2019 23 Nov 01:18 -0600, Csahok Zoltan wrote:  
> >>> My 2c: try with "export EDITOR=..."  
> >> Hi Zoli,
> >>
> >> This is the setting in log_cfg.dat that I am testing with Tom's new
> >> patch to allow specifying any editor, not a shell variable.
> >>
> >> 73, Nate
> >>
> >> --
> >>
> >> "The optimist proclaims that we live in the best of all
> >> possible worlds.  The pessimist fears this is true."
> >>
> >> Web: https://www.n0nb.us
> >> Projects: https://github.com/N0NB
> >> GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819
> >>  
> >
> >
> > --
> >
> > Subject: Digest Footer
> >
> > ___
> > Tlf-devel mailing list
> > Tlf-devel@nongnu.org
> > https://lists.nongnu.org/mailman/listinfo/tlf-devel
> >
> >
> > --
> >
> > End of Tlf-devel Digest, Vol 188, Issue 25
> > **  



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: tlf and the nano editor

[Thomas Beierlein]

As a final touch TLF now rereads the whole logfile after the editing
command is finished.
That was not implemented correctly before.

For all that who want to experiment with a graphical editor (gedit,
gvim, ...) make sure that the editor stays in foreground and blocks TLF
until editing is done. Otherwise rereading and scoring may be wrong and
need to be corrected by ':rescore' command afterwards.

E.g., for gvim you can use 'EDITOR=gvim -f'.

Be aware that that is normally not the case for the EDITOR variable in
environment.

73, de Tom

Am Sat, 23 Nov 2019 19:33:58 +0100 schrieb Thomas
Beierlein :

> Hi, 
> 
> please see the improved version on the same link as yesterday.
> 
> From the commit message:
> 
> > Improve editor handling
> >
> >- Uses it also for :CFG and :SET commands
> >- Fall back to editor defined in environment if not defined in
> >  logcfg.dat
> >- Show warning if editor program not found  
> 
> @nate: I tested it with gedit and gvim -> works. What is emacs doing?
> 
> 
> 73, de Tom DL1JBE
> 
> 
> Am Fri, 22 Nov 2019 20:19:53 +0100
> schrieb Thomas Beierlein :
> 
> > Hi all,
> > 
> > as the fixed choice of editors is quite a nuisance I prepared a
> > changed version for tests. Please find it at
> > https://github.com/dl1jbe/tlf/tree/new_editor
> > 
> > Download the code and build TLF as told in the INSTALL file. Do not
> > forget the 'autoreconf -i' step.
> > 
> > The new version accepts any string as editor command and will just
> > call that program with the logfile name as parameter.
> > 
> > That means
> > 
> > EDITOR=my-shiny-editor
> > 
> > in logcfg.dat will call
> > 
> > 'my-shiny-editor '
> > 
> > So a simple EDITOR=nano should do afterwards.
> > 
> > Please test and give feedback. 
> > 
> > 73, de Tom DL1JBE
> > 
> > Am Fri, 22 Nov 2019 11:08:52 -0600
> > schrieb jim smith :
> >   
> > > On Fri, 22 Nov 2019 15:06:14 +0100
> > > Joop Stakenborg  wrote:
> > > 
> > > > I have gotten used to the GNU nano editor, but it does not seem
> > > > to work with tlf. When I type :edit in the callsign field, tlf
> > > > exits and returns straight away without opening nano. Both joe
> > > > and vi work okay here. It is hard to debug, have to spent some
> > > > time on it to see what actually happens. Maybe use gdb with a
> > > > break added. I will have a look next week.
> > > > 
> > > > 
> > > > 73 de Joop PG4I
> > > >   
> > > 
> > > 
> > > Hi Joop,
> > > 
> > > I don't know if this helps any, but I don't have any problems
> > > running nano with tlf on ubuntu 18.04. I have *not* updgraded to
> > > tlf 1.4 yet (was going to do that this weekend.
> > 
> > 
> >   
> 
> 
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: tlf and the nano editor

[Thomas Beierlein]

Hi, 

please see the improved version on the same link as yesterday.

From the commit message:

> Improve editor handling
>
>- Uses it also for :CFG and :SET commands
>- Fall back to editor defined in environment if not defined in
>  logcfg.dat
>- Show warning if editor program not found

@nate: I tested it with gedit and gvim -> works. What is emacs doing?


73, de Tom DL1JBE


Am Fri, 22 Nov 2019 20:19:53 +0100
schrieb Thomas Beierlein :

> Hi all,
> 
> as the fixed choice of editors is quite a nuisance I prepared a
> changed version for tests. Please find it at
> https://github.com/dl1jbe/tlf/tree/new_editor
> 
> Download the code and build TLF as told in the INSTALL file. Do not
> forget the 'autoreconf -i' step.
> 
> The new version accepts any string as editor command and will just
> call that program with the logfile name as parameter.
> 
> That means
> 
> EDITOR=my-shiny-editor
> 
> in logcfg.dat will call
> 
> 'my-shiny-editor '
> 
> So a simple EDITOR=nano should do afterwards.
> 
> Please test and give feedback. 
> 
> 73, de Tom DL1JBE
> 
> Am Fri, 22 Nov 2019 11:08:52 -0600
> schrieb jim smith :
> 
> > On Fri, 22 Nov 2019 15:06:14 +0100
> > Joop Stakenborg  wrote:
> >   
> > > I have gotten used to the GNU nano editor, but it does not seem to
> > > work with tlf. When I type :edit in the callsign field, tlf exits
> > > and returns straight away without opening nano. Both joe and vi
> > > work okay here. It is hard to debug, have to spent some time on it
> > > to see what actually happens. Maybe use gdb with a break added. I
> > > will have a look next week.
> > > 
> > > 
> > > 73 de Joop PG4I
> > > 
> > 
> > 
> > Hi Joop,
> > 
> > I don't know if this helps any, but I don't have any problems
> > running nano with tlf on ubuntu 18.04. I have *not* updgraded to
> > tlf 1.4 yet (was going to do that this weekend.  
> 
> 
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: tlf and the nano editor

[Thomas Beierlein]

Hi Joop,

thanks for the test. It was just a quick shot for a test. I will look
into it tomorrow evening. 

In the case that someone forgot to specify the EDITOR= command I will
fall back to the editor specified in the environment.

73, de Tom

Am Fri, 22 Nov 2019 20:57:59 +0100 schrieb Joop Stakenborg
:

> Hi Tom,
> 
> 
> it works okay for the :edit command, but you need to change the code
> for both the :set and :cfg commands (which allows editing of
> logcfg.dat), they both start the joe editor, even though I have
> EDITOR=nano in logcfg.dat.
> 
> The code is in changepars.c
> 
> Thanks,
> 
> Joop
> 
> Op 22-11-19 om 20:19 schreef Thomas Beierlein:
> > Hi all,
> >
> > as the fixed choice of editors is quite a nuisance I prepared a
> > changed version for tests. Please find it at
> > https://github.com/dl1jbe/tlf/tree/new_editor
> >
> > Download the code and build TLF as told in the INSTALL file. Do not
> > forget the 'autoreconf -i' step.
> >
> > The new version accepts any string as editor command and will just
> > call that program with the logfile name as parameter.
> >
> > That means
> >
> > EDITOR=my-shiny-editor
> >
> > in logcfg.dat will call
> >
> > 'my-shiny-editor '
> >
> > So a simple EDITOR=nano should do afterwards.
> >
> > Please test and give feedback.
> >
> > 73, de Tom DL1JBE
> >
> > Am Fri, 22 Nov 2019 11:08:52 -0600
> > schrieb jim smith :
> >  
> >> On Fri, 22 Nov 2019 15:06:14 +0100
> >> Joop Stakenborg  wrote:
> >>  
> >>> I have gotten used to the GNU nano editor, but it does not seem to
> >>> work with tlf. When I type :edit in the callsign field, tlf exits
> >>> and returns straight away without opening nano. Both joe and vi
> >>> work okay here. It is hard to debug, have to spent some time on it
> >>> to see what actually happens. Maybe use gdb with a break added. I
> >>> will have a look next week.
> >>>
> >>>
> >>> 73 de Joop PG4I
> >>>  
> >>
> >> Hi Joop,
> >>
> >> I don't know if this helps any, but I don't have any problems
> >> running nano with tlf on ubuntu 18.04. I have *not* updgraded to
> >> tlf 1.4 yet (was going to do that this weekend.  
> >
> >  



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: tlf and the nano editor

[Thomas Beierlein]

Hi all,

as the fixed choice of editors is quite a nuisance I prepared a
changed version for tests. Please find it at
https://github.com/dl1jbe/tlf/tree/new_editor

Download the code and build TLF as told in the INSTALL file. Do not
forget the 'autoreconf -i' step.

The new version accepts any string as editor command and will just call
that program with the logfile name as parameter.

That means

EDITOR=my-shiny-editor

in logcfg.dat will call

'my-shiny-editor '

So a simple EDITOR=nano should do afterwards.

Please test and give feedback. 

73, de Tom DL1JBE

Am Fri, 22 Nov 2019 11:08:52 -0600
schrieb jim smith :

> On Fri, 22 Nov 2019 15:06:14 +0100
> Joop Stakenborg  wrote:
> 
> > I have gotten used to the GNU nano editor, but it does not seem to
> > work with tlf. When I type :edit in the callsign field, tlf exits
> > and returns straight away without opening nano. Both joe and vi
> > work okay here. It is hard to debug, have to spent some time on it
> > to see what actually happens. Maybe use gdb with a break added. I
> > will have a look next week.
> > 
> > 
> > 73 de Joop PG4I
> >   
> 
> 
> Hi Joop,
> 
> I don't know if this helps any, but I don't have any problems running
> nano with tlf on ubuntu 18.04. I have *not* updgraded to tlf 1.4 yet
> (was going to do that this weekend.



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Don't forget Winkeydaemon!

[Thomas Beierlein]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am Thu, 21 Nov 2019 19:31:11 -0600
schrieb Nate Bargmann :

> Many years ago (late 2007) Rein, PA0R, wrote up a Perl script to work
> with the K1EL series of Winkeyers.  I found that it worked with my
> HamGadgets MK-1 which has a K1EL compatible interface.
> 
...
> 
> The winkeydaemon is a drop-in replacement for cwdaemon for the K1EL
> Winkeyer series and any compatibles, like mine.  I have used it
> throughout a weekend with Tlf with no issues.
> 
Same here. I have the K3NG arduino based nanoKeyer. It works without
hassle.

73, de Tom DL1JBE
> 
> All that said, if anyone has one of the Winkeyer USB models, I'd
> appreciate some testing.  A friend has been having trouble getting his
> to work with winkeydaemon and we've not gotten together to try
> troubleshooting it.
> 
> 73, Nate
> 



- -- 
"Do what is needful!"
Ursula LeGuin: Earthsea
- --

-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQTY6BXzAKH/Wa02IMhB7i6pdiBT1QUCXdeE8QAKCRBB7i6pdiBT
1f+XAJ9pT1OyI3uwE5Z07qID5KCmuz3/fgCfbkQSp4FKUECXxQDXZa1CtDqypgk=
=Jo8e
-END PGP SIGNATURE-

Re: TLF-1.4.0 release

[Thomas Beierlein]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Nate,

Am Thu, 21 Nov 2019 20:17:41 -0600
schrieb Nate Bargmann :

> Some items to add to your list, Tom.
> 
snip .


I will add the points to the list. Thanks.

I am sure there will be some discussion about the menus. Let us see.

One last point:

>  - WISHLIST: Rework the curses UI to avoid the 80x25 hard coded screen
>size.  I've looked into this a time or two and doing this won't be
>easy but is probably required for enough screen estate if menus are
>to be implemented.  At the least, more vertical screen space could
>show more log lines or DX spots, for example.  
>
Vertical resize is already done in TLF-1.4.0. Just try it.
It could use a more flexible screen layout during resize, but in the
moment you get a lot of vertical space for the bandmap display.

Horizontal resize has still to be done.

73, de Tom DL1JBE


- -- 
"Do what is needful!"
Ursula LeGuin: Earthsea
- --

-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQTY6BXzAKH/Wa02IMhB7i6pdiBT1QUCXdeENAAKCRBB7i6pdiBT
1ZysAJ4zxyQ1yZ5rmaJhO+lpuFudQYpj1gCfU5TWBhM/bHO7dUbwxjDA8Dt6UCA=
=Nczr
-END PGP SIGNATURE-

Re: GLib version?

[Thomas Beierlein]

Hi Zoli,

Am Wed, 20 Nov 2019 19:48:12 +0100
schrieb Csahok Zoltan :

> I would like to use GLib version >=2.40 for set-related hash table
> functions (g_hash_table_add).

I tried the same back in 2015 while coding the focm.c contest module.

At that time 2.40 was just out for some months but not widely in use.
So I had to fall back to g_hash_table_replace with key and value the
same (see there). 

In meantime nearly all distributions should provide an more actual
version of GLib.

> 
> A quick check of Debian buster shows that it contains GLib 2.58.
> On the other hand, tlf in that release (1.3.2) requires only GLib
> 2.35.9. Similar (or even worse) for sid: tlf 1.4.0 requires 2.30.0
> for non-alpha/powerpc, whereas GLib 2.62 is deployed.
> 
> configure.ac doesn't explicitly mention the required version, so this
> must come from somewhere else. Could this and the Debian (and other
> distro) packages be fixed so that at least 2.40 is required?

If we need 2.40 we should state so in the configure.ac. 

73, de Tom


-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: feature request: cabrillo template

[Thomas Beierlein]

Hi Ervin,

sounds good so far. If there are no other suggestions from Joop or
others just go ahead.

73, de Tom DL1JBE 

 Am Sun, 17 Nov 2019 18:17:13 +0100
schrieb Ervin Hegedüs :

> Hi all,
> 
> On Sun, Nov 17, 2019 at 06:00:41PM +0100, Thomas Beierlein wrote:
> > Hi Joop,
> > 
> > I assume you are talking about the contest and operator related
> > informations gathered when you want to write a new cabrillo file.
> > 
> > Can you please elaborate some more about what you have in mind here.
> > The head part of the cabrillo file is not independent of the
> > contest. So one template for all seems not to fit. But I see that
> > at least the operator related part could be common between contests.
> > 
> > Any comments or suggestions?  
> 
> I don't want to answer for Joop, but I thought about this feature
> earlier.
> 
> I imagined like this:
> 
> logcfg.dat:
> 
> CABRILLO_DATA=/home/airween/.tlf/HA2OS_general.cab
> CABRILLO_CONTEST=CQ-WW-CW
> ...
> 
> /home/airween/.tlf/HA2OS_general.cab
> CABROLLO_CALLSIGN: HA2OS
> CABRILLO_LOCATION: DX
> CABRILLO_CATEGORY-OPERATOR: SINGLE-OP
> CABRILLO_CATEGORY-ASSISTED: NON-ASSISTED
> CABRILLO_CATEGORY-BAND: ALL
> CABRILLO_CATEGORY-POWER: LOW
> CABRILLO_CATEGORY-MODE: CW
> CABRILLO_CATEGORY-TRANSMITTER: ONE
> CABRILLO_CATEGORY-OVERLAY: 
> CABRILLO_CONTEST=
> 
> I wrote deribelately the CABRILLO_CONTEST field at two places
> (logcfg.dat and general data file): the second occurrance of
> field overwrites the first, so therefore we can replace the
> values at every contest, but can use a basic data.
> 
> When user types a ":w" in callsign field (start to export the log
> to CABRILLO), then the fields which has values (by set them the
> fields above) will filled in dialogues.
> 
> If you like this way, I can start to implement it soon.
> 
> 
> 73, Ervin
> HA2OS
> 
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: TLF-1.4.0 release

[Thomas Beierlein]

Hi Nate,

Am Sun, 17 Nov 2019 04:50:16 -0600
schrieb Nate Bargmann :

> Congratulations to Tom and everyone that has worked on this release.
> 
Thanks.

> I've been quiet for the past year or so as I chose a different
> challenge about a year ago due, in part, to the lament of some
> friends.  For the handful of events I operate these days I've chosen
> to use N1MM+ under Wine.  It does work though it is a bit (quite a
> bit) quirky.  

> One feature I really like is to be able to switch from
> ESM to a CT like mode on the fly.  When I do S&P I much prefer the CT
> mode and for running ESM works best for me.  

As far as I see now that could be done in TLF easily. If we switch the
mode after finishing a QSO and before starting a new one, that should
work flawlessly. All that is needed is a way to switch 'ctcompatible'
on and off by key or command. 

Feel free to experiment on it and prepare a pull request if you like.

> Another reason to work
> with it was for our club Field Day operation where other ops seem
> more comfortable with menus and such.

Yes, there seems to be different 'operating modes' in our heads also -
some prefer keyboards and other prefer mouse and menus. I fear that
one can not be changed - every one has to choose the programs which
fits their 'internal working' best :-). 

73, de Tom DL1JBE


-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--



pgp9x5d_A5BO1.pgp
Description: Digitale Signatur von OpenPGP

Re: TLF-1.4.0 release

[Thomas Beierlein]

Hi all,

Am Thu, 14 Nov 2019 20:22:24 +0100
schrieb Csahok Zoltan :

> Thanks, Tom!
> 
> Now it's time for feature requests and bug reports. :-)


As the first feature request came in today by Joop let me start a
little list with things to do. Please feel free to add your ideas to
the list. We then sort out in which order and timeframe we can work on
it:

- Have a template for cabrillo file header  (Joop PG4I)

- Add a keyword to startup TLF in S&P mode (should be an easy one)

- switch between ESM and CT mode during contest (Nate N0NB)

- change internal QSO representation to structs (makes coding much
  simpler and will enable migration of log file to a different format
  later)

- Switch the logfile to a database. The actual TR-Log format has some
  limitations. Log as a database will enable easy statistics, make
  removal of QSOs easier and allows us to store more information about
  the contest. (Long term goal)

- Do a major rework of scoring of multis and points (That is already 
  overdue for some time now). As contests developed in last years there
  are more and more complex scoring schemes. To code a special contest
  module for each contest will not be possible with our limited man
  power. So we need a flexible and programmable scoring which will
  allow us to handle most of the contests by a rule file.
  I fear it will break compatibility with existing TLF rules completely
  and would sure be a major version bump to TLF-2.0 or similar.

Thats for a start. Any additions?

73, de Tom DL1JBE
> 
> 73,
> Zoli
> 
> On Wed, Nov 13, 2019 at 03:06:33PM +0100, Thomas Beierlein wrote:
> > 
> > After a lot of work by all people contributing to TLF I would like
> > to announce the release of the new TLF-1.4.0 version.
> > 
> > You can find it at 
> > 
> > http://download.savannah.gnu.org/releases/tlf/tlf-1.4.0.tar.gz or 
> > https://github.com/Tlf/tlf/releases/download/tlf-1.4.0/tlf-1.4.0.tar.gz
> > 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: TLF-1.4.0 release

[Thomas Beierlein]

Hi Pontus,

in the name of all who spent their time working on TLF let me thank for
your kind words.
We are glad that our work make contesting fun for all of you.

73, de Tom DL1JBE

Am Fri, 15 Nov 2019 08:39:38 +0100
schrieb Pontus Falk :

> Hi,
> 
> Den 2019-11-13 kl. 15:06, skrev Thomas Beierlein:
> 
> > After a lot of work by all people contributing to TLF I would like
> > to announce the release of the new TLF-1.4.0 version.
> > 
> > You can find it at 
> > 
> > http://download.savannah.gnu.org/releases/tlf/tlf-1.4.0.tar.gz or 
> > https://github.com/Tlf/tlf/releases/download/tlf-1.4.0/tlf-1.4.0.tar.gz  
> Thanks a zillion to all of you involved in the development.
> 
> I've been using tlf for a couple of years, most recently in CQ WW SSB
> 2019 and I'm so happy with 1.3.0 - and I see a lot of improvements
> already by just starting 1.4.0.
> 
> Thanks again!
> 
> 73's de SM0RUX Pontus (SM0R in contests)
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: trouble scoring the LZ-DX contest

[Thomas Beierlein]

Hi Joop,


Am Sun, 17 Nov 2019 10:30:22 +0100
schrieb Joop Stakenborg :

> First of all, thanks for the new release! I have started using tlf a
> few weeks ago, very happy!
> 
Nice to hear.
> 
> I am having trouble scoring the lz-dx contest. Points are okay, but 
> multipliers not. The multiplier is either the ITU zone or the LZ 
> district. So I would like to have something like ITU_&_SECTIONS,
> which would work the same as DX_&_SECTIONS.
> 
Sigh, it is a trouble with those 'creative' contest designers (Rant
off).

You are right, at the moment there is no solution for your problem.
Scoring your contest results will be correct, as it is done by the
contest organizer. But we would want at least a good guess how we are
doing.

The keyword suggested by you (ITU_&_SECTIONS, or better
ZONE_&_SECTIONS) would work (and could be added in the next version of
TLF). 

But I fear there will be another combination of multipliers
poping up soon which we do not have in our repertoire.
So a better solution is needed - same goes for point scoring.

I did some investigation how other contest programs solve these problem.
One of the ideas there are to classify multipliers into some main
categories:

- Country/DXCC
- Zone CQ or ITU
- Prefix 
- section or similar

With that we could allow more to count more than one category as multi
and would need additional rules how to combine the values (add if more
than one or score only one) and how to count on different
bands (BY-BAND or ONCE). Than your ITU_&_SECTION could be something
like:

COUNTRY_MULT = DXCC,BY_BAND
ZONE_MULT = ITU,BY_BAND ADD

I am not sure if that would catch all or at least most of the multi
scoring problems for existing contests. 

Feedback on that is very much welcome.

73, de Tom DL1JBE

> 
> Here is part of my rules file, which does not work properly
> (lz_dx_mults attached):
> 
> 
> #
> #  CONTEST PARAMETERS
> #
> #
> MULT_LIST=lz_dx_mults
> COUNTRYLIST=LZ
> SECTION_MULT
> ITUMULT
> #
> #
> #  POINTS LIST
> #
> #
> COUNTRY_LIST_POINTS=10
> MY_CONTINENT_POINTS=1
> DX_POINTS=3
> 
> 
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--