What means exactly "unmatched QSL" from LoTW?

[muihlinn]

I guess it's something non-coincident, but I've found at least one case - possibly more - where I cannot find a reason.

I do sync from LoTW and get this:

While looking at LoTW records I see this:

Which is confirmed, but unrecognized by QLog as confirmed.

The only thing in common between all those unmatched is being FT4 QSOs. I've had issues before with other software uploading FT4 twice, as MFSK and FT4, but LoTW only confirmed one of them. I'm just curious about what is going on here.

[foldynl]

The unmatched QSL field shows all QSOs that do not match your Log entry. Fields which have to match are: Callsign, mode, band, start time.

Unfortunately, what you see is a bug in QLog. You mentioned that all unmatched QSOs are FT4. I found out that QLog does not convert the mode FT4, that is received from WSJTX to the standardized ADIF forms MFSK/FT4. It does not affect the upload to LoTW, because TQSL does the conversion, but it affects other online services. This needs to be fixed.

I'll open an Issue report on it. It will be fixed in the next version - the internal database must also be fixed in the next release.

[muihlinn]

There it should be something more lurking out there. It works fine almost all times, but in the process of sorting all my logs from different computers I've located a couple of QSOs which are confirmed in LoTW and are unmatched in QLog. To my understanding everything matches (callsign, mode, band, start time).

Here is an example:

[foldynl]

it seems that QLog is stricter than LoTW in case of duplicity detection. QLog has a time tolerance of +-1 hour for QSL import (eQSL and LoTW). However, if there is the same QSO in this +-1 hour interval, QLog declares this QSO as Unmatched, because it is not able to pair them exactly (even though they have the same times).

I see the need to reduce this tolerance. I will prepare the fix for it. First of all, I need to find out the suitable time interval for the time tolerance.

[muihlinn]

In such digital modes isn't extremely rare (neither usual) that autoseq or manual operation gets confused after logging a QSO resending TX2 o TX3 which ends being another QSO with the same station right after the first. Sometimes you send RR73, so the software log the QSO, but it's never heard, taking a couple of turns to really finish the QSO. Depending the options in wsjtx or similar you may end with more than one QSO where one was intended. I guess that most of those false dupes happens that way.

Somewhere in the LoTW docs the matching timeframe is described. Can´t recall where, I'm not sure at all but IIRC it was between 15 and 30 minutes. Take it with a grain of salt, I can be completely wrong at it.

[foldynl]

It seems that LoTW time tolerance is really +-30 minutes. I will change QLog to the same interval

[foldynl]

It has been changed in release 0.29.1. QLog accepts -+30 minutes time difference so it should match your QSOs now

[muihlinn]

It has been changed in release 0.29.1. QLog accepts -+30 minutes time difference so it should match your QSOs now

I has matched almost everything from leftover QSO's, but still there are a few that do not match. I haven't had time to check up what's going on with these few, so I will keep this closed until I have looked at them.

Thanks much for your quick patches.