ad: elecraft

Mismatching DXCC country numbers

Discussion in 'Logbook User Forum' started by KE3FG, Jan 26, 2015.

Thread Status:
Not open for further replies.
ad: L-HROutlet
ad: l-rl
ad: Left-2
ad: Subscribe
ad: Left-3
ad: L-MFJ
ad: FBNews-1
  1. KE3FG

    KE3FG XML Subscriber QRZ Page

    Nine of my QSOs with Germany are called "not eligible" for DXWA award. It says that the DXCC number that I submitted does not match what the other party submitted. When I submit an ADIF file, I never include a DXCC number for the QSO. If there is a mismatch, it is the fault of the log program (V1) that generated the wrong DXCC number for a particular ham. Please look into fixing this bug, Alex.
    QRZ_DXCC_error.jpg
     
  2. W1DQ

    W1DQ Logbook Administrator Volunteer Moderator Volunteer DX Helper Platinum Subscriber QRZ Page

    The DXCC number that was filled in to your records is the correct DXCC number. Your worked party has the incorrect number in its QSO record.

    Inasmuch as your ADIF file has no DXCC data, and had QRZ left it blank, both your and your worked party's entry would have also been incorrect. There is no bug to fix, only the mismatch needs correcting. For help, click on "HELP How do I fix this?"
     
    Last edited: Jan 27, 2015
  3. KE3FG

    KE3FG XML Subscriber QRZ Page

    "Your worked party has entered the incorrect number in its QSO record."
    Seven different Germans entered the wrong DXCC number for their country? I seriously doubt that.
    Blaming this problem on the hams won't fix this problem.
    I have never seen that the DXCC number is a requirement for the QSO in an ADIF file, and eQSL and LOTW never complained that I didn't provide a DXCC number for any QSO that I submitted.
     
    Last edited: Jan 27, 2015
  4. KE3FG

    KE3FG XML Subscriber QRZ Page

    I should have added that eQSL & LOTW don't require the DXCC number as part of the ADIF data because the country information is contained in the callsign prefix, so there is no need for the country name or DXCC number in the submitted ADIF file.
     
  5. N0AMT

    N0AMT Ham Member QRZ Page

    Unsure how it happened, whether leftover from V1, or the previous lack of Deleted DXCC Support, I have corrected this.

    It should be noted that this is no longer possible. We've added Deleted DXCC support, which checks incoming QSO records to ensure that the DXCC entity selected fits within that DXCC's active date range. We also updated the existing records in the database to correct them, but apparently, these slipped through the cracks in some way that makes little sense to me.

    Corrected now.

    DXCC Number is not required in an ADIF import, but it is supported. When a DXCC number exists, we try to use it. If it doesn't exist, and COUNTRY does, we use that. If neither exists, we use the Logbook's details for the callsign and date range. If none exists, we use the callsign record. If none exists, we populate based off of prefix.
     
  6. KE3FG

    KE3FG XML Subscriber QRZ Page

    Thank you for taking care of the problem, Alex.
     
  7. KE3FG

    KE3FG XML Subscriber QRZ Page

    Alex, since all the country information including the DXCC number is defined by the callsign prefix, there is no need to use the country name or DXCC number that the ADIF file may contain. The "error" as shown in the OP wouldn't even exist if the logbook determined the DXCC number from the callsign prefix.
    As of today, the problem shown in the OP still exists.
     
  8. N0AMT

    N0AMT Ham Member QRZ Page

    I am looking at your DX World Analysis right now and I do not see any errors, so I'm not sure what problem still exists?
     
  9. N0AMT

    N0AMT Ham Member QRZ Page

    We've analyzed many of the ADIFs that have been sent to us.

    Frequently people do not use the slashed prefix when operating outside their DXCC entity.

    In other words, if I were in Mexico, I might be:
    XE2/N0AMT

    in which case you're correct.

    In surprisingly MANY MANY cases, we've seen something more like

    N0AMT for the callsign, with country as Mexico.

    Therefore, prefix would be wrong.


    We obviously can't handle every single possible case correctly, but we do the best we can to catch as MANY cases as possible.

    Right now, our system works well. (The recently fixed errors with deleted DXCCs that remained from V1, aside)

    If you do not include country or DXCC number, we'll populate it through a number of means. If all of those fail, well.. Garbage In, Garbage Out. There's only so much we can do.
     
  10. KE3FG

    KE3FG XML Subscriber QRZ Page

    You must have fixed the problem described in the OP this afternoon, because this morning it appeared the same as in the OP. Now this evening it doesn't have any errors.
    If I have a QSO with WA6MHZ and report in the ADIF file that his country is France and his DXCC number is 227, would you call it a French contact?
    I think for it to count as a French contact, it should have a prefix like 'F2/' otherwise it is an American contact.
    An error like DXCC mismatch should not exist at all if the logbook relies on the callsign prefix to derive the country.
     
Thread Status:
Not open for further replies.

Share This Page