LOTW Unmatched

[PY2AD]

I need some help...

I have a database containing various callsigns (old ones, past contest callsigns, current contest callsigns, and current standard callsigns).
They are all in the database, and I have each one defined in a specific profile.

Example: Profile PY2AD, with Operator PY2AD and Station PY2AD
Profile PV2D, with Operator PV2D and Station PV2D
And so on.

When I download data from LoTW—even when using retroactive dates—I get many "UNMATCHED" entries for each callsign. I’ve already checked most of them against the LoTW website, and there are no discrepancies.

Does anyone know what causes this, or is there a way to create a file containing only the "UNMATCHED" entries so I can review and potentially correct them?

[aa5sh]

How the LoTW QSL Download works Selecting “My Callsign” The callsign list is built from the Station Callsign values found in your logbook. Only one callsign is requested from LoTW at a time. If you have operated as several callsigns—such as a home call, former call, portable call, or special-event call—you should repeat the download separately for each callsign. Selecting a callsign limits what LoTW sends back. It does not filter the local matching process by your station callsign, which has an important consequence described below. Choosing the date option “QSLs Since” asks LoTW for confirmations received since the selected date. This is normally the best choice for routine updates because it can find a recently received confirmation for a much older QSO. “QSOs Since” asks LoTW for QSOs added to your LoTW account since the selected date. This is more useful when rebuilding or checking a recent upload, but it can miss a new confirmation for an older QSO. For an initial import, select an appropriately old date and process each of your callsigns. Later downloads can normally use “QSLs Since” with a recent date. Downloading overlapping dates is safe; an already processed confirmation is normally recognized rather than duplicated. How QLog matches a downloaded confirmation For every record returned by LoTW, QLog looks in the existing logbook for a QSO with: The same contacted station’s callsign The same band A start time less than 30 minutes apart The same satellite name, including both records having no satellite (if applicable) A compatible mode Callsign, band, and mode comparisons are not case-sensitive. Mode matching QLog first looks for the exact mode. For example, FT8 matches FT8 directly. If that does not produce exactly one result, QLog tries the broader LoTW/DXCC mode group: CW Phone Digital/Data This allows related mode descriptions to match when LoTW considers them equivalent. For example, a downloaded generic DATA confirmation may match a locally logged digital mode. The submode is not separately required during matching. Exactly one match is required QLog updates a QSO only when the search produces exactly one local record. No matching record: reported as Unmatched. Two or more possible records: also reported as Unmatched. Exactly one record: that QSO can be updated. This cautious rule prevents QLog from guessing between duplicate or very similar QSOs. Important point for multiple callsigns Although the selected “My Callsign” controls which records LoTW returns, the current local match does not include your Station Callsign or Operator field. For example, suppose your log contains nearly identical contacts with W1ABC under both K1AAA and K1BBB: If both contacts satisfy the match rules, QLog finds more than one candidate and reports the LoTW record as Unmatched. If only the QSO under the wrong station callsign satisfies the other rules, QLog can update that record because it does not verify the local station callsign. The safest practice for a large multi-callsign log is: Make sure every QSO has the correct Station Callsign. Download each callsign separately. Review unmatched records carefully. Check suspicious confirmations where the same station was worked on the same band and mode within 30 minutes under different callsigns. What QLog updates after a successful match When LoTW reports the QSO as confirmed, QLog can update: LoTW received status LoTW confirmation date Electronic QSL-received method DXCC credit submitted/granted information Prefix and IOTA State and county CQ and ITU zones Grid square and VUCC grids Distance, when a usable local and remote grid are available A newly received confirmation is listed as a New QSL. An already-confirmed QSO that receives additional or improved information is listed as an Updated QSO. QLog does not create another QSO when it processes the same confirmation again. Understanding the summary Downloaded is the number of records returned by LoTW and read by QLog. It does not mean that every record changed the logbook. Updated is the combined number of: Newly confirmed QSOs Existing QSOs whose information was changed or completed Unmatched means QLog found either no candidate or more than one candidate. The summary does not distinguish between those two situations. Errors normally means a downloaded record was missing or contained an invalid required matching value: QSO date/time Contacted callsign Band Mode Some downloaded records may appear only in Downloaded and not in the other totals. This generally means the record matched, but the QSO was already confirmed and no information needed changing. Download-level failures The complete LoTW operation can fail before matching begins because of: Incorrect LoTW username or password No network connection LoTW being unavailable An HTTP/server error Failure to create the temporary processing file Cancellation by the user These produce a separate “LoTW update failed” message rather than ordinary unmatched records.

…

On Jun 24, 2026, at 9:28 PM, PY2AD ***@***.***> wrote: I need some help... I have a database containing various callsigns (old ones, past contest callsigns, current contest callsigns, and current standard callsigns). They are all in the database, and I have each one defined in a specific profile. Example: Profile PY2AD, with Operator PY2AD and Station PY2AD Profile PV2D, with Operator PV2D and Station PV2D And so on. When I download data from LoTW—even when using retroactive dates—I get many "UNMATCHED" entries for each callsign. I’ve already checked most of them against the LoTW website, and there are no discrepancies. Does anyone know what causes this, or is there a way to create a file containing only the "UNMATCHED" entries so I can review and potentially correct them? — Reply to this email directly, view it on GitHub <#1082?email_source=notifications&email_token=AUEEMXQX72VS6H653M6UUVT5BSE3XA5CNFSNUABBM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63RPGEYDGMJWGI3DDJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUEEMXSLMAIULRFTJ6FH3335BSE3XAVCNFSNUABIKJSXA33TNF2G64TZHMZTQNZUG4ZDCMJXHNCGS43DOVZXG2LPNY5TCMBTGE3DENRRUF3AE>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AUEEMXX67XQUKZLWVESNTK35BSE3XA5CNFSNUABBM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63RPGEYDGMJWGI3DDJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/AUEEMXV5EUCUN3R2T7AEXV35BSE3XA5CNFSNUABBM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63RPGEYDGMJWGI3DDJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you are subscribed to this thread.

[PY2AD]

Thanks a lot for the explanation, but I think my case involves an additional factor.

I have examples like this:

PV2D with 134 unmatched entries.
It doesn't qualify as a duplicate—even though a second callsign was used—because PV2D is a contest callsign.

I’ve already compared the log against the LoTW site and the information matches perfectly, yet it still won't confirm.

Another example:

I have 3V8LL confirmed on LoTW with both PR2AD and PY2AD; I understand the rule that it only confirms one. However, even when I manually change LOTW_RCVD to 'Y', it still shows up as unmatched.

Is there a debug command line I can use to list only the unmatched entries and check for potential errors, or to perform manual confirmations? As I mentioned, I’ve already verified on the LoTW site that these unmatched entries are actually confirmed.

[aa5sh]

I put in a put request proposal for the next version to add an ‘All Callsigns’ option so you wouldn’t have to perform the action a couple of times. But I don’t think that would resolve the unmatched question you have. For your example with 3V8LL it’s hard for me to say for sure without more context. Show me the details from LoTW for the QSO and then also the details for the QSOs in QLog? Did you contact him for instance from both callsigns within 30 minutes? Or have duplicate entries in the log within the 30mins?

…

On Jun 25, 2026, at 9:47 AM, PY2AD ***@***.***> wrote: Thanks a lot for the explanation, but I think my case involves an additional factor. I have examples like this: PV2D with 134 unmatched entries. It doesn't qualify as a duplicate—even though a second callsign was used—because PV2D is a contest callsign. I’ve already compared the log against the LoTW site and the information matches perfectly, yet it still won't confirm. Another example: I have 3V8LL confirmed on LoTW with both PR2AD and PY2AD; I understand the rule that it only confirms one. However, even when I manually change LOTW_RCVD to 'Y', it still shows up as unmatched. Is there a debug command line I can use to list only the unmatched entries and check for potential errors, or to perform manual confirmations? As I mentioned, I’ve already verified on the LoTW site that these unmatched entries are actually confirmed. — Reply to this email directly, view it on GitHub <#1082?email_source=notifications&email_token=AUEEMXUUCVWZFXNID3QRWBL5BU3ORA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZUGM2TINJTUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17435453>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUEEMXQMUWCY2HX6CCLZ62T5BU3ORAVCNFSNUABIKJSXA33TNF2G64TZHMZTQNZUG4ZDCMJXHNCGS43DOVZXG2LPNY5TCMBTGE3DENRRUF3AE>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AUEEMXWZ25AIYLJYXQWG3Z35BU3ORA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZUGM2TINJTUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/AUEEMXRBHZMLQDUY6QIOU4D5BU3ORA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZUGM2TINJTUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you commented.

[PY2AD]

In the 3V8LL case, yes, there are indeed two contacts within less than two minutes using two different callsigns. I understand the 30-minute LoTW rule—that makes perfect sense—but why does the "unmatched" notification keep coming up? Every time I download data from an earlier date, that message appears. Is this normal behavior? Can't the system simply ignore it after the initial read?

As for the others, I would need to run some debugging to get more information.

[aa5sh]

If you run from an older date QLog tries to reprocess the file again so that is why the repeated message. But I do think we may can make a change to help with the 3v8LL situation. I added to my other PR validation for matching the ’Station Callsign’ field between LoTW and your Log QSO Detail. So in this situation I would think it would update those appropriately.

…

On Jun 29, 2026, at 9:36 AM, PY2AD ***@***.***> wrote: In the 3V8LL case, yes, there are indeed two contacts within less than two minutes using two different callsigns. I understand the 30-minute LoTW rule—that makes perfect sense—but why does the "unmatched" notification keep coming up? Every time I download data from an earlier date, that message appears. Is this normal behavior? Can't the system simply ignore it after the initial read? As for the others, I would need to run some debugging to get more information. — Reply to this email directly, view it on GitHub <#1082?email_source=notifications&email_token=AUEEMXX4IJLL35IQB6I62IT5CJ5HZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZUG4ZDOMZYUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17472738>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUEEMXQDM77K4LOKUVYDHO35CJ5HZAVCNFSNUABIKJSXA33TNF2G64TZHMZTQNZUG4ZDCMJXHNCGS43DOVZXG2LPNY5TCMBTGE3DENRRUF3AE>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AUEEMXWNGNFRIX6K4JGQ75T5CJ5HZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZUG4ZDOMZYUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/AUEEMXU46LQKZVN3UGOJFRD5CJ5HZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZUG4ZDOMZYUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you commented.

[PY2AD]

Good call; that’s probably the best option in this case. Sometimes we close the same contact with two different leads, and it ends up showing up as a duplicate when it actually isn't one.