Date   

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


Re: new soft for #ft8 / #cluster / #pskreport / #dx / auto-spot #hamradio #wsjtx #wsjtz #jtdx #ft8

Gary Hinson <Gary@...>
 

Hi Eduardo.

 

Although your posting may be a little off-topic, it inspires the idea of perhaps incorporating an encoding/decoding soft modem ‘core’ within Logger32, giving Logger32 more direct control over the RF communications without the constraints of JTDX, WSJT-X, MMVARI etc.

 

I imagine the soft modem would purely and efficiently handle the timing, message generation and formatting, audio generation/modulation, audio demodulation and message unpacking for FT8 (initially at least, maybe other digimodes in time), leaving Logger32 to handle all the rest, the higher-level functions e.g. the user interface, callsign lookups, rig control, logging, alerting, spotting, propagation prediction, mapping, QSLing, awards tracking, satellite tracking …

 

The modem and logging programs might communicate/interoperate through an Application Program Interface, using structured messages with specified formats (e.g. ADIF for QSO info?) and protocols (ideally networkable for multi-computer shacks and remote operation) for specified services (e.g. ‘Encode the following message in FT8 and generate it on the next even cycle: …’ .  If that API was open, it might link other modems (e.g. for CW, RTTY, PSK, digital voice …) and other logging programs (e.g. N1MM+ …), allowing us to mix-n-match whatever best suits our purposes while encouraging further innovation (e.g. dedicated, specialised modem hardware for better performance, variant/novel digimodes, cloud-based logging, multi-band/multi-station coordination, dynamic frequency and power management for path optimisation and QRM evasion, negotiated QSYs, net control, message handling, updated backwards-compatible versions of the API itself …).

 

73

Gary  ZL2iFB

 

From: hamlogger@groups.io <hamlogger@groups.io> On Behalf Of Eduardo Castillo (LU9DCE)
Sent: Sunday, 13 March 2022 2:30 am
To: hamlogger@groups.io
Subject: Re: [hamlogger] new soft for #ft8 / #cluster / #pskreport / #dx / auto-spot #hamradio #wsjtx #wsjtz #jtdx

 

# master-ft8
Soft Hamradio Powershell
 
the source code and the binary for windows (exe) is in
 
-->  https://www.pling.com/p/1731640/
 
This program is made in powershell for radio amateurs it is to work with ft8
 
* Autodetect if you use jtdx or wsjt
* If you make a contact, it uploads it to the cluster and informs you on screen with a text and alarm
* Has pskreports will show you the stations that listen to you
* It has a read-only cluster of different bands
* Shows you the last contacts made
 
I share the code .. so you can modify it to your liking 
 
if you improve it you can share it or send me a copy to
 
hellocodelinux@... to see the improvements
 
I would like someone to help me improve it
 
you need this
 
VC_redist.x64.exe / VC_redist.x86.exe
 
this program uses ncat to upload the dx made to the cluster
 
when you run it for the first time it will take care of downloading ncat automatically


Re: new soft for #ft8 / #cluster / #pskreport / #dx / auto-spot #hamradio #wsjtx #wsjtz #jtdx #ft8

Eduardo Castillo (LU9DCE) <hellocodebsd@...>
 

# master-ft8
Soft Hamradio Powershell

the source code and the binary for windows (exe) is in

-->  https://www.pling.com/p/1731640/

This program is made in powershell for radio amateurs it is to work with ft8

* Autodetect if you use jtdx or wsjt
* If you make a contact, it uploads it to the cluster and informs you on screen with a text and alarm
* Has pskreports will show you the stations that listen to you
* It has a read-only cluster of different bands
* Shows you the last contacts made

I share the code .. so you can modify it to your liking 

if you improve it you can share it or send me a copy to

hellocodelinux@... to see the improvements

I would like someone to help me improve it

you need this

VC_redist.x64.exe / VC_redist.x86.exe

this program uses ncat to upload the dx made to the cluster

when you run it for the first time it will take care of downloading ncat automatically


Re: focus stealing

Eduardo Castillo (LU9DCE) <hellocodebsd@...>
 

here it is the other way around the one that draws the focus is logger with active cherry


Re: Cherry-picking help

Filipe Lopes
 

It is better indeed. 

Thank you.
Filipe CT1ILT

1521 - 1540 of 89327