[RTTY] BARTG HF Contest 2015 Preliminary Results

[Gary Senesac]

Bob,

Actually, there are four time elements involved, two at each end.  I agree with you that the only ones that matter are what was sent and received by each party.  The time sent is automatically generated by the macro that reads the computer clock at that instant.  If that is time grabbed at some hhmmss and the ss part happens to be at 59, then my clock time has already incremented before the other station has finished printing it, let alone logging it!

Even were every one to accurately calibrate their clocks to UTC at the start of the contest these sorts of errors would still creep into the logs.  In the case of my logger, WriteLog, if I've already logged the QSO and then the other guy asks for a repeat of the time my logger will send him the time sent in that QSO, not the current time.  In that regard the time stamp is treated exactly like a serial number and both stations should have logged the same time.  It is useless to compare the time sent with the time logged when the contact is finally completed.  Too many variables can intervene to cause a discrepancy that ultimately is meaningless.

Gary AL9A
Sent from my Kindle HDX

On April 8, 2015, at 3:33 PM, Robert Chudek - K0RC <k0rc at citlink.net> wrote:

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
>

_______________________________________________
RTTY mailing list
RTTY at contesting.com
http://lists.contesting.com/mailman/listinfo/rtty