1. Topics
  2. MSK144 logging and time keeping

MSK144 logging and time keeping

Dave AA6YQ
 

Thanks to all for the comments on this topic.

I'm not planning to make changes to DXKeeper unless LoTW changes its policy, which as I've already posted would be very unlikely. The constructive online venue in which to continue the discussion is here:

<https://groups.arrl.org/g/ARRL-LoTW/messages>

73,

Dave, AA6YQ
Joe Subich, W4TV
 

On 2020-08-20 1:42 AM, David A92GE wrote:

At least one logging program (Logger 32) has a check box option to
force the log book to log start time as end time:
That is *completely wrong*. Using "force start time equals QSO end
time" will *cause* this problem!

This option is contrary to the intent of ADIF and violates the LotW
rule which is to always log the start time.

73,

... Joe, W4TV


On 2020-08-20 1:42 AM, David A92GE wrote:
[Edited Message Follows]
As I mentioned in a previous thread this situation is made worse by the fact that WSJT/JTDX both will log the start time of an incompleted QSO when a subsequent QSO is completed. I believe this is a bug but has not been acknowledged. I have had FT8 QSO's which typically take a minute with start and end times of 18 hours difference. Thanks to Dave's SQL script I now check my log for QSO's over 15 mins length before uploading. It saves issues.
As Iain has rightly said the start time of a QSO is indeterminate unless scheduled. The end time is usually much more likely to be closer for both stations.
At least one logging program (Logger 32) has a check box option to force the log book to log start time as end time:
/*Hi*,/
//
/FYI,/
/Logger32 users can find remedy to the problem, checking the following option:
Force QSO start time equals QSO end time/
*Best regards*,
Alec
73 David
Hasan Schiers N0AN
 

I agree with Joe. In how many cases do two stations start a meteor scatter with 30 minutes different from each other? Almost never. 

This is a solution in search of a problem. Start time logging is just fine. I've been running MS for many years and never have had a LOTW problem with confirmations.

Worst case, and very, very rare, IMO that two stations even running random meteors, have > 30 min starting time differential. It should also be noted that there is considerably ambiguity in ending times for an MS qso, although again, 30 minutes would be pretty odd.

What has already been established works just fine. 

73, N0AN

Hasan


On Wed, Aug 19, 2020 at 6:25 PM Joe Subich, W4TV <lists@...> wrote:

LotW does not recognize "end time".  There is only one time involved in
the QSO entry and by the LotW specification that is the start time.

*ANY ONE OR ANY LOGGING PROGRAM* that uses "end time" is violating the
LotW documentation.  Note: this can be a significant problem with
meteor scatter (MSK144, ISCAT-A, ISCAT-B) and EME QSOs as they are
generally schedules that can last up to an hour with the stations
receiving their reports at widely spaced times.

73,

    ... Joe, W4TV


On 2020-08-19 5:10 PM, Dave AA6YQ wrote:
> + AA6YQ comments below
>
> On Wed, Aug 19, 2020 at 01:14 PM, Sidney Shusterman wrote:
>
>>
>> Thanks for this information. The QSO in question was 42 minutes from start
>> to finish.
>
> + That would explain the lack of a confirmation. I suggest that you contact your QSO partner and ask him or her to resubmit the QSO with the correct start time; that will result in a confirmation.
>
> 73,
>
> Dave, AA6YQ
>
>
>
>



g4wjs
 

Hi Dave and David,

when logging a QSO in WSJT-X the date and times of the start and end of the QSO are presented to the user to check and can be modified before committing the QSO details to the log. There can be some ambiguity as to exactly when a QSO starts, particularly when a prior QSO has failed, the user should confirm that a QSO has been abandoned by hitting the ESC key before stating a new QSO.

73
Bill
G4WJS.

On 20/08/2020 07:22, Dave AA6YQ wrote:

Bill G4WJS, what's your reaction to the MSK144 time logging situation being discussed in this thread?

       73,

              Dave, AA6YQ

As I mentioned in a previous thread this situation is made worse by the fact that WSJT/JTDX both will log the start time of an incompleted QSO when a subsequent QSO is completed. I believe this is a bug but has not been acknowledged. I have had FT8 QSO's which typically take a minute with start and end times of 18 hours difference. Thanks to Dave's SQL script I now check my log for QSO's over 15 mins length before uploading. It saves issues.

As Iain has rightly said the start time of a QSO is indeterminate unless scheduled. The end time is usually much more likely to be closer for both stations.

          73 David A92GE



--
73

Bill

G4WJS.
Dave AA6YQ
 

Bill G4WJS, what's your reaction to the MSK144 time logging situation being discussed in this thread?

       73,

              Dave, AA6YQ

As I mentioned in a previous thread this situation is made worse by the fact that WSJT/JTDX both will log the start time of an incompleted QSO when a subsequent QSO is completed. I believe this is a bug but has not been acknowledged. I have had FT8 QSO's which typically take a minute with start and end times of 18 hours difference. Thanks to Dave's SQL script I now check my log for QSO's over 15 mins length before uploading. It saves issues.

As Iain has rightly said the start time of a QSO is indeterminate unless scheduled. The end time is usually much more likely to be closer for both stations.

          73 David A92GE
Barry Murrell ZS2EZ
 

It makes ZERO sense that LoTW wants to work on "Start" time... the ONLY time that is significant is the END time - when the QSO is logged. Until the QSO is completed it is not a QSO... so of what significance is the Start time?? Simply illogical....

Thanks to the VERY bad QSB down this far South, trying to work DX Stations (particularly in FT8 F/H) my start time of calling them (and initial failed 3x response) against the time of actually logging the call can often be several hours.... I have had the same in RTTY and CW. Start time is irrelevant, when I do a QSL card only the END time (when I logged it) is entered on the card. Why do LoTW want to be different???

Is there some weird rationale behind this??? I certainly don't get it....

73 de BARRY MURRELL ZS2EZ
KF26ta - Port Elizabeth, South Africa
EPC#0558 DMC#1690 30MDG#4081
DXCC HONOR ROLL (332/340)
website : www.zs2ez.co.za

-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Joe Subich, W4TV
Sent: Thursday, 20 August 2020 01:26
To: DXLab@groups.io
Subject: Re: [DXLab] MSK144 logging and time keeping


LotW does not recognize "end time". There is only one time involved in the QSO entry and by the LotW specification that is the start time.

*ANY ONE OR ANY LOGGING PROGRAM* that uses "end time" is violating the LotW documentation. Note: this can be a significant problem with meteor scatter (MSK144, ISCAT-A, ISCAT-B) and EME QSOs as they are generally schedules that can last up to an hour with the stations receiving their reports at widely spaced times.

73,

... Joe, W4TV


On 2020-08-19 5:10 PM, Dave AA6YQ wrote:
+ AA6YQ comments below

On Wed, Aug 19, 2020 at 01:14 PM, Sidney Shusterman wrote:


Thanks for this information. The QSO in question was 42 minutes from
start to finish.
+ That would explain the lack of a confirmation. I suggest that you contact your QSO partner and ask him or her to resubmit the QSO with the correct start time; that will result in a confirmation.

73,

Dave, AA6YQ
David A92GE
 
Edited

As I mentioned in a previous thread this situation is made worse by the fact that WSJT/JTDX both will log the start time of an incompleted QSO when a subsequent QSO is completed. I believe this is a bug but has not been acknowledged. I have had FT8 QSO's which typically take a minute with start and end times of 18 hours difference. Thanks to Dave's SQL script I now check my log for QSO's over 15 mins length before uploading. It saves issues.

As Iain has rightly said the start time of a QSO is indeterminate unless scheduled. The end time is usually much more likely to be closer for both stations.

At least one logging program (Logger 32) has a check box option to force the log book to log start time as end time:

Hi,

 

FYI,

Logger32 users can find remedy to the problem, checking the following option:

Force QSO start time equals QSO end time

Best regards,

Alec

73 David
Joe Subich, W4TV
 

LotW does not recognize "end time". There is only one time involved in
the QSO entry and by the LotW specification that is the start time.

*ANY ONE OR ANY LOGGING PROGRAM* that uses "end time" is violating the
LotW documentation. Note: this can be a significant problem with
meteor scatter (MSK144, ISCAT-A, ISCAT-B) and EME QSOs as they are
generally schedules that can last up to an hour with the stations
receiving their reports at widely spaced times.

73,

... Joe, W4TV

On 2020-08-19 5:10 PM, Dave AA6YQ wrote:
+ AA6YQ comments below
On Wed, Aug 19, 2020 at 01:14 PM, Sidney Shusterman wrote:


Thanks for this information. The QSO in question was 42 minutes from start
to finish.
+ That would explain the lack of a confirmation. I suggest that you contact your QSO partner and ask him or her to resubmit the QSO with the correct start time; that will result in a confirmation.
73,
Dave, AA6YQ
Peter Laws / N5UWY
 

On Wed, Aug 19, 2020 at 5:08 PM Dave AA6YQ <aa6yq@...> wrote:



+ I'd be very surprised if the ARRL could be convinced to switch LoTW from considering "start times" to considering "end times".

Look, I've *watched* the news - this IS the end times!!!

*rimshot*




--
Peter Laws | N5UWY | plaws plaws net | Travel by Train!
Dave AA6YQ
 

+ AA6YQ comments below

On Wed, Aug 19, 2020 at 02:48 PM, iain macdonnell - N6ML wrote:

When, exactly, does a QSO start? This may seem like a stupid question
to those who have not tried meteor scatter. I may double-click on your
CQ to start calling you at 11:00. You may hear me calling at 11:20,
and start sending a signal report to me. I may not receive your signal
report until 11:40. When did the QSO start? 11:00? 11:20? 11:40? As
far as WSJT-X is concerned (IIRC), it starts for me when I
double-click on your CQ. (11:00), but for you, it doesn't start until
you receive my call at 11:20. I have no way of knowing when you
started answering my call, so do I assume that the QSO starts at 11:40
when I first received a report from you?

It seems the error rate might be lower (but still not zero) if LoTW
used the QSO end time instead of the start. A possible way to
accomplish this would be to make WSJT-X (and variants) use the time at
which the QSOs is logged as both the start and end time, but this
would have to be applied unanimously.

+ Since MSK144 QSOs are made with WSJT-X, I would think that user community - perhaps with orchestration by the WSJX-X team - would articulate (and possibly automate) a policy that reliably produces LoTW confirmations.

+ I'd be very surprised if the ARRL could be convinced to switch LoTW from considering "start times" to considering "end times".

      73,

               Dave, AA6YQ

 
Bill Pence
 

yes, no easy answer for this.
MSK144 qso can potentially take super long times....
I think the QSO end time might still have certain flexing as well based on when I get messages vs when the partner sent them?


I certainly get the concept to avoid inaccurate info in your log, but in this narrow case,
I'm not sure I agree that tweaking (yes, that makes it inaccurate) your QSO start time to be within the
30 minute window of the partner logged time (the QSO end time in the case of the original poster) is "bad" 
it seems a a minor infraction.


On Wed, Aug 19, 2020 at 5:48 PM iain macdonnell - N6ML <ar@...> wrote:
On Wed, Aug 19, 2020 at 2:12 PM Dave AA6YQ <aa6yq@...> wrote:
>
> + AA6YQ comments below
>
> On Wed, Aug 19, 2020 at 01:44 PM, Bill Pence wrote:
>
> So, I asked if he changed his qso start time to be within 30 mins of partners end time.
>
> The logic was this would get an lotw match...
>
> + I recommend against putting incorrect information in your log. Contact your QSO partner, point out the error, and ask them to resubmit the QSO with the correct start time.

When, exactly, does a QSO start? This may seem like a stupid question
to those who have not tried meteor scatter. I may double-click on your
CQ to start calling you at 11:00. You may hear me calling at 11:20,
and start sending a signal report to me. I may not receive your signal
report until 11:40. When did the QSO start? 11:00? 11:20? 11:40? As
far as WSJT-X is concerned (IIRC), it starts for me when I
double-click on your CQ. (11:00), but for you, it doesn't start until
you receive my call at 11:20. I have no way of knowing when you
started answering my call, so do I assume that the QSO starts at 11:40
when I first received a report from you?

It seems the error rate might be lower (but still not zero) if LoTW
used the QSO end time instead of the start. A possible way to
accomplish this would be to make WSJT-X (and variants) use the time at
which the QSOs is logged as both the start and end time, but this
would have to be applied unanimously.

73,

    ~iain / N6ML
iain macdonnell - N6ML
 

On Wed, Aug 19, 2020 at 2:12 PM Dave AA6YQ <aa6yq@...> wrote:

+ AA6YQ comments below

On Wed, Aug 19, 2020 at 01:44 PM, Bill Pence wrote:

So, I asked if he changed his qso start time to be within 30 mins of partners end time.

The logic was this would get an lotw match...

+ I recommend against putting incorrect information in your log. Contact your QSO partner, point out the error, and ask them to resubmit the QSO with the correct start time.
When, exactly, does a QSO start? This may seem like a stupid question
to those who have not tried meteor scatter. I may double-click on your
CQ to start calling you at 11:00. You may hear me calling at 11:20,
and start sending a signal report to me. I may not receive your signal
report until 11:40. When did the QSO start? 11:00? 11:20? 11:40? As
far as WSJT-X is concerned (IIRC), it starts for me when I
double-click on your CQ. (11:00), but for you, it doesn't start until
you receive my call at 11:20. I have no way of knowing when you
started answering my call, so do I assume that the QSO starts at 11:40
when I first received a report from you?

It seems the error rate might be lower (but still not zero) if LoTW
used the QSO end time instead of the start. A possible way to
accomplish this would be to make WSJT-X (and variants) use the time at
which the QSOs is logged as both the start and end time, but this
would have to be applied unanimously.

73,

~iain / N6ML
Dave AA6YQ
 

+ AA6YQ comments below

On Wed, Aug 19, 2020 at 01:44 PM, Bill Pence wrote:

So, I asked if he changed his qso start time to be within 30 mins of partners end time.

The logic was this would get an lotw match...

+ I recommend against putting incorrect information in your log. Contact your QSO partner, point out the error, and ask them to resubmit the QSO with the correct start time.

            73,

                 Dave, AA6YQ
Dave AA6YQ
 

+ AA6YQ comments below

On Wed, Aug 19, 2020 at 01:14 PM, Sidney Shusterman wrote:

Thanks for this information. The QSO in question was 42 minutes from start to finish.

+ That would explain the lack of a confirmation. I suggest that you contact your QSO partner and ask him or her to resubmit the QSO with the correct start time; that will result in a confirmation.

        73,

              Dave, AA6YQ
Bill Pence
 

Sorry. Wrong person. In the original message, it was noted:
Qso was over 20 minutes long.
Qso partner logged wso end time.

Result us wso partner's wso time and poster wso time was greater than 30 minutes [42 minutes]
So lotw does not match.

So, I asked if he changed his qso start time to be within 30 mins of partners end time.

The logic was this would get an lotw match...
Bill Pence
 

I thought you said the qso partner used qso end time....



On Wed, Aug 19, 2020, 4:31 PM Peter Laws / N5UWY <plaws0@...> wrote:
On Wed, Aug 19, 2020 at 3:26 PM Bill Pence <pence.bill@...> wrote:
>
> Did you solve the mismatch by changing your qso start time in your log to be within 30 minutes of qso partner end time and resubmit to lotw?
>
> I too find msk qso's can take a VERY long time.

I'm sure that's true but why would that affect the two stations' QSO
start times being greater than 30 minutes apart?




--
Peter Laws | N5UWY | plaws plaws net | Travel by Train!
Peter Laws / N5UWY
 

On Wed, Aug 19, 2020 at 3:26 PM Bill Pence <pence.bill@...> wrote:

Did you solve the mismatch by changing your qso start time in your log to be within 30 minutes of qso partner end time and resubmit to lotw?

I too find msk qso's can take a VERY long time.
I'm sure that's true but why would that affect the two stations' QSO
start times being greater than 30 minutes apart?




--
Peter Laws | N5UWY | plaws plaws net | Travel by Train!
Bill Pence
 

Did you solve the mismatch by changing your qso start time in your log to be within 30 minutes of qso partner end time and resubmit to lotw?

I too find msk qso's can take a VERY long time. 
Sid- K3SX FM19dk MD
 

Thanks for this information. The QSO in question was 42 minutes from start to finish.

On 8/19/2020 2:57 PM, Dave AA6YQ wrote:

+ AA6YQ comments below
Recently I worked a station on MSK144. The QSO took more than 20 minutes to complete. When I uploaded from DX Lab to LOTW the start time was the time used by LOTW. When I did not receive a confirmation within a reasonable time I looked into the situation and found the END time was what my QSO partner had used.

+ LoTW allows for up to 30 minutes of difference between the "start time" you submit and the "start time" your QSO" partner submits; a ~20 minute discrepancy should not have preventing confirmation.

<https://lotw.arrl.org/lotw-help/key-concepts#confirmation>

Since it is not uncommon to have an MSK144 QSO take longer than a few minutes is there a way to direct LOTW to use the end time

+ No.

or set up DX Lab to use the end time?

+ No. For reliable LoTW confirmations, all QSO participants should submit the QSO's "start time". Providing an option to submit the QSO's "end time" would reduce  confirmations.

    73,

         Dave, AA6YQ
Dave AA6YQ
 

+ AA6YQ comments below
Recently I worked a station on MSK144. The QSO took more than 20 minutes to complete. When I uploaded from DX Lab to LOTW the start time was the time used by LOTW. When I did not receive a confirmation within a reasonable time I looked into the situation and found the END time was what my QSO partner had used.

+ LoTW allows for up to 30 minutes of difference between the "start time" you submit and the "start time" your QSO" partner submits; a ~20 minute discrepancy should not have preventing confirmation.

<https://lotw.arrl.org/lotw-help/key-concepts#confirmation>

Since it is not uncommon to have an MSK144 QSO take longer than a few minutes is there a way to direct LOTW to use the end time

+ No.

or set up DX Lab to use the end time?

+ No. For reliable LoTW confirmations, all QSO participants should submit the QSO's "start time". Providing an option to submit the QSO's "end time" would reduce  confirmations.

    73,

         Dave, AA6YQ
1 - 20 of 21