Date   
ZC4

Bill - AA4M
 

Hello,

I've been inactive a LONG time.  With that in mind, I just saw in my DX Progress Report that "U K Bases on Cyprus (ZC4)" is no longer tagged as a deleted country.  Is this right?

73, Bill - AA4M

Re: IOTA Dropdown?

Dave AA6YQ
 

+ AA6YQ comments below

I am new to DXLab

+ Welcome, Al!

and have a question regarding entering an IOTA number when entering the QSO data. Is there a Dropdown with the IOTA numbers, OR do I just enter the IOTA number as I hear it, and the program does the rest for tracking.

+ There are 1190 entries in DXKeeper's IOTA database, so a "dropdown" selector would be unwieldy. Simply type in the 6-character IOTA designator in CC-NNN form, where CC is a continent abbreviation and NNN is a 3-digit number.

+ You'll find 4 articles specific to IOTA award tracking here:

<https://www.dxlabsuite.com/dxlabwiki/IOTAAwardTracking>

+ Before tackling these, I suggest that you start with

<https://www.dxlabsuite.com/dxlabwiki/GettingStarted>

+ and

<https://www.dxlabsuite.com/dxlabwiki/Logging>

+ if you haven't already reviewed these articles.


Assuming there is a IOTA database can I enter the new numbers as they surface?

+ DXLab's IOTA database is managed by Dick N3XRU; you can obtain the latest version (1.27) via the Databases tab of DXView's Configuration window, as described here:

<https://www.dxlabsuite.com/dxlabwiki/InstallIotaDatabase>

+ The IOTA database 1.2.7 announcement is here:

<https://groups.io/g/DXLab/message/186459>

+ To query the IOTA database, type an IOTA designator into the IOTA box in DXView's Main window, and then strike the Enter key.

+ If you want to maintain your own IOTA database, you can do so by terminating DXView and DXKeeper, and then opening the file IOTA.mdb in DXView's Databases folder with Microsoft Access.

73,

Dave, AA6YQ

IOTA Dropdown?

Al Bailey (K8SIX)
 

Good Evening,

I am new to DXLab and have a question regarding entering an IOTA number when entering the QSO data. Is there a Dropdown with the IOTA numbers, OR do I just enter the IOTA number as I hear it, and the program does the rest for tracking. Assuming there is a IOTA database can I enter the new numbers as they surface?

 

BTW a shout out to Larry as I know he is watching. 😊

 

73 de Al, K8SIX

 

Re: WELCUM ME IN BLUE

Dave AA6YQ
 

+ AA6YQ comment sbelow


On Tue, Sep 3, 2019 at 04:38 PM, <WF3W@...> wrote:

My name Phil, call sign WF3W.
 
My 1st flush of joy in finding who-needs-HRD has been, sum what, modified.
 
Trying very hard to figure how scanning between, just, 2 freq can replace scanning a stretch of freq, I xperienced TWO Blue Screens of Death in < 2 minutes.
 
In their infinite mercy, MS [the "S" does NOT stand for SOFT], left a, surprisingly coherent error msg, if not a complete mystery:
 
DRVER POWER STATE FAILURE
 
May I attempt to tempt ur diagnostic skill and xplain why a driver needs power?

+ A device driver may track or manage the power consumption of its associated device.

+ My advice is to

1. check the Windows Event Logs to identify the root cause of the crashes

2. determine which device driver is emitting that message

3. contact the supplier of the device driver to seek technical support

+ See

<https://www.dxlabsuite.com/dxlabwiki/CheckingWindowsEventLogs>

     73,

            Dave, AA6YQ

WELCUM ME IN BLUE

Phil, WF3W
 

Hello all DXLers [?],
 
My name Phil, call sign WF3W.
 
My 1st flush of joy in finding who-needs-HRD has been, sum what, modified.
 
Trying very hard to figure how scanning between, just, 2 freq can replace scanning a stretch of freq, I xperienced TWO Blue Screens of Death in < 2 minutes.
 
In their infinite mercy, MS [the "S" does NOT stand for SOFT], left a, surprisingly coherent error msg, if not a complete mystery:
 
DRVER POWER STATE FAILURE
 
May I attempt to tempt ur diagnostic skill and xplain why a driver needs power?
 
73
 
Phil
 


Re: Dx Keeper Log too Big getting callsign mismtch error??

Dave AA6YQ
 

+ AA6YQ comments below

On Tue, Sep 3, 2019 at 12:40 PM, wb2kfh wrote:

I am getting a callsign Mismatch error says callsign does not match as it appears my log is still on the prior call worked
It is worse on FT 4 as the contacts come quicker
This is the best logging program and features I have used since starting to computer logging in 1996 Thank you Dave and your team!
I experimented and started last night by using a new log and with about 100 contacts in the log it seems much better
Has anyone else had these issues of mismatched callsigns when trying to use JT Alert for auto logging?

Any suggestions other than whats in the help file , manual or blog
I have almost 750,000 QSO’s in the log I am having issues with since 1996 includes contests

+ What is the exact text of the "callsign Mismatch error" message ?

+ Which application is displaying this message?

        73,

                Dave, AA6YQ

 

Re: DXKeeper realtime tracking for Marathon is blank

Dave AA6YQ
 

+ AA6YQ comments below

On Tue, Sep 3, 2019 at 12:07 PM, Catherine James wrote:

I didn't realize that this had to be specifically set, as I don't do satellite or EME work

+ "Include QSOs with no prop" need only be set if your logged QSOs don't specify a "Prop Mode" item. You can specify a default propagation mode on DXKeeper's Configuration window's Defaults tab; I have my default propagation mode set to F2, but I change it when I'm working an Es (sporadic E) or TEP (trans-equatorial) opening. Logging this information can be quite helpful when sometime down-the-road you're staking out a needed DX station.

       73,

            Dave, AA6YQ

 

Dx Keeper Log too Big getting callsign mismtch error??

wb2kfh
 

Sent from my iPhone 8P

On Sep 3, 2019, at 1:18 PM, Dave AA6YQ <@AA6YQ> wrote:

I have been having Logging errors with DxKeeper using WSJT-X with JT Alert. i have tried all the suggestions on the group blog here and am hypothesizing that my log ois too big and taking too long to search details
I am getting a callsign Mismatch error says callsign does not match as it appears my log is still on the prior call worked
It is worse on FT 4 as the contacts come quicker
This is the best logging program and features I have used since starting to computer logging in 1996 Thank you Dave and your team!
I experimented and started last night by using a new log and with about 100 contacts in the log it seems much better
Has anyone else had these issues of mismatched callsigns when trying to use JT Alert for auto logging?

Any suggestions other than whats in the help file , manual or blog
I have almost 750,000 QSO’s in the log I am having issues with since 1996 includes contests

Thanks
Barry
N2BJ
n2bj@...

Re: DXKeeper realtime tracking for Marathon is blank

Catherine James
 

Thank you both.  I will check "include QSOs with no prop", and that will probably fix it. I didn't realize that this had to be specifically set, as I don't do satellite or EME work.

Re: DXKeeper realtime tracking for Marathon is blank

Dave AA6YQ
 

+ AA6YQ comments below

What step have I omitted? The other realtime reports work fine. I have plenty of contacts logged in DXKeeper that should qualify.
In my settings of DXKeeper for Marathon, in "Marathon Bands & Modes" I have only three boxes checked: Mixed, "Include QSOs with no prop", and "Realtime Award Progress. " All of the other band and mode checkboxes are left blank. My reports are working fine.

+ The CQ DX Marathon contest requires all QSOs to be "terrestrial" -- e.g. no satellite or EME QSOs. DXKeeper enforces this rule by ignoring QSOs that do not specify a terrestrial mode of propagation in their "Prop Mode" items. If your logged QSOs do not specify a "Prop Mode" but were all made using terrestrial propagation, then check the "Include QSOs with no prop" box, as John K8AJS suggests above.

+ Logged QSOs whose "power" items exceed the "Max TX Power" you've specified in the "Marathon Bands & Modes" panel will also be ignored.

73,

Dave, AA6YQ

Re: eQSL FT4 confirmations

Björn Ekelund, SM7IUN
 

Thanks for the history lesson, Dave,

very enlightening and interesting. 

Hindsight is always 20/20 so it's easy to be critical to the current structure.
But some further clean up would not hurt. 

Björn SM7IUN

Den tis 3 sep. 2019 kl 20:15 skrev Dave AA6YQ <aa6yq@...>:

+ AA6YQ comments below

Agreed. The current mode "information architecture" i ADIF is a royal mess.

+ From its inception until 2013, ADIF provided only a MODE field. This worked well until new digital modes began appearing at a rapid rate and ops began expecting instant LoTW acceptance for these new digital modes. The gating item for LoTW acceptance of a new digital mode is the release of a new version of ADIF that includes a representation for that new digital mode. Best case, releasing a new version of ADIF requires several weeks for members to vote.

+ In an effort to reduce the delay between "new digital mode available" and "new digital mode included in ADIF", we added a SUBMODE field to ADIF 3.0.4 in August 2-13 with the intention that a new version of ADIF whose only changes were the addition of new SUBMODEs of existing MODEs could be immediately released by the "Secretary of ADIF", a rotating volunteer position.

+ As part of introducing SUBMODE, ~40 previous members of the MODE enumeration were deprecated and re-assigned MODE-SUBMODE combinations. For example

<MODE:5> PSK31

+ was deprecated in favor of

<MODE:3>PSK <SUBMODE:5> PSK31

+ In this context, "deprecated" means "not exported, but accepted during import".

+ Unfortunately, this approach failed to eliminate the need for discussion and voting to approved new versions of ADIF in response to the introduction of a new digital mode: the choice of MODE and SUBMODE representations were contentious enough that the "Secretary of ADIF" was unwilling to act unilaterally.

+ Why are these representations contentious? Because humans are imperfect.

+ ADIF is a standard interchange specification for reliably moving QSO data from one application to another. It is not meant to be read by humans, though the poor state of tooling in the amateur radio community often requires users to edit ADIF files, so we try to make the representations meaningful to humans. From an interchange perspective, for example,

<MODE:5> XYZZY

+ would be a perfectly effective way to represent PSK31 in ADIF. The specification would simply state that XYZZY in the MODE field means "PSK31".

+ Having human-readable MODE representations means that some people care about the representation. Some digital mode authors, for example, objected to having their shiny new mode represented with a MODE-SUBMODE combination, considering it derogatory for their mode to be represented by a submode of some other mode. Others argued over the technical accuracy of the representation; For example, should FT4 have been represented by

<MODE:4>MFSK <SUBMODE:3>FT4

+ or by

<MODE:4>GFSK <SUBMODE:3>FT4

+ The answer? For ADIF's purposes, it doesn't matter. If precise mode specifications were necessary, we'd have used ITU emission designators, as described in

<https://en.wikipedia.org/wiki/Types_of_radio_emissions>

+ Had we gone this route, we'd have specified

<MODE>3 A1A

+ for CW and

<MODE>3 J2B

+ for PSK31. For most users, this would be equivalent to representing PSK31 with

<MODE:5> XYZZY

+ Avoiding the encoding of unnecessary information is a core principle of information architecture. The precise characterization of a mode is unquestionably irrelevant to an interchange specification.

+ It's humorous, in a sick sort of way, that this was brought to a head by the selection of

<MODE:4>MFSK <SUBMODE:3>FT4

+ which is technically accurate (ignoring the MFSK vs. GFSK debate). The representation chosen for FT8 in July 2017

<MODE:3>FT8

+ is inconsistent with the changes introduced with the SUBMODE field. How did this happen? Joe K1JT waited till the last minute to name the new mode, FT8 adoption literally skyrocketed after its public release, and ADIF was under pressure to emit a new version that included FT8 so that LoTW could accept FT8 QSOs without their being "mapped" to DATA so that ops could pursue the (then not yet announced) WAS FT8 endorsement. This error could easily be corrected by deprecating

<MODE:3>FT8

+ in favor of

<MODE:4>MFSK <SUBMODE:3>FT8

+ but I sense little appetite for this.

+ If momentum for a major revision to ADIF's MODE-SUBMODE representations were to reach critical mass, I'd advocate for a change to obscure representations like

<MODE:5> XYZZY

+ Fear not, because few ADIF members will vote for anything that requires making significant changes to their existing code.

          73,

                   Dave, AA6YQ





Re: DXLAB PropView and Other Problems

Dave AA6YQ
 

+ AA6YQ comments below

Thank you Dave. All in working now.

I am now understanding that each app have their own multi monitor box that needs to be checked?

+ Correct. That enables you to force some DXLab applications to appear on the primary monitor where it will always be visible; the Launcher, for example.


I was under the impression that checking the multi monitor box under the Commander panel was for all apps.

+ What gave you that erroneous impression? If there's an error in the documentation, please cite it so that I can correct it.

73,

Dave, AA6YQ

Re: eQSL FT4 confirmations

Dave AA6YQ
 

+ AA6YQ comments below

Agreed. The current mode "information architecture" i ADIF is a royal mess.

+ From its inception until 2013, ADIF provided only a MODE field. This worked well until new digital modes began appearing at a rapid rate and ops began expecting instant LoTW acceptance for these new digital modes. The gating item for LoTW acceptance of a new digital mode is the release of a new version of ADIF that includes a representation for that new digital mode. Best case, releasing a new version of ADIF requires several weeks for members to vote.

+ In an effort to reduce the delay between "new digital mode available" and "new digital mode included in ADIF", we added a SUBMODE field to ADIF 3.0.4 in August 2-13 with the intention that a new version of ADIF whose only changes were the addition of new SUBMODEs of existing MODEs could be immediately released by the "Secretary of ADIF", a rotating volunteer position.

+ As part of introducing SUBMODE, ~40 previous members of the MODE enumeration were deprecated and re-assigned MODE-SUBMODE combinations. For example

<MODE:5> PSK31

+ was deprecated in favor of

<MODE:3>PSK <SUBMODE:5> PSK31

+ In this context, "deprecated" means "not exported, but accepted during import".

+ Unfortunately, this approach failed to eliminate the need for discussion and voting to approved new versions of ADIF in response to the introduction of a new digital mode: the choice of MODE and SUBMODE representations were contentious enough that the "Secretary of ADIF" was unwilling to act unilaterally.

+ Why are these representations contentious? Because humans are imperfect.

+ ADIF is a standard interchange specification for reliably moving QSO data from one application to another. It is not meant to be read by humans, though the poor state of tooling in the amateur radio community often requires users to edit ADIF files, so we try to make the representations meaningful to humans. From an interchange perspective, for example,

<MODE:5> XYZZY

+ would be a perfectly effective way to represent PSK31 in ADIF. The specification would simply state that XYZZY in the MODE field means "PSK31".

+ Having human-readable MODE representations means that some people care about the representation. Some digital mode authors, for example, objected to having their shiny new mode represented with a MODE-SUBMODE combination, considering it derogatory for their mode to be represented by a submode of some other mode. Others argued over the technical accuracy of the representation; For example, should FT4 have been represented by

<MODE:4>MFSK <SUBMODE:3>FT4

+ or by

<MODE:4>GFSK <SUBMODE:3>FT4

+ The answer? For ADIF's purposes, it doesn't matter. If precise mode specifications were necessary, we'd have used ITU emission designators, as described in

<https://en.wikipedia.org/wiki/Types_of_radio_emissions>

+ Had we gone this route, we'd have specified

<MODE>3 A1A

+ for CW and

<MODE>3 J2B

+ for PSK31. For most users, this would be equivalent to representing PSK31 with

<MODE:5> XYZZY

+ Avoiding the encoding of unnecessary information is a core principle of information architecture. The precise characterization of a mode is unquestionably irrelevant to an interchange specification.

+ It's humorous, in a sick sort of way, that this was brought to a head by the selection of

<MODE:4>MFSK <SUBMODE:3>FT4

+ which is technically accurate (ignoring the MFSK vs. GFSK debate). The representation chosen for FT8 in July 2017

<MODE:3>FT8

+ is inconsistent with the changes introduced with the SUBMODE field. How did this happen? Joe K1JT waited till the last minute to name the new mode, FT8 adoption literally skyrocketed after its public release, and ADIF was under pressure to emit a new version that included FT8 so that LoTW could accept FT8 QSOs without their being "mapped" to DATA so that ops could pursue the (then not yet announced) WAS FT8 endorsement. This error could easily be corrected by deprecating

<MODE:3>FT8

+ in favor of

<MODE:4>MFSK <SUBMODE:3>FT8

+ but I sense little appetite for this.

+ If momentum for a major revision to ADIF's MODE-SUBMODE representations were to reach critical mass, I'd advocate for a change to obscure representations like

<MODE:5> XYZZY

+ Fear not, because few ADIF members will vote for anything that requires making significant changes to their existing code.

73,

Dave, AA6YQ

Re: eQSL FT4 confirmations

Dave AA6YQ
 

+ AA6YQ comments below

You make a fair point, but I based my comment on the belief that the main purpose of DXKeeper's confirmation policy is to replicate that of the awards body, in this case eQSL.

+ That's correct. The question in my mind is whether the eQSL policy you report is intentional or inadvertent. I will ask Dave N5UP, who runs eQSL.

73,

Dave, AA6YQ

Re: DXLAB PropView and Other Problems

Timothy Kelly <N8NEU07@...>
 

Thank you Dave. All in working now.

I am now understanding that each app have their own multi monitor box that needs to be checked?

I was under the impression that checking the multi monitor box under the Commander panel was for all apps.

Tim - N8NEU

On Sep 2, 2019, at 7:17 PM, Dave AA6YQ <aa6yq@...> wrote:
+ AA6YQ comments below

Number 2 is still a problem. I open DXKeeper and/or DXView. I slide it (them) over to the second extended monitor and then close the application (clicking on the upper right corner X). I then restart one of the applications and they start back on monitor #1.

+ Please do the following:

1. on the General tab of DXView's Configuration window, check the "Log debugging info" box

2. place DXView's Main window on Monitor #1

3. place DXView's World Map window on Monitor #2

4. terminate DXView

5. start DXView

6. after the Main and World Map windows are visible, on the General tab of DXView's Configuration window, uncheck the "Log debugging info" box

7. attach the errorlog.txt file from your DXView folder to an email message, and send the message to me via

aa6yq (at) ambersoft.com

73,

Dave, AA6YQ




Re: eQSL FT4 confirmations

Björn Ekelund, SM7IUN
 

Agreed. The current mode "information architecture" i ADIF is a royal mess.

Björn SM7IUN

Den tis 3 sep. 2019 kl 17:15 skrev Joe Subich, W4TV <lists@...>:

On 2019-09-03 9:54 AM, Björn Ekelund, SM7IUN wrote:
> You make a fair point, but I based my comment on the belief that the
> main purpose of DXKeeper's confirmation policy is to replicate that
> of the awards body, in this case eQSL. (DXKeeper's mechanics are in
> line with all the other supported awards bodies.)
DXKeeper does not recognize eQSL's "eAwards".  eQSL pseudo confirmations
are only "recognized" for AG members when used for WAZ, WPX, WAE, etc.
and those awards do not differentiate among, PSK, MFSK, JT65, JT9, FT4,
FT8, etc. (they are all "data" thus no need for an "exact mode match").

However, since it does not appear that eQSL offers endorsements for FT4
or MFSK (they show JT65, JT9 and FT8) - at least in the rules for the
awards that I checked - it would not seem to matter whether DXKeeper
recognizes an "exact mode match" for FT4 vs. MFSK/FT4 vs. MFSK.

 > I don't know the exact syntactic rules of ADIF

Unfortunately, ADIF does not have a good set of "rules" for mode and
submode.  To be rigorous, there should only be five or six "modes"
(modulation formats) - CW, AM, FM, FSK, PSK and PULSE (some would add
MFSK - more than two tones - as distinct from FSK - two tones - but
that is splitting hairs).  All current "modes" are simply differences
in data encoding and error correction on top of the six basic types
of modulation - for example, double sideband full carrier (e.g. AM),
lower sideband suppressed carrier (LSB), upper sideband suppressed
carrier (USB), independent sideband suppressed carrier (ISB),
vestigial sideband (VSB - e.g. analog TV) are all forms of AM.

73,

    ... Joe, W4TV


On 2019-09-03 9:54 AM, Björn Ekelund, SM7IUN wrote:
> You make a fair point, but I based my comment on the belief that the main
> purpose of DXKeeper's confirmation policy is to replicate that of the
> awards body, in this case eQSL. (DXKeeper's mechanics are in
> line with all the other supported awards bodies.)
>
> I don't know the exact syntactic rules of ADIF but in my layman's opinion,
> since pairs like "JT9" and "JT9 submode JT9C" and "RTTY" and
> "RTTY submode ASCI" are mode obvious matches, "MFSK" and
> "MFSK submode FT4" should be too.
>
> I don't know if this is why eQSL implemented it so or if they are just
> pragmatically violating the standard since there is bad software out there.
>
> To me it is of little consequence. I only upload to eQSL as a friendly
> service
> for those that care about such confirmations.
>
> But I try to make a habit of reporting all anomalies I find with DXLab.
>
> Björn SM7IUN
>
>
> Den tis 3 sep. 2019 kl 14:32 skrev Joe Subich, W4TV <lists@...>:
>
>>
>>> eQSL considers a QSO confirmed regardless of submode so this works
>>> fine on the web site but DXKeeper does not consider a QSO with
>>> MFSK-Submode FT4 and another QSO with only MFSK a match. Given
>>> eQSL's policy, I think it should.
>>
>> Absolutely not!  <MODE:4> MFSK and <MODE:4> MFSK <SUBMODE:3> FT4 are
>> clearly different and should not represent an exact mode match.
>>
>> FT4 QSOs uploaded with only <MODE:4> MFSK represent uploads from
>> defective loggers (loggers that are not ADIF compliant) and should
>> be rejected until developers like HRD fix their software.
>>
>> 73,
>>
>>      ... Joe, W4TV
>>
>>
>> On 2019-09-03 8:11 AM, Björn Ekelund, SM7IUN wrote:
>>> I played around with FT4 the other day and found that there is a slight
>>> discrepancy between DXKeeper and eQSL
>>> in confirmation criteria.
>>>
>>> It seems a fair share of the users upload their QSO to eQSL without
>>> submode. eQSL considers a QSO confirmed
>>> regardless of submode so this works fine on the web site but DXKeeper
>> does
>>> not consider a QSO
>>> with MFSK-Submode FT4 and another QSO with only MFSK a match. Given
>> eQSL's
>>> policy, I think it should.
>>>
>>> Björn SM7IUN
>>>
>>
>>
>>
>>
>>
>
>
>
>



Re: DXKeeper realtime tracking for Marathon is blank

John Bastin
 

On 3Sep 2019, at 11:21, Catherine James <catherine.james@...> wrote:

What step have I omitted? The other realtime reports work fine. I have plenty of contacts logged in DXKeeper that should qualify.
In my settings of DXKeeper for Marathon, in “Marathon Bands & Modes” I have only three boxes checked: Mixed, “Include QSOs with no prop”, and “Realtime Award Progress.” All of the other band and mode checkboxes are left blank. My reports are working fine.

Hope this helps.

73,


John K8AJS
jbastin1@...
CWOps 1694
Ten-X 11306

DXKeeper realtime tracking for Marathon is blank

Catherine James
 

I recently decided to start tracking my progress toward the 2019 Marathon, mixed.

I went into the DXKeeper Configuration window. Under Marathon Band and Modes, I selected 160, 80, 60, 40, 30, 20, 17, 15, and 10, Mixed, and typed in 1000 max TX power.

I downloaded the Excel spreadsheet from Marathon and installed it in the database folder. I then clicked on Year, Category, Score Sheet Info and selected the path to the Excel.  I have Office 2003 installed on this machine, and outside of DXLab, it can open the downloaded spreadsheet. I also checked Unlimited, Mixed, and entered 2019, my call, and my name. I left the address, antenna, comments, etc. blank for now.

When I go to the Marathon tab on DXKeeper Realtime and select worked, unselect Unworked, I get a blank screen. Clicking on the Report button gives "0 worked" everywhere. Clicking on Recompute at the bottom of the Check Progress tab does not change this.

What step have I omitted?  The other realtime reports work fine. I have plenty of contacts logged in DXKeeper that should qualify.

73,
Cathy N5WVR

Re: eQSL FT4 confirmations

Joe Subich, W4TV
 

On 2019-09-03 9:54 AM, Björn Ekelund, SM7IUN wrote:
You make a fair point, but I based my comment on the belief that the
main purpose of DXKeeper's confirmation policy is to replicate that
of the awards body, in this case eQSL. (DXKeeper's mechanics are in line with all the other supported awards bodies.)
DXKeeper does not recognize eQSL's "eAwards". eQSL pseudo confirmations
are only "recognized" for AG members when used for WAZ, WPX, WAE, etc.
and those awards do not differentiate among, PSK, MFSK, JT65, JT9, FT4,
FT8, etc. (they are all "data" thus no need for an "exact mode match").

However, since it does not appear that eQSL offers endorsements for FT4
or MFSK (they show JT65, JT9 and FT8) - at least in the rules for the
awards that I checked - it would not seem to matter whether DXKeeper
recognizes an "exact mode match" for FT4 vs. MFSK/FT4 vs. MFSK.

I don't know the exact syntactic rules of ADIF
Unfortunately, ADIF does not have a good set of "rules" for mode and
submode. To be rigorous, there should only be five or six "modes"
(modulation formats) - CW, AM, FM, FSK, PSK and PULSE (some would add
MFSK - more than two tones - as distinct from FSK - two tones - but
that is splitting hairs). All current "modes" are simply differences
in data encoding and error correction on top of the six basic types
of modulation - for example, double sideband full carrier (e.g. AM),
lower sideband suppressed carrier (LSB), upper sideband suppressed
carrier (USB), independent sideband suppressed carrier (ISB),
vestigial sideband (VSB - e.g. analog TV) are all forms of AM.

73,

... Joe, W4TV


On 2019-09-03 9:54 AM, Björn Ekelund, SM7IUN wrote:
You make a fair point, but I based my comment on the belief that the main
purpose of DXKeeper's confirmation policy is to replicate that of the
awards body, in this case eQSL. (DXKeeper's mechanics are in
line with all the other supported awards bodies.)
I don't know the exact syntactic rules of ADIF but in my layman's opinion,
since pairs like "JT9" and "JT9 submode JT9C" and "RTTY" and
"RTTY submode ASCI" are mode obvious matches, "MFSK" and
"MFSK submode FT4" should be too.
I don't know if this is why eQSL implemented it so or if they are just
pragmatically violating the standard since there is bad software out there.
To me it is of little consequence. I only upload to eQSL as a friendly
service
for those that care about such confirmations.
But I try to make a habit of reporting all anomalies I find with DXLab.
Björn SM7IUN
Den tis 3 sep. 2019 kl 14:32 skrev Joe Subich, W4TV <lists@...>:


eQSL considers a QSO confirmed regardless of submode so this works
fine on the web site but DXKeeper does not consider a QSO with
MFSK-Submode FT4 and another QSO with only MFSK a match. Given
eQSL's policy, I think it should.
Absolutely not! <MODE:4> MFSK and <MODE:4> MFSK <SUBMODE:3> FT4 are
clearly different and should not represent an exact mode match.

FT4 QSOs uploaded with only <MODE:4> MFSK represent uploads from
defective loggers (loggers that are not ADIF compliant) and should
be rejected until developers like HRD fix their software.

73,

... Joe, W4TV


On 2019-09-03 8:11 AM, Björn Ekelund, SM7IUN wrote:
I played around with FT4 the other day and found that there is a slight
discrepancy between DXKeeper and eQSL
in confirmation criteria.

It seems a fair share of the users upload their QSO to eQSL without
submode. eQSL considers a QSO confirmed
regardless of submode so this works fine on the web site but DXKeeper
does
not consider a QSO
with MFSK-Submode FT4 and another QSO with only MFSK a match. Given
eQSL's
policy, I think it should.

Björn SM7IUN



Re: eQSL FT4 confirmations

Björn Ekelund, SM7IUN
 

You make a fair point, but I based my comment on the belief that the main 
purpose of DXKeeper's confirmation policy is to replicate that of the 
awards body, in this case eQSL. (DXKeeper's mechanics are in 
line with all the other supported awards bodies.) 

I don't know the exact syntactic rules of ADIF but in my layman's opinion, 
since pairs like "JT9" and "JT9 submode JT9C" and "RTTY" and 
"RTTY submode ASCI" are mode obvious matches, "MFSK" and 
"MFSK submode FT4" should be too. 

I don't know if this is why eQSL implemented it so or if they are just 
pragmatically violating the standard since there is bad software out there. 

To me it is of little consequence. I only upload to eQSL as a friendly service 
for those that care about such confirmations. 

But I try to make a habit of reporting all anomalies I find with DXLab. 

Björn SM7IUN


Den tis 3 sep. 2019 kl 14:32 skrev Joe Subich, W4TV <lists@...>:


> eQSL considers a QSO confirmed regardless of submode so this works
> fine on the web site but DXKeeper does not consider a QSO with
> MFSK-Submode FT4 and another QSO with only MFSK a match. Given
> eQSL's policy, I think it should.

Absolutely not!  <MODE:4> MFSK and <MODE:4> MFSK <SUBMODE:3> FT4 are
clearly different and should not represent an exact mode match.

FT4 QSOs uploaded with only <MODE:4> MFSK represent uploads from
defective loggers (loggers that are not ADIF compliant) and should
be rejected until developers like HRD fix their software.

73,

    ... Joe, W4TV


On 2019-09-03 8:11 AM, Björn Ekelund, SM7IUN wrote:
> I played around with FT4 the other day and found that there is a slight
> discrepancy between DXKeeper and eQSL
> in confirmation criteria.
>
> It seems a fair share of the users upload their QSO to eQSL without
> submode. eQSL considers a QSO confirmed
> regardless of submode so this works fine on the web site but DXKeeper does
> not consider a QSO
> with MFSK-Submode FT4 and another QSO with only MFSK a match. Given  eQSL's
> policy, I think it should.
>
> Björn SM7IUN
>