RTTY
[Top] [All Lists]

Re: [RTTY] RTTY DX'ing tutorial

To: "'Alex, VE3NEA'" <alshovk@dxatlas.com>
Subject: Re: [RTTY] RTTY DX'ing tutorial
From: "Ed Muns" <ed@w0yk.com>
Reply-to: ed@w0yk.com
Date: Sun, 10 Apr 2016 13:16:49 -0700
List-post: <rtty@contesting.com">mailto:rtty@contesting.com>
This post came in as I am wrapping up a presentation on "RTTY DXing" for DX
University this coming Friday at the IDXC in Visalia, CA.  It sort of caught
my attention.

Many of the skills that work on one mode also apply to the other modes.
However, there are some key differences, of course.  For a start, many of
the behaviors we see in RTTY DXing, or contesting, are counter-productive.
Simply following the best practices that have evolved over the years in CW
DXing would be a big improvement.  We should always ask why the RTTY mode
needs to be different.  Many times there is no good reason other than
tradition. 

For example, a pseudo-QSK (or, more accurately semi-break-in) can be
mimicked if everyone would make their call sign message just a single
instance of their call sign.  Then, they can tap the message key once,
listen for a few milliseconds, before tapping it again.  This way, they can
send their call sign multiple times, if appropriate, but stop sending when
the DX station starts transmitting.  This single call sign message can
dynamically create a string of call signs of any length.  Unfortunately, the
norm nowadays is to punch a message key that repeats one's call sign 4
times, so the transmission often doubles with the DX station.  If the DX
station is not transmitting when this long message completes, they operator
may send it again, leading to very inefficient operating.

The obvious main difference with the RTTY mode is the use of a hardware or
software decoder rather than the human ear/brain as in CW.  This fact
rightfully makes some of the RTTY operating behavior and messaging different
than CW or SSB. 

One example is sending a serial number, or other unique exchange element,
twice in an exchange.  In CW, a serial number is typically sent just once
and the receiving operator's ear/brain can usually tell if he got a clean
copy.  In RTTY, that dimension is missing and all we have to go on is what
prints.  That is not enough to judge reliability of the copy, so it is
advisable to send a serial number twice.  (Sending it three times so the
receiver can have confidence of at least two of the three match is better,
but of course takes more time.)  GRITTY has advanced decoding capability in
this regard by applying Bayesian statistics, but it is still not as capable
as the ear/brain is for CW.  Thanks for your creative contributions in this
area, Alex.

BTW, there were times this weekend when GRITTY allowed me to copy my report
from a weak DX station buried in DQRM when MMTTY and 2Tone got no hint.
Pretty cool.

Ed W0YK
_______________________________________________________________________

Alex VE3NEA wrote:

I started chasing DX using RTTY three months ago, after 35 years of DX'ing
CW only. Trying to learn the new mode, I searched the 
Internet for RTTY tutorials, and I found quite a few, but all of them either
explained how to set up MMTTY, the software that I 
do not use, or how to operate in the contests. The only presentation on RTTY
DX'ing I could find just told me that I needed two 
macros, my callsign and "599 TU" - something that I had already figured out
myself. How to crack the pileups, how to find the DX 
listening frequency, how to choose the right time to send your call - none
of this was covered in the publications that I could 
find. I know that many of the subscribers to this list are experienced RTTY
DX'ers, even though it is a contesting list, some 
are even on the Honor Roll - perhaps you guys could share your RTTY DX'ing
techniques with those of us who are just making their 
first steps in this area.

Having no RTTY-specific skills, I tried to use my CW techniques to crack the
RTTY pileups, and this worked, to some extent, but 
I quickly discovered that there are some important differences between the
two modes that needed to be addressed. For examnple, 
in CW I use QSK to know when the DX station starts transmitting, so I can
abort my own transmission and listen. Since there is 
no QSK in RTTY, those who send their call 4 or 5 times, have no idea if the
DX has already answered someone or is still 
listening for a new call. They just keep calling, often on top of the
station being worked. My solution to that is to ensure 
that my own messages are shorter than anything the DX might send. Since the
DX usually sends something like <call> 599 <call>, I 
figured I should send my own call no more than 2 times, then I will catch at
least the end of the DX transmission and know in 
what stage the current QSO is.

There is another difference between CW and RTTY. When I find the DX
listening frequency in CW, I tune my TX about 100 Hz higher 
or lower, since I know several others will be calling precisely on that
frequency and will interfere with each other. This often 
works in CW, but not in RTTY: the RTTY decoders do not pick up the signals
that are 100 Hz off, so I have to either call on that 
exact frequency or tune a few hundred Hz away, hoping that the DX will do
the same.

One technique that rarely worked for me in CW but worked much better in RTTY
is tailgating. If the DX operates simplex, quite 
often several stations start calling him on the same frequency, resulting in
no copy at all. I wait until they finish calling, 
then, without any pause, send my call once. On more than one occasion I
added a new one to the log using this trick.

What works for you, and what doesn't? What extra hardware or software does
one need to be competitive in the RTTY pileups? 
Please share your experience.

73 Alex VE3NEA







_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty

_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty

<Prev in Thread] Current Thread [Next in Thread>