Thanks to all who reported on experiences during the FT8 mock contest
last evening. Reports are still coming in, but this seems like a good
time to summarize some basic conclusions.
Beta-testing of software is done to help identify problems including
programming errors, missing or broken features, and undesired behavior
that might be caused by unexpected user actions. Last evening's mock
contest was an effort to exercise the new "RTTY Roundup" message format
in WSJT-X 2.0, under conditions that might be similar to those in a real
RTTY-style contest.
Documentation provided with WSJT-X 2.0-rc1 and -rc2 made it clear that
many features important for contest operating such as dupe checking,
stacked queuing of calls to be worked, display of QSO rate, multipliers,
cumulative score, etc., have not yet been implemented. Moreover,
complete logging when using contest-like messages is limited to a file
"cabrillo.txt". In the -rc1 and -rc2 releases, neither the ADIF log nor
logging information sent to N1MM+, or through JTAlert to DXKeeper, etc.,
would include signal reports, grid locators, or the like.
With these preliminaries out of the way, here's a brief summary list of
findings:
1. Operators who read and followed the instructions had few problems
when working others who had read and followed the instructions.
2. Valid QSOs were properly logged to file cabrillo.log.
3. Manual editing of the CQ ("Tx6") message could produce an improperly
formatted message starting with "CQ RU RU ..." rather than "CQ RU ...".
The program generates the correct message automatically. It was not
intended that anyone should edit the Tx6 message, but the improper
result is a program defect. This bug has been fixed, and it will not
appear in the -rc3 release.
4. Of course the default color-highlighting scheme for decoded messages
is not useful. In a contest we care only about dupes, and maybe
multipliers. Suitable color-highlighting for contesting has not yet
been implemented.
5. Double-clicking on a decoded message could result in setting the Tx
message to Tx2 rather than the correct Tx3. We will look carefully at
the cause, and correct it as necessary.
6. Most of us received messages decoded as "<...>", or perhaps something
like "<...> WZZZZZZZZ/". These were caused by another operator having
selected RTTY Roundup messages without also setting a valid exchange
(state, province, or "DX"). We were aware that a suitable validator for
"Exch" entries is needed, but we have not yet found time to implement it.
7. Transmitting RTTY Roundup messages with a bad or missing "Exch" entry
also puts faulty information in the QSO partner's cabrillo.log, as in
this example:
QSO: 14078 RY 2018-09-27 0257 XE1MEX 569 0001 VK7XX VK7XX RR73
8. At present list of valid state/province/DX abbreviations is as follows:
"AL ","AK ","AZ ","AR ","CA ","CO ","CT ","DE ","FL ","GA ",
"HI ","ID ","IL ","IN ","IA ","KS ","KY ","LA ","ME ","MD ",
"MA ","MI ","MN ","MS ","MO ","MT ","NE ","NV ","NH ","NJ ",
"NM ","NY ","NC ","ND ","OH ","OK ","OR ","PA ","RI ","SC ",
"SD ","TN ","TX ","UT ","VT ","VA ","WA ","WV ","WI ","WY ",
"NB ","NS ","QC ","ON ","MB ","SK ","AB ","BC ","NWT","NF ",
"LB ","NU ","VT ","PEI","DC "
Thus, MD, DE, and DC are allowed, but MDC (which at least one operator
used) is not.
Rule 5.2 of rules for the ARRL RTTY Roundup reads as follows:
"5.2. Multipliers: Each US state (except KH6 and KL7) plus the District
of Columbia (DC), Canadian provinces/territories: NB (VE1, 9), NS (VE1),
QC (VE2), ON (VE3), MB (VE4), SK (VE5), AB (VE6), BC (VE7), NWT (VE8),
NF (VO1), LB (VO2), NU (VYØ), YT (VY1), PEI (VY2) and each DXCC country.
KH6 and KL7 count only as separate DXCC entities."
9. Upon program restart, at least one user had trouble resetting the QSO
serial number to the proper number.
10. Users were warned not to use a compound or nonstandard callsign
during the mock contest. At least one user tried, nevertheless, with
predictably bad results.
I operated for a little over an hour during the test. I made 31 QSOs,
all correctly recorded in cabrillo.log. I did not use JTAlert, but I
opted to send logging information to N1MM+. As expected, the N1MM+ log
shows all QSOs but does not have correct signal reports or exchange
information.
From notes I kept during the test, here are a few additional ideas that
occurred to me:
1. In contest it might be best not to require clicking "OK" to log each
QSO. Instead, log the contact automatically when we receive or transmit
RR73 or 73.
2. We need to implement a simple way for a "Run" station to queue up the
next station to be called, during a QSO already in progress. This could
double the maximum possible QSO rate.
3. Activity during a real contest will not fit into a single 3 kHz
sub-band. We need to seek the best possible way to organize use of a
wider band, say 20 or 30 kHz, perhaps with dial frequencies spaced at
3 kHz intervals.
4. Would it be helpful to filter decoded messages so that transmissions
from already-worked stations don't appear in the left window?
5. Should there be a convention that "Run" stations transmit in the 1st
sequence, S+P stations in the 2nd?
Further comments and suggestions will be welcome!
-- 73, Joe, K1JT
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
