Hi Mike,
On 15/06/2016 23:11, Black Michael wrote:
Well if you're going to start swapping modes you get what you deserve.
Laurie was asking for certainty, I gave a simple example where that is
not possible without major changes to the UDP protocol or much more
processing in JTAlert to decide when a decode may not get a response to
a UDP reply message.
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?
That was the intention.
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?
There is not supposed to be, except for those in the 30m WSPR guard band
but those should cause the pop up message in WSJT-X. When the second
word (third in the case of CQ DX ...) is not a valid callsign where the
definition of valid callsign is very loose i.e. has letters and numbers.
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
