locked JTAlert and N3FJP ARRL RTTY Log


AI3KS
 

I am posting this both in the HamApps and N3FJP Forums, so please excuse the extra bandwidth.
I must be missing something simple but I can't get JTAlert to properly log to N3FJP RTTY Log.

Running:
N3FJP RTTY Roundup Log 3.6
JTAlert 2.12.10
WSJT-X 2.0.0
Windows 10

JTAlert says I am connected to RCL and RU.

When I log a simulated QSO, JTAlert puts the State in the RST Rcvd field and the qso doesn't log. In the WSJT-X contest log, all is well. I have checked the remote PC settings and they look ok. I even tried checking the boxes to have the exchanges logged in the "other"fields and they remain blank.

I uninstalled and reinstalled RTTY Log.

I also tried the Field Day log and that works OK.

If I remember correctly, I even had a misconfiguration where I was running Roundup on WSJT-X with  RTTY Log but had the Field Day Log and Field Day File settings on JTAlert and it then did log the "Other" Fields but still didn't log the fill in the state in RTTY Log.

What am I missing?

Thanks,

Steve, AI3KS


Carey, WB4HXE
 

Steve,
If you click on the ? in the header of JTAlert, Laurie has provided detailed setup information for various contests. I've used it in a test and his instructions work exactly right when followed exactly. I'm at work now but let me know if you need help with it later tonight.
73, Carey, WB4HXE


--
Carey Fisher


JTAlert Support (VK3AMA)
 

On 4/01/2019 2:22 am, Steve Kennick wrote:
I am posting this both in the HamApps and N3FJP Forums, so please excuse the extra bandwidth.
I must be missing something simple but I can't get JTAlert to properly log to N3FJP RTTY Log.

Running:
N3FJP RTTY Roundup Log 3.6
JTAlert 2.12.10
WSJT-X 2.0.0
Windows 10

JTAlert says I am connected to RCL and RU.

When I log a simulated QSO, JTAlert puts the State in the RST Rcvd field and the qso doesn't log. In the WSJT-X contest log, all is well. I have checked the remote PC settings and they look ok. I even tried checking the boxes to have the exchanges logged in the "other"fields and they remain blank.

I uninstalled and reinstalled RTTY Log.

I also tried the Field Day log and that works OK.

If I remember correctly, I even had a misconfiguration where I was running Roundup on WSJT-X with  RTTY Log but had the Field Day Log and Field Day File settings on JTAlert and it then did log the "Other" Fields but still didn't log the fill in the state in RTTY Log.

What am I missing?

Thanks,

Steve, AI3KS

Steve,

Did you follow the Setup instructions in the JTAlert help file?

You mention logging of Other fields, The Other fields only apply to ACLog, none of the N3FJP Contest loggers. If your seeing successful logging of Other fields, that indicates your using ACLog, not a Contest Logger. See the help file ("Tutorials -> N3FJP Contest Logs Logging" topic) for correct N3FJP Contest Loggers setup.

de Laurie VK3AMA


Bernd - KB7AK
 

I followed the setup instructions in the help file and I still have the problem that the State/Province field is blank. If I simulate logging a QSO by clicking on Log QSO in WSJT and fill in the blanks, Rpt S, Rpt R, Exch S, and Exch R, then the QSO gets logged correctly with the state filled in. I will wait until Saturday to check how this works in the real world.

In the setup instructions, the title bar is described as having two additional codes set based on the contest. Based on the description I would expect those two codes to state "[RRL]" and "[RU]", mine are "[RCL]" and "[RU]", so only a match on the second code but not on the first.


JTAlert Support (VK3AMA)
 

Responses inline...

On 4/01/2019 1:20 pm, Bernd - KB7AK wrote:
I followed the setup instructions in the help file and I still have the problem that the State/Province field is blank. If I simulate logging a QSO by clicking on Log QSO in WSJT and fill in the blanks, Rpt S, Rpt R, Exch S, and Exch R, then the QSO gets logged correctly with the state filled in. I will wait until Saturday to check how this works in the real world.
Please describe the steps your performing that result in no State transfer. Are the Log QSO window exchanges fields correctly populated, I suspect they aren't.

If your manually entering the exchanges in the WSJT-X Log QSO window and they are correctly logged. This indicates that the non-manual method your using is likely not filling in those exchanges. How are you performing your tests?

In the setup instructions, the title bar is described as having two additional codes set based on the contest. Based on the description I would expect those two codes to state "[RRL]" and "[RU]", mine are "[RCL]" and "[RU]", so only a match on the second code but not on the first.
"RCL" is correct. There were several iterations of the naming convention before I settled. The help file got out of sync with what JTAlert displays. "RRL" in the help file is incorrect, it should have read "RCL".

de Laurie VK3AMA


Bernd - KB7AK
 

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.

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.

I hope that clears up any confusion I might have caused. 


Michael Black
 

There is a test run scheduled.  Enclosed below
de Mike W9MDB
================================================
Please share this notice with your local groups, as appropriate.

Same time and same drill as in recent years. This coming Friday, let's have two practice sessions to check out station equipment, software and operator(s).

New in 2019! Practice for both RTTY and FT8! Here's the schedule:

2200-2230 UTC, Friday, 5 January - RTTY focus
2230-2300 UTC, Friday, 5 January - FT8 focus

0200-0230 UTC, Saturday, 6 January (Friday evening NA time) - RTTY focus
0230-0300 UTC, Saturday, 6 January (Friday evening NA time) - FT8 focus

"Focus" means lets focus on that mode for the 30 minutes - but if you want to practice switching back and forth between modes by all means do so. I expect you'll find others of a like mind.

Operate just like it's the real thing that starts on Saturday. Use whatever bands are open and active for you at each time slot. For FT8, the following dial frequencies as recommended by Joe K1JT in the January 2019 QST would be a good starting place: 3590, 7080**, 14130, 21130, 28160.

You might want to have a special message prepared to respond to stations telling you that the contest hasn't yet started. (Or, perhaps even practice your typing ;)

Most of all, have fun over the weekend in the RTTY Round-Up! Take some photos of your operation and send them and/or a summary of your experience to me, Jeff WK6I - especially anything around your decisions on how to use (or not use) FT8. It will help me write up the contest for the QST article.

73 jeff wk6i

** Below is a link to the article by Joe K1JT for reference. You may notice that the recommended frequencies for 80 and 40 meters are in typical RTTY subbands. FT8 ops may want to slide up above 7100 or below 3580 if they are having trouble getting a foothold in the recommended ranges.


-- 
Jeff Stai ~ WK6I ~ wk6i.jeff@...
Ask me about Green Keys Night - Jan 1, 2019 0000-2359 UTC!
RTTY op at W7RN
Twisted Oak Winery ~ http://www.twistedoak.com/


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



Bernd - KB7AK
 

Thanks Laurie, might be worth while to add a sentence or two to the help file, I am sure there are others who may fall into the same trap I did since my default logging program doesn't really care which mode WSJT runs in, so it wasn't obvious to me.

It'll all be good, I am looking forward to use this combo of apps for the contest.


AI3KS
 

Carey,

Thanks for the help. I figured out that my problem was self inflicted. In my manual qsos I was not entering the full exchange in the WSJT-X Log screen, only the state.

73,

Steve, AI3KS


AI3KS
 

Laurie,

Thanks for the help. I figured out that my problem was self inflicted. In my manual qsos I was not entering the full exchange in the WSJT-X Log screen, only the state.

73,

Steve, AI3KS


JTAlert Support (VK3AMA)
 

On 5/01/2019 12:48 am, Steve Kennick wrote:
Thanks for the help. I figured out that my problem was self inflicted. In my manual qsos I was not entering the full exchange in the WSJT-X Log screen, only the state.

73,

Steve, AI3KS
Steve,

That is to be expected. Without a correctly formatted exchange, the N3FJP Contest logger may have difficulty logging the correct data.

JTAlert doesn't manipulate the exchange received from WSJT-X, it simply forwards the data onto the logger in a correctly coded logging command. The logger does the validation of the exchange and recording of the data.

The problems experienced by some users have all been due to manually entering exchanges in WSJT-X, rather than having WSJT-X generate the exchange. Eg for the RTTY Roundup the received exchange (that gets sent to the Contest Log) should be of the form "RST State" or "RST SerialNo".

de Laurie VK3AMA


JTAlert Support (VK3AMA)
 

On 5/01/2019 12:48 am, Steve Kennick wrote:
Thanks for the help. I figured out that my problem was self inflicted. In my manual qsos I was not entering the full exchange in the WSJT-X Log screen, only the state.

73,

Steve, AI3KS
A State only exchange is not valid and as a result the N3FJP logger which extracts the State or serial number from the exchange fails. Exchanges should only be of the form "RST State" or "RST SerialNo".

When WSJT-X is allowed to generate the exchanges, they are correctly formatted and the Contest Log will work correctly as you observed. "All bets are off" if exchanges are manually entered and they don't follow the exchange rules of the Contest. JTAlert doesn't validate what is being logged by WSJT-X, it simply acts as a bridge to get the data to the Contest logger.

de Laurie VK3AMA


Herschel Hall
 

I used it in the test tonight & it works great, thanks Laurie


On Fri, Jan 4, 2019 at 8:41 PM HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:
On 5/01/2019 12:48 am, Steve Kennick wrote:
Thanks for the help. I figured out that my problem was self inflicted. In my manual qsos I was not entering the full exchange in the WSJT-X Log screen, only the state.

73,

Steve, AI3KS
A State only exchange is not valid and as a result the N3FJP logger which extracts the State or serial number from the exchange fails. Exchanges should only be of the form "RST State" or "RST SerialNo".

When WSJT-X is allowed to generate the exchanges, they are correctly formatted and the Contest Log will work correctly as you observed. "All bets are off" if exchanges are manually entered and they don't follow the exchange rules of the Contest. JTAlert doesn't validate what is being logged by WSJT-X, it simply acts as a bridge to get the data to the Contest logger.

de Laurie VK3AMA


JTAlert Support (VK3AMA)
 

On 5/01/2019 2:28 pm, Herschel Hall wrote:
I used it in the test tonight & it works great, thanks Laurie
Herschel,

Thanks for the report. Good to hear.

de Laurie VK3AMA


k3np@...
 

This fix worked for me--The state was not getting passed to my N3FJP RTTY contest log. I clicked the ? in JTAlert, searched for "RTTY" and found a topic with screenshots of how/what to set. It had me change from local PC to networked connection and also had me specify the location of the RTTY log file. Hopefully I can remember how to set it all back the way it was after the contest :D 

73 de Andy K3NP


Michael Ernst
 

 

Andy, is yours populating your sent or do you have to type that in manually each time?

 

73,

Mike, AE8U

 

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of k3np@...
Sent: Saturday, January 5, 2019 3:37 PM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] JTAlert and N3FJP ARRL RTTY Log

 

This fix worked for me--The state was not getting passed to my N3FJP RTTY contest log. I clicked the ? in JTAlert, searched for "RTTY" and found a topic with screenshots of how/what to set. It had me change from local PC to networked connection and also had me specify the location of the RTTY log file. Hopefully I can remember how to set it all back the way it was after the contest :D 

73 de Andy K3NP


k3np@...
 

Hi Mike--

No, it's populating it. The only thing that wasn't getting populated was the state and that resolved after I changed the settings as describeed above. 

73,

Andy K3NP


John K9IJ
 

That's a strange fix :) but it worked for me too.

John - K9IJ

On 1/5/2019 2:37 PM, k3np@... wrote:
This fix worked for me--The state was not getting passed to my N3FJP RTTY contest log. I clicked the ? in JTAlert, searched for "RTTY" and found a topic with screenshots of how/what to set. It had me change from local PC to networked connection and also had me specify the location of the RTTY log file. Hopefully I can remember how to set it all back the way it was after the contest :D 

73 de Andy K3NP

-- 
No trees were killed in the sending of this message. However, a large number of electrons were terribly inconvenienced !

k9ij@...
Webmaster, Network Admin, Janitor


Michael Ernst
 

Not sure why, but my setup is not populating my sent RST and I have to manually type it in each time.

 

Mike, AE8U

 

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of k3np@...
Sent: Saturday, January 5, 2019 4:24 PM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] JTAlert and N3FJP ARRL RTTY Log

 

Hi Mike--

No, it's populating it. The only thing that wasn't getting populated was the state and that resolved after I changed the settings as describeed above. 

73,

Andy K3NP