On December 21, 1999, the Federal Communications Commission (FCC) approved a request for a Special Temporary Authority (STA) to establish and operate a 1000-watt Radio Teletype (RTTY) Broadcast Station on 6994KHz and 13972KHz using the callsign WA9XHN. This non-profit broadcast transmitter operated daily until the FCC license expired. The experiment was considered a success with listeners around the world.

A new approach needed to be developed to allow customers to submit multiple channels of text data asynchronously to a broadcast point for delivery to their users at remote points around the globe. A new concept was developed that tied in the original WA9XHN concept with Internet access and minimal hardware and software requirements at a minimal cost for receive capability. PSK31 was recently introduced as a new communications protocol, complete with public domain source code and documentation.

PSK31 was introduced by Peter Martinez, G3PLX as an amateur radio communications mode which uses phase modulation and special character coding. The original protocol was designed to support robust narrow bandwidth communications between two radio operators on a single frequency. The inherent nature of the protocol to receive data in relatively high signal-to-noise ratios make this protocol a candidate for broadcasting data via the short wave bands.

Software and source code was published in the public domain by Moe Wheatley, AE4JY which used a computer and sound card to both decode and encode PSK31 signals. The technology evolved into a complete user interface and Dynamic Link Libraries (DLL) using Microsoft Visual C++ . Most of his software is available with source code in the public domain.

Using this DLL, software was introduced that allowed a Single Side Band (SSB) receiver to decode up to 20 simultaneous PSK31 transmissions at the same time by Joseph T. Faria, W1SQL. Joseph published his public domain software package capable of doing this. This capability would allow for multiple channels to be received, each with a different content.

Equipment requirements were simple for receiving the transmitted protocol. Hardware consists of a Pentium-class computer of 100 MHz or greater with basic sound card, a stable High Frequency (HF) receiver capable of receiving single sideband (SSB) transmission and free software available in the public domain. Both Microsoft Windows™, Linux and UNIX operating systems are also supported.

This article was prepared by the author to introduce you to a recent software development project. These projects include working with Microsoft Visual C++ to produce an integrated software package to support the next-generation STA for WA9XHN. It describes the internal workings of the WinPSK31-16 program that was developed to satisfy the requirement to broadcast multiple channels simultaneously using a single SSB HF transmitter

Software disciplines that are demonstrated in this paper utilize TCP/IP networking, serial communications, Microsoft Foundation Classes™ (MFC).

2 WinPSK31 16 Channel Multiplexer

2.1 Introduction

The PSK31 16 Channel Multiplexer software allows the multiplexing of 16 separate data streams using a single computer and sound card. Protocols that are supported are PSK31 QPSK, BPSK and CW (Morse Code). The 100 Hz spacing allows for the 16 multiplexed signals to be transmitted via a single SSB transmitter.

Operations concepts (CONOPS) include broadcasting of QST's to include channelized subject matters, software testing of multi-channel decoders, PSK31 demonstrations, disaster support transmission of health and status, etc. For those that are diehard CW operators, it can also be used to originate 1 to 16 CW channels of CW text as well. I've run two copies on the same computer for up to 32 simultaneous channels! Internet connectivity has also been added as well, allowing for remote access to any one of the 16 channels.

The software was developed using Microsoft Visual C++ version 6.0 and includes PSK31 and CW sound card engines developed by Moe Wheatley, AE4JY. The license for software written by Moe Wheatley is defined in the GNU General Public License as published by the Free Software Foundation.

2.2 PSK31 Design

The following description of the PSK31 protocol was borrowed from the "WinPSK Technical Reference Manual", by Moe Wheatley, AE4JY. As shown in Figure 1, creating a PSK31 signal is done in stages starting with character input to final waveform output to the soundcard.

Figure 1: Single Channel PSK31 Functional Block Diagram

2.2.1 Input Characters

PSK31 sends and receives 8 bit characters. 0 through 127 are the standard ASCII characters and 128 to 255 are extended characters. PSK31 receive applications ignore most control codes below the SP(/0x30) character to reduce some of the garbage from making it to the screen. Some of the Windows controls also behave badly when a control character is sent to them.

The first step in PSK31 encoding is to map the 8 bit fixed length input characters into variable length characters. By mapping most used characters into shorter codes and least used characters into longer codes, the overall data transfer speed can be increased. This is similar to Morse code where common letters are shorter sequences. The letter 'e' occurs more often in text than a 'z' so it has a varicode of '11' while a 'z' has a code of '111010101'. Notice that lowercase letters have shorter codes than upper case letters. This is why one should not use all uppercase when using PSK31 since the varicode was optimized for lowercase letters.

Since the character data is sent serially, some means of separating characters is also needed. This is accomplished in PSK31 by specifying that two or more consecutive zero bits separate each character. This also places the requirement that each character code cannot contain more than one consecutive zero. It also means each code must start and end with a one. With these requirements the Varicode code table was specified. The varicode words from the table are sent msb first. If a new character is not ready in time to be sent, Zeros are padded into the data stream.

Example bit stream of varicoded character sequence "abc":

2.2.2 BPSK Serialization

PSK31 is actually Differential Phase Shift Keying because the information is sent as changes in signal phase rather than an absolute phase state. This makes signal reception much easier since the initial signal phase does not have to be known. For the Binary Phase Shift Keying mode, the signal either changes phase by 180 degrees for each ZERO bit or remains the same to represent a ONE bit. The symbol rate for PSK31 is 31.25 symbols per second or a period of .032 Seconds. The Varicode word is serialized and converted into a 2 bit symbol before being sent to the differential phase state machine which will determine the next signal phase based on the present phase and the new symbol.

Figure 2: BPSK Serialization

2.2.3 QPSK Serialization

Quad Phase Shift Keying as shown in Figure 3 allows four unique phase states for each symbol effectively doubling the amount of information that can be sent over BPSK. Rather than send data twice as fast, PSK31 uses the extra information to allow for error correction.

Figure 3: QPSK Serialization

For further information on the WinPSK protocol, reference the "WinPSK Technical Reference Manual", by Moe Wheatley, AE4JY. Contact information can be found in the reference section of this paper.

The next sections will discuss the design of the WinPSK31-16 Multiplexer, WEB server and CGI interface, and the WA6XHN Program Schedule architecture.

2.2.4 Multiplexing of 16 Channels

WinPSK31-16 is a PSK31 application capable of generating 16 multiplexed channels on a single sound card. A separate schedule control file can control each channel and text material for broadcast. In addition there is an integrated TCP/IP interface that allows users to telnet into the application using a unique port for each channel.

Figure 4 shows the Power Spectrum bandwidth for a single PSK31 signal. The main power lobe is approximately ±31.1 Hz. Using the third sideband at -48 dB (±70 Hz) as a reasonable power separation level between multiple PSK31 signals, we can determine the optimum spacing between PSK31 signals. Our testing used a value of 100 Hertz with a measured separation between signals of -50 dB power levels.

Figure 4: Single PSK31 Signal Power Spectrum

The spectrum analysis display in Figure 5 uses a Fast Fourier Transform (FFT) algorithm and shows the 16 channels being broadcast simultaneously with sufficient separation between channels for at least -50dB of isolation between channels. It's important for this power separation in order for the sound card to perform its FIR message decoding.

Figure 5: Sixteen PSK31 Channels at 100 Hz Spacing

2.3 PSK31-16 Architecture

2.3.1 Graphical User Interface (GUI)

As with most applications, PSK31-16 was developed using a single dialog window displaying all of the important functions to the operator, as seen in Figure 6. The window dimensions fit within an SVGA 800x600 display screen.

Each of the 16 channels has a check box for controlling the TX operate function, a set of mode buttons that indicate idle, data and Morse code identification (CWID). The drop down list box shows the current text file being transmitted and the queued files in the buffer. To the right is the master control window that establishes how the broadcast feature functions. Commands in the Master control file control channel state, timer delays and data flow. The box on the lower right indicates status of the application.

Figure 6: WinPSK31-16 Control Panel

In the upper right part of the display, the operator is allowed to select Binary PSK (BPSK), Quatrature PSK (QPSK), and CW mode. The frequency mode boxes allow the control operator to set the frequency of the lowest channel and the incremental offset in Hertz of the remainder 16 channels. The Sample Rate check boxes allow the operator to set the samples per second for each of the channels. These radio buttons were provided to allow the selection of the highest sample rate the platform would allow. Because of the nature of generating 16 channels, testing found that at least a 550 MHz processor was required for 44100 BPS sample rate before sound card buffer dropouts were experienced.

WinPSK31-16 was developed using Microsoft Visual C++ version 6.0 and uses a modified version of the DSP software developed by Moe Wheatley, AE4JY. The PSK31 software was enhanced to allow 16 C++ classes to operate in parallel to generate each of the 16 channels as shown in the Figure 7. A CW generator was added from Windows Soundcard Generator program consists of a single executable program "WSCGen" written by Moe Wheatley AE4JY. Moe. Wheatley wrote the program to experiment with using the PC soundcard under Windows 95/98/NT for producing various amateur radio modulation signals. It's capability to generate a, PSK31 BPSK and QPSK signals, and CW code signals were modified and adapted to produce the 16 separate channels using the Microsoft Visual C++ programming environment.

In addition, 16 Telnet channels were added using TCP/IP Port 6000 through 6015 and there is a graphical user scheduler interface capable of controlling each channel separately.

The PSK31 tone generation is controlled using a processing thread that is given a higher priority than other processes. The GUI software is required to give processing time back to the Windows™ operating system at critical locations in the code which allows the time-critical PSK tone generation to keep the sound card input buffer full. This is the difference between a UNIX pre-emptive multi-tasking environment and A Windows™ cooperative multi-tasking environment. The PSK31-16 software application releases time back to the operating system at critical locations in the code in order to retain strict timing requirements.

Figure 7: PSK31-16 Software Data Flow Diagram

2.3.2 Logging

All activities in the Channel Scheduler and the TCP/IP socket services are logged to text files. These files are created using the system date in the file name and are placed in the Log directory. All failed attempts to connect via the Internet are logged as well.

2.3.3 Security, Hacking and Bad Hosts

Users are allowed to input their authentication code during a Telnet session up to 4 times. After the fourth time, the user IP address is logged in a BADHOST file. The CONOPS here is that a user will have to obtain a new IP address before hacking attempts can be continued. This in combination with a Password file should keep most Hackers disappointed at accessing the application.

Additional security is included to encrypt the data input via the TCP/IP interface using a simple algorithm. Due to security concerns, this proprietary algorithm will not be documented in this paper and is subject to periodic change.

2.3.4 TCP/IP Connectivity

Each of the 16 channels has a TCP/IP listen socket attached. These sockets listen to ports 6000 through 6015. Only one connection is allowed to any one port at any time and the user must provide an authentication code. If a user attempts to connect to a channel already occupied by a telnet session he is greeted with a polite rejection message. A Password file controls user access.

2.3.4.1 Telnet Access

A user can use most Telnet applications to access the PSK31-16. A user connecting with full privileges receives the following greeting and will have full transmit authority with transmitted data echoed back to the user.

Welcome to WinPSK31-16 Gateway, you are connecting to Channel 1

Please input your authentication code :*****

Password accepted, You are now connected to PSK31-16 Channel 1

You have write privilege, enjoy

-----------------------------------------------------------

A user with only READ privileges will receive the following greeting and will only be able to monitor activities on that channel

Welcome to WinPSK31-16 Gateway, you are connecting to Channel 1

Please input your authentication code :*****

Password accepted, You are now connected to PSK31-16 Channel 1

You do NOT have write privilege, but you can monitor,

anything you send gets placed in the bit bucket

-----------------------------------------------------------

2.3.4.2 WEB Server Access

A WEB server and Command Graphics Interface (CGI) were added to the architecture to allow the user to drop files into WinPSK31-16 on any channel using common HTML interfaces. Microsoft Visual C++ provided a sample program HTTPSRV as an example of MFC web server application. It operates as a single-document interface application, and has been modified to POST inputs to a CGI application that opens a socket and passes data to PSK31-16.

Modifications have been made to the server to improve Internet security where a remote attacker can run arbitrary code on the server by sending a carefully crafted POST request containing a MS-DOS command. The fix includes a POSTSPAWN control file that lists only those POST executable calls that can be accepted by the server.

As shown in Figure 8, the user submits data to the HTTPSRV via a WEB browser (Netscape or Internet Explorer), the HTTPSRV establishes a socket connection to PSK31-16 and passes the data to the specified channel (1 - 16) and the output flows to the transmitter. Status is returned to the user's WEB browser as to the success or failure of the attempt.

Figure 8: WEB Concept of Operations Data Flow Diagram

2.3.4.3 RTTY Scheduler Access

A software package was developed as a part of the original WA9XHN broadcast architecture that allowed the scheduling, control and transmission of several digital protocols. The application, RTTYApp, as it was called, was modified to include a TCP/IP telnet client capability that would connect to the PSK31-16 application via the Internet. The originator has the option of simultaneous broadcast at his location as well as forwarding the text broadcast material to the PSK31-16 application.

This capability provides a customer the capability to forward traffic to PSK31-16 based on a timed event schedule, thus automating the forwarding of messages at any time of the day. The PSK31-16 input buffer will store and forward any received data, thus accounting for data rate differences between the Internet and the 31.1 Baud rate of PSK31.

2.3.5 Password Access Control

The PASSWORD file contains a user authentication code and a 32 bit-mask authorization code. Some general rules were used in creating the PASSWORD file. The authentication code must begin with an alpha character, and comment lines begin with a non-alpha character. The user authentication code can be up to 255 characters long. The authorization code is a bit-mask for each channel. If the bit is high, that channel is enabled for that user. There are two halves to the authorization code. The lower 16-bits allows user access to that channel and is required for user READ access. The upper 16-bits allow the WRITE access to the channels. You must have READ before you can have WRITE.

aa6ed 0xFFFFFFFF // all access read and write

w7ksj 0x8000FFFE // all except channel 1 port 6000, write only on 15

ch3 0x00000004 // only access to ch 3 port 6002, no write

numchuck 0x00007FFE // all except 15 and 1

guest 0x0000FFFF // Receive-only on all channels

2.4 RTTY Program Scheduler (RTTYApp)

2.4.1 Description

In order to semi-automate the process of scheduling and transmitting data, the scheduler must have the capability to control the data rates, transmitter on/off control and programming material. The program RTTYApp was written in Microsoft Visual C++ version 6.0 and provides the appropriate graphical user interfaces (GUI) as shown in Figure 9. The program was originally designed to control a transmitter directly, but it has been enhanced to support Telnet connections to PSK31-16 and local sound card tone generation for BAUDOT and PSK31 transmissions.

Figure 9: Graphical User Interface

The software scheduler contains several modules that are responsible for controlling its functions. Button controls as shown on Figure 9 shows basic human machine interfaces required to manage the scheduler.

2.4.2 Scheduler Editor

Editing the scheduler is very critical for the proper operation of this software application. Most combinations of bad inputs have been tested, but the basic design is such that on reading the file, only those events in the future will be scheduled (based on current computer clock.

Figure 10: Schedule Editor

2.4.3 Scheduler Design

As shown in Figure 11, news articles are organized into a schedule definition file that defines the date and start time for input text the file. The schedule is loaded and displayed in a list box for the operator to view and modify as required. When the schedule is enabled, the time for the next transmissions is checked against the computer clock, and when ready, is passed to the next function for transmitting. Depending on the MODE setting (Military, TELEX, ITA#2 or ASCII) the data is passed to the Transmit and RS-232 controls.

Figure 11: Scheduler Data Flow Diagram

2.5 Summary

This software development exercise was intended to demonstrate that a simple software application could be prototyped in a quick fashion in order to support an experiment. While the experiment's application may not been the most hi-tech one in recent history, it demonstrate a real-world problem that could be made easier by software.

Figure 12: Elements of the Original WA9XHN Project

The FCC STA demonstrated the interest in this type of communications service. Customers can use the Internet to forward lengthy messages to remote receivers around the globe using the minimal radio frequency bandwidth. Remote receivers can be assembled with little effort; a laptop computer and an HF receiver are all that is required to receive the data.

More information can be obtained at http://www.rtty.com which also has other software and source code for the RTTY software programmer enthusiast.

3 Appendix

3.1 References:

W1SQLPSK 20 Channel Software Application

FARIA, JOSEPH T, W1SQL
117 FAIRLAND DR
FAIRFIELD, CT 06432

WinPSK Technical Reference Manual and WSCGen Developer

WHEATLEY JR, MAURICE S, AE4JY
3342 CANARY TRL
DULUTH, GA 30136

Internet Access:

ae4jy@qsl.net

www.mindspring.com/~ae4jy

Licensee of WA9XHN Special Test Authorization from the FCC

HUTCHISON, GEORGE B, W7KSJ
11224 SE 320TH ST
AUBURN, WA 98002

WinPSK31-16 Developer

BYTHEWAY, WILLIAM H. AA6ED

11108 SE 84^th Place

Renton, WA 98055

aa6ed@arrl.net

GNU GENERAL PUBLIC LICENSE

Version 2, June 1991

59 Temple Place - Suite 330, Boston, MA 02111-1307, USA

3.2 Metrics

The following tables document the over 17837 lines of software code required for this project.

3.2.1 PSK31-16

Acknowledgement of the author is referenced in the comments column. Original AE4JY modules were modified to support the 16 channel multiplexing architecture.

Module	LOC	Comment
Generators.cpp	317	AE4JY
ProcThread.cpp	465	AE4JY
PSKGen.cpp	1066	AE4JY
RttyPsk.cpp	82
RttyPskDlg.cpp	1302
Sound.cpp	657	AE4JY
StdAfx.cpp	8
Telnet.cpp	618
Utilities.cpp	46
Wave.cpp	661	AE4JY
ProcThread.h	57	AE4JY
PSKGen.h	132	AE4JY
Resource.h	142
RttyPsk.h	52
RttyPskDlg.h	188
StdAfx.h	28
Telnet.h	80
Utilities.h	7
Project total	5908

3.2.2 RTTYApp Scheduler

This application was built to provide a robust scheduler for RTTY, PSK31 and now PSK31-16. . Acknowledgement of the author is referenced in the comments column. Original AE4JY modules were modified to support the 16 channel multiplexing architecture.

Module	LOC	Comment
Sound\Generators.cpp	317	AE4JY
Sound\MSKGen.cpp	119	AE4JY
Sound\ProcThread.cpp	498	AE4JY
RTTYApp.cpp	85
RTTYAppDlg.cpp	2964
RTTYSchedule.cpp	865
Sound\Sound.cpp	661	AE4JY
StdAfx.cpp	6
Telnet.cpp	255
codes.h	189
Defines.h	57
Sound\ProcThread.h	64	AE4JY
WinPSKCore\PskCoreImplicit.h	89	AE4JY
Resource.h	114
RTTYApp.h	52
RTTYAppDlg.h	187
RTTYSchedule.h	86
Sound\Sound.h	104	AE4JY
StdAfx.h	27
Telnet.h	68
Project total	6807

3.2.3 HTTPSVR

This application is the WEB server. The original code was provided with the Microsoft Visual C++ libraries and was modified for the POST operation for CGI scripting.

Module	LOC
GenPage.cpp	105
Http.cpp	80
HttpDoc.cpp	346
HttpSvr.cpp	216
HttpView.cpp	601
Listen.cpp	43
MainFrm.cpp	153
NamePage.cpp	133
NoRoot.cpp	52
ReqSock.cpp	1454
Request.cpp	61
RootDlg.cpp	52
RootPage.cpp	118
StdAfx.cpp	16
genpage.h	50
http.h	37
httpdoc.h	81
httpsvr.h	56
httpview.h	94
listen.h	24
mainfrm.h	59
namepage.h	57
NoRoot.h	44
reqsock.h	111
request.h	54
rootdlg.h	44
RootPage.h	55
stdafx.h	33
Project total	4229

3.2.4 HTTPDOC -

This module is the CGI application that is called by HTTPSVR and connects to PSK31-16.

Module	LOC
HTTPDoc.cpp	175
HTTPUtilities.cpp	261
StdAfx.cpp	8
Telnet.cpp	302
HTTPDoc.h	15
HTTPUtilities.h	12
Resource.h	16
StdAfx.h	30
Telnet.h	74
Project total	893