Date   

Auto-update 4.0.292 is on-line ...

Bob
 

v4.0.292 is a maintenance release. Issues addressed include:

Not all fields were transferred when parallel logging.
Under certain conditions a simple check of QSO B4 returned incorrect results.
Fixed problem with QSO delete/modify when using the N1MM bridge and parallel logging was enabled.
Fixed a problem with the CQDXFIELD award calculations.
Eye candy changes made to the TCP Server window.
A new/updated FauxCNTY.CSV file included in the update package.

73.


Re: FT8Summary

John Munton - G7SSE
 

We all have them kind of moments Barry!

Glad the reply helped you out. 

Enjoy the "Famous G" if you have a tipple (quite partial to a drop myself)

73
John - G7SSE

------ Original Message ------
From: "Barry GM4GIF" <gm4gif@...>
Sent: 15/03/2022 16:28:22
Subject: Re: [hamlogger] FT8Summary

Hi Aki
My problem solved hi,
The Dxcc award table wasn’t showing any FT8 contacts at all, the reason being that I didn’t have a Y in the Stats column of the Band/Mode Table against FT8 and also in the Database Maintenance setup I  didn’t have FT8 checked in the Digital column. 

I spotted an earlier reply from John/G7SSE which triggered one of those “oh, of course you (expletive deleted) idiot!!!”  moments, so THANKS John.

Now off to a darkened room with a tot of Bob’s favourite tipple hi.
73
Barry/gm4gif




--
73, John - G7SSE


Re: FT8Summary

Gary Hinson <Gary@...>
 

 

From: hamlogger@groups.io <hamlogger@groups.io> On Behalf Of Barry GM4GIF
Sent: Wednesday, 16 March 2022 5:28 am
To: hamlogger@groups.io
Subject: Re: [hamlogger] FT8Summary

 

Hi Aki

My problem solved hi,

The Dxcc award table wasn’t showing any FT8 contacts at all, the reason being that I didn’t have a Y in the Stats column of the Band/Mode Table against FT8 and also in the Database Maintenance setup I  didn’t have FT8 checked in the Digital column. 

 

I spotted an earlier reply from John/G7SSE which triggered one of those “oh, of course you (expletive deleted) idiot!!!”  moments, so THANKS John.

 

Now off to a darkened room with a tot of Bob’s favourite tipple hi.

73

Barry/gm4gif

 

 

 


Re: eQSL Synchronise from ADIF

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


Re: FT8Summary

Barry GM4GIF
 

Hi Aki
My problem solved hi,
The Dxcc award table wasn’t showing any FT8 contacts at all, the reason being that I didn’t have a Y in the Stats column of the Band/Mode Table against FT8 and also in the Database Maintenance setup I  didn’t have FT8 checked in the Digital column. 

I spotted an earlier reply from John/G7SSE which triggered one of those “oh, of course you (expletive deleted) idiot!!!”  moments, so THANKS John.

Now off to a darkened room with a tot of Bob’s favourite tipple hi.
73
Barry/gm4gif




Re: eQSL Synchronise from ADIF

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









Re: FT8Summary

Barry GM4GIF
 

Thanks Aki
73 de Barry/gm4gif


Re: eQSL Synchronise from ADIF

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


Re: eQSL Synchronise from ADIF

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









Re: FT8Summary

ja1nlx
 

and Logger32 award table shows everything you need ?


73 de aki
JA1NLX

------ Original Message ------
From: "ja1nlx via groups.io" <ayoshida0205@...>
To: "Hanlogger" <hamlogger@groups.io>
Sent: 2022/03/15 20:02:22
Subject: Re: [hamlogger] FT8Summary

Barry

I need to modify own DXCC table which includes 350 country name.
It is almost difficult for me, sorry.

73 de aki
JA1NLX

------ Original Message ------
From: "Barry GM4GIF" <gm4gif@...>
Sent: 2022/03/15 19:58:16
Subject: Re: [hamlogger] FT8Summary

Aki,
A bit obvious, but that should be SummaryFT8 of course, a bit early in the morning here, hi.
Cheers
Barry


Re: FT8Summary

ja1nlx
 

Barry

I need to modify own DXCC table which includes 350 country name.
It is almost difficult for me, sorry.

73 de aki
JA1NLX

------ Original Message ------
From: "Barry GM4GIF" <gm4gif@...>
Sent: 2022/03/15 19:58:16
Subject: Re: [hamlogger] FT8Summary

Aki,
A bit obvious, but that should be SummaryFT8 of course, a bit early in the morning here, hi.
Cheers
Barry


Re: FT8Summary

Barry GM4GIF
 

Aki,
A bit obvious, but that should be SummaryFT8 of course, a bit early in the morning here, hi.
Cheers
Barry


FT8Summary

Barry GM4GIF
 

Hi Aki
Seeing your post reminded me ….
I’ve been using your FB utility FT8Summary, I wonder, would it be possible to display the Country Name as well as the Prefix?
Anyway, hope you’re keeping well, 
Thanks es 73
Barry / gm4gif


Re: eQSL Synchronise from ADIF

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






Re: eQSL Synchronise from ADIF

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


Re: eQSL Synchronise from ADIF

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


Re: ADIF and the ENTRY PaneBob

Bob
 

When exporting an ADIF file, you have the option to rename USER fields. So, for example, you could export USER_1 as <APP_POTA:6>123456. SeventyThree(s).

On 03/14/2022 2:57 PM Bob Boetcher <infosys4u@...> wrote:


ok, thanks, looks like that's what was happening.  Do you know if these user defined fields will, be formatted in ADIF format, or are they for just local fields, for each operator/ham?


Re: ADIF and the ENTRY PaneBob

Bob Boetcher
 

ok, thanks, looks like that's what was happening.  Do you know if these user defined fields will, be formatted in ADIF format, or are they for just local fields, for each operator/ham?


Re: ADIF and the ENTRY Pane

Bob
 


If you do not see USER_1, USER_2, or USER_3 in the ADIF combo box, they are already assigned on of the data entry fields. Go through the seven fields one by one and you'll find where they are allocated. SeventyThre(s).


On 03/14/2022 12:21 PM Bob Boetcher <infosys4u@...> wrote:


Hi,
I was wondering, is it possible to and ADIF fields to the User defined fields in the "entry pane"?  I would like to add a POTA field but there are no USER_!, available in the ADIF pull-down menu. This is all in reference to the "setup user fields" of the Entry Pane.
Tnx,
Bob


ADIF and the ENTRY Pane

Bob Boetcher
 

Hi,
I was wondering, is it possible to and ADIF fields to the User defined fields in the "entry pane"?  I would like to add a POTA field but there are no USER_!, available in the ADIF pull-down menu. This is all in reference to the "setup user fields" of the Entry Pane.
Tnx,
Bob

2301 - 2320 of 90111