Many more additions to the WSJT-X User Guide.

git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@7228 ab8295b8-cf94-4d9e-aec4-7959e3be5d79

doc/CMakeLists.txt

@@ -36,6 +36,7 @@ set (UG_SRCS
   make-qso.adoc
   new_features.adoc
   platform-dependencies.adoc
+  protocols.adoc
   settings-advanced.adoc
   settings-audio.adoc
   settings-colors.adoc
@@ -71,7 +72,11 @@ set (UG_IMGS
   images/help-menu.png
   images/JT4F.png
   images/JT65B.png
+  images/MSK144.png
   images/QRA64.png
+  images/WSPR_WideGraphControls.png
+  images/WSPR_1a.png
+  images/WSPR_2.png
   images/jtalert.png
   images/keyboard-shortcuts.png
   images/log-qso.png

doc/user_guide/en/acknowledgements.adoc

@@ -1,17 +1,19 @@
 // Status=review
 
-Since 2005 the _WSJT_ project (including programs _WSJT_, _MAP65_,
-_WSPR_, _WSJT-X_, and _WSPR-X_) has been "`open source`", with all
-code licensed under the GNU Public License (GPL).  Many users of these
-programs, too numerous to mention here individually, have contributed
-suggestions and advice that have greatly aided the development of
-_WSJT_ and its sister programs.
+The _WSJT_ project was started in 2001.  Since 2005 it has been an
+Open Source project, and it now includes programs _WSJT_, _MAP65_,
+_WSPR_, _WSJT-X_, and _WSPR-X_.  All all code is licensed under the
+GNU Public License (GPL).  Many users of these programs, too numerous
+to mention here individually, have contributed suggestions and advice
+that have greatly aided the development of _WSJT_ and its sister
+programs.
 
 For _WSJT-X_ in particular, we acknowledge contributions from *AC6SL,
-AE4JY, DJ0OT, G4KLA, G4WJS, K3WYC, K9AN, KA6MAL, KA9Q, KB1ZMX, KD6EKQ,
-KI7MT, KK1D, ND0B, PY2SDR, VK3ACF, VK4BDJ, W4TI, W4TV, and W9MDB*.
-Each of these amateurs has helped to bring the program’s design, code,
-and documentation to its present state.
+AE4JY, DJ0OT, G3WDG, G4KLA, G4WJS, IV3NWV, IW3RAB, K3WYC, K9AN,
+KA6MAL, KA9Q, KB1ZMX, KD6EKQ, KI7MT, KK1D, ND0B, PY2SDR, VK3ACF,
+VK4BDJ, VK7MO, W4TI, W4TV, and W9MDB*.  Each of these amateurs has helped to
+bring the program’s design, code, tetsting, and/or documentation to
+its present state.
 
 Most of the color palettes for the _WSJT-X_ waterfall were copied from
 the excellent, well documented, open-source program _fldigi_, by *W1HKJ*

doc/user_guide/en/astro_data.adoc

@@ -1,25 +1,26 @@
 A text box entitled Astronomical Data provides information needed for
 tracking the sun or moon, moon, compensating for EME Doppler shift,
 and estimating EME Doppler spread and path degradation. Toggle the
-*Astronomical data* on the *View* menu to display or remove this window.
+*Astronomical data* on the *View* menu to display or hide this window.
 
 image::AstroData_2.png[align="center",alt="Astronomical Data"]
 
-Available information includes the current *Date* and *UTC* time; *Az*
+Available information includes the current UTC *Date* and time; *Az*
 and *El*, azimuth and elevation of the moon at your own location, in
 degrees; *SelfDop*, *Width*, and *Delay*, the Doppler shift, full
-limb-to-limb Doppler spread, and delay of your own EME echoes; and
-*DxAz* and *DxEl*, *DxDop*, and *DxWid*, corresponding parameters for
-a station located at the DX Grid entered on the main window.  These
-numbers are followed by *Dec*, the declination of the moon; *SunAz*
-and *SunEl*, the azimuth and elevation of the Sun; *Freq*, your stated
-operating frequency in MHz; *Tsky*, the estimated sky background
-temperature in the direction of the moon, scaled to the operating
-frequency; *Dpol*, the spatial polarization offset in degrees; *MNR*,
-the maximum non-reciprocity of the EME path in dB, owing to spatial
-polarization; and finally *Dgrd*, an estimate of the signal
-degradation in dB, relative to the best possible time with the moon 
-at perigee in a cold part of the sky.
+limb-to-limb Doppler spread in Hz, and delay of your own EME echoes in
+seconds; and *DxAz* and *DxEl*, *DxDop*, and *DxWid*, corresponding
+parameters for a station located at the *DX Grid* entered on the main
+window.  These numbers are followed by *Dec*, the declination of the
+moon; *SunAz* and *SunEl*, the azimuth and elevation of the Sun;
+*Freq*, your stated operating frequency in MHz; *Tsky*, the estimated
+sky background temperature in the direction of the moon, scaled to the
+operating frequency; *Dpol*, the spatial polarization offset in
+degrees; *MNR*, the maximum non-reciprocity of the EME path in dB,
+owing to a combination of Faraday rotation and spatial polarization;
+and finally *Dgrd*, an estimate of the signal degradation in dB,
+relative to the best possible time with the moon at perigee in a cold
+part of the sky.
 
 The state of the art for establishing three-dimensional locations of
 the sun, moon, and planets at a specified time is embodied in a
@@ -30,11 +31,12 @@ example, the celestial coordinates of the moon or a planet can be
 determined at a specified time to within about 0.0000003 degrees. The
 JPL ephemeris tables and interpolation routines have been incorporated
 into _WSJT-X_.  Further details on accuracy, especially concerning
-calculated EME Doppler shifts, are described in 
+calculated EME Doppler shifts, are described in QEX (###reference to
+come###).
 
 The sky background temperatures reported by _WSJT-X_ are derived from
 the all-sky 408 MHz map of Haslam et al. (Astronomy and Astrophysics
-Supplement Series, 47, 1, 1982), scaled by frequency to the (-2.6)
+Supplement Series, 47, 1, 1982), scaled by frequency to the -2.6
 power. This map has angular resolution of about 1 degree, and of
 course most amateur EME antennas have much broader beamwidths than
 this. Your antenna will therefore smooth out the hot spots

doc/user_guide/en/controls-functions-center.adoc

@@ -29,11 +29,10 @@ Tx=Rx* checked, your own Tx frequency will move around following your
 callers.
 
 * The *Report* control lets you change a signal report that has been
-inserted automatically. Most reports will fall in the range –26 to +10
-dB.  Remember that JT65 reports saturate at an upper limit of -1
-dB.
+inserted automatically. Typical reports for the various modes fall in
+the range –30 to +20 dB.  Remember that JT65 reports saturate at an
+upper limit of -1 dB.
 
 IMPORTANT: Consider reducing power if your QSO partner reports your
-signal above -5 dB.  The WSJT modes are supposed to be weak signal
-modes!
-
+signal above -5 dB in one of the _WSJT-X_ slow modes.  These are
+supposed to be weak signal modes!

doc/user_guide/en/controls-functions-left.adoc

@@ -15,15 +15,14 @@ you must tune the radio manually.
 
 * Alternatively, you can enter a frequency (in MHz) or band name in
 recognized ADIF format, for example 630m, 20m, or 70cm.  The band-name
-format works only if a working frequency has been set up on that band,
-in which case the first working frequency on that band is
-selected. 
+format works only if a working frequency has been set for that band
+and mode, in which case the first such match is selected.
 
-* If you are using CAT control, a small colored circle appears in
-green if the CAT control is activated and functional.  The green
-circle contains the character S if the rig is detected to be in
-*Split* mode.  The circle becomes red if you have requested CAT
-control but communication with the radio has been lost.
+* A small colored circle appears in green if the CAT control is
+activated and functional.  The green circle contains the character S
+if the rig is detected to be in *Split* mode.  The circle becomes red
+if you have requested CAT control but communication with the radio has
+been lost.
 
 IMPORTANT: Many Icom rigs cannot be queried for split status, current
 VFO or split transmit frequency.  Consequently you should not change

doc/user_guide/en/controls-functions-main-window.adoc

@@ -19,37 +19,37 @@ image::log-qso.png[align="center",alt="Log QSO"]
 freeze the waterfall or open and explore a previously recorded audio
 file.
 
-* *Monitor* restarts normal receive operation.  This button is
-highlighted in green when the _WSJT-X_ is receiving.  If you are
+* *Monitor* toggles normal receive operation on or off.  This button
+is highlighted in green when the _WSJT-X_ is receiving.  If you are
 using CAT control, toggling *Monitor* OFF relinquishes control of the
-rig; if _Monitor returns to last used frequency_ is selected
-on the *Settings | General* tab, toggling *Monitor* back ON will
-return to the original frequency.
+rig; if *Monitor returns to last used frequency* is selected on the
+*Settings | General* tab, toggling *Monitor* back ON will return to
+the original frequency.
 
 * *Erase* clears the right-hand decoded text window. 
 Double-clicking *Erase* clears both text windows.
 
 * *Clear Avg* is present only in modes that support message averaging.
-It provides a way to erase all previous decode information, thus
+It provides a way to erase the accumulating information, thus
 preparing to start a new average.
 
 * *Decode* tells the program to repeat the decoding procedure at the
 Rx frequency (green marker on waterfall scale), using the most recently
 completed sequence of received data.  
 
-* *Enable Tx* toggles the program into automatic T/R sequencing mode
-and highlights the button in red.  A transmission will start at
+* *Enable Tx* toggles automatic T/R sequencing mode on or off and
+highlights the button in red when ON.  A transmission will start at
 the beginning of the selected (odd or even) sequence, or immediately
-if appropriate.  Toggling the button a second time will remove the
-highlighted background color and 
+if appropriate.  Toggling the button to OFF during a transmission
+allows the current transmission to finish.
 
-* *Halt Tx* terminates a transmission in progress and disables
+* *Halt Tx* terminates a transmission immediately and disables
 automatic T/R sequencing.
 
-* *Tune* may be used to switch into Tx mode and generate an
-unmodulated carrier at the specified Tx frequency (red marker on
-waterfall scale).  This process may be useful for adjusting an antenna
-tuner.  The button is highlighted in red while *Tune* is active.
+* *Tune* toggles the program into Tx mode and generates an unmodulated
+carrier at the specified Tx frequency (red marker on waterfall scale).
+This process is useful for adjusting an antenna tuner or tuning an
+amplifier.  The button is highlighted in red while *Tune* is active.
 Toggle the button a second time or click *Halt Tx* to terminate the
 *Tune* process.  Note that activating *Tune* interrupts a receive
 sequence and will prevent decoding during that sequence.

doc/user_guide/en/controls-functions-menus.adoc

@@ -1,9 +1,9 @@
 // Status=review
 
-Program menus offer many options for configuration and operation.
-Most of the items are self-explanatory; a few additional details are
-provided below.  Keyboard shortcuts for some frequently used menu
-items are listed at the right.
+Menus at top of the main window offer many options for configuration
+and operation.  Most of the items are self-explanatory; a few
+additional details are provided below.  Keyboard shortcuts for some
+frequently used menu items are listed at the right edge of the menu.
 
 ==== WSJT-X menu
 image::MacAppMenu.png[align="left",alt="Mac App Menu"]
@@ -37,10 +37,6 @@ image::decode-menu.png[align="left",alt="Decode Menu"]
 ==== Save Menu
 image::save-menu.png[align="left",alt="Save Menu"]
 
-Choose *Save all* to save received data as audio +.wav+ files.
-*Save decoded* will save only those files containing at least one 
-decoded message.  
-
 [[HELP_MENU]]
 ==== Help Menu
 image::help-menu.png[align="left",alt="Help Menu"]

doc/user_guide/en/controls-functions-status-bar.adoc

@@ -1,7 +1,7 @@
 // Status=review
 
-A *Status Bar* at the bottom edge of the main window provides
-information about operating conditions.  
+A *Status Bar* at the bottom edge of the main window provides useful
+information about operating conditions.
 
 //.Status Bar
 image::status-bar-a.png[align="left",alt="Status Bar"]

doc/user_guide/en/controls-functions-wide-graph.adoc

@@ -1,8 +1,9 @@
 // Status=review
 
 The following controls appear at the bottom of the Wide Graph window.
-With the exception of *JT65 nnnn JT9*, they affect only the graphical
-displays — they have no effect on the decoding process.
+With the exception of *JT65 nnnn JT9* (when operating in JT9+JT65
+mode), they affect only the graphical displays.  They have no effect
+on the decoding process.
 
 image::wide-graph-controls.png[align="center",alt="Wide Graph Controls"]
 
@@ -55,19 +56,21 @@ a few Hz.
 [[CONTROLS_FAST]]
 === Fast Graph
 
-Three sliders at the bottom of the Fast Graph window can be used to
-optimize gain and zero-offset of the displayed information.  Hover the
-mouse over a control to display a tip reminding you of its function.
-Clicking the *Auto Level* button will produce reasonable settings
-as a starting point.  The waterfall palette used on this graph is
-the same as the one selected on the Wide Graph.
+The waterfall palette used for the Fast Graph is the same as the one
+selected on the Wide Graph.  Three sliders at the bottom of the Fast
+Graph window can be used to optimize gain and zero-offset for the
+displayed information.  Hover the mouse over a control to display a
+tip reminding you of its function.  Clicking the *Auto Level* button
+will produce reasonable settings as a starting point.
 
 image::fast-graph-controls.png[align="center",alt="Fast Graph Controls"]
 
 [[CONTROLS_ECHO]]
 === Echo Graph
 
-Controls at the bottom of the Echo Graph
+The following controls appear at the bottom of the Echo Graph:
+
+image::echo-graph-controls.png[align="center",alt="EchoGraph Controls"]
 
 - *Bins/Pixel* controls the displayed frequency resolution.  Set this
 value to 1 for the highest possible resolution, or to higher numbers
@@ -77,12 +80,9 @@ to compress the spectral display.
 spectra.
 
 - *Smooth* values greater than 0 apply running averages to the plotted
-spectra.
+spectra, therebu smoothing the curves over multiple bins.
 
 - Label *N* shows the number of echo pulses averaged.
 
 - Click the *Colors* button to cycle through 6 possible choices of
 color and line width for the plots.
-
-image::echo-graph-controls.png[align="center",alt="EchoGraph Controls"]
-

doc/user_guide/en/logging.adoc

@@ -22,10 +22,10 @@ before`" status for this callsign (according to log file
 background color, as follows:
 
 [horizontal]
-!::  default color bright purple: -- New DXCC entity
-~::  light pink: -- You have already worked this DXCC entity but not 
+!::  Default color bright purple: New DXCC entity
+~::  Light pink: You have already worked this DXCC entity but not 
 this station
- ::  green: -- You have previously worked the calling station
+ ::  Green: You have previously worked the calling station
 
 In this respect the program does not distinguish between modes, but it
 does differentiate between bands.

doc/user_guide/en/protocols.adoc

@@ -1,45 +1,50 @@
 [[PROTOCOL_OVERVIEW]]
 === Overview
 
-All QSO modes except ISCAT benefit from the use of structured
-messages.  Each such message consists of two 28-bit fields for
-callsigns and a 15-bit field for a grid locator, report,
-acknowledgment, or a "`73`" sign-off indicator.  Alternatively, a
-72^nd^ bit flags a message containing arbitrary alphanumeric text, up
-to 13 characters.  Special formats allow other information such as
-add-on callsign prefixes (e.g., ZA/K1ABC) or suffixes (e.g., K1ABC/4)
-to be encoded. The basic aim is to compress the most common messages
-used for minimally valid QSOs into a fixed 72-bit length.  To be
-useful, this kind of lossless message compression requires use of a
-strong forward error correcting (FEC) code.  Different FEC codes are
-used for each mode.  These modes require good synchronization of time
-and frequency between transmitting and receiving stations.  As an aid
-to the decoders, each protocol includes a "`synch vector`" of known
-symbols along with the information-carrying symbols.  Generated
-waveforms for all of the _WSJT-X_ modes have continuous phase and
-a constant envelope.
+All QSO modes except ISCAT use structured messages that compress
+user-readable information into fixed-length packets of exactly 72
+bits.  Each message consists of two 28-bit fields for callsigns and a
+15-bit field for a grid locator, report, acknowledgment, or a "`73`"
+sign-off indicator.  A 72^nd^ bit flags a message containing arbitrary
+alphanumeric text, up to 13 characters.  Special cases allow other
+information such as add-on callsign prefixes (e.g., ZA/K1ABC) or
+suffixes (e.g., K1ABC/4) to be encoded. The basic aim is to compress
+the most common messages used for minimally valid QSOs into a fixed
+72-bit length.  To be useful on channels with low signal-to-noise
+ratio, this kind of lossless compression requires use of a strong
+forward error correcting (FEC) code.  Different codes are used for
+each mode.  Accurate synchronization of time and frequency is required
+between transmitting and receiving stations.  As an aid to the
+decoders, each protocol includes a "`sync vector`" of known symbols
+interspersed with the information-carrying symbols.  Generated
+waveforms for all of the _WSJT-X_ modes have continuous phase and 
+constant envelope.
+
+[[SLOW_MODES]]
+=== Slow Modes
 
 [[JT4PRO]]
-=== JT4
+==== JT4
 
 FEC in JT4 uses a strong convolutional code with constraint length
 K=32, rate r=1/2, and a zero tail. This choice leads to an encoded
 message length of (72+31) x 2 = 206 information-carrying bits.
 Modulation is 4-tone frequency-shift keying (4-FSK) at 11025 / 2520 =
 4.375 baud.  Each symbol carries one information bit (the most
-significant bit) and one synchronizing bit.  The pseudo-random sync
-vector is the following sequence:
+significant bit) and one synchronizing bit.  The two 32-bit
+polynomials used for convolutional encoding have hexadecimal values
+0xf2d05351 and 0xe4613c47, and the ordering of encoded bits is
+scrambled by an interleaver.  The pseudo-random sync vector is the
+following sequence (60 bits per line):
 
  000011000110110010100000001100000000000010110110101111101000
  100100111110001010001111011001000110101010101111101010110101
  011100101101111000011011000111011101110010001101100100011111
  10011000011000101101111010
 
-The two 32-bit polynomials used for convolutional encoding have
-hexadecimal values f2d05351 and e4613c47.
 
 [[JT9PRO]]
-=== JT9
+==== JT9
 
 FEC in JT9 uses the same strong convolutional code aa JT4: constraint
 length K=32, rate r=1/2, and a zero tail, leading to an encoded
@@ -56,7 +61,7 @@ the 9-FSK modulation for JT9A is equal to the keying rate, 1.736 Hz.
 The total occupied bandwidth is 9 × 1.736 = 15.6 Hz.
 
 [[JT65PRO]]
-=== JT65
+==== JT65
 
 A detailed description of the JT65 protocol was published in
 {jt65protocol} for September-October, 2005. A Reed Solomon (63,12)
@@ -83,64 +88,74 @@ separation is 110250/4096 = 26.92 Hz multiplied by n for JT65A, with n
 = 2, 3, 4 used to convey the messages RO, RRR, and 73.
 
 [[QRA64_PROTOCOL]]
-=== QRA64
+==== QRA64
 
 Still to come ...
 
 [[SLOW_SUMMARY]]
-=== Slow Mode Summary
+==== Summary
+
+Table 1 provides a brief summary parameters for the slow modes in
+_WSJT-X_.  Parameters K and r specify the constraint length and rate
+of the convolutional codes; n and k give the sizes of the (equivalent)
+block codes; Q is the alphabet size for the information-carrying
+channel symbols; Mod, Baud, and BW specify the modulation type, keying
+rate, and occupied bandwidth; fSync is the fraction of transmitted
+energy devoted to synchronizing symbols; TxT is the transmission
+duration, and S/N is the signal-to-noise ratio (in a 2500 Hz reference
+bandwidth) above which the probability of decoding is 50% or higher.
 
 [[SLOW_TAB]]
 .Parameters of Slow Modes
 [width="90%",cols="3h,^3,^2,^1,^2,^2,^2,^2,^2,^2",frame=topbot,options="header"]
 |===============================================================================
-|Mode  |FEC Type   |(k,n)   | Q|  Mod | Baud |BW (Hz)|fSync|TxT (s)|S/N (dB)
+|Mode  |FEC Type   |(n,k)   | Q|  Mod | Baud |BW (Hz)|fSync|TxT (s)|S/N (dB)
 |JT4A  |K=32, r=1/2|(206,72)| 2| 4-FSK| 4.375|  17.5 | 0.50| 47.1   | -23
-|JT9A  |K=13, r=1/2|(206,72)| 8| 9-FSK| 1.736|  15.6 | 0.19| 49.0   | -27
-|JT65A |RS         |(63,12) |64|65-FSK| 2.692| 177.6 | 0.50| 46.8   | -25
-|QRA64A|QRA        |(63,12) |64|64-FSK| 1.736| 111.1 | 0.25| 48.4   | -28
+|JT9A  |K=32, r=1/2|(206,72)| 8| 9-FSK| 1.736|  15.6 | 0.19| 49.0   | -27
+|JT65A |Reed Solomon|(63,12) |64|65-FSK| 2.692| 177.6 | 0.50| 46.8   | -25
+|QRA64A|Q-ary Repeat Accumulate|(63,12) |64|64-FSK| 1.736| 111.1 | 0.25| 48.4   | -26
 | WSPR |K=32, r=1/2|(162,50)| 2| 4-FSK| 1.465|   5.9 | 0.50|110.6   | -29
 |===============================================================================
 
-Frequency spacing between tones, total occupied bandwidth, and
-approximate threshold signal-to-noise ratios are given for the various
-submodes of JT4, JT9, JT65, and QRA64 in the following table:
+Submodes of the JT4, JT9, JT65, and QRA64 protocols offer wider tone
+spacings that may be desirable for channels causing significant
+Doppler spread.  Table 2 summarizes the tone spacings, bandwidths, and
+threshold sensitivities of the various submodes.
 
- Submode Spacing   BW    S/N
-           (Hz)   (Hz)    dB
- ----------------------------
- JT4A     4.375   17.5   -23
- JT4B     8.75    35.0   -22
- JT4C    17.5     70.0   -21
- JT4D    39.375  157.5   -20
- JT4E    78.75   315.0   -19
- JT4F    157.5   630.0   -18
- JT4G    315.0  1260.0   -17
+[[SLOW_SUBMODES]]
+.Parameters of Slow Submodes
+[width="50%",cols="h,3*^",frame=topbot,options="header"]
+|=====================================
+|Mode  |Tone Spacing  |BW (Hz)|S/N (dB)
+|JT4A  |4.375|  17.5  |-23
+|JT4B  |8.75 |  35.0  |-22
+|JT4C  |17.5 |  70.0  |-21
+|JT4D  |39.375| 157.5 |-20
+|JT4E  |78.75|  315.0 |-19
+|JT4F  |157.5|  630.0 |-18
+|JT4G  |315.0| 1260.0 |-17
+|JT9A  |1.736|  15.6  |-27
+|JT9B  |3.472|  15.6  |-26
+|JT9C  |6.944|  15.6  |-25
+|JT9D  |13.889|  15.6 |-24
+|JT9E  |27.778|   250 |-23
+|JT9F  |55.556|   500 |-22
+|JT9G  |111.111| 2000 |-21
+|JT9H  |222.222| 2000 |-20
+|JT65A |2.692| 177.6  |-25
+|JT65B |5.383| 355.3  |-25
+|JT65C |10.767| 710.6 |-25
+|QRA64A|1.736| 111.1  |-26
+|QRA64B|3.472| 222.2  |-26
+|QRA64C|6.944| 444.4  |-26
+|QRA64D|13.889| 888.8 |-26
+|QRA64E|27.778|1777.8 |-26
+|=====================================
 
- JT9    1.7361  15.625   -27
+[[FAST_MODES]]
+=== Fast Modes
 
- JT65A  2.6917   177.6   -25
- JT65B  5.3833   355.3   -24
- JT65C  10.767   710.6   -23
-
- QRA64A  1.736   111.1   -28?
- QRA64B  3.472   222.2   
- QRA64C  6.944   444.4
- QRA64D 13.889   888.9
- QRA64E 27.228  1777.8
-
-JT4 and JT65 signal reports are constrained to the range –1 to –30
-dB. This range is more than adequate for EME purposes, but not enough
-for optimum use at HF. S/N values displayed by the JT4 and JT65
-decoders are clamped at an upper limit –1 dB, and the S/N scale
-becomes significantly nonlinear above –10 dB.  JT9 allows signal
-reports in the range –50 to +49 dB. It manages this by taking over a
-small portion of "`message space`" that would otherwise be used for
-grid locators within 1 degree of the south pole. The S/N scale of the
-present JT9 decoder is reasonably linear (although it's not intended
-to be a precision measurement tool).
-
-=== ISCAT
+==== ISCAT
 
 ISCAT messages are free-form, up to 28 characters in length.
 Modulation is 42-tone frequency-shift keying at 11025 / 512 = 21.533
@@ -180,7 +195,15 @@ symbols in each 24, the user message +@CQ WA9XYZ+ repeats at its own
 natural length, 10 characters.  The resulting sequence is extended as
 many times as will fit into a Tx sequence.
 
-=== MSK144
+==== JT9
+
+The JT9 slow modes all use keying rate 4.375 baud.  By contrast, with
+the *Fast* setting submodes JT9E-H adjust the keying rate to match the
+increased tone spacings.  Message durations are therefore much
+shorter, and they are sent repeatedly throughout each Tx sequence.
+For details see Table 3, below.
+
+==== MSK144
 
 Standard MSK144 messages are structured in the same way as those in
 the slow modes, with a 72 bits of user information.  Forward error
@@ -219,18 +242,18 @@ adjusted to provide the flattest possible response over the range
 300Hz to 2700Hz. The maximum permissible frequency offset between you
 and your QSO partner ± 200 Hz.
 
-=== Fast Mode Summary
+==== Summary
 
 .Parameters of Fast Modes
-[width="90%",cols="3h,^3,^2,^1,^2,^2,^2,^2,^2,^2",frame="topbot",options="header"]
-|=============================================================================
-|Mode     |FEC Type   |(k,n)   | Q|  Mod | Baud |BW (Hz)|fSync|TxT (s)|S/N (dB)
-|ISCAT-A  |   -       |  -     |42|42-FSK| 21.5 |  905  | 0.17| 1.176  | 
-|ISCAT-B  |   -       |  -     |42|42-FSK| 43.1 | 1809  | 0.17| 0.588  | 
-|JT9E     |K=32, r=1/2|(206,72)| 8| 9-FSK| 25.0 |  225  | 0.19| 3.400  |  
-|JT9F     |K=32, r=1/2|(206,72)| 8| 9-FSK| 50.0 |  450  | 0.19| 1.700  |  
-|JT9G     |K=32, r=1/2|(206,72)| 8| 9-FSK|100.0 |  900  | 0.19| 0.850  |  
-|JT9H     |K=32, r=1/2|(206,72)| 8| 9-FSK|200.0 | 1800  | 0.19| 0.425  |  
-|MSK144   |LDPC       |(128,72)| 2| OQPSK| 2000 | 2000  | 0.11| 0.072  | -5
-|MSK144 Sh|LDPC       |(32,16) | 2| OQPSK| 2000 | 2000  | 0.20| 0.020  | -5
-|=============================================================================
+[width="90%",cols="3h,^3,^2,^1,^2,^2,^2,^2,^2",frame="topbot",options="header"]
+|=====================================================================
+|Mode     |FEC Type   |(k,n)   | Q|  Mod | Baud |BW (Hz)|fSync|TxT (s)
+|ISCAT-A  |   -       |  -     |42|42-FSK| 21.5 |  905  | 0.17| 1.176 
+|ISCAT-B  |   -       |  -     |42|42-FSK| 43.1 | 1809  | 0.17| 0.588 
+|JT9E     |K=32, r=1/2|(206,72)| 8| 9-FSK| 25.0 |  225  | 0.19| 3.400 
+|JT9F     |K=32, r=1/2|(206,72)| 8| 9-FSK| 50.0 |  450  | 0.19| 1.700 
+|JT9G     |K=32, r=1/2|(206,72)| 8| 9-FSK|100.0 |  900  | 0.19| 0.850 
+|JT9H     |K=32, r=1/2|(206,72)| 8| 9-FSK|200.0 | 1800  | 0.19| 0.425 
+|MSK144   |LDPC       |(128,72)| 2| OQPSK| 2000 | 2000  | 0.11| 0.072 
+|MSK144 Sh|LDPC       |(32,16) | 2| OQPSK| 2000 | 2000  | 0.20| 0.020 
+|=====================================================================

doc/user_guide/en/vhf-features.adoc

@@ -157,22 +157,23 @@ QRA64 is an experimental mode in the Version 1.7 alpha release of
 _WSJT-X_.  Some details of the protocol are still subject to change,
 and some features of the decoder will almost surely change.  In most
 ways you will find operation of QRA64 similar to JT65.  The following
-screen shot shows examples of QRA64A transmissions recorded over the
-EME path at 144 MHz (G4SWX transmitting to K1JT) and 10 GHz (VK7MO
-transmitting to G3WDG).  Notice the small red curve plotted below
-frequency 1000 Hz in the Wide Graph.  Even though the VK7MO signal is
-scarcely visible in the waterfall, the red curve shows that the
-decoder has accurately and reliably detected its synchronizing
-symbols.
+screen shot shows examples of two QRA64A transmissions recorded over
+the EME path.  The first (at 1554 UTC) shows G4SWX transmitting to
+K1JT at 144 MHz; the second shows VK7MO transmitting to G3WDG at 10
+GHz.  Notice the small red curve plotted below frequency 1000 Hz in
+the Wide Graph.  Even though the VK7MO signal is hard to discern in
+the waterfall, the red curve shows that the decoder has accurately and
+reliably detected its synchronizing symbols, and the decode is
+successful.
 
 image::QRA64.png[align="center",alt="QRA64"]
 
 === ISCAT
 
 ISCAT is a useful mode for signals that are weak but more or less
-steady in amplitude, at least for several seconds.  Aircraft scatter
+steady in amplitude over several seconds or longer.  Aircraft scatter
 at 10 GHz is a good example.  ISCAT messages are free-format and may
-have any length from 1 to 28 characters.  The protocol includes no
+have any length from 1 to 28 characters.  This protocol includes no
 error-correction facility.
 
 === MSK144
@@ -180,12 +181,20 @@ error-correction facility.
 Meteor-scatter QSOs can be made any time on the VHF bands at distances
 up to about 2100 km (1300 miles).  Completing a QSO takes longer in
 the evening than in the morning, longer at higher frequencies, and
-longer at distances close to the upper limit.  But with patience, 
-100 Watts or more, and a single yagi it can usually be done.
+longer at distances close to the upper limit.  But with patience, 100
+Watts or more, and a single yagi it can usually be done.  The
+following screen shot shows two 15-second MSK144 transmissions from
+W5ADD during a 50 MHz QSO with K1JT, at a distance of about 1800 km
+(1100 mi).  The decoded segments have been encircled on the *Fast
+Graph* spectral display.
 
-Unlike other _WSJT-X modes, MSK144 decodes received signals in real
-time.  Decoded messages will appear on your screen almost as soon as
-you hear them.
+image::MSK144.png[align="center",alt="MSK144"]
+
+Unlike other _WSJT-X modes, MSK144 decodes signals in real time,
+during the reception sequence.  Decoded messages will appear on your
+screen almost as soon as you hear them.
+
+To configure _WSJT-X_ for MSK144 operation:
 
 - Select *MSK144* from the *Mode* menu.
 
@@ -198,39 +207,48 @@ you hear them.
 - Set the *T/R* sequence duration to 15 s.
 
 - To match decoding depth to your computer's capability, click
-*Monitor* (if it's not already green) to start a receiving sequence
-and observe the percentage of CPU usage displayed on the _Receiving_
-label in the Status Bar:
+*Monitor* (if it's not already green) to start a receiving sequence.
+Observe the percentage of CPU usage displayed on the _Receiving_ label
+in the Status Bar:
 
 image::Rx_pct_MSK144.png[align="center",alt="MSK144 Percent CPU"]
 
 - The displayed number (here 17%) indicates the fraction of CPU
-capability used being used by the MSK144 real-time decoder.  If it is
-well below 100% you may increase the decoding depth from *Fast*
-to *Normal* or *Deep*, and increase *F Tol* from 100 to 200 Hz.
+capability being used by the MSK144 real-time decoder.  If it is well
+below 100% you may increase the decoding depth from *Fast* to *Normal*
+or *Deep*, and increase *F Tol* from 100 to 200 Hz.
 
 IMPORTANT: Most modern multi-core computers can easily handle the
-optimum parameters *Deep* and *F Tol 200*.  Slower machines may not be
-able to keep up at these settings; in that case there will be a modest
-loss in decoding capability for the weakest pings.
+optimum parameters *Deep* and *F Tol 200*.  Older and slower machines
+may not be able to keep up at these settings; in that case there will
+be a modest loss in decoding capability for the very weakest pings.
 
-- T/R sequences of 15 seconds or less requires choosing your
+- T/R sequences of 15 seconds or less requires selecting your
 transmitted messages very quickly.  Check *Auto Seq* to have the
-computer make the necessary decisions automatically, based on received
-messages.
+computer make the necessary decisions automatically, based on the
+messages received.
 
-For operation at 144 MHz or above you may find it helpful to use
-short-format messages for Tx3, Tx4, and Tx5.  These messages are 20 ms
-long, compared with 72 ms for full-length MSK144 messages.  Their
-information content is a 12-bit hash of the two callsigns, rather than
-the callsigns themselves, plus a 4-bit report, acknowledgment, or
-sign-off.  Only the intended recipient can decode short-messages.
+- For operation at 144 MHz or above you may find it helpful to use
+short-format *Sh* messages for Tx3, Tx4, and Tx5.  These messages are
+20 ms long, compared with 72 ms for full-length MSK144 messages.
+Their information content is a 12-bit hash of the two callsigns,
+rather than the callsigns themselves, plus a 4-bit numerical report,
+acknowledgment (RRR), or sign-off (73).  Only the intended recipient
+can decode short-messages.  They will be displayed with the callsigns
+enclosed in <> angle brackets, as in the following model QSO
+
+ CQ K1ABC FN42
+                    K1ABC W9XYZ EN37
+ W9XYZ K1ABC +02
+                    <K1ABC W9XYZ> R+03
+ <W9XYZ K1ABC> RRR
+                    <K1ABC W9XYZ> 73
 
-- Check *Sh* to enable short messages.
 
 IMPORTANT: There is little or no advantage to using MSK144 *Sh*
-messages at 50 or 70 MHz.  At these frequencies most pings are long
-enough to support standard messages.
+messages at 50 or 70 MHz.  At these frequencies, most pings are long
+enough to support standard messages -- which have the advantage of
+being readable by anyone listening in.
 
 === Echo Mode
 
@@ -260,7 +278,8 @@ using either *Rig* or *Fake It* on the *Settings | Radio* tab.
 cycles.
 
 - _WSJT-X_ calculates and compensates for Doppler shift automatically.
-Your return echo should always appear at the center of the plot area
-on the Echo Graph window, as in the screen shot below.
+As shown in the screen shot below, when proper Doppler corrections
+have been applied your return echo should always appear at the center
+of the plot area on the Echo Graph window.
 
 image::echo_144.png[align="center",alt="Echo 144 MHz"]

doc/user_guide/en/wspr.adoc

@@ -2,9 +2,9 @@
 reconfigure itself to the WSPR interface, removing some controls not
 used in WSPR mode.
 
-- Configure the Wide Graph as suggested in the screen shot below.
+- Set the Wide Graph controls as suggested below.
 
-image::WSPR.png[align="center",alt="WSPR mode"]
+image::WSPR_WideGraphControls.png[align="center",alt="WSPR_WideGraphControls"]
 
 - Use the mouse to drag the width and height of the main window to the
 desired size.
@@ -67,6 +67,23 @@ _WSJT-X_ tries to execute the command
  user_hardware nnn 
 
 - In the above command +nnn+ is the band-designation wavelength in
-meters. You will need to write your own program, script, or batch file
-to do the necessary switching at your station.
+meters. You must write your own program, script, or batch file to do
+the necessary switching at your station.
 
+The following screen shot is an example of WSPR operation with
+band-hopping enabled:
+
+image::WSPR_2.png[align="center",alt="WSPR_2"]
+
+A careful look at the screen shot above illustrates some of the
+impressive capabilities of the WSPR decoder.  For example, look at the
+decodes at UTC 0152, 0154, and 0156 along with the corresponding
+minutes from the waterfall display below.  Yellow ovals have been
+added to highlight two isolated signals decoded at -28 and -29 dB in
+the first and third two-minute interval.  At 0154 UTC signals from
+VE3FAL, AB4QS, and K5CZD fall within a 5 Hz interval near audio
+frequency 1492 Hz; similarly, K3FEF, DL2XL/P, and LZ1UBO fall within
+a 6 Hz interval near 1543 Hz.  Each of the overlapping signals is
+decoded flawlessly.
+
+image::WSPR_1a.png[align="center",alt="WSPR_1a"]