FYI
Since the only reliable (?) method for identifying WSJT-X decodes that
will accept the UDP Reply Command is the "Try it and wait to see if
WSJT-X responds" technique. I will be changing JTAlert behaviour with
respect to the UDP Reply command, AKA double-click a CQing Callsign.
From the next JTAlert release, only standard format CQ decodes, "CQ
Callsign Grid" will be highlighted in JTAlert as double-clickable. All
other CQ style decodes will no longer accept the double-click or be
highlighted (green rectangle drawn around the callsign) as accepting a
double-click.
de Laurie VK3AMA
On 10/06/2016 2:10 PM, Laurie, VK3AMA wrote:
I propose that the UDP protocol, specifically the decode packet, be
extended to include a Boolean flag that identifies if the decode will
respond to a UDP Reply command.
Not all CQ/QRZ decodes are supported by the UDP Replycommand and it
would be beneficial if those decodes are easily identified (within the
decode packet) as not being acceptable by WSJT-X, rather than
performing exception tests or analysis of the decode string
structureas is currently neededto identify these unsuitable decodes.
Thoughts?
de Laurie VK3AMA
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
