locked Config Nightmares 2 #FT8


Peter Klein - KD7MW
 

I'm starting a new topic to avoid confusion. I have been unable to get JTAlert to work with Log4OM and either WSJT-X or JTDX since upgrading to JTAlert v. 2.50.9. Previously, I had it working with both JT programs, using a non-multicast loopback address. But in the process of upgrading all three programs this week, something broke.

I have working configurations for Log4OM plus both WSJT-X and JTDX while NOT using JTAlert.  I decided to try WSJT-X first, and then try to apply that to JTDX once I got WSJT-X working.  So I set up new configurations in both Log4OM and WSJT-X, followed the instructions in the three programs' manuals and help files as best I could. So far, No success.  I have written up my configuration, with screen grabs, in the following RTF file on DropBox. It should be readable with MS Word, Libre Office or Wordpad.

https://www.dropbox.com/s/k01u8rhwd242s1l/KD7MW-JTAlertMulticastConfig1.rtf?dl=0

Incidentally, the old Log4OM configuration worked (without JTAlert running) when using Fldigi--by itself, not simultaneously with either JT decoder programs.  It uses a totally different port, and just has Log4OM monitor the Fldigi log file for changes. So I don't think that has anything to do with what's going on now. Which seems to be that JTAlert is not communicating with WSJT-X at all, and only partially with Log4OM.

Could someone please tell me what's going on?
--Peter, KD7MW


JTAlert Support (VK3AMA)
 

On 18/01/2022 11:50 am, Peter Klein - KD7MW wrote:
I'm starting a new topic to avoid confusion. I have been unable to get JTAlert to work with Log4OM and either WSJT-X or JTDX since upgrading to JTAlert v. 2.50.9. Previously, I had it working with both JT programs, using a non-multicast loopback address. But in the process of upgrading all three programs this week, something broke.

I have working configurations for Log4OM plus both WSJT-X and JTDX while NOT using JTAlert.  I decided to try WSJT-X first, and then try to apply that to JTDX once I got WSJT-X working.  So I set up new configurations in both Log4OM and WSJT-X, followed the instructions in the three programs' manuals and help files as best I could. So far, No success.  I have written up my configuration, with screen grabs, in the following RTF file on DropBox. It should be readable with MS Word, Libre Office or Wordpad.

https://www.dropbox.com/s/k01u8rhwd242s1l/KD7MW-JTAlertMulticastConfig1.rtf?dl=0

Incidentally, the old Log4OM configuration worked (without JTAlert running) when using Fldigi--by itself, not simultaneously with either JT decoder programs.  It uses a totally different port, and just has Log4OM monitor the Fldigi log file for changes. So I don't think that has anything to do with what's going on now. Which seems to be that JTAlert is not communicating with WSJT-X at all, and only partially with Log4OM.

Could someone please tell me what's going on?
--Peter, KD7MW

Peter,

I see nothing wrong in the your provided images. It is all very simple.

The problem is that JTAlert is not receiving any UDP messages from WSJT-X as indicated by the "Unknown Band, Unknown Mode" in the JTAlert titlebar. A couple of likely culprits...
  1. The UDP messages are being blocked by some other application set to work with WSJTX but configured to use unicast, not multicast, on port 2237. Do you have another application running set to work with WSJTX directly? If so what is it?

  2. The JTAlert process responsible for managing the UDP comms is not running. Rather than trying to find the process in TaskManager, the simplest check is done by trying to open the JTAlert About window, via the "Help" menu. If that window fails show that tells me the JTAlertV2.Manager.exe process is not running. This is typically caused by not installing the NET 5 Desktop Runtime.

Let me know what you find.

de Laurie VK3AMA


kiyo
 

Hi Peter,

My Log4OM2 and JTalert settings were the same.
However, the settings of WSJT-X are different from mine. The image below
image.png
The UDP server port numbers 2237 and 2333 are in different locations. Is this irrelevant?

For me, with this setting, I select the callsign from JTAlert, call it, send the callsign to Log4OM2, and send the QSO information to Log4OM2 with the log button of WSJT-X.

--
73, Kiyo JA9HWD


2022年1月18日(火) 9:50 Peter Klein - KD7MW <boulanger.croissant@...>:

I'm starting a new topic to avoid confusion. I have been unable to get JTAlert to work with Log4OM and either WSJT-X or JTDX since upgrading to JTAlert v. 2.50.9. Previously, I had it working with both JT programs, using a non-multicast loopback address. But in the process of upgrading all three programs this week, something broke.

I have working configurations for Log4OM plus both WSJT-X and JTDX while NOT using JTAlert.  I decided to try WSJT-X first, and then try to apply that to JTDX once I got WSJT-X working.  So I set up new configurations in both Log4OM and WSJT-X, followed the instructions in the three programs' manuals and help files as best I could. So far, No success.  I have written up my configuration, with screen grabs, in the following RTF file on DropBox. It should be readable with MS Word, Libre Office or Wordpad.

https://www.dropbox.com/s/k01u8rhwd242s1l/KD7MW-JTAlertMulticastConfig1.rtf?dl=0

Incidentally, the old Log4OM configuration worked (without JTAlert running) when using Fldigi--by itself, not simultaneously with either JT decoder programs.  It uses a totally different port, and just has Log4OM monitor the Fldigi log file for changes. So I don't think that has anything to do with what's going on now. Which seems to be that JTAlert is not communicating with WSJT-X at all, and only partially with Log4OM.

Could someone please tell me what's going on?
--Peter, KD7MW


Peter Klein - KD7MW
 

Hi, Laurie. I thought that I had installed .NET 5, but evidently I hadn't.  That was the problem. I now have JTAlert working with both JTDX and WSJT-X now. Reliability is 100% so far with WSJT-X. 

With JTDX, when I double click on a call in JTAlert's Callsign window, the call usually appears in Log4OM and JTDX, but occasionally not. That may have something to do with how much each of the two JT programs are pounding on the CPU and network layer.

My, things have grown quite a bit in v. 2.50.x. I think I need a second screen!

Thanks very much for the quick diagnosis!
73,
-Peter, KD7MW


Michael Black
 

One think I can highly recommend is to turn on single-click.
It's helped my carpal tunnel problems.
Mike W9MDB

Inline image





On Monday, January 17, 2022, 10:28:13 PM CST, Peter Klein - KD7MW <boulanger.croissant@...> wrote:


Hi, Laurie. I thought that I had installed .NET 5, but evidently I hadn't.  That was the problem. I now have JTAlert working with both JTDX and WSJT-X now. Reliability is 100% so far with WSJT-X. 

With JTDX, when I double click on a call in JTAlert's Callsign window, the call usually appears in Log4OM and JTDX, but occasionally not. That may have something to do with how much each of the two JT programs are pounding on the CPU and network layer.

My, things have grown quite a bit in v. 2.50.x. I think I need a second screen!

Thanks very much for the quick diagnosis!
73,
-Peter, KD7MW


Peter Klein - KD7MW
 

Now THAT is a great idea.  Thanks, Mike!
--Peter, KD7MW


JTAlert Support (VK3AMA)
 

On 18/01/2022 3:31 pm, Michael Black via groups.io wrote:
With JTDX, when I double click on a call in JTAlert's Callsign window, the call usually appears in Log4OM and JTDX, but occasionally not. That may have something to do with how much each of the two JT programs are pounding on the CPU and network layer.

Not likely a network or cpu issue. Either your getting old, like me, and sometimes the double-click is not fast enough (just joking) or since it is JTDX it is set to only respond to the callsign click event for CQ decodes only. Check the JTDX "Misc -> Accept UDP Reply messages" menu and set it to "all messages".



If the physical double-click is an issue, set JTAlert to use a single click.
Set via the Callsigns window Options popup (click the gear icon).


de Laurie VK3AMA


Peter Klein - KD7MW
 

Again, spot on, Laurie. JTDX was set to only respond to callsign clicks for CQ decodes.  Fixed now. Thanks again!
73,
--Peter, KD7MW