locked Re: UDP doesn't work between WSJTX running on another computer

HamApps Support (VK3AMA)

On 9/04/2018 4:00 AM, Brian wrote:
It seems that JTAlert must have wsjtx running on the same windows computer.  I am not sure why this is given that the two programs communicate via an internet protocol - UDP.  Another HAM buddy of mine uses HRD for his main log.  Installed JTAlert on the same Windows computer.  But, he installed wsjtx on a RaspberryPi.  I mentioned to him that I have been successful in a similar setup, but I use CQRLog (multi-platform) on a Linux computer (Ubuntu 16.04).  I indicated that I was able to configure the wsjtx running on Raspbian (RPi) to point to the nic's IP Address (network interface card) on the main shack computer (Ubuntu) and have CQRLog's wsjtx listener interface receive the UDP packets.  Worked really well.  Main log program on one computer and wsjtx on another computer.

However, JTAlert won't even start if you don't have wsjtx running on the local Windows computer.  What?  That seems odd.  A UDP server and client shouldn't care who is started first or second or where.  wsjtx sends periodic heartbeats on its UDP stream.  So a UDP server should be able to sync up.  Ok, to satisfy JTAlert's need to have the local version (on Windows) of wsjtx started, my buddy starts wsjtx.  It is not connected to his rig in anyway.  Interestingly enough, JTAlert recognizes the started wsjtx on windows.  But there is no traffic coming from that instance of wsjtx.  There is UDP traffic being streamed from the Raspberry PI at the Windows computer.  When the heartbeat and decodes start to arrive at the Windows server's doorstep from the wsjtx instance running on the RPi, JTAlert recognizes the packets and now works.  However, a JTAlert error comes up saying something like "array variable subscript badly formatted".  If he just leaves that error displayed (or move it off to the side), JTAlert continues to run happily.

Question and Request:
  • Why does JTALert require wsjtx to execute locally on the same computer when an internet protocol is being used to connect the two programs: wsjtx and JTAlert?
  • If there isn't a reason and this use case was not considered, I would like to request that the JTAlert UDP support allow for wsjtx to execute on another computer so that JTAlert can listen on a Windows computer's nic (not the loopback adaptor - for wsjtx UDP traffic.


While JTAlert communicates with WSJT-X via UDP, the code for WSJT-X support dates back to when WSJT-X didn't have the UDP interface, where communications with WSJT-X was via direct window manipulation/reading and monitoring of a WSJT-X status file.

When UDP was added, a decision was made to make that as painless as possible to the end user (zero changes needed), with no need for setting ip/port/filepaths, this is automatically handled by JTAlert reading the WSJT-X config file which JTAlert locates by determining the --rig-name of the running WSJT-X process. Each instance of WSJT-X has a unique config file and file location. Performance was also considered, potentially high-latency network comms (slow local networks, wifi, internet) would be detrimental to JTAlert responsiveness to decodes (especially now with FT8). The decision was made to have JTAlert work only with local WSJT-X processes.

Also, JTAlert supports up to 16 instances of WSJT-X with near zero setup required by the JTAlert user (only requiring the setting of unique udp ports in WSJT-X) for seamless multi-instance JTAlert/WSJT-X operation. Start the required number of WSJT-X instances followed by the same number of JTAlert instances, all automatic. There are many JTAlert users running multiple instances, some with 10 or more, 24x7.

I mention all the above to provide some insight into what is happening internally with JTAlert. While at first glance providing settings to manually specify the UDP port and IP is a trivial matter making that work with the current JTAlert code is far from trivial and would require a significant expenditure in time, coding and testing, to provide a facility to JTAlert V2 (which is near end-off-life) that may only be used by a very small number of users.

Yours is the first request I have had to allow JTAlert to work with a remote instance of WSJT-X (so the demand for such a facility is extremely low). While that is technically possible and rather simple using the UDP interface, it is far from simple implementing it within the current code. The uptake of such a feature would be very minimal among the JTAlert user-base, IMHO.

Spending precious coding time away from the higher priority JTAlert V3 coding,
I feel would be unwise. The
reward-for-effort ratio is too low to get your request onto the JTAlert V2 enhancement list at this time, sorry.

I have added your request to the todo/wish list, but implementation is unlikely until the new JTAlert V3 is released (still several months away). JTAlert V3 is being coded with no expectation that WSJT-X will be running locally, this also applies to the supported Loggers.

de Laurie VK3AMA

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