Hamradio and computer programming are my favourite hobbies, so it will be no surprise that I am a fan of the digimodes. My first love was RTTY using a mechanical teleprinter (Siemens T37) and a demodulator with filters built around the familiar 88 mH toroids.

With the advent of microprocessors and their peripherals the noisy teletype was replaced by an 8080-based microcomputer and a home built computer character display IKUNULLIUS [1]. When a kit to build your own graphic display (black and white) became available the field of SSTV was entered [2]. Gradually these applications were moved to a standard PC using software like Digipan [3] and jvcomm32 [4].

Last year I got a Silicon Graphics INDIGO-2 workstation for free. It has a big high resolution color monitor and the specs revealed a powerful audio subsystem. Although I am retired now, I still like to exercise my skills in (realtime) programming. Trying to put this machine to use in hamradio then was a natural thing to do. Logical candidate applications were SSTV and PSK31. I am active in both modes using a commercial DSP-controller from SCS, the PTC-IIe and the windows software that came with it. I am very satisfied with this setup and I get compliments on the purity of the signal, so technically there was no need to try to move these applications to the INDIGO.
So just for fun and to gain understanding of the PSK31 technique I started this project.

Every software project should start with a set of demands. I formulated the following:

A literature study revealed that Moe Wheatley, AE4JY, has developed his program WINPSK more or less with the same motivation. His comprehensive technical manual [5] and the availability of the source code of WINPSK gave me a splendid starting point. Although quite some of his code has been used, the program that I developed is not a straight port of WINPSK to SGI's operating system IRIX. The main differences are:

The remainder of this article is devoted to a description of the program which I have called IRIXPSK and its performance in operation.


The main program follows the standard design for an X11 program. It starts with the initialisations, i.e. of the windows structure and the audio subsystem, followed by a loop in which all the work is done. During this loop mouse and keyboard input is recognized and acted upon in a way that depends on a state variable (rx=1 receive; rx=0 transmit).

Receive mode

The processing in receive mode follows the setup of Moe Wheatley [5]. In receive mode the work is done in the routine do_rx(), mouse input is limited to left clicking in the waterfall display window to set the rx frequency (cfreq) and keyboard input to the character control-Y to end the receive mode.

Do_rx() starts with acquiring 4104 audio samples at 11025 Hz in a buffer using the routine monorec(). The first processing step is low pass filtering with a cutoff frequency of 2700 Hz, simultaneously reducing the number of samples by a factor of 2. 2048 of the resulting 2052 samples are copied and used in a Fast Fourier Transformation (FFT). The result is converted to a powerspectrum (1024 points) which has a resolution of 2.7 Hz and spans 0 - 2756 Hz. After conversion to a logarithmic color scale from blue to yellow this spectrum is put in the top line of the waterfall display window after scrolling down the original content of this window 1 line down.

Parallel to the FFT the result of the low pass filtering and decimation by 2 is also fed to a numerically controlled oscillator (NCO) running at cfreq Hz. Up to the BPSK-symbol detection the output of the NCO is processed by a number of finite impulse response (FIR) digital filters in 3 stages. The filters were taken from the paper by Wheatley [5]. Symbol synchronization and detection is realized in a manner different from WINPSK. The result of the last 79-tap FIR filter consists of 229 points in the frequency band of 0 - 16 Hz and represents 11.6 symbols. A phase change of 180o has zero crossings as well in the I- as in the Q-form of this signal. The location of the zero crossings are determined and together with the knowledge that the length of a symbol is 19.6 points the position of the symbols and their value is found.

Transmit mode

In transmit mode the work is done in the routine do_tx(). Buttons for canned messages for CQ and Brag text can be activated by left mouse clicks. There is a button for an emergency stop of the transmitter and keyboard text is entered into a keyboard buffer (type ahead). The do_tx() routine takes ascii characters from the keyboard buffer, translates them into varicode symbols and generates the corresponding audio signal for these symbols and sends this audio out via the audio subsystem at a sample rate of 11025 Hz. If no keyboard text is available in the keyboard buffer zero symbols are generated and sent to the audio subsystem.

If an ascii character control-Y is typed at the keyboard the system returns to the receive mode

Realtime aspects

In rx-mode the audio subsystem is started to gather audio samples in an internal buffer with a sample rate of 11025 Hz. With a blocking routine called ALreadsamps() from the audio library of the IRIX operating system 4104 audio samples are transferred from the internal buffer of the audio subsystem to a memory buffer of the program in the routine monorec(). If there are not sufficient audio samples available the routine waits until all required samples are gathered. The processing of the acquired audio samples should be ready before the internal buffer is filled completely. This can be checked with the use of a routine called ALgetfilled from the audio library. As long as the number that is returned by this routine is less than the size of the buffer all is OK.

In tx-mode the program puts audio samples in a buffer of the audio subsystem. Now the internal buffer should not be completely empty before a next set of samples is put into it.


In rx-mode the number of audio samples available when starting a new run through the processing loop is generally around 1000 at a buffersize of 4104 samples, so the processing speed is more than adequate. Also in tx-mode no problems were encountered with the processing speed.

The system was tested on the air with the line output of the INDIGO-2 audio subsystem connected to the phone patch input at the back side of my YAESU FT-ONE transceiver. The audio line output was set to 100 mV amplitude in the software. Mike input control on the trx can then be at the 8 oclock position. The AF-out terminal at the back side of the trx was connected to the microphone input of the audio subsystem of the INDIGO and is at a level that fits the input range rather well if maximum gain is set in the software. Both audio cables were wound with 4 windings through a toroidal core to prevent hf interference in the audio subsystem. To be able to evaluate the performance of the system the audio rx-signal was also fed to a commercial DSP mulitmode controller, the PTC-IIe from SCS.

The rx results of both systems are generally about the same. Only under rapid QSB situations the PTC-IIe is clearly the better one. I guess that its AGC system is better. Changing the time constants in IRIXPSK did not improve the situation. Under constant weak signal conditions IRIXPSK performs somewhat better, presumably because I did not implement squelch and I do operate the PTC-IIe with its squelch on. Switching the squelch of the PTC-IIe off under these conditions causes too much garbling.



Download irixpsk.tar