Hi Bill;
it's hard to hit a performance target without knowing what the numbers
need to be. Checking each call one at a time externally would surely
be the slowest.
But it also seems like the timing requirements on external dupe
checking could be relaxed entirely by doing something like this, which
would even fit into your existing framework in place for communicating
with external programs:
(For contesting dupe-check purposes, you just need a WORKED/NOT-WORKED):
In the speedy internal table used to maintain the wsjt-x worked-before
status, add a field that can store a signal field with values
EXTERNAL_NO_INFO / EXTERNAL_NOT_WORKED / EXTERNAL_WORKED
You only have to externally check call signs that haven't been worked
in WSJT-X, and are EXTERNAL_NO_INFO or EXTERNAL_NOT_WORKED.
End of Decode Interval 0:
Send all of the non-wsjtx-worked calls with EXTERNAL_NO_INFO or
EXTERNAL_NOT_WORKED to the external program. Don't wait around. You
can probably use the existing decode message broadcasts for these.
Paint the status of each decoded call on the screen informed by the
local super-speedy DB for whether they've been worked, but also taking
into account the EXTERNAL_* flags. Use a different color for NO_INFO
and NOT_WORKED statuses.
Start Decode Interval 1:
The external app sends the information to update the EXTERNAL_*
flags (only with WORKED or NOT_WORKED) in the speedy table using the
existing UDP infrastructure you have in place (with a new message type
defined, of course). The colors of a particular callsign may be off by
up to a decode interval. I don't recall if you can re-color calls
on-screen after they've been decoded, but you could.
You could argue that EXTERNAL_NO_INFO and EXTERNAL_NOT_WORKED are the
same, but if they're colored differently, a wise operator will wait
for the EXTERNAL_NOT_WORKED color if they're concentrating on wsjt-x
operation, and not adding calls into the external one through another
means.
So the only new work here is the extra field consultation and
coloration, and the messages to update your speedy internal table.
-Brian N9ADG
On Tue, Nov 20, 2018 at 11:40 AM Bill Somerville <g4...@classdesign.com> wrote:
>
> On 20/11/2018 19:25, Brian Moran wrote:
> > Hi Bill! You say time critical -- how many milliseconds are currently
> > available to look up the up-to-40-calls and render a 'worked_before'
> > status for each of them?
>
> Hi Brian,
>
> we have no deadline specified but I would expect the current
> implementation to add no more than a handful of microseconds (probably a
> lot less) to the print delay of each decode it might highlight. Note
> that this is almost certainly orders of magnitude faster than the time
> required assemble a network message, dispatch it, context switch to
> another application, receive the message, parse it, do a lookup, compose
> a reply, dispatch it, context switch again, receive the reply, parse it,
> act on it.
>
> 73
> Bill
> G4WJS.
>
>
>
> _______________________________________________
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
