From 31b474883b07fcc7ab52e7ee7743cedd80f05929 Mon Sep 17 00:00:00 2001 From: Joe Taylor Date: Tue, 25 Oct 2016 20:50:36 +0000 Subject: [PATCH] Further updates of the v1.7 release notes. git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@7231 ab8295b8-cf94-4d9e-aec4-7959e3be5d79 --- v1.7_Features.txt | 79 +++++++++++++++++++++++------------------------ 1 file changed, 39 insertions(+), 40 deletions(-) diff --git a/v1.7_Features.txt b/v1.7_Features.txt index 93d33cedc..fbf3abce7 100644 --- a/v1.7_Features.txt +++ b/v1.7_Features.txt @@ -13,38 +13,40 @@ Short list of new features 8. Multiple configurations can be saved and restored. 9. Sample-file download facility. 10. Optional auto-sequencing for "fast" modes. +11. Power settings optionally remembered for Transmit and Tune on a + band-by-band basis. New Modes --------- 1. MSK144 is intended for meteor scatter at 50 MHz and higher. It -uses a low-density parity check code (LDPC) designed by K9AN. The -mode is a direct descendant of the now-defunct mode JTMSK, with a -number of improvements for better performance on weak and short meteor -pings. The effective character transmission rate is about 250 cps, -compared with 147 cps for FSK441. Like JT4, JT9, JT65, and QRA64, -MSK144 uses strong forward error correction. Message decoding is -essentially "all or nothing": partial decodes do not occur, and you -will see little or no garbage on your screen. +uses a low-density parity check code (LDPC) designed by Steve Franke, +K9AN. The mode is a direct descendant of the now-defunct mode JTMSK, +with a number of improvements for better performance on weak and short +meteor pings. The effective character transmission rate is about 250 +cps, compared with 147 cps for FSK441. Like JT4, JT9, JT65, and +QRA64, MSK144 uses strong forward error correction. Message decoding +is all or nothing: partial decodes do not occur, and you will see +little or no garbage on your screen. -Standard MSK144 message frames are 72 ms long, compared to about 120 -ms for FSK441. The MSK144 waveform allows coherent demodulation, -allowing up to 3 dB better sensitivity. After QSO partners have -exchanged callsigns, MSK144 can use even shorter messages, only 20 ms -long. As in all the fast modes in WSJT-X, the 20 ms or 72 ms messages -are repeated without gaps for the duration of a transmission cycle. -For most purposes we recommend a T/R cycle duration of 15 s, but 5 s -and 10 s sequences are also supported. +Standard MSK144 message frames are 72 ms long, compared with about 120 +ms for an equivalent FSK441 message. The MSK144 waveform allows +coherent demodulation, allowing up to 3 dB better sensitivity. After +QSO partners have exchanged callsigns, MSK144 can use even shorter +messages, only 20 ms long. As in all the fast modes in WSJT-X, the 72 +ms (or 20 ms) messages are repeated without gaps for the duration of a +transmission cycle. For most purposes we recommend a T/R cycle +duration of 15 s, but 5 s and 10 s sequences are also supported. Short ("Sh") messages in MSK144 are intended primarily for 144 MHz and -higher, where many pings are short. These messages do not contain -full callsigns; instead, they contain a hash of the two callsigns -along with a report, acknowledgement, or 73. Short messages are fully -decodable only by the station to whom they are addressed, as part of -an ongoing QSO, because only then will the received hash match that -calculated using the known strings for "My Call" and "DX Call". If -you are monitoring someone else's QSO, you will not be able to decode -its Sh messages. +higher frequencies, where most pings are very short. These messages +do not contain full callsigns; instead, they contain a hash of the two +callsigns along with a report, acknowledgement, or 73. Short messages +are fully decodable only by the station to whom they are addressed, as +part of an ongoing QSO, because only then will the received hash match +that calculated using the known strings for "My Call" and "DX Call". +If you are monitoring someone else's QSO, you will not be able to +decode its Sh messages. An MSK144 signal occupies the full bandwidth of a typical SSB transmitter, so transmissions are always centered at an offset of @@ -55,13 +57,13 @@ and your QSO partner is 200 Hz, and less is better. 2. QRA64 is a intended for EME and other weak-signal use. Its internal code was designed by Nico Palermo, IV3NWV, and implemented in -WSJT-X by K1JT. The protocol uses a "Q-ary Repeat Accumulate" code, -another one of the latest research areas in communication theory. The -QRA64 code is inherently better than the Reed Solomon (63,12) code -used in JT65, yielding already a 1.3 dB advantage. QRA64 uses a new -synchronizing scheme based on a 7 x 7 Costas array, so you will not -see a bright sync tone at the lowest tone frequency. This change -yields another 1.9 dB advantage. +WSJT-X by K1JT. The protocol uses a "Q-ary Repeat Accumulate" code -- +along with LDPC, another one of the latest research areas in +communication theory. The QRA64 code is inherently better than the +Reed Solomon (63,12) code used in JT65, yielding already a 1.3 dB +advantage. QRA64 uses a new synchronizing scheme based on a 7 x 7 +Costas array, so you will not see a bright sync tone at the lowest +tone frequency. This change yields another 1.9 dB advantage. In most respects our implementation of QRA64 is operationally similar to JT65. QRA64 does not use two-tone shorthand messages, and it makes @@ -95,12 +97,9 @@ identify. Final Comments -------------- -Remember that you are using an Alpha Release. We will be grateful for -any and all reports from test users that may help us to further -improve WSJT-X. The most helpful reports describe the problem clearly -and include a complete recipe to reproduce it. Send your reports to -wsjtgroup@yahoogroups.com. - -Please be patient concerning responses from the development group. -Several of us will be on vacation or otherwise engaged during much of -August. +Remember that you are using a pre-release version of WAJT-X. We will +be grateful for any and all reports from test users; these will surely +help us to make further improvements to WSJT-X. The most helpful bug +reports describe the problem clearly and include a complete recipe to +reproduce it. Feature requests are also welcome. Send your reports +to wsjtgroup@yahoogroups.com.