locked window not showing decoded callsigns


Tory Wiedenkeller
 

I'm not sure what setting I messed up. I had the decode window showing the incoming callsigns, but now it's not showing them.

What do I need to change so this window shows decoded callsigns? Thanks


HamApps Support (VK3AMA)
 

On 27/05/2021 1:40 pm, Tory Wiedenkeller wrote:

I'm not sure what setting I messed up. I had the decode window showing the incoming callsigns, but now it's not showing them.

What do I need to change so this window shows decoded callsigns? Thanks


Open the Settings of the Main JTAlert window and navigate to the "Window -> Decodes" section and tick the enable box.

de Laurie VK3AMA


Tory Wiedenkeller
 


Ok, I did as you suggested.  When I got in to the Decodes pane, the box was already 'enabled.'

Additionally, I do have the .net file installed. I also installed the 64 bit version for WSJT-X, which is what I'm running.
No offense, but the previous version was much more easily installed and used. 

In other posts I've read, they indicate that the UDP is also handled differently.

Additionally, I can't get jt-alert to work with ACL. I click the 'log' button at the end of a QSO but it doesn't log the QSO.
On Wed, May 26, 2021 at 9:50 PM HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:
On 27/05/2021 1:40 pm, Tory Wiedenkeller wrote:

I'm not sure what setting I messed up. I had the decode window showing the incoming callsigns, but now it's not showing them.

What do I need to change so this window shows decoded callsigns? Thanks


Open the Settings of the Main JTAlert window and navigate to the "Window -> Decodes" section and tick the enable box.

de Laurie VK3AMA


Virus-free. www.avast.com


HamApps Support (VK3AMA)
 

On 27/05/2021 11:01 pm, Tory Wiedenkeller wrote:
Ok, I did as you suggested.  When I got in to the Decodes pane, the box was already 'enabled.'

Additionally, I do have the .net file installed. I also installed the 64 bit version for WSJT-X, which is what I'm running.
No offense, but the previous version was much more easily installed and used. 

In other posts I've read, they indicate that the UDP is also handled differently.

In your original message, there was no indication that you were experiencing UDP failure messages. That is the root of your problem. If JTAlert is not receiving decodes from WSJT-X because of a UDP failure, it is normal for the Decodes window to not display any new entries.

Get the UDP to work and the Decodes window will start updating as it receives decodes from its controlling parent, JTAlert.

There are not any new UDP requirements introduced with JTAlert 2.50.x, they are the same as the old 2.16.x versions. The only changes to UDP handling were required when WSJT-X 2.3.x changed how it distributed multicast UDP packets. JTAlert had to change to accommodate those changes.

Recent message traffic involving UDP changes have been typically due to the introduction of additional applications trying to work directly with WSJT-X resulting in JTAlert being blocked from interacting with WSJT-X. This is not due to any defect in JTALert, but misconfigured UDP handling. Once an additional WSJT-X interacting application is added into the mix, WSJT-X needs to be switched from using unicast to mulitcast UDP and all applications that want to talk to WSJT-X concurrently also need to be changed to using multicast. This is a not a new requirement of JTAlert. Multicast support by JTAlert was introduced back in August 2020.

Proper setup for mulitcast UDP has a dedicated section in the help file. It covers what needs to change in WSJT-X and the simple, single menu-entry enable needed  by JTAlert.

de Laurie VK3AMA