Topics

Request: DXKeeper - QSL/QSL Config/LOTW

Stephen ™
 

Hi Folks,

Can the DXKeeper QSL/ QSL Config/LOTW "Permit uploading of QSO's already uploaded" option please be made sticky?

In the past I realise that this option would have been not made sticky as processing power and resources utilised by the LOTW servers were limited. This is now not the case and/or a significant issue. Many people that I assist with deploying DXLab and DXKeeper (especially integrated with JT-Alert and WSJT-X /derivatives) complain that it is PAINFUL having to set this option each time, when uploading logs via DXKeeper, and say just one single record halts processing of thousands of batched records.

Most other systems that I am familiar with and support actively allow uploads to LOTW's central servers (i.e QRZ.COM, Clublog etc.) with the "allow uploading of already existing records" options set or have other ways to mitigate these issues.

This is a minor request I know - but one that I believe that many will find of great utility. It is only now a reasonable ask as technology and resources have advanced significantly to the point where this request can reasonably be considered :-)

Thanks and 73.

Steve I
VK3VM / VK3SIR

Dave AA6YQ
 

+ AA6YQ comments below

Can the DXKeeper QSL/ QSL Config/LOTW "Permit uploading of QSO's already uploaded" option please be made sticky?

+ Doing so would allow permanent circumvention of TQSL's mechanism that prevents already-uploaded QSOs from being uploaded. Before TQSL included this mechanism, many users routinely uploaded every logged QSO after logging a few new ones. Back then, more than half of all QSOs submitted to LoTW were unnecessary duplicates!


In the past I realise that this option would have been not made sticky as processing power and resources utilised by the LOTW servers were limited. This is now not the case and/or a significant issue.

+ Based on my understanding of LoTW gained during 5 years as a volunteer member of the ARRL's LoTW Committee, I strongly disagree.


Many people that I assist with deploying DXLab and DXKeeper (especially integrated with JT-Alert and WSJT-X /derivatives) complain that it is PAINFUL having to set this option each time, when uploading logs via DXKeeper, and say just one single record halts processing of thousands of batched records.

+ If DXKeeper's LoTW automation is correctly used, one should never encounter the "no QSOs were processed because some QSOs were duplicates or invalid" response from TQSL. Please describe the usage scenarios that generate this response.

73,

Dave, AA6YQ

ND9G Mike
 

From LotW:

A logging application that employs TrustedQSL to upload logged QSOs to LoTW is responsible for ensuring that QSOs already submitted to LoTW are not resubmitted unless they've subsequently been modified. Uploading all of a log's QSOs should not be routine. As described below, TQSL detects such duplicate QSOs and prevents them from being routinely uploaded.

 
My personal opinion on this, is that I think those that need to do this on any form of regular basis need to start thinking about having a single log of record that handles the bulk of the administrative functions. Trying to have every application uploading to everywhere, just because it can, isn't good practice.

73,
Mike ND9G


On Wed, Feb 20, 2019 at 7:10 PM Stephen ™ <stephen_i@...> wrote:

Hi Folks,

Can the DXKeeper QSL/ QSL Config/LOTW "Permit uploading of QSO's already uploaded" option please be made sticky?

In the past I realise that this option would have been not made sticky as processing power and resources utilised by the LOTW servers were limited. This is now not the case and/or a significant issue. Many people that I assist with deploying DXLab and DXKeeper (especially integrated with JT-Alert and WSJT-X /derivatives) complain that it is PAINFUL having to set this option each time, when uploading logs via DXKeeper, and say just one single record halts processing of thousands of batched records.

Most other systems that I am familiar with and support actively allow uploads to LOTW's central servers (i.e QRZ.COM, Clublog etc.) with the "allow uploading of already existing records" options set or have other ways to mitigate these issues.

This is a minor request I know - but one that I believe that many will find of great utility. It is only now a reasonable ask as technology and resources have advanced significantly to the point where this request can reasonably be considered :-)

Thanks and 73.

Steve I
VK3VM / VK3SIR

Dave AA6YQ
 

+ AA6YQ comments below

A logging application that employs TrustedQSL <http://www.arrl.org/files/file/LoTW%20Developer/tqsllib-doc.zip> to upload logged QSOs to LoTW is responsible for ensuring that QSOs already submitted to LoTW are not resubmitted unless they've subsequently been modified. Uploading all of a log's QSOs should not be routine. As described below, TQSL detects such duplicate QSOs and prevents them from being routinely uploaded.

https://lotw.arrl.org/lotw-help/developer-submit-qsos/?lang=en

My personal opinion on this, is that I think those that need to do this on any form of regular basis need to start thinking about having a single log of record that handles the bulk of the administrative functions. Trying to have every application uploading to everywhere, just because it can, isn't good practice.

+ If QSOs are successfully submitted to LoTW from another application, the "LoTW QSL Sent" fields of those QSOs should be set to 'Y'. If those QSOs are subsequently exported to an ADIF file and imported into DXKeeper, DXKeeper's "Add Requested" function would not add them to the QSL Queue for uploading to LoTW, as this function only populates the QSL Queue with QSOs whose "LoTW QSL Sent" items are set to 'R'.

73,

Dave, AA6YQ

Steve Ireland
 

Dave,

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

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.

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

Having the ability to upload "corrected records" - that appear as duplicates to you - is not necessarily a bad thing either. 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.

Complex and valid reasoning here for a simple request ….

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? Perhaps the whole policy of being unable to delete records from LOTW needs to be reviewed? Perhaps the simplest fix is for TQSL to be updated to permit upload of non-duplicate records yet only fail the duplicates?

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.

Regards,

Steve I
VK3VM / VK3SIR

Steve Ireland
 

Dave - slight correction/clarification: 

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? Perhaps the whole policy of being unable to delete records from LOTW needs to be reviewed? Perhaps the simplest fix is for TQSL to be updated to permit upload of non-duplicate records yet only fail the duplicates?

The way that eQSL handles duplicates checking is perhaps the "Gold standard" - offering a function to identify duplicates via the web interface and then offering either an "auto-fix" based on the latest record received OR permitting manual selection of the record to be retained. Perhaps such a function is needed for LOTW based on your identification of so many duplicates entering onto the system?

Yet I still feel that this is perhaps unnecessary and undesirable. Duplicates are NOT necessarily a bad thing under LOTW's policy … and restate that many duplicates from responsible Amateurs are actually corrected / updates / manually improved records ! I myself was always taught to only maintain ACCURATE data. Sometimes it becomes obvious that not all Amateurs out there do that - and one must go in and fix that data !

Having duplicates in the LOTW system maintains a record - a trail - of changes that have taken place :-) But as we know, it can also be considered to consume resources.

I still restate that t0he 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.

Regards,

Steve I
VK3VM / VK3SIR

 

Kent Olsen
 

Steve

I guess I dont understand the problem.

LotW is not a log book. It is a QSL confirmation service. What does it mater that there may be a duplicate qso in LotW? It only takes one for confirmation, the duplicate qso just sits there. You say it "consumes resources". Are there less available resources because of duplicates? Yes I'm asking...

QRZ and Eqsl are log book programs that allow you to do what ever you want with your data, just not the same as LotW.

I for one hope that LotW never lets a user delete contacts from its servers. That could be used in a bad way.

Out of all the qso's sent to LotW how many do you think are duplicates? I dont know, what does it mater?

Eqsl the "Gold Standard"? I get request on Eqsl all the time for a QSO I never had or could have had.

Thanks
73
Kent
N6WT


On Thu, Feb 21, 2019 at 2:35 PM Steve Ireland <vk3sir@...> wrote:

Dave - slight correction/clarification: 

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? Perhaps the whole policy of being unable to delete records from LOTW needs to be reviewed? Perhaps the simplest fix is for TQSL to be updated to permit upload of non-duplicate records yet only fail the duplicates?

The way that eQSL handles duplicates checking is perhaps the "Gold standard" - offering a function to identify duplicates via the web interface and then offering either an "auto-fix" based on the latest record received OR permitting manual selection of the record to be retained. Perhaps such a function is needed for LOTW based on your identification of so many duplicates entering onto the system?

Yet I still feel that this is perhaps unnecessary and undesirable. Duplicates are NOT necessarily a bad thing under LOTW's policy … and restate that many duplicates from responsible Amateurs are actually corrected / updates / manually improved records ! I myself was always taught to only maintain ACCURATE data. Sometimes it becomes obvious that not all Amateurs out there do that - and one must go in and fix that data !

Having duplicates in the LOTW system maintains a record - a trail - of changes that have taken place :-) But as we know, it can also be considered to consume resources.

I still restate that t0he 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.

Regards,

Steve I
VK3VM / VK3SIR

 

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

73,

Dave, AA6YQ

Dave AA6YQ
 

+ AA6YQ comments below

Dave - slight correction/clarification:

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? Perhaps the whole policy of being unable to delete records from LOTW needs to be reviewed? Perhaps the simplest fix is for TQSL to be updated to permit upload of non-duplicate records yet only fail the duplicates?

The way that eQSL handles duplicates checking is perhaps the "Gold standard" - offering a function to identify duplicates via the web interface and then offering either an "auto-fix" based on the latest record received OR permitting manual selection of the record to be retained. Perhaps such a function is needed for LOTW based on your identification of so many duplicates entering onto the system?

+ If eQSL is comfortable with their server spending cycles detecting duplicate QSOs, that's their decision. Having TQSL prevent duplicates from reaching the LoTW server cut the server's load by more than 50%!


Yet I still feel that this is perhaps unnecessary and undesirable. Duplicates are NOT necessarily a bad thing under LOTW's policy … and restate that many duplicates from responsible Amateurs are actually corrected / updates / manually improved records ! I myself was always taught to only maintain ACCURATE data. Sometimes it becomes obvious that not all Amateurs out there do that - and one must go in and fix that data !

+ That's incorrect. TQSL does not consider submission of a corrected QSO to be a duplicate.

73,

Dave, AA6YQ

Steve Ireland
 

Dave,

I appreciate all your comments and responses. Yet  there are a significant number of flaws in every argument arguments - both mine and yours. The arguments used here are skilled and I am sure has come up before. But perhaps the time is now to rethink... as many of these arguments appear to be formulated before the explosion of the JT-technologies and the subsequent auto-logging facilities supported with such (and additional support software such as JTAlert).

Comments that I have made should be taken further with an aim to improvement - improvements needed due to changed times and changed needs. As stated the JT-Software and the ability to "auto-log" and very rapidly changed the whole ball-game and exponentially increased data volumes; complete mind sets and ways of looking at problems, data and solutions were created. Hence hiding ones' head in the sand like an ostrich and hoping that matters will just mysteriously go away is invalid as a solution;  and I reiterate that it is not just the DXLab product but also other end products - some that integrate in and use the DXLab suite - that contribute to the LOTW issues that you raise.

To improve and make better is what we all should be striving for. Just hiding under a rock and hoping that it will go away leads to explosions in the end....

The responsible technical attitude is not to "poo-poo" ideas, discussion or advancement; the responsible AMATEUR (HAM - Help All Mankind) pathway should never be to "poo-poo" ideas or discussion that leads to advancement. Yet all so often - and almost with every product and system - there is resistance and division rather than forward vision and cooperative effort (often with a need to look outside the square) to solve problems.

Perhaps it is time to look at policies … time to look at advancement? The ARRL's supported and free LOTW database cannot just be an endless pit of any garbage thrown into it. 

Transparency, simplicity and advancement is what I am asking for … not divisive resistance that is rampant through AR.

To hash and rehash these issues only creates angst and anger and promulgates the so-called "wars" that are prevalent in AR. I will not comment further on this topic - but I will restate that there is good evidence (that I have provided) that having the "Permit uploading of QSO's already uploaded" made sticky … Yet our responses also clearly indicate that there should be efforts at the LOTW administrative end to simplify and support - to deal with this duplicates and unnecessary data transfers to the LOW server clusters at a technical level.


73 and end of my comments on the subject here. I am happy to work with the ARRL's LOTW team at any time to discuss ways and strategies to mitigate issues raised. I am easy to contact via voice :-)

Steve I
VK3VM / VK3SIR

BILL KENNAMER
 

Steve,

I can state positively that the LOTW database is NOT intended for your use. It is a secure database for use by DXCC to allow for electronic QSLing. That is all it is. It is not intended as backup storage for your logs. It is for keeping DXCC (and some other awards) secure, and as such cannot and should not be changed by users. It does allow the user to see his award progress, and necessary corrections can be made by DXCC staff only, as it should be in a secure database.

The primary, and really only, reason that LOTW exists is so that you don't have to send cards by mail to the DXCC Desk, and to relieve you of some of the burden of bureau QSLing for contacts where you don't need the card but the other party needs the credit for their award.

73

On Friday, February 22, 2019, 2:12 AM, Steve Ireland <vk3sir@...> wrote:

Dave,

I appreciate all your comments and responses. Yet  there are a significant number of flaws in every argument arguments - both mine and yours. The arguments used here are skilled and I am sure has come up before. But perhaps the time is now to rethink... as many of these arguments appear to be formulated before the explosion of the JT-technologies and the subsequent auto-logging facilities supported with such (and additional support software such as JTAlert).

Comments that I have made should be taken further with an aim to improvement - improvements needed due to changed times and changed needs. As stated the JT-Software and the ability to "auto-log" and very rapidly changed the whole ball-game and exponentially increased data volumes; complete mind sets and ways of looking at problems, data and solutions were created. Hence hiding ones' head in the sand like an ostrich and hoping that matters will just mysteriously go away is invalid as a solution;  and I reiterate that it is not just the DXLab product but also other end products - some that integrate in and use the DXLab suite - that contribute to the LOTW issues that you raise.

To improve and make better is what we all should be striving for. Just hiding under a rock and hoping that it will go away leads to explosions in the end....

The responsible technical attitude is not to "poo-poo" ideas, discussion or advancement; the responsible AMATEUR (HAM - Help All Mankind) pathway should never be to "poo-poo" ideas or discussion that leads to advancement. Yet all so often - and almost with every product and system - there is resistance and division rather than forward vision and cooperative effort (often with a need to look outside the square) to solve problems.

Perhaps it is time to look at policies … time to look at advancement? The ARRL's supported and free LOTW database cannot just be an endless pit of any garbage thrown into it. 

Transparency, simplicity and advancement is what I am asking for … not divisive resistance that is rampant through AR.

To hash and rehash these issues only creates angst and anger and promulgates the so-called "wars" that are prevalent in AR. I will not comment further on this topic - but I will restate that there is good evidence (that I have provided) that having the "Permit uploading of QSO's already uploaded" made sticky … Yet our responses also clearly indicate that there should be efforts at the LOTW administrative end to simplify and support - to deal with this duplicates and unnecessary data transfers to the LOW server clusters at a technical level.


73 and end of my comments on the subject here. I am happy to work with the ARRL's LOTW team at any time to discuss ways and strategies to mitigate issues raised. I am easy to contact via voice :-)

Steve I
VK3VM / VK3SIR

Joe Subich, W4TV
 

On 2019-02-22 3:12 AM, Steve Ireland wrote:

But perhaps the time is now to rethink... as many of these arguments appear to be formulated before the explosion of the JT-technologies and the subsequent auto-logging facilities supported with such (and additional support software such as JTAlert).
The appearance of WSJT-X with auto upload capabilities *DOES NOT* in
any way change the fact that DXKeeper - or any other logging software -
has no business automatically uploading the same SOs over and over and
over again. There is *ABSOLUTELY NO JUSTIFIABLE REASON* to make "allow
duplicates" sticky other that to enable lazy/stupid operators and
intentionally break LotW.

As far as I'm concerned, anyone who needs a sticky "allow duplicates"
can stop using LotW. We're better off without such lazy users - they're probably the same users who can't get their station locations right and
who continually upload their entire log with a different location every
time they move.

73,

... Joe, W4TV


On 2019-02-22 3:12 AM, Steve Ireland wrote:
Dave,
I appreciate all your comments and responses. Yet  there are a significant number of flaws in every argument arguments - both mine and yours. The arguments used here are skilled and I am sure has come up before. But perhaps the time is now to rethink... as many of these arguments appear to be formulated before the explosion of the JT-technologies and the subsequent auto-logging facilities supported with such (and additional support software such as JTAlert).
Comments that I have made should be taken further with an aim to improvement - improvements needed due to changed times and changed needs. As stated the JT-Software and the ability to "auto-log" and very rapidly changed the whole ball-game and exponentially increased data volumes; complete mind sets and ways of looking at problems, data and solutions were created. Hence hiding ones' head in the sand like an ostrich and hoping that matters will just mysteriously go away is invalid as a solution;  and I reiterate that it is not just the DXLab product but also other end products - some that integrate in and use the DXLab suite - that contribute to the LOTW issues that you raise.
To improve and make better is what we all should be striving for. Just hiding under a rock and hoping that it will go away leads to explosions in the end....
The responsible technical attitude is not to "poo-poo" ideas, discussion or advancement; the responsible AMATEUR (HAM - Help All Mankind) pathway should never be to "poo-poo" ideas or discussion that leads to advancement. Yet all so often - and almost with every product and system - there is resistance and division rather than forward vision and cooperative effort (often with a need to look outside the square) to solve problems.
Perhaps it is time to look at policies … time to look at advancement? The ARRL's supported and free LOTW database cannot just be an endless pit of any garbage thrown into it.
Transparency, simplicity and advancement is what I am asking for … not divisive resistance that is rampant through AR.
To hash and rehash these issues only creates angst and anger and promulgates the so-called "wars" that are prevalent in AR. I will not comment further on this topic - but I will restate that there is good evidence (that I have provided) that having the "Permit uploading of QSO's already uploaded" made sticky … Yet our responses also clearly indicate that there should be efforts at the LOTW administrative end to simplify and support - to deal with this duplicates and unnecessary data transfers to the LOW server clusters at a technical level.
73 and end of my comments on the subject here. I am happy to work with the ARRL's LOTW team at any time to discuss ways and strategies to mitigate issues raised. I am easy to contact via voice :-)
Steve I
VK3VM / VK3SIR

Barry Murrell ZS2EZ
 

Well said Joe - could not agree more!! Making "Allow Duplicates" sticky is a recipe for disaster!!!!

I do NOT auto-upload to either LoTW or eQSL - after each operating session it takes me a WHOLE 3 mouse clicks to upload! This makes sure that any "problem QSOs" are sorted out BEFORE being sent to LoTW.

It seems that the whole auto-upload craze is resulting in a lot of sloppy, inaccurate logging... and lazy operators that couldn't be bothered about the integrity of their logs.

As for eQSL.... every time I sync my log with eQSL I get a list of errors, indicating claimed QSOs that never happened. I treat eQSL in the same way as my LoTW QSOs - no match, no confirmation. I never "fix" my log to match a claim.... seeing as I only really upload to eQSL (and QRZ.com) as a service to other users (I am interested primarily in DXCC and WAS), they are really not a priority to me.

73 de BARRY MURRELL ZS2EZ
KF26ta - Port Elizabeth, South Africa
EPC#0558 DMC#1690 WCC#030 30MDG#4081
DXCC HONOR ROLL (331/340)
DXCC(mixed)#41,146 DXCC(RTTY)#1,916
DXCC(phone)#34,990 DXCC(CW)#11,714
DXCC 80m,40m,30m,20m,17m,15m,12m,10m 5BDXCC#8,916
WAS Triple Play #492 WAS(RTTY)#538 WAS(Digital)#163-Endorsements JT65,FT8
WAZ(RTTY)#185 WAE-I(mixed)#72 WAZS(mixed)#214 AAA#1569
AS ZR6DXB: VUCC(50MHZ)#1,334 UKSMG WAE(Silver)#75 UKSMG AFRICA#22 WAC (Satellite)
website : www.zs2ez.co.za

-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Joe Subich, W4TV
Sent: Friday, 22 February 2019 15:27
To: DXLab@groups.io
Subject: Re: [DXLab] Request: DXKeeper - QSL/QSL Config/LOTW


On 2019-02-22 3:12 AM, Steve Ireland wrote:

But perhaps the time is now to rethink... as many of these arguments
appear to be formulated before the explosion of the JT-technologies
and the subsequent auto-logging facilities supported with such (and
additional support software such as JTAlert).
The appearance of WSJT-X with auto upload capabilities *DOES NOT* in any way change the fact that DXKeeper - or any other logging software - has no business automatically uploading the same SOs over and over and over again. There is *ABSOLUTELY NO JUSTIFIABLE REASON* to make "allow duplicates" sticky other that to enable lazy/stupid operators and intentionally break LotW.

As far as I'm concerned, anyone who needs a sticky "allow duplicates"
can stop using LotW. We're better off without such lazy users - they're probably the same users who can't get their station locations right and who continually upload their entire log with a different location every time they move.

73,

... Joe, W4TV


On 2019-02-22 3:12 AM, Steve Ireland wrote:
Dave,

I appreciate all your comments and responses. Yet there are a significant number of flaws in every argument arguments - both mine and yours. The arguments used here are skilled and I am sure has come up before. But perhaps the time is now to rethink... as many of these arguments appear to be formulated before the explosion of the JT-technologies and the subsequent auto-logging facilities supported with such (and additional support software such as JTAlert).

Comments that I have made should be taken further with an aim to improvement - improvements needed due to changed times and changed needs. As stated the JT-Software and the ability to "auto-log" and very rapidly changed the whole ball-game and exponentially increased data volumes; complete mind sets and ways of looking at problems, data and solutions were created. Hence hiding ones' head in the sand like an ostrich and hoping that matters will just mysteriously go away is invalid as a solution; and I reiterate that it is not just the DXLab product but also other end products - some that integrate in and use the DXLab suite - that contribute to the LOTW issues that you raise.

To improve and make better is what we all should be striving for. Just hiding under a rock and hoping that it will go away leads to explosions in the end....

The responsible technical attitude is not to "poo-poo" ideas, discussion or advancement; the responsible AMATEUR (HAM - Help All Mankind) pathway should never be to "poo-poo" ideas or discussion that leads to advancement. Yet all so often - and almost with every product and system - there is resistance and division rather than forward vision and cooperative effort (often with a need to look outside the square) to solve problems.

Perhaps it is time to look at policies … time to look at advancement? The ARRL's supported and free LOTW database cannot just be an endless pit of any garbage thrown into it.

Transparency, simplicity and advancement is what I am asking for … not divisive resistance that is rampant through AR.

To hash and rehash these issues only creates angst and anger and promulgates the so-called "wars" that are prevalent in AR. I will not comment further on this topic - but I will restate that there is good evidence (that I have provided) that having the "Permit uploading of QSO's already uploaded" made sticky … Yet our responses also clearly indicate that there should be efforts at the LOTW administrative end to simplify and support - to deal with this duplicates and unnecessary data transfers to the LOW server clusters at a technical level.

73 and end of my comments on the subject here. I am happy to work with
the ARRL's LOTW team at any time to discuss ways and strategies to
mitigate issues raised. I am easy to contact via voice :-)

Steve I
VK3VM / VK3SIR

Dave AA6YQ
 

+ AA6YQ comments below

There is *ABSOLUTELY NO JUSTIFIABLE REASON* to make "allow duplicates" sticky other that to enable lazy/stupid operators and intentionally break LotW.

As far as I'm concerned, anyone who needs a sticky "allow duplicates" can stop using LotW. We're better off without such lazy users - they're probably the same users who can't get their station locations right and who continually upload their entire log with a different location every time they move.

+ Joe, I know that you have long been passionate about preventing misuse of LoTW, but it is inappropriate here to refer to anyone as lazy or stupid. Please don't do that again.

73,

Dave, AA6YQ