w4kek/WSJT-X
1
0
Fork 0
mirror of https://github.com/saitohirga/WSJT-X.git synced 2026-06-05 23:44:56 -04:00
Code Issues Packages Projects Releases Wiki Activity

Merged from trunk:

Browse Source 
------------------------------------------------------------------------
r8060 | k1jt | 2017-09-01 13:51:42 +0100 (Fri, 01 Sep 2017) | 2 lines

Add a link to G3WDG doc on using QRA64 for microwave EME.

------------------------------------------------------------------------
r8061 | k1jt | 2017-09-01 17:22:19 +0100 (Fri, 01 Sep 2017) | 1 line

Fix a misspelled word.
------------------------------------------------------------------------
r8062 | bsomervi | 2017-09-01 21:10:35 +0100 (Fri, 01 Sep 2017) | 7 lines

Rationalize NA contest mode

Generic message packing and unpacking routines now understand antipode
grid contest messages.  These messages  are now recognized as standard
messages in  message response processing and  dealt with appropriately
when contest mode is selected and applicable (currently FT8 and MSK144
only).
------------------------------------------------------------------------
r8063 | bsomervi | 2017-09-01 21:43:45 +0100 (Fri, 01 Sep 2017) | 1 line

Fix issue compiling with Qt older than v5.7
------------------------------------------------------------------------
r8064 | bsomervi | 2017-09-01 22:29:02 +0100 (Fri, 01 Sep 2017) | 7 lines

Fix issues with type 2 compound calls in contest mode

Message generation in  contest mode now generates the  correct Tx3 for
type 2 calls.

"<type-2> 73"  is a free  text so  needed special handling  in message
processing.
------------------------------------------------------------------------
r8065 | bsomervi | 2017-09-01 23:22:20 +0100 (Fri, 01 Sep 2017) | 11 lines

Improved message generation for type 2 calls in contest mode

These attempt  to ensure that  a prefix is  logged by the  QSO partner
even if the compound call holder user Tx3 to tail-end a QSO.

The  type  2 message  generation  options  are largely  overridden  in
contest mode as only a few options make sense. Key is that Tx1 may use
only the base call when calling split is necessary, this requires that
both Tx3 and Tx4 have the full compound call otherwise the QSO partner
will never see the  full call until it is possibly  too late i.e. post
logging.
------------------------------------------------------------------------
r8066 | bsomervi | 2017-09-02 00:28:44 +0100 (Sat, 02 Sep 2017) | 5 lines

Fix erroneous auto stop critera for auto reply in FT8

We cannot assume that a "DE <dx-call>  <anything>" is or is not for us
so  we must  continue calling  and  risk possible  QRM. Calling  split
avoids this issue.
------------------------------------------------------------------------



git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx-1.8@8067 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
This commit is contained in:
Bill Somerville
2017-09-01 23:55:56 +00:00
parent f67ed2006e
commit b048669c02
30 changed files with 144 additions and 199 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/user_guide/en/protocols.adoc
+6 -7
View File
@@ -149,13 +149,12 @@ separation is 110250/4096 = 26.92 Hz multiplied by n for JT65A, with n
[[QRA64_PROTOCOL]]
==== QRA64
QRA64 is an experimental mode intended for EME and other extreme
weak-signal applications. Its internal code was designed by IV3NWV.
The protocol uses a (63,12) **Q**-ary **R**epeat **A**ccumulate code
that is inherently better than the Reed Solomon (63,12) code used in
JT65, yielding a 1.3 dB advantage. A new synchronizing scheme is based
on three 7 x 7 Costas arrays. This change yields another 1.9 dB
advantage.
QRA64 is intended for EME and other extreme weak-signal applications.
Its internal code was designed by IV3NWV. The protocol uses a (63,12)
**Q**-ary **R**epeat **A**ccumulate code that is inherently better
than the Reed Solomon (63,12) code used in JT65, yielding a 1.3 dB
advantage. A new synchronizing scheme is based on three 7 x 7 Costas
arrays. This change yields another 1.9 dB advantage.
In most respects the current implementation of QRA64 is operationally
similar to JT65. QRA64 does not use two-tone shorthand messages, and
doc/user_guide/en/vhf-features.adoc
+11 -11
View File
@@ -158,15 +158,14 @@ image::JT65B.png[align="center",alt="JT65B"]
=== QRA64
QRA64 is an experimental mode in Version 1.8 of _WSJT-X_. The mode is
designed especially for EME on VHF and higher bands; its operation is
generally similar to JT4 and JT65. The following screen 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 Hz, so although
the signal is reasonably strong its tones are broadened enough to make
them hard to see on the waterfall. The triangular red marker below
the frequency scale shows that the decoder has achieved
synchronization with a signal at approximately 967 Hz.
QRA64 is designed for EME on VHF and higher bands; its
operation is generally similar to JT4 and JT65. The following screen
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
Hz, so although the signal is reasonably strong its tones are
broadened enough to make them hard to see on the waterfall. The
triangular red marker below the frequency scale shows that the decoder
has achieved synchronization with a signal at approximately 967 Hz.
image::QRA64.png[align="center",alt="QRA64"]
@@ -192,11 +191,12 @@ initially, as the QRA64 tones are often not visible on the waterfall.
The box labeled *Tx6* switches the Tx6 message from 1000Hz to 1250Hz
to indicate to the other station that you are ready to receive messages.
TIP: QRA64 is different from JT65 in that the decoder attempts to find
and decode only a single signal in the receiver passband. If many
signals are present you may be able to decode them by double-clicking
on the lowest tone of each one in the waterfall.
on the lowest tone of each one in the waterfall.
TIP: G3WDG has prepared a more detailed tutorial on using {QRA64_EME}.
=== ISCAT