开云体育

That's surprising, as DXKeeper, as does eQSL, follows the ADIF standard which does consider FT4 as a submode of MFSK.

Neil, KN3ILZ

Maybe this has been discussed before but it seems eQSL considers FT4 and MFSK the same mode while DXKeeper does not.

I believe that eQSL's "rules" should apply for eQSL confirmations in DXKeeper.

For cards and LOTW, ARRL's "rules" should of course apply.

Bj?rn

+ AA6YQ comments below

Maybe this has been discussed before but it seems eQSL considers FT4 and MFSK the same mode

+ They aren't the same mode. What leads you to conclude that eQSL considers them the same?


while DXKeeper does not. I believe that eQSL's "rules" should apply for eQSL confirmations in DXKeeper.

+ What changes in DXKeeper behavior are you proposing?


73,

Dave, AA6YQ

He might be referring to the fact that some QSO's in eQSL come through as just MFSK, while the majority comes through as MFSK(FT4). If a QSO is logged as MFSK in eQSL it cannot be matched to a QSO that is logged as FT4 in DXKeeper, I usually have one of 2 each week.?

开云体育

--
73

Bill

G4WJS.

Although somewhat questionable, I therefore propose DXKeeper
considers MFSK without submode and FT4 as the same mode for eQSL
confirmations.

Absolutely not! MFSK without a sub-mode can be any of number of
"modes" including MFSK8, MFSK16, and JS8 each of which are
recognized for various award programs.

Accepting MFSK as equivalent to MFSK(FT4) is equivalent to accepting
PSK as equivalent to PSK(PSK31) or PSK(PSK63) or PSK(PSK125), etc.

The proper solution is to get the station that uploaded the QSO with
MODE=MFSK SUBMODE=<none> to fix his/her upload as either MODE=FT4
(not ADIF compliant) or as MODE=MFSK SUBMODE=FT4 (correct).

eQSL *should* refuse to accept QSOs with MODE=MFSK SUBMOD=<none>
or treat them as "data only".

73,

... Joe, W4TV


On 2020-06-13 4:03 PM, Bj?rn Ekelund, SM7IUN wrote:

Yes.
But logging into eqsl.cc shows that eQSL considers them a match and thereby
represents a confirmed QSO.
Although somewhat questionable, I therefore propose DXKeeper considers MFSK without?submode
and FT4 as the same mode for eQSL confirmations.
Bj?rn
Den l?r 13 juni 2020 kl 21:57 skrev Bernd - KB7AK <bernd1peters@... <mailto:bernd1peters@...>>:
He might be referring to the fact that some QSO's in eQSL come
through as just MFSK, while the majority comes through as MFSK(FT4).
If a QSO is logged as MFSK in eQSL it cannot be matched to a QSO
that is logged as FT4 in DXKeeper, I usually have one of 2 each week.

+ AA6YQ comments below

He might be referring to the fact that some QSO's in eQSL come through as just MFSK, while the majority comes through as MFSK(FT4).

+ Sounds like one or more logging applications are not correctly submitting FT4 QSOs to eQSL. If you submit a QSO to eQSL.cc whose mode is MFSK (instead of FT4), it will believe you.

If a QSO is logged as MFSK in eQSL it cannot be matched to a QSO that is logged as FT4 in DXKeeper

+ That's correct.

73,

Dave, AA6YQ

+ AA6YQ comments below

But logging into eqsl.cc shows that eQSL considers them a match and thereby represents a confirmed QSO.

Although somewhat questionable, I therefore propose DXKeeper considers MFSK without submode and FT4 as the same mode for eQSL confirmations.

+ That would be propagating a defect in eQSL to DXKeeper. No thanks.

+ I will alert Dave N5UP of eQSL.cc.

73,

Dave, AA6YQ

+ AA6YQ comments below

Just to avoid any misunderstanding, I agree that eQSL's current practice is questionable.

If you are able to convince eQSL to change that is of course the best solution.

I did not even consider that. Perhaps I just think too much of them.

+ As a start, I've asked Dave N5UP to articulate eQSL's policy for mode-matching in confirmations. We can then compare it to WAZ and WPX mode-matching policies.

73,

Dave, AA6YQ

We can then compare it to WAZ and WPX mode-matching policies.

WAZ and WPX are like DXCC in mode matching ... they don't care except
that the mode is "DATA". The only difference among DXCC, WAZ and WPX
is that WAZ separates traditional RTTY from DATA.

WAZ:

Note 2: This WAZ award is designed to encourage activity and
experimentation using any of the digital modes available to amateurs.
The list includes, but is not limited to, PSK-31, AMTOR, PACTOR, and
Spread Spectrum. QSL cards must indicate the specific mode used for
the QSO. RTTY does not count for this award, as it has its own award.
This award will not be endorsed for any specific digital mode. You
may elect to use a single digital mode or different digital modes in
working toward this WAZ award.

WPX:

Separate, distinctively marked certificates are available for SSB,
CW, Digital (RTTY/PSK) and Mixed (CW, SSB/Phone, Digital).

73,

... Joe, W4TV


On 2020-06-14 1:25 AM, Dave AA6YQ wrote:

+ AA6YQ comments below
Just to avoid any misunderstanding, I agree that eQSL's current practice is questionable.
If you are able to convince eQSL to change that is of course the best solution.
I did not even consider that. Perhaps I just think too much of them.
+ As a start, I've asked Dave N5UP to articulate eQSL's policy for mode-matching in confirmations. We can then compare it to WAZ and WPX mode-matching policies.
73,
Dave, AA6YQ

+ AA6YQ comments below

did N5UP respond?

+ He did not respond, despite two follow-up messages.

73,

Dave, AA6YQ