HamRadio Tech

RTTY

RTTY or RadioTeletype is a direct machine to machine communications mode using the Baudot (or Murray) code. This mode became popular with many amateurs when surplus TTY machines became available at a reasonable cost after World War II. These mechanical monsters provided a keyboard for Input and a paper roll for printed Output. They were also useful to help hold the house down in times of hurricane winds - they must weigh a ton. Video displays were still too exotic and expensive in those days. It was not until the mid 1970s that we began to see the Video Display come into more widespread use. (By the way, have you ever wondered why early Program Languages like BASIC use the command PRINT to display their output?) When transmitting Morse Code, the transmitter is switched on and off to make the dits and dahs. When sending Teletype however the transmitter runs continuously, sending either of two frequencies conventionally known as Mark and Space (a reference to paper tape reception of telegraphy). The early pioneers found on-off keying was not all that successful for Teletype signals because of interference from static. They experimented with FSK, or Frequency Shift Keying and found it performed much better. With FSK, the transmitter is shifted up in frequency every time a Mark is to be sent, reverting to the lower frequency for a Space. The amount of the shift is usually 170 Hz for Amateur Radio use although many commercial Teletype signals use other shifts, notably 425 Hz and 850 Hz. Many systems use AFSK or Audio Frequency Shift Keying. When this is sent, the transmitting station generates the Mark and Space audio tones and feeds them into the transmitter's microphone input. The result at the receiving end is that the same audio tones are heard and processed, whether the transmitting station used FSK or AFSK. When listening to a teletype signal off air, you will soon get to recognise the familiar warble of Mark and Space tones. In the modern amateur shack the TTY machine is usually a Multi-mode controller or PC interface cable connected to an HF transceiver which the operator tunes so that the received audio is just the right pitch or audio frequency to trigger the demodulator's Mark and Space responce. If the transceiver is slightly off the correct frequency the tones vary and the text becomes garbled or even lost altogether. To help the other station tune the receiver correctly, a RTTY operator can send a string of alternate R and Y characters RYRYRYRYRY. This pattern is chosen as it produces the most frequent and almost symmetrical alternation of Mark and Space tones, giving the receiving operator the best chance to tune the receiver before the "real" message starts. However, even if the signal is accurately tuned, the information can become garbled or completely lost due to interference, fading, or noise. Often, it is possible to make sense of the message even with parts missing, but RTTY is by NO means an error free mode! The new DSP based programs such as MMTTY, are able to decode RTTY signals with much greater sensitivity than the older analog systems. The Baudot code is a 5 bit code and those of you who are familiar with Binary Notation will know that the maximum number of values we can have with 5 bits is 32. That means that each unit of transmission, one keystroke if you like, can contain any one of 32 possible values. If you look up a table of Baudot codes you will see there are 32 values listed, one code for each letter of the alphabet plus a few other codes for other things such as a space and a Carriage Return. But, what if we want to send a number such as "9" or a question mark? These are not mentioned in that table because all 32 codes are already used. The solution is rather similar to the Typewriter or Computer Keyboard where we have the Shift key to get various additional codes from the keyboard. Most keys will produce a different result if we hold down the Shift key as we type. Well, one of those original 32 codes is a special code known as FIGS (for Figures Shift). The convention is that when we want to send a number or some other special character such as a punctuation mark, we can do that by firstly transmitting a FIGS code. Then instead of using that original table of 32 codes, we have a second table of codes to use, and that second table includes all ten numeric digits and various punctuation marks. Provided both sides of the conversation observe the convention, the sender can send a FIGS and start using the second table; the receiver will see the FIGS code and it too will interpret all data that follows from the second table. With just 5 bits of data we then have almost 64 different codes we can send and receive. (I say almost because there is some duplication in the two tables, including a space and a Carriage Return but that is not important here). Even that many codes is not enough to handle all 26 letters of the alphabet in both UPPER and lower case, so RTTY systems always operate in upper case only. If we wanted to type a big number (say "13579") we don't have to send FIGS before every digit. We send that code only once and the receiver then will take EVERYTHING we type from now as if it belongs in the second table. When we want to revert to the normal alphabetic table of codes we can send another special code, this one called LTRS (for Letters Shift). Then everything goes back to normal, using the original alphabetic table of codes. Normally we don't have to concern ourselves with these FIGS and LTRS codes. Our computing equipment will take care of those things for us. We just type away and rely on the system to generate and send those codes when necessary. It is quite possible to lose bits here and there when receiving a RTTY signal, whether it be because of fading, interference, frequency drift, or whatever. One of the big problems with lost data is the possible loss of a FIGS or LTRS code! Say we had sent "13579" and then typed "HAPPY BIRTHDAY". Our equipment would have sent a LTRS code before the first "H" but what if the receiver did not copy the LTRS code we sent? Can you imagine what happens? As far as the receiver is concerned we are still sending numbers or other codes from the numeric table! So our "HAPPY BIRTHDAY" is going to come out looking something like "#-006 ?845#$-6". And EVERYTHING we type from then on is going to look just as strange until we happen to send another LTRS code later. It is for this reason that many systems include an option to "Un-shift on space". If you have a multi mode TNC capable of handling RTTY, you will probably have this option in your TNC. If that option is ON then your receiving system will imply a LTRS code every time it receives a space. So if you seem to be copying lots of funny numbers from a strong, well tuned signal, try setting that option ON. We can overcome some of these problems by using ASCII instead of using the Baudot code. With ASCII we can have 128 different codes so we do not need the FIGS/LTRS codes. All Personal Computers use ASCII as their native "language" so it would be a reasonable thing to use. Although not part of the defined ASCII standard, it has become an almost de-facto standard in the computer world that an additional 128 characters are available, often called Extended ASCII. But, despite these benefits, Baudot continues to rule the airwaves for Amateur and Commercial Teletype transmissions. Today, RTTY is still a popular mode especially on the HF bands, and the advent of the "Glass Terminal", firstly the Dumb Terminal and now the Personal Computer, has brought this mode to even more operators the world over. Many specialised RTTY systems were developed for the Amateur enthusiasts but have been superseded now by the Personal Computer with one of the Multi Mode TNCs or sound card DSP programs which handle RTTY and many other modes besides. The latest Computerised RTTY equipment generally allows us to use the mode better, quieter, more efficiently, using less power and occupying less space than the old TTY machines, but the limitations of the mode remain.

---

Any contribution to Digital Modes technology are welcome! Just write us and feel free to send us your articles for this Technical Area inside DMC Web Site!