w4kek/WSJT-X
1
0
Fork 0
mirror of https://github.com/saitohirga/WSJT-X.git synced 2024-11-25 13:48:42 -05:00
Code Issues Packages Projects Releases Wiki Activity

Editorial work by Dave, KC3GPM.

Browse Source
This commit is contained in:
Joe Taylor 2020-07-14 13:45:32 -04:00
parent bdc3ebddcc
commit 4213e02905
1 changed files with 23 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

45
doc/user_guide/en/decoder_notes.adoc
View File

@ -1,19 +1,21 @@
[[AP_Decoding]]
// Status: edited
=== AP Decoding
The _WSJT-X_ decoders for FT4, FT8, JT65, and QRA64 include optional
procedures that take advantage of naturally accumulating information
during a minimal QSO. This _a priori_ (AP) information increases
sensitivity of the decoder by up to 4 dB, at the cost of a slightly
higher rate of false decodes.
The _WSJT-X_ decoders for FT4, FT8, JT65, QRA64, include
procedures that use naturally accumulating information during a
minimal QSO. This _a priori_ (AP) information increases sensitivity
of the decoder by up to 4 dB, at the cost of a slightly higher rate of
false decodes. AP is optional in FT8, JT65, and QRA64, but is always
enabled for FT4.
For example: when you decide to answer a CQ, you already know your own
callsign and that of your potential QSO partner. The software
therefore "`knows`" what might be expected for at least 57 message
bits (28 for each of two callsigns, 1 or more for message type) in the
next received message. The decoder's task can thus be reduced to
bits (28 for each of two callsigns, one or more for message type) in the
next received message. The decoder's task is thus reduced to
determining the remaining 15 bits of the message and ensuring that the
resulting solution is consistent with the message's parity symbols.
resulting solution is reliable.
AP decoding starts by setting AP bits to the hypothesized values, as
if they had been received correctly. We then determine whether the
@ -21,12 +23,12 @@ remaining message and parity bits are consistent with the hypothesized
AP bits, with a specified level of confidence. Successful AP decodes
are 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, `a2` indicates that the successful decode used *MyCall* as
example, `a2` indicates that the successful decode used MyCall as
hypothetically known information.
[[FT8_AP_INFO_TABLE]]
.FT4 and FT8 AP information types
[width="50%",cols="h10,<m20",frame=topbot,options="header"]
[width="35%",cols="h10,<m20",frame=topbot,options="header"]
|===============================================
|aP | Message components
|a1 | CQ &#160; &#160; ? &#160; &#160; ?
@ -49,7 +51,7 @@ be attempted in each state.
[[FT8_AP_DECODING_TYPES_TABLE]]
.FT4 and FT8 AP decoding types for each QSO state
[width="50%",cols="h10,<m20",frame=topbot,options="header"]
[width="35%",cols="h10,<m20",frame=topbot,options="header"]
|===========================================
|State |AP type
|CALLING STN | 2, 3
@ -60,14 +62,12 @@ be attempted in each state.
|CALLING CQ | 1, 2
|===========================================
Decoding with _a priori_ information behaves slightly differently in
JT65. Some details are provided in Tables 3 and 4. Notations such as
`a63`, use a second digit to indicate the number of Rx intervals
averaged to obtain the decode.
Decoding with _a priori_ information behaves slightly differently
in JT65. Some details are provided in Tables 3 and 4.
[[JT65_AP_INFO_TABLE]]
.JT65 AP information types
[width="50%",cols="h10,<m20",frame=topbot,options="header"]
[width="35%",cols="h10,<m20",frame=topbot,options="header"]
|===============================================
|aP | Message components
|a1 | CQ &#160; &#160; ? &#160; &#160; ?
@ -81,7 +81,7 @@ averaged to obtain the decode.
[[JT65_AP_DECODING_TYPES_TABLE]]
.JT65 AP decoding types for each QSO state
[width="50%",cols="h10,<m20",frame=topbot,options="header"]
[width="35%",cols="h10,<m20",frame=topbot,options="header"]
|===========================================
|State |AP type
|CALLING STN | 2, 3, 6, 7
@ -93,7 +93,6 @@ averaged to obtain the decode.
|===========================================
[[Decoded_Lines]]
=== Decoded Lines
Displayed information accompanying decoded messages generally includes UTC,
@ -110,7 +109,7 @@ summarized in the following Table:
[width="50%",cols="h,3*^",frame=topbot,options="header"]
|===========================================
|Mode |Mode character|Sync character|End of line information
|FT4 | + | | ? &#160; aP
|FT4 | ~ | | ? &#160; aP
|FT8 | ~ | | ? &#160; aP
|JT4 | $ | *, # | f, fN, dCN
|JT9 | @ | |
@ -126,10 +125,12 @@ Sync character::
End of line information::
`?` - Decoded with lower confidence +
`a` - Decoded with aid of some a priori (AP) information +
`a` - Decoded with aid of some _a priori_ (AP) information +
`C` - Confidence indicator [ISCAT and Deep Search; (0-9,*)] +
`d` - Deep Search algorithm +
`E` - Size of MSK eye diagram opening - if negative, the eye is closed +
`f` - Franke-Taylor or Fano algorithm +
`H` - Number of bit errors corrected +
`M` - Message length (characters) +
`N` - Number of Rx intervals or frames averaged +
`P` - Number indicating type of AP information (Table 1, above) +
@ -140,7 +141,7 @@ Table 6 below shows the meaning of the return codes R in QRA64 mode.
[[QRA64_AP_INFO_TABLE]]
.QRA64 AP return codes
[width="50%",cols="h10,<m20",frame=topbot,options="header"]
[width="35%",cols="h10,<m20",frame=topbot,options="header"]
|===============================================
|rc | Message components
|0 | ? &#160; &#160; ? &#160; &#160; ?