CQ Worldwide DX Contest, RTTY
Call: K7IA
Operator(s): K7IA
Station: K7IA
Class: SOAB HP
QTH: NM
Operating Time (hrs): 25:17
Summary:
Band QSOs Pts State/Prov DX Zones
------------------------------------------
80: 79 102 31 9 9
40: 202 368 44 39 14
20: 278 501 47 47 15
15: 378 717 45 52 21
10: 289 740 23 39 12
------------------------------------------
Total: 1226 2428 190 186 71 Total Score = 1,085,316
Club: Arizona Outlaws Contest Club
Comments:
Best outing yet! The high bands were wonderful, and even 40 and 80 were
unusually quiet.
Last week I completed writing a "Primer" on Contesting and RTTY. It covers the
"basics" of each, and it's been reviewd by a number of RTTY contesters, both in
North America and Europe. Using numerous examples, it explains the differences
between contesting and ragchewing, how to make efficient contest exhanges, how
Baudot RTTY is very unlike the newer digital modes (and therefore how to
commuicate within the limitations of 5-level Baudot Code, and a wealth of
operating tips. If you're interested in a copy, then please send me an email,
and I'll send one to you.
Because proper "parsing" of callsigns and contest exchange elements is one of
the best ways that RTTY contesters can assist each other in making contest
calls and exchanges, here's an excerpt from my Primer to whet your whistle:
Parsing Exchange Elements
Parsing is not new to you--you're doing it right now. As you read this, you
are visually parsing the words, thanks to the spaces and punctuation characters
between them. If there were no such separators,
itwouldbeverydifficultbutnotimpossibletoreadthetext. Without RTTY parsing
separators, callsigns and exchanges are often difficult to read, and it is
nearly impossible for a contest logger to distinguish a valid callsign or
exchange fields. Yes, loggers like N1MM look for callsigns and color highlight
them on the receiver's screen, but N1MM cannot find callsigns unless they are
surrounded by parsing separators. Three events interfere with parsing
separators: they may be garbled in transmission; phantom letters usually
appear at the tail end of the other op's transmissions; and most commonly, most
RTTY operators don't include parsing separators in the first place. We cannot
prevent garbles and phantom characters, but we can encourage operators to use
parsing separators.
Phantom Characters:
I've already discussed garbles, the first of the above three events, so let's
move to the second, the appearance of phantom characters. If you have ever
made more than a handful of RTTY contacts, you have undoubtedly seen a
"phantom" character or two appear on your screen where the "typehead" is when
the other operator's RTTY signal disappears. It happens because the transition
from RTTY signal to normal background noise is not a smooth one, and the sound
card interprets the transition audio as RTTY and makes a character (or two).
This is not the fault of the sound card or your RTTY engine, because I saw the
very same thing back in the 1970's when I was using my Model 15 and ST-6 analog
demodulator. If the sending operator doesn't include parsing separator
characters in his transmissions, the beginning and end of his every
transmission will be joined to phantom characters. This makes visual parsing
difficult and logger parsing nearly impossible. Result: the receiving
operator must either manually enter callsigns and exchange data by keystrokes,
or ask the sender for a repeat. Either way, the QSO rate slows down. I
emphasize that it is the transmitting operator, and not the receiving operator,
who must take steps to make his transmissions easy for the receiving operator to
parse. This is why I send every contest transmission as a separate line of type
and why I ensure that every string in that line of type is sandwiched between
parsing separators. For parsing to work, both the CRLF and space character
"sandwich" must be created.
When the sending operator makes it easy for the logger to parse, the receiving
operator can enter QSO info simply by mouse clicks, speeding up the QSO (and
avoiding entry typos). For example, N1MM will identify every combination of
letters and numerals as a callsign if that combination follows the general
format rules of a callsign. Every instance of a so-identified "callsign" is
color highlighted on the screen, and a mouse click on a highlighted callsign
places it into the callsign box of the QSO entry window. No more slow manual
typing! No more fat finger typos! Additionally, while contest exchange
elements are not color highlighted, left clicking them, one at a time, places
them into their respective entry boxes in the QSO entry window. The chaps that
seem to respond quickly to contest exchanges they receive aren't fast
typists--they're fast mouse clickers!! They are fast only when their senders
include parsing separators in their transmissions.
Here is an illustration of phantom characters and parsing:
I'll send my CQ call using the Running F-1 Macro above, and I see the following
on my screen:
CQ CQ SARTG K7IA K7IA (Print begins in column 2)
V (Phantom character in column 1)
The first line is the text in my F-1 macro (including the leading space
character). The last two characters I send is the CRLF pair, placing the
typehead at the first column of the second line. The transition from RTTY
audio to background noise (MMTTY listens to my Tx monitor) prints the "V" in
the second line's first column--a "phantom character." There's a good chance
the S&P has a phantom character or two in the first column(s) of his second
line. His phantom character(s) may not be the same as mine, because his sound
card is different than mine. But you should always assume the other operator
is seeing phantom characters.
Now suppose my friend K7IPZ, answers my call by sending only his callsign
(twice) without including CRLF and separator spaces at beginning and end of his
transmission. Here's what I might see on my screen, beginning with the display
above:
CQ CQ SARTG K7IA K7IA
VK7IPZ K7IPZYQ
Here you can see that K7IPZ's callsign is concatenated to the phantom "V," and
two more phantom characters, "YQ" produced by the transition at the end of
K7IPZ's transmission have been added to the display. My screen's "typehead"
sits immediately after the phantom "Q," because K7IPZ did not begin with a CRLF
pair. "VK7IPZ" follows the rules of a callsign, and it will be color
highlighted by N1MM. "K7IPZYQ" will not be highlighted. You can imagine how
excited I might be as I think, erroneously, that an Australian is calling me,
but the presence of "K7IPZYQ" means the "Australian" is a phantom, too.
If K7IPZ had instead placed space characters at the beginning and end of his
transmission, then my screen would display:
CQ CQ SARTG K7IA K7IA
V K7IPZ K7IPZ YQ
and both instances of his callsign, K7IPZ, would be highlighted. K7IPZ's line
of print still ends in the column following the letter "Q" above, instead of at
the beginning of the following line. Since K7IPZ sent his callsign more than
once, and since both instances match each other, then I am certain that my copy
of his callsign is correct. But if there is no match, then I'll wonder which of
the two is correct. I'll need a "tiebreaker," to decide, so I'll ask him for a
repeat, slowing things down.
It's would be far easier if K7IPZ had added CRLFs at beginning and end along
with the parsing separators. This would be the result on my screen (his screen
would be similar):
CQ CQ SARTG K7IA K7IA
V
K7IPZ K7IPZ
JS
Note that phantom characters (most likely different ones) still appear in the
first column in a line, but the leading space of the CQ message and his
callsign appear in the second column. K7IPZ's transmission is now easy to
parse by eye and by logger, and I can immediately send my exchange to him.
The example above shows how parsing the beginning and end of a transmission is
facilitated. Now let's consider parsing of exchange elements. When I send my
F-2 exchange to K7IPZ, here is what his screen should display:
CQ CQ SARTG K7IA K7IA My CQ call
H Phantom character
K7IPZ K7IPZ His parsed S&P F-1 callsign
WL Phantom characters
K7IPZ TU 599-078-078 K7IA My parsed Run F-2 exchange
MU Phantom characters
Notice how "tidy" the appearance of his screen is. If K7IPZ is using a logger
that can parse callsigns and data elements, then all he needs to do is to hover
the mouse cursor over one of the serial numbers, "078," and left-click to copy
the s/n into its data entry box. He should have already left-clicked my
callsign as I called CQ, so there's no need to do it again. And because the
signal report is "599," there's no need to click it, because loggers default to
"599." Parsing transmitted strings reduces data entry to mouse clicks, and
every operator can make more QSOs per hour.
Let's look quickly at the exchange of a hypothetical contest where signal
report, serial number, and first name are exchanged. My Run F-2 exchange would
be:
K7IPZ TU 599-066-066 DAN DAN K7IA
All K7IPZ needs to do is to hover the mouse over a serial number, 066, and left
click, then hover over my name, DAN, and left click. Data entry finished, send
exchange, and QSO is finished.
I would NOT craft my exchange as:
K7IPZ TU 599-066-066-DAN-DAN K7IA
and I'll leave it to you to decide why...
Use a space character to separate alphabetic strings (a space is nonprinting
and ensures the carriage remains in LTRS shift), and use a FIGS shift
punctuation character to separate groups of numbers (because the carriage is
already in FIGS shift). If you use a space character to separate number
groups, then the carriage will first downshift to LTRS shift (recall Unshift on
Space is turned on), and then another FIGS shift has to be sent before the next
numeric string can be sent. Sending more FIGS and LTRS increases the
probability that one of them will be garbled, leaving the carriage in the
incorrect shift. (Remember that when UOS is turned on, a space character is
automatically followed by a LTRS shift.) I use the hyphen to separate numeric
strings it is a FIGS shift character and because it doesn't interfere with
vision.
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
|