[RTTY] spaces, dashes, and everything

[Jeff Stai]

During this recent WPX I received exchanges with all manner of dashes,
spaces, periods, and even more exotic forms of punctuation. My personal
observations:

- I think either dashes or spaces between numbers is just fine. When I see
dashes or spaces I know what is going on and I can deal with that. What I
have a harder time dealing with is other more exotic punctuation especially
like: ( 485 ) ( 485 ). I tend to associate unexpected punctuation like )
and ( with text that's in error, and if there are any actual bad characters
in the mix these special characters can make it really hard to sort out..
If asked I would probably urge folks to keep it simple, dashes or spaces
are fine, but please keep it to that.

- Did someone publish an article that said that the best form of exchange
was "599nnn" (i.e., NO space)? Because, I don't think I have ever seen so
many of those as this WPX, especially from JA but not exclusively so.
(Think of all the milliseconds this saves...;) Makes it a little harder to
click but otherwise not a big deal, just wondering.

- I also noticed more people are echoing back MY serial number - usually
before they send their serial number (but I did see one or two send my SN
as part of the TU). This seems like a bad idea to me because when receiving
is difficult I am looking for any numbers that make sense, and adding extra
numbers to the mix would only seem to confuse. I personally would urge
folks to not echo back my exchange but maybe there's a good reason to do so
I'm not thinking of...?

- I used spaces between my numbers, and I only send the SN twice (599 nnn
nnn) for what it's worth. Up to 999 I hardly had any fill requests. Once I
had 4 digits in my SN I got a lot more fill requests. I suspect that seeing
4 digits throws some people until they get used to them later in the
contest. I do know 4 digit SNs used to throw me when I was new at this.
Again for what it is worth...

- In a previous life I designed error correcting and detecting codes (EDC)
and methodologies for hard disk drives and for solid state disks. One of
the things I understood from those days is that EDC can be enhanced greatly
if you have usable "back channel" info that can direct you to error
locations. In storage these back channels depend on the media itself, but
for our purposes the received audio constitutes a back channel. I am
finding with sufficient practice at listening to the quality of the signals
I am receiving I can make a good judgement as to which print is good and
which is questionable. It's kind of hard to describe what "good" sounds
like but simple examples of "bad" include crashes and fades. (I expect that
defining "good" here is kind of like defining "smut" - can't say exactly
what it sounds like - but you know it when you hear it.)

Just some foods for thought... - jeff wk6i


-- 
Jeff Stai ~ wk6i.jeff at gmail.com
Twisted Oak Winery ~ http://www.twistedoak.com/
Facebook ~ http://www.facebook.com/twistedoak