locked Re: JTAlert and N3FJP ARRL RTTY Log


JTAlert Support (VK3AMA)
 

Responses inline...

On 4/01/2019 4:27 pm, Bernd - KB7AK wrote:
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.

de Laurie VK3AMA


Join Support@HamApps.groups.io to automatically receive all group messages.