locked More Flex multi-slice anomalous behavior... #FT8 #DXLAB


Joe
 
Edited

This is another chapter in my efforts to at least chronicle anomalous behavior when using WSJTX and JTAlert with 3 or more Flex Radio 6600M slices (receiver instances) active.

This setup is:
  Flex 6600m with four panadapters with slices A-D each in its own panadapter
  SmartSDR, DXKeeper
  3 instances of WSJTX
  3 slices (B-D) tuned to FT8
  1 slice (A) tuned to a 20m cw frequency
  3 instances of JTAlert paired with the 3 instances of WSJTX
  DXKeeper set to upload each QSO to LotW as it is entered.

The problem is that either two instances of JTAlert are requesting DXKeeper to log the same QSO made on slice C, or the slice C instance is making duplicate requests.  After I enter OK on the QSO confirmation window that pops up, I get a window that says that LotW rejected my log request because it was a duplicate.  Inspecting  DXKeeper, I see two new entries for the same QSO, one with the proper 'R' in the LotW RCVD column, the second without (since the duplicate logging attempt was rejected).

At this point I reboot all instances of JTAlert and life goes back to normal.  This duplicate logging did not happen two hours earlier when I logged a QSO from the D slice.

This error is repeatable, meaning once it starts, it continues until the software (all JTAlert instances) is rebooted. No idea why it starts in the first place, as it does not always show this behavior.  

Just reporting the facts...

Joe/WQ6Q

Addendum (The plot thickens):  This situation repeated itself a couple of hours after the first occurrence.  This time I paid a bit more attention to the screens and saw that not one but two of the pop-up windows that start out "JTAlert: QSO to DXLab DXKeeper", which is consistent with the fact that duplicate logging requests are being passed to DXKeeper.  One was located in front of the first JTAlert instance (#1-slice B) and the other was in front of the second instance of JTAlert (#2-slice C). This time I subsequently logged QSOs from slice D and slice B without duplicates being sent.  Returning to slice C and logging a QSO generates duplicate requests.  And then I noticed that the information in the main windows of JTAlert #1 and JTAlert #2 was the same!  How I missed that before I have no idea. So somehow, both JTAlert instances were bound to the same WSJTX instance, that for slice C.  The top line of each of the first two JTAlert windows had "JTAlert 2.51.3 WQ6Q [15m,FT8,DXK,#1]" and "JTAlert 2.51.3 WQ6Q [15m,FT8,DXK,#2]", respectively.


JTAlert Support (VK3AMA)
 

On 14/05/2022 7:21 am, Joe wrote:
Addendum (The plot thickens):  This situation repeated itself a couple of hours after the first occurrence.  This time I paid a bit more attention to the screens and saw that not one but two of the pop-up windows that start out "JTAlert: QSO to DXLab DXKeeper", which is consistent with the fact that duplicate logging requests are being passed to DXKeeper.  One was located in front of the first JTAlert instance (#1-slice B) and the other was in front of the second instance of JTAlert (#2-slice C). This time I subsequently logged QSOs from slice D and slice B without duplicates being sent.  Returning to slice C and logging a QSO generates duplicate requests.  And then I noticed that the information in the main windows of JTAlert #1 and JTAlert #2 was the same!  How I missed that before I have no idea. So somehow, both JTAlert instances were bound to the same WSJTX instance, that for slice C.  The top line of each of the first two JTAlert windows had "JTAlert 2.51.3 WQ6Q [15m,FT8,DXK,#1]" and "JTAlert 2.51.3 WQ6Q [15m,FT8,DXK,#2]", respectively.


There have been past reports, (either on the WSJTX or WSJT-Devel groups, I don't recall which one) where a WSJT-X instance in a multi-instance Flex setup would suddenly change to using a different Flex slice other than the slice it was originally set to. Perhaps you're seeing the results of WSJTX switching slices. JTAlert has no concept of Flex slices, it associates itself with a WSJTX instance only and the gets the Band/Mode/DXCall status from WSJTX only. If WSJTX is reporting the wrong status than JTAlert will also.

Do you have each WSJT-X instance set with a unique --rig-name? You need to.
How do you have the WSJT-X UDP Server set? It needs to be set to use a multicast IP and the same port for each WSJT-X instance. eg 224.0.0.1 on port 2237.

When you see this happen again please post the JTAlert current operating state for each JTAlert instance as reported when you use the "Help -> About" menu. Hint: use the clipboard copy icon top-right of the current operating state results. Paste those results into a reply to this thread.

As a temporary measure enable JTAlert docking to WSJTX. Use the "View -> Dock to WSJT-X window" menu. When you see multiple JTAlert instances reporting the same band/mode do those JTAlert instance windows move to docking the same WSJT-X instance?


de Laurie VK3AMA



Joe
 

Laurie:

It took a bit longer than I expected to duplicate the situation described above.  This time, of four instances, I had two attempting to log the same info.  When I looked at the 'about' data, two instances of JTAlert were reporting  the same WSJT-X Window title, command line, and rig-name (see below), but with different UDP ports used.  I closed all four JTAlert instances, restarted three JTAlert instances.  I got the exact same results: the 2nd and 3rd instance of JTAlert were both mapped to the same WSJTX instance as show below.  The JTALert windows identifies properly, in that they are labeled #2 and #3.

Question: when JTAlert starts how does it decide which WSJTX instance to pair with?  In this in PID order?  Also, how can the two instances of JTAlert track the same instance of WSJTX with different UDP ports?

Joe/WQ6Q

..........................................................................................................................
JTAlert Instance       : #2
JTAlert Start Params   : /wsjtx
WSJT-X Window Title    : WSJT-X - Faraday-D   v2.5.4   by K1JT, G4WJS, K9AN, and IV3NWV
WSJT-X Command Line    : "C:\WSJT\wsjtx\bin\wsjtx.exe" --rig-name Faraday-D
WSJT-X   --rig-name    : Faraday-D
WSJT-X Config File     : C:\Users\joe\AppData\Local\WSJT-X - Faraday-D\WSJT-X - Faraday-D.ini
WSJT-X Version         : 2.5.4
WSJT-X Revision        : d28164
WSJT-X Spec Op Mode    : None
WSJT-X UDP ID          : WSJT-X - Faraday-D
WSJT-X UDP Port        : 2237
WSJT-X UDP Server      : 224.0.0.1
WSJT-X UDP Max Schema  : 3
 
==================================================
UDP Ports used
--------------------------------------------------
JTAlert.exe           : 57568 56558
JTAlertV2.Manager.exe : 52105 52106 52107
JTAlertV2.Decodes.exe : 
 
 
==================================================
Audio output devices
--------------------------------------------------
[1] Speakers / Headphones (Realtek Audio)
[2] DAX RESERVED AUDIO RX 5 (FlexRadio Systems DAX Audio)
[3] DAX Audio TX (FlexRadio Systems DAX TX)
[4] CABLE Input (VB-Audio Virtual Cable)
[5] DAX RESERVED AUDIO RX 4 (FlexRadio Systems DAX Audio)
[6] DAX RESERVED AUDIO RX 7 (FlexRadio Systems DAX Audio)
[7] DAX RESERVED MIC AUDIO (FlexRadio Systems DAX MIC Audio)
[8] DAX RESERVED AUDIO RX 3 (FlexRadio Systems DAX Audio)
[9] DAX RESERVED IQ RX 4 (FlexRadio Systems DAX IQ)
[10] DAX RESERVED AUDIO RX 1 (FlexRadio Systems DAX Audio)
[11] DAX RESERVED IQ RX 1 (FlexRadio Systems DAX IQ)
[12] DAX RESERVED AUDIO RX 2 (FlexRadio Systems DAX Audio)
[13] DAX RESERVED AUDIO RX 8 (FlexRadio Systems DAX Audio)
[14] DAX RESERVED IQ RX 2 (FlexRadio Systems DAX IQ)
[15] DAX RESERVED IQ RX 3 (FlexRadio Systems DAX IQ)
[16] DAX RESERVED AUDIO RX 6 (FlexRadio Systems DAX Audio)
 
 
==================================================
JTAlertV2.Manager (2.51.3.0) status
(2022-05-21 16:48:00 utc)
--------------------------------------------------
CLR Version       : 5.0.16
NET Framework     : .NET 5.0.16
Architecture      : x64 64bit
--------------------------------------------------
UDP Router        : Initialized : YES (WSJT-X - Faraday-D)
Audio             : Initialized : YES (16 output devices)
Activity Service  : Initialized : NO
Messaging Service : Initialized : YES (started : 17)
HamSpots Service  : Initialized : YES
QRZ Xml           : Initialized : YES (WQ6Q)
HamQth Xml        : Initialized : YES 
QRZ Log           : Initialized : YES (1EC6-3528-C0B5-1220)
HamQth Log        : Initialized : YES 
ClubLog Log       : Initialized : YES (WQ6Q)
Eqsl Log          : Initialized : YES 
HrdLog Log        : Initialized : YES 
DXLab DDE         : Initialized : YES
User Alert        : Initialized : YES
Updates Check     : Initialized : NO
Environment Check : Initialized : NO
Maintenance       : Initialized : YES (started : 3600)
--------------------------------------------------
..........................................................................................................................
JTAlert Instance       : #3
JTAlert Start Params   : /wsjtx
WSJT-X Window Title    : WSJT-X - Faraday-D   v2.5.4   by K1JT, G4WJS, K9AN, and IV3NWV
WSJT-X Command Line    : "C:\WSJT\wsjtx\bin\wsjtx.exe" --rig-name Faraday-D
WSJT-X   --rig-name    : Faraday-D
WSJT-X Config File     : C:\Users\joe\AppData\Local\WSJT-X - Faraday-D\WSJT-X - Faraday-D.ini
WSJT-X Version         : 2.5.4
WSJT-X Revision        : d28164
WSJT-X Spec Op Mode    : None
WSJT-X UDP ID          : WSJT-X - Faraday-D
WSJT-X UDP Port        : 2237
WSJT-X UDP Server      : 224.0.0.1
WSJT-X UDP Max Schema  : 3
 
==================================================
UDP Ports used
--------------------------------------------------
JTAlert.exe           : 65308 56525
JTAlertV2.Manager.exe : 63102 63103 63104
JTAlertV2.Decodes.exe : 
 
 
==================================================
Audio output devices
--------------------------------------------------
[1] Speakers / Headphones (Realtek Audio)
[2] DAX RESERVED AUDIO RX 5 (FlexRadio Systems DAX Audio)
[3] DAX Audio TX (FlexRadio Systems DAX TX)
[4] CABLE Input (VB-Audio Virtual Cable)
[5] DAX RESERVED AUDIO RX 4 (FlexRadio Systems DAX Audio)
[6] DAX RESERVED AUDIO RX 7 (FlexRadio Systems DAX Audio)
[7] DAX RESERVED MIC AUDIO (FlexRadio Systems DAX MIC Audio)
[8] DAX RESERVED AUDIO RX 3 (FlexRadio Systems DAX Audio)
[9] DAX RESERVED IQ RX 4 (FlexRadio Systems DAX IQ)
[10] DAX RESERVED AUDIO RX 1 (FlexRadio Systems DAX Audio)
[11] DAX RESERVED IQ RX 1 (FlexRadio Systems DAX IQ)
[12] DAX RESERVED AUDIO RX 2 (FlexRadio Systems DAX Audio)
[13] DAX RESERVED AUDIO RX 8 (FlexRadio Systems DAX Audio)
[14] DAX RESERVED IQ RX 2 (FlexRadio Systems DAX IQ)
[15] DAX RESERVED IQ RX 3 (FlexRadio Systems DAX IQ)
[16] DAX RESERVED AUDIO RX 6 (FlexRadio Systems DAX Audio)
 
 
==================================================
JTAlertV2.Manager (2.51.3.0) status
(2022-05-21 16:47:13 utc)
--------------------------------------------------
CLR Version       : 5.0.16
NET Framework     : .NET 5.0.16
Architecture      : x64 64bit
--------------------------------------------------
UDP Router        : Initialized : YES (WSJT-X - Faraday-D)
Audio             : Initialized : YES (16 output devices)
Activity Service  : Initialized : NO
Messaging Service : Initialized : YES (stopped)
HamSpots Service  : Initialized : YES
QRZ Xml           : Initialized : YES (WQ6Q)
HamQth Xml        : Initialized : YES 
QRZ Log           : Initialized : YES (1EC6-3528-C0B5-1220)
HamQth Log        : Initialized : YES 
ClubLog Log       : Initialized : YES (WQ6Q)
Eqsl Log          : Initialized : YES 
HrdLog Log        : Initialized : YES 
DXLab DDE         : Initialized : YES
User Alert        : Initialized : YES
Updates Check     : Initialized : NO
Environment Check : Initialized : NO
Maintenance       : Initialized : YES (started : 3600)
--------------------------------------------------
 
 


JTAlert Support (VK3AMA)
 

On 22/05/2022 3:13 am, Joe wrote:
Question: when JTAlert starts how does it decide which WSJTX instance to pair with?  In this in PID order?  Also, how can the two instances of JTAlert track the same instance of WSJTX with different UDP ports?

JTAlert looks at the running time of each detected WSJT-X instance. The oldest gets picked up by instance #1, the second oldest by instance #2, etc. PIDs are not used as there is no guaranteed ordering of the number.

You're provided JTAlert data doesn't show WSJT-X on 2 different ports, they show the same port 2237. That is correct behavior. JTAlert uses the WSJT-X UDP ID that appears in every udp message, based on the --rig-name, to determine if the udp message is to be handled by the receiving JTAlert instance. udp messages from different udp ids are ignored.

Rather than using "--rig-name Faraday-D" put an equals sign between the parameter and the value, eg. "--rig-name=Faraday-D"
. This shouldn't be needed, but I am grasping at straws trying to work out is happening your end.

Questions...
  1. When a JTAlert instance starts associating itself with the wrong WSJTX instance has there been a restart of a WSJTX instance, either deliberately or via a configuration switch? WSJTX does a restart when switching configs.

  2. Do you have unique --rig-names set for each WSJTX instance?

  3. How are you starting you're WSJTX instances?

de Laurie VK3AMA



Joe
 

Questions...
1.  When a JTAlert instance starts associating itself with the wrong WSJTX instance has there been a restart of a WSJTX instance, either deliberately or via a configuration switch? WSJTX does a restart when switching configs.

   Not sure.  I do sometimes close a WSJTX instance if I switch, say, to cw on that slice.  But I usually just let it keep running in parallel.  What does JTAlert do when the instance that it is bound to is stopped?  I see that it keeps running...and seems to find a new instance when a WSJTX comes back.  This based on 2 minutes of playing just now.

2.  Do you have unique --rig-names set for each WSJTX instance?

   Yes, as indicated in the About JTAlert info.  The first one has no rig name, then the next three are "faraday-B", "..-C", and "..-D".

3.  How are you starting you're WSJTX instances?

   I have screen icons for each and I double click them as needed, in sequence usually, but not always.  This so that the JTAlert instance positions line up with the correct WSJTX instance on my screens.  

Joe/WQ6Q


Tom Melvin
 

Hi

Add a rig-name to the 1st instance as well.  I did have issues early on when swapping config’s in WSJT-X - not saying it will help but does make all instances the same.


Tom GM8MJV





On 24 May 2022, at 18:28, Joe <radio.wq6q@...> wrote:

Questions...
1.  When a JTAlert instance starts associating itself with the wrong WSJTX instance has there been a restart of a WSJTX instance, either deliberately or via a configuration switch? WSJTX does a restart when switching configs.

   Not sure.  I do sometimes close a WSJTX instance if I switch, say, to cw on that slice.  But I usually just let it keep running in parallel.  What does JTAlert do when the instance that it is bound to is stopped?  I see that it keeps running...and seems to find a new instance when a WSJTX comes back.  This based on 2 minutes of playing just now.

2.  Do you have unique --rig-names set for each WSJTX instance?

   Yes, as indicated in the About JTAlert info.  The first one has no rig name, then the next three are "faraday-B", "..-C", and "..-D".

3.  How are you starting you're WSJTX instances?

   I have screen icons for each and I double click them as needed, in sequence usually, but not always.  This so that the JTAlert instance positions line up with the correct WSJTX instance on my screens.  

Joe/WQ6Q


JTAlert Support (VK3AMA)
 

On 25/05/2022 3:28 am, Joe wrote:
Questions...
1.  When a JTAlert instance starts associating itself with the wrong WSJTX instance has there been a restart of a WSJTX instance, either deliberately or via a configuration switch? WSJTX does a restart when switching configs.

   Not sure.  I do sometimes close a WSJTX instance if I switch, say, to cw on that slice.  But I usually just let it keep running in parallel.  What does JTAlert do when the instance that it is bound to is stopped?  I see that it keeps running...and seems to find a new instance when a WSJTX comes back.  This based on 2 minutes of playing just now.

2.  Do you have unique --rig-names set for each WSJTX instance?

   Yes, as indicated in the About JTAlert info.  The first one has no rig name, then the next three are "faraday-B", "..-C", and "..-D".

3.  How are you starting you're WSJTX instances?

   I have screen icons for each and I double click them as needed, in sequence usually, but not always.  This so that the JTAlert instance positions line up with the correct WSJTX instance on my screens.  

Joe/WQ6Q


Since there is wsjtx restarting in a multi-instance setup you will need to restart all JTAlert instances.
While JTAlert can handle, in a single instance setup, a restart of wsjt and the resulting change in udp comms, that mechanism is unreliable in a multi-instance setup. It depends on which instance number was restarted.

In a multicast udp setup the use of the same udp port for all wsjtx instances is the recommended setting, you can still use unique udp ports for each wsjtx instance. Perhaps that may help in keeping the JTAlert/Instances in sync. It's worth a try and won't break the udp comms.

de Laurie VK3AMA