RTTY
[Top] [All Lists]

Re: [RTTY] BARTG HF Contest 2015 Preliminary Results

To: rtty@contesting.com
Subject: Re: [RTTY] BARTG HF Contest 2015 Preliminary Results
From: Robert Chudek - K0RC <k0rc@citlink.net>
Reply-to: k0rc@citlink.net
Date: Wed, 08 Apr 2015 18:33:27 -0500
List-post: <rtty@contesting.com">mailto:rtty@contesting.com>
This doesn't make any sense to me.

There are two time "elements" in the BARTG contest. One is part of the exchange. That time stamp is not anchored to the current time (computer clock). The time value in the exchange is "latched" when the first report is sent. It should never change for that QSO.

The second time element is when the operator logs the QSO. That is variable and is irrelevant to the time stamp that was send by the other operator. Consider the time stamp in the exchange as a serial number. Once it is sent the first time, it should never change, even if it takes 10 minutes to complete the QSO.

If the sending operator uses the wrong time stamp macro, that's an operator / operating error. (In other words, if conditions are very poor and it takes 10 minutes to complete the QSO, s/he could send 10 different time stamps! So which one do I log?).

If you are allowing for that variability (poor operating procedure), that penalizes the operators who send the correct (consistent) exchange. The time stamp in the exchange should be treated like a serial number and be flagged as an error if it does not match the other log.

The QSO logged time stamp is a different matter, where the computer clocks can be off by quite a few minutes. Also this varies also whether the QSO is logged when it is initiated or when it is completed by each operator. A reasonable window of "match" is understandable in that circumstance. I would hope RTTY operators would be "in synch" +/- 10 minutes of each other (or less).

Or am I missing something here?

73 de Bob - KØRC in MN

------------------------------------------------------------------------
On 4/8/2015 5:30 PM, Simone Wilson wrote:
CQ,
I have noted a significant problem, highlighted by a few respondents, where the exchange element of the QSO time is out by one or more minutes. This can happen as the clock ticks over the minute mid QSO and under difficult condition, even two minutes. Whilst the original time is transmitted the number finally logged is the current clock time due to the wrong time macro being used in the exchange setup. I have therefore decided to allow a tolerance of two minutes on the exchange time to cope with this very common fault. The test has been re-uploaded and is again available at the URL below.

73 de Simone. M0BOX

BARTG Contest Manageress


http://tinyurl.com/opezrbn

_______________________________________________
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

<Prev in Thread] Current Thread [Next in Thread>