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
|