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
|