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 {VERSION_MAJOR}.{VERSION_MINOR} offers ten different
protocols or modes: *FT4*, *FT8*, *JT4*, *JT9*, *JT65*, *QRA64*,
*ISCAT*, *MSK144*, *WSPR*, and *Echo*.  The first six are designed for
making reliable QSOs under 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.  FT4 is
faster still (7.5 s T/R sequences) and especially well suited for
radio contesting.  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.

Note that even though their T/R sequences are short, FT4 and FT8 are
classified as slow modes because their message frames are sent
only once per transmission.

*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 -31 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
2.1.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 2.1.0-rc1, 2.1.0-rc2, etc., would
be beta releases leading up to the final release of v2.1.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.