When I had the
situation earlier when no states were transferred, at that time I
hadn't set WSJT into contest mode, I was just having regular QSO's
and tried to log them, each one failed with an error of "invalid
abbreviation" in N3FJP. Once I put WSJT into contest mode, and
simulated a successful QSO, by first selecting a station, then
clicking Log QSO in WSJT, then filling in the blanks for the 4
fields I described before, then I was able to log a QSO and data
was transferred properly. I even created a Cabrillo log file and
it looked perfectly Ok.
Trying to Log to a N3FJP Contest Log when
WSJT-X is NOT in contest mode will not work. JTAlert has checks to
see if WSJT-X is in Contest mode and which Contest is selected,
this affects what JTAlert does under the hood and the structure of
the logging command sent to the Contest Log. By not having WSJT-X
in Contest mode, JTAlert defaults to the normal logging command
for ACLog and the Contest Log specific commands are not sent. This
is why the Contest Log was missing data.
What still puzzles
me is the fact when I click a station, the following happens: The
call sign is properly populated, RST R is populated with 599,
ST/PR/# is empty, RST S is populated with 599, and Country is
populated with the proper country name. I suspect that once the
first real exchange happens, all fields will be properly updated.
I wish we had a test run like they did before the contest in
December to see how it works under real life conditions. I trust
you that you tested everything and that it will work on Saturday.
All N3FJP Loggers utilise the same (exact)
lookup functions when a DX Call is initially sent to it. This is
what you observed when the DX Call in WSJT-X was changed.
