Re: eQSL Synchronise from ADIF
Gary Hinson <Gary@...>
Hi Dave.toggle quoted messageShow quoted text
We're not ignoring you, honest. I don't use eQSL myself, so I can't readily
check/verify the Logger32 eQSL sync functions against the documentation, or
against the obvious requirements.
The information in that part of the manual was - I think - either
transferred over from the v3.5 help file written some years back by persons
now unknown, or donated by someone on the beta test team more recently.
It's also entirely possible I may have munted it [ZL technical term] in the
process, or misunderstood explanations, or lost the plot.
Maybe you can help get to the bottom of this by exploring the issue - using
a test log perhaps and a version of the eQSL sync ADIF file with variant QSO
records. Are you certain those bad/mismatched QSOs ONLY differ by a few
mins in the times? Does it matter which times differ (time on or time off)?
If the time mismatch is more than zero but less than a minute, does that
generate a match or mismatch? What about mismatches on other fields?
From: email@example.com <firstname.lastname@example.org> On Behalf Of Dave Sergeant
Sent: Tuesday, 15 March 2022 9:28 am
Subject: Re: [hamlogger] eQSL Synchronise from ADIF
No replies to my query on this.
According to 16.4.4 there is a +/= 10 minute tolerance on the matching:
"The eQSL sync function searches for a QSO in the logbook that matches in
terms of callsign, band, mode and date/time. To allow for clock variations,
it allows +/- 10 minutes leeway on the time. If a QSO with the same
callsign, band and mode is found at about the right time, and if
the eQSL_SENT field is Y, a match has been found so the eQSL_RCVD field is
set to Y."
I can see no other reason why the QSOs given below are being rejected, the
time is out by 1 and 2 minutes.
73 Dave G3YMC
On 11 Mar 2022 at 12:25, Dave Sergeant G3YMC wrote:
I thought (though cannot find it in the manual) that when you