Hi Mike,
This approach with 3rd party SW would add more complexity to WSJT-X's QSO
logging and new callsign indication, seems like we will have to use JTAlert
logging instead of WSJT-X in multicast configuration.
73 Igor UA3DJY
>Пятница, 4 декабря 2015, 18:46 -05:00 от Michael Black :
>
>
On 05/12/2015 00:24, Laurie, VK3AMA wrote:
The only reason that JTAlert is not using multi-cast is due to
limitations of the current JTAlert Compiler/Language. One of many
reasons (not to mention lack of multi-threading and async
functionalities) that JTAlert is being rewritten.
Understood Laur
On 5/12/2015 11:01 AM, Bill Somerville wrote:
The requirement for multicast support is so that other applications that
wish to receive notifications from WSJT-X can coexist with each other.
In other words a well behaved WSJT-X UDP protocol server should use
multicast UDP to be a good citizen, not
On 04/12/2015 23:46, Michael Black wrote:
> But that won't be available until next year some time since it's a
> complete rewrite of JTAlert. The current version can't support
> multicast so right now one JTAlert is needed for each WSJT-X.
Hi Mike,
that's not correct. A single unicast UDP serve
I do believe that ability is under development for JTAlert where one
JTAlert can manage multiple WSJT-X instances.
But that won't be available until next year some time since it's a complete
rewrite of JTAlert. The current version can't support multicast so right
now one JTAlert is needed for each
