[RTTY] BARTG HF Contest 2015 Preliminary Results

Thu Apr 9 08:43:02 EDT 2015

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 at gmail.com>
To: pcooper <pcooper at guernsey.net> 
Cc: Simone Wilson <m0box at btinternet.com>; rtty at 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 at 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 at contesting.com
>http://lists.contesting.com/mailman/listinfo/rtty
>