w4kek
/
WSJT-X
mirror of https://github.com/saitohirga/WSJT-X.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
WSJT-X/lib/digi-contest.txt

278 lines
13 KiB
Plaintext
Raw Permalink Blame History

Possible FT8 Enhancements for Contesting
----------------------------------------
In addition to all the standard FT8 messages, FT8 DXpedition Mode
defines a new message type to convey messages like this example
acknowledging completion of a QSO with K1ABC and initiating a QSO with
W9XYZ:
K1ABC RR73; W9XYZ <KH1/KH7Z> -11
With 15s T/R sequencing and otherwise using standard FT8 messages,
this feature allows QSO rates up to 120/hour with one Tx signal. The
callsign enclosed in angle brackets is sent as a 10-bit hash code.
High QSO rates are also desirable for contest operating, but some
details are quite different from the DXpedition case. Contesting is a
many-to-many (as opposed to many-to-one) activity. We distinguish
between "Run stations" and "S+P stations" rather than between "Fox"
and "Hounds".
An optimal sequence of messages suitable for contesting looks
something like the list in Table 1, where {exch} represents the
required contest exchange. With 15 s transmissions and a steady
stream of callers, messages like these can support QSO rates
approaching 120/hour.
Table 1. Example sequence of FT8 contest messages
-------------------------------------------------------------------------
Run station S+P stations
-------------------------------------------------------------------------
1. CQ K1ABC
2. K1ABC W9XYZ, K1ABC G4AAA, ...
3. W9XYZ K1ABC {exch}
4. K1ABC W9XYZ {exch}
5. TU; G4AAA K1ABC {exch}
6. K1ABC G4AAA {exch}
7. TU; VE2BBB K1ABC {exch}
8. K1ABC VE2BBB {exch}
9. ...
-------------------------------------------------------------------------
In some circumstances one or both station callsigns may safely be
taken as known by context. High-rate contest transmissions in SSB,
CW, and RTTY can therefore be considerably shortened with no resulting
ambiguity for attentive operators. CQing stations need not include
their own callsign in every transmission, while S+P stations may send
only their own callsign at first, as in line 2 of Table 2, and then
only the contest exchange, as in line 4.
Table 2. Abbreviated contest messages
-------------------------------------------------------------------------
Run station S+P stations
-------------------------------------------------------------------------
1. CQ K1ABC
2. W9XYZ, G4AAA, ...
3. W9XYZ {exch}
4. {exch} (sent by W9XYZ)
5. TU; G4AAA {exch}
6. {exch} (sent by G4AAA)
7. TU; VE2BBB {exch}
8. {exch} (sent by VE2BBB)
9. TU; CQ K1ABC
10. ...
-------------------------------------------------------------------------
There would be no advantage to such message brevity with FT8. FT8
transmissions are of fixed duration, by design; and the AP decoder can
treat the home callsign and previously decoded callsigns as
hypothetically given, thereby making the effective code rate lower and
sensitivity up to 4 dB better.
Required exchange information for some relevant contests is
illustrated in Table 3, along with a breakdown of bit requirements for
each component of the exchange. Lower-case letter-number combinations
such as r1, r3, s7,... in the table suggest the meanings and indicate
the number of bits required to convey each part of the exchange.
Further details are given below the Table. Parameter T1 is the total
number of exchange bits, and T2=T1+56 is the number of bits for the
full message, including two standard 28-bit callsigns.
Table 3. Examples of required contest exchanges {exch}
------------------------------------------------------------------------------
Event Exchange Example Bits T1 T2
------------------------------------------------------------------------------
ARRL RTTY US/Can: rpt state/prov R 579 MA r1 r3 s7 11 67
DX: rpt serial R 559 0013 r1 r3 n12 16 72
Field Day US/Can: OpClass Section R 6A EMA r1 n5 c3 s7 16 72
DX: OpClass DX R 1A DX r1 n5 c3 s7 16 72
CQ WPX RTTY RST + serial R 589 0013 r1 r3 n12 16 72
CQ WW RTTY US/Can: RST CQZ state/prov R 579 8 NJ r1 r3 z6 s6 16 72
DX: RST + CQzone R 559 3 r1 r3 z6 10 66
ARRL VHF+ grid4 R FN42 r1 g15 16 72
EU VHF+ rpt serial grid6 R 590013 IO91NP r1 r3 n12 g25 41 97
------------------------------------------------------------------------------
Meaning and number of bits for each exchange component:
c3 Operating class (A-F)
g15 grid4
g25 grid6
n12 Serial number
n5 Number of transmitters (0-31)
r1 acknowledgment of received exchange
r3 3-bit report (0-7 ==> -24 to +18 dB, effectively "S2 to "S9")
s6 US state or Canadian province (48+14=62)
s7 ARRL/RAC Section (83 sections)
z6 CQ zone
------------------------------------------------------------------------------
How best to accommodate all these possibilities within the 72+3-bit
FT8 message payload? Let i3 (aka "i3bit") denote message type, with
available range 0-7. Type 0 is already used for standard JT-style
structured messages and free text, and type 1 for DXpedition mode.
Examples of suggested new message types 2 through 6 are summarized in
the Table 4.
Table 4. Proposed FT8 message types
------------------------------------------------------------------------------
i3 Example message Bits i72 Total Special purpose
------------------------------------------------------------------------------
0 K1ABC W9XYZ EN37 28 28 15 0 72 Standard message
0 FREE TEXT 71 1 72 Free text
1 K1ABC RR73; W9XYZ <KH1/KH7Z> -11 28 28 10 6 72 DXpedition Mode
2 W9XYZ K1ABC x16 28 28 16 72 Contesting
3 TU; G4AAA K1ABC x16 28 28 16 72 Contesting with "TU;"
4 <K1ABC> W9XYZ/R R x25 17 28 1 1 25 72 Rovers, Grid6
5 <K1ABC> PJ4/W9XYZ 17 49 66 Compound TxCall
6 PA9XYZ R 590003 IO91NP 28 1 3 12 24 68 EU VHF contest
7 tbd...
The first callsign in a message can also be "CQ" and a few other
special tokens. Type 3 messages are the same as type 2 except for
including "TU;", the completion-of-QSO indicator. Message fragments
x16 and x25 represent generic contest exchanges. A "contest template"
will define the specific source encoding/decoding needed for each
event.
Suggested message types 4 and 5 use a 17-bit hash for the first
callsign. I'm imagining that we'd start with a 32-bit crc and then
use its remainder after dividing by the prime number 131063. Values
less than 131063 will be the desired hash code, and the nine values
131063-131071 can be assigned special meanings such as CQ, QRZ, etc.
Type 4 messages identify the transmitting station as a Rover and can
also accommodate 6-digit grid locators. Type 5 messages allow the
transmitting station to send a full compound callsign with add-on
prefixes up to 4 characters and suffixes up to 3. Compound callsigns
are also permissible for the hashed callsigns in message types 4 and
5.
Contest Operating
-----------------
Operating in this proposed FT8 Contest Mode would be similar to that
in current RTTY contests. CQing stations will be distributed over 20
kHz or more on each band, perhaps at ~500 Hz separation. They will
respond to callers on their own frequency +/- ~200 Hz. Thus, a CQing
station and callers should occupy no more than 500 Hz total bandwidth.
CQers might always transmit at Tx audio frequency 1750 Hz and
configure their FT8 decoders to respond to signals between 1500 and
2000 Hz. S+P stations will typically work their way up or down the
band, perhaps in steps of 2 or 3 kHz, looking for unworked CQers. The
FT8 Contest GUI will offer special features for CQ mode and S+P mode
that make such conventions easy to follow.
Some Pertinent Questions
------------------------
1. FT8 is a good mode, but does it make for a good contesting mode?
The model described above maxes out at 120 QSOs/hour. (One can
imagine SO2R or even SO3R extensions, doubling or tripling that
limit.) Should we consider T/R sequences of 10s, or even 5s, to get
potentially higher rates? Should we consider giving up synchronized,
fixed-length sequences entirely, and use operator-determined start
times and transmission lengths? That's a significant departure from
all existing WSJT-X modes.
2. How much automation should be permissible?
We're not aiming to make a contesting robot. We want something that
rewards operator and station performance. The recently introduced FT8
DXpedition Mode offers the "Fox" operator a list of decoded "Hounds"
sorted by Call, Grid, S/N, Distance, or Random order. Hounds must
initiate their calls to Fox, and Fox must manually select each Hound
to be called. Otherwise, QSOs proceed with standard FT8
"auto-sequencing". Is this model acceptable?
3. How much bandwidth? How much sensitivity?
RTTY signals use bandwidth ~220 Hz and require S/N around -5 dB or
better, measured in a 2500 Hz bandwidth. FT8 uses signal bandwidth 50
Hz and reaches threshold sensitivity between -20 and -24 dB, depending
on how much a priori (AP) information is available. Shorter
transmissions conveying the same messages would increase the
bandwidth, S/N threshold, and potential QSO rate proportionally. Has
FT8 already hit the "sweet spot" of such trade-offs?
4. Suitable power limits?
WSJT-X modes are designed as weak-signal modes. They have strong FEC
and don't suffer from partial or corrupted copy. Sensitivity already
beats RTTY by 15-19 dB, so arguably it makes sense for an FT8 contest
or contest category to be limited to 100 W or even QRP power levels.
5. What software should provide the operator's GUI?
Things are described above as though WSJT-X, the software that
introduced FT8, would be used for contest operating. WSJT-X can send
QSO information to N1MM+ and other logging programs, so they could be
used in combination with WSJT-X. Alternatively, we could set things
up so that N1MM+ is the control program and FT8 encoding/decoding is
provided by a plug-in "MMFT8" similar to MMTTY. Operators already
into serious RTTY contesting would probably like the N1MM-in-control
option. However, existing FT8 users might be more comfortable with
WSJT-X in full control. Moreover, WSJT-X offers full support for
Linux and MacOS, which N1MM+ does not.
########################################################################
More thinking, beyond the above...
FT8 currently uses LDPC(174,87), where 87=72+3+12. Suggest going to
LDPC(174,91), with 91=72+5+14. This would give us 32 message types
rather than 7, and stronger suppression of false decodes. SNR penalty
would be 10log(91/87)=0.2 dB.
MSK144 currently uses LDPC(128,80), where 80=72+8. Suggest going to
LDPC(128,87), with 87=72+5+10. SNR penalty is 0.4 dB.
ARRL RTTY Roundup
-------------------------------------------------------------------------
Run station S+P stations
-------------------------------------------------------------------------
1. CQ K1ABC
2. K1ABC W9XYZ, K1ABC G4AAA, ...
3. W9XYZ K1ABC 579 MA
4. K1ABC W9XYZ 599 WI
5. TU; G4AAA K1ABC 559 MA
6. K1ABC G4AAA 579 0013
7. TU; VE2BBB K1ABC 599 MA
8. K1ABC VE2BBB 599 QC
9. TU; CQ K1ABC
-------------------------------------------------------------------------
NA VHF Contest
-------------------------------------------------------------------------
Run station S+P station i3
-------------------------------------------------------------------------
1. CQ K1ABC/R FN54 0
2. K1ABC W9XYZ EN37 0
3. W9XYZ K1ABC R FN54 2
4. K1ABC W9XYZ RR73 0
5. CQ K1ABC/R FN54 0
-------------------------------------------------------------------------
1. CQ K1ABC FN42 0
2. <K1ABC> W9XYZ/R EN47 5
3. W9XYZ K1ABC R FN42 0
4. DE W9XYZ/R RR73 0
5. CQ K1ABC FN42 0
-------------------------------------------------------------------------
EU VHF+ Contest
-------------------------------------------------------------------------
Run station S+P station i3
-------------------------------------------------------------------------
1. CQ G4ABC IO91 0
2. G4ABC PA9XYZ JO22 0
3. PA9XYZ 590003 IO91NP 6
4. G4ABC R 570007 JO22DB 6
5. PA9XYZ G4ABC RR73 0
Reference in New Issue View Git Blame Copy Permalink