// Status=review
//Needs work!
.JT9 Protocol and Implementation

JT9 is a mode designed for making minimal QSOs at LF, MF, and HF.  It
uses 72-bit structured messages that are nearly identical (at the user
level) to those in JT65.  Error control coding (ECC) uses a strong
convolutional code with constraint length K=32, rate r=1/2, and a zero
tail, leading to an encoded message length of (72+31) × 2 = 206
information-carrying bits.  Modulation is 9-FSK: eight tones are used
for data, one for synchronization.  Sixteen symbol intervals are
devoted to synchronization, so a transmission requires a total of 206
/ 3 + 16 = 85 (rounded up) channel symbols. The sync symbols are
those numbered 1, 2, 5, 10, 16, 23, 33, 35, 51, 52, 55, 60, 66, 73,
83, and 85 in the transmitted sequence. 

Each symbol lasts for 6912 sample intervals at 12000 samples per
second, or about 0.576 s.  Tone spacing of the 9-FSK modulation is
12000/6912 = 1.736 Hz, the inverse of the symbol duration.  The total
occupied bandwidth is therefore 9 × 1.736 = 15.6 Hz.  The generated
JT9 signal has continuous phase and constant amplitude.  There are no
key clicks, and the transmitter's power amplifier need not be highly
linear.

.Transmitting

Immediately before the start of a transmission WSJT-X encodes a
user’s message and computes the sequence of tones to be sent.  The
transmitted audio waveform is computed on-the-fly, using 16-bit
integer samples at a 48000 Hz rate.  The digital samples are converted
to an analog waveform in the sound card (or equivalent D/A interface).

.Receiving and Decoding

WSJT-X acquires 16-bit integer samples from the sound card at a 48000
Hz rate, and immediately downsamples the data stream to 12000 Hz.
Spectra from overlapping data segments are computed for the waterfall
display and saved at intervals of 0.188 s, half the JT9 symbol length.
As shown in screen shots earlier in this guide, a JT9 signal appears
in the *Cumulative* spectrum as a nearly rectangular shape about 16 Hz
wide.  Although there is no clearly visible “sync tone” like the one
at the low-frequency edge of a JT65 signal, by convention the nominal
frequency of a JT9 signal is taken to be that of the lowest tone, at
the left edge of the spectrum.

At the end of a reception sequence, about 50 seconds into the UTC
minute, received data samples are forwarded to the decoder.  For
operator convenience the decoder goes through its full procedure
twice: first at the selected Rx frequency, and then in the full
displayed frequency range (or in JT9+JT65 mode, the displayed range
above the blue *JT65 nnnn JT9* marker).  Decoding of clean JT9 signals
in a white-noise background starts to fail around signal-to-noise
ratio –25 dB and reaches 50% copy at -26 dB.

Each decoding pass can be described as a sequence of discrete blocks.
For those wishing to study the program’s algorithms and source code,
perhaps with an eye toward future improvements, the blocks are labeled
here with the names of functional procedures in the code.

 sync9:	    Use sync symbols to find candidate JT9 signals 
            in the specified frequency range

Then, at the frequency of each plausible candidate:

 downsam9:  Mix, filter and downsample to 16 complex 
            samples/symbol

 peakdt9:   Using sync symbols, time-align to start of JT9 symbol 
            sequence

 afc9:	    Measure frequency offset and any possible drift

 twkfreq:   Remove frequency offset and drift

 symspec2:  Compute 8-bin spectra for 69 information-carrying
            symbols, using the time- and frequency-aligned data;
            transform to yield 206 single-bit soft symbols

 interleave9: Remove single-bit symbol interleaving imposed at the
	    transmitter

 decode9:   Retrieve a 72-bit user message using the sequential
            Fano algorithm for convolutional codes


 unpackmsg: Unpack a human-readable message from the 72-bit 
            compressed format

With marginal or unrecognizable signals the sequential Fano algorithm
can take exponentially long times.  If the first step in the above
sequence finds many seemingly worthy candidate signals, and if many of
them turn out to be undecodable, the decoding loop could take a very
long time.  For this reason the decode9 step is programmed to “time
out” and report failure if it takes too long.  The choices *Fast |
Normal | Deepest* on the Decode menu provide a three-step adjustment
of this timeout limit.