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

JTAlert Support (VK3AMA)

On 25/05/2022 3:28 am, Joe wrote:
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.  


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

Join Support@HamApps.groups.io to automatically receive all group messages.