eQSL Upload Question

[dl2ki]

Hi Ladislav,

a known OM has the following understanding problem.

He is trying out QLog but has uploaded his QSO's to eQSL in the past. These are now available on eQSL. After selecting "Service -> eQSL -> Selection" all QSO's appear in QLog as "Selected QSO" for upload, as they are not marked as uploaded in QLog.

He is now afraid that the QSOs will be duplicated in eQSL after an upload. In "CQRLOG" there is an option "mark all QSO as uploaded to eQSL", with which one can set the uploaded mark in "CQRLOG".

His question is whether he can upload the QSOs from QLog without them appearing twice in eQSL.

Since the exact functionality of the connection to eQSL and Clublog is not described in more detail, I would rather ask here, as you surely know the functionality from the source code.

In addition, he asked whether an automatic syncronisation between eQSL, Clublog and QLog is possible, which is currently not the case.

Many thanks in advance.

[foldynl]

Wolfgang,

QLog eQSL Upload is controlled by ADIF value EQSL_QSL_SENT (QLog shows it as eQSLs). Currently, QLog sends QSO to eQSL when EQSL_QSL_SENT = N. Otherwise, QSO is not sent. It is a process that is based on the ADIF specification, so I think there is no need to copy this to the Wiki.

Unfortunately, what I discovered is one misunderstanding what I made. I describe it in following issue report. that's exactly what I'm trying to fix now. Another bad news is that I found out what the situation is in other logging applications and it is not so clear to me.

Getting back to the problem of your OM. It is necessary to find out what is the value of EQSL_QSL_SENT. Ideally, send me one ADIF record with the QSO.

QLog does not contain any functionality to "mark all QSOs as uploaded" It can be done by "batch" edit the QSOs. But as I wrote, there is nothing good to do in QLog regarding uploading to services, because I have prepared a patch that implements correct sending to services based on ADIF spec.

It means:
QLog versions up to 0.19: QLog sends everything marked N (eQSL, LoTW) - that's wrong
QLog upcoming version 0.20: QLog will send anything to eQSL, LoTW that is marked R, Q or has no value filled. Otherwise, the QSO will not be sent. Functionality "mark all QSOs as uploaded" is not planned now (it does not means that won't be implemented in the future), because it should be set correctly by Logging software. Batch QSO edit can be used to change the value in QLog.

That is the current situation. I apologize for the problems, but at the moment I am focusing on getting the status of the uploading to the services "properly" fixed.

[dl2ki]

Thank you for the detailed information. I have once so forwarded to the OM.
I think that the OM will then wait for version 0.20.

[foldynl]

would it be possible to send me a ADIF record of the impacted QSO?

[dl2ki]

Hi,

the value is always "<eqsl_qsl_sent:1>N".

But I will set the values in the database to "Y" for the OM, so he can go on with it.
In my database they are also all on "Y".

<EQSL_QSL_SENT>Y</EQSL_QSL_SENT>

We'll just wait and see how you changed that in version 0.20.

Here is a record from its ADIF export.

call:6IU1...
<qso_date:8:D>20201208
<time_on:6:T>092800
<qso_date_off:8:D>20201208
<time_off:6:T>094200
<rst_rcvd:3>579
<rst_sent:3>579
name:8Fab.....
qth:6Ma....
cqz:215
ituz:228
freq:1:N7
band:340m
mode:2CW
cont:2EU
dxcc:3248
country:5Italy
<qsl_rcvd:1>Y
<qsl_sent:1>Y
<lotw_qsl_rcvd:1>N
<lotw_qsl_sent:1>N
<tx_pwr:1>5
<clublog_qso_upload_status:1>N
comment:23tnx for my first cw qso
<eqsl_qsl_rcvd:1>N
<eqsl_qsl_sent:1>N
<hrdlog_qso_upload_status:1>N
<my_antenna:7>Doublet
<my_city:10>Wes.......
<my_gridsquare:6>JN....
<my_rig:5>Tramp
notes:15my first cw qso
operator:4Hans
<qrzcom_qso_upload_status:1>N
qslmsg:23my first cw QSO, QRP-5W
<qsl_sent_via:1>D
<station_callsign:6>OE....
<app_eqsl_upload_date:8>20201208

[foldynl]

Many thanks for the ADIF record.

This is exactly the situation I was afraid of. Current QLog interprets N as "not sent, will be sent", but correctly it should be "don't send". So your OM expectation was correct - do not send the QSO. If QLog will be upgraded from 0.19 (current) to 0.20 (next), this error will have to be fixed somehow in internal database. The bad thing is that I can't decide if N is a QLog "error" what means "not sent but it will be sent", or if it's an imported "N" what means "do not send". I solved it by assuming that all N in the QLog are errors, so during the upgrade I will change N to Q, which will lead to all currently N-QSOs being sent. Well, now I see that there may also be cases when N in the DB is imported N, which means "do not send". I'm sorry, but I made quite a mess of it and I don't know how to fix it correctly. The source code is already prepared but I am still thinking how to fix it in database. However, your case shows me that it will be better to leave N as N in QLog database - newly, QSO will not be sent. In the event that N was incorrectly filled by QLog as an error, an operator will change it from N to Q manually.

[foldynl]

I'm looking for other things that are not related to QLog. What application does your OM use? I can seen that ADIF contains field "app_eqsl_upload_date". It says that QSO has been already sent to EQSL service but "eqsl_qsl_sent" is set to N - what means "do not send". In this case, I would assume that "eqsl_qsl_sent" should have a value 'Y" - what means "QSL has been already sent and accepted by eQSL" and "EQSL_QSLSDATE" should contain a date of sending.

[dl2ki]

I asked again for information.

The OM has so far entered all QSO's directly via the eQSL website, and has not yet used a logbook program. Therefore, this is all new for him.

The data was then exported from eQSL and transferred to QLog.

If the version 0.20 is there, I will carry out necessary adjustments to the data then together with him.

Thank you again for your engagement. I hope that the motivation remains, hi.

[foldynl]

Wolfgang,

it is not a good idea to download ADI from eQSL and import it to any log application. I don't know exactly how it is with eQSL, but for example LoTW provides a very limited amount of information from QSOs. See example below

<APP_LoTW_OWNCALL:6>OK1MLG
<STATION_CALLSIGN:6>OK1MLG
<CALL:5>xxxxxx
<BAND:3>15M
<FREQ:8>21.30680
<MODE:3>SSB
<APP_LoTW_MODEGROUP:5>PHONE
<QSO_DATE:8>20210710
<APP_LoTW_RXQSO:19>2021-08-15 05:35:10 // QSO record inserted/modified at LoTW
<TIME_ON:6>124800
<APP_LoTW_QSO_TIMESTAMP:20>2021-07-10T12:48:00Z // QSO Date & Time; ISO-8601
<QSL_RCVD:1>Y
<QSLRDATE:8>20230226
<APP_LoTW_RXQSL:19>2023-02-26 22:20:00 // QSL record matched/modified at LoTW
<eor>

there are many application-dependent tags.