In 1985, I built a home-brew decoder and experimented with RTTY, but I never got it to work. I've since decided that I didn't know how to tune RTTY properly. Things changed in 2005 when I downloaded CocoaModem made my first RTTY contacts.
Since I was involved in contesting, I naturally turned to RTTY contesting. Today, it is unusual to hear RTTY signals on the bands except during contests. Thirty or more years ago, RTTY was commonly heard on 80 and 20m.
Characteristics
Several characteristics of RTTY must be understood in order to communicate effectively:
- RTTY has no error correction or detection -- unlike AMTOR, Packet, FT4 or FT8. This means whatever that prints might be wrong. And if it is wrong, you will not know.
- RTTY prints garbage. Without a signal, random characters print. This further complicates determining what is correct and what is not.
- RTTY does not handle multiple signals well. When two or more stations call at the same time, RTTY will not print reliably. Certain decoders may print the strongest signal, if you are lucky.
- RTTY text comes in a continuous stream. Long lines wrap to the next, or one can force a new line by sending a carriage return / line feed combination. Wrapped lines are often difficult to read.
- RTTY has two shift states, LETTERS and FIGURES in the Baudot encoding. RTTY rests in the LETTERS state. An unprinted FIGURES character is transmitted to shift to the FIGURES state. A similar LETTERS unprinted character can be sent to shift back, or one can automatically unshift on a space character.
Principles
For effective RTTY contest communication, several principles apply.
- Brevity - every character sent must have a purpose. There should be no wasted characters.
- Duplication - every important element should be sent twice. This contradicts the brevity principle. Because RTTY prints incorrect characters, sending important elements twice helps ensure correct reception.
- Scrolling - each message starts a new line, but ends with a space. This technique keeps lines from wrapping, and avoids the end of message being confused by garbage characters when the signal drops.
- Shifts - avoid needless shifts. Any sequence involving the unprinted FIGURES or LETTERS characters takes longer to send.
Messages
(I'm using N1MM messages for my examples. Other software may have different macro names and techniques, but the same principles apply)
Every message starts with a {TX} and ends with {RX}. This transitions the software to transmit and back to receive.
S & P
Let's say you want to answer someone's CQ. This means you need to send your call. For that, you'd use a macro like this:
{TX}{ENTERLF}{MYCALL} {MYCALL} {RX}
or
{TX}{ENTERLF}* * {RX}
(For N1MM, the asterisk and {MYCALL} macros are the same)
Notice the message starts with {TX}, performs a carriage return / line feed with {ENTERLF}, sends the call twice, ends with a space and then {RX} to go back to receive. Sending the call twice helps to ensure the recipient receives it correctly.
If you are lucky enough to get a response, you'll have to send the exchange. The exchange will vary by contest, but it could be a message like this:
{TX}{ENTERLF}! 599 GA GA DE {MYCALL} {RX}
This is what I send in the RTTY Roundup. First is the recipient's call (!). Then 599 -- don't use 5NN, because that actually takes longer to send in RTTY -- and send it only once, because it isn't important. Then the exchange is sent twice, followed by the prosign DE and my call, followed by a space.
N1MM's authors recommend you use the ! character rather than the {CALL} macro. The reason is that {CALL} isn't subject to correction -- it sends the contents of the Call field at the start of the message. The ! character will send the Call field as it is being corrected in real time. As a practical matter, most RTTY contest contacts involve pointing and clicking on callsigns, so there's less typing, and therefore fewer corrections involved.
A couple of things here. Notice I did not use the {EXCH} macro above. When there are multiple elements to the exchange, I put the repetitions together. So, I tend put the exchange information into the macro directly. For example, here's an S & P exchange for CQWW RTTY:
{TX}{ENTERLF}! 599 GA GA 5 5 DE {MYCALL} {RX}
GA for Georgia, and 5 for zone 5. For NAQP RTTY, it would be:
{TX}{ENTERLF}! 599 BILL BILL GA GA DE {MYCALL} {RX}
Some might balk at the use of the DE prosign, particularly for exchanges that involve a state or section, since DE might be confused with Delaware. However, I think this prosign is useful, as it establishes the callsign is of the answering station, and not the CQing station.
CQing
Calling CQ in a contest is the most-used message:
{TX}{ENTERLF}CQ RU {MYCALL} {MYCALL} CQ {RX}
Note that the important information -- the callsign -- is repeated. The other curious thing is the "CQ" at the end. This indicates I finished a CQ message. This is important because one cannot tell when potential callers tune in to your signal. If they do so during the first callsign, the can't tell if you are calling or answering a CQ. Putting "CQ" at the end establishes you are calling CQ. And it is shorter than "QRZ?".
Naturally, one indicates the contest in the CQ message. Here it is "RU" for Round Up. Use whatever is appropriate for the contest, or simply "TEST".
When someone answers your call, you send an exchange message:
{TX}{ENTERLF}! 599 GA GA ! {RX}
Note that the exchange is sent twice, and if there were more than one element to the exchange, I'd send those twice as well:
{TX}{ENTERLF}! 599 BILL BILL GA GA ! {RX}
Another item to notice is there is no {MYCALL} macro in this message. Instead, the caller's callsign (!) is sent twice, once at the beginning and once at the end. There are two reasons for this. First, it follows the principle of sending important information twice. It could be the caller's callsign printed incorrectly to me, or perhaps it will print incorrectly when I send the message back. If I only send the callsign once, the caller might or might not correct it if is wrong, or they may correct it if it printed incorrectly to them.
Unnecessary corrections are a waste of time, but necessary corrections are desired.
Second, it may be that during the response with the exchange, other stations may also be calling. This, creates a good chance that the initial callsign in the response will print incorrectly. If you don't send the callsign again at the end, it could be unclear who you responded to.
Once you've received the exchange from the caller, one sends an acknowledgement:
{TX}{ENTERLF}! TU DE {MYCALL} CQ {RX}
Short and simple. Two features here. One is the DE prosign, to indicate this is the transmitting station's call, and ending with "CQ" to invite new callers.
Turnaround
Occasionally, multiple callsigns will print in response to a CQ. You can only respond to one at time. Since you can only respond to one at a time, this leaves someone waiting. Rather than have them call again, you can use a turnaround message which acknowledges a completed contact and starts a new one:
{TX}{ENTERLF}! TU {LOGTHENGRAB}NOW..{ENTERLF}{F5} 599 GA GA {F5} {RX}
This message omits {MYCALL}, and uses the {LOGTHENGRAB} macro to first log, then grab the callsign off the automatic decode stack, then it follows with the normal exchange. If you use Single Operator Call Stacking, you can use {LOGTHENPOP} instead. See the N1MM manual.
Note that instead of using the exclamation point (!), we use the {F5} macro. Both the exclamation point and the {CALL} macro won't be updated by the {LOGTHENGRAB} macro, but {F5} will.
Short
When signals are strong, and the bands are quiet, perhaps the principle of sending information twice doesn't apply. Most RTTY contests allows contacts on multiple bands, and the exchange doesn't change. In these cases, you may want to have short messages handy. Here are some examples:
{TX}{ENTERLF}! 599 BILL GA DE {MYCALL} {RX} -- short S & P exchange
{TX}{ENTERLF}! 599 BILL GA {RX} -- short exchange for S & P or CQing
{TX}{ENTERLF}599 BILL BILL GA GA {RX} -- repeat of just the exchange
{TX}{ENTERLF}CQ RU {MYCALL} CQ {RX} -- short CQ
{TX}{ENTERLF}TU DE {MYCALL} CQ {RX} -- short acknowledgement
All these should be used when you have solid copy, want to get back to other callers quickly, or you are fairly certain the other operator already has your exchange information from a previous contact.
Tips
Some tips I've picked up over the last decade that are helpful.
- Use Slow AGC - Fast AGC can confuse decoders and introduce print errors
- Use TX Filtering on AFSK - If you are using MMTTY or similar software, use the 512 tap TX Filter. It helps transmit a cleaner signal.
- Listen with Headphones - sometimes you can hear signals that don't always print, if you listen with headphones, you can hear the stations calling you. It also helps you improve your timing in a pile.
On that last tip, turn the volume on the headphones way down. You just have to sense when signals are there, you aren't decoding them. (I believe it was the late Irv Hoff, W6FFC (SK) -- a RTTY pioneer -- who suffered hearing loss at 2125 and 2295 Hz from listening to RTTY signals)
Practical Messages
There are a handful of other messages you may wish to have handy. Here's one I use often, when you didn't copy anything sent:
{TX}{ENTERLF}AGN AGN {RX}
Or perhaps you need a fill of one element:
{TX}{ENTERLF}STATE? STATE? {RX}
{TX}{ENTERLF}NR? NR? {RX}
{TX}{ENTERLF}NAME? NAME? {RX}
Before you open up with a CQ on a frequency, this is good one:
{TX}{ENTERLF}QRL? DE {MYCALL} {RX}
Maybe if you are not sure someone is calling you:
{TX}{ENTERLF}QRZ DE {MYCALL} {MYCALL} {RX}
Or the short version:
{TX}{ENTERLF}QRZ DE {MYCALL} {RX}
Every once and a while, directed call is useful, especially when two stations are calling CQ on top of each other:
{TX}{ENTERLF}! DE {MYCALL} {MYCALL} {RX}
Conclusion
RTTY contests are a ton of fun. Program a set of messages and try it. You'll like it.
Login
Although quantum processors exist today, they are still a long way off from becoming practical... 
Some old computer languages are destined to never die. They do, however, evolve. For example,... 
I try not to go off on security rants in the newsletter, but this week... 
