mirror of
https://github.com/saitohirga/WSJT-X.git
synced 2025-08-02 14:12:27 -04:00
------------------------------------------------------------------------ r7997 | k1jt | 2017-08-03 19:18:34 +0100 (Thu, 03 Aug 2017) | 2 lines More User Guide updates. ------------------------------------------------------------------------ r7998 | bsomervi | 2017-08-04 19:03:54 +0100 (Fri, 04 Aug 2017) | 5 lines Optimize decoded text display to limit heap usage Decoded text line now use considerably less heap memory as they accumulate. This change also limits the maximum number of decode lines saved per session to 5000. ------------------------------------------------------------------------ r7999 | k1jt | 2017-08-04 19:07:23 +0100 (Fri, 04 Aug 2017) | 1 line Text and figs for User Guide on Frequency Calibration. Still need same for Reference Spectrum and Equalization. ------------------------------------------------------------------------ r8000 | bsomervi | 2017-08-04 23:00:20 +0100 (Fri, 04 Aug 2017) | 1 line Add missing MOC generated source include ------------------------------------------------------------------------ r8001 | bsomervi | 2017-08-04 23:00:35 +0100 (Fri, 04 Aug 2017) | 1 line Remove \r and \n from process stdout so Windows looks like everthing else ------------------------------------------------------------------------ git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx-1.8@8002 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
93 lines
3.8 KiB
Plaintext
93 lines
3.8 KiB
Plaintext
=== AP Decoding
|
|
|
|
With the QRA64 decoder Nico Palermo, IV3NWV, introduced a technique
|
|
for decoding with the aid of information that naturally accumulates
|
|
during a minimal QSO. This _a priori_ (AP) information can be
|
|
used to increase the sensitivity of the decoder.
|
|
|
|
When an operator decides to answer a CQ, he already knows his own
|
|
callsign and that of his potential QSO partner. He therefore knows
|
|
what to expect for at least 56 of the 72 message bits in a
|
|
standard-format response to his call. The _WSJT-X_ decoders for QRA64
|
|
and FT8 can use these AP bits to decode messages containing them with
|
|
higher sensitivity than otherwise possible.
|
|
|
|
We have implemented AP decoding in slightly different ways in QRA64
|
|
and FT8. To provide some explicit examples for users, we provide here
|
|
a brief description of the FT8 behavior.
|
|
|
|
The FT8 decoder always tries first to decode a signal without using
|
|
any AP information. If this attempt fails, and if *Enable AP* is
|
|
checked on the *Decode* menu, a second attempt hypothesizes that the
|
|
message contains callsigns MyCall and DxCall. If the QSO has
|
|
progressed to the point where signal reports have been exchanged, a
|
|
third attempt hypothesizes that the message contains the known
|
|
callsigns followed by RRR, RR73, or 73.
|
|
|
|
AP decoding attempts effectively set the AP bits to the hypothesized
|
|
values, as if they had been received perfectly. The decoder then
|
|
proceeds to determine whether the remaining message and parity bits
|
|
are consistent with the hypothesized AP bits. If a codeword is found
|
|
that the decoder judges to have high (but not overwhelmingly high)
|
|
probability of being correct, a ? character is appended when the
|
|
decoded message is displayed.
|
|
|
|
Successful AP decodes are always labeled with an end-of-line indicator
|
|
of the form aP, where P is one of the single-digit AP decoding types
|
|
listed in Table 1. For example, an a2 designator says that the
|
|
successful decode used MyCall as hypothetically known information.
|
|
|
|
[[AP_INFO_TABLE]]
|
|
.AP information types
|
|
[width="25%",cols="h10,<m20",frame=topbot,options="header"]
|
|
|===============================================
|
|
|P | Message components
|
|
|1 | CQ     ?     ?
|
|
|2 | MyCall     ?     ?
|
|
|3 | MyCall DxCall     ?
|
|
|4 | MyCall DxCall RRR
|
|
|5 | MyCall DxCall 73
|
|
|6 | MyCall DxCall RR73
|
|
|===============================================
|
|
|
|
=== Decoded Lines
|
|
|
|
Displayed information accompanying decoded messages generally includes UTC,
|
|
signal-to-noise ratio in dB, time offset DT in seconds, and
|
|
audio frequency in Hz. Some modes include additional information such
|
|
as frequency offset from nominal (DF), frequency drift (Drift or F1),
|
|
or distance (km or mi).
|
|
|
|
There may also be some cryptic characters with special meanings
|
|
summarized in the following Table:
|
|
|
|
[[DECODED_LINES_TABLE]]
|
|
.Notations used on decoded text lines
|
|
[width="50%",cols="h,3*^",frame=topbot,options="header"]
|
|
|===========================================
|
|
|Mode |Mode character|Sync character|End of line information
|
|
|FT8 | ~ | | aP
|
|
|JT4 | $ | *, # | f, fN, dNC
|
|
|JT9 | @ | |
|
|
|JT65 | # | |
|
|
|JT65 VHF| # | *, # | f, fN, dNC
|
|
|QRA64 | : | * | R
|
|
|ISCAT | | * | M N C T
|
|
|MSK144 | & | | N
|
|
|===========================================
|
|
Sync character::
|
|
`*` - Normal sync +
|
|
`#` - Alternate sync
|
|
|
|
End of line information::
|
|
`a` - Decoded with aid of some a priori (AP) information
|
|
`C` - Confidence indicator [ISCAT and Deep Search; (0-9,*)] +
|
|
`d` - Deep Search algorithm +
|
|
`f` - Franke-Taylor or Fano algorithm +
|
|
`M` - Message length (characters) +
|
|
`N` - Number of Rx intervals or frames averaged +
|
|
`P` - Number indicating type of AP information (Table 1, above) +
|
|
`R` - Return code from QRA64 decoder +
|
|
`T` - Length of analyzed region (s)
|
|
|