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

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

 

DX Labs SpotCollector to Flex 6400/Maestro - FT8

K4PX K4PX
 

When I double click on an FT8 spot in DX Labs SpotCollector, the Flex 6400/Maestro uses USB instead of DIGU.  Any ideas why this would be happening?
Thanks!
Joe/K4PX

Re: PSK31 signal strength

Rick Boswell
 

What leads you to conclude that the SNR being reported is accurate?
Nothing. Perhaps inaccurate but maybe consistently so. Hoping for some  informed perspectives on this.

RB

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

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

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

Re: PSK31 signal strength

Dave AA6YQ
 

+ AA6YQ comments below

What leads you to conclude that the SNR being reported is accurate?

Nothing. Perhaps inaccurate but maybe consistently so. Hoping for some informed perspectives on this.

+ I don’t know if it's technically possible to compute an accurate SNR for PSK signals. Given the rapid decline in PSK utilization, taking time away from higher priority tasks to find out is not justifiable. If you point me at a description of how to compute SNR for PSK signals, I will consider implementing it in WinWarbler.

73,

Dave, AA6YQ

Re: DXBase2007 Log Import and Setting Multiple myQTH ID Correctly-Follow Up

Walter Miller, AJ6T
 

Hello again Dave and DXLab group,

I spent some months just logging new contacts into DXKeeper, mating it with WSJT-X/JTAlert, importing N1MM+ logs and so on. Ultimately I got tired of not having my entire QSO database handy (making it hard to know which DX stations to chase without referencing back to DXBase), so I finally did follow the instructions below to export my 32,000 DXBase QSOs into DXKeeper. Thankfully all seemed just fine at that point as evidenced by my DXCC stats across all bands being exactly the same in DXBase and DXKeeper.  I used the procedure Dave suggested below to cleanup the MyQTH data for the operations at multiple locations, and all seemed well.  However, I ran into problems after my first upload of DXKeeper data to LoTW (my entire old DXBase log is already in LoTW).  I filtered the DXKeeper log for just the recent QSOs with my current station callsign and current MYQTHID and uploaded those 337 QSOs to LoTW.  The status on those QSOs shows properly as "U" but when I go to the next step to Sync LoTW QSOs, DXKeeper crashes and becomes unresponsive.  The message I get after about 2 seconds is DXKeeper: Checking LoTW uploaded QSO data (Not Responding), and the DXKeeper windows are garyed-out.  My only recourse is to close DXKeeper and restart it.  The same thing happens after rebooting Windows 10.  How do I get out of this jam?

73, Walt, AJ6T

On 8/21/2018 5:51 PM, Dave AA6YQ wrote:
+ AA6YQ comments below

I am getting ready to import my DXBase 2007 log with 30,000+ QSOs into DXKeeper, and I need advice on how to deal with the multiple QTHs associated with those contacts.

+ Welcome to DXLab, Walt!

+ If you haven't already, I suggest that you review these articles:

<https://www.dxlabsuite.com/dxlabwiki/GettingStarted>

<https://www.dxlabsuite.com/dxlabwiki/Logging>

<https://www.dxlabsuite.com/dxlabwiki/QSOImport>

<https://www.dxlabsuite.com/dxlabwiki/ManageMultipleQTHs>


I managed the multiple QTHs in DXBase by a notation in the Comments field like "@Saratoga" or "@GF" (plus other commentary text appropriate to that QSO). I was careful to select appropriate QSOs and upload them to LoTW with the correct station location in TQSL. I used the DXBase "Special-1" field to group QSOs for a given operating session from a particular QTH with names like "LoTW27" and then only that batch of QSOs was uploaded to LoTW. Since I operate remotely from several different stations that I have setup, the LoTWxx indicators are not in contiguous blocks with respect to date and time.

What is the best way to deal with this messy import situation? I certainly don't want to examine each imported contact one at a time to set the DXKeeper myQTH value.

I am not a SQL programmer, but I can imagine something like this would work after defining the multiple possibilities for the DXKeeper myQTH
values:

If Comments contains "@GF" then set myQTH to "Great Falls"

+ Based on your description above, I'm assuming that the contents of the DXBase "Special-1" field need not be consulted, because the information in the DXBase Comments field is sufficient to accurate determine the location from which each QSO was made. I'm further assuming that the ADIF file generated by DXBase places in the information you captured in its Comments field is placed in either the COMMENT or NOTES ADIF field, both of which DXKeeper imports into its COMMENT item.

+ If these assumptions are incorrect, please let me know, and proceed no further.


+ Step 1 is to import your QSOs, and correct any errors reported by DXKeeper's Import function. On the Main window's "Import QSOs" tab,

1a. in the Options panel, uncheck all of the boxes except "Record import errors in error file", which should be checked

1b. set the "ADIF style options" panel to DXBase

1c. uncheck all boxes in the "Duplicate checking", "Substitution options" and "Replacement options" panels.

1d. click the Start button to initiate the Import function

+ Step 2 is to correct errors reported in the error file generated by the Import function; if there are a log of errors, please describe them here, as DXKeeper's ability to modify many QSOs "en masse" can be used to correct several classes of error rather than making corrects one-QSO-at-a-time

+ Step 3 is to make a backup copy of you log; this preserves all the work done so far in case your "multiple QTH" wrangling requires a second or third attempt.

+ Step 4 is to use the Main window's "my QTHs" tab to define a "my QTH" for each geographic location from which you've made QSOs. Unless you've made QSOs from different QTHs in the same town, I suggest a location's town name as its myQTH ID. At this stage, you don't need to fully populate each myQTH -- just specify a "my QTH ID" and maybe check/uncheck the WAS and VUCC boxes to indicate which QTHs are valid for these awards (if you're pursuing them).

+ Step 5 is repeated for each location from which you've made QSOs:

5a. filter the Log Page Display to contain only QSOs made from a particular location

5b. on the Main window's "My QTHs" tab, click on the entry for the "My QTH" associated with this location, and then click the "Set myQTH ID" button.

+ To filter the Log Page Display to contain only QSOs made from a particular location, you would use an SQL expression such as

COMMENT LIKE '*@GF*'

and

COMMENT LIKE '*@SARATOGA*'

+ The first will filter the Log Page Display to contain only QSOs that contain@GFanywhere within their COMMENT items.

+ This article explains how to filter QSOs in the Log Page Display:

<https://www.dxlabsuite.com/dxlabwiki/QSOFiltering>

+ In this case, the procedure to use in step 5a above is

* on the Main window's "Log QSOs" tab, click the Adv button to open the "Advanced Sorts, Filters, and Modifiers" window

* in the "Advanced Sorts, Filters, and Modifiers" window's "SQL Query Filters" panel,

*** type an SQL expression (like one from step 5.b above) into the first "QSL expression" box, and then click the Filter button to its right.

*** on the Main window's "Log QSOs" tab, confirm that the QSOs visible in the Log Page Display are those made from the location associated with the SQL expression you specified.

+ Keep in mind that you have a backup copy of your log, and that updating your logged QSOs for a particular location takes only a few keystrokes and mouse clicks -- so relax while performing this procedure! If you have questions or need help, don't hesitate to post them here.

73,

Dave, AA6YQ





Re: DX Labs SpotCollector to Flex 6400/Maestro - FT8

Dave AA6YQ
 

+ AA6YQ comments below

When I double click on an FT8 spot in DX Labs SpotCollector, the Flex 6400/Maestro uses USB instead of DIGU. Any ideas why this would be happening?

+ I'm assuming that you do not have WinWarbler running.

+ In the "Transceiver mode with no Digital Mode Application connected" panel on the General tab of SpotCollector's Configuration window, what is selected in the "non-RTTY Digital spot" sub-panel?

73,

Dave, AA6YQ

Re: DXBase2007 Log Import and Setting Multiple myQTH ID Correctly-Follow Up

Dave AA6YQ
 

Hello again Dave and DXLab group,

I spent some months just logging new contacts into DXKeeper, mating it with WSJT-X/JTAlert, importing N1MM+ logs and so on. Ultimately I got tired of not having my entire QSO database handy (making it hard to know which DX stations to chase without referencing back to DXBase), so I finally did follow the instructions below to export my 32,000 DXBase QSOs into DXKeeper. Thankfully all seemed just fine at that point as evidenced by my DXCC stats across all bands being exactly the same in DXBase and DXKeeper. I used the procedure Dave suggested below to cleanup the MyQTH data for the operations at multiple locations, and all seemed well. However, I ran into problems after my first upload of DXKeeper data to LoTW (my entire old DXBase log is already in LoTW). I filtered the DXKeeper log for just the recent QSOs with my current station callsign and current MYQTHID and uploaded those 337 QSOs to LoTW. The status on those QSOs shows properly as "U" but when I go to the next step to Sync LoTW QSOs, DXKeeper crashes and becomes unresponsive. The message I get after about 2 seconds is DXKeeper:

Checking LoTW uploaded QSO data (Not Responding), and the DXKeeper windows are garyed-out. My only recourse is to close DXKeeper and restart it. The same thing happens after rebooting Windows 10. How do I get out of this jam?

+ The words "Not Responding" appearing in window's title bar is Windows-speak for "busy performing an input/output operation". The appearance of these words does not mean "application has crashed".

+ The action you have taken directs LoTW to assemble information about your 32,000 QSOs, and then download that information to DXKeeper. This process could easily take 24 hours or more.

+ DXKeeper provides an alternative: it will provide you with a URL that will cause your web browser to download the information from LoTW; when that download is complete, DXKeeper will then process the downloaded file. Let me know if you're interested; if so, I'll provide step-by-step instructions.

+ Another alternative would be to direct DXKeeper to mark all of your QSOs imported from LoTW as being uploaded to LoTW and accepted by LoTW.

+ You will likely encounter a similar problem the first time you invoke "Sync LoTW QSLs".

73,

Dave, AA6YQ

Re: DXBase2007 Log Import and Setting Multiple myQTH ID Correctly-Follow Up

Walter Miller, AJ6T
 

Dave.....thanks again. Your support for DXLab is outstanding and much appreciated.

I was under the impression that the action I triggered with Sync LoTW QSOs applied only to the recently-uploaded 337 contacts.  I would prefer to pursue your first remedy via a URL since it appears to me that will scrub my LoTW situation more correctly than your second suggestion.  I say that since I know I made an error in DXBase that resulted in all of my QSOs being marked as uploaded to LoTW, when I know that some QSOs had been deliberately excluded from LoTW due to MyQTH kind of issues (one example is from very early contacts in my ham career with my original 1965 WB2REE callsign for which I had submitted paper cards long prior to the start of LoTW).  Will DXKeeper properly unmark the "U" status for logbook entries that were improperly indicated as uploaded in the original DXBase file that was imported to DXKeeper?

By the way, I do plan to further scrub my log to correct all of the MyQTH issues, and separately upload those QSOs to LoTW.  I realize, of course, that all of the HF QSOs from various locations around the country count toward DXCC and Challenge awards.  Will DXKeeper separately account for VUCC accounts from different QTHs that are too far apart to be joined together?

One final question while I have your attention.  What SQL query can I use to locate QSOs with no assigned MyQTH?

73, Walt, AJ6T

On 2/21/2019 7:50 PM, Dave AA6YQ wrote:
Hello again Dave and DXLab group,

I spent some months just logging new contacts into DXKeeper, mating it with WSJT-X/JTAlert, importing N1MM+ logs and so on. Ultimately I got tired of not having my entire QSO database handy (making it hard to know which DX stations to chase without referencing back to DXBase), so I finally did follow the instructions below to export my 32,000 DXBase QSOs into DXKeeper. Thankfully all seemed just fine at that point as evidenced by my DXCC stats across all bands being exactly the same in DXBase and DXKeeper. I used the procedure Dave suggested below to cleanup the MyQTH data for the operations at multiple locations, and all seemed well. However, I ran into problems after my first upload of DXKeeper data to LoTW (my entire old DXBase log is already in LoTW). I filtered the DXKeeper log for just the recent QSOs with my current station callsign and current MYQTHID and uploaded those 337 QSOs to LoTW. The status on those QSOs shows properly as "U" but when I go to the next step to Sync LoTW QSOs, DXKeeper crashes and becomes unresponsive. The message I get after about 2 seconds is DXKeeper:

Checking LoTW uploaded QSO data (Not Responding), and the DXKeeper windows are garyed-out. My only recourse is to close DXKeeper and restart it. The same thing happens after rebooting Windows 10. How do I get out of this jam?

+ The words "Not Responding" appearing in window's title bar is Windows-speak for "busy performing an input/output operation". The appearance of these words does not mean "application has crashed".

+ The action you have taken directs LoTW to assemble information about your 32,000 QSOs, and then download that information to DXKeeper. This process could easily take 24 hours or more.

+ DXKeeper provides an alternative: it will provide you with a URL that will cause your web browser to download the information from LoTW; when that download is complete, DXKeeper will then process the downloaded file. Let me know if you're interested; if so, I'll provide step-by-step instructions.

+ Another alternative would be to direct DXKeeper to mark all of your QSOs imported from LoTW as being uploaded to LoTW and accepted by LoTW.

+ You will likely encounter a similar problem the first time you invoke "Sync LoTW QSLs".

73,

Dave, AA6YQ



Re: DXBase2007 Log Import and Setting Multiple myQTH ID Correctly-Follow Up

Dave AA6YQ
 

+ AA6YQ comments below

Dave.....thanks again. Your support for DXLab is outstanding and much appreciated.

I was under the impression that the action I triggered with Sync LoTW QSOs applied only to the recently-uploaded 337 contacts.

+ "Sync LoTW QSOs" requests all QSOs accepted after the date shown beneath the "Sync LoTW QSOs" button. You can change this date by double-clicking it; that would be another way to not request and process all 30,000 QSOs in LoTW.

I would prefer to pursue your first remedy via a URL since it appears to me that will scrub my LoTW situation more correctly than your second suggestion. I say that since I know I made an error in DXBase that resulted in all of my QSOs being marked as uploaded to LoTW, when I know that some QSOs had been deliberately excluded from LoTW due to MyQTH kind of issues (one example is from very early contacts in my ham career with my original
1965 WB2REE callsign for which I had submitted paper cards long prior to the start of LoTW). Will DXKeeper properly unmark the "U" status for logbook entries that were improperly indicated as uploaded in the original DXBase file that was imported to DXKeeper?

+ Perhaps the first step should be for you to send me the DXBase-generated ADIF file that you imported into DXKeeper so I can see what if any LoTW status information was included. Please place this ADIF file in a zip archive, attach it to an email message, and send it to me via

aa6yq (at) ambersoft.com

+ After I see what LoTW information DXBase has provided, we can decide how best to get your DXKeeper log exactly synced with LoTW.

By the way, I do plan to further scrub my log to correct all of the MyQTH issues, and separately upload those QSOs to LoTW. I realize, of course, that all of the HF QSOs from various locations around the country count toward DXCC and Challenge awards. Will DXKeeper separately account for VUCC accounts from different QTHs that are too far apart to be joined together?

+ Yes. Each "my QTH" provides VUCC and WAS boxes that you can check to indicate whether QSOs made from the "my QTH" count towards your VUCC and WAS awards.

One final question while I have your attention. What SQL query can I use to locate QSOs with no assigned MyQTH?

+ This one:

LEN(MYQTHID)=0

73,

Dave, AA6YQ

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

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

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

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

Re: DX Labs SpotCollector to Flex 6400/Maestro - FT8

K4PX K4PX
 

Hello Dave,
Thank you for your reply and your help.  Sorry for the bother but I love your software and am trying to get fully back into ham radio after being off the air for 40 years!  To answer your questions:

+I DO NOT have WinWarbler running
+In the "Transceiver mode with no Digital Mode Application connected" panel on the General tab of SpotCollector's Configuration window, what is selected in the "non-RTTY Digital spot" sub-panel?
USB WAS SELECTED HERE...BY DEFAULT I GUESS?  SO I CHANGED IT TO "DIGU" AND NOW ALL IS WELL!!!!

Thanks Dave.  Man, how you know every nook and cranny of this software is amazing to me!  I guess because you wrote it!  Will you be in Dayton/Xenia?  Would love to shake your hand.

73,
Joe
K4PX

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

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

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

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

SpotCollector program error 10013 in module WebServerForm.WebTimer_Timer:

John AC4CA
 

Reloaded SC - nil; rebooted PC - nil: Spots.mdb - Spots table opens okay in Access, as do all others in Databses folder.

30-Jul-2014 07:14:07 > SpotCollector version 6.9.1

30-Jul-2014 07:14:07 > App.Path          : C:\DXLab\SpotCollector

30-Jul-2014 07:14:07 > App.exe           : SpotCollector

30-Jul-2014 07:14:07 > Operating System  : Windows 8 (64-bit) build 9200

30-Jul-2014 07:14:07 > Locale ID         : 1033 (0x409)

30-Jul-2014 07:14:07 > ANSI CodePage     : 1252

30-Jul-2014 07:14:07 > OEM CodePage      : 437

30-Jul-2014 07:14:07 > Country           : United States

30-Jul-2014 07:14:07 > Language          : English

30-Jul-2014 07:14:07 > DecimalSeparator  : .

30-Jul-2014 07:14:07 > ThousandSeparator : ,

30-Jul-2014 07:14:07 > DXLab Apps        : [CC,DXK]

30-Jul-2014 08:04:26 > program error 10013 in module WebServerForm.WebTimer_Timer: The requested address is a broadcast address, but flag is not set

30-Jul-2014 12:40:50 > SpotCollector shutdown

Re: SpotCollector program error 10013 in module WebServerForm.WebTimer_Timer:

rcktscientist64
 

An error log from 2014? Does the computer have the right date and time?

Reloaded SC - nil; rebooted PC - nil: Spots.mdb - Spots table opens okay in Access, as do all others in Databses folder.

30-Jul-2014 07:14:07 > SpotCollector version 6.9.1
30-Jul-2014 07:14:07 > App.Path : C:\DXLab\SpotCollector
30-Jul-2014 07:14:07 > App.exe : SpotCollector
30-Jul-2014 07:14:07 > Operating System : Windows 8 (64-bit) build 9200
30-Jul-2014 07:14:07 > Locale ID : 1033 (0x409)
30-Jul-2014 07:14:07 > ANSI CodePage : 1252
30-Jul-2014 07:14:07 > OEM CodePage : 437
30-Jul-2014 07:14:07 > Country : United States
30-Jul-2014 07:14:07 > Language : English
30-Jul-2014 07:14:07 > DecimalSeparator : .
30-Jul-2014 07:14:07 > ThousandSeparator : ,
30-Jul-2014 07:14:07 > DXLab Apps : [CC,DXK]
30-Jul-2014 08:04:26 > program error 10013 in module WebServerForm.WebTimer_Timer: The requested address is a broadcast address, but flag is not set
30-Jul-2014 12:40:50 > SpotCollector shutdown
_._,_._,_

Bruce - K5WBM

CQ-WAE File Error Message and Unable to Export Data With File Open Error Message

Mark Robinson
 

I started having issues with my DXKeeper today when I was running through my standard procedure to upload to LOTW, EQSL, CQQRZ and Clublog.


When I invoke DXKeeper it comes up with a message that says.  I never got this message before

CQ-WAE award file C:\DXLAB\DXKeeper\Databases\CQWAE.txt defines more than 100 regions

I then click on OK and DXKeeper starts OK.    I set my filter to display LOTW is Requested.   I then go into Export QSO's   Export Standard ADIF > Start

I set the target folder and file name and then I get the message  - (normally DXKeeper recalls the last file location. This time it did not and I had to drill down into the N drive)

unable to open ADIF file   N:\00_A_ DOC_AREA  etc etc        File Already Open

Note - (normally DXKeeper recalls the last file location. This time it did not and I had to drill down into the N drive)


The file hasn't even been created yet.   I rebooted my pc and restarted everything and still get this error message.

I am not sure what to do now.  I am running Win 7 Pro 64 bit and the latest version of DXKeeper 14.8.5

73 Mark N1UK



Re: SpotCollector program error 10013 in module WebServerForm.WebTimer_Timer:

John AC4CA
 

Thanks, yes it does. Set for local time.  Didn't notice the timestamp in the errorlog, but the file was written with the correct timestamp. -John