harvesting information from duplicate QSOs


Dave AA6YQ
 

I have a new version of DXKeeper that can

- when you invoke the "Duplicates Filter" provided on the "Advanced Sorts, Filters, and Modifiers" window, optionally populate empty
items in a QSO to be retained with information harvested from one or more duplicates of that QSO

- when importing QSOs from a file with duplicate checking enabled, optionally populate empty items in a logged QSO with information
harvested from a duplicate QSO present in that file

Does anyone have a "real world scenario" in which either form of the above new functionality could be tested?

73,

Dave, AA6YQ


Mike - W1MI
 

I recently worked a 1x1 special event station on many bands and modes.  QRZ.com had outdated information, and it would have been
helpful to populate each new QSO with the info from a previous one.  Could this "Duplicates Filter" be extended to work with QSOs
coming in through the N1MM/DXKeeper bridge?

73, Mike - W1MI


On Sun, Jul 18, 2021 at 04:56 AM, Dave AA6YQ wrote:
I have a new version of DXKeeper that can

- when you invoke the "Duplicates Filter" provided on the "Advanced Sorts, Filters, and Modifiers" window, optionally populate empty
items in a QSO to be retained with information harvested from one or more duplicates of that QSO

- when importing QSOs from a file with duplicate checking enabled, optionally populate empty items in a logged QSO with information
harvested from a duplicate QSO present in that file

Does anyone have a "real world scenario" in which either form of the above new functionality could be tested?

73,

Dave, AA6YQ


Dave AA6YQ
 

+ AA6YQ comments below

I recently worked a 1x1 special event station on many bands and modes. QRZ.com had outdated information, and it would have been helpful to populate each new QSO with the info from a previous one. Could this "Duplicates Filter" be extended to work with QSOs coming in through the N1MM/DXKeeper bridge?

+ No, that would require a separate project. Also, there is no way for a DXLab application to know whether the information provided by a callbook lookup is accurate or outdated.

73,

Dave, AA6YQ


Mike - W1MI
 

+ No, that would require a separate project. Also, there is no way for a DXLab application to know whether the information provided by a callbook lookup is accurate or outdated.

OK, but after the Qs are in DXKeeper, this filter could be used?

Does "duplicates" (in your original message) mean QSOs with the same call, but not necessarily the same date, mode, band?

Thanks, Mike - W1MI


Dave AA6YQ
 

+ No, that would require a separate project. Also, there is no way for a DXLab application to know whether the information provided by a callbook lookup is accurate or outdated.

OK, but after the Qs are in DXKeeper, this filter could be used?

+ Only if the QSOs were duplicates.

Does "duplicates" (in your original message) mean QSOs with the same call, but not necessarily the same date, mode, band?

+ Same callsign, same band, same mode, same date-and-time within the range specified in the Range box in the Duplicates panel on the "Advanced Sorts, Filters, and Modifiers" window. See

https://www.dxlabsuite.com/dxkeeper/Help/FilterLog.htm#Duplicate%20filter

+ When you're logging new a new QSO with callsign C from DXKeeper or WinWarbler, you can arrange for previous QSOs C to be displayed in DXKeeper's Log Page Display, and for the following information to be harvested from those previous and included in the new QSO if not already specified: DXCC entity, name, QSL via, QTH, Grid 1, IOTA, QSL address, Primary Administrative Subdivision, Secondary Administrative Subdivision, ITU, CQ, continent, eQSL.cc member and LotW member. See, for example

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

73,

Dave, AA6YQ


Mike - W1MI
 

Thanks for the explanation Dave.  Now that I understand it, no I don't have a '"real world scenario" in which either form of the above new functionality could be tested'.
73, Mike - W1MI


On Sun, Jul 18, 2021 at 08:46 PM, Dave AA6YQ wrote:
+ No, that would require a separate project. Also, there is no way for a DXLab application to know whether the information provided by a callbook lookup is accurate or outdated.

OK, but after the Qs are in DXKeeper, this filter could be used?

+ Only if the QSOs were duplicates.

Does "duplicates" (in your original message) mean QSOs with the same call, but not necessarily the same date, mode, band?

+ Same callsign, same band, same mode, same date-and-time within the range specified in the Range box in the Duplicates panel on the "Advanced Sorts, Filters, and Modifiers" window. See

https://www.dxlabsuite.com/dxkeeper/Help/FilterLog.htm#Duplicate%20filter

+ When you're logging new a new QSO with callsign C from DXKeeper or WinWarbler, you can arrange for previous QSOs C to be displayed in DXKeeper's Log Page Display, and for the following information to be harvested from those previous and included in the new QSO if not already specified: DXCC entity, name, QSL via, QTH, Grid 1, IOTA, QSL address, Primary Administrative Subdivision, Secondary Administrative Subdivision, ITU, CQ, continent, eQSL.cc member and LotW member. See, for example

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

73,

Dave, AA6YQ