KS QP Saturday--The Good, The Bad, and The Ugly

[Nate Bargmann]

Apologies to Sergio Leone for hijacking his movie title.  ;-)

This weekend is the annual Kansas QSO Party and I've been putting TLF
through the paces again.  I am using Git master at commit 67e2322.

The Good:

Escape is working well to stop a voice transmission that is in progress.

The sound log files are now in a subdirectory of the working directory.

The Bad:

I had the first lock-up of TLF in recent memory, if ever, earlier today.
I am not sure if I struck Ctrl-S (now that I think about it) but TLF in
the XTerm I am using would not respond.  I used 'pkill -f tlf' to dump
it and restart it.  I know I had intended to Alt-Tab back to the XTerm
from Firefox to enter a call and that is when it happened.  Operator or
TLF error, I'm not sure.

Related, at one point TLF was getting sluggish while the TU CW message
was being sent with the callsign text not being cleared and the worked
before window remaining visible until after the TU message was sent.  At
one point this remained for several seconds and a station was answering
and I could not type and then it returned to normal.  Oddly, I didn't
see that again.  There were only about 230 Qs in the log file at the
time.

The Ugly:

Escape is wiping out the entered data when first pressed while a CW
message is in process (I don't recall if it did the same thing on SSB).
This requires a repeat request or a good short term memory (I had to ask
for repeats when this happened).  If there are users that want to
maintain the current behavior then it should be configurable.  If it
already is and I missed it, that's on me.

TLF seems to be inventing multipliers in the scoring window.  The actual
ones appearing in the log file are correct but the Mul: value seemed to
increment almost without a pattern.  Consequently the displayed score is
nonsensical.

I noticed when I restarted TLF after the pkill command that it prompted
me whether to rescore the log.  I answered Y and when the logging screen
came up all of the CW QSOs were set to 2 points instead of 3 (in the
KSQP CW score 3 points and SSB score 2 points each).  For whatever
reason I had SSBMODE set in log_cfg.dat.  Just now I commented it out
and started TLF again and did not get the rescoring prompt and my last
CW contacts are still at 3 points.

Thankfully, the log file was backed up each time.

I suppose this brings up another question, what value is there in
storing a point value in the log file?  It seems to me that if points
are calculated by mode that the mode column should be the determining
factor.  Also, mults will need to be read and calculated from each line
so doing so for the mode would seem consistent.

I also think it is an error in judgment to be rewriting the log file in
the first place.  Thankfully this bug didn't destroy my event as
Cabrillo generation was not affected.  I think that TLF should only
append to the log file and the only time it is written is when the
operator performs an editing action either in TLF or an external editor.
As I see it, the log data is the most precious part of the event and I
know that most of us don't back up the log file with every disk write,
but perhaps we should!

Anyway, these are the issues I found today.  What will tomorrow bring?

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

signature.asc
Description: PGP signature