Open Source WSJT
Status, Capabilities, and Future Evolution
Joe Taylor, K1JT
12th International EME ConferenceWürzburg, August 25–27, 2006
Introduction
The software program WSJT originated in 2001 as part of an attempt to ﬁnd optimum or near-optimum coding and modulation schemes for weak signal communication on
the amateur VHF/UHF bands. My initial experiments were made with phase shift keying(PSK) on meteor scatter paths, but the ﬁrst practical system made available to others used
continuous-phase, 4-tone frequency shift keying (4-FSK) at 441 baud with noncoherent demodulation and a unique self-synchronizing method. This mode, called FSK441, is now the
predominant one used for amateur meteor scatter communication throughout the world. A
detailed description of it was published in the December 2001 issue of QST.1
In late 2001 I began experimenting with a 44-tone FSK system keyed at 5.38 baud,
designed primarily for EME. A version of WSJT including the JT44 protocol was releasedin early 2002, and the ﬁrst EME contacts with it were made soon afterward. A descriptionof JT44 appeared in the June 2002 issue of QST.2 A few months later the JT6M mode wasintroduced, using 44-FSK at 21.5 baud—a keying rate well suited to working ionosphericscatter on the 50 MHz band. The JT44 and JT6M modes worked well, but some early users
more knowledgeable than I about digital communication techniques suggested that forward
error-correction (FEC) might be beneﬁcial, especially on the EME path. I was intrigued,
but badly in need of education. Some months of study and many questions of experts wererequired before I could usefully proceed in this direction.
By late 2003 a new mode called JT65 had been designed and tested successfully on
both terrestrial and EME paths. JT65 is a departure from previous WSJT modes in that it
uses structured messages to allow lossless compression of callsigns and grid locators. With
such compression, FEC enhancement becomes a necessity. The low-rate Reed Solomon code
selected for JT65 makes a good match for the chosen FSK modulation, which consists of 64
1

J. Taylor, K1JT, “WSJT: New Software for VHF Meteor-Scatter Communication,” QST December 2001,
pp. 36–41.
2

J. Taylor, K1JT, “JT44: New Digital Mode for Weak Signals,” QST June 2002, pp. 81–82.

orthogonal data tones and a 65th tone used for time and frequency synchronization. A stateof-the-art, award-winning “algebraic soft decision” algorithm3 decodes received messages,
and message averaging permits the decoding of messages too weak to be copied in a single
transmission.
Several features were added to the JT65 decoder during its ﬁrst year, including automatic frequency control to correct drifting signals and a hinted decoding procedure that takes
advantage of a callsign database to suggest hypothetical messages to be compared against
received data. Laboratory simulations were carried out to measure JT65’s performance andreliability, and these measurements were conﬁrmed by on-the-air experience. A user-leveldescription of JT65 was published in the June 2005 issue of QST,4 and full technical detailsof the JT65 protocol and its implementation within WSJT published a few months later
in QEX.5 JT65 has become popular because it oﬀers an opportunity for even modest-sizedstations (single yagis and 150 Watts) to make dozens of unique EME QSOs at 144 MHz.
Open Source
Recognizing that I am not getting any younger, and hoping that the considerable eﬀort
put into WSJT modes might evolve into even better things for amateur radio, in 2005 I undertook a major re-write of the program so that it could be made “open source.” This goal
was accomplished by the end of 2005; the program’s source code, written in a combinationof Python, Fortran, and C, is now available to anyone6 under the terms of the GNU General
Public License.7 Working with the beneﬁt of an open repository for the code, a core group of
highly competent programmers are now actively engaged as the WSJT development team.8
Sharing their valuable know-how, these individuals have compiled, operated, and made enhancements to WSJT on the Windows, Linux, and FreeBSD platforms. More than 200 otherpeople have downloaded and studied the WSJT source code, as well, and many have oﬀeredvaluable advice and counsel to the development team. The team welcomes new members,
and there are many opportunities for good ideas in coding theory, digital signal processing,3

R. Koetter and A. Vardy, “Soft-Decision Algebraic Decoding of Reed Solomon Codes,” in IEEE Transactions on Information Theory, 49, 2809–2825, 2003.
4

J. Taylor, K1JT, “EME with JT65,” QST, June 2005, pp. 80–82.

5

J. Taylor, K1JT, “The JT65 Communications Protocol”, QEX, September-October 2005, pp. 3–12.

6

Source code can be downloaded from http://developer.berlios.de/projects/wsjt/.

7

Text of the GPL may be found at http://www.gnu.org/copyleft/gpl.html

8Team members presently include DL3LST, K1JT, KK7KA, N4HY, OH6EH, ON/G4KLX, VA3DB, andJames Courtier-Dutton.

user-interface design, and the like. Most of us are amateurs in some or all of these areas,
and we have much to learn! For those interested in programming details, an Appendix tothis paper provides a structural overview of the WSJT program as of version 5.9.
Present Status
Unlike commercially engineered hardware or software, WSJT is a just-for-fun activity
that has been pursued for its educational beneﬁts and a desire to push forward the amateur
weak-signal frontier. Part of the fun, and large portions of the educational beneﬁts, areclosely related to the program’s status as a work always in progress. New ideas are frequently
tried and tested, and when successful they may lead to new program features. I expect that
this trend will continue and perhaps even accelerate as new people become involved.
Despite continuing program evolution, the basic capabilities of WSJT have been essentially stable since 2003 for the FSK441 and JT6M modes and since early 2005 for JT65. It
appears that JT65 has become the mode of choice for the majority of amateur VHF EME
contacts, except perhaps during CW-only contests or activity weekends. The reasons areeasy to understand, and can be summarized in the following table summarizing minimum
usable signal levels for various classes of JT65 messages and decodings:

Message type
Arbitrary message, including plain text . . .
Callsign in database (Deep Search) . . . . . . .
Arbitrary message, with averaging . . . . . . .
Message synchronization . . . . . . . . . . . . . . . . .
Shorthand RO, RRR, 73 . . . . . . . . . . . . . . . . .

Minimum S/N (dB)
−24
−28
−29
−30
−32

The tabulated signal levels are quoted in dB relative to the noise power in a nominal SSB
transceiver’s 2500 Hz bandwidth. They measurements are based on numerical simulations
using the JT65B submode, with simulated Rayleigh fading and controlled amounts of additive white gaussian noise. Additional details of the simulation results are contained in
Figure 1.
For comparison, it is useful to note that signals begin to become audible around −16 dB
on the WSJT scale (or +1 dB in 50 Hz bandwidth), depending somewhat on the details ofreceiver and ear-brain ﬁltering. When copying messages of similar complexity, JT65 generally
outperforms human-copied Morse code by 10–15 dB.

Fig. 1.— Percentage of simulated JT65B transmissions copied correctly, as a function of signalto-noise ratio in 2500 Hz bandwidth. KV indicates Koetter-Vardy algorithm, while KV2 and KV4
indicate Koetter-Vardy decoding of the averages of 2 and 4 transmissions, respectively. DS indicatesthe Deep Search algorithm, “Sync” indicates achievement of time and frequency synchronization,and “Shorthand” indicates copy of the special messages RO, RRR, and 73.

JT65 has some characteristics that require getting used to. Unlike the more traditional
coding and modulation methods widely employed in amateur weak-signal work, the reliability of copy with JT65 is not incrementally degraded as signals approach the minimum
usable levels. Instead, one normally sees a whole message decoded correctly, or not at all.
When hinted decoding (the so-called Deep Search decoder) is used, only hypothetical messages combining CQ or the user’s own callsign with a callsign and locator from the callsign
database will be tested against the received information. A stranger callsign—one not in
the database—cannot be copied this way, nor can any plain text message. Such messages
must be decoded by the general purpose Koetter-Vardy decoder, using message averaging if
necessary.
The JT65 protocol is reasonably robust in the presence of low-level interference suchas weak birdies. The decoders in WSJT cope well when several JT65 signals are present
simultaneously, often allowing the operator to copy each signal separately even if they overlap in time and frequency.9 The protocol’s shorthand messages are an extremely eﬀective
and reliable way of exchanging minimal signal reports, acknowledgments, and end-of-QSO
indications (RO, RRR, 73). Other message formats are available to convey multi-valued
signal reports, suitably tagged with callsigns, whenever circumstances make them desirable.
During the development of WSJT, and especially while working on the EME-capablemodes JT44 and JT65, I have enjoyed and beneﬁted from a wide range of input from others.
Dozens of experienced EME practitioners have been approached for advice and have willingly
shared their views; excellent suggestions have been volunteered from an even larger number.
Most recently the enlarged WSJT development team has contributed very signiﬁcantly, as
well. Inevitably, we have not satisﬁed all requests, but the evident popularity of JT65 seems
to indicate that a good balance of features and capabilities has been achieved. Operating
experience with JT65 now extends over some 2.5 years, and with that experience a heavy
dependence on scheduled QSOs is rapidly fading away. As everyone at this conference knows,
the thrill of an unexpected response to one’s CQ directed at the moon can be a captivating
experience.
Not surprisingly, some operators who are more comfortable with traditional coding andmodulation techniques have stayed with the modes they like best—and that is as it should be.
Morse code with on-oﬀ keying remains an extremely powerful and capable communication
protocol, one that has much greater ﬂexibility and a wider range of utility than the specialpurpose protocols of WSJT.
Looking Ahead
I have mentioned that WSJT is a work in progress. What lies ahead? What might be
the most telling motivations for future changes or additions? What about other possible
implementations of the various signaling protocols developed for WSJT—perhaps in completely independent programs, or perhaps in new programs that might begin with some or
all of the code base of WSJT, but then evolve quite separately? “Open source” means thatthe program code is freely available to anyone, and may be used or modiﬁed for any purpose,as long as the same licensing conditions are passed on to all users. My personal view is thatthese possible courses of future development are all highly desirable, and would bring goodthings to our hobby in this information age. I hope that at least some of them will come topass.
9

All JT65 transmissions are timed to start on a UTC minute; the JT65B signal bandwidth is about
355 Hz.

Some good ideas for future development are already being discussed. Two members of
the present WSJT development team (KK7KA and ON/G4KLX) have some clever ideas
about protocols that could be especially eﬀective for microwave EME. Another member(N4HY) is working on an open-source version of a soft-decision Reed Solomon decoder, onethat might outperform the Koetter-Vardy algorithm now used in WSJT. I have made earlytests of a meteor-scatter mode that shows promise of signiﬁcant advantages over FSK441,
while retaining its desirable features, and also of a potential enhancement to JT65. I willcomment only brieﬂy on the latter ideas in this written paper; with good luck, some on-theair performance measurements will be available in time for oral presentation at the Würzburg
conference.
During the original design of JT65 I had in mind its possible use in terrestrial VHF/UHF
contests. I also thought it might be desirable for standard JT65 messages to include QSO
information beyond the minimal exchanges of callsigns and single-valued signal reports. After
discussion with many others I settled on including the grid locator of the transmitting stationin the basic message structure and allowing for multi-valued numerical signal reports. I alsodecided to place the majority of necessary information for a minimal valid QSO in the ﬁrst
exchanged messages—the ones containing callsigns, grid locators, and default OOO signal
reports.
The exchange of grid locators is unnecessary, and not particularly useful in EME QSOs.
They could reasonably be omitted. Further performance advantages might be gained byspreading the transmitted information more evenly over the procedural stages of a QSO.
I outlined one way of doing this in a talk at the 11th International EME Conference, twoyears ago, and received favorable responses about it then and afterward. These ideas havenow been developed further, and I am working on a possible superset of JT65 that would
accommodate them in a backward-compatible way. An up-to-date progress report on thatwork will be presented at Würzburg.

Appendix: Programmer’s Overview of WSJTWSJT is a computer program designed to facilitate Amateur Radio communication under
extreme weak-signal conditions. Three distinct coding and modulation methods are provided:
FSK441 for communication by meteor-scatter techniques on the VHF bands; JT6M for meteor andionospheric scatter, primarily on the 6 meter band; and JT65 for the very challenging Earth-MoonEarth path. Each mode uses constant-envelope, phase-continuous FSK with keying rates and total
bandwidths chosen to optimize eﬀectiveness for the diﬀerent propagation types, consistent with thelimitations of typical amateur equipment.

WSJT runs under recent versions of the Windows, Linux, and FreeBSD operating systems.
The program’s user interface is written in the elegant and freely available language called Python.
The Python code runs without changes on any supported platform, as long as the necessary modules
are installed. The remaining source code can be compiled under Windows, Linux, FreeBSD, andMacintosh OS/X. Platform-dependent versions of FFTW, PortAudio, and libsamplerate need to
be installed.
User Interface
The principal Python source-code ﬁles and their purposes include:
1. wsjt.py: Deﬁnes the main-screen graphical user interface (GUI) for user interaction; orchestrates all event-driven and time-shared activities.
2. specjt.py: Provides real-time display of received signals as two-dimensional “waterfall”
spectra, with bandwidths and scrolling rates suitable for each mode.
3. options.py: Provides entry ﬁelds for user-deﬁned parameters.
4. astro.py: Displays astronomical data for sun, moon, sky temperature, etc.
Several smaller Python ﬁles serve a number of minor utility functions.

Background Tasks
The main Python-coded procedures make calls to external routines compiled from code written
in Fortran or C. A variety of global data is shared among modules through common blocks deﬁned in
Fortran. The Python code runs in a single thread, although timers make the functions of the several
main modules appear concurrent. Fortran routines create additional threads used for soundcard
I/O and the encoding and decoding of user messages.
As a small part of its overall task, the decoder for JT65 invokes an external program named
KVASD (or KVASD.EXE) located in the main WSJT directory. If this program is present it uses
information on received 64-FSK symbols and attempts to decipher it according to a Reed Solomon(63,12) code, using the algebraic soft-decision algorithm of Koetter and Vardy3 . If KVASD is notpresent, WSJT uses its own internal hard-decision Reed Solomon decoder instead. Interprocess
communication between WSJT and KVASD takes place through a shared disk ﬁle. KVASD is
not an integral part of WSJT; its algorithm is patented, and the source code is the propertyof CodeVector Technologies, LLC. However, compiled versions of KVASD may be freely used inconjunction with WSJT for the purposes of amateur radio weak-signal communication.

Operation Sequence
WSJT execution starts at the top of Python ﬁle wsjt.py. The other Python modules areloaded and executed as needed. Fortran routines are called to start a high-priority thread that
handles continuous A/D and D/A streams, as well as a background thread for decoding received
or previously recorded signals. The top-level Python code determines the overall state of program
operation, for example “Idle,” “Monitoring,” or “Transmitting.” In normal usage the operator puts
the program into “Auto” mode, which results in a timed sequence of alternating transmission andreception intervals.

Other Open-Source Software used in WSJTWSJT 5.9 uses the following open source libraries:
1. FFTW, by Matteo Frigo and Steven Johnson, for computing Fourier transforms.
2. PortAudio, by Ross Bencina and Phil Burk, for audio I/O.
3. ALSA, “Advanced Linux Sound Architecture.” For details, see http://www.alsa-project.org/.
4. Secret Rabbit Code or libsamplerate, by Erik de Castro, for accomplishing band-limited
resampling of data.
5. RS, by Phil Karn, KA9Q, for Reed Solomon encoding and hard-decision decoding.

Partial List of Functions and Subroutines
In the following list of procedure names and descriptions, indentation gives a rough idea about
the relative dependencies of functions.
Audio initialization, message encoding, and display computations:blanker.f90
fivehz.f90
flat2.f
pix2d65.f90
pix2d.f90
runqqq.f90
wsjtgen.f90
abc441.f90

Noise blanker
Called by PortAudio callback at 5 Hz rate
Flatten the spectrum for waterfall display
Compute pixels for waterfall display
Compute pixels for waterfall display
Execute another process
Generate Tx waveforms
Part of FSK441 generator

gen65.fchkmsg.f

Generate JT65 waveform
Check a JT65 message for presence of ’OOO’

encode65.f
Encode a JT65 message
getpfx1.f
Handle extra DXCC prefixes
getpfx2.f
Handle extra DXCC prefixes
graycode.f
Convert binary to/from Gray code
grid2k.f
Convert grid locator to integerinterleave63.f Interleave JT65 symbols
nchar.f
Convert number, letter, space to 0-36
packcall.fRoutines for JT65 source encoding
packdxcc.f
Encode DXCC prefix
packgrid.f
Encode grid locator
packmsg.f
Assemble parts of a message
packtext.f
Encode a plain text message
pfx.f
List of add-on DXCC prefixes
gen6m.fgentone.f
gencw.fmorse.f
gencwid.f
gcom1.f90
gcom2.f90
gcom3.f90
gcom4.f90

Generate JT6M waveform
Generate tone for JT6M message
Generate CW waveform
Convert ascii to morse dits
Generate a CW ID message
Global variables shared among Fortran, Python,and C routines

Astronomical calculations:astro.fazdist.fcoord.fdcoord.f
deg2grid.f
dot.f
ftsky.f
geocentric.f
GeoDist.f
grid2deg.f
moon2.f
MoonDop.f
sun.f
toxyz.f

Computes Az, El, Doppler for Sun, Moon, etc.
Computes azimuth, distance, etc., between two locators
Spherical trig utility
Spherical trig utility in double precision
Convert lat/long (degrees) to grid locator
Compute dot productGet sky temperature from data file
Convert geodetic to geocentric coords
Compute azimuth and distance between two locators
Convert grid locator to lat/long
Compute moon location at specified date and time
Compute lunar doppler shift and related quantities
Compute sun location at specified date and time
Convert from polar to cartesian coordinates

General Utilities:
db.f
igray.f

Compute decibels from ratio
Gray code

indexx.f
set.f
pctile.frfile2.fsort.fcutil.c

Sort routineMove, add, zero, ...
Sort an array and get specified percentile
Read a binary file
Sort an array
Fortran wrappers for some basic C functions

FFTs:
fftw3.ffour2a.ffour2.f
ps.f
xfft.fxfft2.f

Fortran definitions for FFTW
Wrapper to make FFTW look like four2
FFT in FortranCompute power spectrum
Real to complex FFT wrapper
Real to complex FFT wrapper

Decoding Routines:
wsjt1.f
avesp2.fbzap.fdetect.fflatten.flongx.f
lpf1.fmtdecode.f
ping.fs2shape.fsmooth.f
spec2d.f
stdecode.f
sync.fTop-level decoding routine; handles FSK441 especially
Computes average spectrum
Find and remove birdies
Measure power in FSK441 tones
Flatten the spectrum
Decode normal FSK441 messages
Quick-and-dirty lowpass filter
Multi-tone decoding
Find pings
Flatten the 2d spectrum
Smooth by boxcar averaging
Compute 2d spectrum for FSK441
Decode FSK441 shorthand messages
Synchronize FSK441 data

wsjt65.f
afc65.favemsg65.f
decode65.f
deep65.f
demod64a.f
extract.f
flat1.fgetsnr.fk2grid.flimit.f
peakup.f

JT65 decoder
AFC for JT65
Decode average message
Decode JT65 message
Deep search decoder
Compute probabilities of transmitted symbols
Extract message from JT65 symbol probabilities
Flatten the passband
Compute snr or shorthand message
Convert integer to 4-digit grid locator
Clipper for JT65
Interpolate to find fractional-bin peak

setup65.f
short65.f
slope.f
spec2d65.f
spec441.f
sync65.f
unpackcall.f
unpackgrid.f
unpackmsg.f
unpacktext.f
xcor.fdecode6m.f
syncf0.f
syncf1.fsynct.favemsg6m.f
JT65code.f

Initialize pseudorandom sync vector
Detect JT65 shorthand messages
Remove a straight-line slope
Compute 2d spectrum for JT65
Compute spectra for FSK441 decoding
Synchronize a JT65 signal
Unpack callsign
Unpack grid locator
Unpack a JT65 message
Unpack a plain text message
Compute cross-correlation for JT65 sync
Decode a JT6M signal
First frequency sync
Second freq sync
First time sync
Get average JT65 message
Example program to illustrate and test JT65
coding and decoding

Hard-Decision Reed Solomon encoder and decoder:decode_rs.c
encode_rs.c
init_rs.c
wrapkarn.c

Karn’s RS decoder
Karn’s RS encoder
Initialization routine
Wapper for FortranC Functions for Audio and T/R switching:jtaudio.c
padevsub.c
ptt.c
ptt_linux.c
resample.c
start_alsa.c
start_threads.c

Audio I/O, calls PortAudio routines
Select desired audio device
PTT via serial port DTR/RTS
PTT via serial or parallel ports (*nix)
Wrapper for resample routine
Start audio streams using ALSA
Start audio and decoder threads