It should also be pointed out that
1. SUBMODE was added to version 3.0.4 of the ADIF specification, which was
approved and released 6 years ago (2013-08-04).
2. It takes less than an hour to add SUBMODE import/export to an application
that already supports MODE import/export.
73,
Dave, AA6YQ
-----Original Message-----
From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: Wednesday, July 31, 2019 11:05 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] FT4 and LOTW
On 31/07/2019 14:37, Serge Smirnoff R6YY via wsjt-devel wrote:
> Gentlemen, hello!
>
> The decision of the admin LOTW to give the FT4 mode the status of the
> MFSK mode / FT4 sub-mode is absurd.
>
> Not all Loggers soft understand the concept of submod. Different
> loggers differently perceive the information coming from the WSJTX and
> each in its own way translates it into LOTW. In turn, LOTW in its own
> way interprets the information received. And the result for the user
> is a very small percentage of confirming FT4 QSOs, although almost
> 100% send their data to LOTW.
>
> On the other hand, how does FT4 differ from FT8 for LOTW? Nothing.
> Why, for what purposes it was worth reinventing the bike with a mod /
> submod.
>
> Maybe I don t understand something, but the fact of low affirmation of
> links exists. And the problem is in the innovation admin LOTW.
>
> What do you say, colleagues?
>
> Regards, Serge R6YY
Serge,
please write a new post when starting a new topic, replying to an existing
thread and changing the subject is confusing for those of us that use threaded
email clients to manage posts on many lists.
Your rant misses some important facts. The decision to have ADIF records record
FT4 mode contacts as MODE=MFSK and SUMODE=FT4 was that of the ADIF committee
who are the guardian of the ADIF specification. They, quite sensibly IMHO, have
decided that new data modes should be classified by their generic modulation
type and sub-classified by the protocol of the messaging. They have not changed
anything retrospectively, FT8 and other similar modes remain as they were before
FT4 went public a few weeks ago. There is no extra complexity, logging programs
and other consumers of ADIF data need to be extended to support
FT4 if they are to remain ADIF specification compliant. Those same programs may
choose to accept MODE=FT4 and a substitute for FT4 QSO records, that is their
choice and probably a wise one. What they must do is encode FT4 QSO data with
MODE=MFSK and SUBMODE=FT4 when *exporting* data. I see no problem whatsoever,
logging programs when adding FT4 support need to handle FT4 according to the
ADIF specification when exporting ADIF compliant data.
With respect to LoTW, they will accept any valid digital mode QSO record
(except CW) with the simple MODE=DATA classification, they will also accept QSO
records with MODE=FT4, and QSO records with MODE=MFSK combined with
SUBMODE=FT4. Only the first of these is limited, because a very small number of
awards and certificates require exactly FT4 to be logged as the mode. Many
other awards and certificates do not distinguish between different digital
modes and MODE=DATA is sufficient.
LoTW users have the choice to upload QSOs with MODE=DATA and later re-upload
with more specific mode designations. That is fine and the choice of the
individual LoTW users. The resulting duplicate records in the LoTW database are
benign. If you have a match for your FT4 qsos, or any other digital mode QSOs,
on LoTW that only provides a MODE=DATA confirmation and you require a more
specific match; then I suggest that you contact your QSO partners for each need
confirmation and politely ask them to re-upload their QSOs using the latest
tQSL and tQSL configuration such that the more specific mode fields are present
for matching.
73
Bill
G4WJS.
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
---
This email has been checked for viruses by AVG.
https://www.avg.com
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
