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

Reply via email to