Re: TQSL 2.5 Release candidate (2.5-rc1) available for testing

Phil Cooper


Many thanks for the explanations. All is clear now with the frequency issue.

I think it is a shame that some programs can't yet cope with FT4, when so many of the free ones cope with it so well, and have done from the outset.
I can only hope that this will all get sorted in time.
As for the Zones issue, I can understand it where there is some doubt about the actual zone, but I am finding that many that are clearly in a specific zone still can't get it right. I recently had a match for an IK2 stations where he obviously had his CQ and ITU zones swapped, but thankfully, it's not a deal breaker for any WAS certificate for me. I also have instances of US stations with a similar issue, and I usually take time to email them and let them know. I guess about 10% respond and fix it, while the rest appear to ignore it.

Thanks again for all your efforts!

73 de Phil GU0SUP

-----Original Message-----
From: ARRL-LoTW@... [mailto:ARRL-LoTW@...] On Behalf Of Rick Murphy
Sent: 01 October 2019 02:00
To: ARRL-LoTW@...
Subject: Re: [ARRL-LoTW] TQSL 2.5 Release candidate (2.5-rc1) available for testing

On Mon, Sep 30, 2019 at 5:15 PM Phil Cooper via Groups.Arrl.Org
<> wrote:


Sterling work on the update!

A couple of queries....

1. Does this mean that folk using some programs that currently do NOT upload FT4 QSO's correctly now WILL be uploaded with the correct ADIF tags? My concern here is with my desire to chase FT4 WAS, and the fact that some (mostly paid-for programs) are not yet able to correctly handle FT4 as a mode for LoTW.
No, this was purely a defect in the ADIF Editor built in to TQSL. It
was saving any QSO that should have been stored as MODE/SUBMODE as
just MODE (<MODE:3>FT4). Yes, the behavior of TQSL was wrong in the
same way as some logging programs.

2. Is there some way of making sure that folk enter the correct CQ and ITU zones? Just recently, when syncing my logging program with LoTW, I am seeing more than a few where I get QSO Partner has not specified a CQ Zone (or ITU Zone), which means that I could potentially lost out on a credit somewhere.
If there's address data for the call, TQSL will pre-fill the zones. If
not, it's up to the user to know and fill them in. I've fixed the
problem cases where the zones are reversed, and Logbook fixes the
issues where the zones are incorrect for the entity. Forcing people to
enter a zone is not going to happen for reasons already hashed out.

3. Like Gary ZL2IFB. I am concerned about the wording of the first line, about frequency. Can you explain what this means please?
Already explained (I hope).
-Rick (MU/K1MU in April, possibly)
Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA

Join to automatically receive all group messages.