General RTTY and PSK Information

RTTY Information

General RTTY info

• Audio processing is off
  • Speech processing is off
  • Hi boost is off (Kenwood radios)
• Radio should be in LSB mode
• The most used 'Speed' is 45 Baud (60 words/min)
• The 'standard' shift is 170 Hz
• When using a TNC set 'Mark' to 2125 Hz and the 'Space' to 2295 Hz
• Don't overrun your finals from the transceiver and/or amplifier
  • 50 percent duty cycle is mostly ok
  • See the Interfacing section of this help for url's and tips on interfacing.
• The BAUDOT character-set does not have all ASCII characters so some special characters such as (~ * _ @ # =)? can not be printed/transmitted.
• Almost always only the small filters in the radio are being used (250 - 500 Hz)

Common RTTY Frequencies

General RTTY info

By Rich, VE3IAY

The 5-bit Baudot code only has enough different characters for 26 letters plus 6 control codes, so to get numbers and punctuation the text has to be preceded with a special "FIGS" character (one of the 6 control codes) to get a second set of 26 characters (10 numbers plus 16 punctuation marks). FIGS is "sticky", so there is another special "LTRS" character to switch back to the letters case.

Just like any other character, these FIGS and LTRS characters can be damaged by noise, QRM, QSB, etc., and if they are, the received info is displayed wrongly until the next LTRS or FIGS character (or the next space, if you are both using UnShift On Space = USOS) comes along and sets things right. Sometimes the opposite happens - a real character is converted by noise into a FIGS or LTRS code, with similar results.

The most common problem that results is numbers being printed as letters, so for example, pretty soon RTTY operators will get used to interpreting "TOO" as "599" and "UE" as "73". Serial numbers are slightly more difficult; "PQW" in the input data is most likely "012", and so on. Letters can also be printed as numbers; for example, "CQ TEST" when converted to FIGS case becomes ":1 53'5".

Various software has different ways of helping out with this. Each way has its own pluses and minuses. In MMTTY run stand-alone, if you right click on a "word", the entire word changes to the opposite case. So, for example, my call sign is converted to ;3E8-6 , and yours would come out as ;-E0) . Some programs have a separate (usually one-line) window in which all incoming text is displayed in the opposite case. N1MM's digital window has an option (available by right-clicking in the DI window) which reserves one line for opposite-case display, but instead of using it to display incoming text as it comes in, it shows text that the mouse "hovers" over (no click necessary) in the opposite case. This requires you to move the mouse over the offending text, but it doesn't get lost whenever there is a line feed in the incoming data.

If everyone is using USOS (unshift on space), as they should, then most of these errors only last for one "word" (up until the next space), and you can probably get by without any LTRS/FIGS assistance from your software. However, some people refuse to use USOS, and some subvert it by refusing to put spaces in their messages, probably from a mistaken wish to make their messages as short and "efficient" as possible. Having the opposite-case display can be almost a necessity in such cases. These folks haven't yet realized that the goal is to maximize communications throughput, not to minimize the time spent transmitting, and they also haven't yet worked out that a single request for a repeat every few QSOs can cost them more time than they save. In anything less than perfect conditions, this is quite likely.

For example, some people send their exchange as 599-123-123. If you miss the FIGS character, this comes out as TOOAQWEAQWE. Not everyone can figure out the serial number from that, especially if you add in a few other errors so it comes out as TOOAPWEUQWA.

On the other hand, if the exchange is sent as 599 123 123 123 using USOS, a single error does no harm. Even at a fairly high error rate, you still have a reasonable chance of getting two identical serial numbers in the clear and not needing a repeat. Yes, 599-123-123 is much faster than 599 123 123 123 with USOS when conditions are perfect, but when signals are poor, the net throughput of the second version can be a lot higher.

Of course, the guy who doesn't put in any separator at all (599123 or TOOQWE) forces you to enter the entire exchange by hand even if there is no transmission error - maybe his software doesn't recognize serial numbers in the clear, but maybe yours does - does he have to penalize you too?

PSK Information

General PSK info

• Keep your macros short. 
• PSK is about 1/3 slower than RTTY; you can really impact your rates with wordy macros
• Use lower case letters wherever possible. 
• PSK is a varicode mode. That means that characters contain a variable number of bits, unlike ASCII characters that have a fixed number of bits. Most lower-case PSK characters have fewer bits in them than their upper-case equivalents, so lower-case (in general) transmits faster.

On the radio make sure:

• Audio processing is off
  • Speech processing is off
  • Hi boost is off (Kenwood radios)
• Radio should be in USB mode
  LSB is also possible but normally USB is used.
• Don't overrun your finals from the transceiver and/or amplifier
  • 50 percent duty cycle is mostly ok
  • See the Interfacing section of this help for url's and tips on interfacing.
• Using lower case letters instead of all caps, will increase speed and reduce TX time.
• Only 100 Hz is needed as channel separation.
• Example filter usage:
  • Available 2.4 kHz / 250 Hz /100 Hz filter bandwidths.
  • 2.4 kHz is used for monitoring the PSK area of band when in search and pounce mode.
  • 250 Hz and 100 Hz filter bandwidths are used when in run mode.