mirror of
https://github.com/saitohirga/WSJT-X.git
synced 2024-11-25 13:48:42 -05:00
User Guide updates in preparation for pending release of v1.7.0-rc3.
git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@7344 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
This commit is contained in:
parent
8cf4fd2f8e
commit
66cd1a191e
@ -37,11 +37,13 @@ TIP: Consider reducing power if your QSO partner reports your
|
|||||||
signal above -5 dB in one of the _WSJT-X_ slow modes. These are
|
signal above -5 dB in one of the _WSJT-X_ slow modes. These are
|
||||||
supposed to be weak signal modes!
|
supposed to be weak signal modes!
|
||||||
|
|
||||||
* With *Rx frequency offset with "CQ nnn"* checked on the *Settings ->
|
* With *Split operation* activated on the *Settings -> Radio* tab, you
|
||||||
General* tab and *Split operation* activated on the *Settings ->
|
can activate the spinner control *Tx CQ nnn* by checking the box to
|
||||||
Radio* tab, you can activate the spinner control *CQ Rx nnn* by
|
its right. The program will then generate something like `CQ nnn
|
||||||
checking the box to its right. The program will then generate
|
K1ABC FN42` for your CQ message, where `nnn` is the kHz portion of
|
||||||
something like `CQ 285 K1ABC FN42` for your CQ message, and it will
|
your current operating frequency. Your CQ message *Tx6* will then be
|
||||||
handle the appropriate frequency switching between a CQ on the
|
transmitted at the calling frequency selected in the *Tx CQ nnn* spinner
|
||||||
conventional calling frequency and completing your QSO on the
|
control. All other messages will be transmitted at your current
|
||||||
specified offset frequency.
|
operating frequency. On reception, when you double-click on a message
|
||||||
|
like `CQ nnn K1ABC FN42` your rig will QSY to the specified frequency
|
||||||
|
so you can call the station at his specified response frequency.
|
||||||
|
Binary file not shown.
Before Width: | Height: | Size: 2.4 KiB After Width: | Height: | Size: 2.8 KiB |
Binary file not shown.
Before Width: | Height: | Size: 5.4 KiB After Width: | Height: | Size: 5.2 KiB |
@ -32,7 +32,7 @@ End of line information::
|
|||||||
`f` - Franke-Taylor or Fano algorithm +
|
`f` - Franke-Taylor or Fano algorithm +
|
||||||
`M` - Message length (characters) +
|
`M` - Message length (characters) +
|
||||||
`N` - Number of Rx intervals or frames averaged +
|
`N` - Number of Rx intervals or frames averaged +
|
||||||
`R` - Amount of _a priori_ information used by decoder +
|
`R` - Return code from QRA64 decoder +
|
||||||
`T` - Length of analyzed region (s)
|
`T` - Length of analyzed region (s)
|
||||||
|
|
||||||
=== Reference Spectrum
|
=== Reference Spectrum
|
||||||
|
@ -126,12 +126,11 @@ separation is 110250/4096 = 26.92 Hz multiplied by n for JT65A, with n
|
|||||||
|
|
||||||
QRA64 is an experimental mode intended for EME and other extreme
|
QRA64 is an experimental mode intended for EME and other extreme
|
||||||
weak-signal applications. Its internal code was designed by IV3NWV.
|
weak-signal applications. Its internal code was designed by IV3NWV.
|
||||||
The protocol uses a (63,12) Q-ary Repeat Accumulate code that is
|
The protocol uses a (63,12) **Q**-ary **R**epeat **A**ccumulate code
|
||||||
inherently better than the Reed Solomon (63,12) code used in JT65,
|
that is inherently better than the Reed Solomon (63,12) code used in
|
||||||
yielding a 1.3 dB advantage. A new synchronizing scheme is based on
|
JT65, yielding a 1.3 dB advantage. A new synchronizing scheme is based
|
||||||
three 7 x 7 Costas arrays. This change yields another 1.9 dB
|
on three 7 x 7 Costas arrays. This change yields another 1.9 dB
|
||||||
advantage. A few details of the QRA64 protocol are still subject to
|
advantage.
|
||||||
change, as more experience is gained.
|
|
||||||
|
|
||||||
In most respects the current implementation of QRA64 is operationally
|
In most respects the current implementation of QRA64 is operationally
|
||||||
similar to JT65. QRA64 does not use two-tone shorthand messages, and
|
similar to JT65. QRA64 does not use two-tone shorthand messages, and
|
||||||
@ -141,8 +140,7 @@ QSO progresses -- for example, when reports are being exchanged and
|
|||||||
you have already decoded both callsigns in a previous transmission.
|
you have already decoded both callsigns in a previous transmission.
|
||||||
QRA64 presently offers no message averaging capability, though that
|
QRA64 presently offers no message averaging capability, though that
|
||||||
feature may be added. In early tests, many EME QSOs were made using
|
feature may be added. In early tests, many EME QSOs were made using
|
||||||
submodes QRA64A-E on bands from 144 MHz to 10 GHz. Optimum processing
|
submodes QRA64A-E on bands from 144 MHz to 24 GHz.
|
||||||
of signals with large Doppler spread remains to be implemented.
|
|
||||||
|
|
||||||
[[SLOW_SUMMARY]]
|
[[SLOW_SUMMARY]]
|
||||||
==== Summary
|
==== Summary
|
||||||
|
@ -159,13 +159,28 @@ _WSJT-X_. The mode is designed especially for EME on VHF and higher
|
|||||||
bands; operation is generally similar to JT65. The following screen
|
bands; operation is generally similar to JT65. The following screen
|
||||||
shot shows an example of a QRA64C transmission from DL7YC recorded at
|
shot shows an example of a QRA64C transmission from DL7YC recorded at
|
||||||
G3WDG over the EME path at 24 GHz. Doppler spread on the path was 78
|
G3WDG over the EME path at 24 GHz. Doppler spread on the path was 78
|
||||||
Hz, so although the signal is reasonable strong its tones are
|
Hz, so although the signal is reasonably strong its tones are
|
||||||
broadened enough to make them hardto see on the waterfall. The red
|
broadened enough to make them hard to see on the waterfall. The red
|
||||||
curve shows that the decoder has achieved synchronization with a
|
curve shows that the decoder has achieved synchronization with a
|
||||||
signal at about 970 Hz.
|
signal at approximately 967 Hz.
|
||||||
|
|
||||||
image::QRA64.png[align="center",alt="QRA64"]
|
image::QRA64.png[align="center",alt="QRA64"]
|
||||||
|
|
||||||
|
The QRA64 decoder makes no use of a callsign database. Instead, it
|
||||||
|
takes advantage of _a priori_ (already known) information such as the
|
||||||
|
one's own callsign and the encoded form of message word `CQ`. In
|
||||||
|
normal usage, as a QSO progresses the available _a priori_ (AP)
|
||||||
|
information increases to include the callsign of the station being
|
||||||
|
worked and perhaps also his/her 4-digit grid locator. The decoder
|
||||||
|
always begins by attempting to decode the full message using no AP
|
||||||
|
information. If this attempt fails, additional attempts are made
|
||||||
|
using available AP information to provide initial hypotheses about the
|
||||||
|
message content. At the end of each iteration the decoder computes
|
||||||
|
the extrinsic probability of the most likely value for each of the
|
||||||
|
message's 12 six-bit information symbols. A decode is declared only
|
||||||
|
when the total probability for all 12 symbols has converged to an
|
||||||
|
unambiguous value very close to 1.
|
||||||
|
|
||||||
=== ISCAT
|
=== ISCAT
|
||||||
|
|
||||||
ISCAT is a useful mode for signals that are weak but more or less
|
ISCAT is a useful mode for signals that are weak but more or less
|
||||||
|
Loading…
Reference in New Issue
Block a user