Re: Request: DXKeeper - QSL/QSL Config/LOTW

Dave AA6YQ

+ AA6YQ comments below

The situation occurs with FT8 with JTAlert when you end up in what is described as the well-known "RRR/73 Loop". I never advise the use of auto-logging - but many still ignore.

+ I am not familiar with the "RRR/73 Loop", but I'll assume that it results in the same QSO being logged more than once.

+ DXKeeper's "Add Requested" function will not add a QSO to the QSL Queue if an QSL Queue entry with the same callsign, band, mode, and time is already present. Thus the combination of the "RRR/73 Loop" and enabling auto-logging should not result in DXKeeper submitting already-submitted QSOs to LoTW.

I always advise and set up systems so that one has to manually upload records. You can have a situation say where the communication with LOTW via TQSL has failed for whatever reason as the pathway for using TQSL is complex.

+ How would a situation " where the communication with LOTW via TQSL has failed" cause an already-submitted QSO to be resubmitted?

Yet Systems such as JTAlert permit direct loading to systems such as QRZ.COM.

QRZ.COM has the dreaded "leaderboard" - and it is known that you need to modify a record then do the upload to QRZ.COM for it to update. Many users do this frequently. Then if you do a manual upload from DXKeeper via TQSL duplicates will be recognised.

+ If a user is uploading QSOs from QRZ.COM to LoTW, then they should export an ADIF file from that presumably will have "LoTW QSL Sent" set to 'Y', which when imported into DXKeeper will prevent DXKeeper from submitting an already-submitted QSO to LOTW.

I see this all the time and assist many ops with this issue.

Systems such as QRZ.COM etc. do not fail sends to LOTW if duplicates are detected anyway.

+ I'll alert the ARRL's IT staff, as this is inconsistent with expected behavior.

Having this function in any form allows circumvention as you identify. Yet not having the ability to over-ride duplicate checking creates chaos.

+ DXKeeper provides the ability to override TQSL's duplicate checking.

Having the ability to upload "corrected records" - that appear as duplicates to you - is not necessarily a bad thing either.

+ TQSL does not reject "corrected records" as duplicates.

Hey. I even research some QSO's across all systems (eQSL, QRZCQ etc) and then modify some records in QRZ.COM with correct data and then re-load that record up to LOTW through QRZ.COM. That way correct data filters back to my DXKeeper.

+ The activity you describe does not create duplicate QSOs.

Complex and valid reasoning here for a simple request ….

+ The conclusion I reach from your explanation is that QRZ is not complying with the ARRL's LoTW upload policy, and should be reminded to do so.

My request is based on simplicity - especially as I work with a number of Amateurs with disabilities..

Perhaps it needs to be raised with the LOTW administrative groups for a function to be implemented, perhaps via the web interface, to "weed out" old duplicates - only leaving the newest version?

+ Why should LoTW processing cycles be spent on weeding out duplicates that TQSL can prevent from ever reaching LoTW?

Perhaps the whole policy of being unable to delete records from LOTW needs to be reviewed?

+ The policy of not allowing users to delete records has nothing to do with the issue at hand. LoTW staff has conceptually agreed to provide the ability for users to hide and un-hide unconfirmed QSO. From the user's perspective, hiding a QSO will be equivalent to deleting it -- except that the QSO can be "unhidden" if it was mistakenly hidden. Since the ARRL has re-assigned its LoTW developers to work on other projects, I have no idea when this might be implemented.

Perhaps the simplest fix is for TQSL to be updated to permit upload of non-duplicate records yet only fail the duplicates?

+ That would require extending TQSL to report each rejected QSO to the user. It would require extending applications like DXKeeper to interpret TQSL's rejection reporting, and inform the user. Given the number of logging applications impacted, this would not be a "simple fix".

The simplest fix overall is to make "Permit uploading of QSO's already uploaded" sticky. Yes I have thought this through long and hard before making the request.

+ I strongly disagree.


Dave, AA6YQ

Join to automatically receive all group messages.