[RTTY] DX-Stations guide to RTTY, Rev. 0.0

[Ekki neu]

As mentioned in my other mail, I think it would be useful to write a guide
for DXpeditions who want to work RTTY. RTTY is becoming ever more popular
due to simple and affordable soundcard solutions, so it becomes more and
more interesting as alternative mode for DX-peditions.

This guide is work in progress and requires YOUR help. Many parts are not
finalized yet (marked [TBD]), or need to be rewritten or enhanced or
corrected.
So, if you have any input, corrections, hints, or just think that I am
blatantly wrong, please reply on the list or privately to ekki@df4or.de
So far (Rev. 0.0) this document covers only my opinion on how to RTTY on a
dxpedition... surely not the last word in expert dxing...

================================================
DX-Stations Guide to RTTY
Rev. 0.0 dated 23.April 2002
maintained by Ekki, DF4OR, email: ekki@plicht.de


This guideline should help you in preparing your dxpedition and make the
most out of RTTY.

0. Revision history
Rev. 0.0 dated 23.April 2002 - started guide
================================================
Contents
1 Equipment
1.1 RTTY Hardware
1.2 RTTY Hardware Transceiver
1.2 RTTY Software

2. Frequencies
2.1 Classic bands
2.2 WARC bands

3. RTTY Operation

4. Misc
4.1 How about other digital modes?
4.2 DX during an RTTY contest?
4.3 Is it worthwile at all? How many RTTYers are there?
4.4
================================================
1 Equipment
The question on hand is whether to use an external TNC or TU (Terminal Unit)
a la KAM, PTC (TBD: other brands???) etc. or use the soundcard of the
notebook you have with you anyway. There is no easy answer, but here we go.
Probably the best advice is: Take the equipment your are most familiar with!
You have to handle it in stressful, uncomfortable situations and should know
it very well.

1.1 RTTY HARDWARE
TNC vs Soundcard (SC) comparision table, in no particular order
(this will be a table later, here in tabular format for sake of plain text
email)

Does more than one mode
- TNC: Yes, maybe helpful in other situations (e.g. Pactor link to back
home, WinLink network)
- SC: RTTY only (most)

Requires extra power supply
- TNC: Yes, but you could probably draw power from the rig with just one
cable for power and data.
- SC: No.

Redundancy
- TNC: Only if you take more than one (preferrably of the same model)
- SC: most likely in each notebook you have with you anyway

Performance
- TNC: No to very little requirements on the PC side, just a serial cable
port. If you have only pure DOS machines with you, TNCs are the only
practical solution, there is no support for soundcard solutions under DOS.
Up to date DSP TNCs handle (decode) RTTY very well, although AF filters are
not configurable.
- SC: Can make intense use of resources on the PC under Windows(tm).
Recommended speed of PC is something around 300 MHz and above, 32 MB RAM or
more. Make sure that all system sound events are turned off. Make sure that
resource consuming processes are stopped (virus scanners, scheduler, power
management etc.) Fine tuning the performance of soundcard solutions often
requires a somewhat deeper knowledge of the PC and OS.
- Note: Some informations hints that MMTTY (soundcard software) decodes RTTY
better than many expensive TNCs, under certain conditions. This may apply to
5% or less of all contacts. (TBD: how does other sc software compare???)

Ease of use, repairing
- TNC: If broken, forget it. Take two or more TNCs of same model with you.
- SC: Just a cable, could be done on site. If the soundcard itself or the
operating system integration fails - forget it. Take OS CD ROMs with you,
just in case.

Cost
- TNC: mid to high
- SC: low to zero

Weight, Size:
- TNC: around 500 grams (excluding cables), size approx.: x by x by x
centimeters [TBD]
- SC: weight: cables only, size: none

Automated operations (mailbox, winlink)
- TNC: Yes, most
- SC: No

Problems with interfacing to Transceiver
- TNC: requires AF in (or FSK), AF out, PTT. Does support FSK vs AFSK in
most cases.
- SC: requires the same: AF in, AF out, PTT. Some sc solutions support FSK
(MMTTY). PTT requires a miniml interface with one or two transistors, fits
in the serial cable jack.
- Both: Adjust the modulation level very carefully, do not override the
transmitter (distortions, side spurs).

Conclusion Hardware
>From the above it seems that soundcard solutions win easily, at least from
the p.o.v. of a dxpedition. It's free, weighs nothing, easy to repair.
Downside: requires Windows and a somewhat more powerful PC. Extensive
testing before the expedition is highly recommended, but you know that
anyway.

Recommended Hardware (TNCs):
(TBD)

1.2 RTTY HARDWARE Transceiver
Since RTTY is continuos in its output, as opposed to SSB or CW, make sure
the rig and linear you are using can sustain that full load over extended
periods. If not, reduce power to 50% to 70% of maximum.

Special notes on various models:
FT-1000 (D, MP, MkV)
The FT-1000 supports FSK and AFSK. Recommended use is FSK. Don't use the
E-DSP on receiver, it can only limit and distort the digital signal. Use of
narrow filters (250 Hz to 00 Hz) is a must. Use high or low tones as
desired, make the appropiate adjustments in the menu. Make sure that RTTY
keying polarity is correct if using FSK (see menu). Shift is 170 Hz, not 200
Hz (see menu).

FT-9xx:
[TBD]

IC-756Pro/Pro2:
Supports FSK and AFSK, FSK recommended. Supplies power to TNC on same jack.
Adjust for hi or low tones in menu when using FSK. Hi tones has the benefit
that the built-in RTTY decoder can be used concurrently with the PC. Program
suitable DSP filters of 250, 350 and 500 Hz before operation in RTTY mode.
Since each mode has an own filter set, this does not affect SSB or CW
operation.
The band scope is very handy to see where the pile-up is, shows problematic
areas (automated stns).

Other rigs:
[TBD]


1.3 SOFTWARE
Probably the most popular soundcard program is MMTTY by JE3HHT. Others are
Zakanaka by Bob, Call?, or W MIXW by UA???call. [TBD: complete]
Probably the most important aspect to a dxpedition is the integretion with a
logging program and the ease of use, to allow for rapid handling of many
qsos per hour.
Here MMTTY has a benefit. MMTTY consists of two parts - the "engine" and the
user interface. Since Mako, the author of MMTTY made the interface of the
engine public to other programmers, they could include the MMTTY engine in
their program. Examples are Writelog, RckRTTY and more (TBD: more logging
software with MMTTY). Zakanaka interfaces with "LOgger" in a similiar way.

(TBD: slightly more detailed discussion of various software programs, pros
and cons, integration into logging software.)


================================================
2. FREQUENCIES
Depending on the rarity of your dxpedition, the classical bands (20, 15,
maybe 10) are most important. Nevertheless, more and more RTTY happens also
on the WARC bands. Please note that some countries have special band
segments for digital modes (e.g. Japan on 40m). (TBD: does this apply?)
80m and 40m are heavily used during RTTY contests, less so under normal
conditions. The usual problems of operation on low bands apply (noise,
antennas etc.).
160m is rarely used with RTTY.

General note:
Although a dxpedition is the most important event to you and many dxers
around the world, some people are not interested in it. Yes, indeed. In CW
and SSB that is easily recognized by the width of the respective band
segments. Not so in RTTY: due to the small digital segments not used by
automated stations (mailboxes), a major dxpedition can easily take up the
full band segment, making other, non-dx contacts impossible. Perhaps its a
good idea to leave 1 or 2 kc on the lower edge of the segment free.

Automated stations:
All digital segments are full (some say infested with) of automated stations
(mailboxes, forwarding etc.), at least on 20 and 15m. Since these are in
your listening window, they will make your life harder. Try to avoid these
segments.

Split operation and listening window size
It should go without discussion that split operation is mandantory. As usual
most dx-operations do split up. Due to the limited size of the RTTY segment
on 20m a listening window of up to 10 kHz seems to be most practical. 15m is
better but collides with segments for automated stations, see below.
If you mention the listening window (range, e.g. up 1 to 9) in your exchange
is your decision. But if you do - please stick to it, people will use it.
As in CW and SSB, RTTY dxers seeking you are listening in on the station you
are currently working and will call you on the same spot. That's ok, but
after a while you will have a solid wall of pile up and decode nothing - if
you don't move. So move your receiving frequency after each two three
contacts, make full use of the intended listening window range.

All following segments are IARU recommendations as of (TDB: date)
20m
IARU recommended digital segment: 14xxx to 14xxx (TBD)
20m real world usage:
14065 to 14070: automated stations (Pactor)
14070 to 14073: PSK31
14073 to 14079: automated stations (Pactor)
14080 to 14080: MFSK16 center of activity
14080 to 14090: RTTY
14091 to 14099: automated stations (Pactor)
14100: NCDxF beacons
14101 to 1411?: automated stations (HF Packet)

Recommendation:
Transmit on 14082, listen from 14083 to at least 14089, maybe up to 14098.
Although this includes partially a segment where mailboxes are, you can make
contacts since these are not active at all times.

15m:
IARU recommended digital segment: 21xxx to 21xxx (TBD)
15m real world usage:
21065 to 21070: automated stations (Pactor)
21070 to 21073: PSK31
21074 to 21079: automated stations (Pactor)
21080 to 21080: MFSK16 center of activity
21080 to 21090: RTTY
21091 to 21xxx: automated stations (HF packet) [TBD]

Recommendation:
Transmit on 21082, listen from 21083 to 21099.

10m:
[TBD]

80m:
Varies depending on ITU zones 1,2,3.
ITU Zone 1 (Eu, Af): 35xx to 3599
ITU Zone 2         : [TBD]
ITU Zone 3         : [TBD]

Recommendation:
[TBD]

40m:
Varies depending on ITU zones 1,2,3.
ITU Zone 1 (Eu, Af): 7035 to 7045
ITU Zone 2         : [TBD]
ITU Zone 3         : [TBD]

[TBD]



2.2 WARC bands
IARU recommended digital segments: [TBD]


================================================
3. RTTY operation
Basically RTTY operation is not too different from CW or SSB. The problem is
with QSB, that the listener can't really make out whether you sent him a
report or not. Ok, that applies to other modes as well, but probably is more
of a problem in RTTY.
The key to efficient RTTY operation on a dxpedition are the buffers, the
contents of the exchange. With the right buffers working RTTY becomes a
matter of a few (best case: 2) mouse clicks per qso. Since you have one hand
free most of the time, eating or having a cool beer in the other hand
becomes possible. Another strong reason to do RTTY on a dxpedition :-)

Important:
Do yourself a favor - use an external mouse, not the mouse pad or knob
integrated into the notebook. These may be ok for occasional use, for hectic
dxing they are worthless. Don't forget a mouse pad, even if you use an
optical mouse.

You probably never need more than 4 buffers:
- CQ
- report exchange
- QSL & QRZ
- QSL route info

Optional:
- QRZ with callsign fragment
- wrkd b4, no dupes pse
- QRX x minutes
- QRT, QSY etc.
- multiple CQ buffers for different bands with different listening windows.

All above mentioned software offers placeholders or variables which can be
used in the buffers. Since the notation of these variables vary from program
to program, we use the generic variable <hiscall> for the call of the
station calling you, <CR> is carriage return. DX1DX is the dx-peditions
callsign in the examples.

Important:
Start each buffer with a space and a carriage return <CR>. This helps the
receiving station to synchronize on your signal. Do this at least for the
report and qsl&qrz buffer.

Buffer 1 - CQ:
<SPACE><CR>CQ CQ de dx1dx dx1dx up<CR>
or
<SPACE><CR>CQ CQ de dx1dx up 1 to 5<CR>

Buffer 2 - report:
<SPACE><CR><hiscall> ur 599 599 qsl? <hiscall><CR>
or shorter
<SPACE><CR><hiscall> 599 599 <hiscall> bk<CR>

It is important to send <hiscall> twice, at the start and end of your
transmission. With this scheme, a calling station can identify his call even
if his transmission overlapped with yours or if QSB hit at one or other end
of your transmission.

Buffer 3 - QSL & QRZ:
<SPACE><CR><hiscall> QSL TU QRZ de DX1DX up<CR>
or
<SPACE><CR><hiscall> QSL 73 qrz de DX1DX up 1 to 9<CR>

Since you waited with your transmission until you have received the report
of the caller, an overlap occurs rarely, it is sufficient to send the
callers callsign only once at the beginning. Hopefully he sees it. Repeating
the callers callsign more often seems unescessary [TBD: other opinions?]

Buffer 4 - QSL route and other info:
<SPACE><CR>QSL via XX1XX XX1XX, iota XX-000<CR>now qrz de DX1DX up<CR>
or what ever you think nescessary for the world to learn about your
dxpedition.
Send every ten minutes or so.


Other optional buffers
[TBD]



How often should the report be sent if no reply is heard?
Twice.
Well, how often do you give them a chance in CW or SSB? No repetition at all
seems unfair and produces only additonal traffic. One repetition is probably
sufficient, two is gracious. Everyting above two repetitions is too much,
the caller should get his act together and buy a receiver.

What to do when even after two repetitions no reply is heard?
Just use your buffer #1, CQ. Don't just pick another call and send a report
to him. This confuses the callers, they don't know if the previous qso has
ended or was terminated. A CQ call is a clear message to everyone. Maybe use
an extra short CQ buffer for this purpose:
<SPACE><CR>nil hrd - CQ de DX1DX up<CR>

Just two mouse clicks for a complete QSO? How?
Provided you have a suitable software, configured for optimum.
Say you have been calling CQ, callers plenty. Select a frequency, find a
call on the screen, wait until the end of his transmission - <Click #1> on
callsign (ok, double click in most cases). This sends out the report buffer.
You receive a correct reply from the station you sent the report to. Click
<#2> on buffer QSL&QRZ, this stores and logs the callsign and sends out the
QRZ call. Next one...

================================================
4. Miscellaneous
4.1 How about other digital modes?
Although the lovers of other digi modes will be upset - forget it.
- PSK31: Besides RTTY, PSK31 is the most widely used digital mode,
disregarding automated stations which use Pactor. Until now no dx-pedition
has used PSK31, so you could be the first. [TBD: True?]
In other words: there is no practice in PSK31 for dxpeditions, no
established rules. Forget it.
- Pactor, Amtor: Forget it, impractical, too slow for a decent throughput.
- MFSK16: too few stations, not widely used.
- Clover: same
- Throb: same
- Hell: same
- SSTV: Though not strictly a digital mode, often mentioned. Nice but too
slow.


4.2 DX during an RTTY contest?
Happens frequently, maybe there are too many dx-peditions? (just joking). Or
too many RTTY contests? (No!). Well, we all have to live with it. Try to
avoid the crowded RTTY segments, specially on 15 and 10 go to the extreme
ends of the digital segment.


4.3 Is it worthwile at all? How many RTTYers are there?
Yes, it is. Besides being a comparatively relaxing way of dx-ing, there are
a lot of RTTY dxers and growing. A discussion in April 2002 for the VK9ML
dxpedition brought the rough concensus that there are about 5.000 to 7.000
active RTTYers worldwide, probably more. With a rate of 3 per minute (vy
good!) you work 180 per hour, 1.000 in 6 hrs (roughly). Realistically - if
you provide about two hours per day per major region (NA, EU, Pac) you can
work a lot of the RTTY community. If you can provide more time to RTTY, the
better.
================================================