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