1. Topics
  2. Questions on import of ADIF from N1MM

Questions on import of ADIF from N1MM

Tom LeClerc
 

Good Morning!

As I was importing the CQ 160 CW ADIF file it reminded me of a observation I've seen in several contest imports:
  • A lot of administrative subdivisions and secondary administrative subdivisions (counties, etc) are imported that DXLabs knows to be incorrect (most likely because LOTW data that is set wrong).  Ideally LOTW would provide dropdowns and not allow that data to be entered wrong but that will probably never happen.  To save a LOT of work using the broke filter and fixing all those errors, can DXLabs not import incorrect data?  I know that the import would take longer BUT I'd rather have the system do that than for me to go back and remove the bad data after...
  • This is especially apparent when someone is a snowbird or has 2 or more locations.  County, zone, etc. is seldom fixed by the amateur for their stints away from home...
  • When using the CBA (callbook lookup feature) the system does not see to bring in the bad data.  It must be filtering for that when doing that function.  Like don't import a county with a state header that is different.
One last note, AMAZING program Dave.  Thanks so much for all the hard work you put into it...

73, Tom
--
  Tom LeClerc, Amateur Radio Station W1TJL
Contest Station for N1MM, W1TJL, and others
   (past calls WB1CBY, /VE8,XL8,CI8,VO2)
              email: w1tjl@...
Dave AA6YQ
 

+ AA6YQ comments below
A lot of administrative subdivisions and secondary administrative subdivisions (counties, etc) are imported that DXLabs knows to be incorrect (most likely because LOTW data that is set wrong).  Ideally LOTW would provide dropdowns and not allow that data to be entered wrong but that will probably never happen.  To save a LOT of work using the broke filter and fixing all those errors, can DXLabs not import incorrect data?  I know that the import would take longer BUT I'd rather have the system do that than for me to go back and remove the bad data after...

+ There is no way for DXKeeper to know that the imported data is incorrect. It can flag inconsistencies, but cannot resolve them.

+ You can do the following:

1. Clear the Select item in all logged QSOs

2. Configure DXKeeper to set the Select item to Y in each logged QSO

3. Filter the Log Page Display to show only QSOs whose Select items are set to 'Y'

4. Depress the CTRL and ALT keys while click the CBA button above the "Log Page Display" on the Main window's "Log QSOs" tab

Doing so will populate all location-based data in your imported QSOs from whichever callbook you have selected.

Alternatively, immediately after importing, you could filter the Log Page Display to display all imported QSOs flagged as Broken, and then invoke CTRL-ALT-CBA.

         73,

            Dave, AA6YQ
Rick Murphy
 

Tom,
What's the errors you're seeing? 
Logbook will "correct" simple errors that are easy to spot (like bad zones. my favorite story here is the Texas ham that loudly told the Logbook helpdesk that they were idiots because EVERYBODY knows that Texas is in zone 5..)

It's hard to upload QSOs with completely wrong data like that, because it's not allowed.  But it's not possible to  detect people using the wrong QTH data.  If you have cases where those inconsistencies could be discovered and prevented, I'd love to hear them.
73,
     -Rick

On Sun, Jan 29, 2023 at 10:37 PM Dave AA6YQ <aa6yq@...> wrote:
+ AA6YQ comments below
A lot of administrative subdivisions and secondary administrative subdivisions (counties, etc) are imported that DXLabs knows to be incorrect (most likely because LOTW data that is set wrong).  Ideally LOTW would provide dropdowns and not allow that data to be entered wrong but that will probably never happen.  To save a LOT of work using the broke filter and fixing all those errors, can DXLabs not import incorrect data?  I know that the import would take longer BUT I'd rather have the system do that than for me to go back and remove the bad data after...

+ There is no way for DXKeeper to know that the imported data is incorrect. It can flag inconsistencies, but cannot resolve them.

+ You can do the following:

1. Clear the Select item in all logged QSOs

2. Configure DXKeeper to set the Select item to Y in each logged QSO

3. Filter the Log Page Display to show only QSOs whose Select items are set to 'Y'

4. Depress the CTRL and ALT keys while click the CBA button above the "Log Page Display" on the Main window's "Log QSOs" tab

Doing so will populate all location-based data in your imported QSOs from whichever callbook you have selected.

Alternatively, immediately after importing, you could filter the Log Page Display to display all imported QSOs flagged as Broken, and then invoke CTRL-ALT-CBA.

         73,

            Dave, AA6YQ



--
Rick Murphy, D. Sc., CISSP-ISSAP, K1MU/4, Annandale VA USA
Larry K8UT
 

Tom

A suggestion when importing from an N1MM+ contest: In the DXKeeper >Import QSOs tab >Replacement Options box, check "Contest ID" and enter the N1MM contest name and the date (or just the year if it's an annual contest). There are benefits to having your general purpose logging program "know" your contest history and differentiating contests Qs from DXing Qs.

-larry (K8UT)


------ Original Message ------
From "Dave AA6YQ" <aa6yq@...>
Date 1/29/2023 22:37:33
Subject Re: [DXLab] Questions on import of ADIF from N1MM

+ AA6YQ comments below
A lot of administrative subdivisions and secondary administrative subdivisions (counties, etc) are imported that DXLabs knows to be incorrect (most likely because LOTW data that is set wrong).  Ideally LOTW would provide dropdowns and not allow that data to be entered wrong but that will probably never happen.  To save a LOT of work using the broke filter and fixing all those errors, can DXLabs not import incorrect data?  I know that the import would take longer BUT I'd rather have the system do that than for me to go back and remove the bad data after...

+ There is no way for DXKeeper to know that the imported data is incorrect. It can flag inconsistencies, but cannot resolve them.

+ You can do the following:

1. Clear the Select item in all logged QSOs

2. Configure DXKeeper to set the Select item to Y in each logged QSO

3. Filter the Log Page Display to show only QSOs whose Select items are set to 'Y'

4. Depress the CTRL and ALT keys while click the CBA button above the "Log Page Display" on the Main window's "Log QSOs" tab

Doing so will populate all location-based data in your imported QSOs from whichever callbook you have selected.

Alternatively, immediately after importing, you could filter the Log Page Display to display all imported QSOs flagged as Broken, and then invoke CTRL-ALT-CBA.

         73,

            Dave, AA6YQ
1 - 4 of 4