RTTY decoding using a PDP-11

How this project started
It all started with questions on the list about the DPV11 (which is a synchronous serial interface) and for what that interface could be used. "Not much" was the answer, but one interesting application was the processing of packet radio signals.
Packet radio is developed and used by HAM radio amateurs and is based on the X.25 standard. However, writing the code of a TNC (Terminal Node Controller) for the PDP-11 is not a trivial task. Also needed is a modem that converts the audio tones into a digital stream of data bits. HAM radio amateurs use 300 Bd signal speed on short wave (HF), but on VHF (starting from 144 MHz) the signal speed is 1200 Bd or higher. I am not sure that the PDP-11 TNC implementation could keep up at 1200 Bd.
So much for packet radio.
There is an other interesting text communication mode used by HAM radio amateurs. It is called RTTY, which stands for Radio over TeleTYpe. RTTY is pronounced as "rit-ti-ti". RTTY is a signal that consists of two tones, one represents a logic "0", the other a logic "1". The signal speed is 45.45 Bd, but since every character has a startbit my guess is that the SLU (Serial Line Unit, asynchronous serial interface) set at 50 Bd will do fine.
The output on the screen of RTTY signals is character-based, no fancy graphics here!

What you need to receive RTTY signals
On modern PC's, amateurs use the sound card as demodulator and interface. The processing speed of a modern PC is fast enough to do some signal processing with a sound card. Just "google" with the terms "soundcard" and "hamradio"!
Using a PDP-11 means we do not have a sound card, so the conversion from audio into digital data bits must be done in electronics. This is the part that you either buy (new in a shop or check out for example eBay!) or make it yourself.
To receive RTTY signals you need the following stuff.

Receiver (obviously)
- On the HF bands the receiver must have a "BFO" (Beat Frequency Oscillator) to tune in to the signals.
  Common short wave receivers only receive AM signals, which makes it difficult (but not impossible) to tune to HAM radio RTTY signals. If the receiver has a selectable bandwidth, set it to 3 kHz or lower. Receivers with no selectable bandwidth settings are 9 kHz (Europe) or 10 kHz (USA) wide. In that case you may need some filtering in the audio signal. See the audio interface description.
- On the VHF bands the modulation most used is FM. Here the tones are always correct, so no fine tuning on the transmission signal is needed.
Demodulator
You must convert the audio tones into binary. The most common way to do this uses two separate bandfilter circuits.
Each bandfilter is designed for one tone. Frequencies outside the band only produces a small signal at the output of the filter. Tones that lie inside the bandfilter generate a large output signal. The output signals of both bandfilter go to a comparator with a threshold. The output of the comparator is the digital bitstream.
(RS-232) interface
The output signal from the demodulator must adhere to the standard signal specification of the serial interface in the PDP-11 that you plan to use.

What you need to decode RTTY signals
Only the software, and of course a PDP-11 with an available asynchronous serial port.

Backgrounder on RTTY modulation signals
As in all fields, standardisation is not always there from the start. Same goes for the used frequencies for the tones.
RTTY started with the use of a Teletype (hey, what's in a name?). Teletypes use current loop as connection, where the steady state (when current flows) is called the "space" signal. When the current is interrupted the signal is called "mark".
On VHF amateurs use as mark frequency a tone of 2975 Hz. The space tone has a defined shift from the mark frequency of 850 Hz, the space frequency is 2125 Hz. However, 2975 Hz is a rather high frequency if you transmit on HF bands, where the bandwidth of the signal is just 3 kHz. So, on the HF bands the mark frequency is 2295 Hz, and the shift is 170 Hz. That means that the space frequency is still 2125 Hz.
Now for standardisation ... the above described frequencies are nowadays called "old tones".
You guessed: there is also a scheme called "new tones".
The shifts used are still 170 Hz and 850 Hz, but the mark (and thus space) frequency are lowered. Again, the space frequency is always the same, which is 1275 Hz. That makes the mark frequency either 1445 Hz (170 Hz shift) or 2125 Hz (850 Hz shift). Press agencies (Reuter, etc.) transmitted on short wave using RTTY to send articles. They used a shift of 425 Hz. However, my guess is that you will not receive much of these signals anymore.
Finally, sometimes HAM amateurs get the polarity wrong, so "mark" becomes "space", and "space" becomes "mark". But more common is that the signal is transmitted on the Lower Side Band, and you are receiving on the Upper Side Band. This is easily handled either in the demodulator (simple switch of the bandwidth filter output) or in software (invert the received data bits).

Some more information about the code used
The code used with RTTY signal is the standardised CCITT Alphabet No.2 (ITA-2) character table, also known as Baudot code. Baudot code is a 5 bit code. That means that there are at maximum 32 bit combinations to form characters. Not enough for just the alphabet and the numbers, forget interpunction characters and lowercase or uppercase!
To get rid of this limitation a few bit combinations are reserved and some have a special meaning. One of those is called "Figures", an other is called "Letters". These are abbreviated on a Teletype keyboard as "FIGS" and "LTRS".
From these two keys you can recognize if your Teletype generates 5-bit Baudot code or 7-bit ASCII code.
When you pressed the LTRS key ("letter shift"), all following keys that you press generate (uppercase) letters (A-Z). After you press *one time* the FIGS key ("figures shift"), all following keys that you press generate numbers and some interpunction characters. To generate any letter you must first hit the LTRS key.

Here is the complete code table. Remark: the lsb (least significant bit) is transmitted first.


 bitcode  LTRS   FIGS     hex    oct          bitcode  LTRS   FIGS     hex    oct
 ------------------------------------         ------------------------------------
 00011     A      -        03     03          10111     Q      1        17     27
 11001     B      ?        19     31          01010     R      4        0A     12
 01110     C      :        0E     16          00101     S      BELL     05     05
 01001     D      $        09     11          10000     T      5        10     20
 00001     E      3        01     01          00111     U      7        07     07
 01101     F      !        0D     15          11110     V      ;        1E     36
 11010     G      &        1A     32          10011     W      2        13     23
 10100     H      STOP     14     24          11101     X      /        1D     35
 00110     I      8        06     06          10101     Y      6        15     25
 01011     J      '        0B     13          10001     Z      "        11     21
 01111     K      (        0F     17          01000     CR     CR       08     20
 10010     L      )        12     22          00010     LF     LF       02     02
 11100     M      .        1C     34          00100     SP     SP       04     04
 01100     N      ,        0C     14          11111     LTRS   LTRS     1F     37
 11000     O      9        18     30          11011     FIGS   FIGS     1B     33
 10110     P      0        16     26          00000     n/a    n/a      00     00

There are some small differences between CCITT No.2 and ITA-2 (US) in "FIGURES SHIFT" mode.

bitcode	CCITT No.2	ITA-2
00101	apostrophe	BELL
01001	WRU	$
01011	BELL	apostrophe
10001	+	double quote
10100	pound sign	#
11110	=	;

Sometimes people forgot to hit the LTRS key. What followed was garbage of numbers and interpunction characters instead of text. This problem was solved by a feature that is called UOS, which stands for Unshift On Space. If UOS was enabled and the message sending party generated a (white)space after any number or interpunction (comma is a good example), the receiving party automatically reverted from FIG to LET to get intell (readable) output.

The demodulator
To be able to receive RTTY signals at all shifts and tones you must build a few more bandfilters (read the backgrounder on RTTY signals). The center frequencies of the bandfilters are the following.

1275 space - new tones
1445 mark - new tones, shift 170
2125 space - old tones, shift 850 OR mark - new tones, shift 850 (rare)
2295 mark - old tones, shift 170
2975 mark - old tones, shift 850

The bandfilters are constructed using the old OpAmp µA741 (or LM741, etc.) A good design which is not difficult to build is from the German amateur DJ6HP. This is only suitable for RTTY. I have used this design in the 19-eighties.
A simple converter based on a PLL using the Exar XR2211 also produces good results.
Check out Technicothica for more on converters, especially the buttons "AEA CP-1", "AEA CP-100" and "XR2206 & XR2211".
I could have built a filter-based converter myself (I've done it before!), but I guess I am getting a bit lazy.
So, when an AEA CP-100 Computer Patch was offered on www.eHam.net , I bought it (for just $20).

Timing the received data bits
After the demodulator, the audio tones are represented by a digital signal ('0'/'1'). In the idle state the received bit is always a logic '1'. The start of a new character is indicated by a '1' -» '0' transition, the start-bit. The data bits of the character follow the start-bit at fixed time intervals, the baudrate.
The detection of the start-bit is trivial in the decoding software. Just poll the input. However, the question is "how to time the interval, and sample the following data bits?" A poor solution is the "busy-wait" loop, in which you run the timing in a tight loop of which you counted the cycles needed to execute the instructions in the loop. The drawback of this approach is that the processor cannot do anything else (what a waste), and timing can be off when the software runs on another system.
Since you need a parallel I/O module (at least one input bit, but if you also want to transmit, you need two output bits, one for the data, the other to switch the transceiver to TX), you can use more I/O bits to make an accurate timing generator. Of course, you can install a programmable timing module in your PDP-11, but I consider that overkill. Anyway, if you do not want to solder a little electronics, the UNIBUS module is the M7228, and the QBUS module is the M7952. But you will have to write the software to control these timing modules yourself, I only develop what is described here.
accurate timing generator

The drawing shows the principle diagram of the timing generator. It is a so-called dead-ending counter. "CLK" is a free-running oscillator, which is adjusted to an appropriate frequency. The NAND gate enables/disabled the the clock pulses to the 74LS193's which are setup as down-counters. On the parallel input data you set a number that must be counted down (at the CLK frequency), and with the LOAD signal you set the counter to that value. As the counter value is no longer '0000 0000', the CD output is logic '1', so a logic '1' on the ENABLE signal will start the counter. When the counter reaches '0000 0000', the CD output goes to logic '0', thus disabling the counter via the NAND gate. The CD output also generates an interrupt to the processor (via the parallel I/O module), to indicate that the loaded time-out value has occurred.

... to be continued ...
but this is a low-priority project. I have some other contraptions to finish first!
(A switchbox to connect two sets mutual exclusive to either a PC with galvanic isolation, or to a real handmike with PTT, morse key and loudspeaker or headphones. This project will be publicized in "Electron", a monthly magazine for HAM radio amateurs).