3830
[Top] [All Lists]

[3830] WAE RTTY K7IA Single Op HP

To: 3830@contesting.com, k7iaham@gmail.com
Subject: [3830] WAE RTTY K7IA Single Op HP
From: webform@b41h.net
Reply-to: k7iaham@gmail.com
Date: Sun, 11 Nov 2012 17:06:24 -0800
List-post: <3830@contesting.com">mailto:3830@contesting.com>
                    WAE DX Contest, RTTY

Call: K7IA
Operator(s): K7IA
Station: K7IA

Class: Single Op HP
QTH: NM
Operating Time (hrs): 16:26

Summary:
 Band  QSOs  Pts  QTCs  Mults
------------------------------
   80:   36   36          56
   40:  134  134    50   126
   20:  158  158   160    82
   15:  133  133    69    90
   10:   66   66   230    62
------------------------------
Total:  527  527   509   416  Total Score = 430,976

Club: Arizona Outlaws Contest Club

Comments:

Unlike previous years, I ended up with a few dozen unsent QTCs--points lying on
the table!  SA ops can pick up a load of QTC points in the last three hours of
this event.  Amazing how many ops worldwide refuse "free" points...

RTTY Contesting Tips:

Contesting is a cooperative effort between all ops involved, regardless of
mode, but owing to its very nature, RTTY needs even more cooperation for a
number of reasons, including:  all "Search and Pounce" stations calling a
"Running" station are at nearly zero beat and QRMing each other in a pileup; 
RTTY is indeed a digital mode, but unlike "modern" digi modes, it is not error
correcting, it is very prone to garbled characters (and non-printing carriage
control characters); and it doesn't use the 8-level ASCII code, so the
transmitting operator can never be certain about the status of the other chap's
carriage or LTRS/FIGS case.

The aim of the following tips is to promote the cooperative effort between
sending and receiving ops.

1.  Read the contest rules before the event so that you well know what the
required exchange is.  The WAE's exchange is only RST and serial number, so
adding name, state, etc., only slows things down.

2.  Learn the differences between the "Running" operator and the "Search and
Pounce" operator.  They have different roles in the flow of a QSO exchange.

3.  Learn how to zero beat the RTTY station you wish to call.  The WAE was not
a particularly crowded event, but other RTTY contests are, especially CQ WW
RTTY, ARRL RTTY Roundup, and NAQP RTTY.  In crowded RTTY events, Running ops
use narrow passband tuning to reduce interference between adjacent Running
neighbors.  When an S&P makes a call that is not at zero beat, he may out of
the passband, and not be heard by the Running op he is trying to call.  Worse,
he will QRM the adjacent Running op and his pileup.

4.  Construct your contest exchange messages (macros) so that they are short
and sweet.  The longer a RTTY macro message, the greater is the chance for
garbles, particularly when QRN and QRM are high.  Garbled characters lead to
undertainty regarding callsigns and exchange data fields, and the only way to
clear up uncertainty is to ask for a repeat, which consumes contest time. 
Therefore, you can minimize the lengths of your macros by sending only the
information needed and required by the contest sponsor:  your callsign, the
other chap's callsign (so he is certain that you have it), and your exchange. 
You should send nothing else--omit the prosigns, greetings, and other time
consuming and garble-enhancing "fluff," like: DE, BK, K, KN, GL, NR, RST, QSL?,
GL, date/time, and the like.  Keep in mind that a contest is just that--it isn't
a ragchew or a QSO Party.  Serious contesters want to make as many
accurately-logged QSOs as is possible in the time alloted to the event.  Please
don't slow them down by sending non-essential fluff.

5.  Understand that in the past, the signal report used to convey some "real"
information in contest events, but that is no longer the case.  Both contesters
and contest logging software are "pre-programmed" for RST = "599." I's a bloody
nuisance to edit the RST field whenever something else is sent, so just go with
the flow and send RST only ONCE, as "599."  The real meat of the exchange is
whatever accompanies the signal report.  In the WAE, it is the serial number,
which should be sent at least twice (twice in good condx, a few more times in
poor conditions).  Whoever sends a s/n to me only once will be asked to repeat
it, garbles being what they are.  So pay attention to the conditions and adjust
accordingly.

6.  When you make your initial S&P call to a Running op, send only your
callsign, and send it twice in good conditions, three times in poor conditions.
 Do not send his callsign (or "DE")--he is the only Runner on "his" frequency,
and he already knows his callsign.  Those needless characters QRM the other S&P
ops who are calling, and they increase the risk of garbles.  Note well that the
Running op wants to service all of the S&P ops who are calling, and he wants to
do it quickly and accurately so that the S&P ops can get on their way to work
other Runners and so that the Runner can enjoy a high QSO rate.  RTTY QRM often
makes it impossible to decode and print anyone, and when that happens, no QSOs
are made, wasting everyone's time.

7.  If you're an S&P op, the Runner will send his exchange to you first, and
then it's your turn to send your exchange.  Send just your exchange--do not
repeat his exchange back to him, because it wastes time (other S&Pers are
waiting for their chance), and the Runner already knows his exchange.

8.  Similarly, if you're an S&P op, the QSO is finished when the Running op
acknowledges receipt of your exchange (he will send "TU" or "RRR" or "QSL") 
Sometimes the Runner won't send any sort of confirmation, moving to his next CQ
or QRZ call.  That leaves the S&P op hanging, in my opinion.  If you aren't
certain that your QSO has been acknowledged, then call him again (or don't log
him).  After the Runner confirms receipt, there is no need to add to the QRM by
saying "thanks" or "good luck" again, so let the Runner make his next call.

9.  In my view, most of the wasted time, confusion about callsigns and exchange
fields, and garbled characters are caused by poorly constructed macro messages. 
By "poorly constructed" I mean that they inhibit "parsing" of the elements of
the exchange message.  Both the operator and good contest logging software
parse incoming RTTY text, so here is where you can make it either easy or
difficult for the other op's eye, contest logger, or both.  You should
construct your macro exchanges so that all of data fields (including callsigns)
are separated by appropriate "parsing separators."  The reason you can read this
paragraph easily is because I have placed a parsing separator between each of
the words--a space character.  You should do the same in your RTTY contest
macros.  I discuss RTTY parsing at great length in a document I recently
wrote:

I have recently written a primer discussing the basics of contesting and RTTY
(principal emphasis on RTTY contesting).  If you are interested in examining
the above tips (and more) at a deeper level, then please send me an email, and
I will be pleased to send a copy to you.  It's in .pdf format, so you will
receive it quickly.  It's been well reviewed by both experienced RTTY
contesters and newbies, it's 40 pages in length, and there is no "fluff!"

Thanks for the QSOs!  See you in CQ WW CW.

73,
dan k7ia


Posted using 3830 Score Submittal Forms at: http://www.hornucopia.com/3830score/
______________________________________________
3830 mailing list
3830@contesting.com
http://lists.contesting.com/mailman/listinfo/3830

<Prev in Thread] Current Thread [Next in Thread>
  • [3830] WAE RTTY K7IA Single Op HP, webform <=