re-submitting QSOs to LoTW


Dave AA6YQ
 

Since TQSL 2.0 was released in 2013, it has rejected QSOs already submitted to LoTW. It does this to reduce the load on the LoTW
Server caused by ops who resubmit their entire logs each time they log a few new QSOs.

At that time, re-submitting an already-submitted QSO did not trigger a rejection by TQSL if the resubmitted QSOs had been
"improved" by correcting the contents of one or more fields (e.g. a gridsquare) or by adding additional information (e.g. a CQ
zone).

In TQSL 2.2.1, released in March 2016, this behavior was changed: resubmitted QSOs are rejected whether they've been improved or
not. This change was made to help prevent inadvertent changes to already-submitted QSOs, e.g. by ops who resubmit all of their QSOs
with a new Station Location after relocating, instead of just those made after relocating.

Thus if you wish to resubmit improved QSOs to LoTW using DXKeeper's "Upload to LoTW" function, you must first enable the "Permit
uploading of QSOs already uploaded to LoTW" option on the "QSL Configuration" window's LoTW tab. Note that the next time you start
DXKeeper, this option will intentionally not be enabled.

73,

Dave, AA6YQ


Rick Murphy
 

To explain the issue here, and why TQSL does what it does, here's some details.

TQSL records QSO uploads and will detect previously uploaded QSOs.

Initially, this detection included QSO details: Mode, Band, Date, Time. So you couldn't re-upload a QSO with some station again.

There were some stations re-uploading QSOs with location data changed, like grid, state, county, or zones. TQSL didn't initially detect these and just let them go. That caused QSLs on Logbook to come and go based on what Station Location the uploader used.  (Consider the case of a roving operator that changes their gridsquare then re-uploads all of their log repeatedly using the 'current' Grid. Confirmations come and go.)
So, in TQSL 2.2.1, I started tracking Station Location details as well, and generate errors when a new upload of a QSO tries to change Station Location details: grid, zones, state, county. The error tells the operator what they're changing and asks them to verify that the change is intentional.

The command that DXKeeper uses for uploading QSOs to Logbook doesn't have a way to tell DXKeeper that "there's a change in this QSO and you need to verify if it's OK with the Operator". The result is that adding Station Location details, or changing them in any way, will cause a QSO to trip the "already uploaded" error.

The problem in the reported case was that the operator added a CQ zone to a station location that previously did not have one. TQSL rejected that change, but should not have done that. The next release of TQSL won't reject QSOs with details ADDED, but will continue to reject QSO changes other than that.

For those to be uploaded, you need to use the "Permit uploading of QSOs already uploaded to LoTW" option that Dave explained.  Once the TQSL update is installed, adding station location details will not require using that option.
73,
    -Rick


On Sat, Jun 18, 2022 at 5:53 PM Dave AA6YQ <aa6yq@...> wrote:
Since TQSL 2.0 was released in 2013, it has rejected QSOs already submitted to LoTW. It does this to reduce the load on the LoTW
Server caused by ops who resubmit their entire logs each time they log a few new QSOs.

At that time, re-submitting an already-submitted QSO did not trigger a rejection by TQSL  if the resubmitted QSOs had been
"improved" by correcting the contents of one or more fields (e.g. a gridsquare) or by adding additional information (e.g. a CQ
zone).

In TQSL 2.2.1, released in March 2016, this behavior was changed: resubmitted QSOs are rejected whether they've been improved or
not. This change was made to help prevent inadvertent changes to already-submitted QSOs, e.g. by ops who resubmit all of their QSOs
with a new Station Location after relocating, instead of just those made after relocating.

Thus if you wish to resubmit improved QSOs to LoTW using DXKeeper's "Upload to LoTW" function, you must first enable the "Permit
uploading of QSOs already uploaded to LoTW" option on the "QSL Configuration" window's LoTW tab. Note that the next time you start
DXKeeper, this option will intentionally not be enabled.

     73,

              Dave, AA6YQ








--
Rick Murphy, D. Sc., CISSP-ISSAP, K1MU/4, Annandale VA USA


Jim Sjoberg
 

Dave and Rick,

The 'Permit uploading of QSO's already uploaded to LOTW' turned out to be
the solution.
As I said to Dave a couple of days ago, there should be an easy fix.
The box in DXkeepers LOTW entry for this must be checked after each QSO
upload. It drops out.
But it works.
The file error message initially was very misleading indicating a station
location change as a problem.
I want to thank both of you for all the research into finding a workable
solution for this.
Many QSO's already uploaded to LOTW without a hangup.
Thanks again.

Jim, AG9S

-----Original Message-----
From: DXLab@groups.io <DXLab@groups.io> On Behalf Of Dave AA6YQ
Sent: Saturday, June 18, 2022 4:53 PM
To: DXLab@groups.io
Subject: [DXLab] re-submitting QSOs to LoTW

Since TQSL 2.0 was released in 2013, it has rejected QSOs already submitted
to LoTW. It does this to reduce the load on the LoTW Server caused by ops
who resubmit their entire logs each time they log a few new QSOs.

At that time, re-submitting an already-submitted QSO did not trigger a
rejection by TQSL if the resubmitted QSOs had been "improved" by correcting
the contents of one or more fields (e.g. a gridsquare) or by adding
additional information (e.g. a CQ zone).

In TQSL 2.2.1, released in March 2016, this behavior was changed:
resubmitted QSOs are rejected whether they've been improved or not. This
change was made to help prevent inadvertent changes to already-submitted
QSOs, e.g. by ops who resubmit all of their QSOs with a new Station Location
after relocating, instead of just those made after relocating.

Thus if you wish to resubmit improved QSOs to LoTW using DXKeeper's "Upload
to LoTW" function, you must first enable the "Permit uploading of QSOs
already uploaded to LoTW" option on the "QSL Configuration" window's LoTW
tab. Note that the next time you start DXKeeper, this option will
intentionally not be enabled.

73,

Dave, AA6YQ


Dave AA6YQ
 

+ AA6YQ comments below
The 'Permit uploading of QSO's already uploaded to LOTW' turned out to be
the solution.
As I said to Dave a couple of days ago, there should be an easy fix.
The box in DXkeepers LOTW entry for this must be checked after each QSO
upload. It drops out.

+ As stated in the last sentence of my post in

https://groups.io/g/DXLab/message/208650

+ that's intentional.

But it works.
The file error message initially was very misleading indicating a station
location change as a problem.

+ Adding a CQ zone to your Station Location is what triggered the rejection by TQSL.

+ I missed the change made to TQSL back in 2016 in which resubmitting an improved or corrected QSO would lead to a rejection by TQSL.

     73,

            Dave, AA6YQ

       


Joe Subich, W4TV
 

The 'Permit uploading of QSO's already uploaded to LOTW' turned out to be the solution. As I said to Dave a couple of days ago, there should be an easy fix. The box in DXkeepers LOTW entry for this must be checked after each QSO upload. It drops out.
Rather than fix (upload) each QSO individually:
1) Update your tQSL "Station Location" to include the changes
2) add all of the QSOs to be fixed to the LotW upload queue
3) Set the "Allow Duplicates" option
4) Upload the entire queue at one time.

73,

... Joe, W4TV

On 2022-06-18 11:03 PM, Dave AA6YQ wrote:
+ AA6YQ comments below
The 'Permit uploading of QSO's already uploaded to LOTW' turned out
to be
the solution.
As I said to Dave a couple of days ago, there should be an easy fix.
The box in DXkeepers LOTW entry for this must be checked after each QSO
upload. It drops out.
+ As stated in the last sentence of my post in
https://groups.io/g/DXLab/message/208650 <https://groups.io/g/DXLab/message/208650>
+ that's intentional.
But it works.
The file error message initially was very misleading indicating a
station
location change as a problem.
+ Adding a CQ zone to your Station Location is what triggered the rejection by TQSL.
+ I missed the change made to TQSL back in 2016 in which resubmitting an improved or corrected QSO would lead to a rejection by TQSL.
     73,
            Dave, AA6YQ