locked Incorrect logged QSO times in WSJT-X Version 2.5.4 when running MSK144 #IssueReport #logging #MSK144


 

There was a discussion about the times being logged by WSJT-X on the Pingjockey.net (meteor scatter chat room) site a few days ago, so I decided to collect some data (the last 10 years of my professional career was all about testing software)!

The attached text file shows what I found over a couple of days. The notes also show whether or not WSJT-X cycled back to TX6 after sending or receiving a '73', which I think had been discussed before ('Auto Seq' is checked). People are still complaining about this!

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 data includes the actual (partial) entry from my 'wsjtx.log' files; those are marked with a single asterisk ('*'). In some cases, the 'wsjtx.log' entry from my QSO partner is also included; those are marked with a double asterisk ('**').

You can see in some cases, the start and stop times are correct and in other cases, the QSO end time is logged in both fields. I've already shared this with a couple of people and none of us can see a pattern to it.

This has caused a problem for some folks with LoTW confirmations as meteor scatter QSOs (particularly on 2 meters and above) can take longer than the LoTW time window. LoTW considers a QSO valid if the QSO start times are within 30 minutes of each other. So, if a QSO takes more than a half hour and my QSO partner logs the correct start time and I log the end time as the start time (or vice-versa), LoTW will reject the QSO. eQSL considers the QSO valid only if the start times are within a 15 minute window.

As there is no provision to automatically answer a call when running MSK144 (why not?), I would assume the start time should be the time that I double clicked on a message from someone answering my CQ or the time I double clicked on someone's CQ in order to answer.

I would also assume that the end time logged should be whenever I send or receive an 'RRR' or a '73'. Could you clarify these assumptions?

===============================================================================

08-03-2022 (MSK144)

09:52 K0TPP answered my CQ on 6 meters
Start & Stop times logged correctly
WSJT Cycled to TX6
* 2022-08-03,09:52:00,2022-08-03,09:53:38,K0TPP,

10:14 N9EP Answered my CQ on 2 meters (CM&SH)
Had to manually click 'Log QSO'- Cockpit error
Stop time logged as both start & stop
WSJT did not cycle to TX6
* 2022-08-03,10:14:30,2022-08-03,10:28:50,N9EP,

10:17 KD9VV Answered my CQ on 6 meters
Manually selected TX5 after KD9VV reported my RRR on PJ
Start & Stop times logged correctly
WSJT did not cycle to TX6
* 2022-08-03,10:17:30,2022-08-03,10:19:15,KD9VV,

10:54 W9VHF Answered my CQ on 2 meters (CM&SH)
Stop time logged as both start & stop
WSJT did not cycle to TX6
* 2022-08-03,11:06:45,2022-08-03,11:06:45,W9VHF,

10:59 AE5VB Answered my CQ on 6 meters
Manually selected TX5 after AE5VB reported my RRR on PJ
Start & Stop times logged correctly
WSJT did not cycle to TX6
* 2022-08-03,10:59:45,2022-08-03,11:02:15,AE5VB,


08-03-2022 (FT8)

14:28 Answered CQ from WD4EWZ on 6 meters
Start & Stop times logged correctly
WSJT Cycled to TX6
* 2022-08-03,14:28:30,2022-08-03,14:29:30,WD4EWZ,

14:35 WA2VNV Answered my CQ on 6 meters
Start & Stop times logged correctly
WSJT Cycled to TX6
* 2022-08-03,14:36:45,2022-08-03,14:37:45,WA2VNV,


08-04-2022 (MSK144)

10:21 KD9VV Answered my CQ on 6 meters
Manually selected TX5 after KD9VV reported my RRR on PJ
Start & Stop times logged correctly
WSJT did not cycle to TX6
* 2022-08-04,10:21:15,2022-08-04,10:23:15,KD9VV,

10:23 Answered CQ from K0TPP on 6 meters
Stop time logged as both start & stop
WSJT did not cycle to TX6
* 2022-08-04,10:26:15,2022-08-04,10:26:15,K0TPP,

10:40 K0TPP Answered my CQ on 2 meters (CM&SH)
Stop time logged as both start & stop
WSJT did not cycle to TX6
* 2022-08-04,10:45:15,2022-08-04,10:45:15,K0TPP,

10:56 W9VHF answered my CQ on 6 meters
Start & Stop times logged correctly
WSJT Cycled to TX6
* 2022-08-04,10:56:30,2022-08-04,10:57:30,W9VHF,
** 2022-08-04,10:56:20,2022-08-04,10:57:30,WA2FZW,

11:18 K2DRH answered my CQ on 6 meters
Start & Stop times logged correctly
WSJT Cycled to TX6
2022-08-04,11:18:30,2022-08-04,11:19:33,K2DRH,


08-05-2022 (MSK144)

10:22 KD9VV Answered my CQ on 6 meters
Start time logged as both start & stop
WSJT Cycled to TX6
* 2022-08-05,10:24:34,2022-08-05,10:24:34,KD9VV,

10:27 W9VHF answered my CQ on 2 meters (CM&SH)
Start & Stop times logged correctly
WSJT did not cycle to TX6
* 2022-08-05,10:26:45,2022-08-05,10:28:45,W9VHF,
** 2022-08-05,10:24:45,2022-08-05,10:29:58,WA2FZW,

10:40 Answered K0TPP CQ on 2 meters (CM&SH)
Manually selected TX5 after Larry reported RRR on PJ
Start & Stop times logged correctly
WSJT did not cycle to TX6
* 2022-08-05,10:59:51,2022-08-05,10:59:51,K0TPP,

10:45 Answered V9VHF CQ on 6 meters
Start & Stop times logged correctly
WSJT did not cycle to TX6
* 2022-08-05,10:47:15,2022-08-05,10:48:15,W9VHF,
** 2022-08-05,10:46:00,2022-08-05,10:48:29,WA2FZW,

11:33 K2DRH Answered my CQ on 6 meters
Start & Stop times logged correctly
WSJT Cycled to TX6
* 2022-08-05,11:33:00,2022-08-05,11:34:00,K2DRH,

--
John P.
WA2FZW


Michael Black
 

We need to see the exchanges in the ALL.TXT file for the ones where end-time is start time.
There are conditions where the start time gets "reset".
As always though it's up to the user to ensure the times are correct for such extreme conditions in particular.  There's only so much automation we can do.
Here's some of the logic but maybe there's some EME exceptions we need to put in.
void MainWindow::set_dateTimeQSO(int m_ntx){
    // m_ntx = -1 resets to default time
    // Our QSO start time can be fairly well determined from Tx 2 and Tx 3 -- the grid reports
    // If we CQ'd and sending sigrpt then 2 minutes ago n=2
    // If we're on msg 3 then 3 minutes ago n=3 -- might have sat on msg1 for a while
    // If we've already set our time on just return.
    // This should mean that Tx2 or Tx3 has been repeated so don't update the start time
    // We reset it in several places
    if (m_ntx == -1) { // we use a default date to detect change
      m_dateTimeQSOOn = QDateTime {};
    }
    else if (m_dateTimeQSOOn.isValid ()) {
        return;
    }
    else { // we also take of m_TRperiod/2 to allow for late clicks
      auto now = QDateTime::currentDateTimeUtc();
      m_dateTimeQSOOn = now.addSecs (-(m_ntx - 2) * int(m_TRperiod) -
                                     int(fmod(double(now.time().second()),m_TRperiod)));
    }
}

Mike W9MDB

On Sunday, August 7, 2022 at 01:05:19 PM CDT, John P <j.m.price@...> wrote:

There was a discussion about the times being logged by WSJT-X on the Pingjockey.net (meteor scatter chat room) site a few days ago, so I decided to collect some data (the last 10 years of my professional career was all about testing software)!

The attached text file shows what I found over a couple of days. The notes also show whether or not WSJT-X cycled back to TX6 after sending or receiving a '73', which I think had been discussed before ('Auto Seq' is checked).  People are still complaining about this!

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 data includes the actual (partial) entry from my 'wsjtx.log' files; those are marked with a single asterisk ('*'). In some cases, the 'wsjtx.log' entry from my QSO partner is also included; those are  marked with a double asterisk ('**').

You can see in some cases, the start and stop times are correct and in other cases, the QSO end time is logged in both fields. I've already shared this with a couple of people and none of us can see a pattern to it.

This has caused a problem for some folks with LoTW confirmations as meteor scatter QSOs (particularly on 2 meters and above) can take longer than the LoTW time window. LoTW considers a QSO valid if the QSO start times are within 30 minutes of each other. So, if a QSO takes more than a half hour and my QSO partner logs the correct start time and I log the end time as the start time (or vice-versa), LoTW will reject the QSO. eQSL considers the QSO valid only if the start times are within a 15 minute window.

As there is no provision to automatically answer a call when running MSK144 (why not?), I would assume the start time should be the time that I double clicked on a message from someone answering my CQ or the time I double clicked on someone's CQ in order to answer.

I would also assume that the end time logged should be whenever I send or receive an 'RRR' or a '73'. Could you clarify these assumptions?

===============================================================================

08-03-2022 (MSK144)

09:52 K0TPP answered my CQ on 6 meters
      Start & Stop times logged correctly
      WSJT Cycled to TX6
*    2022-08-03,09:52:00,2022-08-03,09:53:38,K0TPP,

10:14 N9EP Answered my CQ on 2 meters (CM&SH)
      Had to manually click 'Log QSO'- Cockpit error
      Stop time logged as both start & stop
      WSJT did not cycle to TX6
*    2022-08-03,10:14:30,2022-08-03,10:28:50,N9EP,

10:17 KD9VV Answered my CQ on 6 meters
      Manually selected TX5 after KD9VV reported my RRR on PJ
      Start & Stop times logged correctly
      WSJT did not cycle to TX6
*    2022-08-03,10:17:30,2022-08-03,10:19:15,KD9VV,

10:54 W9VHF Answered my CQ on 2 meters (CM&SH)
      Stop time logged as both start & stop
      WSJT did not cycle to TX6
*    2022-08-03,11:06:45,2022-08-03,11:06:45,W9VHF,
 
10:59 AE5VB Answered my CQ on 6 meters
      Manually selected TX5 after AE5VB reported my RRR on PJ
      Start & Stop times logged correctly
      WSJT did not cycle to TX6
*    2022-08-03,10:59:45,2022-08-03,11:02:15,AE5VB,


08-03-2022 (FT8)

14:28 Answered CQ from WD4EWZ on 6 meters
      Start & Stop times logged correctly
      WSJT Cycled to TX6
*    2022-08-03,14:28:30,2022-08-03,14:29:30,WD4EWZ,

14:35 WA2VNV Answered my CQ on 6 meters
      Start & Stop times logged correctly
      WSJT Cycled to TX6
*    2022-08-03,14:36:45,2022-08-03,14:37:45,WA2VNV,


08-04-2022 (MSK144)

10:21 KD9VV Answered my CQ on 6 meters
      Manually selected TX5 after KD9VV reported my RRR on PJ
      Start & Stop times logged correctly
      WSJT did not cycle to TX6
*    2022-08-04,10:21:15,2022-08-04,10:23:15,KD9VV,

10:23 Answered CQ from K0TPP on 6 meters
      Stop time logged as both start & stop
      WSJT did not cycle to TX6
*    2022-08-04,10:26:15,2022-08-04,10:26:15,K0TPP,

10:40 K0TPP Answered my CQ on 2 meters (CM&SH)
      Stop time logged as both start & stop
      WSJT did not cycle to TX6
*    2022-08-04,10:45:15,2022-08-04,10:45:15,K0TPP,

10:56 W9VHF answered my CQ on 6 meters
      Start & Stop times logged correctly
      WSJT Cycled to TX6
*    2022-08-04,10:56:30,2022-08-04,10:57:30,W9VHF,
**    2022-08-04,10:56:20,2022-08-04,10:57:30,WA2FZW,

11:18 K2DRH answered my CQ on 6 meters
      Start & Stop times logged correctly
      WSJT Cycled to TX6
      2022-08-04,11:18:30,2022-08-04,11:19:33,K2DRH,


08-05-2022 (MSK144)

10:22 KD9VV Answered my CQ on 6 meters
      Start time logged as both start & stop
      WSJT Cycled to TX6
*    2022-08-05,10:24:34,2022-08-05,10:24:34,KD9VV,

10:27 W9VHF answered my CQ on 2 meters (CM&SH)
      Start & Stop times logged correctly
      WSJT did not cycle to TX6
*    2022-08-05,10:26:45,2022-08-05,10:28:45,W9VHF,
**    2022-08-05,10:24:45,2022-08-05,10:29:58,WA2FZW,

10:40 Answered K0TPP CQ on 2 meters (CM&SH)
      Manually selected TX5 after Larry reported RRR on PJ
      Start & Stop times logged correctly
      WSJT did not cycle to TX6
*    2022-08-05,10:59:51,2022-08-05,10:59:51,K0TPP,

10:45 Answered V9VHF CQ on 6 meters
      Start & Stop times logged correctly
      WSJT did not cycle to TX6
*    2022-08-05,10:47:15,2022-08-05,10:48:15,W9VHF,
**    2022-08-05,10:46:00,2022-08-05,10:48:29,WA2FZW,

11:33 K2DRH Answered my CQ on 6 meters
      Start & Stop times logged correctly
      WSJT Cycled to TX6
*    2022-08-05,11:33:00,2022-08-05,11:34:00,K2DRH,

--
John P.
WA2FZW


Jim Brown
 

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.

73, Jim K9YC


Dave AA6YQ
 

+ 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


 

On Sun, Aug 7, 2022 at 04:41 PM, Michael Black wrote:


We need to see the exchanges in the ALL.TXT file for the ones where end-time
is start time.
Not sure who 'we' is, but here is the entries from ALL.txt covering the QSO with K0TPP that started at 10:23 on 8/4. The end time was logged as the start time for that QSO.

=================================================================================

220804_102313 50.260 Rx MSK144 8 13.7 1510 CQ K0TPP EM48
220804_102314 50.260 Rx MSK144 9 13.7 1509 CQ K0TPP EM48
220804_102315 50.260 Tx MSK144 0 0.0 1500 KD9VV WA2FZW 73
220804_102339 50.260 Rx MSK144 1 9.7 1511 CQ K0TPP EM48
220804_102340 50.260 Rx MSK144 6 10.0 1512 CQ K0TPP EM48
220804_102355 50.260 Tx MSK144 0 0.0 1500 K0TPP WA2FZW FN20
220804_102401 50.260 Rx MSK144 -4 1.5 1488 WN3SIX KD9VV R+00
220804_102415 50.260 Tx MSK144 0 0.0 1500 K0TPP WA2FZW FN20
220804_102445 50.260 Tx MSK144 0 0.0 1500 K0TPP WA2FZW FN20
220804_102515 50.260 Tx MSK144 0 0.0 1500 K0TPP WA2FZW FN20
220804_102543 50.260 Rx MSK144 -5 12.7 1511 WA2FZW K0TPP -05
220804_102545 50.260 Tx MSK144 0 0.0 1500 K0TPP WA2FZW R-05
220804_102601 50.260 Rx MSK144 1 1.0 1514 WA2FZW K0TPP RRR
220804_102605 50.260 Rx MSK144 6 5.0 1515 WA2FZW K0TPP RRR
220804_102615 50.260 Tx MSK144 0 0.0 1500 K0TPP WA2FZW 73

--
John P.
WA2FZW


Jim Brown
 

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


Sam Birnbaum
 

Hi all,

Please check the wsjtx_log.aid file and see what are the values for time and time off. Wsjtx passes that in the UDP message to any program that monitors it. I checked my records and in fact time off is not the same as time started.

This may point to a problem elsewhere in the logging chain.

73,

Sam W2JDB

On Monday, August 8, 2022, 04:57:10 AM EDT, Jim Brown <k9yc@...> wrote:

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


Michael Black
 

The idea is that the starting QSO time is SUPPOSED to be the start time of the first message you receive from someone minus the transmit period.The stop is either TX4 or TX5.
So...I did a local test calling myself (and I answered myself too...does this count as a valid QSO? :-)


124821 Tx 205 ~ CQ W9MDB EM49

124845 Tx 205 ~ CQ W9MDB EM49

124900 -17 0.1 1726 ~ W9MDB W9MDB -20

124915 Tx 205 ~ W9MDB W9MDB R-17

124930 2 0.1 1725 ~ W9MDB W9MDB RR73

124945 Tx 205 ~ W9MDB W9MDB 73

WSTJX logs this as start 12:48:45 and stop 12:49:45 using the start time of the transmissions.
If you see an "incorrect" time please provide the exchange information like this so we can see what happened.
Mike W9MDB

On Monday, August 8, 2022 at 03:57:10 AM CDT, Jim Brown <k9yc@...> wrote:

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


Michael Black
 

And do you have the ADIF record too?  Should have asked for that too.
Mike W9MDB

On Monday, August 8, 2022 at 02:05:23 AM CDT, John P <j.m.price@...> wrote:

On Sun, Aug  7, 2022 at 04:41 PM, Michael Black wrote:


We need to see the exchanges in the ALL.TXT file for the ones where end-time
is start time.
Not sure who 'we' is, but here is the entries from ALL.txt covering the QSO with K0TPP that started at 10:23 on 8/4. The end time was logged as the start time for that QSO.

=================================================================================

220804_102313    50.260 Rx MSK144  8 13.7 1510 CQ K0TPP EM48
220804_102314    50.260 Rx MSK144  9 13.7 1509 CQ K0TPP EM48
220804_102315    50.260 Tx MSK144  0  0.0 1500 KD9VV WA2FZW 73
220804_102339    50.260 Rx MSK144  1  9.7 1511 CQ K0TPP EM48
220804_102340    50.260 Rx MSK144  6 10.0 1512 CQ K0TPP EM48
220804_102355    50.260 Tx MSK144  0  0.0 1500 K0TPP WA2FZW FN20
220804_102401    50.260 Rx MSK144  -4  1.5 1488 WN3SIX KD9VV R+00
220804_102415    50.260 Tx MSK144  0  0.0 1500 K0TPP WA2FZW FN20
220804_102445    50.260 Tx MSK144  0  0.0 1500 K0TPP WA2FZW FN20
220804_102515    50.260 Tx MSK144  0  0.0 1500 K0TPP WA2FZW FN20
220804_102543    50.260 Rx MSK144  -5 12.7 1511 WA2FZW K0TPP -05
220804_102545    50.260 Tx MSK144  0  0.0 1500 K0TPP WA2FZW R-05
220804_102601    50.260 Rx MSK144  1  1.0 1514 WA2FZW K0TPP RRR
220804_102605    50.260 Rx MSK144  6  5.0 1515 WA2FZW K0TPP RRR
220804_102615    50.260 Tx MSK144  0  0.0 1500 K0TPP WA2FZW 73

--
John P.
WA2FZW


 

As far as I can see the QSO actually started with the call at 102515 that K0TPP answered. The QSO comprises that transmissions highlighted below. The unanswered calls do NOT form part of the QSO.

73 Phil GM3ZZA.

Sent from Mail for Windows

From: John P
Sent: 08 August 2022 08:05
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Incorrect logged QSO times in WSJT-X Version 2.5.4 when running MSK144 #IssueReport #logging

On Sun, Aug 7, 2022 at 04:41 PM, Michael Black wrote:


We need to see the exchanges in the ALL.TXT file for the ones where end-time
is start time.
Not sure who 'we' is, but here is the entries from ALL.txt covering the QSO with K0TPP that started at 10:23 on 8/4. The end time was logged as the start time for that QSO.

=================================================================================

220804_102313 50.260 Rx MSK144 8 13.7 1510 CQ K0TPP EM48
220804_102314 50.260 Rx MSK144 9 13.7 1509 CQ K0TPP EM48
220804_102315 50.260 Tx MSK144 0 0.0 1500 KD9VV WA2FZW 73
220804_102339 50.260 Rx MSK144 1 9.7 1511 CQ K0TPP EM48
220804_102340 50.260 Rx MSK144 6 10.0 1512 CQ K0TPP EM48
220804_102355 50.260 Tx MSK144 0 0.0 1500 K0TPP WA2FZW FN20
220804_102401 50.260 Rx MSK144 -4 1.5 1488 WN3SIX KD9VV R+00
220804_102415 50.260 Tx MSK144 0 0.0 1500 K0TPP WA2FZW FN20
220804_102445 50.260 Tx MSK144 0 0.0 1500 K0TPP WA2FZW FN20
220804_102515 50.260 Tx MSK144 0 0.0 1500 K0TPP WA2FZW FN20
220804_102543 50.260 Rx MSK144 -5 12.7 1511 WA2FZW K0TPP -05
220804_102545 50.260 Tx MSK144 0 0.0 1500 K0TPP WA2FZW R-05
220804_102601 50.260 Rx MSK144 1 1.0 1514 WA2FZW K0TPP RRR
220804_102605 50.260 Rx MSK144 6 5.0 1515 WA2FZW K0TPP RRR
220804_102615 50.260 Tx MSK144 0 0.0 1500 K0TPP WA2FZW 73

--
John P.
WA2FZW








--
73 Phil GM3ZZA


Dave AA6YQ
 

Here's LoTW's criteria for a confirmation:

https://lotw.arrl.org/lotw-help/key-concepts/

Relevant to this discussiion, "both QSO descriptions specify start times within 30 minutes of each other".

Since the "QSO completion time" is a value on which the applications used by both parties to a QSO should agree, Jim K9YC's suggestion below to specify a start time of "X minutes prior to the completion time" is sensible. X can be set to the mode's minimum QSO duration.

73,

Dave, AA6YQ

-----Original Message-----
From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Jim Brown
Sent: Monday, August 08, 2022 3:26 AM
To: main@WSJTX.groups.io
Cc: WSJT software development
Subject: Re: [WSJTX] Incorrect logged QSO times in WSJT-X Version 2.5.4 when running MSK144 #IssueReport #logging #MSK144

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







--
This email has been checked for viruses by AVG.
https://www.avg.com


 

On Mon, Aug 8, 2022 at 02:05 PM, Sam Birnbaum wrote:


Please check the wsjtx_log.aid file
Sam... Here are the start and end times recorded in the wsjtx_log.adi file for the K0TPP QSO. Both 10:26:15

<qso_date:8>20220804 <time_on:6>102615 <qso_date_off:8>20220804 <time_off:6>102615

Don't see any reason to expect the ADI file data to be any different than the wsjtx.log file entry.

--
John P.
WA2FZW


 

On Mon, Aug 8, 2022 at 04:57 AM, Jim Brown wrote:


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.
Jim... Not everybody uses automatic logging. Some folks still do it manually and I would expect them to log the correct start and end times, so if WSJT-X is logging incorrect times, the problem still exists. Replacing one piece of bad data with another piece of bad data isn't such a great idea!

As GM3ZZA pointed out, the start time should probably be considered to be the call at 102515 that K0TPP answered.

--
John P.
WA2FZW


Jim Brown
 

You still don't understand the problem. You're describing a casual HF QSO. The Starting Time problem involves very different QSOs.

Remember that WSJT-X is used in a very wide variety of situations, everything from casual operation HF to extreme weak signal work from LF to UHF. Here's only one example.

A DX station or an expedition to a rare grid or county begins operation, and those needing to work him start calling as soon as they hear him, setting the caller's Start Time. There are many practical conditions of propagation and QRM that result in the DX station hearing the caller and beginning the QSO 30-120 minutes later. Since LOTW uses the starting times to validate a QSO, the validation fails.

I mostly use WSJT-X for weak signal work on 160M, 60M, and 6M, and to work an HF DXpedition. I've encountered this problem at least a half dozen times, losing QSOs that were quite important to me. Propagation for many QSOs on these bands is highly variable, involving multi-hop E-skip on 6M, similarly "spot-lighty" propagation on 160M. To work EU from near San Francisco on 60M, there's a window of 2-3 hours around the terminator.

73, Jim K9YC

On 8/8/2022 6:41 AM, Philip Rose via groups.io wrote:
As far as I can see the QSO actually started with the call at 102515 that K0TPP answered. The QSO comprises that transmissions highlighted below. The unanswered calls do NOT form part of the QSO.


Joe Subich, W4TV
 

On 2022-08-08 4:42 PM, Jim Brown wrote:
A DX station or an expedition to a rare grid or county begins
operation, and those needing to work him start calling as soon as
they hear him, setting the caller's Start Time. There are many
practical conditions of propagation and QRM that result in the DX
station hearing the caller and beginning the QSO 30-120 minutes
later.
Jim,

Set the watchdog to 5 minutes and double click on the DX Station
each time the watchdog times out. Double clicking on the DX Station
will reset the start time and you will never be "out of tolerance"
with the resulting time in your log.

73,

... Joe, W4TV

On 2022-08-08 4:42 PM, Jim Brown wrote:
You still don't understand the problem. You're describing a casual HF QSO. The Starting Time problem involves very different QSOs.
Remember that WSJT-X is used in a very wide variety of situations, everything from casual operation HF to extreme weak signal work from LF to UHF. Here's only one example.
A DX station or an expedition to a rare grid or county begins operation, and those needing to work him start calling as soon as they hear him, setting the caller's Start Time. There are many practical conditions of propagation and QRM that result in the DX station hearing the caller and beginning the QSO 30-120 minutes later. Since LOTW uses the starting times to validate a QSO, the validation fails.
I mostly use WSJT-X for weak signal work on 160M, 60M, and 6M, and to work an HF DXpedition. I've encountered this problem at least a half dozen times, losing QSOs that were quite important to me. Propagation for many QSOs on these bands is highly variable, involving multi-hop E-skip on 6M, similarly "spot-lighty" propagation on 160M. To work EU from near San Francisco on 60M, there's a window of 2-3 hours around the terminator.
73, Jim K9YC
On 8/8/2022 6:41 AM, Philip Rose via groups.io wrote:
As far as I can see the QSO actually started with the call at 102515 that K0TPP answered. The QSO comprises that transmissions highlighted below. The unanswered calls do NOT form part of the QSO.


Michael Black
 

I see one problem.
I ran a local loopback test and found the CQ side logged the start time as the start time of the TX2 message and the TX1 side marked it as the start of the CQ.  Kind of the opposite one what one would expect but both sides should agree on what the start time is.So we need to fix this.
Mike W9MDB


Sam Birnbaum
 

Hi John,
Disregard me previous msg sent about 5 minutes ago.
The very few times I ran MSK144 the adi record has different start stop times. In one case it's about 20 minutes:

<call:4>K2GK <gridsquare:4>FN30 <mode:6>MSK144 <rst_sent:3>-03 <rst_rcvd:3>+24 <qso_date:8>20200824 <time_on:6>142600 <qso_date_off:8>20200824 <time_off:6>142902 <band:2>6m <freq:9>50.261500 <station_callsign:5>W2JDB <my_gridsquare:4>FN30 <eor><call:4>K2GK <gridsquare:4>FN30 <mode:6>MSK144 <rst_sent:3>+00 <rst_rcvd:3>+11 <qso_date:8>20200825 <time_on:6>152015 <qso_date_off:8>20200825 <time_off:6>152100 <band:2>6m <freq:9>50.261500 <station_callsign:5>W2JDB <my_gridsquare:4>FN30 <eor><call:4>K2GK <gridsquare:4>FN30 <mode:6>MSK144 <rst_sent:3>-05 <rst_rcvd:3>+11 <qso_date:8>20200825 <time_on:6>152215 <qso_date_off:8>20200825 <time_off:6>152300 <band:2>6m <freq:9>50.261500 <station_callsign:5>W2JDB <my_gridsquare:4>FN30 <eor> Just some questions? 1: Are the log times always wrong or only if either you are calling CQ or the other ham is calling CQ?2: Are times wrong if/when you manually press Alt+Q to popup the log qso prompt or only if in contest mode and you have the Auto Log option checked? 
Just trying to isolate the condition if possible
73,
Sam W2JDB

-----Original Message-----
From: John P <j.m.price@...>
To: main@WSJTX.groups.io
Sent: Mon, Aug 8, 2022 2:24 pm
Subject: Re: [WSJTX] Incorrect logged QSO times in WSJT-X Version 2.5.4 when running MSK144 #IssueReport #logging

On Mon, Aug  8, 2022 at 02:05 PM, Sam Birnbaum wrote:


Please check the wsjtx_log.aid file
Sam... Here are the start and end times recorded in the wsjtx_log.adi file for the K0TPP QSO. Both 10:26:15

<qso_date:8>20220804 <time_on:6>102615 <qso_date_off:8>20220804 <time_off:6>102615

Don't see any reason to expect the ADI file data to be any different than the wsjtx.log file entry.

--
John P.
WA2FZW


Reino Talarmo
 

A DX station or an expedition to a rare grid or county begins operation, and those needing to work him start calling as soon as they hear him, setting the caller's Start Time.
Hi Jim,

With all respect of your problems you are actually introducing a third working related time "Caller's Start Time". Of course even that is interesting on the operator's point of view, but it really involves highly probably only one station especially on MS QSOs. So it is not something that is common to both stations. The other party may also be involved into another call at that time and may not consider it as a start of a QSO at all, especially DX station has that problem due to a pile.
Programming that time into an automation is most probably impossible as you stated "as soon as they hear him" and e.g. there seems to be many operators that just start calling without even hearing (seeing) the DX station!
Perhaps we should limit our logging to "QSO start time" and "QSO completion time". Those are easier to define, but still a bit difficult to program correctly as the example shows. One reason could be that there were two QSOs ongoing according to the ALL.txt information, if I remember proper.

73, Reino OH3mA


Jim Brown
 

On 8/8/2022 10:16 PM, Reino Talarmo wrote:
With all respect of your problems you are actually introducing a third working related time "Caller's Start Time".
No, I did not. What I said is that the logging software sets the caller's "Start Time" under the conditions I described can often be 30-90 minutes before the QSO actually takes place, it takes place over 1-2 minutes, and the DX logs it when HE responds to the caller. In the conditions I described, these Starting Times are 30-90 minutes apart.


Of course even that is interesting on the operator's point of view, but it really involves highly probably only one station especially on MS QSOs.
So it is not something that is common to both stations.

But it doesn't matter -- the solution I proposed works for short QSOs and long ones. What matters is that the LOGGED Start Times are within 30 minutes of each other.

The other party may also be involved into another call at that time and may not consider it as a start of a QSO at all, especially DX station has that problem due to a pile.

Exactly right! THAT is the problem.

Programming that time into an automation is most probably impossible as you stated "as soon as they hear him" and e.g. there seems to be many operators that just start calling without even hearing (seeing) the DX station!
Yes, but it doesn't matter. What matters is that they log the Start Time of the QSO within 30 minutes of each other. This is a STANDARD, which in the context of this discussion, is poorly conceived, but it is the STANDARD, and we have to live with it.

BTW -- I've been a member of the Standards Committee of the Audio Engineering Society for nearly 30 years, an international committee, and am principal author of seven Standards on EMC.

One of the shortcomings of WSJT-X authors is their limited exposure to many of the ways their wonderful software is used. One of the great strengths of the AES Standards Committee is that our members come from nearly a many different disciplines in how our Standards are used. We have important contributors from TV and Radio Broadcasting, Sound Reinforcement for large and small venues, Recording, Remote Broadcast and Recording, Small Home Studios, professionals who design the systems and those who use them.

The solution I proposed is sensible, as indicated by AA6YQ, who has for 20 years studied LOTW and other such systems, and produced professional quality software to support it. My solution is trivially easy to program. I've been using Dave's DXKeeper for nearly 20 years. His contributions have been recognized by ARRL with an award for Technical Excellence.

Perhaps we should limit our logging to "QSO start time" and "QSO completion time". Those are easier to define,
No, they are NOT, for the several examples I've cited.

Consider this, Reino. The DX logs the Start Time for his QSO when he starts to work me, and the Completion Time, which doesn't matter, when he copies my RRR. But the CALLER'S logging software logs the Starting Time as 30-90 minutes earlier. This happens with ALL WSJT-X modes, not only MSK144. I've had it happen more with FT8.

73, Jim K9YC


Reino Talarmo
 

Mike,
I see multiple problems, when there are repetitions of messages as you don't know which messages are really received and recorded by the other end. The problem is multiplied, if you try to record correctly two or more interleaved QSOs. So good luck. Luckily we have that LoTW 30 min time tolerance.
My assumption of the start time is, when both ends start a specific QSO. In principle at reception of a message to you, when you start to send a response to it. End time is, when you send or receive the last 'R'-message or perhaps 73 could be included.
73, Reino OH3mA

-----Original Message-----
From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Michael Black via groups.io
Sent: 9. elokuutata 2022 1:32
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Incorrect logged QSO times in WSJT-X Version 2.5.4 when running MSK144 #IssueReport #logging

I see one problem.
I ran a local loopback test and found the CQ side logged the start time as the start time of the TX2 message and the TX1 side marked it as the start of the CQ. Kind of the opposite one what one would expect but both sides should agree on what the start time is.So we need to fix this.
Mike W9MDB