Thanks Dave. For those reading the mail, DXKeeper is part of his
FREEWARE DXLab Suite.
To the development team -- it seems to me that the time sent to logging
software as the starting time ought to be either 1) the completion time
or 2) 2 minutes prior to the completion time. This solves the "long QSO"
problem with modes like MSK144, and weak signal modes like Q65 and FST4,
and I've experienced the problem several times using FT8 to work
expeditions or rare grids with marginal propagation.
BTW -- I'm using JTAlert, and I think that it is doing the interchange
with DXKeeper.
73, Jim K9YC
On 8/7/2022 12:33 PM, Dave AA6YQ wrote:
+ AA6YQ comments below
On 8/7/2022 6:49 AM, John P wrote:
I already inquired about the problem on the DxLab group. Dave (DxLab) said
DxKeeper (my logging program) logs what it gets from JTAlert. Laurie (JTAlert)
said JTAlert logs what it gets from WSJT-X. My observations would seem to
confirm this.
The fundamental problem is that LOTW uses the Start time of the QSO with a
certain time window for matching, most ham logging software adheres to this,
and some QSOs, like MS and DX chasing can exceed that window.
DXKeeper sets the start time of a QSO when I first enter the other station's
call. I've experienced this several times chasing a rare grid on 6M FT8, when
I've chased him for 30-45 minutes with varying propagation, and his start time
is when he finally works me.
+ When you're logging CW or SSB QSOs using DXKeeper's Capture window, there are
two options that determine whether the QSO's start time is automatically set:
1. "Set QSO start when RST Rcvd"
2. "Set QSO start on Lookup"
+ If neither option is set, the QSO is marked as "started" when you click the
Capture window's Begin button, or its Log button.
+ When you're making FT8 QSOs with WSJT-X and logging them to DXKeeper, WSJT-X determines
the "QSO Start" time.
73,
Dave, AA6YQ
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
