WSJT-X/doc/user_guide/en/introduction.adoc

// Status=review

_WSJT-X_ is a computer program designed to facilitate basic amateur
radio communication using very weak signals. The first four letters in
the program name stand for "`**W**eak **S**ignal communication by
K1**JT**,`" while the suffix "`-X`" indicates that _WSJT-X_ started as
an extended and experimental branch of the program
_WSJT_.

_WSJT-X_ Version 1.9 offers nine different protocols or modes: *FT8*,
*JT4*, *JT9*, *JT65*, *QRA64*, *ISCAT*, *MSK144*, *WSPR*, and *Echo*.
The first five are designed for making reliable QSOs under extreme
weak-signal conditions. They use nearly identical message structure
and source encoding.  JT65 and QRA64 were designed for EME
("`moonbounce`") on the VHF/UHF bands and have also proven very
effective for worldwide QRP communication on the HF bands.  QRA64 has
a number of advantages over JT65, including better performance on the
very weakest signals.  We imagine that over time it may replace JT65
for EME use.  JT9 was originally designed for the LF, MF, and lower HF
bands.  Its submode JT9A is 2 dB more sensitive than JT65 while using
less than 10% of the bandwidth.  JT4 offers a wide variety of tone
spacings and has proven highly effective for EME on microwave bands up
to 24 GHz.  These four "`slow`" modes use one-minute timed sequences
of alternating transmission and reception, so a minimal QSO takes four
to six minutes — two or three transmissions by each station, one
sending in odd UTC minutes and the other even.  FT8 is operationally
similar but four times faster (15-second T/R sequences) and less
sensitive by a few dB.  On the HF bands, world-wide QSOs are possible
with any of these modes using power levels of a few watts (or even
milliwatts) and compromise antennas.  On VHF bands and higher, QSOs
are possible (by EME and other propagation types) at signal levels 10
to 15 dB below those required for CW.

*ISCAT*, *MSK144*, and optionally submodes *JT9E-H* are "`fast`"
protocols designed to take advantage of brief signal enhancements from
ionized meteor trails, aircraft scatter, and other types of scatter
propagation. These modes use timed sequences of 5, 10, 15, or 30 s
duration.  User messages are transmitted repeatedly at high rate (up
to 250 characters per second, for MSK144) to make good use of the
shortest meteor-trail reflections or "`pings`".  ISCAT uses free-form
messages up to 28 characters long, while MSK144 uses the same
structured messages as the slow modes and optionally an abbreviated
format with hashed callsigns.  

*WSPR* (pronounced "`whisper`") stands for **W**eak **S**ignal
**P**ropagation **R**eporter.  The WSPR protocol was designed for probing
potential propagation paths using low-power transmissions. WSPR
messages normally carry the transmitting station’s callsign, grid
locator, and transmitter power in dBm, and they can be decoded at
signal-to-noise ratios as low as -28 dB in a 2500 Hz bandwidth.  WSPR
users with internet access can automatically upload reception
reports to a central database called {wsprnet} that provides a mapping
facility, archival storage, and many other features.

*Echo* mode allows you to detect and measure your own station's echoes
from the moon, even if they are far below the audible threshold.

_WSJT-X_ provides spectral displays for receiver passbands as wide as
5 kHz, flexible rig control for nearly all modern radios used by
amateurs, and a wide variety of special aids such as automatic Doppler
tracking for EME QSOs and Echo testing.  The program runs equally well
on Windows, Macintosh, and Linux systems, and installation packages
are available for all three platforms.

*Version Numbers:* _WSJT-X_ release numbers have major, minor, and
patch numbers separated by periods: for example, _WSJT-X_ Version
1.9.0.  Temporary "`beta`" release candidates are sometimes made in
advance of a new general-availability release, in order to obtain user
feedback.  For example, version 1.9.0-rc1, 1.9.0-rc2, etc., would
be beta releases leading up to the final release of v1.9.0.
Release candidates should be used _only_ during a short testing
period. They carry an implied obligation to provide feedback to the
program development group.  Candidate releases should not be used on
the air after a full release with the same number has been made.