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.'
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