Topics

MSFT vs FT4

Björn SM7IUN
 

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

neil_zampella
 

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

Neil, KN3ILZ

On 6/13/2020 3:22 AM, Björn Ekelund, SM7IUN wrote:
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


Virus-free. www.avg.com

Dave AA6YQ
 

+ 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

Bernd - KB7AK
 

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. 

Björn SM7IUN
 

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

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. 

g4wjs
 

Hi Björn,

that is very questionable. Accepting an electronic QSL with a mode of 'FT4' as an FT4 QSO is acceptable, although not ADIF compliant. Accepting an electronic QSL with a mode of 'MFSK' and sub-mode of 'FT4' is perfectly acceptable and ADIF compliant. Accepting an electronic QSL with a mode of 'MFSK' and no sub-mode *may* be acceptable as a "DATA" QSL match to a local FT4 QSO record, but really there is a problem upstream that needs resolving. It is not the gift of DXKeeper to guess if a QSO 2-way match was in FT4 mode if there is no information to back that up.

73
Bill
G4WJS.

On 13/06/2020 21:03, 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@...>:
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.

Joe Subich, W4TV
 

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.

Dave AA6YQ
 

+ 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

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

Björn SM7IUN
 

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. 

Björn SM7IUN

Den sön 14 juni 2020 kl 02:03 skrev Dave AA6YQ <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






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

Joe Subich, W4TV
 

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

Björn SM7IUN
 

Hi Dave,

did N5UP respond? I keep getting QSL confirmations from eqsl.cc that consider 
FT4 and MFSK a "close enough match" to warrant a QSO confirmation. 

Björn SM7IUN


Den sön 14 juni 2020 kl 02:03 skrev Dave AA6YQ <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






Dave AA6YQ
 

+ AA6YQ comments below

did N5UP respond?

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

73,

Dave, AA6YQ