Under normal conditions that would be true and it is true almost 100% from the
CQ side...but....answering a CQ you can sit on TX 1 waiting for an opening
while somebody else is in a QSO with them.Namely when you respond to a CQ but
they end up working somebody else first.That's why I subbed some time from Tx
2/Tx 3 to make it match the CQ line.If you think about it you're almost 100%
guaranteed that Tx 2/Tx 3 means you really are in the QSO where Tx 6/Tx 1
doesn't guarantee that at all...
So you can do this for exampleCQ G4WSJ IO91G4WSJ K1JT FN20 -- Note two
responses come inG4WSJ W9MDB EM49K1JT G4WSJ -01 -- You pick Joe to workG4WSJ
K1JT R-01K1JT G4WSJ RRRW9MDB G4WSJ -01 -- You now go back and answer me -- this
is the start of your QSO on Tx 2G4WSJ W9MDB R-01 -- I answer and this is the
start of my side on Tx 3
This happens a fair bit so the logic allows for this...to be even longer which
I've experienced numerous times.....also for propagation problems where it
takes time for conditions to match on both side or for big pileups. If
anything the logic could be tightened up for this but it ends up being about 2
minutes off on the above. If we change it use just the sig report the time
offset could be removed. Then at least it would be consistent on all QSOs.
Like I said, I tried to make it match the CQ line in the vast majority of cases.
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....that's what prompted me to do this on WSJT-X's side where one knows more
of what's going on from user actions.After we added TIME_ON Laurie made a
change to JTAlert to use WSJT-X's TIME_ON instead of his guess which, in all my
testing, is dang near 100% spot on.
Where are the examples of it being wrong? I'm a bit pedantic about time and
would like to fix it to be what everybody agrees is "correct".
de Mike W9MDB
From: Bill Somerville <[email protected]>
To: [email protected]
Sent: Tuesday, February 7, 2017 6:04 AM
Subject: Re: [wsjt-devel] WSJT-X: QSO start and end times
Hi Mike,
On 07/02/2017 04:45, Black Michael wrote:
In that case it could be simplified to just the start of Tx 2 or 3. CQ/Tx 1
still not being even close in too many circumstances.
Why is Tx 1 not the start of a QSO?
I'd like to see exactly what is being reported as inaccurate and what they
are claiming is the "correct" time since it is rather subjective.
It is because the current implementation attempts to backdate QSO start in a
way that is error prone, for example it assumes a CQ but a sked has no CQ call.
Result is that many start times are two periods before the first transmission,
maybe even when the band or frequency is elsewhere or the computer and radio
not even switched on.
The way I see it is on tx/rx of 1st message.
I'm not sure Rx time of the first message should really be considered, for
example I could decode a station calling me but ignore it while doing something
else that might include me making other QSOs or I could just be leaving the
shack for a meal. That Rx message is not the start of any subsequent QSO. What
do you think of my suggestion to Andy? "Maybe something like: The time of the
first transmission of a standard message that is not CQ or QRZ for a new DX
call. DX call here being defined as the base call to allow for the discovery of
a compound call part way through a QSO." 73
Bill
G4WJS.
------------------------------------------------------------------------------
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
------------------------------------------------------------------------------
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
