Well if you're going to start swapping modes you get what you deserve.
I thought the problem was WITHOUT doing such things there were some CQ patterns
that you could double-click in WSJT-X and it would work...but double-clicking
from JTAlert would not for some odd reason.Maybe the fixes you did to the CQ
QRZ and such fixed those edge cases?
Is there any CQ pattern that should work in WSJT-X but not in JTAlert when it
returns the decode as far as you know?
de Mike W9MDB
From: Bill Somerville <[email protected]>
To: [email protected]
Sent: Wednesday, June 15, 2016 5:05 PM
Subject: Re: [wsjt-devel] Request: WSJT-X UDP protocol extension to identify
decodes to will accept UDP reply command.
On 15/06/2016 22:40, Laurie VK3AMA wrote:
Because without the certainty that a Decode is "UDP Reply capable", JTAlert has
no reliable way of highlighting that a Callsign is double-clickable. If JTAlert
highlights a Callsign as double-clickable to the end user, there is an
expectation that WSJT-X will respond to that double-click. That doesn't
currently happen. As a result, the end-user is left with the impression that
JTAlert is broken (with a resulting increase in support emails I receive), when
it is not broken, just that WSJT-X will not accept the Reply Command for that
particular decode. To try and avoid this situation, my intention is to only
provide a "Double-clickable indication" to the end user when the decode is
known to accept the Reply Command.
JTAlert needs to know programmatically that a particular decode will accept
the UDP Reply Command.
Trying to educate the end-user that not all CQ decodes will accept the
double-click and that they need to only use the JTAlert double-click on certain
decodes is not practical. Thus my desire to only indicate decodes that will
accept the double-click and get the end-user into the habit, that "this type of
visual indication" will correctly setup WSJT-X, rather then the "try it and
see if it works" as currently exists.
I'm not sure how I can explain this any differently.
Hi Laurie, I understand what you are asking. Let me give you an example, that
you can try, that may help to explain why this is not 100% possible: 1) Select
JT9+JT65 mode in WSJT-X and monitor an HF band with activity in both modes,
2) wait until a station calls CQ,
3) switch WSJT-X to the other mode from CQ caller,
4) double click the CQ message. What do you expect WSJT-X to do? How can
WSJT-X inform you at decode time whether a double click will get a response?
This may seem a contrived case to you but it is a simple example of why the
decision to respond to a double click is made at the time of the double click,
not at the time of decode.
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. 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
------------------------------------------------------------------------------
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
