[CQ-Contest] RDXC Log Checking

[Ed Steeble]

Bob,

Regarding: >
 > 1) What happens when the second checksum is received wrong? How do you
 > "start over"?

Wouldn't it be just like you would do w/o a check sum, ask for a repeat? 
However the repeat should include the call and checksum too, not just 
the RST and serial number. Part of this exercise involves getting the 
call correct too.

73, Ed
K3IXD

Robert Chudek - K0RC wrote:
> "This would be a good contest for improving coping of call signs and
> exchanges. The negative is the contester couldn't log the casual
> operator who dropped by to hand out a QSO, to work DX, or maybe states
> for Triple Play award. However, there could be a special (null) check
> sum value for those situations."
> 
> Two questions...
> 
> 1) What happens when the second checksum is received wrong? How do you 
> "start over"?
> 
> 2) "a special (null) check sum value for those situations"... Isn't that 
> what "599" already is?
> 
> 73 de Bob - KØRC in MN
> 
> 
> 
> ----- Original Message ----- From: "Ed Steeble" <esteeble at sc.rr.com>
> To: "cq-contest" <cq-contest at contesting.com>
> Cc: "Ed K3IXD" <esteeble at sc.rr.com>
> Sent: Friday, March 13, 2009 9:23 AM
> Subject: Re: [CQ-Contest] RDXC Log Checking
> 
> 
>>
>> After reading all the back and forth comments generated by K5ZD about
>> the RDXC log checking I think that we need a new contest which has a
>> new exchange or a contest with a modified exchange. Namely, a contest
>> with a software generated checksum to be sent back in acknowledgment of
>> the exchange. The checksum insures accuracy.
>>
>> I propose that the software programs be revised to compute a simple
>> check sum from a public algorithm. The check sum would be computed from
>> the sender's QSOs date (YYYY/MM/DD - Zulu date), time (in hhmm - Zulu
>> time), band (in meters), call sign worked, and exchange sent (maybe RST
>> and serial number).
>>
>> For example, a contest that requires RST and serial number.
>>
>> K3IXD calls CQ.
>>
>> K5ZD answers him.
>>
>> K3IXD sends on 20m at 2009/03/12 1359z:
>> K5ZD 599 025 K3IXD (and K3IXD software computes a checksum based on what
>> he sent).
>>
>> In reply K5ZD sends on 20m at 2009/03/12, 1400z:
>> K3IXD 599 060 ab45 K5ZD (his software has computed a checksum on what he
>> copied. Also the software computed a checksum based on what K3IXD sent.
>> That will be compared to what K5ZD receives from K3IXD in the following
>> exchange).
>>
>> If K3IXD receives a checksum that matches what his software expects, he
>> replies:
>> K5ZD fj98 K3IXD (the checksum computed from what K3IXD copied)
>> else K3IXD retransmit his original exchange, but not with a new QSO
>> date/time.
>>
>> If that matches what K5ZD software expects, K5ZD replies:
>> K3IXD TU K5ZD
>>
>> K3IXD calls CQ
>>
>> This would be a good contest for improving coping of call signs and
>> exchanges. The negative is the contester couldn't log the casual
>> operator who dropped by to hand out a QSO, to work DX, or maybe states
>> for Triple Play award. However, there could be a special (null) check
>> sum value for those situations.
>>
>> The WAE already has contesters sending QSO information back but to
>> another station. All :-) it would take is for some sponsor to require a
>> checksum exchange and one or more software developers to implement it.
>>
>> 73, Ed
>> K3IXD
>>
>>
>> _______________________________________________
>> CQ-Contest mailing list
>> CQ-Contest at contesting.com
>> http://lists.contesting.com/mailman/listinfo/cq-contest
>>
> 
> ------------------------------------------------------------------------
> 
> 
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.0.237 / Virus Database: 270.11.10/1996 - Release Date: 03/11/09 20:42:00
>