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?

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

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

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

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).

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

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

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

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

... 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

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

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

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

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

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

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