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


Brian
 

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 - 127.0.0.1) for wsjtx UDP traffic.

regards, 
Brian
VE3IBW


HamApps Support (VK3AMA)
 
Edited

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 - 127.0.0.1) for wsjtx UDP traffic.

regards, 
Brian
VE3IBW
Brian,

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
   


Brian
 

Hi Laurie, 

Thanks for the very thoughtful and insightful reply.

It is possible, from what you say about v3, that perhaps the interplay among a remote wsjtx instance and JTAlert will be possible with no additional work on your part.  This conjecture on my part is driven by your statement that the hard dependencies to wsjtx will be removed or softened in JTAlert v3.  I will test my use case when v3 becomes available. 

As long as JTAlert doesn't specifically reference the loopback adapter and instead uses the active NIC, then perhaps the configuration of JTAlert can remain as you have expressed with regards to just specifying the port to listen on.  From what I observed on the weekend, I would say JTAlert is listening on the active NIC's IP address and port successfully; of course after faking out JTAlert with a dummy instance of wsjtx on the same machine as JTAlert and leaving that wsjtx instance running.  The added bits of looking for a running wsjtx instance first and determining the port that wsjtx is emitting UDP packets on is a nice touch.  But, I am happy to change a port to something else for those cases where multiple wsjtx instances are running.  I think the default (2237) that wsjtx has established could be a default for JTAlert as well when no wsjtx configuration file can be found.  However, I understand your goal and the cases that you have described in your response.

I appreciate being put on the wish list.  I figured that my use case would be an outlier. 

regards, 
Brian
VE3IBW