Date   

Re: Unable to see why QSO is marked as Broken

Stewart Wilkinson
 

I seem to have fixed them this time. Seems that somehow the Rx Freq got set and although the rx band appeared to be set correctly it was not happy.

I'll adapt my import / frequency correction process for the next time and hope that sorts it.

--
Stewart G0LGS


Re: Spotcollector versus Capture&Commander

Dave AA6YQ
 

+ AA6YQ comments below

Starting 06/06/2021 i noticed a strange fenomena.

I used to D-click on a spotted Callsign, near the middel of the Callsign. Normally the arrow of the mouse changes into a cursor, blinking most left of the spotted Callsign,second Column. Then Capture is populated with all info, and Commander is following as it should do.
Then the cursor stops blinking, and the black arrow in the most left column moves to the latest spot received.

It happens sometime, that after D-clicking on the spotted Callsign, the blinking cursor is not placed left of the Callsign, but stays in the middel of the Callsign, exactly on the place i D-clicked. Capture and Commander are not following. The black arrow in the left most column then stays near the clicked callsign for a very long time.

Strange, but sometimes after minutes, or after selecting another spotted Callsign, and then D-clicking again on the earlier spot, all things went to normal.

+ Whether or not the Capture window is populated from the information in a double-clicked Spot Database Entry depends on the Entry's Mode, whether or not a digital mode application is "connected", and the settings in the "Actions with Digital Mode Application connected" panel on the Configuration window's General tab, as described in

https://www.dxlabsuite.com/spotcollector/Help/ConfigurationGeneral.htm#Phone%20Modes%20Panel

73,

Dave, AA6YQ


Re: Unable to see why QSO is marked as Broken

Dave AA6YQ
 

+ AA6YQ comments below

I have 10 QSO's that I imported from another logging program that DXKeeper thinks are broken, yet none of the Visible fields in the log seem to be showinfg the RED or BLUE font.

If I click 'Edit' for any of these QSO's then it will not let me 'Save' them.

They appear to have been uploaded to LoTW perfectly.

Is there another way to find what it thinks is wrong or to get it to re-check the entries ?

+ See

https://www.dxlabsuite.com/dxkeeper/Help/LogIntegrity.htm

73,

Dave, AA6YQ


Spotcollector versus Capture&Commander

eddy on5jk
 

Hallo Dave and all other users of DXLab.

Starting 06/06/2021 i noticed a strange fenomena.

I used to D-click on a spotted Callsign, near the middel of the Callsign. Normally the arrow of the mouse changes into a cursor, blinking most left of the spotted Callsign,second Column. Then Capture is populated with all info, and Commander is following  as it should do. Then the cursor stops blinking, and the black arrow in the most left column moves to the latest spot received.

It happens sometime, that after D-clicking on the spotted Callsign, the blinking cursor is not placed left of the Callsign, but stays in the middel of the Callsign, exactly on the place i D-clicked. Capture and Commander are not following. The black arrow in the left most column then stays near the clicked callsign for a very long time.

Strange, but sometimes after minutes, or after selecting another spotted Callsign, and then D-clicking again on the earlier spot, all things went to normal.

Mostly my SC is fltered by SQL, showing ON-stations, FaunaFlora activations or French Stations, and only SSB.

All tested Callsigns are in the "SSB" segment according to the loaded "Bandmode" file.

What is happening?  Thanks for help.

Eddy ON5JK


Unable to see why QSO is marked as Broken

Stewart Wilkinson
 

Hi,

I have 10 QSO's that I imported from another logging program that DXKeeper thinks are broken, yet none of the Visible fields in the log seem to be showinfg the RED or BLUE font.

If I click 'Edit' for any of these QSO's then it will not let me 'Save' them.

They appear to have been uploaded to LoTW perfectly.

Is there another way to find what it thinks is wrong or to get it to re-check the entries ?

--
Stewart G0LGS


Re: 20yr log transcription and LoTW

Dave AA6YQ
 

+ AA6YQ comments below

I mentioned earlier that I was doing a project to get my buddy's logs of 20yrs from paper to digital form. He and his wife both have DXCC/VUCC but only applied with enough cards at the time for those. By now, these logs hold a lot of work, and we're eager to see what confirmations await in LoTW.

They kept things in different logbooks. We're focusing on the 6-meter logs currently, and have all of those entered into DXK! Also, the LoTW certificate and postcard have arrived. I've provisioned a separate notebook computer for his station, and I'm acting as his QSL manager. They live off-grid with solar power, limited cell phone, etc... So it's on me. ;)

I'm anxious to continue and upload the log to LoTW, but that could be a very bad idea. I'll bet that Dave has a walkthrough in the wiki for this?

+ Serving as a QSL Manager by using DXKeeper on a separate computer is no different than the way you use DXKeeper yourself.

My surmise is that a log validation needs to be done, to ensure all logged items are valid and congruous.

+ DXKeeper prevents you from logging a QSO with a serious error or omission.

For instance, a recompute operation complains about a number of issues with a missing band or such.

+ The Recompute function identifies errors that are not considered fatal. See

https://www.dxlabsuite.com/dxkeeper/Help/LogIntegrity.htm

+ My general advice is to correct any errors as you create them. So after spending an evening using the Main window to enter already-completed QSOs from a paper logbook, click the Broke button in the Filter panel at the bottom of the Main window's "Log QSOs" tab and correct whatever errors it displays.


Oh! So... Those we transcribed were one batch that's in the current DXK log. Another was transcribed by another fellow some years ago with unknown methods and I imported that ADIF. Those may be the only ones that have those issues because DXK wouldn't allow such to be entered. Right?

+ DXKeeper won't stop you from logging a QSO with a Russian station that specifies an invalid Oblast. It will stop you from logging a QSO with a Russian station that specifies an invalid date.


So, I think my first step is to separate the log into 6M contacts and export those. And then export the rest into another file. Then import the 6M file, and focus solely on those. Is that a good plan? See? I've already messed up, but this is reverseable. LoTW can be updated, but only to a degree.

+ After you enter a batch of new QSOs from a paper logbook and correct any errors reported by the Broke filter, there is no reason to not submit them to LoTW/eQSL/ClubLog.

A very important concern here is that station information from 20yrs can change. Grid squares are important for 6M of course, though his focus is on DXCC. I have my own DXK "Handling of LoTW QSL detail inconsistencies" to overwrite. I figure it's what they've logged ultimately that matters, they know where they were at the time. Is that right?

+ By "they know where they were at the time", does "they" refer to QSO partners? If so, I'd say that while they always know where they are, whether they conveyed and accurate grid square, and whether the conveyed grid square was accurate logged is less than 100% certain.


So, I figure that if I set that for his log,

+ To what does the word "that" refer?

and upload QSOs to LoTW, then Update QSLs from LoTW, would make the most sense overall?

I think the idea will be to do small batches at a time, to gauge the results. Regardless of confidence in the strategy. To limit the impact of unforeseen behavior. But this may be a lot more straightforward than I imagine. I really don't want to flummox LoTW with multiple QSOs logged trying to 'get it right'.

+ If you run the Broke filter before submitting each newly-entered batch of QSOs to LoTW, there shouldn't be much if any subsequent error correction required.

+ Before you proceed any further, decide how you want the "Subdivision validity checking" option set in the "Other Awards" panel on the Configuration window's Awards tab:

https://www.dxlabsuite.com/dxkeeper/Help/Configuration.htm#Subdivisions%20box

73,

Dave, AA6YQ


Re: Pathfinder and 425DxNews

Dave AA6YQ
 

+ AA6YQ comments below

I'm the maintainer of 425dxn.org <http://425dxn.org/> and I'm a DxLab Suite user.
I see Pathfinder cannot get response from www.425dxn.org <http://www.425dxn.org/> because we've passed on https protocol.
I've also implemented a "special call leaderboard" list based on 425Dx News Calendar and active at download moment.

For other issues about interfacing 425DxNews and DxLab... here I am.

+ thanks, Leo. Previously, Pathfinder would search 425DXN for QSL information about 8P9RY with the URL

http://www.iz5fsa.net/425dxn/?op=wsearch&query=8P9RY

+ but this URL no longer works. Changing this URL to

https://www.425dxn.org/index.php?op=wsearch&query=8p9ry&limit=1

+ makes it work. You can try this yourself by editing the 425DXN.txt file in Pathfinder's Searches folder to specify the URL as

https://www.425dxn.org/index.php?op=wsearch&query={targetcallsign}&limit=1

+ Save the change, restart Pathfinder, and see if it works to your satisfaction. If so, let me know and I'll distribute an updated 425DXN.txt to the DXLab user community.

73,

Dave, AA6YQ


Re: 20yr log transcription and LoTW

w6de
 

There are several how-to-do-it articles in the DXLab Wiki that might help.

There is a semi-automated process that can identify apparent errors, sorting the errors may take manual intervention.  It can take a while to get all the issues sorted out as you have to make decisions on each and every error.  One of the most important things is to set the award objectives before running these tools.

The entire process is described here:

http://www.dxlabsuite.com/dxlabwiki/AwardTracking

This is a rather exhaustive list of things to setup and check settings on in order to proceed to the next article.

 

The first pass and manual tracking is described here:

http://www.dxlabsuite.com/dxlabwiki/AnalyzeDXCCCredits

 

After using the manual process for a bit, you get some confidence in how the process works and you can try the Automated Linking next:

http://www.dxlabsuite.com/dxlabwiki/AutoLinkDXCCCredits

 

It took me several sittings over several days to get my initial logs sorted out multiple years ago.  As I have doubled the size of my log since 2011, I periodically re-run Analyze DXCC Credits and I’m always surprised to find a few errors some are mine, some are ARRL’s, and some are my QSO partner’s errors.

 

73,

Dave, w6de

 

 

From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Jon Gefaell via groups.io
Sent: Tuesday, June 08, 2021 20:43
To: DXLab@groups.io
Subject: [DXLab] 20yr log transcription and LoTW

 

I mentioned earlier that I was doing a project to get my buddy's logs of 20yrs from paper to digital form. He and his wife both have DXCC/VUCC but only applied with enough cards at the time for those. By now, these logs hold a lot of work, and we're eager to see what confirmations await in LoTW.

They kept things in different logbooks. We're focusing on the 6-meter logs currently, and have all of those entered into DXK! Also, the LoTW certificate and postcard have arrived. I've provisioned a separate notebook computer for his station, and I'm acting as his QSL manager. They live off-grid with solar power, limited cell phone, etc... So it's on me. ;) 

I'm anxious to continue and upload the log to LoTW, but that could be a very bad idea. I'll bet that Dave has a walkthrough in the wiki for this? My surmise is that a log validation needs to be done, to ensure all logged items are valid and congruous. For instance, a recompute operation complains about a number of issues with a missing band or such.

Oh! So... Those we transcribed were one batch that's in the current DXK log. Another was transcribed by another fellow some years ago with unknown methods and I imported that ADIF. Those may be the only ones that have those issues because DXK wouldn't allow such to be entered. Right?

So, I think my first step is to separate the log into 6M contacts and export those. And then export the rest into another file. Then import the 6M file, and focus solely on those. Is that a good plan? See? I've already messed up, but this is reverseable. LoTW can be updated, but only to a degree.

A very important concern here is that station information from 20yrs can change. Grid squares are important for 6M of course, though his focus is on DXCC. I have my own DXK "Handling of LoTW QSL detail inconsistencies" to overwrite. I figure it's what they've logged ultimately that matters, they know where they were at the time. Is that right?

So, I figure that if I set that for his log, and upload QSOs to LoTW, then Update QSLs from LoTW, would make the most sense overall?

I think the idea will be to do small batches at a time, to gauge the results. Regardless of confidence in the strategy. To limit the impact of unforeseen behavior. But this may be a lot more straightforward than I imagine. I really don't want to flummox LoTW with multiple QSOs logged trying to 'get it right'.

 

Thank you very, very much. Sorry this is so rambling. Would be much easier to describe conversationally. :)

Jay is anxious for us to proceed, but I just don't want to screw the pooch here.


Re: LOTW QSLing with callsign changes

Dave AA6YQ
 

+ AA6YQ comments below
Thanks, Dave!  I'll give it a try.  Still a newbie with DxLab

+ The first section of 

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

+ describes the available documentation resources.

+ All questions are welcome here, no matter how many times they've already been asked and answered, or how obvious the answers might be in documentation.

       73,

              Dave, AA6YQ

 

 


20yr log transcription and LoTW

Jon Gefaell
 

I mentioned earlier that I was doing a project to get my buddy's logs of 20yrs from paper to digital form. He and his wife both have DXCC/VUCC but only applied with enough cards at the time for those. By now, these logs hold a lot of work, and we're eager to see what confirmations await in LoTW.

They kept things in different logbooks. We're focusing on the 6-meter logs currently, and have all of those entered into DXK! Also, the LoTW certificate and postcard have arrived. I've provisioned a separate notebook computer for his station, and I'm acting as his QSL manager. They live off-grid with solar power, limited cell phone, etc... So it's on me. ;) 

I'm anxious to continue and upload the log to LoTW, but that could be a very bad idea. I'll bet that Dave has a walkthrough in the wiki for this? My surmise is that a log validation needs to be done, to ensure all logged items are valid and congruous. For instance, a recompute operation complains about a number of issues with a missing band or such.

Oh! So... Those we transcribed were one batch that's in the current DXK log. Another was transcribed by another fellow some years ago with unknown methods and I imported that ADIF. Those may be the only ones that have those issues because DXK wouldn't allow such to be entered. Right?

So, I think my first step is to separate the log into 6M contacts and export those. And then export the rest into another file. Then import the 6M file, and focus solely on those. Is that a good plan? See? I've already messed up, but this is reverseable. LoTW can be updated, but only to a degree.

A very important concern here is that station information from 20yrs can change. Grid squares are important for 6M of course, though his focus is on DXCC. I have my own DXK "Handling of LoTW QSL detail inconsistencies" to overwrite. I figure it's what they've logged ultimately that matters, they know where they were at the time. Is that right?

So, I figure that if I set that for his log, and upload QSOs to LoTW, then Update QSLs from LoTW, would make the most sense overall?

I think the idea will be to do small batches at a time, to gauge the results. Regardless of confidence in the strategy. To limit the impact of unforeseen behavior. But this may be a lot more straightforward than I imagine. I really don't want to flummox LoTW with multiple QSOs logged trying to 'get it right'.

 

Thank you very, very much. Sorry this is so rambling. Would be much easier to describe conversationally. :)

Jay is anxious for us to proceed, but I just don't want to screw the pooch here.


Re: LOTW QSLing with callsign changes

dwfred@bellsouth.net
 

Thanks, Dave!  I'll give it a try.  Still a newbie with DxLab.
73,

Dean W8ZF


Re: LOTW QSLing with callsign changes

Dave AA6YQ
 

+ AA6YQ comments below
I tried searching this on the forum, but it seems different enough that most of the information doesn't apply.
+ See "Handling Multiple Callsigns and Operating Locations with LoTW" in

https://www.dxlabsuite.com/dxlabwiki/LotWMultipleCallsignsLocations

I had CALL#1, changed to CALL#2, and then went back to CALL#1.

I noticed several QSOs that were not being confirmed in LOTW.  After digging, I realized that these were made at a time when I held CALL#2 (but they are in the same log).  They were probably not being confirmed because the logged callsign was not my CALL#1. 

  • I have already uploaded all my log to LOTW using CALL#1.
  • I have just today applied for, and received a tQSL certificate for CALL#2.
  • I have changed DXKeeper's STATION_CALLSIGN for all of the QSOs made under CALL#2.
How do I apply for LOTW confirmation of those QSOs made with CALL#2, but were already submitted as CALL#1 as the STATION_CALLSIGN?
+ Resubmit those QSOs to LoTW with your "Callsign Certificate" for Callsign #2 with the correct "Station Location".

     73,

             Dave, AA6YQ


LOTW QSLing with callsign changes

dwfred@bellsouth.net
 

I tried searching this on the forum, but it seems different enough that most of the information doesn't apply.

I had CALL#1, changed to CALL#2, and then went back to CALL#1.

I noticed several QSOs that were not being confirmed in LOTW.  After digging, I realized that these were made at a time when I held CALL#2 (but they are in the same log).  They were probably not being confirmed because the logged callsign was not my CALL#1. 

  • I have already uploaded all my log to LOTW using CALL#1.
  • I have just today applied for, and received a tQSL certificate for CALL#2.
  • I have changed DXKeeper's STATION_CALLSIGN for all of the QSOs made under CALL#2.
How do I apply for LOTW confirmation of those QSOs made with CALL#2, but were already submitted as CALL#1 as the STATION_CALLSIGN?

A little difficult to follow, I know.  Thanks for reading this far, and for any help you can provide.

Dean W8ZF


Pathfinder and 425DxNews

IZ5FSA Leo
 

Hi OM.
I'm the maintainer of 425dxn.org and I'm a DxLab Suite user.
I see Pathfinder cannot get response from www.425dxn.org because we've passed on https protocol.
I've also implemented a "special call leaderboard" list based on 425Dx News Calendar and active at download moment.

For other issues about interfacing 425DxNews and DxLab... here I am.

Best 73s de Leo IZ5FSA


--
--
73 de Leo IZ5FSA


SpotCollector 8.8.8 is available

Dave AA6YQ
 

If you are using Windows Defender anti-malware, direct it to update its definitions from

https://www.microsoft.com/en-us/wdsi/definitions

before you install SpotCollector 8.8.8.


This release

- ignores erroneous NPOTA, POTA, SOTA, and WWFF designators in spot notes (tnx to Björn SM7IUN and Bruce K5WBM)

- when WSJT-X reports a station R decoding a station C with SNR S, the Spot Database entry created for C specifies R as the spotting
station, not the user's callsign

- correctly interoperates with an instance of WSJT-X running on a computer whose locale uses network segment separators other than
the period character (tnx to Thomas DF2LH)

- updates the CollectingSpots.htm, ConfigurationNotifications.htm, DXClusterInteraction.htm, and SourceConnection.htm documentation
files


Notes:

1. Update your firewall and anti-malware applications to consider the new versions of SpotCollector.exe and SC_WSJTX.exe to be
"safe"

a. 0/15 Jotti scanners detected malware in SpotCollector.exe

b. 0/69 VirusTotal scanners detected malware in SpotCollector.exe

c. 0/15 Jotti scanners detected malware in SC_WSJTX.exe

d. 2/69 VirusTotal scanners detected malware in SC_WSJTX.exe

e. SpotCollector.exe and SC_WSJTX.exe have been submitted to "Microsoft Security Intelligence" and found free of malware.

2. If this upgrade doesn't work correctly, see the "After an Upgrade" section of

http://www.dxlabsuite.com/dxlabwiki/ApplicationStoppedWorking

3. After upgrading, to revert to the previous version of SpotCollector, see

http://www.dxlabsuite.com/dxlabwiki/RevertApplicationVersion

4. This version provides an updated Sub-band Definition file:

BandModes 2021-04-20

with a single CW entry for the new 5m band and a single CW entry for the new 8m band. You can define a custom Sub-band Definition
file that is consistent with 5m and 8m usage in your area, as described in

https://www.dxlabsuite.com/dxlabwiki/SubbandDefinitions



SpotCollector 8.8.8 is available via the DXLab Launcher, and via

http://www.dxlabsuite.com/download.htm


73,

Dave, AA6YQ


Re: Sorting By Dates Change Power

Dave AA6YQ
 

+ AA6YQ comments below
  • specify the new value of the item in the Item new value box
  • click the Mod button to update that item with the specified new value in all QSOs in the Log Page Display

+ The controls mentioned above are present in the "Modify QSOs" panel at the bottom of the "Advanced Sorts, Filters, and Modifiers"  window.

     73,

           Dave, AA6YQ


Re: Sorting By Dates Change Power

rcktscientist64
 

Jim,

It's on the bottom of the DXKeeper Advanced Sorts, Filters, & Modifiers page.  Make sure you backup your log before modifying the QSO's in case things don't work as planned.


On Mon, Jun 7, 2021 at 4:43 PM Jim K9TF <jim.gmforum@...> wrote:
Hi Bruce, thank you
Not seeing where these are:
  1. specify the new value of the item in the Item new value box

  2. click the Mod button to update that item with the specified new value in all QSOs in the Log Page Display

I do have the power category highlighted in blue no other options.

Jim K9TF



--
Bruce
K5WBM


Re: Sorting By Dates Change Power

Jim K9TF <jim.gmforum@...>
 

I was able to sort the dates. Adv commands gave me a problem but finally got it to work.

 

I highlighted the power column all in blue but did not see the following:

 

  1. specify the new value of the item in the Item new value box
  2. click the Mod button to update that item with the specified new value in all QSOs in the Log Page Display

 

Be Well--

Jim K9TF


Re: Sorting By Dates Change Power

Jim K9TF <jim.gmforum@...>
 

Hi Bruce, thank you
Not seeing where these are:
  1. specify the new value of the item in the Item new value box

  2. click the Mod button to update that item with the specified new value in all QSOs in the Log Page Display

I do have the power category highlighted in blue no other options.

Jim K9TF


Re: ascending or descending? SC/DXK

Dave AA6YQ
 

Not an issue, but a query.

I sort both DXK and SC so the most recent entries are added to the bottom of the stack, and older entries scroll off the top. The thing is, I have absolutely no idea right now why. I sort DXK by UTC, and SC by "Last", I know why I do that, but there may be other ideas to consider.

I'd be more than interested in learning what, and more importantly why you might be doing it one way or the other?

+ It's entirely personal preference.

+ In the good old days, DX spots were displayed in text windows as they arrived from VHF packet radios, with each new spot appended beneath the one before it. So when I first implemented SpotCollector, the Spot Data Display showed new or just-updated Entries at the bottom. The logging application I briefly used before developing DXKeeper (LOGic) displayed the most recent QSOs at the bottom, so I designed DXKeeper to work that way without even thinking about it.

+ Later, users coming to DXLab from other applications that worked differently asked for the options to replicate that behavior, so I added "Sort Order" panels to the Configuration windows of both SpotCollector and DXKeeper.

73,

Dave, AA6YQ

2801 - 2820 of 204584