On 10/09/2017 03:44, Rich - K1HTV wrote:
How about this suggestion? Is there any way to modify the program to
accept either the contest format (K9AN K1HTV FM18) or the non-contest
format (K9AN K1HTV -15) as valid TX2 messages and proceed by replying
with a Tx3 message?
The same holds for the TX3 message reception. Could the program be
written in such a way as to accept either a contest TX4 message (K9AN
K1HTV R FM18) or a non-contest TX4 message (K9AN K1HTV RRR) as being
valid, then continue on to the Tx5 message?
Hi Rich,
there are two differences to WSJT-X when NA contest mode is enabled.
1) the Tx3 message is sent as a standard grid message but with the grid
"flipped" to its antipode. The sending application shows that message as
"<dx-call> <de-call> R <grid>" (note what is sent on air is "<dx-call>
<de-call> <antipode-grid>"). A receiving application will either receive
the message as normal and it cannot know that it was intended to be
interpreted in NA contest mode (it could easily be a valid grid on HF
for example), but if the receiving application is in NA contest mode it
assumes that any grid message where the grid is more than 10,000km away
must be a contest Tx3 message and it translates "<dx-call> <de-call>
<grid>" to "<dx-call> <de-call> R <antipode-grid>" thus restoring the
original correct grid due to the flip at both Tx and Rx ends.
2) the receiving application follows a different sequence of message
exchange and treats the received contest format Tx3 style message as
equivalent to a standard RRR message.
If you think this through you will find that the application cannot "fix
up" QSOs between stations that have not both set NA contest mode without
breaking the normal FT8 processing for everyone else.
Please don't forget, this NA contest mode was added as a quick fix for
the many stations wanting to utilize FT8 and MSK144 in some NA contests.
It is not intended as a permanent solution as it has many obvious
limitations. As I pointed out before, we have some options for FT8 with
the extended 75-bit payload but it will take time to come up with a
concrete protocol enhancement that works for the maximum number of most
commonly used different contest formats. For MSK144 we are still stuck
with a 72-bit payload so any expansion options there will require a
breaking change to the protocol which is even more difficult to manage.
For now those intending to use FT8 or MSK144 NA contest mode in battle
must find a way to inform any stations they might work that the too must
enable NA contest mode. All I can suggest is make some noise about it on
the KST/ping jockey/... nets and IRC channels pre-contest and let other
know what you intend. It will be difficult as you don't have the easy
option of sending "I am in a contest and require you to send me this
information".
73
Bill
G4WJS.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
