On 25/05/2022 3:28 am, Joe wrote:
Since there is wsjtx restarting in a
multi-instance setup you will need to restart all JTAlert
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
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".
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.
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