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?
On Tue, Nov 20, 2018 at 11:09 AM Bill Somerville <g4...@classdesign.com> wrote:
>
> On 20/11/2018 18:06, Brian Moran wrote:
> > In the ARRL RTTY Roundup, the rules say work stations once per band,
> > regardless of mode. This means those stations using both RTTY and FT8
> > modes in the same contest will have to check callsigns in BOTH MODES
> > to know what to work efficiently.
> >
> > Will there be a means supported to do an 'outcall' to another program
> > to check duplicate status of any particular contact? For example, N1MM
> > Logger+ uses the SQLite DB, but access doesn't have to be through N1MM
> > Logger+; to check dupe status, a small app could be written to perform
> > the DB query. I'm pretty sure on modern computers the SQLite library
> > is fast enough to handle the lookup of a list of callsigns before
> > display, especially if they're queried in a single SQL lookup (e.g.
> > "WHERE CALLSIGN IN ('N1ABC', 'K2ABC', 'K3ABC', 'W4ABC'])
> >
> > I would expect that if a serious contest station were employing both
> > modes, they'd keep the 'ground truth' database of stations worked in a
> > contest logger.
> >
> > Brian N9ADG
>
> Hi Brian,
>
> your points are valid but I would be concerned about performance. We
> would effectively be relinquishing the completion of printing of decodes
> to an external application. This is a time-critical operation in WSJT-X
> and the implied round-trip exchange is a potential problem. Currently
> highlighting is done using a high performance in-memory table and
> indexes. Adding dupe and needed multiplier checking is on the list but
> not yet implemented.
>
> I suspect a practical approach may be achieved by having some sort of
> hand-over process where QSOs so far would be passed over to WSJT-X so
> that it could update its table in the background. That approach with a
> push mechanism from the single source of truth application (N1MM Logger+
> for example) would avoid any delays at decode time with two applications
> having to have a conversation during a time-critical phase of
> processing. I do realize that there will certainly be contest operators
> running SO2R or even multi-multi that will want a more real-time scheme.
> That is a much tougher proposition to which I would think about some
> sort of bridging application that becomes the single source of real-time
> truth (SST) of QSOs completed so far. That SST could be the logging
> application a you describe.
>
> Whatever we do will need a lot of thought, and I for one will resist
> adding too much contest (or log specific) functionality into WSJT-X as
> that adds a maintenance burden which is a distraction from the core
> weak-signal QSO tool aims of WSJT-X.
>
> 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
