locked How JTAlert communicates with WSJT-Xand logger such as HRD


KT7AZ
 

I have found bits and pieces of how JTAlert connects to WSJT-X and with logging programs such as HRD.  It would really help if there was a flow chart or diagram as to what happens under the hood.  Such as how data is transferred between the programs, etc.

Thanks

Gary
--
KT7AZ


g4wjs
 

On 10/03/2021 16:50, KT7AZ wrote:

I have found bits and pieces of how JTAlert connects to WSJT-X and with logging programs such as HRD.  It would really help if there was a flow chart or diagram as to what happens under the hood.  Such as how data is transferred between the programs, etc.

Thanks

Gary
--
KT7AZ
Hi Gary,

I can speak about how JTAlert and WSJT-X exchange information.

WSJT-X instances are configured to send information packets (UDP datagrams) to a specified server application (an IP address or host name along with a service port number), that server listens on the host and service port and can be JTAlert. The data packets include each decode as it happens, changes in key status values like mode, and other dynamic status information like frequency etc.. The server may also reply to these messages with other messages that can "drive" WSJT-X in a few specific ways, like initiating a QSO with a station previously decode calling CQ. The protocol optionally allows for multiple servers to interoperate with WSJT-X instances sharing the same server service port number by using a technique called multicast group addressing.

I am not an expert on how JTAlert interoperates with HRD, but I believe the HRD logbook is a TCP/IP server that other applications, like JTAlert, can feed logged QSO information. I also believe HRD does not provide a logbook lookup facility via that channel, so JTAlert may also open the HRD logbook database directly for read-only access to query worked before status etc..

Rather confusingly HRD is also able to take network traffic sent from WSJT-X, although that feed was never intended for that purpose. That feed has only the basic ADIF information of logged QSOs accepted in WSJT-X. This channel is via UDP sent to a different host and service port pair specified in WSJT-X, currently named as the "Secondary UDP Server (deprecated)" in "Settings->Reporting", deprecated because the N1MM Logger+ application, for which it was originally intended, now use the preferred UDP feed I mention above.



--
73
Bill
G4WJS.


Admin <n4fwd.ar@...>
 

I am trying to get JTAlert 2.16.17 to talk with WSJT-X 2.3.0. Both programs are running on Linux Mint 20.1. I seem to have hit a snag with the UDP server settings. Searching online, I have tried the 127.0.0.1:2237 with the three check-boxes enabled on the right side of that Reporting menu area.
JTAlert gives me the following alerts:
First window: Reading settings data
                       Standby
Second window: Waiting for WSJT-X to start
                            WSJT-X must be running before JTAlert can continue

I tried different versions of JTAlert and all of them give me the same alerts as above.

Any suggestions?


g4wjs
 

On 16/03/2021 13:42, N4FWD wrote:
I am trying to get JTAlert 2.16.17 to talk with WSJT-X 2.3.0. Both programs are running on Linux Mint 20.1. I seem to have hit a snag with the UDP server settings. Searching online, I have tried the 127.0.0.1:2237 with the three check-boxes enabled on the right side of that Reporting menu area.
JTAlert gives me the following alerts:
First window: Reading settings data
                       Standby
Second window: Waiting for WSJT-X to start
                            WSJT-X must be running before JTAlert can continue

I tried different versions of JTAlert and all of them give me the same alerts as above.

Any suggestions?
OM,

I was under the impression that JTAlert was a MS Windows only application, how are you running it on Linux?



--
73
Bill
G4WJS.


HamApps Support (VK3AMA)
 

On 17/03/2021 5:06 am, g4wjs wrote:
I was under the impression that JTAlert was a MS Windows only application, how are you running it on Linux?

--
73
Bill
G4WJS.
That's the case. JTAlert is Windows only.
Currently, there are no plans to migrate to Linux or MacOS.

de Laurie VK3AMA


N4FWD <n4fwd.ar@...>
 

In answer to the question "how are you running it on Linux?", WINE 6.4 and some Microsoft components.
More information:
 Using various networking tools, I determined that initially, JTAlert does not listen to port 2237 on address 127.0.0.1. I have surmised is that JTAlert is using a different Microsoft method to determine that wsjtx is running.
I can see that wsjtx is sending the UDP packets to 127.0.0.1:2237. I can see the JTAlert is opening listening ports. I do not see a listening port being opened on 127.0.0.1:2237.

It is a shame that JTAlert is locked down to Microsoft as it looks like a great program.


N4FWD <n4fwd.ar@...>
 

There is no need to port JTAlert to Linux or MacOS. Instead of looking for wsjtx, if JTAlert would simply listen for UDP packets on 127.0.0.1:2237 as the documentation says, then I believe that it would work just fine.


Michael Black
 

It's looking for the WSJT-X.ini file to get the port settings.

The path would be %LOCALAPPDATA%\WSJT-X\WSJT-X.ini

Where the WSJT-X directory also includes the -r switch of WSJT-X if used.  So "wsjtx -r test" would be "WSJT-X - test"

So you need to figure out where %LOCALAPPDATA% is and probably do a hard link to WSJT-X.ini

Found this info that should help.

The Application Data folder is saved in the APPDATA environment variable.

You can see its value by running: (a weird combination of wine and Unix  )
wine cmd /c set|grep APPDATA

The output you recieve should look like this:
APPDATA=C:\windows\profiles\mohag\Application Data
LOCALAPPDATA=C:\windows\profiles\mohag\Local Settings\Application Data

The physical folder would then be
~/.wine/drive_c/windows/profiles/`whoami`/Application" "Data


Mike W9MDB

On Wednesday, March 17, 2021, 06:29:42 AM CDT, N4FWD <n4fwd.ar@...> wrote:


In answer to the question "how are you running it on Linux?", WINE 6.4 and some Microsoft components.
More information:
 Using various networking tools, I determined that initially, JTAlert does not listen to port 2237 on address 127.0.0.1. I have surmised is that JTAlert is using a different Microsoft method to determine that wsjtx is running.
I can see that wsjtx is sending the UDP packets to 127.0.0.1:2237. I can see the JTAlert is opening listening ports. I do not see a listening port being opened on 127.0.0.1:2237.

It is a shame that JTAlert is locked down to Microsoft as it looks like a great program.


N4FWD <n4fwd.ar@...>
 

Mike W9MDB, Thank you for the insight into where JTAlert is looking for its "flag" that wsjtx is installed. 


N4FWD <n4fwd.ar@...>
 

After much testing and trying different approaches to the communication problem, I have to agree with the author that JTAlert will never be ported to Linux or MacOS. From what I have been able to determine, JTAlert does all the setup programmically (ie. the Microsoft way of doing things). Porting such a program would entail a major re-write of the internals.

Thank you to all who assisted me with this experiment. Just my opinion, Python and N3FJP Logging software do a better job of logging and alerting.


HamApps Support (VK3AMA)
 

On 17/03/2021 10:29 pm, N4FWD wrote:
I have surmised is that JTAlert is using a different Microsoft method to determine that wsjtx is running.

JTAlert at startup enumerates the running wsjtx.exe processes running on the local machine. It does this so that it can provide a zero-setup experience for the end-user (for the JTAlert<->WSJT-X interaction). Enumerating the running processes is also critical in providing automatic multi-instance support (again with zero settings).

de Laurie VK3AMA


HamApps Support (VK3AMA)
 

On 18/03/2021 6:31 am, N4FWD wrote:
Thank you for the insight into where JTAlert is looking for its "flag" that wsjtx is installed.

FYI, JTAlert doesn't go looking for the WSJT-X config (.ini) file until it has detected a running instance of WSJT-X running on the local machine.
If WSJT-X is not detected running on the local PC, JTAlert never goes looking for the .ini file, it waits until WSJT-X is started.

de Laurie VK3AMA
 


d_ziolkowski
 

"Just my opinion, Python and N3FJP Logging software do a better job of logging and alerting."

compared to what?

Dan KC2STA

On Wed, Mar 17, 2021 at 5:28 PM N4FWD <n4fwd.ar@...> wrote:
After much testing and trying different approaches to the communication problem, I have to agree with the author that JTAlert will never be ported to Linux or MacOS. From what I have been able to determine, JTAlert does all the setup programmically (ie. the Microsoft way of doing things). Porting such a program would entail a major re-write of the internals.

Thank you to all who assisted me with this experiment. Just my opinion, Python and N3FJP Logging software do a better job of logging and alerting.



--
Dan Ziolkowski KC2STA
SKCC #4290T
Ubuntu LINUX


 

For what it is worth, I have both JT-Alert running, on the Windows box that hosts WSJT-X, and JT-Bridge (https://jt-bridge.eller.nu) running on my MacBook Air connecting to Aether (https://aetherlog.com) for logging. It works for me. Particularly, as a lot of the time I am connecting to the Windows machine using VNC from the MacBook to operate. 
Ah! The joys of a mixed environment :-)
Doug VK2EY/N1KIQ


HamApps Support (VK3AMA)
 

On 18/03/2021 10:08 pm, d_ziolkowski wrote:
"Just my opinion, Python and N3FJP Logging software do a better job of logging and alerting."

compared to what?

Dan KC2STA

Don't worry about it. It was a troll post, IMO.
That individual joined the group to post a couple of messages and promptly left the group within 30 seconds after posting the above comment.

de Laurie VK3AMA


Brian (N2MLP)
 

Would stay away from HRD

 

========================

         de N2MLP Brian

       Monroe County PA

 

 

========================

 

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of N4FWD
Sent: Wednesday, March 17, 2021 5:27 PM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] How JTAlert communicates with WSJT-Xand logger such as HRD

 

After much testing and trying different approaches to the communication problem, I have to agree with the author that JTAlert will never be ported to Linux or MacOS. From what I have been able to determine, JTAlert does all the setup programmically (ie. the Microsoft way of doing things). Porting such a program would entail a major re-write of the internals.

Thank you to all who assisted me with this experiment. Just my opinion, Python and N3FJP Logging software do a better job of logging and alerting.