Simone, does (or, can) your log checking software produce a listing of how
many times each station's sent exchange was (supposedly) busted by the other
station? If so, a high percentage in this listing casts suspicion on the
sending station's ability to log what they actually sent (or, to send a
consistent exchange through repeats). Having this data doesn't solve the
problem, but gives you better insight into what the problem really is and
how extensive it is.
As others have commented, using time as an exchange element has two sides.
On the one hand, it is an easy way to create unique exchanges that require
careful handling by both sides of the QSO. It really doesn't matter what
the time exchange element really is, relative to actual time, but only that
the receiving station copy what was sent. On the other hand, time "may" be
more problematic than serial number or other unique exchange element, in
that it can have a wider range of inconsistency on the sender's end. And,
on the receiving end, one could incorrectly guess the time exchange element
by looking at one's own clock. But, one can argue that any unique exchange
element is subject to the same potential issue of the sending station not
consistently sending only one unique exchange element per QSO and logging it
correctly.
The same issue occurs with serial number contests and some log checkers
allow the serial number to be off by one. Even that is not perfect because
the receiving station may have missed hearing his serial number but copied
the next QSO's serial number and assumed that his from the prior QSO is N-1.
That assumption can often be wrong when the running station is SO2R with
runs going on two radios. He really didn't copy what was sent but the log
checking gives him a free ride.
Thus, this problem occurs with any unique exchange element. For constant
exchange elements, it is easy enough to construct reverse logs and decide
that the exchange actually sent is what most recipients logged. Reverse
logs also highlight the problem of receiving stations relying on prefilled
exchanges rather than copying and logging carefully.
Free rides aren't necessarily bad unless they are so prevalent as to
invalidate the basic concept of making a valid QSO most of the time. Each
contest organizer needs to decide whether the challenge of using unique
exchanges is more important than being able to adjudicate the logs closely.
Ed W0YK
-----Original Message-----
From: RTTY [mailto:rtty-bounces@contesting.com] On Behalf Of SIMONE WILSON
Sent: 09 April, 2015 05:43
To: Michael Therrien; pcooper
Cc: rtty@contesting.com
Subject: Re: [RTTY] BARTG HF Contest 2015 Preliminary Results
This is a contentious issue, I never expected it to be otherwise. It is a
problem that didn't exist in the older manual days, but with the advent of
computers doing the job it has shown up issues.
I have been given proof positive of the issue. Let me sumaraise. Station A
is the CQer and station B is the responder. A sends his exchange G9AA ur 599
123 1234 KN so far so good, B sends G9BB ur 599 206 1235. Still good as long
as each station puts the final time element they TX in their log. However
A's log submitted to me shows he sent 599 123 1235.
It has long been the assumption that the sending log is the correct one so I
should, and the automatic adjudication does, invalidate B's logged QSO,
Given we can, and do, log the text window to a file when contesting - just
in case - you can clearly see that B received 1234 from A, yet A logs 1235.
Go figure. Now I know that N1MM+ has a specific macro called TIME2 which
grabs the time to TX and doesn't let it alter until the QSO completes or is
abandoned. But if this particular macro isn't selected by the operator then
the time becomes subject to real time, thus the error occurs. Is this the
case for other RTTY contesting software? Not all submitted logs contain the
imformation to see which programme was used to generate the log, so I can't
point any finger on the issue, however it is clear that incorrect macro
selection will cause an issue.
So the question then raises how to adjudicate this problem, and believe me
when I say it is a significant problem. I have three choices:-
1. Believe the logs reflect what was transmitted and adjudicate accordingly.
2. Allow some flexibility to cope with this error.
3. DQ both sides of the contact due to an error on one side because one side
did make a mistake.
If I select 1, then there will be howls of protest from those whose contacts
are incorrectly DQd with reams of evidence to prove their point. If I select
3, there will be howls of protest from those whose QSO was otherwise
correct. Selecting 2 seems to me to be the logical option (generating far
less howls of protest that either 1 or 3) following it up with a review on
the whole contest exchange for future tests.
Option 2 is the one I am going to take. Ultimately, as the Contest
Manageress, it is my decision to make. It will provide the best and fairest
solution. I will then conduct a review with the BARTG committee with a view
to drop the variable element of the exchange and replace it with something
that will challenge you, but not be reliant on the vagaries of time.
Something that all current popular contesting software already handles. In
the words of Baldrick, I have a cunning plan.
73
Simone - M0BOX
BARTG Contest Manageress
________________________________
From: Michael Therrien <mike.n1md@gmail.com>
To: pcooper <pcooper@guernsey.net>
Cc: Simone Wilson <m0box@btinternet.com>; rtty@contesting.com
Sent: Thursday, 9 April 2015, 12:29
Subject: Re: [RTTY] BARTG HF Contest 2015 Preliminary Results
I concur fully.
I am thoroughly baffled by discrepancies of HOURS noted in my RBN data.
I may not participate in this contest again unless the fairness and
adjudication issues can be adequately resolved.
Mike N1MD
On Thu, Apr 9, 2015 at 5:42 AM, pcooper <pcooper@guernsey.net> wrote:
Hi all,
>
>I am not sure that this is a good idea, and probably requires a little more
analysis before making this move.
>
>As has been noted, there are FOUR instances of the time in each QSO, but
the logged time is really of little or no consequence.
>
>Proper contesting software will allow the user to transmit the time as part
of the exchange, and will keep it at that same time if repeats are needed -
and they were in many cases, with me at least.
>
>I wonder how many of these logs that were off by more than 1 minute were
not compiled using one of the major contesting programs?
>
>I know Writelog handles it correctly, and I assume that N1MM and some of
the others do too.
>
>Looking at my RBN (from the first pass), I did note several deductions
where the time was off by a minute or two, but what was more concerning were
the number of contacts that appeared in the RBN that were off by a large
number of minutes.
>I had a couple that were something like 2h 40m off, and at least one was
from a major contest station, which makes me suspicious.
>
>The time as sent is pretty much arbitrary, and one only has to copy what
was sent, not the ACTUAL time, but I would guess most serious contest
entrants will have synched their shack PC at the start of the contest, or
more likely have an app that keeps the PC clock synched all the time.
>I am willing to concede that I may well have entered a wrong time from a
few stations, especially given the awful conditions that were present during
the contest, but I really can't understand why I would be so far off on a
few.
>
>It would be interesting to know what software the logs that were off by a
minute or two were running.
>
>I don't have access to my RBN here at work, but I will check it again when
I get home, and see what it shows about times being off by so much.
>
>73 de Phil GU0SUP
>
>_______________________________________________
>RTTY mailing list
>RTTY@contesting.com
>http://lists.contesting.com/mailman/listinfo/rtty
>
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
|