BARTG HF RTTY Contest
Call: K7IA
Operator(s): K7IA
Station: K7IA
Class: SOAB HP
QTH:
Operating Time (hrs): 9:08
Summary:
Band QSOs Countries Call Areas
-----------------------------------
80: 8 2 7
40: 122 11 15
20: 238 27 19
15: 53 14 12
10:
-----------------------------------
Total: 421 54 53 Continents = 7 Total Score = 270,282
Club:
Comments:
Weekend time split between BARTG RTTY, Russian DX (CW), and chores.
A few suggestions for RTTY ops to make things easier for the running op:
1. To make it easier for the running op, who always transmits on a constant
"running" frequency, Search and Pounce ops should turn OFF Automatic Frequency
Control and set parameters to 170 Hz shift. Then tune the running op's
frequency, which will not change during the QSO. Many callers were so far
outside of my narrow passband (300Hz wide with K3's "Dual Passband Filter")
that my AFC (great in running mode only) could not catch up to the callers.
2. Regarding the Zulu time exchange:
a) Make certain that your computer logger's clock is indeed set to Zulu time
before the contest begins. Make a few "dummy" QSOs and verify that the correct
time is logged. A half dozen stations's clocks were in error by one to three
hours. Running stations have plenty to do to keep the traffic moving, so help
them out by not giving them editing chores. Help yourself, too--mismatched
times in logs may incur penalties for you.
b) The time exchange field is just as important as the serial number, so it
should be sent the same number of times as is the s/n. Doing so minimizes the
need for repeats due to garbles.
c) N1MM Logger (FREEware!) is very automated for RTTY. Callsigns and exchange
fields appearing in the Receive window can be transferred to the logging window
with no more than a mouse click--no manual typing, and therefore, fewer
mistakes caused by fat fingers. The BARTG rules require a FOUR digit Zulu time
in the log. There is no need to add "Z," or colons, or seconds to it, and doing
so only causes the runner to do some needless editing to reduce lengthy time
fields to HHMM format. Anything that slows the runner down also slows down the
Search and Pouncers, so please find out how to truncate your logger's time to
HHMM format so that the running op won't have to edit your exchange. For N1MM
logger, the macro to use is {TIME2}.
3. When band conditions are noisy, as they are when the bands are crowded,
noise can cause garbles in received signals. Thus, it's better to send your
callsign and exchange a minimum of twice instead of once. It is unlikely that
two garbles will affect the same character in a callsign or exchange element if
they are sent twice. Garbles require correction, and that requires repeating
the exchanges. It's surprising how many ops send their callsign/exchange only
once, especially in noisy conditions. When conditions are very noisy, adjust
to them and send everything more than twice.
4. Ever notice the garbled junk characters that usually appear either at the
beginning or at the end (or both) of a line (when the received transmission
begins and ends)? Those garbles are caused by the buildup and decay of the
audio tones when a transmission begins and ends respectively. There is no way
to avoid them, but you can separate those garbles from the "good" text by:
a) Beginning every transmitted string with either a space character or,
better, a Carriage Return/Line feed followed by a space character (Aside: When
you press the "Enter" key, computer Baudot RTTY generates and transmits two
characters and not one: a carriage return followed by a line feed. This is
exactly what the operators did in the old days of "real" RTTY, when mechanical
teleprinters were used. In those days, to move the carriage to the left margin
and to advance the paper by one line, the human operator had to press the CR key
followed by the LF key. You can imagine the result of failing to press either
of those two keys (also imagine the result if one of those key presses were
garbled by atmospheric conditions). The Baudot RTTY "5-level" code hasn't
changed from the machine days, but our computer removes the need for us to
press both keys (in fact, the LF key doesn't exist on modern keyboards). There
are other two-key burdens that the computer has eliminated. Check out the LTRS
and FIGS keys to see what the old timers had to do for punctuation. Yep, the
LTRS and FIGS non-printing characters are still being generated and
transmitted, and, like all other BAUDOT RTTY characters, they are susceptible
to garbles from QRM or QRN. It's left to you to decide which makes more sense
to RTTY ops: sending a signal report as "599" or as "5NN.")
b) Make certain that every callsign (ditto for alphameric exchanges) is
sandwiched between two space characters. This will make the callsign stand
alone, enabling the logger's callsign parser to parse it as a callsign and
allow the operator to click it for insertion into the logging window. This is
another reason to end each exchange string with a space character--if the last
datafield is a callsign, and if the usual garble at the end of the line is
concatenated with the callsign, no parsing will occur, and the operator may be
unsure about the callsign itself.
As you can see, Baudot RTTY is more involved than "texting!"
Thanks for the soapbox, for the QSOs, and for a good time on Sunday!
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
|