[RTTY] BARTG HF Contest 2015 Preliminary Results

Thu Apr 9 11:16:02 EDT 2015

Simone,

In my personal opinion, your "cunning plan" seems reasonable and fair to
me. I believe the most important element of the plan is the review of the
exchange by the BARTG committee to potentially eliminate the ambiguity
inherent in the present scheme for future competitions.

I enjoy this contest. I do not participate as a rabid contester but as a
RTTY devotee. However, my enjoyment in a contest is predicated on knowing
that the playing field is level and the rules are clear for all
participants and judges.

73

Mike N1MD

On Thu, Apr 9, 2015 at 8:43 AM, SIMONE WILSON <m0box at btinternet.com> wrote:

> 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
>
>
>
>
>