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