I can tell you exactly how I got it. I used fldigi in XmlRpc mode. I made a PSK31 contact and CQRLOG logged it as such. I then used CQRLOG to "Upload QSOs to LoTW web page". When the QSO was confirmed in LoTW, I "Download and process data from LoTW website" and got the error.
Here's the ADIF export for the QSO from CQRLOG:
ADIF export from CQRLOG for Linux version Alpha_(134)_QT6
Copyright (C) 2025 by Petr, OK2CQR and Martin, OK1RR
Internet: http://www.cqrlog.com
<ADIF_VER:5>3.1.0
<CREATED_TIMESTAMP:15>20250125 081802
<PROGRAMID:6>CQRLOG
<PROGRAMVERSION:15>Alpha_(134)_QT6
<EOH>
<QSO_DATE:8>20250125<TIME_ON:4>0147<TIME_OFF:4>0156<STATION_CALLSIGN:4>N9KT<CALL:5>K7RCR<MODE:3>PSK<FREQ:6>7.0715<BAND:3>40m<RST_SENT:3>599<RST_RCVD:3>599<NAME:4>Rick<QTH:9>SAHUARITA<QSL_SENT:1>N<QSL_RCVD:1>N
<GRIDSQUARE:6>DM41mx<MY_GRIDSQUARE:6>EM69wv<DISTANCE:4>2392<TX_PWR:3>100<APP_CQRLOG_DXCC:1>W<DXCC:3>291<COMMENT:21>Daugher lives in Indy<ITUZ:1>6<CQZ:1>3<STATE:2>AZ<CNTY:7>AZ,Pima
<APP_CQRLOG_PROFILE:27>1|EM69wv|Indianapolis, IN||<LOTW_QSL_SENT:1>Y<LOTW_QSLSDATE:8>20250124<CONT:2>NA<EQSL_QSL_SENT:1>Y<EQSL_QSLSDATE:8>20250124
<EOR>
And here's the error message:
<ADIF_VER:5>3.1.0
<CREATED_TIMESTAMP:15>20250125 060153
LoTW import errors from CQRLOG for Linux version Alpha_(134)_QT6
Copyright (C) 2025 by Petr, OK2CQR and Martin, OK1RR
Internet: http://www.cqrlog.com
<EOH>
<APP_CQRLOG_ERROR:330>
------------------------------------------------
QSO NOT FOUND in log
Call: K7RCR
Band: 40M
Mode: DATA
Submode:
QSO_date: 2025-01-25
Time_on: 014700
QSLR: Y
QSLRDate: 2025-01-25
CQZ: 03
ITUZ:
IOTA:
Grid: DM41mx
State: AZ
County: AZ,PIMA
------------------------------------------------
<LOTW_QSL_SENT:1>Y<LOTW_QSLSDATE:8>20250125<APP_CQRLOG_NOTE:36>This line prevents reupload to LoTW
<EQSL_QSL_SENT:1>Y<EQSL_QSLSDATE:8>20250125<APP_CQRLOG_NOTE:36>This line prevents reupload to eQSL
<CONTEST_ID:25>Qso_was_not_found_in_log!
<CALL:5>K7RCR<BAND:3>40M<FREQ:7>7.07150<MODE:4>DATA<APP_LoTW_MODE:4>DATA<APP_LoTW_MODEGROUP:4>DATA<QSO_DATE:8>20250125<APP_LoTW_RXQSO:19>2025-01-25 03:07:07 // QSO record inserted/modified at LoTW<TIME_ON:6>014700<APP_LoTW_QSO_TIMESTAMP:20>2025-01-25T01:47:00Z // QSO Date & Time; ISO-8601<QSL_RCVD:1>Y<QSLRDATE:8>20250125<APP_LoTW_RXQSL:19>2025-01-25 03:07:07 // QSL record matched/modified at LoTW<DXCC:3>291<COUNTRY:24>UNITED STATES OF AMERICA<APP_LoTW_DXCC_ENTITY_STATUS:7>Current<PFX:2>K7<APP_LoTW_2xQSL:1>N<APP_LoTW_QSLMODE:5>PSK31<GRIDSQUARE:6>DM41MX<STATE:2>AZ // Arizona<CNTY:7>AZ,PIMA // Pima<CQZ:2>03<eor>
Questions:
1. Did I do something wrong? If yes, how do I keep it from happening again? It is adding errors for every PSK31 contact I make!
2. How can I fix the existing errors and keep it from happening again? I'm now afraid to make more PSK31 contacts!
3. If it wasn't my fault, can you fix the program?
Thank you again for such a wonderful program!
-David, N9KT
HI David!
You have done nothing wrong. The opponent station has used LoWT mode conversion because his log program (or he thinks that) PSK31 is not defined in ADIF.
That is wrong.
PSK31 belongs mode group PSK , see https://adif.org/315/ADIF_315.htm#Mode_Enumeration of ADIF standards.
So there is no need to make any mode conversions. Qso should be sent to LoTW as mode PSK. How ever when you look at error file Cqrlog gives to you, you can see that LoTW reports this conversion happened within it's own program based ADIF tag.
ADIF tags beginning "APP_" are program specific tags that are counted on only by program that finds it's own name inside the tag. So Cqrlog does not care about them if there is no "CQRLOG" inside.
But you can now manually enter LoWT confirmation received for that qso as you can see from error ADIF that qso was ok.
If opponent station uses logging program that propely follows ADIF standard there should not be this kind of problem in future with PSK31.
Unfortunately many logging programs do not follow standards (not even try to do it).
--
Saku
OH1KH
Saku-
Thank you for the detailed explanation! However, I still need a little guidance. I also found the "LoTW/eQSL import errors" section in the manual and read it thoroughly.
I took the "errors_LoTW.adi" file and imported it into my log like the "LoTW/eQSL import errors" section said to do. It immediately created an "errors_ADIFimport2025-01-25 07_14_33.adi" file. That file had the following in it:
ADIF export from CQRLOG for Linux version Alpha_(134)_QT6
Copyright (C) 2025 by Petr, OK2CQR and Martin, OK1RR
Internet: http://www.cqrlog.com
ERROR QSOs FROM ADIF IMPORT
<ADIF_VER:5>3.1.0
<CREATED_TIMESTAMP:15>20250125 121444
<PROGRAMID:6>CQRLOG
<PROGRAMVERSION:15>Alpha_(134)_QT6
<EOH>
<APP_CQRLOG_ERROR:330>------------------------------------------------QSO NOT FOUND in logCall: K7RCRBand: 40MMode: DATASubmode: QSO_date: 2025-01-25Time_on: 014700QSLR: YQSLRDate: 2025-01-25CQZ: 03ITUZ: IOTA: Grid: DM41mxState: AZCounty: AZ,PIMA------------------------------------------------<LOTW_QSL_SENT:1>Y<LOTW_QSLSDATE:8>20250125<APP_CQRLOG_NOTE:36>This line prevents reupload to LoTW<EQSL_QSL_SENT:1>Y<EQSL_QSLSDATE:8>20250125<APP_CQRLOG_NOTE:36>This line prevents reupload to eQSL<CONTEST_ID:25>Qso_was_not_found_in_log!<CALL:5>K7RCR<BAND:3>40M<FREQ:7>7.07150<MODE:4>DATA<APP_LoTW_MODE:4>DATA<APP_LoTW_MODEGROUP:4>DATA<QSO_DATE:8>20250125<APP_LoTW_RXQSO:19>2025-01-25 03:07:07 // QSO record inserted/modified at LoTW<TIME_ON:6>014700<APP_LoTW_QSO_TIMESTAMP:20>2025-01-25T01:47:00Z // QSO Date & Time; ISO-8601<QSL_RCVD:1>Y<QSLRDATE:8>20250125<APP_LoTW_RXQSL:19>2025-01-25 03:07:07 // QSL record matched/modified at LoTW<DXCC:3>291<COUNTRY:24>UNITED STATES OF AMERICA<APP_LoTW_DXCC_ENTITY_STATUS:7>Current<PFX:2>K7<APP_LoTW_2xQSL:1>N<APP_LoTW_QSLMODE:5>PSK31<GRIDSQUARE:6>DM41MX<STATE:2>AZ // Arizona<CNTY:7>AZ,PIMA // Pima<CQZ:2>03<eor>
ERROR: Wrong QSO mode: DATA
What do I do now?
-David, N9KT
HI David!
Thanks for feedback. Perhaps I have not made things clear enough in "LoTW/eQSL import errors" section of Cqrlog/Help.
I added a line:
NOTE: Importing error files is not meant to fix situation where you have the qso already on your log. You just should then check the differences with your log and received confirmation and decide if you can manually make qso confirmed.
That is just like in your case. You have qso in log, and you have received confirmation. Then there is no need to import error file to Cqrlog. Just make the confirmation manually received as you can see from error log that problem lays on mode="Data" and that LoTW says it has changed mode and shows that APP_LoTW_QSLMODE is PSK31. The same that you have logged into your log.
To do this manually you just find the qso from your log (QSOlist), click the qso so that selection mark appears to leftmost column, then choose File/Group edit
and ensure the text is "Apply will affect to selected qsos".
Find LoTW received from selector and "L" appears automatically to "value". Then press button "Apply" and job is done.
A word more about importing error files.
Imagine situation that you have worked a WSJT-X or fldigi qso and logged it but forgot to put the remote on at Cqrlog side.
Then you have the qso in WSJT-X own log but not in Cqrlog.
Once you receive confirmation you get error "QSO not in log". Then you check WSJT-X own log and notice t is there but you forgot to use remote and so it is not in Cqrlog.
Then you just import that error file and Qso in in your Cqrlog, alredy confirmed.
--
Saku
OH1KH
Saku-
Thank you for the explanation and the clear instructions (we should make a FAQ out of some of these).
I followed them and verified that there is now an "L" in the "qslr" column.
And in "Edit details" it shows:
LoTW QSL sent date 2025-01-24
LoTW QSL rcvd date 2025-01-26
(I would have posted a snapshot inline, but I couldn't figure out how so I included it)
However, the next time I imported from LoTW, I got the same error as before! I thought that the error would go away since CQRLOG would see that the QSO was already confirmed and ignore the QSL in the download.
So, even though I manually confirmed it in CQRLOG as an LoTW QSL, I still get the error. Will I get these errors from now on every time I "Download and process data from LoTW website"?
Thanks again for all your help!
-David, N9KT
File:
HI!
Now it depends your LoTW request and Cqrlog version.
In official version you have to manually set the "date on or after" from where beginning LoTW confirmations are fetch.
If you keep the same date there you get always confirmations from that same date, what includes that problem qso.
With CqrlogAlpha you can set program checkbox to change the date to last used day-1 automatically.
About editing forum message:
If you want image, colors, etc. into your forum message select "text format"(below edit box) to be "Full HTML".
After that click "Enable rich-text" that is above "Full HTML" selector.
Then you can start to write your message and paste images from clipboard to it.
If edit box is too small you can drag it bigger from botton right corner (where 3 stripes are in 45degrees angle)
--
Saku
OH1KH