Right after starting to accept FT8 eQSL decided to upgrade their mode definitions to those of ADIF 3.0.4, so the mode is now "PSK (PSK31)" and not PSK31.
eQSL offers the option to upgrade your outbox, but it seems cqrlog currently is not ready for this change as it does not recognize new PSK (PSK31) contacts at the moment. I saw no announcements from eQSL so I guess they surprised all software developers.
From the eQSL_error.txt file:
QSO NOT FOUND in log
Call: I2CZQ
Band: 20M
Mode: PSK
QSO_date: 2017-06-17
Time_on: 0945
which is in my log as PSK31 at that date/time.
I'm sorry, I don't use digi modes but CQRLOG has a special configuration for modes that are not build-in. It's in Preferences -> Modes -> User defined digital modes. I'm not sure if it helps, but maybe it will.
73 Petr, OK7AN
--
http://HamQTH.com/ok2cqr
https://ok2cqr.com
[quote=ok7an]I'm sorry, I don't use digi modes but CQRLOG has a special configuration for modes that are not build-in. It's in Preferences -> Modes -> User defined digital modes. I'm not sure if it helps, but maybe it will.
73 Petr, OK7AN[/quote]
No, that does not help. eQSL now works with ADIF 3.0.5 and when I look up that conformation I see:
<CALL:5>I2CZQ<QSO_DATE:8:D>20170617<TIME_ON:4>0945<BAND:3>20M<MODE:3>PSK<SUBMODE:5>PSK31<RST_SENT:3>599<RST_RCVD:0><QSL_SENT:1>Y<QSL_SENT_VIA:1>E<APP_EQSL_AG:1>Y<GRIDSQUARE:6>JN55BL<EOR>
Note how it says mode PSK and submode PSK31. It's in the log as PSK31. I guess cqrlog has to deal with mode/submode somehow, either in the QSO or in the input from eQSL. It's not a simple thing, which is why I post it as 'wishlist' and not as 'bug'.
The short version of this issue is that eQSL went to version 3.0.4 of the ADIF specification. Both internally and when you download the adif of your inbox. CQRLOG 2.0.5 (001) has issues when selecting 'download from eQSL' with importing contacts from that adif file with mode/submode.
I just looked at ADIF 3.0.6 spec and here is my personal note.
They got completely crazy! It's one BIG mess. How long did they have their head in microwave oven? Submodes? Really? Why just don't use modes as they are? Maybe for award, DXCC but why submodes for QSO?
And what about QRZCOM_QSO_UPLOAD_DATE? We'll add another field what about HAMQTH_QSO_UPLOAD_DATE? What is APP_ prefix for? For fun? No, I'm no so stupid and don't want to have HAMQTH_QSO_UPLOAD_DATE, I already use APP_ prefix for that. The same with CLUBLOG and HRDLOG. Twenty minutes in microwave? I have no idea. I'm sorry but I doubt I'll support this mess. I'm sorry. They are crazy.
The same with ARRL LOTW. We have to wait until they add FT8 support. Why they should be? We have new mode, we just want to validate if the mode is the same like WKD station has. Why they care if it's FT8, FT-9, FTXX?
--
http://HamQTH.com/ok2cqr
https://ok2cqr.com
Hi!
I'm working on improving the LoTW import and saw the problem with submodes for eQSL, I guess it still exists? Can you upload or email me an eQSL ADIF example, with the same info as the example above but with the full ADIF so I can test? (I'm currently no eQSL user)
73 de Jonas
must have pushed wrong reply button, was replying to msg #4
This is now fixed and kindly merged into master branch by Petr this morning, now the eQSL import also uses submode to find matching qsos in the log. I also implemented time matching, so now the time in the log must be +/-60min (eQSL spec.) with the time in the eQSL.
Thanks to PE4KH for testing!