My Comments inline...
On 8/02/2017 1:16 AM, ANDY DURBIN wrote:
"I also wonder if the ones complaining are using the older version of
JTAlert which tries to "guess" the TIME_ON from the 1st observation of
the callsign which works on a normal QSO but not when you're waiting
for them at all"
JTAlert doesn't attempt to guess. It simple records the time of the
first appearance of the DXCall. The user has to make the some sort of
effort to ensure the data is correct before logging.
I have not complained to anyone but I have had to track down multiple
instances of incorrect QSO time reporting that probably were caused by
this problem.
If you don't complain, then how is anyone to know there is an issue!
In all cases I looked back thought the QSO decode records and found
that the reported QSO time correlated to a time when I had called the
station but had not completed a contact until a much later call.
JTAlert records the time when the DXCall field is first populated, as
the first step it trying to derive the TIME_ON. (Since WSJT-X has never
provided that data). That time is recorded in the time field of the log
fields area. The tooltip for that field explains that a double-click
will reset the time to the current UTC time. If a QSO is late in
starting all that needs to be done is double-click that time field when
the QSO starts to get an accurate TIME_ON value recorded in the log.
All seen with older versions of JTAlert and WSJT-X. These errors
can be detected from eQSL reports but with LoTW the QSO is simply lost.
Any code that attempts to derive a QSO start time should also include
a reasonableness test on QSO duration.
At some point, the operator has to take some responsibility over what
they are logging and not just blindly accept whatever is provided
(in an editable form) There is more than sufficient time during a
JT65/9 QSO to ensure that log field data is accurate and make
adjustments prior to hitting the Log button.
73,
Andy k3wyc
de Laurie VK3AMA
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
