eQSL Synchronise from ADIF


Dave Sergeant G3YMC <dave@...>
 

I thought (though cannot find it in the manual) that when you
synchronised eQSL (and LOTW) using a downloaded ADIF file that there
was some tolerance on the times to allow for mismatches. 10 minutes I
recall. This is not happening.

Just downloaded my inbox (I have my own routine to do this) and found a
couple didn't match (from bad.adi):
<CALL:5>G4BUE<BAND:4>160M<MODE:2>CW<QSO_DATE:8>19760214<TIME_ON:4>2128
time in my log 2126
<CALL:5>G4BUE<BAND:3>80M<MODE:2>CW<QSO_DATE:8>20070114<TIME_ON:4>1633
time in my log 1632

Is the time tolerance not working?

73 Dave G3YMC

http://davesergeant.com


Dave Sergeant G3YMC <dave@...>
 

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
synchronised eQSL (and LOTW) using a downloaded ADIF file that there was
some tolerance on the times to allow for mismatches. 10 minutes I
recall. This is not happening.

Just downloaded my inbox (I have my own routine to do this) and found a
couple didn't match (from bad.adi):
<CALL:5>G4BUE<BAND:4>160M<MODE:2>CW<QSO_DATE:8>19760214<TIME_ON:4>2128
time in my log 2126
<CALL:5>G4BUE<BAND:3>80M<MODE:2>CW<QSO_DATE:8>20070114<TIME_ON:4>1633
time in my log 1632

Is the time tolerance not working?

http://davesergeant.com


Gary Hinson <Gary@...>
 

Hi Dave.

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?

73
Gary ZL2iFB

-----Original Message-----
From: hamlogger@groups.io <hamlogger@groups.io> On Behalf Of Dave Sergeant
G3YMC
Sent: Tuesday, 15 March 2022 9:28 am
To: hamlogger@groups.io
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
synchronised eQSL (and LOTW) using a downloaded ADIF file that there
was some tolerance on the times to allow for mismatches. 10 minutes I
recall. This is not happening.

Just downloaded my inbox (I have my own routine to do this) and found
a couple didn't match (from bad.adi):
<CALL:5>G4BUE<BAND:4>160M<MODE:2>CW<QSO_DATE:8>19760214<TIME_ON:4>2128
time in my log 2126
<CALL:5>G4BUE<BAND:3>80M<MODE:2>CW<QSO_DATE:8>20070114<TIME_ON:4>1633
time in my log 1632

Is the time tolerance not working?

http://davesergeant.com


ja1nlx
 

This is my test result. Logger32 ver4.0.291

Time in eQSL file is 1130
Time in Logbook
1100 -> error
1110 -> updated
1140 -> updated
1150 -> updated
1200 -> updated
1210 -> error

I think it works as expected.

73 de aki
JA1NLX

------ Original Message ------
From: "Dave Sergeant G3YMC" <dave@...>
To: hamlogger@groups.io
Sent: 2022/03/15 5:28:25
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
synchronised eQSL (and LOTW) using a downloaded ADIF file that there was
some tolerance on the times to allow for mismatches. 10 minutes I
recall. This is not happening.

Just downloaded my inbox (I have my own routine to do this) and found a
couple didn't match (from bad.adi):
<CALL:5>G4BUE<BAND:4>160M<MODE:2>CW<QSO_DATE:8>19760214<TIME_ON:4>2128
time in my log 2126
<CALL:5>G4BUE<BAND:3>80M<MODE:2>CW<QSO_DATE:8>20070114<TIME_ON:4>1633
time in my log 1632

Is the time tolerance not working?

http://davesergeant.com






Bob
 

Actually, it's +/- 30 minutes, and the code that scans the logbook for a matching QSO is the same for eQSL sync, LoTW sync, and QSL sync. But it's easy enough to test/check if it works, simply edit the two QSOs <TIME_ON:6>123456 to match what's in the logbook and try again.

It may be helpful to compare the original eQSL ADIF record with what is in the Logger32 BAD.ADI file. That way we can look for things like the OPERATOR field mismatch.

SeventyThree(s).

PS. Apologies for not answering on Friday, but I did not get your original message sent on Friday, or your follow up today. I did however see Garys reply from this morning,

On 03/14/2022 7:44 PM Gary Hinson <gary@...> wrote:


Hi Dave.

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?

73
Gary ZL2iFB

-----Original Message-----
From: hamlogger@groups.io <hamlogger@groups.io> On Behalf Of Dave Sergeant
G3YMC
Sent: Tuesday, 15 March 2022 9:28 am
To: hamlogger@groups.io
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
synchronised eQSL (and LOTW) using a downloaded ADIF file that there
was some tolerance on the times to allow for mismatches. 10 minutes I
recall. This is not happening.

Just downloaded my inbox (I have my own routine to do this) and found
a couple didn't match (from bad.adi):
<CALL:5>G4BUE<BAND:4>160M<MODE:2>CW<QSO_DATE:8>19760214<TIME_ON:4>2128
time in my log 2126
<CALL:5>G4BUE<BAND:3>80M<MODE:2>CW<QSO_DATE:8>20070114<TIME_ON:4>1633
time in my log 1632

Is the time tolerance not working?

http://davesergeant.com









Dave Sergeant G3YMC <dave@...>
 

Thanks Bob.

I didn't find out why the original batch didn't match. Then I was
misled this morning after I did another download of just 5 QSOs and one
of them failed. Played around with matching the times but then realised
I had logged V26K as V26BK....

I will keep an eye on the situation, but clearly if it is +/- 30
minutes I should not have a problem on that front.

73 Dave G3YMC

On 15 Mar 2022 at 8:41, Bob wrote:

Actually, it's +/- 30 minutes, and the code that scans the logbook for a
matching QSO is the same for eQSL sync, LoTW sync, and QSL sync. But
it's easy enough to test/check if it works, simply edit the two QSOs
<TIME_ON:6>123456 to match what's in the logbook and try again.

It may be helpful to compare the original eQSL ADIF record with what is
in the Logger32 BAD.ADI file. That way we can look for things like the
OPERATOR field mismatch.

SeventyThree(s).

http://davesergeant.com


Bob
 

Correction:

It would be helpful to compare the eQSL ADIF records of these two QSOs with an ADIF export from Logger32 of these two QSOs. 73.

On 03/15/2022 8:41 AM Bob <k4cy@...> wrote:


Actually, it's +/- 30 minutes, and the code that scans the logbook for a matching QSO is the same for eQSL sync, LoTW sync, and QSL sync. But it's easy enough to test/check if it works, simply edit the two QSOs <TIME_ON:6>123456 to match what's in the logbook and try again.

It may be helpful to compare the original eQSL ADIF record with what is in the Logger32 BAD.ADI file. That way we can look for things like the OPERATOR field mismatch.

SeventyThree(s).

PS. Apologies for not answering on Friday, but I did not get your original message sent on Friday, or your follow up today. I did however see Garys reply from this morning,

On 03/14/2022 7:44 PM Gary Hinson <gary@...> wrote:


Hi Dave.

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?

73
Gary ZL2iFB

-----Original Message-----
From: hamlogger@groups.io <hamlogger@groups.io> On Behalf Of Dave Sergeant
G3YMC
Sent: Tuesday, 15 March 2022 9:28 am
To: hamlogger@groups.io
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
synchronised eQSL (and LOTW) using a downloaded ADIF file that there
was some tolerance on the times to allow for mismatches. 10 minutes I
recall. This is not happening.

Just downloaded my inbox (I have my own routine to do this) and found
a couple didn't match (from bad.adi):
<CALL:5>G4BUE<BAND:4>160M<MODE:2>CW<QSO_DATE:8>19760214<TIME_ON:4>2128
time in my log 2126
<CALL:5>G4BUE<BAND:3>80M<MODE:2>CW<QSO_DATE:8>20070114<TIME_ON:4>1633
time in my log 1632

Is the time tolerance not working?

http://davesergeant.com









Gary Hinson <Gary@...>
 

Thanks all, I'm glad it's resolved.

I'll correct/update the manual accordingly.

Another small step for mankind!

73
Gary ZL2iFB

-----Original Message-----
From: hamlogger@groups.io <hamlogger@groups.io> On Behalf Of Dave Sergeant
G3YMC
Sent: Wednesday, 16 March 2022 1:56 am
To: hamlogger@groups.io
Subject: Re: [hamlogger] eQSL Synchronise from ADIF

Thanks Bob.

I didn't find out why the original batch didn't match. Then I was misled
this morning after I did another download of just 5 QSOs and one of them
failed. Played around with matching the times but then realised I had logged
V26K as V26BK....

I will keep an eye on the situation, but clearly if it is +/- 30 minutes I
should not have a problem on that front.

73 Dave G3YMC

On 15 Mar 2022 at 8:41, Bob wrote:

Actually, it's +/- 30 minutes, and the code that scans the logbook for
a matching QSO is the same for eQSL sync, LoTW sync, and QSL sync. But
it's easy enough to test/check if it works, simply edit the two QSOs
<TIME_ON:6>123456 to match what's in the logbook and try again.

It may be helpful to compare the original eQSL ADIF record with what
is in the Logger32 BAD.ADI file. That way we can look for things like
the OPERATOR field mismatch.

SeventyThree(s).

http://davesergeant.com


Gianfranco
 

About this:
do you see any difference between these two qsos, apart from a minute of difference?
or is the error caused by the four digits instead of the six as in the Logger32?
It seems to me that there is nothing else different

Logger32:
<CALL:5>RL3DD<QSO_DATE:8:D>20220203<TIME_ON:6>092900
<BAND:3>20m<MODE:4>MFSK<SUBMODE:3>FT4<RST_RCVD:3>+00
                           <RST_SENT:3>-10<CONT:2>EU <CQZ:2>16 <DXCC:2>54
<FREQ:9>14.082010<GRIDSQUARE:6>KO85xf <ITUZ:2>29
                           <OPERATOR:6>IK3OGN<PFX:3>RL3 <LOTW_QSL_SENT:1>Y
                           <LOTW_QSL_RCVD:1>Y <EQSL_QSL_RCVD:1>Y  <STATE:2>MO
                           <K_INDEX:1>5 <TIME_OFF:6>093000 <SFI:3>128 <A_INDEX:2>12
                           <FREQ_RX:9>14.082009 <EOR>

Eqsl:
QSO not found in Logbook: <CALL:5>RL3DD<QSO_DATE:8:D>20220203<TIME_ON:4>0930
<BAND:3>20M<MODE:4>MFSK<SUBMODE:3>FT4<RST_SENT:3>+00
<RST_RCVD:0><QSL_SENT:1>Y<QSL_SENT_VIA:1>E<APP_EQSL_AG:1>Y
                           <GRIDSQUARE:6>KO85sk<EOR>

73 de ik3ogn GFranco

Il 15/03/2022 15:19, Bob ha scritto:
Correction:

It would be helpful to compare the eQSL ADIF records of these two QSOs with an ADIF export from Logger32 of these two QSOs. 73.

On 03/15/2022 8:41 AM Bob <k4cy@...> wrote:

Actually, it's +/- 30 minutes, and the code that scans the logbook for a matching QSO is the same for eQSL sync, LoTW sync, and QSL sync. But it's easy enough to test/check if it works, simply edit the two QSOs <TIME_ON:6>123456 to match what's in the logbook and try again.

It may be helpful to compare the original eQSL ADIF record with what is in the Logger32 BAD.ADI file. That way we can look for things like the OPERATOR field mismatch.

SeventyThree(s).

PS. Apologies for not answering on Friday, but I did not get your original message sent on Friday, or your follow up today. I did however see Garys reply from this morning,

On 03/14/2022 7:44 PM Gary Hinson <gary@...> wrote:

Hi Dave.

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?

73
Gary ZL2iFB

-----Original Message-----
From: hamlogger@groups.io <hamlogger@groups.io> On Behalf Of Dave Sergeant
G3YMC
Sent: Tuesday, 15 March 2022 9:28 am
To: hamlogger@groups.io
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
synchronised eQSL (and LOTW) using a downloaded ADIF file that there
was some tolerance on the times to allow for mismatches. 10 minutes I
recall. This is not happening.

Just downloaded my inbox (I have my own routine to do this) and found
a couple didn't match (from bad.adi):
<CALL:5>G4BUE<BAND:4>160M<MODE:2>CW<QSO_DATE:8>19760214<TIME_ON:4>2128
time in my log 2126
<CALL:5>G4BUE<BAND:3>80M<MODE:2>CW<QSO_DATE:8>20070114<TIME_ON:4>1633
time in my log 1632

Is the time tolerance not working?
http://davesergeant.com










Gianfranco
 

... is there any difference on this other qso, except 30 seconds?
But there are others and all with a few minutes more or less. (at least apparently because if there's a difference then it's somewhere else)
The perplexity expressed by Dave G3YMC was therefore more than legitimate for me.

Logger32:
<CALL:5>UT5ED <QSO_DATE:8:D>20220203 <TIME_ON:6>092830 <BAND:3>20m <MODE:4>MFSK
<SUBMODE:3>FT4 <RST_RCVD:3>+07 <RST_SENT:3>-03
<CONT:2>EU <CQZ:2>16 <DXCC:3>288 <FREQ:9>14.082010
<GRIDSQUARE:6>KN78kl <ITUZ:2>29 <OPERATOR:6>IK3OGN
<PFX:3>UT5 <LOTW_QSL_SENT:1>Y <LOTW_QSL_RCVD:1>Y <EQSL_QSL_RCVD:1>Y
<K_INDEX:1>5 <TIME_OFF:6>092900 <SFI:3>128 <A_INDEX:2>12
<FREQ_RX:9>14.082010 <EOR>

Eqsl:
QSO not found in Logbook:
<CALL:5>UT5ED<QSO_DATE:8:D>20220203<TIME_ON:4>0929<BAND:3>20M<MODE:4>MFSK
<SUBMODE:3>FT4<RST_SENT:2>07<RST_RCVD:0><QSL_SENT:1>Y<QSL_SENT_VIA:1>E<QSLMSG:19>TNX

For QSO TU 73!.<APP_EQSL_AG:1>Y<GRIDSQUARE:6>KN78kl<EOR>

73 de ik3ogn GFranco

Il 16/03/2022 08:37, Gianfranco via groups.io ha scritto:
About this:
do you see any difference between these two qsos, apart from a minute of difference?
or is the error caused by the four digits instead of the six as in the Logger32?
It seems to me that there is nothing else different

Logger32:
<CALL:5>RL3DD<QSO_DATE:8:D>20220203<TIME_ON:6>092900
<BAND:3>20m<MODE:4>MFSK<SUBMODE:3>FT4<RST_RCVD:3>+00
                           <RST_SENT:3>-10<CONT:2>EU <CQZ:2>16 <DXCC:2>54
<FREQ:9>14.082010<GRIDSQUARE:6>KO85xf <ITUZ:2>29
<OPERATOR:6>IK3OGN<PFX:3>RL3 <LOTW_QSL_SENT:1>Y
                           <LOTW_QSL_RCVD:1>Y <EQSL_QSL_RCVD:1>Y  <STATE:2>MO
                           <K_INDEX:1>5 <TIME_OFF:6>093000 <SFI:3>128 <A_INDEX:2>12
                           <FREQ_RX:9>14.082009 <EOR>

Eqsl:
QSO not found in Logbook: <CALL:5>RL3DD<QSO_DATE:8:D>20220203<TIME_ON:4>0930
<BAND:3>20M<MODE:4>MFSK<SUBMODE:3>FT4<RST_SENT:3>+00
<RST_RCVD:0><QSL_SENT:1>Y<QSL_SENT_VIA:1>E<APP_EQSL_AG:1>Y
                           <GRIDSQUARE:6>KO85sk<EOR>

73 de ik3ogn GFranco


Il 15/03/2022 15:19, Bob ha scritto:
Correction:

It would be helpful to compare the eQSL ADIF records of these two QSOs with an ADIF export from Logger32 of these two QSOs. 73.

On 03/15/2022 8:41 AM Bob <k4cy@...> wrote:

  Actually, it's +/- 30 minutes, and the code that scans the logbook for a matching QSO is the same for eQSL sync, LoTW sync, and QSL sync. But it's easy enough to test/check if it works, simply edit the two QSOs <TIME_ON:6>123456 to match what's in the logbook and try again.

It may be helpful to compare the original eQSL ADIF record with what is in the Logger32 BAD.ADI file. That way we can look for things like the OPERATOR field mismatch.

SeventyThree(s).

PS. Apologies for not answering on Friday, but I did not get your original message sent on Friday, or your follow up today. I did however see Garys reply from this morning,

On 03/14/2022 7:44 PM Gary Hinson <gary@...> wrote:

  Hi Dave.

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?

73
Gary  ZL2iFB

-----Original Message-----
From: hamlogger@groups.io <hamlogger@groups.io> On Behalf Of Dave Sergeant
G3YMC
Sent: Tuesday, 15 March 2022 9:28 am
To: hamlogger@groups.io
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
synchronised eQSL (and LOTW) using a downloaded ADIF file that there
was some tolerance on the times to allow for mismatches. 10 minutes I
recall. This is not happening.

Just downloaded my inbox (I have my own routine to do this) and found
a couple didn't match (from bad.adi):
<CALL:5>G4BUE<BAND:4>160M<MODE:2>CW<QSO_DATE:8>19760214<TIME_ON:4>2128
time in my log 2126
<CALL:5>G4BUE<BAND:3>80M<MODE:2>CW<QSO_DATE:8>20070114<TIME_ON:4>1633
time in my log 1632

Is the time tolerance not working?
http://davesergeant.com














Dave Sergeant G3YMC <dave@...>
 

On 16 Mar 2022 at 9:33, Gianfranco via groups.io wrote:

... is there any difference on this other qso, except 30 seconds?
But there are others and all with a few minutes more or less. (at least
apparently because if there's a difference then it's somewhere else) The
perplexity expressed by Dave G3YMC was therefore more than legitimate
for me.
Thanks GFranco, you are as mystified as me. Since I for a long time
have been updating my eQSL via adif uploads all these QSOs will already
have met the eQSL matching process. Any I find in my eQSL inbox which
don't match are looked at and either rejected or corrected if my log is
wrong. If they pass eQSLs matching process why does L32 complain?

73 Dave G3YMC


http://davesergeant.com


Dino
 

GFranco. Look at the date. You havein eQSL  03032202

73 9A2NO

On 16.03.22. 08:37, Gianfranco via groups.io wrote:
About this:
do you see any difference between these two qsos, apart from a minute of difference?
or is the error caused by the four digits instead of the six as in the Logger32?
It seems to me that there is nothing else different

Logger32:
<CALL:5>RL3DD<QSO_DATE:8:D>20220203<TIME_ON:6>092900
<BAND:3>20m<MODE:4>MFSK<SUBMODE:3>FT4<RST_RCVD:3>+00
                           <RST_SENT:3>-10<CONT:2>EU <CQZ:2>16 <DXCC:2>54
<FREQ:9>14.082010<GRIDSQUARE:6>KO85xf <ITUZ:2>29
<OPERATOR:6>IK3OGN<PFX:3>RL3 <LOTW_QSL_SENT:1>Y
                           <LOTW_QSL_RCVD:1>Y <EQSL_QSL_RCVD:1>Y  <STATE:2>MO
                           <K_INDEX:1>5 <TIME_OFF:6>093000 <SFI:3>128 <A_INDEX:2>12
                           <FREQ_RX:9>14.082009 <EOR>

Eqsl:
QSO not found in Logbook: <CALL:5>RL3DD<QSO_DATE:8:D>20220203<TIME_ON:4>0930
<BAND:3>20M<MODE:4>MFSK<SUBMODE:3>FT4<RST_SENT:3>+00
<RST_RCVD:0><QSL_SENT:1>Y<QSL_SENT_VIA:1>E<APP_EQSL_AG:1>Y
                           <GRIDSQUARE:6>KO85sk<EOR>

73 de ik3ogn GFranco


Il 15/03/2022 15:19, Bob ha scritto:
Correction:

It would be helpful to compare the eQSL ADIF records of these two QSOs with an ADIF export from Logger32 of these two QSOs. 73.

On 03/15/2022 8:41 AM Bob <k4cy@...> wrote:

  Actually, it's +/- 30 minutes, and the code that scans the logbook for a matching QSO is the same for eQSL sync, LoTW sync, and QSL sync. But it's easy enough to test/check if it works, simply edit the two QSOs <TIME_ON:6>123456 to match what's in the logbook and try again.

It may be helpful to compare the original eQSL ADIF record with what is in the Logger32 BAD.ADI file. That way we can look for things like the OPERATOR field mismatch.

SeventyThree(s).

PS. Apologies for not answering on Friday, but I did not get your original message sent on Friday, or your follow up today. I did however see Garys reply from this morning,

On 03/14/2022 7:44 PM Gary Hinson <gary@...> wrote:

  Hi Dave.

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?

73
Gary  ZL2iFB

-----Original Message-----
From: hamlogger@groups.io <hamlogger@groups.io> On Behalf Of Dave Sergeant
G3YMC
Sent: Tuesday, 15 March 2022 9:28 am
To: hamlogger@groups.io
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
synchronised eQSL (and LOTW) using a downloaded ADIF file that there
was some tolerance on the times to allow for mismatches. 10 minutes I
recall. This is not happening.

Just downloaded my inbox (I have my own routine to do this) and found
a couple didn't match (from bad.adi):
<CALL:5>G4BUE<BAND:4>160M<MODE:2>CW<QSO_DATE:8>19760214<TIME_ON:4>2128
time in my log 2126
<CALL:5>G4BUE<BAND:3>80M<MODE:2>CW<QSO_DATE:8>20070114<TIME_ON:4>1633
time in my log 1632

Is the time tolerance not working?
http://davesergeant.com














Dino
 

Sorry . You have 20220203... ??? in year 2202

7 Dino

On 16.03.22. 08:37, Gianfranco via groups.io wrote:
About this:
do you see any difference between these two qsos, apart from a minute of difference?
or is the error caused by the four digits instead of the six as in the Logger32?
It seems to me that there is nothing else different

Logger32:
<CALL:5>RL3DD<QSO_DATE:8:D>20220203<TIME_ON:6>092900
<BAND:3>20m<MODE:4>MFSK<SUBMODE:3>FT4<RST_RCVD:3>+00
                           <RST_SENT:3>-10<CONT:2>EU <CQZ:2>16 <DXCC:2>54
<FREQ:9>14.082010<GRIDSQUARE:6>KO85xf <ITUZ:2>29
<OPERATOR:6>IK3OGN<PFX:3>RL3 <LOTW_QSL_SENT:1>Y
                           <LOTW_QSL_RCVD:1>Y <EQSL_QSL_RCVD:1>Y  <STATE:2>MO
                           <K_INDEX:1>5 <TIME_OFF:6>093000 <SFI:3>128 <A_INDEX:2>12
                           <FREQ_RX:9>14.082009 <EOR>

Eqsl:
QSO not found in Logbook: <CALL:5>RL3DD<QSO_DATE:8:D>20220203<TIME_ON:4>0930
<BAND:3>20M<MODE:4>MFSK<SUBMODE:3>FT4<RST_SENT:3>+00
<RST_RCVD:0><QSL_SENT:1>Y<QSL_SENT_VIA:1>E<APP_EQSL_AG:1>Y
                           <GRIDSQUARE:6>KO85sk<EOR>

73 de ik3ogn GFranco


Il 15/03/2022 15:19, Bob ha scritto:
Correction:

It would be helpful to compare the eQSL ADIF records of these two QSOs with an ADIF export from Logger32 of these two QSOs. 73.

On 03/15/2022 8:41 AM Bob <k4cy@...> wrote:

  Actually, it's +/- 30 minutes, and the code that scans the logbook for a matching QSO is the same for eQSL sync, LoTW sync, and QSL sync. But it's easy enough to test/check if it works, simply edit the two QSOs <TIME_ON:6>123456 to match what's in the logbook and try again.

It may be helpful to compare the original eQSL ADIF record with what is in the Logger32 BAD.ADI file. That way we can look for things like the OPERATOR field mismatch.

SeventyThree(s).

PS. Apologies for not answering on Friday, but I did not get your original message sent on Friday, or your follow up today. I did however see Garys reply from this morning,

On 03/14/2022 7:44 PM Gary Hinson <gary@...> wrote:

  Hi Dave.

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?

73
Gary  ZL2iFB

-----Original Message-----
From: hamlogger@groups.io <hamlogger@groups.io> On Behalf Of Dave Sergeant
G3YMC
Sent: Tuesday, 15 March 2022 9:28 am
To: hamlogger@groups.io
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
synchronised eQSL (and LOTW) using a downloaded ADIF file that there
was some tolerance on the times to allow for mismatches. 10 minutes I
recall. This is not happening.

Just downloaded my inbox (I have my own routine to do this) and found
a couple didn't match (from bad.adi):
<CALL:5>G4BUE<BAND:4>160M<MODE:2>CW<QSO_DATE:8>19760214<TIME_ON:4>2128
time in my log 2126
<CALL:5>G4BUE<BAND:3>80M<MODE:2>CW<QSO_DATE:8>20070114<TIME_ON:4>1633
time in my log 1632

Is the time tolerance not working?
http://davesergeant.com














Dave Sergeant G3YMC <dave@...>
 

Eh??? That is March 2nd 2022.

The two are identical:

logger32 <QSO_DATE:8:D>20220203
eQSL <QSO_DATE:8:D>20220203

73 Dave G3YMC

On 16 Mar 2022 at 11:29, Dino wrote:

Sorry . You have 20220203... ??? in year 2202

7 Dino

http://davesergeant.com


Gianfranco
 

I apologize but this is the last qso in chronological order and I do not find
significant differences apart from the time (one minute and 15 seconds)
well within the tolerance of 10 minutes allowed.

Logger32:
<CALL: 6> OM5ALL <QSO_DATE: 8: D> 20220306 <TIME_ON: 6> 203845 <BAND: 4> 160m <MODE: 3> FT8
<RST_RCVD: 3> -10 <RST_SENT: 3> -12 <CONT: 2> EU <CQZ: 2> 15 <DXCC: 3> 504 <FREQ: 8> 1.842139
<GRIDSQUARE: 4> JN97 <ITUZ: 2> 28 <OPERATOR: 6> IK3OGN <PFX: 3> OM5 <APP_LOGGER32_LoTW: 1> Y
<LOTW_SEND: 1> Y <EQSL_QSL_RCVD: 1> Y <TIME_OFF: 6> 203959 <FREQ_RX: 8> 1.841804 <EOR>

Eqsl:
QSO not found in Logbook:
<CALL:6>OM5ALL<QSO_DATE:8:D>20220306<TIME_ON:4>2040<BAND:4>160M<MODE:3>FT8
<RST_SENT:3>-10<RST_RCVD:0><QSL_SENT:1>Y<QSL_SENT_VIA:1>E<GRIDSQUARE:6>JN97BX<EOR>

It is evident that there is an error somewhere (an invisible character?) but I cannot find it.
Stop, stop.
73 de ik3ogn GFranco

Il 16/03/2022 09:33, Gianfranco via groups.io ha scritto:
... is there any difference on this other qso, except 30 seconds?
But there are others and all with a few minutes more or less. (at least apparently because if there's a difference then it's somewhere else)
The perplexity expressed by Dave G3YMC was therefore more than legitimate for me.

Logger32:
<CALL:5>UT5ED <QSO_DATE:8:D>20220203 <TIME_ON:6>092830 <BAND:3>20m <MODE:4>MFSK
<SUBMODE:3>FT4 <RST_RCVD:3>+07 <RST_SENT:3>-03
<CONT:2>EU <CQZ:2>16 <DXCC:3>288 <FREQ:9>14.082010
<GRIDSQUARE:6>KN78kl <ITUZ:2>29 <OPERATOR:6>IK3OGN
<PFX:3>UT5 <LOTW_QSL_SENT:1>Y <LOTW_QSL_RCVD:1>Y <EQSL_QSL_RCVD:1>Y
<K_INDEX:1>5 <TIME_OFF:6>092900 <SFI:3>128 <A_INDEX:2>12
<FREQ_RX:9>14.082010 <EOR>

Eqsl:
QSO not found in Logbook:
<CALL:5>UT5ED<QSO_DATE:8:D>20220203<TIME_ON:4>0929<BAND:3>20M<MODE:4>MFSK
<SUBMODE:3>FT4<RST_SENT:2>07<RST_RCVD:0><QSL_SENT:1>Y<QSL_SENT_VIA:1>E<QSLMSG:19>TNX
For QSO TU 73!.<APP_EQSL_AG:1>Y<GRIDSQUARE:6>KN78kl<EOR>

73 de ik3ogn GFranco


Il 16/03/2022 08:37, Gianfranco via groups.io ha scritto:
About this:
do you see any difference between these two qsos, apart from a minute of difference?
or is the error caused by the four digits instead of the six as in the Logger32?
It seems to me that there is nothing else different

Logger32:
<CALL:5>RL3DD<QSO_DATE:8:D>20220203<TIME_ON:6>092900
<BAND:3>20m<MODE:4>MFSK<SUBMODE:3>FT4<RST_RCVD:3>+00
                           <RST_SENT:3>-10<CONT:2>EU <CQZ:2>16 <DXCC:2>54
<FREQ:9>14.082010<GRIDSQUARE:6>KO85xf <ITUZ:2>29
<OPERATOR:6>IK3OGN<PFX:3>RL3 <LOTW_QSL_SENT:1>Y
                           <LOTW_QSL_RCVD:1>Y <EQSL_QSL_RCVD:1>Y  <STATE:2>MO
                           <K_INDEX:1>5 <TIME_OFF:6>093000 <SFI:3>128 <A_INDEX:2>12
                           <FREQ_RX:9>14.082009 <EOR>

Eqsl:
QSO not found in Logbook: <CALL:5>RL3DD<QSO_DATE:8:D>20220203<TIME_ON:4>0930
<BAND:3>20M<MODE:4>MFSK<SUBMODE:3>FT4<RST_SENT:3>+00
<RST_RCVD:0><QSL_SENT:1>Y<QSL_SENT_VIA:1>E<APP_EQSL_AG:1>Y
                           <GRIDSQUARE:6>KO85sk<EOR>

73 de ik3ogn GFranco


Il 15/03/2022 15:19, Bob ha scritto:
Correction:

It would be helpful to compare the eQSL ADIF records of these two QSOs with an ADIF export from Logger32 of these two QSOs. 73.

On 03/15/2022 8:41 AM Bob <k4cy@...> wrote:

  Actually, it's +/- 30 minutes, and the code that scans the logbook for a matching QSO is the same for eQSL sync, LoTW sync, and QSL sync. But it's easy enough to test/check if it works, simply edit the two QSOs <TIME_ON:6>123456 to match what's in the logbook and try again.

It may be helpful to compare the original eQSL ADIF record with what is in the Logger32 BAD.ADI file. That way we can look for things like the OPERATOR field mismatch.

SeventyThree(s).

PS. Apologies for not answering on Friday, but I did not get your original message sent on Friday, or your follow up today. I did however see Garys reply from this morning,

On 03/14/2022 7:44 PM Gary Hinson <gary@...> wrote:

  Hi Dave.

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?

73
Gary  ZL2iFB

-----Original Message-----
From: hamlogger@groups.io <hamlogger@groups.io> On Behalf Of Dave Sergeant
G3YMC
Sent: Tuesday, 15 March 2022 9:28 am
To: hamlogger@groups.io
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
synchronised eQSL (and LOTW) using a downloaded ADIF file that there
was some tolerance on the times to allow for mismatches. 10 minutes I
recall. This is not happening.

Just downloaded my inbox (I have my own routine to do this) and found
a couple didn't match (from bad.adi):
<CALL:5>G4BUE<BAND:4>160M<MODE:2>CW<QSO_DATE:8>19760214<TIME_ON:4>2128
time in my log 2126
<CALL:5>G4BUE<BAND:3>80M<MODE:2>CW<QSO_DATE:8>20070114<TIME_ON:4>1633
time in my log 1632

Is the time tolerance not working?
http://davesergeant.com


















Gianfranco
 

Dave, you're right to complain.
I no longer pay attention to errors of this type but I do like you ... I just correct them.
But now that the problem has emerged, I wanted to give my opinion.
Thanks for the attention.
73 de ik3ogn GFranco
 


Il 16/03/2022 10:28, Dave Sergeant G3YMC ha scritto:

On 16 Mar 2022 at 9:33, Gianfranco via groups.io wrote:

... is there any difference on this other qso, except 30 seconds?
But there are others and all with a few minutes more or less. (at least
apparently because if there's a difference then it's somewhere else) The
perplexity expressed by Dave G3YMC was therefore more than legitimate
for me.

Thanks GFranco, you are as mystified as me. Since I for a long time 
have been updating my eQSL via adif uploads all these QSOs will already 
have met the eQSL matching process. Any I find in my eQSL inbox which 
don't match are looked at and either rejected or corrected if my log is 
wrong. If they pass eQSLs matching process why does L32 complain?

73 Dave G3YMC


http://davesergeant.com








Bob
 

I made a dummy Logbook and imported the Logger32 ADIF record. I then made another ADIF file with your eQSL ADIF record. This is the result. SeventyThree(s)


On 03/16/2022 3:37 AM Gianfranco via groups.io <tog-franco@...> wrote:


About this:
do you see any difference between these two qsos, apart from a minute of
difference?
or is the error caused by the four digits instead of the six as in the
Logger32?
It seems to me that there is nothing else different

Logger32:
<CALL:5>RL3DD<QSO_DATE:8:D>20220203<TIME_ON:6>092900
<BAND:3>20m<MODE:4>MFSK<SUBMODE:3>FT4<RST_RCVD:3>+00
                           <RST_SENT:3>-10<CONT:2>EU <CQZ:2>16 <DXCC:2>54
<FREQ:9>14.082010<GRIDSQUARE:6>KO85xf <ITUZ:2>29
                           <OPERATOR:6>IK3OGN<PFX:3>RL3 <LOTW_QSL_SENT:1>Y
                           <LOTW_QSL_RCVD:1>Y <EQSL_QSL_RCVD:1>Y 
<STATE:2>MO
                           <K_INDEX:1>5 <TIME_OFF:6>093000 <SFI:3>128
<A_INDEX:2>12
                           <FREQ_RX:9>14.082009 <EOR>

Eqsl:
QSO not found in Logbook:
<CALL:5>RL3DD<QSO_DATE:8:D>20220203<TIME_ON:4>0930
<BAND:3>20M<MODE:4>MFSK<SUBMODE:3>FT4<RST_SENT:3>+00
<RST_RCVD:0><QSL_SENT:1>Y<QSL_SENT_VIA:1>E<APP_EQSL_AG:1>Y
                           <GRIDSQUARE:6>KO85sk<EOR>

73 de ik3ogn GFranco


Il 15/03/2022 15:19, Bob ha scritto:
Correction:

It would be helpful to compare the eQSL ADIF records of these two QSOs with an ADIF export from Logger32 of these two QSOs. 73.

On 03/15/2022 8:41 AM Bob <k4cy@...> wrote:


Actually, it's +/- 30 minutes, and the code that scans the logbook for a matching QSO is the same for eQSL sync, LoTW sync, and QSL sync. But it's easy enough to test/check if it works, simply edit the two QSOs <TIME_ON:6>123456 to match what's in the logbook and try again.

It may be helpful to compare the original eQSL ADIF record with what is in the Logger32 BAD.ADI file. That way we can look for things like the OPERATOR field mismatch.

SeventyThree(s).

PS. Apologies for not answering on Friday, but I did not get your original message sent on Friday, or your follow up today. I did however see Garys reply from this morning,

On 03/14/2022 7:44 PM Gary Hinson <gary@...> wrote:


Hi Dave.

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?

73
Gary ZL2iFB

-----Original Message-----
From: hamlogger@groups.io <hamlogger@groups.io> On Behalf Of Dave Sergeant
G3YMC
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
synchronised eQSL (and LOTW) using a downloaded ADIF file that there
was some tolerance on the times to allow for mismatches. 10 minutes I
recall. This is not happening.

Just downloaded my inbox (I have my own routine to do this) and found
a couple didn't match (from bad.adi):
<CALL:5>G4BUE<BAND:4>160M<MODE:2>CW<QSO_DATE:8>19760214<TIME_ON:4>2128
time in my log 2126
<CALL:5>G4BUE<BAND:3>80M<MODE:2>CW<QSO_DATE:8>20070114<TIME_ON:4>1633
time in my log 1632

Is the time tolerance not working?



















Bob
 

Same as before. Imported the QSO, made a dummy eQSL ADIF file (I had to add the <EOR>) and ran eQSL sync. Same result. SeventyThree(s).


On 03/16/2022 4:33 AM Gianfranco via groups.io <tog-franco@...> wrote:


... is there any difference on this other qso, except 30 seconds?
But there are others and all with a few minutes more or less. (at least
apparently because if there's a difference then it's somewhere else)
The perplexity expressed by Dave G3YMC was therefore more than
legitimate for me.

Logger32:
<CALL:5>UT5ED <QSO_DATE:8:D>20220203 <TIME_ON:6>092830 <BAND:3>20m
<MODE:4>MFSK
<SUBMODE:3>FT4 <RST_RCVD:3>+07 <RST_SENT:3>-03
<CONT:2>EU <CQZ:2>16 <DXCC:3>288 <FREQ:9>14.082010
<GRIDSQUARE:6>KN78kl <ITUZ:2>29 <OPERATOR:6>IK3OGN
<PFX:3>UT5 <LOTW_QSL_SENT:1>Y <LOTW_QSL_RCVD:1>Y <EQSL_QSL_RCVD:1>Y
<K_INDEX:1>5 <TIME_OFF:6>092900 <SFI:3>128 <A_INDEX:2>12
<FREQ_RX:9>14.082010 <EOR>

Eqsl:
QSO not found in Logbook:
<CALL:5>UT5ED<QSO_DATE:8:D>20220203<TIME_ON:4>0929<BAND:3>20M<MODE:4>MFSK
<SUBMODE:3>FT4<RST_SENT:2>07<RST_RCVD:0><QSL_SENT:1>Y<QSL_SENT_VIA:1>E<QSLMSG:19>TNX

For QSO TU 73!.<APP_EQSL_AG:1>Y<GRIDSQUARE:6>KN78kl<EOR>

73 de ik3ogn GFranco


Il 16/03/2022 08:37, Gianfranco via groups.io ha scritto:
About this:
do you see any difference between these two qsos, apart from a minute
of difference?
or is the error caused by the four digits instead of the six as in the
Logger32?
It seems to me that there is nothing else different

Logger32:
<CALL:5>RL3DD<QSO_DATE:8:D>20220203<TIME_ON:6>092900
<BAND:3>20m<MODE:4>MFSK<SUBMODE:3>FT4<RST_RCVD:3>+00
                           <RST_SENT:3>-10<CONT:2>EU <CQZ:2>16 <DXCC:2>54
<FREQ:9>14.082010<GRIDSQUARE:6>KO85xf <ITUZ:2>29
<OPERATOR:6>IK3OGN<PFX:3>RL3 <LOTW_QSL_SENT:1>Y
                           <LOTW_QSL_RCVD:1>Y <EQSL_QSL_RCVD:1>Y 
<STATE:2>MO
                           <K_INDEX:1>5 <TIME_OFF:6>093000 <SFI:3>128
<A_INDEX:2>12
                           <FREQ_RX:9>14.082009 <EOR>

Eqsl:
QSO not found in Logbook:
<CALL:5>RL3DD<QSO_DATE:8:D>20220203<TIME_ON:4>0930
<BAND:3>20M<MODE:4>MFSK<SUBMODE:3>FT4<RST_SENT:3>+00
<RST_RCVD:0><QSL_SENT:1>Y<QSL_SENT_VIA:1>E<APP_EQSL_AG:1>Y
                           <GRIDSQUARE:6>KO85sk<EOR>

73 de ik3ogn GFranco


Il 15/03/2022 15:19, Bob ha scritto:
Correction:

It would be helpful to compare the eQSL ADIF records of these two
QSOs with an ADIF export from Logger32 of these two QSOs. 73.

On 03/15/2022 8:41 AM Bob <k4cy@...> wrote:

  Actually, it's +/- 30 minutes, and the code that scans the logbook
for a matching QSO is the same for eQSL sync, LoTW sync, and QSL
sync. But it's easy enough to test/check if it works, simply edit
the two QSOs <TIME_ON:6>123456 to match what's in the logbook and
try again.

It may be helpful to compare the original eQSL ADIF record with what
is in the Logger32 BAD.ADI file. That way we can look for things
like the OPERATOR field mismatch.

SeventyThree(s).

PS. Apologies for not answering on Friday, but I did not get your
original message sent on Friday, or your follow up today. I did
however see Garys reply from this morning,

On 03/14/2022 7:44 PM Gary Hinson <gary@...> wrote:

  Hi Dave.

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?

73
Gary  ZL2iFB

-----Original Message-----
From: hamlogger@groups.io <hamlogger@groups.io> On Behalf Of Dave
Sergeant
G3YMC
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
synchronised eQSL (and LOTW) using a downloaded ADIF file that there
was some tolerance on the times to allow for mismatches. 10 minutes I
recall. This is not happening.

Just downloaded my inbox (I have my own routine to do this) and found
a couple didn't match (from bad.adi):
<CALL:5>G4BUE<BAND:4>160M<MODE:2>CW<QSO_DATE:8>19760214<TIME_ON:4>2128

time in my log 2126
<CALL:5>G4BUE<BAND:3>80M<MODE:2>CW<QSO_DATE:8>20070114<TIME_ON:4>1633
time in my log 1632

Is the time tolerance not working?

























Bob
 

Same again. This is boreing. SeventyThree(s).

On 03/16/2022 6:57 AM Gianfranco via groups.io <tog-franco@...> wrote:


I apologize but this is the last qso in chronological order and I do not
find
significant differences apart from the time (one minute and 15 seconds)
well within the tolerance of 10 minutes allowed.

Logger32:
<CALL: 6> OM5ALL <QSO_DATE: 8: D> 20220306 <TIME_ON: 6> 203845 <BAND: 4>
160m <MODE: 3> FT8
<RST_RCVD: 3> -10 <RST_SENT: 3> -12 <CONT: 2> EU <CQZ: 2> 15 <DXCC: 3>
504 <FREQ: 8> 1.842139
<GRIDSQUARE: 4> JN97 <ITUZ: 2> 28 <OPERATOR: 6> IK3OGN <PFX: 3> OM5
<APP_LOGGER32_LoTW: 1> Y
<LOTW_SEND: 1> Y <EQSL_QSL_RCVD: 1> Y <TIME_OFF: 6> 203959 <FREQ_RX: 8>
1.841804 <EOR>

Eqsl:
QSO not found in Logbook:
<CALL:6>OM5ALL<QSO_DATE:8:D>20220306<TIME_ON:4>2040<BAND:4>160M<MODE:3>FT8
<RST_SENT:3>-10<RST_RCVD:0><QSL_SENT:1>Y<QSL_SENT_VIA:1>E<GRIDSQUARE:6>JN97BX<EOR>

It is evident that there is an error somewhere (an invisible character?)
but I cannot find it.
Stop, stop.
73 de ik3ogn GFranco


Il 16/03/2022 09:33, Gianfranco via groups.io ha scritto:
... is there any difference on this other qso, except 30 seconds?
But there are others and all with a few minutes more or less. (at
least apparently because if there's a difference then it's somewhere
else)
The perplexity expressed by Dave G3YMC was therefore more than
legitimate for me.

Logger32:
<CALL:5>UT5ED <QSO_DATE:8:D>20220203 <TIME_ON:6>092830 <BAND:3>20m
<MODE:4>MFSK
<SUBMODE:3>FT4 <RST_RCVD:3>+07 <RST_SENT:3>-03
<CONT:2>EU <CQZ:2>16 <DXCC:3>288 <FREQ:9>14.082010
<GRIDSQUARE:6>KN78kl <ITUZ:2>29 <OPERATOR:6>IK3OGN
<PFX:3>UT5 <LOTW_QSL_SENT:1>Y <LOTW_QSL_RCVD:1>Y <EQSL_QSL_RCVD:1>Y
<K_INDEX:1>5 <TIME_OFF:6>092900 <SFI:3>128 <A_INDEX:2>12
<FREQ_RX:9>14.082010 <EOR>

Eqsl:
QSO not found in Logbook:
<CALL:5>UT5ED<QSO_DATE:8:D>20220203<TIME_ON:4>0929<BAND:3>20M<MODE:4>MFSK
<SUBMODE:3>FT4<RST_SENT:2>07<RST_RCVD:0><QSL_SENT:1>Y<QSL_SENT_VIA:1>E<QSLMSG:19>TNX

For QSO TU 73!.<APP_EQSL_AG:1>Y<GRIDSQUARE:6>KN78kl<EOR>

73 de ik3ogn GFranco


Il 16/03/2022 08:37, Gianfranco via groups.io ha scritto:
About this:
do you see any difference between these two qsos, apart from a minute
of difference?
or is the error caused by the four digits instead of the six as in
the Logger32?
It seems to me that there is nothing else different

Logger32:
<CALL:5>RL3DD<QSO_DATE:8:D>20220203<TIME_ON:6>092900
<BAND:3>20m<MODE:4>MFSK<SUBMODE:3>FT4<RST_RCVD:3>+00
                           <RST_SENT:3>-10<CONT:2>EU <CQZ:2>16
<DXCC:2>54
<FREQ:9>14.082010<GRIDSQUARE:6>KO85xf <ITUZ:2>29
<OPERATOR:6>IK3OGN<PFX:3>RL3 <LOTW_QSL_SENT:1>Y
                           <LOTW_QSL_RCVD:1>Y <EQSL_QSL_RCVD:1>Y 
<STATE:2>MO
                           <K_INDEX:1>5 <TIME_OFF:6>093000 <SFI:3>128
<A_INDEX:2>12
                           <FREQ_RX:9>14.082009 <EOR>

Eqsl:
QSO not found in Logbook:
<CALL:5>RL3DD<QSO_DATE:8:D>20220203<TIME_ON:4>0930
<BAND:3>20M<MODE:4>MFSK<SUBMODE:3>FT4<RST_SENT:3>+00
<RST_RCVD:0><QSL_SENT:1>Y<QSL_SENT_VIA:1>E<APP_EQSL_AG:1>Y
                           <GRIDSQUARE:6>KO85sk<EOR>

73 de ik3ogn GFranco


Il 15/03/2022 15:19, Bob ha scritto:
Correction:

It would be helpful to compare the eQSL ADIF records of these two
QSOs with an ADIF export from Logger32 of these two QSOs. 73.

On 03/15/2022 8:41 AM Bob <k4cy@...> wrote:

  Actually, it's +/- 30 minutes, and the code that scans the
logbook for a matching QSO is the same for eQSL sync, LoTW sync,
and QSL sync. But it's easy enough to test/check if it works,
simply edit the two QSOs <TIME_ON:6>123456 to match what's in the
logbook and try again.

It may be helpful to compare the original eQSL ADIF record with
what is in the Logger32 BAD.ADI file. That way we can look for
things like the OPERATOR field mismatch.

SeventyThree(s).

PS. Apologies for not answering on Friday, but I did not get your
original message sent on Friday, or your follow up today. I did
however see Garys reply from this morning,

On 03/14/2022 7:44 PM Gary Hinson <gary@...> wrote:

  Hi Dave.

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?

73
Gary  ZL2iFB

-----Original Message-----
From: hamlogger@groups.io <hamlogger@groups.io> On Behalf Of Dave
Sergeant
G3YMC
Sent: Tuesday, 15 March 2022 9:28 am
To: hamlogger@groups.io
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
synchronised eQSL (and LOTW) using a downloaded ADIF file that there
was some tolerance on the times to allow for mismatches. 10
minutes I
recall. This is not happening.

Just downloaded my inbox (I have my own routine to do this) and
found
a couple didn't match (from bad.adi):
<CALL:5>G4BUE<BAND:4>160M<MODE:2>CW<QSO_DATE:8>19760214<TIME_ON:4>2128

time in my log 2126
<CALL:5>G4BUE<BAND:3>80M<MODE:2>CW<QSO_DATE:8>20070114<TIME_ON:4>1633

time in my log 1632

Is the time tolerance not working?
http://davesergeant.com





















Dave Sergeant G3YMC <dave@...>
 

Maybe boring to you Bo but both myself and GFranco and posibly others
are seeing this problem. Honestly we are not making it up, it is very
very real. Something different between our systems, configuration and
settings maybe? For information I am running L32 on Windows 11.

73 Dave G3YMC

On 16 Mar 2022 at 16:45, Bob wrote:

Same again. This is boreing. SeventyThree(s).

http://davesergeant.com