[RTTY] BARTG HF Contest 2015 Preliminary Results

[Robert Chudek - K0RC]

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 at contesting.com
> http://lists.contesting.com/mailman/listinfo/rtty
>