LOTW is the well known ARRL log online useful to match and confirm contacts between the radio operators without the need to exchange paper cards.
JTDX is one of the most used weak signal decoder/encoder software in use by the HAM radio community. JTDX saves QSO in ADIF format to the wsjtx_log.adi file. This file or a part of it, is periodically sent to LOTW, automatically or manually.
JTDX records, for each QSO, the start and ending GMT hours formatted as example
<time_on:6>120802 <time_off:6>120944
It may happen, during the normal activity, that you start calling a station and keep calling for a long time or stop calling him and continue after a pause. This often happens with OM of rare countries, rare squares or DXpeditions.
When finally the rare DX answers, 73, QSO logged and time_on differs from time_off of several minutes (hours?).
The rare DX station, on the contrary, saves your QSO in his log with time_on reasonably very close to time_off.
When both upload the log on LOTW, the QSO will be validated only if the two time_on values differ of maximum 30 minutes.
Kudos to Sergio IK0FTA who discovered the flaw.
I don’t know why LOTW use time_on instead the more logical time_off to match the QSO, there will be a reason for sure, I hope. However the solution is simple: edit the file wsjtx_log.adi and modify the time_on of QSOs that last more than 30 minutes to make them shorter.
Too many QSO to check ? There is a script :-)
#!/usr/bin/env python2
# coding=utf-8
import time
import sys
import os
reload(sys)
sys.setdefaultencoding('utf8')
def printfound(line):
print "\nLong QSO detected!"
print "##################"
print line
print "##################\n"
with open("./wsjtx_log.adi", "r") as myfile:
with open("./fixed_qso.adi", "w") as outfile:
outfile.write("Time_on fix for LOTW - IW0FFK 2022\n<EOH>\n")
print "> Log found"
for line in myfile:
if "<time_on:6>" in line:
rawtimeon = line[line.index('<time_on:6>')+11:line.index('<time_on:6>')+18]
rawtimeoff = line[line.index('<time_off:6>')+12:line.index('<time_off:6>')+19]
hh_on = int(rawtimeon[:2])
hh_off = int(rawtimeoff[:2])
mm_on = int(rawtimeon[2:4])
mm_off = int(rawtimeoff[2:4])
ss_on = int(rawtimeon[4:])
ss_off = int(rawtimeoff[4:])
if hh_on == hh_off:
if (mm_off - mm_on) > 25:
printfound(line)
outfile.write(line[:line.index('<time_on:6>')+11] + str(hh_off).zfill(2) + str(mm_off-1).zfill(2) + \
str(ss_off).zfill(2) + line[line.index('<time_on:6>')+17:] + '\n')
elif (hh_off - hh_on) == 1:
if ((mm_off + 60) - mm_on) > 25:
printfound(line)
outfile.write(line[:line.index('<time_on:6>')+11] + str(hh_off).zfill(2) + str(mm_off-1).zfill(2) + \
str(ss_off).zfill(2) + line[line.index('<time_on:6>')+17:] + '\n')
else:
print "Very long QSO or data inconsistencies"
print line
print "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
outfile.write(line[:line.index('<time_on:6>')+11] + str(hh_off).zfill(2) + str(mm_off-1).zfill(2) + \
str(ss_off).zfill(2) + line[line.index('<time_on:6>')+17:] + '\n')
Copy and paste the code above into an empty text file and save as adif4lotw.py.
Copy adif4lotw.py file into the JTDX log folder and run the command
python2 adif4lotw.py
A new file named fixed_qso.adi is created containing the suspicious QSO with the time_on value corrected and set close to time_off.
This file can be uploaded to LOTW.
If you use Python3 instead of Python2, it should be easy to modify the script to make it work.
I tested this script in Linux and works fine, probably it works also in Windows or OSX with Python installed.
Using the script I recovered about 15 QSO confirmation and three new squares ^_^
I don’t know if also WSJT-X has this problem, worth to check.
iw0ffk 
