locked JTAlert not communicating with WSTJ-X??


Floyd Sense
 

Have been using JTAlert and WSJT-X for a couple of years with no problems.  After not using the programs for a week, I fired up WSJT-X and JTAlert today and after some time got a nebulous message from JTAlert saying something about UDP to WSJT-X not working.  Running 2.4.0 of WSJT-X.  I downloaded the latest version of JTAlert, with same problem.  Followed instructions in JTAlert Help and here's the info from JTAlert:

JTAlert Instance       : #1
JTAlert Start Params   : /wsjtx
WSJT-X Window Title    : WSJT-X   v2.4.0   by K1JT, G4WJS, K9AN, and IV3NWV
WSJT-X Command Line    : "C:\WSJT\wsjtx\bin\wsjtx.exe"
WSJT-X   --rig-name    :
WSJT-X Config File     : C:\Users\floyd\AppData\Local\WSJT-X\WSJT-X.ini
WSJT-X Version         :
WSJT-X Revision        :
WSJT-X Spec Op Mode    : None
WSJT-X UDP ID          :
WSJT-X UDP Port        : 2237
WSJT-X UDP Server      : 224.0.0.1
WSJT-X UDP MCast on LB : True
WSJT-X UDP Max Schema  :

==================================================
UDP Ports used
--------------------------------------------------
JTAlert.exe           : 56694 59221
JTAlertV2.Manager.exe : 57669 57670 57671
JTAlertV2.Decodes.exe :


==================================================
Audio output devices
--------------------------------------------------
[1] Speakers (Synaptics HD Audio)
[2] Speakers (2- USB AUDIO  CODEC)


==================================================
JTAlertV2.Manager (2.50.5.0) status
(2021-08-16 19:33:06 utc)
--------------------------------------------------
CLR Version       : 5.0.6
NET Framework     : .NET 5.0.6
Architecture      : x64 64bit
--------------------------------------------------
UDP Router        : Initialized : YES (WSJT-X)
Audio             : Initialized : YES (2 output devices)
Activity Service  : Initialized : YES (started : 58)
Messaging Service : Initialized : YES (started : 17)
HamSpots Service  : Initialized : YES
QRZ Xml           : Initialized : YES
HamQth Xml        : Initialized : YES
QRZ Log           : Initialized : YES
HamQth Log        : Initialized : YES
ClubLog Log       : Initialized : YES
Eqsl Log          : Initialized : YES
HrdLog Log        : Initialized : YES
DXLab DDE         : Initialized : YES
User Alert        : Initialized : YES
Updates Check     : Initialized : YES (started : 3600)
Environment Check : Initialized : YES (started : 3600)
Maintenance       : Initialized : YES (started : 3600)
--------------------------------------------------

I followed the instructions and have the right stuff specified in WSTJ-X setup as seen here:



So, where do I go from here?  Since the previous version of JTAlert had the same problem, I'm assuming there is no sense in going back to that version. 

73, K8AC


Floyd Sense
 

Got this resolved.  My guess is that a recent Windows update disabled UDP or just the 2237 port.  If you Google "Windows 10 how to enable UDP" and look at some of the results, you'll see how it's done.  I enabled the port 2237 and went into Windows Firewall and added entries for WSJT-X and JTAlert.  After I did those things, I rebooted Windows and everything worked like it used to.  Ain't Windows fun!

73, Floyd - K8AC


HamApps Support (VK3AMA)
 

On 17/08/2021 5:46 am, Floyd Sense wrote:
Have been using JTAlert and WSJT-X for a couple of years with no problems.  After not using the programs for a week, I fired up WSJT-X and JTAlert today and after some time got a nebulous message from JTAlert saying something about UDP to WSJT-X not working.  Running 2.4.0 of WSJT-X.  I downloaded the latest version of JTAlert, with same problem.  Followed instructions in JTAlert Help and here's the info from JTAlert:

JTAlert Instance       : #1
JTAlert Start Params   : /wsjtx
WSJT-X Window Title    : WSJT-X   v2.4.0   by K1JT, G4WJS, K9AN, and IV3NWV
WSJT-X Command Line    : "C:\WSJT\wsjtx\bin\wsjtx.exe"
WSJT-X   --rig-name    :
WSJT-X Config File     : C:\Users\floyd\AppData\Local\WSJT-X\WSJT-X.ini
WSJT-X Version         :
WSJT-X Revision        :
WSJT-X Spec Op Mode    : None
WSJT-X UDP ID          :
WSJT-X UDP Port        : 2237
WSJT-X UDP Server      : 224.0.0.1
WSJT-X UDP MCast on LB : True
WSJT-X UDP Max Schema  :

The lack of "Version", "Revision" & "Schema" values in the above indicate that JTAlert never received any UDP data from WSJT-X as those values are directly read from the WSJTX UDP messages.

Are you running any other applications set to work with WSJTX?

Some possible reasons...
  • Since this is a recent development, than likely your PC Protect software has started interfering. Sorry, I cannot provide help with individual Protection software installations & setup.

  • WSJTX is running with elevated privileges (set to run as administrator). There is never any need to run WSJTX elevated. Check the properties of both the wsjtx.exe executable file AND the shortcut that is used to start WSJTX.

  • WSJTX is not monitoring decodes. There have been issues with WSJTX where it is not set to monitor and the UDP status or heartbeat messages are never sent. Enabling the Monitor button is enough to kick WSJTX into gear and start sending UDP messages.

  • Some other application is set to work with WSJTX directly and it is not using multicasting UDP thus locking JTAlert out because it has seized exclusive control of the 2237 port. Know applications that don't support multicast are DXLab SpotCollector, N1MM, Logger32. Also a default install of ACLog not correctly setup to use multicast.

  • I have seen on two different occasions, where the 224.0.0.1 multicast address did not work for some reason, switching to an alternate address like 239.255.0.1 then restarting both WSJTX & JTAlert was enough to restore UDP comms.

  • Windows needs a restart to apply any pending updates.

de Laurie VK3AMA


HamApps Support (VK3AMA)
 

On 17/08/2021 7:08 am, Floyd Sense wrote:
Got this resolved.  My guess is that a recent Windows update disabled UDP or just the 2237 port.  If you Google "Windows 10 how to enable UDP" and look at some of the results, you'll see how it's done.  I enabled the port 2237 and went into Windows Firewall and added entries for WSJT-X and JTAlert.  After I did those things, I rebooted Windows and everything worked like it used to.  Ain't Windows fun!

73, Floyd - K8AC

Tnx for the update Floyd. You can ignore my incoming message where I list multiple possible causes.

de Laurie VK3AMA


Floyd Sense
 

Laurie - I appreciate the prompt response to my problem.  It would be nice if I fully understood what happened so that I can deal with it quickly if and when it happens again.  While I have a pretty good understanding of Windows and communications in general, I haven't a clue what is meant by "multicasting" and frankly don't intend to spend any of my time left of earth learning what it is.  After all, all I'm after here is to be able to get my FT8 contacts logged to DXLab.  You asked what other apps might be communicating with WSJT-X - I use DXLab for logging, so I'd say that DXKeeper and SpotCollector are talking to WSJT-X.  Another thing confusing about the Multicasting thing: In my 2.16.17 version of JTAlert, JTAlert help recommends I specify the IP address for the UDP server in WSJT-X settings as 127.0.0.1, and that works.  In the 2.50.x version of JTAlert, it recommends 224.0.0.1.  I tried that and it did not work and the 239 series of addresses got me another nebulous error message.  It would be useful if you could add something to the help explanation that explains why the different address ranges and why we should care about multicasting.  Apparently, I'm NOT using multicasting now and all is working just fine.

73, Floyd - K8AC


HamApps Support (VK3AMA)
 

On 17/08/2021 7:33 am, Floyd Sense wrote:
Laurie - I appreciate the prompt response to my problem.  It would be nice if I fully understood what happened so that I can deal with it quickly if and when it happens again.  While I have a pretty good understanding of Windows and communications in general, I haven't a clue what is meant by "multicasting" and frankly don't intend to spend any of my time left of earth learning what it is.  After all, all I'm after here is to be able to get my FT8 contacts logged to DXLab.  You asked what other apps might be communicating with WSJT-X - I use DXLab for logging, so I'd say that DXKeeper and SpotCollector are talking to WSJT-X.  Another thing confusing about the Multicasting thing: In my 2.16.17 version of JTAlert, JTAlert help recommends I specify the IP address for the UDP server in WSJT-X settings as 127.0.0.1, and that works.  In the 2.50.x version of JTAlert, it recommends 224.0.0.1.  I tried that and it did not work and the 239 series of addresses got me another nebulous error message.  It would be useful if you could add something to the help explanation that explains why the different address ranges and why we should care about multicasting.  Apparently, I'm NOT using multicasting now and all is working just fine.

73, Floyd - K8AC

I changed from recommending the unicast 127.0.0.1 setup to the multicast 224.0.0.1 setup because when I provided instructions for both (which still works) people couldn't or wouldn't follow the instructions, so I did a Microsoft and dumbed it down, rather than providing setup instructions where the user gets to make choices, I just provide a fixed set of instructions without confusing the issue with alternatives or user choices.

Mutlicast was chosen due to the number of applications that are now working with WSJTX directly. For multiple concurrently running applications working with WSJTX, the only way to get that to work correctly is to have all participating applications use multicast UDP. There is no choice, this is  not a JTAlert restriction, it is how WSJTX is designed. That all falls in a heap however if the other applications don't support multicast due to the how they were coded. There is nothing to do in those situations except to pick which you want to work with WSJTX and not use the others that get locked out.

de Laurie VK3AMA
 


Floyd Sense
 

Laurie - thanks again for the explanations.  I'd like to offer a general suggestion for improvement that would make life easier for both newcomers and experienced users who find that their previously working setup no longer works.  You and the other authors of software in this realm (WSJT-X, DXLab, JTAlert, et al) ought to sit down together at some gathering (like the Dayton Hamvention) and take a hard look at the big picture of getting all these pieces/parts working together.  Each of you has his own version of the intracacies of getting all this to work together and not all agree.  Example: AA6YQ, DXLab author, can go to great lengths explaining why there is no need for using multicasting.  The fact is, you can get things to work using multicasting or NOT using multicasting. 

I use JTAlert for one reason only: It seems to be the only way to get DXLab's DXKeeper to log my FT8/FT4 QSOs as they happen.  There really ought to be a short cut for making that happen without getting bogged down in all the other JTAlert issues.

And, another big-picture peave of mine: It sure would be nice if there were a single place to look for an indication of whether a specific WSJT-X decoded call sign would satisfy my needs as a new DXCC country, Marathon country, etc.  Every piece of software seems to think it important to color the decoded call signs according to some arcane set of rules particular to that piece of software.  The only one that counts for me is what DXKeeper thinks based on what's in my log database.  But, since DXKeeper doesn't do multicasting, those colors can't be set?  Each set of software seems to have its own unique database of what's needed and those need to be synced with one another?  There must be a better way of doing things.

But, getting back to my original problem, JTAlert not communicating with WSJT-X: We really have no idea why, after 2,783 properly logged QSOs using JTAlert and DXKeeper, it suddenly stopped working.  Maybe a Windows update caused it, but I just don't know.  What I do know is this: As things sit today, if you are a DXLab user, you MUST use JTAlert if you want WSJT-X QSOs logged to DXKeeper, BUT, to do that, YOU MUST NOT CHECK THE ENABLE BOX IN THE WSJT-X PANEL OF SPOTCOLLECTOR - SPOT SOURCES IN SPOTCOLLECTOR CONFIG.  If you do check that box, what happens regarding logging will depend on whether you start JTAlert or SpotCollector first.  If you start JTAlert first, logging will work and the Spotcollector enable box will be silently disabled.  If you start SpotCollector first, JTAlert will not connect to WSJT-X and then of course logging to DXKeeper will NOT work.  

Now, back to working DX.



73, Floyd - K8AC


Tom Melvin
 

Floyd

While I don’t have an real issue getting the components talking to each other - I would point out - JTAlert (Free) author in Australia, WSJT-X (Free) primary support developer in UK, Log4OM (Free) author UK, GridTracker (Free) author US, DXLabs (Free?) author - US.

One common issue ‘free' - getting a pile of people in multiple continents to travel - even if it was permitted due to Covid who is going to fund this. I doubt the authors will.

Add in the other versions of WSJT-X - MSHV, JTDX, WSJTX-Z, WSJT-X (modified) - some are not even happy to discuss a standard and have pulled core features out of their version.

I can see zero possibility of getting together to sort it - there is a pretty good standard that 90% of the packages support - most of the packages have pretty good guides - but then who reads guides - who even looks at forum/reflector posts.

Developers try to please as many people as possible - that is why there are options for some obscure packages. In some cases it may be the changes needed to ‘work happily’ with other packages is not possible.  That is why you see a pile of ‘Depreciated’ options appearing - work arounds that were used in past - as communications between ‘modules’ are more and more standard these work arounds can be removed.  You can’t force users to do something - the B4 definition - in WSJT-X it depends on a text file that people truncate periodically, JTAlert can use a file or ‘proper’ logger program - need to support multiple loggers - colours always will have to be user definable due to users vision requirements. You can’t force users to use a specific logger.

Having said all that one of the biggest issues is OS support, whether it’s MicroSoft upgrades, new cutting edge version of Linux, The posts are showing more and more issues with the OS blocked traffic - the OS vendor has decided no-one really should be using port XYZ so it’s blocked. Many anti-virus packages will not let the user know - they expect users to read the manual/release notes - but we know the answer to that.

So I suspect there will be no quick solution - you will have to rely on authors updating release notes / FAQ / On-Line support forums. Keep in mind it many not be author’s fault - the OS can come into play

Enjoy the DX - 6m is open here at present so working some here as well

Tom
GM8MJV


On 17 Aug 2021, at 15:09, Floyd Sense <floydsense@...> wrote:

Laurie - thanks again for the explanations.  I'd like to offer a general suggestion for improvement that would make life easier for both newcomers and experienced users who find that their previously working setup no longer works.  You and the other authors of software in this realm (WSJT-X, DXLab, JTAlert, et al) ought to sit down together at some gathering (like the Dayton Hamvention) and take a hard look at the big picture of getting all these pieces/parts working together.  Each of you has his own version of the intracacies of getting all this to work together and not all agree.  Example: AA6YQ, DXLab author, can go to great lengths explaining why there is no need for using multicasting.  The fact is, you can get things to work using multicasting or NOT using multicasting. 

I use JTAlert for one reason only: It seems to be the only way to get DXLab's DXKeeper to log my FT8/FT4 QSOs as they happen.  There really ought to be a short cut for making that happen without getting bogged down in all the other JTAlert issues.

And, another big-picture peave of mine: It sure would be nice if there were a single place to look for an indication of whether a specific WSJT-X decoded call sign would satisfy my needs as a new DXCC country, Marathon country, etc.  Every piece of software seems to think it important to color the decoded call signs according to some arcane set of rules particular to that piece of software.  The only one that counts for me is what DXKeeper thinks based on what's in my log database.  But, since DXKeeper doesn't do multicasting, those colors can't be set?  Each set of software seems to have its own unique database of what's needed and those need to be synced with one another?  There must be a better way of doing things.

But, getting back to my original problem, JTAlert not communicating with WSJT-X: We really have no idea why, after 2,783 properly logged QSOs using JTAlert and DXKeeper, it suddenly stopped working.  Maybe a Windows update caused it, but I just don't know.  What I do know is this: As things sit today, if you are a DXLab user, you MUST use JTAlert if you want WSJT-X QSOs logged to DXKeeper, BUT, to do that, YOU MUST NOT CHECK THE ENABLE BOX IN THE WSJT-X PANEL OF SPOTCOLLECTOR - SPOT SOURCES IN SPOTCOLLECTOR CONFIG.  If you do check that box, what happens regarding logging will depend on whether you start JTAlert or SpotCollector first.  If you start JTAlert first, logging will work and the Spotcollector enable box will be silently disabled.  If you start SpotCollector first, JTAlert will not connect to WSJT-X and then of course logging to DXKeeper will NOT work.  

Now, back to working DX.



73, Floyd - K8AC


Floyd Sense
 

All good points, Tom.  Another member of this group questioned why I was using JTAlert at all since I don't need the functions it provides.  Turns out that was an excellent question.  When I got started with WSJT-X three years or so ago, I was told that JTAlert was required to provide the interface to my logging program and that seems to have been correct.  It turns out that today, it's no longer required and the logging program can receive logged QSO info directly from WSJT-X.  I'm sure that if I went back through all the release notes for the logging program I would find the info on when that happened.  But, with scores of programs in daily use, I choose not to read the detailed update info on every one of them.  And of course, there's the OS changes you mention and those are rarely documented.  It would be nice if there were a "standards organization" to help establish some common interfaces to both software and hardware for ham related stuff, but guess there just isn't the justification for that when the software is free.

73, Floyd - K8AC


Michael Black
 

One of my favorite sayings..."That's the nice thing about standards...there are so many to choose from."

Mike W9MDB




On Tuesday, August 17, 2021, 10:32:56 AM CDT, Floyd Sense <floydsense@...> wrote:


All good points, Tom.  Another member of this group questioned why I was using JTAlert at all since I don't need the functions it provides.  Turns out that was an excellent question.  When I got started with WSJT-X three years or so ago, I was told that JTAlert was required to provide the interface to my logging program and that seems to have been correct.  It turns out that today, it's no longer required and the logging program can receive logged QSO info directly from WSJT-X.  I'm sure that if I went back through all the release notes for the logging program I would find the info on when that happened.  But, with scores of programs in daily use, I choose not to read the detailed update info on every one of them.  And of course, there's the OS changes you mention and those are rarely documented.  It would be nice if there were a "standards organization" to help establish some common interfaces to both software and hardware for ham related stuff, but guess there just isn't the justification for that when the software is free.

73, Floyd - K8AC


Tom Melvin
 

Yup standard in one place do seem to differ from others - not just radio related between regions - metric / imperial come to mind :-)

Ok Floyd -  in years gone by you needed to use the ‘forward’ option to have a package in the middle now that has been bypassed so the ‘Why do you need xyz’ type question is very valid as packages grow and direct support is added.

Regards

Tom
GM8MJV


On 17 Aug 2021, at 16:41, Michael Black via groups.io <mdblack98@...> wrote:

One of my favorite sayings..."That's the nice thing about standards...there are so many to choose from."

Mike W9MDB




On Tuesday, August 17, 2021, 10:32:56 AM CDT, Floyd Sense <floydsense@...> wrote:


All good points, Tom.  Another member of this group questioned why I was using JTAlert at all since I don't need the functions it provides.  Turns out that was an excellent question.  When I got started with WSJT-X three years or so ago, I was told that JTAlert was required to provide the interface to my logging program and that seems to have been correct.  It turns out that today, it's no longer required and the logging program can receive logged QSO info directly from WSJT-X.  I'm sure that if I went back through all the release notes for the logging program I would find the info on when that happened.  But, with scores of programs in daily use, I choose not to read the detailed update info on every one of them.  And of course, there's the OS changes you mention and those are rarely documented.  It would be nice if there were a "standards organization" to help establish some common interfaces to both software and hardware for ham related stuff, but guess there just isn't the justification for that when the software is free.

73, Floyd - K8AC