On 10/06/2016 05:10, 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.
Hi Laurie,
that is not very easy, for example if the decodes are erased then they
are no longer capable of being replied. Bottom line is that the decision
to react to a decode on double click (or UDP reply message) is made at
the time it is done, not when the decode is received.
Yesterday I committed a change that will make the highlighting and the
response to UDP reply messages more consistent. Other than that you
should just send the reply packets and if WSJT-X does not respond then
it should be safe to assume that double clicking the same decode in
WSJT-X would not do anything either, with the exception that only
general call *standard messages* will be responded to via the UDP reply
message. No one to my knowledge has complained that double clicking some
decodes in WSJT-X does not cause WSJT-X to react.
If JTAlert users are finding that a general call message is not being
responded to then they must put forward a case for making them standard
messages. That is a very difficult case to make because we cannot change
the protocol without major disruption. There are edge cases like the
possible use of the E9 prefixes for more flexible CQ calls, this is
where change should be requested rather than expecting WSJT-X guess the
intent of various free text messages.
73
Bill
G4WJS.
------------------------------------------------------------------------------
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. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
