Re: Last minute: rules/scoring for the King of Spain CW contest

[Csahok Zoltan]

Thanks for the rules! They worked fine. I added these extra lines to define
the neccessary Cabrillo fields:

CABRILLO-CONTEST = EA-MAJESTAD-CW
CABRILLO-CATEGORY-MODE = CW
#CABRILLO-CONTEST = EA-MAJESTAD-SSB
#CABRILLO-CATEGORY-MODE = SSB
CABRILLO-CATEGORY-BAND = (ALL, 160M, 80M, 40M, 15M, 10M)
CABRILLO-CATEGORY-POWER = (HIGH, LOW, QRP)

I assume the same rules apply to the SSB contest too.

Could you create a pull request for this?

Multiplier counting is a bit different in EA and HADX/UKEI contests.
HADX/UKEI do *not* count "own" country as DXCC multiplier -
HADX: worked DXCC + WAE list countries (exception HA) and Hungarian counties...
UKEI: DXCC countries worked on each band, (excluding the UK/EI DXCC countries...
Whereas EA *does* count them -
... EADX-100 entities + The Spanish provinces + SMR ...

So these 2 QSOs
EA3XXX  599 B
EA5YYY  599 A
result is 3 multipliers: EA, EA/B, EA/A.

Having 2 multipliers is currently not yet supported, but we are working on it.

73,
Zoli

On Fri, May 17, 2024 at 11:20:57PM +0200, Koos van den Hout PE4KH wrote:
>
> Finally time for an attempt to get the scoring/multipliers right for the
> King of Spain CW contest. The evening before the contest.
>
> I have the rules from
> https://concursos.ure.es/en/s-m-el-rey-de-espana-cw/bases/
>
> I started thinking there is one set of multipliers for all the URE contests
> but there are subtle differences!
>
> I used the plugin method and I based it on the ukeidx.py and hadx.py
> plugins. Python is not my primary programming language!
>
> Attached:
>
> rules/eakingofspain
> rules/eakingofspain.py
>
> I will go into the contest with these. As the URE concursos organizers are
> usually quite fast with the scoring I can validate my scoring when they get
> back to me and I will update accordingly.
>
> Please test and good luck in the contest!
>
> Koos van den Hout PE4KH
>
> --
> PE4KH amateur radio station
> https://pe4kh.idefix.net/

Re: EU DX Contest

[Csahok Zoltan]

Yes, indeed, the EU-DX rules really mix DXCCs and legal countries.
I have updated my branch to reflect this, as far as I could interpret the rules.
Now scoring is also done in the plugin.
One has to specify their (legal) country code (like IT for Italy)
or DX for non-EU stations.
The available methods/values are documented in the man page.

73,
Zoli

On Mon, Feb 05, 2024 at 01:15:33AM +0200, Matei Conovici wrote:
> Some notes about scoring: I noticed during the contest that IT9 was only
> awarded 3 points instead of 10 so I said to myself "I'll just add it
> to the country
> list later". It's a bit more complicated.

Re: EU DX Contest

[Csahok Zoltan]

QSO with the same station in CW and SSB can be considered using MIXED.
Updated my branch to reflect this.

73,
Zoli

On Thu, Feb 01, 2024 at 07:19:20AM +0200, Matei Conovici wrote:
> > Check the branch https://github.com/zcsahok/tlf/tree/poc_xmult,
> > the rules are currently in test/rules/eudx.
>
> Thank you very much! It works perfectly for my purposes as I will be
> CW-only. However,
> for mixed entries, a second contact with the same station on the same
> band (one CW, one SSB) does not
> give you qso points for the second one and it should, if i'm reading
> sections 8 & 9 of the rules correctly.
> Multipliers only count once, and this is ok.
>
> I think I'm all set, thank you again.
>
> 73 de YO3GEK,
> Matei

Re: EU DX Contest

[Csahok Zoltan]

Hi Matei,

The TLF core is somwhat limited when it comes to multiplier handling.
To overcome this one can write contest specific plugins.
The choice of multipliers for EU-DX (country+EU region) can be implemented
using the "several multipliers per QSO" approach. 
(https://github.com/Tlf/tlf/issues/411)
For the moment this a proof-of-concept, but I plan to make a PR if it works OK.

Check the branch https://github.com/zcsahok/tlf/tree/poc_xmult,
the rules are currently in test/rules/eudx.
After compiling TLF can be started from this dir using
../../../src/tlf -nrv

Attached is a screenshot with the test log showing 3 OE's worked from 2 regions
and 2 LZ's from the same region but worked once on 40 then on 20.
There are 7 multipliers in total.

73,
Zoli

On Wed, Jan 31, 2024 at 03:03:09PM +0200, Matei Conovici wrote:
> Good afternoon,
>
> I'm trying to cook a rules file for EU-DX Contest this weekend. The
> point scoring part seems to work, but I'm struggling with the
> multipliers.
>

Re: enable python Plugin

[Csahok Zoltan]

Hello Herve,

python-config in Debian/Ubuntu is part of python3-dev package. Not sure about
the OS you are using.
For a reference you can check the step "Install dependencies" in
https://github.com/Tlf/tlf/blob/master/.github/workflows/ci-build.yml

Hope this helps.

73,
Zoli


On Wed, Jan 24, 2024 at 11:02:43PM +0100, f8...@free.fr wrote:
>Hello,
>
>I am trying to enable python plugin in order to add some new contest
>rules.
>
>I clone from github the latest repository.
>
>When I launch  ./configure --enable-plugin I get this error :
>
>configure: error: cannot find python-config for /usr/local/bin/python3.
>
>I have python3.12 version installed on my linux (launch by python3
>command)
>
>.configure see python3 version = 3.1
>
> checking for python3 version... 3.1
>
>checking for /usr/local/bin/python3 version... (cached) 3.1
>
>Thanks for your help,
>
>Best 73's
>
>Herve

Re: How to set up the Marconi Club A.R.I.Loano QSO PARTY DAY

[Csahok Zoltan]

Hi Martin,

The rules are in PR https://github.com/Tlf/tlf/pull/420
(or in my fork: https://github.com/zcsahok/tlf/tree/marconi_day_rules)
You need a TLF built from github master with python plugin support.
Then copy the 3 files from rules/mcd into your rules/ dir and set
RULES=mcd

73 and hny,
Zoli


On Thu, Jan 04, 2024 at 02:05:57AM +0100, Martin Kratoska wrote:
> Hi all,
>
> First my best wishes for the New Year 2024.
>
> I'm trying to set up the  Marconi Club A.R.I.Loano QSO PARTY DAY which runs
> on Jan. 6, 2024 07-21 UTC. I would like to have online scoring, theree is a
> problem with QSO with Members (I am also a Member #223) which are the
> multipliers and 5 points worth.
>
> Can anybody help?
>
> 73,
> Martin, OK1RR
> MARCONISTA #223

Re: TLF and the Stew Perry

[Csahok Zoltan]

Cabrillo format doesn't support literals, only predefined symbolic tags.
The offending entry is "EN62,4".

For a solution check for example rules/cqww160/cqww160
The main configs in your case would be

CABRILLO=UNIVERSAL
CABRILLO-EXCHANGE=EN62

but other CABRILLO-* fields can be also set as required
in order to avoid TLF asking for them.

73,
Zoli
ha5cqz

On Mon, Jan 01, 2024 at 11:16:48PM -0600, Bill Lederer wrote:
>Thanks.
>My next question is producing the cabrillo file for this contest.  In my
>logcfg.dat, I have specified
>CABRILLO-TEMPLATE=stewperry.fmt
>Which contains
>QSO_FMT=FREQ,5;MODE,2;DATE,10;TIME,4;MYCALL,13;EN62,4;HISCALL,13;EXCH
>This yields an error at startup of
>Wrong Parameter for keyword  'CABRILLO-TEMPLATE': unknown tag
>'QSO_FMT=FREQ,5;MODE,2;DATE,10;TIME,4;MYCALL,13;EN62,4;HISCALL,13;EXCH'
>I get the same result if the first field is QSO instead of QSO_FMT.
>Thanks,
>    w8lvn
>On Sun, Dec 31, 2023 at 1:32 PM Csahok Zoltan <[1]ha5...@gmx.com> wrote:
>
>  Check that you have set your locator right in logcfg.dat:
>
>  MYQRA=AB12CD
>
>  73,
>  Zoli
>
>  On Sun, Dec 31, 2023 at 11:08:21AM -0600, Bill Lederer wrote:
>  >    I ran the december stew perry contest. TLF is working for me well,
>  but I
>  >    haven't worked out how the scoring is done.
>  >    I'm using the provided stewperry rules file with my call and
>  exchange set
>  >    up the way I like.
>  >    However, the scoring seems not quite right, with scores of 20 for a
>  qso
>  >    with a station near me, as opposed to 2 or three points.
>  >    Is there a setup step that I am missing?
>  >    --
>  >    --w8lvn--
>
>--
>--w8lvn--
>
> References
>
>Visible links
>1. mailto:ha5...@gmx.com

Re: TLF and the Stew Perry

[Csahok Zoltan]

Check that you have set your locator right in logcfg.dat:

MYQRA=AB12CD


73,
Zoli

On Sun, Dec 31, 2023 at 11:08:21AM -0600, Bill Lederer wrote:
>I ran the december stew perry contest. TLF is working for me well, but I
>haven't worked out how the scoring is done.
>I'm using the provided stewperry rules file with my call and exchange set
>up the way I like.
>However, the scoring seems not quite right, with scores of 20 for a qso
>with a station near me, as opposed to 2 or three points.
>Is there a setup step that I am missing?
>--
>--w8lvn--

Re: ToDo item: switch logfile to database

[Csahok Zoltan]

Hi,

I see currently no issue that introducing a DB backend would solve.
Technically for 1k records and holding it in memory no DB is required.

One thing, on the other hand, that is now seriously broken is the networking
support. I requires a careful rework, including probably a redesign
as it apparently was created only with "simple" contests like CQWW in mind.
A shared DB could be an option here, but other loggers also typically use
distributed logkeeping for a reason.

73,
Zoli


On Thu, Dec 28, 2023 at 06:18:13AM +, Marcin SP6MI wrote:
>
> Hi,
> Thank you Ervin, if it's not a problem I would like to show your code.
>
> Br
> Marcin SP6MI
>

Re: Remove CTCOMPATIBLE mode (RFC #2)

[Csahok Zoltan]

Wouldn't SPRINTMODE do this for you? (or is it broken? haven't tried it yet)

   SPRINTMODE
  If  set,  Tlf will automatically switch its mode between LOG and
  S after every QSO.


73,
Zoli

On Sun, Aug 27, 2023 at 09:09:44PM +0200, Fred Siegmund wrote:
> Basically you would need to switch RUN and S mode all the time. But I
> don't want to block development, I can use old versions.
>
> 73 Fred
>
> Am 27.08.23 um 18:16 schrieb Csahok Zoltan:
> > Fred, what is exactly the problem with the normal (ESM) mode in the sprint?
> > And how does the behavior differ from CTCOMPATIBLE mode?
> >
> > I'd also suggest to drop CTCOMPATIBLE and if this the case then improve ESM.
> >
> > 73,
> > Zoli
> >
> > On Sun, Aug 27, 2023 at 01:16:20PM +0200, Fred Siegmund wrote:
> > > I still see no useful possibility to log Sprint contests with QSY rule in
> > > ESM.
> > >
> > > 73 Fred
> > >

Re: Remove CTCOMPATIBLE mode (RFC #2)

[Csahok Zoltan]

Fred, what is exactly the problem with the normal (ESM) mode in the sprint?
And how does the behavior differ from CTCOMPATIBLE mode?

I'd also suggest to drop CTCOMPATIBLE and if this the case then improve ESM.

73,
Zoli

On Sun, Aug 27, 2023 at 01:16:20PM +0200, Fred Siegmund wrote:
> I still see no useful possibility to log Sprint contests with QSY rule in
> ESM.
>
> 73 Fred
>

Re: Few questions about tlf code

[Csahok Zoltan]

Hi Marcin,

The ToDo list is somewhat outdated, qso data has been already collected
into qso_t structure. Other items could be also done in the meantime.

Regarding code formatting we use astyle with the 'astylerc' file that
is provided in the tools directory. Ideally after all changes code should
be reformatted. Not sure what code blocks have no indentation, I had no
similar issue. (ok, I'm using vi...)

73,
Zoli

Re: Solved issues

[Csahok Zoltan]

Hi Marcin,

I'm not quite sure which list of issues do you mean? (Or is it the ToDo file?)
The issues on github (https://github.com/Tlf/tlf/issues) are closed
as soon as there is a working fix for them.

Yes, please create a usual pull request for the ToDo list.
All contributions are welcome!

73,
Zoli

On Tue, Jun 27, 2023 at 09:16:17AM +, Marcin SP6MI wrote:
>Hi,
>I've checked recently list of issues reported and opened for tlf, and
>looks like some of them are already solved and changes are merged to
>master. Can someone verify that list and close them?
>Additionally one question, I want to start contributing to project, and
>I've prepared small change related to one of "ToDo" list. Does sending
>pull request procedure is same as for issue fixes?
>Br
>Marcin SP6MI
>Wysłano z bezpiecznej poczty e-mail [1]Proton Mail.
>
> References
>
>Visible links
>1. https://proton.me/

Re: failed tlf check

[Csahok Zoltan]

Hi John,

The failed test (rules) requires a supported terminal setting.
For me this line does the trick

TERM=xterm make check


73,
Zoli

On Tue, Jun 27, 2023 at 01:12:12AM +, john kuras wrote:
>I built tlf from the latest github source with no errors. I then did a
>make check and all tests passed except for one. I am forwarding a copy of
>the test-suit.log output file from the failed test per the request printed
>by make check:
>-john,
>w7og

> ==
>Tlf 1.5~git: test/test-suite.log
> ==
>
> # TOTAL: 28
> # PASS:  27
> # SKIP:  0
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
>
> .. contents:: :depth: 2
>
> FAIL: run_rules
> ===
>
> [==] Running 1 test(s).
> [ RUN  ] test_rules
> [  ERROR   ] --- "neqp(TIMEOUT), focmarathon(TIMEOUT), cqww(TIMEOUT), 
> mst(TIMEOUT)" != ""
> [   LINE   ] --- test_rules.c:61: error: Failure!
> ++ neqp
> ++ mwc
> ++ focmarathon
> ++ ukeidx
> ++ cqww
> ++ naqp
> ++ ksqp
> ++ mst
> ++ cqww160
> [  FAILED  ] test_rules
> [==] 1 test(s) run.
> [  PASSED  ] 0 test(s).
> [  FAILED  ] 1 test(s), listed below:
> [  FAILED  ] test_rules
>
>  1 FAILED TEST(S)
> FAIL run_rules (exit status: 1)
>

Re: Testing out TLF-1.5 for NAQP

[Csahok Zoltan]

The rules are meant to be more like templates as they typically require some 
customizing for the particular user (setting county code, etc).

So the process of using them is
1) build a current verison of TLF (on a recent Linux, e.g. Ubuntu 22 or Debian 
11)
autoreconf -i \
&& ./configure --prefix=/usr \
--enable-fldigi-xmlrpc --enable-python-plugin \
&& TERM=xterm make all check
2) copy the files (in this case naqp and naqp.py) into the local rules/ 
directory
3) check+tweak the files if needed
4) reference naqp in local logcfg.dat
5*) if there is a stock (=old) TLF installed then copy cabrillo.fmt from the 
repo into the local directory (the dir where you start TLF from)
6) run the locally built TLF

*Step 5 is normally a one-time action.

73,
Zoli


On Sun, May 21, 2023 at 08:49:51PM -0500, Bill Lederer wrote:
>I am trying to test TLF for NAQP. The rules file for this is actually a
>directory, which contains two files. One is the naqp contest definition
>file, plus naqp.py.
>It doesn't seem to pick up all the info from the file 'naqp'.
>In looking at the code in utils.c, the function find_available does not
>seem to check for the possibility of a directory.
>Or am I looking in the wrong place?
>--
>--w8lvn--

Re: Fwd: UK/EI DX CW Contest – 29th/30th April 2023

[Csahok Zoltan]

See https://github.com/Tlf/tlf/pull/391

73,
Zoli

On Thu, Apr 27, 2023 at 06:21:09PM +0200, Martin Kratoska wrote:
> Just trying to prepare files for the UKEICC Contest. Rather weird, rather
> complex. Any help/ideas?
> 
> Has anybody ready to use, tested files?
> 
> Would be nice to see in the future tlf on the list of programs supporting
> this nice contest.
> 
> 73,
> Martin, OK1RR

Re: Mult List, Aliases, and Truncated Exchange Field

[Csahok Zoltan]

Yes, please add the rules to rules/neqp. I'd be nice to have also a test
for it, check the recently merged PR #388 for an example.

73,
Zoli

On Thu, Apr 13, 2023 at 12:01:16PM -0400, Alan Dove wrote:
> Zoli:
> 
> Okay, I created the "neqp" branch, changed that line to 
> 
> #define MAX_SECTION_LENGTH 5
> 
> then recompiled and tested it. It now logs the full 5-character
> exchange, and with my mult list it seems to be scoring correctly. I
> sent a pull request for that. Should I also add my rules and neqp_mults
> files to /rules and push them to the branch?
> 
> -- 
>  --Alan (AB1XW)

Re: Mult List, Aliases, and Truncated Exchange Field

[Csahok Zoltan]

Hi Alan,

As a quick fix increase the max section length defined in tlf.h

#define MAX_SECTION_LENGTH 4

We'll have to check if this causes any issues before making it official.


73,
Zoli

Re: Color changes

[Csahok Zoltan]

Hi Martin,

Here is a screenshot from today's mix of Oster Contest and MWC.
I'm using xfce4-terminal, it has no issues with readibility.
These are the default colors of the terminal but they can also be easily 
customized.

73,
Zoli


On Fri, Mar 31, 2023 at 11:06:58PM +0200, Martin Kratoska wrote:
> The color scheme used in tlf is excellent except the cyan color which is
> badly visioble on the used background (see attached screenshot, that's what
> I see on my monitor).
> 
> I suggest to replace this color with red color (ff) which excellent
> visibility, see my notes in the pic.
> 
> Is there a common place where the color can be changed?
> 
> 73,
> Martin, OK1RR

Re: Cabrillo format

[Csahok Zoltan]

Hi Marcin,

How did you export the log to Cabrillo?
Normally it is done by entering
:WRI
in the call input field.

The file you got is just TLF's internal log file. So either the export was done
differently or you are looking at the wrong file.
The exported Cabrillo file is called .cbr.


73,
Zoli

On Mon, Jan 30, 2023 at 06:37:24AM +, Marcin SP6MI wrote:
>Hi,
>Yesterday I've exported log from small general contest to carbillo format,
>and looks like it's not valid with standard. Order of fields is different,
>date has wrong format. Where I can define format of cabrillo file (if it's
>possible). 
>I got:
>80SSB 29-Jan-23 18:00 001 3Z3AHK 59 59 2 3727.0
>And according to standard should be
>QSO:  3727 PH 2023-01-29 1800 SN10PWS 59 001 3Z3AHK 59 002 0
>Thanks
>Br
>Marcin SP6MI
>Wysłano z bezpiecznej poczty e-mail [1]Proton Mail.
> 
> References
> 
>Visible links
>1. https://proton.me/

Re: tlf wrong keying

[Csahok Zoltan]

Hi Alexej,

You probably missed the customizing step. TLF uses by default
the delivered generic configuration files from /usr/share/tlf.
Generally they have to be tailored for the actual user and contest.

This is also the case for CQWW. The default rule file
(/usr/share/tlf/rules/cqww) contains 14 as sent exchange
F3=@ ++5NN--14
This has to be adapted to your zone.

Here are the steps to set things up from scratch:

1) create a new folder (as you did already, cqww-test) and change to it
2) copy the default logcfg.dat
cp /usr/share/tlf/logcfg.dat .
3) edit local logcfg.dat, change this line to match your callsign
CALLSIGN=NOCALL
4) crate a sub-folder called 'rules'
5) copy default CQWW rule file into 'rules'
cp /usr/share/tlf/rules/cqww rules/
6) edit your local rules/cqww, change at least F3 and S_TU_MSG definitions

The .paras file is written only, you can ignore it. It's only used internally
to mark that TLF has been already started from that folder.

I guess you are using an older TLF version. It's always recommended to
build the latest one from github.

73,
Zoli


On Tue, Jan 03, 2023 at 09:09:47PM +0300, Alexej wrote:
>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
>--... ...--

Re: TLF publicity

[Csahok Zoltan]

Thanks for sharing, Drew! It's always nice to see TLF in action.
73,
Zoi

On Sun, Jan 01, 2023 at 05:08:33PM +, Drew Arnett wrote:
> I was delighted to see TLF in the California QSO Party results video.
> https://youtu.be/5OkXZqPYd_4?t=752
> 
> Drew
> n7da

Re: When writing the Cabrillo file the exchange is not prompted

[Csahok Zoltan]

Here a minimal working example. All fields are either pre-filled or disabled,
so no questions are asked.

73,
Zoli




sscbr.tgz
Description: application/gtar-compressed

Re: When writing the Cabrillo file the exchange is not prompted

[Csahok Zoltan]

> Is something like 'CABRILLO-EXCHANGE= # A 83 KS' supported?
Yes, exactly.

Regarding the template: could it be that TLF doesn't use it? Due to eg. not
finding it.
It works OK for me.

73,
Zoli

Re: When writing the Cabrillo file the exchange is not prompted

[Csahok Zoltan]

And there is surely neither CABRILLO-EXCHANGE nor SERIAL_EXCHANGE in
the logcfg and rule file?
(stock logcfg.dat has "CABRILLO-EXCHANGE= #" on line 171)

73,
Zoli

On Mon, Nov 21, 2022 at 06:37:33AM -0600, Nate Bargmann wrote:
> * On 2022 21 Nov 06:12 -0600, Csahok Zoltan wrote:
> > Try adding this line to SS_template.cbr:
> > 
> > EXCHANGE: 12 ABC
> 
> I added:
> 
> EXCHANGE: # A 83 KS
> 
> to the template and there is no change to the generated Cabrillo file.
> 
> 73, Nate
> 

Re: When writing the Cabrillo file the exchange is not prompted

[Csahok Zoltan]

Try adding this line to SS_template.cbr:

EXCHANGE: 12 ABC

As there is no way to deduct the sent exchange from a template
it has to be specified explicitly. An exception to this is the case when
SERIAL_EXCHANGE is set. (and this is also the default assumption, that's why
you see serial numbers in the cbr file)
This is not a valid Cabrillo field, but it's not taken over to the generated
file either.

Make also sure that CABRILLO-EXCHANGE is not set in logcfg/rule file.
Same for SERIAL_EXCHANGE, as it takes precedence.

Optionally, you could also use CABRILLO-EXCHANGE in logcfg/rule
instead of adding it to the template. All configs can be specified
both ways.

73,
Zoli


On Mon, Nov 21, 2022 at 05:19:08AM -0600, Nate Bargmann wrote:
> * On 2022 20 Nov 22:27 -0600, Csahok Zoltan wrote:
> > Hi Nate,
> > 
> > How are your CABRILLO* config parameters set?
> 
> In the rules file there is CABRILLO=ARRL-SS and in logcfg.date there is
> CABRILLO-TEMPLATE=SS_template.cbr and the template file has nothing out
> of the ordinary.
> 
> > Did TLF ask for the other fields like category info?
> 
> Yes, it mostly went through everything until I added the template file
> and the setting for its name in logcfg.dat.
> 
> 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
> 

Re: When writing the Cabrillo file the exchange is not prompted

[Csahok Zoltan]

Hi Nate,

How are your CABRILLO* config parameters set?
Did TLF ask for the other fields like category info?

73,
Zoli


On Sun, Nov 20, 2022 at 09:44:09PM -0600, Nate Bargmann wrote:
> Hi All.
> 
> I just completed working some of the ARRL SS this weekend.  As the logs
> must be submitted within seven (7) days, I set to work on generating the
> Cabrillo file.  The problem is that the program doesn't prompt for my
> sent exchange.  I built TLF from the master branch on Friday, if that
> makes a difference.
> 
> I am only seeing the serial number in the Cabrillo file, the rest of my
> sent exchange is not there.
> 
> 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
> 

Re: TLF Won't Start in Ununtu 22

[Csahok Zoltan]

Hi Alan,

Is this the stock TLF from Ubuntu repo or a locally compiled one?
If compiled then was it compiled on Ubuntu 20 or 22?
If it was compiled on 20 then recompile it.

Ubuntu 22 has Hamlib v4, whereas Ubuntu 20 uses Hamlib v3 packaged
bit confusingly into libhamlib2. So it looks like your TLF binary
requires the older Hamlib version that is not available on Ubuntu 22.


73,
Zoli


On Wed, Nov 09, 2022 at 05:20:01PM -0500, a...@alandove.com wrote:
> Hey, folks:
> 
> I haven't done any contesting for a few months, and in the meantime upgraded 
> my ham computer from Ubuntu 20 to 22. All's been fine: CQRLog, Flrig, and 
> Fldigi run as before. When I went to start up TLF today, though, I got:
> 
> "tlf: error while loading shared libraries: libhamlib.so.2: cannot open 
> shared object file: No such file or directory"
> 
> Hamlib and all the other dependencies are already installed. What's going on?
> 
>   - Alan (AB1XW)
> 
> Alan Dove, PhD
> alan.d...@gmail.com

Re: What is the tlf future?

[Csahok Zoltan]

Hi Martin,

You have probably experienced the Pyhton 2-to-3 switchover that caused a number 
of troubles.
Since 2020 version 3 is the only active one and as far as see it's reasonable 
stable.
Of course things can change, but I see no future issues at the moment.

Regarding the development of TLF I can only give my point of view.
For me a big pro that is can run in a single terminal without any
desktop environment involved. It also fits in my unix-like approach:
"do one thing and do it well". A loggers task is to allow logging QSOs
(meaning also helping sending the right messages) and as a bonus
it does score calculation, a bandmap view, and can save the log ready to be 
submitted.
It can also control the rig, but the actual low level control is done via 
Hamlib.
Same for keying: any cwdaemon compatible program can be used.
Or for voice messages: we let external tools play or record them.
All these are just as loosely coupled as neccessary.
As I use mostly the same rig+keyer rigctld and cwdaemon are
both started automatically at system boot. No need to touch them later on.

Configuration is typically a one time task, normally done before the contest.
I'm quite OK with editing some text files, see no benefit of a GUI.
Nevertheless it could be added even as a companion tool,
just as it was done for a graphical bandmap 
(https://github.com/zcsahok/tlf_bandmap)
The very first step would be to come up with a usable design.
Who and when implements it depends on the priorities and resources available
to the involved parties, as always.

In the last few years the somewhat rusty code base was considerably improved.
My goal was to be able to add new contests reasonably easily and also
to be able to run a contest end-to-end until generating a Cabrillo file.
We still have a number of open topics and broken features (like networking)
that will need considerable efforts. But all in all I see a remarkable progress.
What is vital is the user feedback as it help us stay on the right track.


73,
Zoli

Re: How to add a contest?

[Csahok Zoltan]

We are working on adding Python plugins to TLF. This will allow
defining a wide range of contests not falling into the currently
available categories.

One of such contests is the MWC were I take place semi-regularly.
My prototype plugin supports correct scoring inluding the "last letter"
multiplier. Band map shows new mults as expected. The exported Cabrillo
can be directly submitted, no post-processing is required.


73,
Zoli

On Sun, Oct 09, 2022 at 07:09:51PM +0200, Thomas Beierlein wrote:
> 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: Winkeydaemon question

[Csahok Zoltan]

Hi Martin,

Glad to hear that you were able to sort out the TLF-related issues.

Regading Winkeydaemon: you could try starting it with the option
-q $'\x09\x04'
This sets the initial message to disable PTT on Pin 5. I do not own
a Winkey device, so this is just a guess based on the docs.

Odroid N2: it's supported by Armbian (https://www.armbian.com/odroid-n2/)
so you can easily set up a Debian-like OS. Compiling TLF shall be no issue.

73,
Zoli

Re: Bug report - writeparas.c: Error opening file

[Csahok Zoltan]

Check your libcw6 version. There was a fix in 3.5.1 for something similar.
(see also http://unixcw.sourceforge.net/news.html )

73, Zoli

On Sun, Aug 28, 2022 at 07:19:04PM +, Marcin SP6MI wrote:
> It was Slackware, it doesn't have by default option to install tlf, it has to 
> be compiled and installed manually.
> No during test in ubuntu, I've found that cwdaemon starts extending dah 
> signals and ends transmission with setting carrier. It's strange, not sure if 
> it's causes by interface drivers, or cwdaemon.
>
> Thanks
> Br
> Marcin
>

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

[Csahok Zoltan]

Hi Nate,

Wow, you brought a lot of stuff to check!

I suggest to tackle the issues one by one on github.
It seems the "random mult" issue (#273) hit again after one year.
Could you please open issues for the input clearing on Esc
and the scoring anomaly?

If neither the log file nor the relevant rule were changed then
the scoring must come the same result and not prompt for re-saving.
During rescoring (and also at initial entry) only the second part
of the log line after the received exchange is updated. This done
to ensure that what the user sees (mults and points) is exactly what is
stored in the log file. We could of course store only the raw QSO data
in the log file, but as historically mults and points were also included
this feature was kept for compatibility and a kind of user friendliness
(mults/point can be check in log file without starting TLF).


73,
Zoli

On Sat, Aug 27, 2022 at 09:58:03PM -0500, Nate Bargmann wrote:
> 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
>

Re: Bug report - writeparas.c: Error opening file

[Csahok Zoltan]

It could also be that your distro's (older) TLF was started instead
of the one you compiled due to PATH issues.

73,
Zoli

On Sun, Aug 28, 2022 at 07:02:33PM +, Marcin SP6MI wrote:
> Hi,
> I was running in from subfolder in my $HOME, and tlf was built from latest 
> git version. Ok, I'll investigate this, now I'm testing on latest Ubuntu, and 
> looks that this problems doesn't occur.
> Thanks for tip.
>
> All the best,
> Br
> Marcin SP6MI
>
>
>

Re: Bug report - writeparas.c: Error opening file

[Csahok Zoltan]

Hi Marcin,

Thanks for reporting this issue.
I assume that you were running TLF from a directory that was not
writeable by your user (e.g. / or /usr/bin).
Could you check if this issue goes away when starting TLF
from a writeable directory? You could test writetability
by executing
  touch .paras
beforhand.

Generally, I suggest using the latest TLF from github as for example
this code for writing the .paras file has been dropped 1.5 years ago
in January 2021.
If you have any problems compiling from code, let us know.


73,
Zoli


On Fri, Aug 26, 2022 at 07:30:48PM +, Marcin SP6MI wrote:
>Hi,
>I've found unexpected behavior in latest tlf.
>System: Slackware current, tlf: 1.4, hamlib: 3.3
>Getting error:
>writeparas.c: Error opening file
>How to replicate:
>Setup rig control, which works, but run tlf without connected TRX, open
>info screen ":info", then any key to exit from info screen. Getting this
>error, tlf terminates.
>Thanks
>Br
>Marcin SP6MI

Re: winkeyer daeon

[Csahok Zoltan]

winkeydaemon doesn't write to /var/log.

Here's how I used it.
1) stop cwdaemon to free up the UDP port

sudo systemctl stop cwdaemon

2) start winkeydaemon in foreground mode (not as a daemon)

./winkeydaemon -n -d /dev/ttyUSBx

where ttyUSBx is the USB device of your winkeyer.

Pressing F9 (question mark) in TLF shall result in something like this:

Stat: 0xc0
Idle
Got $datagram = "?";
New client:127.0.0.1:60527
Fifo: ?
Wrote 1 bytes, Fifo:

Stat: 0xc4
Keyer busy
?

Stat: 0xc0
Idle



73,
Zoli

On Thu, May 26, 2022 at 05:12:25PM -0400, Ed wrote:
>
> I'm trying to use my Winkeyer using the daemon by Nate N0NB and I see
> no way to run it. Problem /var/log  shows no winkeyer daemon nor does
> it show anywhere. Guess it is just another dead end.
>
> Thanks for your input, much appreciated.
>
> Ed W3NR

Re: Re-sending a serial in S mode

[Csahok Zoltan]

Yes, underscore (_) is unfortunately hardcoded to send
   
no matter how F3 or S_TU_MSG is configured.
One more issue to be fixed...

Maybe sending the last F3/S_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.

Re: cwdaemon

[Csahok Zoltan]

Hi Zilvis,

Tried with the same cwdaemon (0.10.2) and libcw6 3.5.1-4 on Debian 11
(arch x86_64) + a fresh tlf build, and it had no issues.
cwdaemon started as

/usr/sbin/cwdaemon -d ttyS2 -n -xn -iii | tee cw.log

(I use a physical serial port)

Sent a ? using netcat:
echo '?' | nc -u -w0 localhost 6789
and then started tlf and pressed F9. Log is attached.

Do you see the lines when tlf initializes cwdaemon?
cwdaemon:II: escaped request: "0"
cwdaemon:II: requested resetting of parameters
...etc...

73,
Zoli

cwdaemon: Not forking...
Press ^C to quit
cwdaemon:II: setting sound system "Null"
cwdaemon:II: starting generator with sound system "Null": success
cwdaemon:II: ---
cwdaemon:II: request: "?"
cwdaemon:II: Morse character "?" to be queued in libcw
cwdaemon:DD: Morse character "?" has been queued in libcw
cwdaemon:II: keying event "1"
cwdaemon:II: keying event "0"
cwdaemon:DD: ...recv_from (no data)
cwdaemon:II: keying event "1"
cwdaemon:DD: ...recv_from (no data)
cwdaemon:II: keying event "0"
cwdaemon:DD: ...recv_from (no data)
cwdaemon:II: keying event "1"
cwdaemon:DD: ...recv_from (no data)
cwdaemon:II: keying event "0"
cwdaemon:DD: ...recv_from (no data)
cwdaemon:II: keying event "1"
cwdaemon:DD: ...recv_from (no data)
cwdaemon:II: keying event "0"
cwdaemon:DD: ...recv_from (no data)
cwdaemon:II: keying event "1"
cwdaemon:DD: ...recv_from (no data)
cwdaemon:II: keying event "0"
cwdaemon:DD: ...recv_from (no data)
cwdaemon:II: keying event "1"
cwdaemon:DD: ...recv_from (no data)
cwdaemon:II: keying event "0"
cwdaemon:II: low TQ callback: start, TQ len = 1, PTT flag = 0x00/ame
cwdaemon:II: low TQ callback: branch 3, PTT flag = 0x00/ame
cwdaemon:II: low TQ callback: end, TQ len = 1, PTT flag = 0x00/ame
cwdaemon:DD: ...recv_from (no data)
cwdaemon:DD: ...recv_from (no data)
cwdaemon:DD: ...recv_from (no data)
cwdaemon:DD: ...recv_from (no data)
cwdaemon:DD: ...recv_from (no data)
cwdaemon:DD: ...recv_from (no data)
cwdaemon:DD: ...recv_from (no data)
cwdaemon:II: ---
cwdaemon:II: escaped request: "0"
cwdaemon:II: requested resetting of parameters
cwdaemon:II: setting sound system "Null"
cwdaemon:II: starting generator with sound system "Null": success
cwdaemon:DD: PTT flag = 0 (0x00/ame)
cwdaemon:II: resetting completed
cwdaemon:II: ---
cwdaemon:II: escaped request: "3800"
cwdaemon:II: requested tone [Hz]: "800"
cwdaemon:II: tone: 800 Hz
cwdaemon:II: ---
cwdaemon:II: escaped request: "g70"
cwdaemon:II: requested volume [%]: "70"
cwdaemon:II: ---
cwdaemon:II: escaped request: "226"
cwdaemon:II: requested morse speed [wpm]: "26"
cwdaemon:II: ---
cwdaemon:II: escaped request: "71"
cwdaemon:II: requested weighting: "1"
cwdaemon:II: ---
cwdaemon:II: escaped request: "d0"
cwdaemon:II: requested PTT delay [ms]: "0"
cwdaemon:DD: PTT flag = 0 (0x00/ame)
cwdaemon:II: ensure PTT off
cwdaemon:II: ---
cwdaemon:II: escaped request: "e8"
cwdaemon:EE: band switch output not implemented
cwdaemon:DD: ...recv_from (no data)
cwdaemon:II: ---
cwdaemon:II: request: "?"
cwdaemon:II: Morse character "?" to be queued in libcw
cwdaemon:DD: Morse character "?" has been queued in libcw
cwdaemon:II: keying event "1"
cwdaemon:II: keying event "0"
cwdaemon:DD: ...recv_from (no data)
cwdaemon:II: keying event "1"
cwdaemon:DD: ...recv_from (no data)
cwdaemon:II: keying event "0"
cwdaemon:DD: ...recv_from (no data)
cwdaemon:II: keying event "1"
cwdaemon:DD: ...recv_from (no data)
cwdaemon:II: keying event "0"
cwdaemon:DD: ...recv_from (no data)
cwdaemon:II: keying event "1"
cwdaemon:DD: ...recv_from (no data)
cwdaemon:II: keying event "0"
cwdaemon:DD: ...recv_from (no data)
cwdaemon:II: keying event "1"
cwdaemon:DD: ...recv_from (no data)
cwdaemon:II: keying event "0"
cwdaemon:DD: ...recv_from (no data)
cwdaemon:II: keying event "1"
cwdaemon:DD: ...recv_from (no data)
cwdaemon:II: keying event "0"
cwdaemon:II: low TQ callback: start, TQ len = 1, PTT flag = 0x00/ame
cwdaemon:II: low TQ callback: branch 3, PTT flag = 0x00/ame
cwdaemon:II: low TQ callback: end, TQ len = 1, PTT flag = 0x00/ame
cwdaemon:DD: ...recv_from (no data)
cwdaemon:DD: ...recv_from (no data)
cwdaemon:DD: ...recv_from (no data)
cwdaemon:DD: ...recv_from (no data)
cwdaemon:DD: ...recv_from (no data)
cwdaemon:DD: ...recv_from (no data)
cwdaemon:DD: ...recv_from (no data)
cwdaemon:DD: ...recv_from (no data)

Re: TLF logger, countrylist file format?

[Csahok Zoltan]

Hi Gerard,

The fix is available as a pull request. May I ask you to check if it
solves the issue?

Here are the steps to build it in the /tmp/tlf directory:

/tmp$ git clone https://github.com/zcsahok/tlf --branch fix_countrylist_parsing
/tmp$ cd tlf
/tmp/tlf$ autoreconf --install --force
/tmp/tlf$ ./configure --prefix=/usr --datadir=/usr/share
/tmp/tlf$ make


73,
Zoli

Re: TLF logger, countrylist file format?

[Csahok Zoltan]

Hi Gerard,

Even if it's not easy to trigger the buffer overflow, things do not work
as expected. I've opened an issue: https://github.com/Tlf/tlf/issues/319

Thanks for reporting!

I suggest generally to use the latest code (master branch from github)
if possible, as it contains a number of fixes and improvements.
It also shortens the feedback loop for any issues found.

73,
Zoli

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

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

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


73,
Zoli

Re: What is "D=" Indicating?

[Csahok Zoltan]

It's the auto CQ delay time in 500 ms units.
It can be set through CQDELAY= and changed by Ctl-PgUp/PgDn.

73,
Zoli

Re: Cabrillo Export Error

[Csahok Zoltan]

Glad to hear that it worked! Current Tlf version supports specifying
Cabrillo header value through CABRILLO-* configuration parameters.
This avoids the need to enter all the values each time an export is made.
Have a look at share/logcfg.dat in the repo.

73,
Zoli

Re: Cabrillo Export Error

[Csahok Zoltan]

Hi Alan,

What Tlf version are you using?

Is this the expected format?
QSO: 14038 CW 2022-02-19 1732 AB1XW599 MAHA8VV599 KW

73,
Zoli

On Mon, Feb 21, 2022 at 09:29:58PM +, Alan Dove wrote:
> Hey, folks:
>
> I spoke too soon, here's one more issue. In trying to submit my log for
> ARRL DX CW, the bot threw it back in my face with a bunch of errors. It
> seems TLF has inserted an extra column of RSTs, for example:
>
> QSO: 14038 CW 2022-02-19 1732 AB1XW 599 599 MA
> HA8VV 599 KW
>
> It should instead be ... AB1XW 599 MA HA8VV ... with only one RST
> from me. As I only had 58 QSOs in my intermittent operation, I'm just
> manually editing the file, but folks with bigger entries will likely
> have a harder time.
>
>   --Alan (AB1XW)
>

Re: Xplanet works for a while then quits

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

Re: Moving the bandmap.

[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 

Re: ADIF bug

[Csahok Zoltan]

Hi Phil,

Reviewing the commit history I found that your issue was fixed around
this time last year by a fellow FD participant:
https://github.com/Tlf/tlf/pull/177

As 1.4.1 dates from April 2020 this fix is only part of the current master.
When using 1.5 and specifying '1D WV' as 'Your exchange' the exported ADIF
file has the right content. (I also added NO_RST config to suppress 599s)

3.10
TLF
1.5~git

LZ1QN/P15M21.0192CW2021060515011D
 WV003


73,
Zoli

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

[Csahok Zoltan]

I'll check this.

73,
Zoli

On Sun, Jan 17, 2021 at 12:47:37PM -0600, Nate Bargmann wrote:
> 
> I think the problem lies in the declaration of int_p in parse_logcfg.h,
> line 61 where its type is int and rig_model_t has a type of uint32_t.
> 
> Perhaps adding another member to that union that is of type rig_model_t
> and reworking the other calls will solve this?
> 
> 73, Nate
> 

Re: unixcw/cwdaemon and SDR support

[Csahok Zoltan]

Hi Matthew,

I did run into the issue with cwdaemon: after an upgrade its config file
was reset and it produced an erratic keying. Changing sound back to 'n'
solved the issue and my conclusion was that cwdaemon is meant for either
keying or side tone generation, but not for both. Which was just fine for me
as I anyway prefer the side tone generated by the rig. So I didn't bother
looking into it.

For unixcw you can contact Kamil (unixcw.sourceforge.net) although he
doesn't seem to be too active recently. I was able to get some fixes
included into the code by providing a PR on sourceforge. But that was
several years ago.

Is the root cause of the issue clear? Simply reducing buffer size wouldn't
hurt too much the performance IMO, so if that really cures the problem 
then it should be OK.

Re tlfmarkers: currenly it contains just the last handful of spots received
from the cluster, not what is exactly shown on the band map.
I think this is a bug, i.e. the band map evolved into a usable feature
whereas tlfmarkers remained using old spot handling.
Probably it has not many users, so no-one complained.
So this one is a task to be completed.

73,
Zoli
ha5cqz

Re: unixcw/cwdaemon and SDR support

[Csahok Zoltan]

Hi Matthew,

I did run into this issue with cwdaemon: after an upgrade its config file
was reset and it produced an erratic keying. Changing sound back to 'n'
solved the issue and my conclusion was that cwdaemon is meant for either
keying or side tone generation, but not for both. Which was just fine for me
as I anyway prefer the side tone generated by the rig. So I didn't bother
looking into it.

For unixcw you can contact Kamil (unixcw.sourceforge.net) although he
doesn't seem to be too active recently. I was able to get some fixes
included into the code by providing a PR on sourceforge. But that was
several years ago.

Is the root cause of the issue clear? Simply reducing buffer size wouldn't
hurt too much the performance IMO, so if that really cures the problem 
then it should be OK.

Re tlfmarkers: currenly it contains just the last handful of spots received
from the cluster, not what is exactly shown on the band map.
I think this is a bug, i.e. the band map evolved into a usable feature
whereas tlfmarkers remained using old spot handling.
Probably it has not many users, so no-one complained.
So this one is a task to be completed.

73,
Zoli
ha5cqz

micromuf

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

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

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

Re: Real RST possible?

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

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.

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

73,
Zoli

Re: Real RST possible?

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

Re: Rethinking the need for CT compatible mode

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

Re: padding in cwdaemon packets

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

Re: Using hamlib for CW keying

[Csahok Zoltan]

Now I remember that actually our FD is setup is just like this:
using a single USB-serial converter with RX/TX controlling the rig via hamlib
and DTR doing keying via cwdaemon. We had no issues with it. 
The only thing is that at Tlf start-up the key is down for a second.
I'll check hamlib config to see if this behaviour can be cured.
Thanks Nate for the pointer.

73,
Zoli

On Fri, Nov 29, 2019 at 12:51:59PM -0600, Nate Bargmann wrote:
> That's cool, Olaf.
> 
> It stands to reason that the DTR and RTS lines would explicitly need to
> be turned off as I think the kernel automatically enables them when an
> application initializes the port.
> 

Re: tlf and the nano editor

[Csahok Zoltan]

My 2c: try with "export EDITOR=..."

73,
Zoli

On Fri, Nov 22, 2019 at 07:18:35PM -0600, Nate Bargmann wrote:
> My first test with EDITOR=gedit resulted in nothing happening.  I ran
> gedit from another terminal and it opened fine.  Then I tried emacs

Re: Using hamlib for CW keying

[Csahok Zoltan]

Hi Christian,

Yes, keying does work with the script. But as far I can see
there are two issues with hamlib keying:

- in-band speed changes are not supported. one can't send "+++TEST---"

- sending a large message could block rig interface until it gets queued.

Given the rig protocol (KY command) and the way hamlib supports it
I see no option to circumvent these.

WinKeyer on the other hand offers in-band speed change and winkeyerdaemon
provides the buffering for a cwdaemon compatible UDP interface.

Correct me if I'm wrong here.


73,
Zoli


On Fri, Nov 22, 2019 at 12:18:18AM +0100, Christian Treldal wrote:
> 
> I tested today $echo "+\send_morse'test'" | nc -w 1 localhost 4532 to a
> IC-7610 and it cw happily
> 

Re: GLib version?

[Csahok Zoltan]

Hi Tom, hi Nate,

Thanks for the feedback. My conclusion is that it's safe to assume
that GLib >=2.40.0 is generally available.
Will change configure.ac accordingly (hard check).

I'm still wondering though where are the debian pkg dependencies specified
and how come Tlf 1.4.0 has different settings.

BTW in debian Tlf recommends sox and xplanet, but not cwdaemon.
Could this also be improved?


73,
Zoli

On Thu, Nov 21, 2019 at 06:53:49AM +0100, Thomas Beierlein wrote:
> 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
> --
> 

GLib version?

[Csahok Zoltan]

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

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?

I hope this doesn't break anything.

73,
Zoli

Re: TLF-1.4.0 release

[Csahok Zoltan]

Thanks, Tom!

Now it's time for feature requests and bug reports. :-)

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
> 
> 
> Besides some fixed bugs and internal improvements it provides 
> the following new features (see also the NEWS file and the man page
> for details):
> 
> TLF now allows the use of aliases in multiplier files. So you can
> have different section codes in exchange which count as the same
> multiplier. See discussion of MULT_FILE in man page for details.
> (Tnx for suggesting to N0NB). 
> 
> A new CALLMASTER= keyword was added to allow naming the used
> callmaster database file (default is still 'callmaster').
> 
> If RECALL_MULTS is set the content of the exchange field got
> always overwritten (e.g. by setting from initial exchange file).
> Now TLF keeps the content of the exchange field if it is not empty
> - actual input gets precedence over stored 'old' data.
> 
> TLF now respects the number of lines of your console window (linux
> console or terminal window). You can also resize the window
> vertically while TLF is running. The extra space is used to display
> additional lines for the bandmap.
> 
> The startup code was rewritten to allow a better readability of
> the startup messages by users
>   * 'verbose' startup ('tlf -v') waits for a key press before
> clearing the screen
>   * If started in an empty directory (new contest or first start)
> TLF switches to verbose mode automatically.
> 
> 
> 
> Major changes:
> Building TLF without Hamlib support is no longer supported. 
> 
> The old audio SCAN functionality got dropped as it was no longer
> working. 
> 
> The handling of multiplier entries in the logfile got changed to
> unify the handling between different contests.
> As a downside it may happen (depending on the contest rules) that
> TLF will get the multiplier counts wrong for logfiles written with
> an older version of TLF.
> In such an case you can export your logfile to cabrillo and
> re-import it to a new logfile in actual format (use 'tlf -i' for
> that).
> 
> Bugfixes:
> - Correct color display for TERM=xterm-256color
> - Correct transposition of check and section for arrlss (Tnx N0NB)
> - The old CQWW simulator code got repaired and should be working
>   again (see :sim in man page).
> - Fix segmentation fault on return from editlog(), 
> - Adapt to new 'rigmode' interface in hamlib library
> - Correct some problem in sideband selection when switching CW <->
>   SSB
> - Fix segfault on missing RIGPORT definition (tnx N0NB)
> - Fix possible segfaults in readcabrillo() function
> 
> 
> 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: Qso counter bug?

[Csahok Zoltan]

Hi Tom,

Made a quick test with the slowest machine that I use, a Pentium M 1.7GHz.
Execution of readcalls() took about 150 ms per 1k QSOs (data are below).
The code scales mostly linearly except dupe checking that is using
a slow linear search. Latter makes it O(N^2) but its contribution
is quite small: for 5k removing dupe checking reduced execution time to ~600 ms 
only.
Probably not worth changing it to a hash lookup at the moment.
Most of the time (~2/3) is spent figuring out DXCC info in getctydata().

Considering that typical Q counts are around or less than 1k we can conclude
that re-reading takes ~100 ms or less. Such a delay is completely bearable
for a deletion or other operations (e.g. log editing).

One thing I noticed is that upper bounds of various arrays are not checked,
the program crashes simply with segfault. It's prio3 but should be addressed 
later.

73,
Zoli

#
# Intel(R) Pentium(R) M processor 1.70GHz
#
# Q  ms
5000 740
4000 580
3000 410
2000 280
1000 130
800 110
500 70
300 45


On Thu, Nov 07, 2019 at 07:54:32AM +0100, Thomas Beierlein wrote:
> Rereading the problem and my own answer it seems I got it total wrong.
> Sorry for that (Lessons learned: DO not answer mails if you are not
> fully awake).
> 
> Zoli is right, there are two bugs to fix which should be done before
> release of 1.4.0 version.

> 
> Anyway we should test how much time a automatic rescore after delete
> takes and if we can use that now, given the actual speed of modern
> computers.
> 
> 73, de Tom
> 
> 

Re: Preparations for TLF-1.4.0 release

[Csahok Zoltan]

Hi Tom,

Nothing is pending from my side. Revert-after-grab will come later this year.

73,
Zoli

On Mon, Oct 28, 2019 at 07:09:27AM +0100, Thomas Beierlein wrote:
> 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
> 

Re: [Tlf-devel] TLF mentioned on Linux in the Ham Shack

[Csahok Zoltan]

Thanks for promoting TLF, Koos! Also thanks for sharing.
73,
Zoli

On Thu, Aug 08, 2019 at 09:11:19PM +0200, Koos van den Hout PE4KH wrote:
> 
> Linux in the Ham Shack is a podcast (audio series) on using Linux in
> amateur radio.
> 
> They did an episode on TLF, based on input by another amateur and
> myself. My comments were based on doing the IARU-HF contest in 2019 with
> TLF and in 2017 with yfktest.
> 
> Episode via
> 
> http://lhspodcast.info/2019/08/lhs-episode-295-tlf-contest-logger-deep-dive/
> 
> Enjoy,
> 
> Koos PE4KH
> 
> -- 
> PE4KH amateur radio station
> https://pe4kh.idefix.net/

___
Tlf-devel mailing list
Tlf-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tlf-devel

Re: [Tlf-devel] atoi hiscall

[Csahok Zoltan]

Hi Ervin,

Yes: if you enter a frequency in kHz as callsign, then the rig switches to it.
A nice but maybe undocumented feature.

73,
Zoli

> Another note to Thomas/Zoli HA5CQZ: do you know about this line?
> 
> https://github.com/Tlf/tlf/blob/tlf-1.3.2/src/callinput.c#L648
> 
>   if (atoi(hiscall) < 1800) {
> 
> this will always 0, and less than 1800 - or em I wrong? :)
> 
> 
> 73, Ervin
> HA2OS
> 
> 

___
Tlf-devel mailing list
Tlf-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tlf-devel

Re: [Tlf-devel] Fw: Entry issues & key issues

[Csahok Zoltan]

This can be quite easily done in recall_exchange without disturbing
the contest state machine (i.e. keeping Enter and Tab functions as-is).
A sensible correction.

73,
Zoli

> > > 
> > > As a sidenote: Maybe we should rethink the behaviour of the
> > > RECALL_MULTS and it should only pick up old exchange if the comment
> > > field is empty.
> > > 
> > > 73, de Tom DL1JBE
> > > 

___
Tlf-devel mailing list
Tlf-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tlf-devel

Re: [Tlf-devel] Entry issues & key issues

[Csahok Zoltan]

Thanks Tom for the clarification! It's indeed RECALL_MULTS that interferes
when used with Tab instead of Enter. I was able to reproduce it with Adam's
setup, while in my case it worked as I wasn't using this feature.
(and was using the Enter+Enter sequence)

btw while testing I realized that
tlf -f myconfig.dat
doesn't work, only
tlf -fmyconfig.dat
This one needs a fix, too.

73,
Zoli



On Mon, Jul 01, 2019 at 08:28:25PM +0200, Thomas Beierlein wrote:
> Hi Adam and Zoli,
> 
> maybe I can add some additional information related to the exchange
> problem.
> 
> Adam as Zoli told you the normal sequence is just to press ENTER after
> entering the call and again after the exchange. TAB is mostly to allow
> you to come back to the call input field from the exchange field for
> corrections.
> 
> Normally in your input sequence (TAB and then ENTER) the exchange is
> kept intact but you have to press ENTER twice.
> 
> ARRLFD is a little bit special here. It sets the RECALL_MULTS keyword
> automatically and tries to find an already known exchange from having
> worked the station on other band or from an INITIAL_EXCHANGE file to
> fill it in.
> 
> If TLF has no information about the exchange field it clears the
> exchange field and that is what you can observe.
> 
> So best would be to always use the ENTER key to switch to the next
> state of the QSO. 
> 
> As a sidenote: Maybe we should rethink the behaviour of the
> RECALL_MULTS and it should only pick up old exchange if the comment
> field is empty. 
> 
> 73, de Tom DL1JBE
> 
> 

___
Tlf-devel mailing list
Tlf-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tlf-devel

Re: [Tlf-devel] Entry issues & key issues

[Csahok Zoltan]

Hi Adam,

Thanks for the update. I also tried it with Konsole (v18.04.0, KDE 5.54)
and the cursor keys worked.

For the FD issue: is this the sequence that you use?
- input call
- Enter << cursor moves to exchange field
- input exchange
- Enter << here your exchange gets erased, QSO is not logged

Maybe send me your logcfg.dat and rules file, as with my setup it works
and I beleive I don't nothing special.

73,
Zoli



On Fri, Jun 28, 2019 at 03:45:54PM -0700, Adam Clark wrote:
> Hi again Zoli,
> 
> Just thought I'd let you know that I tested with the git version of tlf, and 
> adding some test entries (still using the field day setup/config), I have to 
> re-enter the exchange each time.  
> 
> However, cursor keys work, so that's a bonus!
> 
> 73,
> Adam
> 

___
Tlf-devel mailing list
Tlf-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tlf-devel

Re: [Tlf-devel] Entry issues & key issues

[Csahok Zoltan]

Hi Adam,

Glad to hear that you used TLF during the FD. We strive improving it,
so any feedback (including bugs reports, of course) is welcome.

The issue (or at least something similar) in SSB mode I've also experienced:
one had press Enter twice to get the QSO logged. Now, however, I was not
fully able reproduce it using the latest version from git.
Were you in CQ or S mode? Did you use Enter or Tab to switch to the exchange
field?

Regarding the arrow keys I have to check it on a KDE system.

73,
Zoli


On Thu, Jun 27, 2019 at 12:15:27PM -0700, Adam Clark wrote:
> Hi all,
> 
> I recently discovered TLF and used it to play around with during this past 
> Field Day.  I had a couple of questions about it as I had two issues:
> 
> First, I was operating phone only and when I went to log a QSO, very often 
> the 
> exchange field would just blank rather than enter the QSO.  Only once or 
> twice 
> did hitting enter (with both callsign and exchange entered) actually log the 
> QSO on that attempt.  I can tell you it was tricky at times waiting for 
> confirmation of a QSO and hitting enter watching the exchange disappear after 
> it might have been sitting there for a few minutes. 
> 
> The second item seems really strange but has obviously been an issue along 
> the 
> way - arrow keys didn't function in it at all, so I wasn't able to make use 
> of 
> any function that relied on them.
> 
> My environment was running tlf within kde's konsole.  After discovering 
> cursor 
> keys weren't working, I tried running it with "TERM=linux tlf", but that 
> didn't help the issue.
> 
> So I suspect there's likely items that I may have not done appropriately in 
> logcfg.dat or elsewhere, but I haven't found the information on what the 
> issues might have been.  Pretty much everything else got working very easily, 
> including rig control, packet interface, cabrillo export, etc. and I am 
> grateful for finding this logger!
> 
> The packaged version I have installed here is tlf-1.2.4.5-lp150.3.3.x86_64 
> from the opensuse hamradio repository.
> 
> Thanks all in advance!
> -Adam
> 
> 
> 
> ___
> Tlf-devel mailing list
> Tlf-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tlf-devel

___
Tlf-devel mailing list
Tlf-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tlf-devel

Re: [Tlf-devel] debian test failure

[Csahok Zoltan]

Managed to install a Sparc64 system and reproduce the issue.

It is a test-only error due to only storing a pointer instead of
saving the actual message string during the tests.
Some of these strings are generated in local variables
that may "disappear" before it comes to actually check them.

It's interesting that this issue didn't surface before. These
architectures (hppa, sparc64, alpha) seem to have a different
stack handling that zeroes new frames and thus overwrites previous
locals.

Preparing a PR with the fix.

73,
Zoli

On Thu, Nov 01, 2018 at 07:55:42PM +0100, Ervin Hegedüs wrote:
> 
> Anyway, the problem should be the old libc, old compiler, ...
> 
> I'm wondering what will you find. :)
> 
> 
> 73, Ervin
>  

___
Tlf-devel mailing list
Tlf-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tlf-devel

[Tlf-devel] v1.4 topics

[Csahok Zoltan]

Hi Tom,

Some topics from my backlog:

* improve the "grab a spot while in run mode" use case:
- while CQing user grabs a spot using Alt-G
- mode switches to Log, freq is saved
- change: as soon as the QSO is logged (or Esc'ed) mode+freq
switch back automatically
(i.e. no need to press # and +)
- advanced mode: if supported by radio VFO-B
could be used to receive both freqs.

* grab on-screen spots only ("WYSIWYG"):
- use case: screen is full of cluster spots; user wants to jump to DL1ABC;
by mistake types DL2; Alt-G jumps to DL2XYZ that is also spotted
but was not visible.
result: user is confused.
- on the other hand jumping to an off-screen spot could make sense
if one knows from another source that the station was spotted.

* switch to hamlib's freq_t for frequencies:
tlf currently typically uses kHz values as floats
demo of a rounding error: https://repl.it/repls/EasyForcefulPackage


73,
Zoli

On Thu, Sep 13, 2018 at 07:02:26AM +0200, Thomas Beierlein wrote:

> * allow vertical resizing of tlf (more room for cluster messages)
> * drop 'scan' menu with noise bridge, panorama scan and smeter display
>   (It did not work for a long time and I think no one is using it)
> 
> If there are additional ideas please add to the above list and send
> back.
> 
> 73, de Tom DL1JBE

___
Tlf-devel mailing list
Tlf-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tlf-devel

Re: [Tlf-devel] Preparation for tlf-1.3.1

[Csahok Zoltan]

Hi Tom,

Thanks for the information.

Once the release is out I'll start with the changes for making
hamlib mandatory. (i.e. getting rid of a bunch of conditional stuff)

73,
Zoli


On Tue, Sep 11, 2018 at 07:07:24AM +0200, Thomas Beierlein wrote:
> Hi all,
> 
> after a busy spring time and summer holiday I will try to pick up all
> merge requests from the last weeks and prepare a (long overdue)
> tlf-1.3.1 version in the next two weeks.
> 
> If all goes well a tlf-1.3.1_pre will be ready on the weekend. If there
> are no fixes needed a final version can come up a week later.
> 
> 73, de Tom DL1JBE
> 
> -- 
> "Do what is needful!"
> Ursula LeGuin: Earthsea
> --
> 
> 
> ___
> Tlf-devel mailing list
> Tlf-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tlf-devel

___
Tlf-devel mailing list
Tlf-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tlf-devel

Re: [Tlf-devel] Recommended code formatting settings for Emacs?

[Csahok Zoltan]

Hi Nate,

Sorry, using vim here.
But we could (at least in the future) set up astyle to expand tabs.

73,
Zoli

On Tue, Mar 27, 2018 at 07:58:09PM -0500, Nate Bargmann wrote:
> Well, it's been some time since I hacked on Tlf and I'm getting back to
> it.  As I've converted to using Emacs over the past year, the Tlf source
> uses a mixture of four space indents and, presumably, eight space tabs
> to align certain blocks of the code.  When I was using Geany, it was
> able to use the correct character depending on the indent level.  As I'm
> just looking at the code again, I'm curious if anyone else is using
> Emacs and what their settings are.
> 
> I presently have Emacs configured for four spaces for each indent level
> that we're using in Hamlib.  I could probably come up with a proper Tlf
> configuration with some help.
> 
> 73, Nate
> 
> -- 
> 
> "The optimist proclaims that we live in the best of all
> possible worlds.  The pessimist fears this is true."
> 
> Web: http://www.n0nb.us  GPG key: D55A8819  GitHub: N0NB



> ___
> Tlf-devel mailing list
> Tlf-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tlf-devel


___
Tlf-devel mailing list
Tlf-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tlf-devel

Re: [Tlf-devel] [dl1jbe/test-travis] moved to cmocka (#7)

[Csahok Zoltan]

Hi Tom,

Nice to hear that it works well.
In fact I have applied astyle formatting to the *.c files in test/,
and thus was assuming that all whitespaces are "correct".
Anyway, no problem making the patterns more relaxed.
Verbose mode is not that trivial. One can execute the script manually
and check the outputs (run_*.c and defs.am). At least this is much faster
than a full automake cycle.

73,
Zoli

On Thu, Feb 01, 2018 at 06:18:25PM +0100, Thomas Beierlein wrote:
> Hi Zoli,
> 
> I did convert some of my old tests to your framework. 
> 
> It works very well and the code is mostly much more clear than in the
> old version. Excellent work.
> 
> I found one small problem. Your test_ parser is a little bit picky with
> regards to whitespaces.
> 
>  void test_aa(void **state) 
> 
> is well, but
>  
>  void test_aa( void **state)
> 
> does not work at all. As there is also no verbose option it took me
> some time to find the problem. So maybe you can improve it a little bit
> to 
> - ignore whitespace in that test_ and setup_ definitions and
> - have some kind of verbose option for debugging.
> 
> Anyway, the solution works so well I will bring it back to the main tlf
> repo shortly. Well done.
> 
> 73, de Tom DL1JBE
> 
> 
>  Am Wed, 31 Jan 2018 10:23:29 -0800
> schrieb Zoltan Csahok :
> 
> > The setup is as follows
> > - there are test groups defined in `test_XX.c` files
> > - each file defines test functions `void test_AA(void **state)`
> > - each test can have setup/teardown functions (`setup_AA` and
> > `teardown_AA`) or there can be common (default) s/t functions.
> >   -  these are used in `cmocka_unit_test_setup_teardown`
> > - a test group can have overall s/t funcions, they are used in
> > `cmocka_run_group_tests`
> > - a test group specifies which objects it has to be linked with using
> > `// OBJECT bbb.o` syntax
> > - for each test group an own runner `run_XX` is generated and built
> >   - it is linked with `data.c` (global data) and `functions.c`
> > (common net/hamlib functions)
> > - wrapping can be added later if needed
> > - `make check` runs the test groups and reports their result
> > (PASS/FAIL). The actual logs are in `run_XX.log` files, they contain
> > detail info on failures. (they are output by the CI jobs)
> > - if new test groups or test cases are added then an `autoreconf -i`
> > must be executed
> > 
> > I've taken over your `scoreTest.c` as `test_score.c`: the change was
> > minimal, the actual test functions could be used as-is. Also
> > converted 2 of my basic tests.
> > 
> > As Ubuntu Trusty used by Travis has a too old cmocka I had to compile
> > v1.0.1 from sources.
> > 
> > I think this is quite usable and flexible now.
> > 
> 
> 
> -- 
> "Do what is needful!"
> Ursula LeGuin: Earthsea
> --
> 
> 
> ___
> Tlf-devel mailing list
> Tlf-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tlf-devel

___
Tlf-devel mailing list
Tlf-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tlf-devel

Re: [Tlf-devel] TravisCI - testing

[Csahok Zoltan]

Hi Tom,

I have checked your approach. I think the following combination of both
could work
- one test harness like my run.c + the (generated, if poss) test defs
- global data (mostly from src/main.c) in a global.c
- functions that use network/hamlib/curses mocked/wrapped in global.c
- per file test files (test_xxx.c), each with init/clean as needed
* there shouldn't be any interference between tests as long as they
set up everything they need
* a file tests the "public" functions defined in the corresponding .h 
file
- all used objects are linked from src
* no compilation is needed and
* they are used as they are present in tlf executable
- Makefile.am is used to set the right libs for linking
* mainly needed for glib (I didn't need this unil now)

Will make a prototype in test-travis to see if the above is feasible.

73,
Zoli


On Sun, Jan 28, 2018 at 04:35:53PM +0100, Thomas Beierlein wrote:
> Hi Zoli,
> 
> I just pushed my own 'tests' branch which I mentioned yesterday to 
> 
> https://github.com/dl1jbe/tlf/tree/tests
> 
> I uses cmocka-1.1.1 as test framework. It needs to be installed by hand
> before, as I did not integrate the check for it into configure.ac
> until now. 
> 
> Maybe we can integrate both our test setups.
> 
> 
> By the way I like your idea with the automatic generation of "defs.h"
> and the Makefile on the fly. I fear it will only work for tests where
> the code under test is located in one c-file only. There is still a lot
> of code which is tightly coupled and needs to compile in more than one
> file and stub out quite some other functions too (see my code).
> 
> One of my goals is to reduce that coupling to make testing easier.
> 
> 73, de Tom DL1JBE
> 
> 
> Am Fri, 26 Jan 2018 20:31:00 +0100
> schrieb Csahok Zoltan <ha5...@freemail.hu>:
> 
> > Tom, cloned your repo and Travis CI works quite well.
> > I'll try to add a CUnit test as per docs. Not all of Tlf
> > can be tested that way, but let's see how far we can get.
> > 
> > The .astylerc you shared looks OK to me.
> > (yes, I meant indent of 4 spaces)
> > 
> > 73,
> > Zoli
> > 
> > 
> > On Fri, Jan 26, 2018 at 02:42:41PM +0100, Thomas Beierlein wrote:
> > > That repo was only set up as a playground to test the features of
> > > travis-ci - not for real tlf development.
> > > 
> > > 73, de Tom  
> > 
> > ___
> > Tlf-devel mailing list
> > Tlf-devel@nongnu.org
> > https://lists.nongnu.org/mailman/listinfo/tlf-devel
> 
> 
> 
> -- 
> "Do what is needful!"
> Ursula LeGuin: Earthsea
> --
> 
> 
> ___
> Tlf-devel mailing list
> Tlf-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tlf-devel

___
Tlf-devel mailing list
Tlf-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tlf-devel

Re: [Tlf-devel] TravisCI

[Csahok Zoltan]

Tom, cloned your repo and Travis CI works quite well.
I'll try to add a CUnit test as per docs. Not all of Tlf
can be tested that way, but let's see how far we can get.

The .astylerc you shared looks OK to me.
(yes, I meant indent of 4 spaces)

73,
Zoli


On Fri, Jan 26, 2018 at 02:42:41PM +0100, Thomas Beierlein wrote:
> That repo was only set up as a playground to test the features of
> travis-ci - not for real tlf development.
> 
> 73, de Tom

___
Tlf-devel mailing list
Tlf-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tlf-devel

[Tlf-devel] code indenting?

[Csahok Zoltan]

Hi,

Another topic: as the code has grown over the time and many authors
contributed to it the formatting is inherently not consistent.

GNU indent is a powerful tool for C source formatting and present in any
modern Linux distro. We could define a common style simply by setting up
an .indent.pro file.
see http://www.gnu.org/software/indent/manual/indent.html#SEC4

I have no particular formatting preferences provided that tab size is 4.
Any suggestions?

73,
Zoli



___
Tlf-devel mailing list
Tlf-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tlf-devel

Re: [Tlf-devel] tlf without hamlib?

[Csahok Zoltan]

Hi Ervin, hi Tom,

Thanks for your replies. So, if there are no further objections
then I put making hamlib mandatory on the top of my list.

In fact it seems that even xmlrpc is compiled in the packaged versions.
But that I would not touch now.

73,
Zoli

On Tue, Jan 23, 2018 at 08:47:36PM +0100, Ervin Hegedüs wrote:
> Hi Zoli,
> 
> On Tue, Jan 23, 2018 at 06:52:33PM +0100, Csahok Zoltan wrote:
> > Hi,
> > 
> > Currently tlf has an optional hamlib support. I guess it's optional due
> > to historical reasons: hamlib may have been not always available or unstable
> > in the past.
> > Now hamlib is the de-facto standard rig control library for Linux.
> > A quick check of official debian tlf packages shows that in all versions
> > hamlib support is compiled in.
> 
> it's just one distribution. There are several others, which
> contains Tlf, eg. Gentoo (maintainer is Thomas), SuSE, Slackware,
> Arch, and many others.
> 
> > The question: could we make hamlib support mandatory?
> 
> Interesting idea, and I don't know any other reason to do that,
> just what if there is a distro, which doesn't distribute the Tlf
> with hamlib.
> 
> (After a quick search, in case of most distros I didn't find Tlf,
> or if the distro contains, that is a very old version of Tlf,
> eg. 1.1.3...)
> 
> > The advantage of this change is that all code parts not using hamlib
> > could be disposed of (incl. #ifdef's). Functionally there should be no 
> > drawbacks,
> > as rig control can be disabled with the -r option.
> 
> Note, that you should disable the RIG control if you place a
> comment sig to the lines in logcfg.dat, before the RIG_ options.
> 
> > What do you think? Is there a use case for tlf compiled without hamlib?
> 
> I think we should do - but I'm curious about the opinions of
> other users.
> 
> 
> 73, Ervin
> HA2OS
>  

___
Tlf-devel mailing list
Tlf-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tlf-devel