locked Start-Time and End-Time of a FT8 QSO #FT8


Knut Steinar Fremme OE4KSF
 

Start-Time  and End-Time of a FT8 QSO
 
I have been using WSJT-X together with MacLoggerDX for a year now, and wherry happy about how it works.
 
But I have been a thing that I have not understood for a while, and that is why some of my QSO when sendt to QRZ was not confirmed when they should.
 
Yesterday I found the reason.
 
If I first have someone calling me, but in bad conditions and he is not receiving my RR73 or I’m not receiving his 73 
Then after 3 hours we try again - and at this time we do succeed - and RR73 + 73
I’m sending the QSO to MacLoggerDX - that again is sending the entry to QRZ and LoTW
 
When I then look at the entries I find that the start-time for the log entry is the start time for the FIRST QSO, that did not succeed , and the end-time is the end-time for the QSO that did succeed 
 
And when the caller is sending his entries to QRZ and/or LoTW - there is no match - because of the wrong Start-Time 

Regards and 73  Knut  OE4KSF


Jim Cooper
 

On 25 Feb 2020 at 21:45, Steinar Fremme wrote:

> When I then look at the entries I
> find that the start-time for the log
> entry is the start time for the
> FIRST QSO, that did not succeed , and
> the end-time is the end-time for the
> QSO that did succeed

when the WSJT-X "Log QSO" window
pops up, there is a place to show both the
start and end time of the contest.

Why don't you just edit that before
you click OK ?

The problem I see is that you do not know
what time the other station is using to log
your exchange, but it is probably closer to
your END time ... since that is when the
contact is actually "real".

w2jc

graphic

  


Knut Steinar Fremme OE4KSF
 

Sure I can , but why should it be necessary - I classify it as a bug in functionality.

And yes - I just set the start time - 1 minute before end-time - and then all is ok.

Now when I know about - i'm checking everyone of them  -
and even started to edit old logs in QRZ - and are getting quite a few new confirmations - now that I'm aware of it.

But when you have a pile up - it takes time - and easy to overlook - and should not be necessary at all.
 
I have close to 17.000 FT8 QSO's now - and when the conditions on 20m is as it has been a few days now - easy to overlook this problem.

Also to mention - I have other QSO's in between the two with the same station - and impossible to remember if I have seen this station before today.

Well , that is my meaning anyway - and I still do classify it as an design flow 

73 Knut OE4KSF


Bill Somerville
 

On 26/02/2020 16:12, Steinar Fremme wrote:
Sure I can , but why should it be necessary - I classify it as a bug in functionality.

And yes - I just set the start time - 1 minute before end-time - and then all is ok.

Now when I know about - i'm checking everyone of them  -
and even started to edit old logs in QRZ - and are getting quite a few new confirmations - now that I'm aware of it.

But when you have a pile up - it takes time - and easy to overlook - and should not be necessary at all.
 
I have close to 17.000 FT8 QSO's now - and when the conditions on 20m is as it has been a few days now - easy to overlook this problem.

Also to mention - I have other QSO's in between the two with the same station - and impossible to remember if I have seen this station before today.

Well , that is my meaning anyway - and I still do classify it as an design flow 

73 Knut OE4KSF

Knut,

this will only happen if you have no intervening QSOs.

If you abandon a QSO then hit the ESC key, this will forget the abandoned QSO details.

73
Bill
G4WJS


Knut Steinar Fremme OE4KSF
 

Ok, I will try the Esc key , but I find also entries that do have other QSO's in between - that is what really concerns me .

I'm just sitting and editing my logs in MacLogger - and find 1 out of 100 (About) to be wrong - and most of them have other QSO's in between.

So if what you say is the case - then the problem is something else - that it doesn't record the correct start time - but pics something else .
I have checked the logs ALL.txt for a few of the wrong entries to see if the problem could be in transferring the log entry into MacLogger, but it's wrong also there - it has the correct start time for the new call in there. 
Luckily MacLogger is setting the time On column entry in Bold when it sees a timing wish is possible wrong - so now I'm looking for them 

73 Knut OE4KSF


Jim Shorney
 

It is up to the operator to ensure the accuracy of what goes into your log. Always.

73

-Jim
NU0C

On Wed, 26 Feb 2020 08:12:59 -0800
"Steinar Fremme" <steinar@...> wrote:

Sure I can , but why should it be necessary - I classify it as a bug in functionality.