DX-Stations Guide to RTTY Operations

What is this?

Watching some DXpeditions early in 2002 working RTTY, and participating in the following discussions on the RTTY email reflector on contesting.com the idea was born to write up what experienced RTTY ops think on how to do RTTY during a dxpedition. This is the result.

This guide is work in progress, it is probably never finished and will change over time. If you think something is wrong, should be expressed better or have enhancements, please drop me a line at ep (at) plicht.de

Thanks to Phil (GU0SUP), Richard (VE3IAY), Don (K2XF) and many others, especially on the RTTY mail reflector at contesting.com.

© Copyright notice

This document is copyright © Ekki Plicht, DF4OR. You are free to use it whereever and however you want, as long as the document is not changed and includes this copyright notice.

DX-Stations Guide to RTTY Operations

Maintained by Ekki, DF4OR, mail: ep (at) 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. Apr 2002 - started guide
Rev. 0.1 dated 24. May 2002 - first web version, not published
Rev. 0.2 dated 20. Aug 2002 - second web version, published
Rev. 0.3 dated 09. Sep 2005 - third web version, published
Rev. 0.4 dated 22. Nov 2006 - cosmetic changes, fourth web version, published

Contents

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 (TU, PC, Soundcard)

TNC vs Soundcard (SC) comparision table, in no particular order

  TNC Soundcard
Does more than one mode Yes, maybe helpful in other situations (e.g. Pactor link to back home, WinLink network) RTTY mostly, rest depending on software. MixW does most, except ARQ modes
Requires extra power supply Yes, but you could probably draw power from the rig with just one cable for power and data. No
Redundancy Only if you take more than one (preferrably of the same model) Most likely in each notebook you have with you anyway
Required PC Performance 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.
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.
Special hint on MMTY: If you experience lockups, try adjusting the "Priority" setting in MMTTY. Set to "Highest",do not use "Critical". Adjust the souncard buffer size, lower values (512) can help.
Receive Performance
(decoding)
Up to date DSP TNCs decode RTTY very well. AF Filters no configurable AF filters are configurable, but a sound understanding of signal analysis is helpful. Some information hints that MMTTY (and probably other 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?)
Repairing If broken, forget it. Take two or more TNCs of same model with you. 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.
Ease of Use Depends on the software (RTTY program) which makes use of the TNC. Configuration of the TNC can be tedious. Take handbook with you. Depends on the software (RTTY program) which makes use of the soundcard driver (MMTTY or other). Most have meaningful default settings. If you decide to play with the filter configurations, a degree in Signal Analysis is helpful. Make sure the helpfile is installed.
Cost Mid to high
Hardware costs money.
Zero to Mid range.
Some programs are for free, others, which are more suitable for a contest or DX-pedition, do cost serious money. Consider asking the author for a donation for your DX-pedition.
Weight, Size Around 500 grams (excluding cables), size approx.: x by x by x centimeters [TBD] Weight: cables only, Size: none
Automated operations (mailbox, winlink) Yes, most No
Interfacing to Transceiver Requires AF in (or FSK), AF out, PTT. Does support FSK vs AFSK in most cases
Both solutions require very careful adjustment of AF levels, otherwise severe overmodulation and bad HF transmission can occur. This applies to AFSK ops, FSK is easier here.
Requires AF in (or FSK), AF out, PTT. Some SC solutions support FSK (MMTTY). PTT requires a minimal interface with one or two transistors, fits in the serial cable jack. Depending on which input you use on the rig, VOX operation may be possible. Some programs supply a method to key the rig via a control command to the rig (serial cable required then).
Both solutions require very careful adjustment of AF levels, otherwise severe overmodulation and bad HF transmission can occur. This applies only to AFSK ops, FSK is easier here.
     

Conclusion Hardware

From the above it seems that soundcard solutions wins hands down, at least from the point of view of a DXpedition. It's nearly free, wheighs nothing, easy to repair.
Downside: All soundcard software 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)

Other Hardware

(by Phil, GU0SUP)
I would like to suggest the possible use of an external audio filter. I use one in my shack primarily for contesting and for (trying) to work dxpeditions. The one I use has switched capacitor filters, and is essential if the band is crowded. It simply sits between the rig and the soundcard, and I can also monitor the filtered audio through a seperate speaker.
Seperate DSP filters are also available. I know many rigs have DSP built in, but for the type of people you are aiming this guide at, they may not know how to get the best out of a built-in DSP filter on RTTY.

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: (If you have anythingto contribute, let me know!

FT-1000 (D, MP, MkV)

The FT-1000 supports FSK and AFSK. Recommended use is FSK. Don't use (or only very carefully) the E-DSP on receiver, it can only limit and distort the digital signal. Use of narrow filters (250 Hz to 500 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-900:

Phil (GU0SUP) writes:
The FT900 does NOT have FSK. It isn't an ideal rig for RTTY (despite the fact that I use one!), but it is small and easily portable. Filtering isn't ideal either, but is adequate.

IC-756Pro/Pro2/Pro3:

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).

IC-706xxx

Supports AFSK and FSK, FSK recommended. Supplied power to TNC on same jack. Supports Hi- or Low-Tones (menu). Narrow filter (250Hz, 350Hz) optional and highly recommended.

Other rigs:

[TBD]

1.3 SOFTWARE

Probably the most popular soundcard program is MMTTY by Mako, JE3HHT. Others are listed below. Probably the most important aspect to a dxpedition is the integration 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.

Software List (always incomplete...)

(TBD: more detailed discussion of programs, esp. suitability for DX-peditions)

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, enough room left for people not working you.

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 8 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.

Bandplans

All following segments are IARU recommendations as of 1998. All frequencies in kHz.

20m

IARU recommended digital segment: 14070 to 14112

bp20-iaru.jpg - 22277 Bytes

20m real world usage:

bp20-real.jpg - 24354 Bytes
14065 to 14069: automated stations (Pactor)
14069 to 14073: PSK31
14073 to 14079: automated stations (Pactor)
14080     MFSK16 center of activity
14080 to 14090: RTTY
14091 to 14099: automated stations (Pactor)
14100     NCDxF beacons, do not transmit
14101 to 14112: automated stations (HF Packet)

During a major contest, RTTY activity goes from roughly 14075 up to about 14110.

Recommendation 20m:

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: 21080 to 21120

15m real world usage:

21065 to 21070: automated stations (Pactor)
21070 to 21073: PSK31
21074 to 21079: automated stations (Pactor)
21080     MFSK16 center of activity
21080 to 21090: RTTY
21091 to 21120: automated stations (HF packet)

During a major contest, RTTY activity goes from roughly 21075 up to about 21115.

Recommendation 15m:

Transmit on 21082, listen from 21083 to 21099.
Although this includes partially a segment where mailboxes are, you can make contacts since these are not active at all times.

10m:

IARU recommended digital segment: 28050 to 28150

10m real world usage:

28080 to 28090: RTTY
28080     MFSK16 center of activity
28120     PSK31 center of activity

During a major contest, RTTY activity goes from roughly 28070 up to about 28115. Few automated stations are also active on 10m, but more seldom than on 20m and 15m.

Recommendation 10m:

Transmit on 28082, listen from 28083 to 28100.

Other bands

On most other bands the assignments for digital modes vary with the ITU Region. Three regions are defined:

160m:

Varies depending on ITU Regions 1,2,3.

ITU Region Digital segment
1
1838 to 1840 Digimode (exc. Packet), CW
1840 to 1842 Digimode (exc. Packet), Phone, CW
2
1800 to 1830 CW, Digimode
1830 to 1840 CW, Digimode (CW DX window)
3
1830 to 1834 RTTY, CW Dx

Recommendation 160m:

[TBD]

80m:

Varies depending on ITU Regions 1,2,3.

ITU Region Digital segment
1
3580 to 3590 Digimode, CW
3590 to 3600 Digimode, Packet preferred, CW
3600 to 3620 Phone, Digimode, CW
2
3580 to 3620 Digimode, Phone permitted (NIB), CW
3620 to 3635 Digimode, Packet priority, Phone permitted (NIB), CW
3 No data on digital segments

Recommendation 80m:

[TBD]

40m:

Varies depending on ITU Regions 1,2,3.

ITU Region Digital segment
1
7035 to 7040 Digimode (exc. Packet), SSTV, CW
7040 to 7045 Digimode, (exc. Packet, SSTV), CW
2
7035 to 7040 Digimode with other regions, CW
7040 to 7050 Packet with other Regions, CW
7100 to 7120 Digimode, Phone, CW
3 No data on digital segments

Recommendation 40m:

[TBD]

2.2 WARC bands

30m:

Varies depending on ITU Regions 1,2,3.

ITU Region Digital segment
1
10140 to 10150 Digimode (exc. Packet), CW
2
10130 to 10140 Digimode, CW
10140 to 10150 Digimode, Packet preferred, CW
3 No data on digital segments

Recommendation 30m:

[TBD]

17m:

Varies depending on ITU Regions 1,2,3.

ITU Region Digital segment
1
18100 to 18109 Digimode, CW
2
18100 to 18105 Digimode, CW
18105 to 18109.5 Digimode, Packet preferred, CW
3 No data on digital segments

Recommendation 17m:

[TBD]

12m:

Varies depending on ITU Regions 1,2,3.

ITU Region Digital segment
1
24920 to 24929 Digimode, CW
2
24920 to 24925 Digimode, CW
24925 to 24929.5 Digimode, Packet preferred, CW
3 No data on digital segments

Recommendation 12m:

[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 four buffers

Optional

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]

Q: 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.

Q: 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 aborted. 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>

Q: 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?

Assuming you are interested in high QSO rates also in digital modes, RTTY seems to be the most practical mode. RTTY Dxers are used to DX-op style working. Although other (HF) digital modes have been done from DX-peditions, most seem to be too slow or unpractical.

PSK31

PSK31 is nowadays the most popular digi mode. There have been Dx-Peditions working in PSK, and there is certainly some interest in that. On the other hand, some DXpeditions reported that PSK31 is just too slow, an exchange takes somewhat longer than in RTTY. Furthermore the culture for DXing doesn't seem to be as widespread as in RTTY, people tend to chat. For which (chatting) PSK31 is ideal...

Phil (GU0SUP) writes:
However, it is worth remembering that PSK will often work when RTTY will not. It is also now heavily used by the QRP brigade, this bringing more ops into the digital world. We are now entering the decline of conditions, so it may be worth considering PSK. Many dxpeditions HAVE used PSK successfully :- D68C was probably the first to make the most use of PSK, but others have used this mode.
SSTV is also quite popular, as per PW0T recently, but as you say, it is a slow mode. However, if it is a major dxpedition, then it may be worthwhile at the end of the trip.

Richard, VE1IAY writes:
I think you're writing PSK31 off a bit prematurely. (Ekkis comment: I had much more unfriendly wording here on PSK31 in the first version :-). When I look at NG3K's web site of announced DX operations, I see quite a few that announce they are going to do PSK in addition to other modes (the earliest one I found was in June 1999, back when PSK31 was still new).
As a personal example, I have PSK31 QSOs verified with D68C on three bands, RTTY on only two. ZK1NDS is another one - from him I have PSK31 from N. Cook (my only QSO ever in any mode with ZK1/N), and RTTY from S. Cook (only semi-rare, at least in my log). I also have several PSK31 QSLs from visitors to not-so-rare places like ZD8, PJ5, TI, TG, EA6, HB0, P4 - not exactly rare DX, but people going there on "casual" DXpeditions might like to read your guide too. According to my log, there are also resident hams operating PSK31 from places like C31, ZD7, V51, TF, OY, FR, PZ - these guys might also like to benefit from your advice. Besides, most SC RTTY programs (except for MMTTY) will also do PSK31, so it costs nothing to include both modes in your repertoire. I think your advice for RTTY carries over to PSK31 pretty directly, although there might be some special techniques for split operation in this mode.

Pactor, Amtor

It seems as if ARQ modes have been relegated to automated operations (Mailboxes), for which they are certainly very suited. Keyboard to Keyboard QSO rarely happen, so using it as an DX-pedition mode seems like a waste of time.

MFSK16

(TBD) No information at hand. Anybody volunteering?

Clover

(TBD) No information at hand. Anybody volunteering?

Throb

(TBD) No information at hand. Anybody volunteering?

Hell

(TBD) No information at hand. Anybody volunteering?

SSTV

Although not strictly a digital mode, often mentioned together. Seems attractive if you have a digital camera and can send pictures from your DX-pedition on the spot. But high rates are unachievable with tx times of 60 seconds per picture minimum.
If you decide to do SSTV, stick to the recommended band segments and negotiate contacts in SSB before and after the actual SSTV transmission. That's at least what the SSTV people told me on the reflector.

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.

Phil (GU0SUP) writes:
This is probably the BEST time for a dxpedition to run RTTY, as there is no need to operate split, and a high QSO rate can be achieved. It also gives you a solid 24 hours or 48 hours of RTTY, thus making the most of the time on that mode.

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.