Topics

Incorrect start times in WSJT and JTDX - feature request

David A92GE
 

Apologies Dave in advance, but a "feature request".

It has been reported by myself and others in the relevant forums, that often WSJT and JTDX will log incorrect start times. It is usually due to an earlier "broken" QSO being completed later, when the start time of the first "broken" QSO is logged with the end time of the completed QSO. This can be hours different and cause QSO's not to be verified in eQSL and I presume (not checked) in LotW. Both of which use the start time (my opinion incorrectly) as the QSO time that is verified rather than the end time. As the developers of the software do not seem to want to address this issue, would it be possible for DXKeeper to flag up potentially incorrect logging; say if the WSJT/JTDX software passes a log QSO that exceeds 15 minutes earlier than the end time? When running a pile up it can be difficult to keep up what is being logged but if the time were highlighted it would assist greatly. 

73
David
A92GE

g4wjs
 

On 04/07/2020 12:51, David A92GE wrote:
Apologies Dave in advance, but a "feature request".

It has been reported by myself and others in the relevant forums, that often WSJT and JTDX will log incorrect start times. It is usually due to an earlier "broken" QSO being completed later, when the start time of the first "broken" QSO is logged with the end time of the completed QSO. This can be hours different and cause QSO's not to be verified in eQSL and I presume (not checked) in LotW. Both of which use the start time (my opinion incorrectly) as the QSO time that is verified rather than the end time. As the developers of the software do not seem to want to address this issue, would it be possible for DXKeeper to flag up potentially incorrect logging; say if the WSJT/JTDX software passes a log QSO that exceeds 15 minutes earlier than the end time? When running a pile up it can be difficult to keep up what is being logged but if the time were highlighted it would assist greatly.

73
David
A92GE
Hi David,

weak signal QSOs often take many minutes, sometime even hours. In WSJT-X we expect users to inform the software when a QSO has been abandoned, this can be done by simply hitting the ESC key.

73
Bill
G4WJS.



--
73

Bill

G4WJS.

Joe Subich, W4TV
 

On 2020-07-04 7:56 AM, g4wjs wrote:

In WSJT-X we expect users to inform the software when a QSO has been
abandoned, this can be done by simply hitting the ESC key.
WSJT-X should consider a QSO abandoned when the user clicks on a
different signal (callsign) - ie. "DX Call" changes. Returning to
a previous signal/callsign should restart the QSO (at least for
HF operation).

73,

... Joe, W4TV


On 2020-07-04 7:56 AM, g4wjs wrote:
On 04/07/2020 12:51, David A92GE wrote:
Apologies Dave in advance, but a "feature request".

It has been reported by myself and others in the relevant forums, that often WSJT and JTDX will log incorrect start times. It is usually due to an earlier "broken" QSO being completed later, when the start time of the first "broken" QSO is logged with the end time of the completed QSO. This can be hours different and cause QSO's not to be verified in eQSL and I presume (not checked) in LotW. Both of which use the start time (my opinion incorrectly) as the QSO time that is verified rather than the end time. As the developers of the software do not seem to want to address this issue, would it be possible for DXKeeper to flag up potentially incorrect logging; say if the WSJT/JTDX software passes a log QSO that exceeds 15 minutes earlier than the end time? When running a pile up it can be difficult to keep up what is being logged but if the time were highlighted it would assist greatly.

73
David
A92GE
Hi David,
weak signal QSOs often take many minutes, sometime even hours. In WSJT-X we expect users to inform the software when a QSO has been abandoned, this can be done by simply hitting the ESC key.
73
Bill
G4WJS.

g4wjs
 

Hi Joe,

it does. The problem being described should only be happening if another QSO is not initiated within the interval. WSJT-X has no idea if a QSO is still in progress if nothing happens to indicate that.

73
Bill
G4WJS.

On 04/07/2020 13:38, Joe Subich, W4TV wrote:
On 2020-07-04 7:56 AM, g4wjs wrote:

In WSJT-X we expect users to inform the software when a QSO has been
abandoned, this can be done by simply hitting the ESC key.

WSJT-X should consider a QSO abandoned when the user clicks on a
different signal (callsign) - ie. "DX Call" changes.  Returning to
a previous signal/callsign should restart the QSO (at least for
HF operation).

73,

   ... Joe, W4TV


On 2020-07-04 7:56 AM, g4wjs wrote:
On 04/07/2020 12:51, David A92GE wrote:
Apologies Dave in advance, but a "feature request".

It has been reported by myself and others in the relevant forums, that often WSJT and JTDX will log incorrect start times. It is usually due to an earlier "broken" QSO being completed later, when the start time of the first "broken" QSO is logged with the end time of the completed QSO. This can be hours different and cause QSO's not to be verified in eQSL and I presume (not checked) in LotW. Both of which use the start time (my opinion incorrectly) as the QSO time that is verified rather than the end time. As the developers of the software do not seem to want to address this issue, would it be possible for DXKeeper to flag up potentially incorrect logging; say if the WSJT/JTDX software passes a log QSO that exceeds 15 minutes earlier than the end time? When running a pile up it can be difficult to keep up what is being logged but if the time were highlighted it would assist greatly.

73
David
A92GE

Hi David,

weak signal QSOs often take many minutes, sometime even hours. In WSJT-X we expect users to inform the software when a QSO has been abandoned, this can be done by simply hitting the ESC key.

73
Bill
G4WJS.



--
73

Bill

G4WJS.

Dave AA6YQ
 

+ AA6YQ comment sbelow

It has been reported by myself and others in the relevant forums, that often WSJT and JTDX will log incorrect start times. It is usually due to an earlier "broken" QSO being completed later, when the start time of the first "broken" QSO is logged with the end time of the completed QSO. This can be hours different and cause QSO's not to be verified in eQSL and I presume (not checked) in LotW. Both of which use the start time (my opinion incorrectly) as the QSO time that is verified rather than the end time. As the developers of the software do not seem to want to address this issue, would it be possible for DXKeeper to flag up potentially incorrect logging; say if the WSJT/JTDX software passes a log QSO that exceeds 15 minutes earlier than the end time? When running a pile up it can be difficult to keep up what is being logged but if the time were highlighted it would assist greatly.

+ The SQL expression

datediff("n",QSO_Begin,QSO_End)>15

+ will filter the Log Page Display to show only QSOs whose duration exceeds 15 minutes.

+ Note that when you select a QSO in the Log Page Display, the QSO panel's caption will display the QSO's duration (in minutes:seconds format) within parenthesis.

73,

Dave, AA6YQ

David A92GE
 

It happens even when there are several completed QSO's in between the broken and completed QSO. 

73

David
A92GE

David A92GE
 

Thanks for that - at least I can periodically check if there are errors.

73
David 
A92GE