Return-Path: Received: from rly-mh02.mx.aol.com (rly-mh02.mail.aol.com [172.21.166.138]) by air-mh08.mail.aol.com (v121.4) with ESMTP id MAILINMH084-bbd47e62d196c; Sun, 23 Mar 2008 06:12:54 -0400 Received: from post.thorcom.com (post.thorcom.com [193.82.116.20]) by rly-mh02.mx.aol.com (v121.4) with ESMTP id MAILRELAYINMH025-bbd47e62d196c; Sun, 23 Mar 2008 06:12:43 -0400 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1JdNBi-0006gm-Rv for rs_out_1@blacksheep.org; Sun, 23 Mar 2008 10:12:26 +0000 Received: from [83.244.159.144] (helo=relay3.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1JdNBi-0006gd-Be for rsgb_lf_group@blacksheep.org; Sun, 23 Mar 2008 10:12:26 +0000 Received: from ug-out-1314.google.com ([66.249.92.170]) by relay3.thorcom.net with esmtp (Exim 4.63) (envelope-from ) id 1JdNBc-0001Dl-Fc for rsgb_lf_group@blacksheep.org; Sun, 23 Mar 2008 10:12:26 +0000 Received: by ug-out-1314.google.com with SMTP id a2so2320098ugf.13 for ; Sun, 23 Mar 2008 03:12:09 -0700 (PDT) Received: by 10.67.22.14 with SMTP id z14mr3813654ugi.24.1206267129506; Sun, 23 Mar 2008 03:12:09 -0700 (PDT) Received: by 10.66.244.4 with HTTP; Sun, 23 Mar 2008 03:12:09 -0700 (PDT) Message-ID: Date: Sun, 23 Mar 2008 10:12:09 +0000 From: "Andy Talbot" To: rsgb_lf_group@blacksheep.org Cc: "Joe Taylor" MIME-Version: 1.0 X-Spam-Score: 0.9 (/) X-Spam-Report: autolearn=disabled,HTML_10_20=0.945,HTML_MESSAGE=0.001 Subject: LF: Thoughts on WSJTA tests vs. WSPR Content-Type: multipart/alternative; boundary="----=_Part_7175_29584433.1206267129502" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on post.thorcom.com X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.63 X-SA-Exim-Scanned: Yes Sender: owner-rsgb_lf_group@blacksheep.org Precedence: bulk Reply-To: rsgb_lf_group@blacksheep.org X-Listname: rsgb_lf_group X-SA-Exim-Rcpt-To: rs_out_1@blacksheep.org X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-AOL-IP: 193.82.116.20 X-AOL-SCOLL-AUTHENTICATION: listenair ; SPF_helo : n X-AOL-SCOLL-AUTHENTICATION: listenair ; SPF_822_from : ? X-Mailer: Unknown (No Version) ------=_Part_7175_29584433.1206267129502 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Having just read back through Joe Taylor's WSJT documentation, my comments last night about how the WSJTA version ought to be 3dB better than the ..B due to narrower signal bandwidth just aren't true. The noise / weak signal performance is governed by the FFT bin size which is inextricably linked with the symbol length and remains substantially constant between WSJTa/b/c. So therefore, to all intents and purposes, there is no major S/N difference between any of the three modes. The symbol length is 0.372s, and bin size 2.69Hz (11025 / 4096). Compare this to WSPR with its symbol rate and signal bandwidth of 12000/8192 = 1.46Hz. An immediate improvement of 2.6dB in S/N. Couple this with the processing not having to cope with a spread out signal, less overhead on a sync sequence and able to make more use of the interleaving, and its becoming easier to see why the mode is quite a lot better in practice than JT65a when used on LF. The wider bandwidth JT65B and C modes are to cope with frequency spreading and the scattering present on VHF/UHF and EME links. The wider tone spacing is just to help tone separation in the decoder. It provides no additional advantage *when propagation is clean* and no frequency spreading occurs - exactly the case at LF I went back and did some S/N measurements again, using GB3VHF / JT65B with an attenuator in the antenna feed until I got the same S/N reports as last night's tests. Those S/N reports are below the threshold for decoding rising to just about sitting at the lower end of what can be averaged into a report after three demods. Based on this new understanding I am now a lot less surprisd that no decodes were achieved. In a way, it is rather unfortunate that the WSJT Rx algorithm can detect the sync sequence several dB below what is can extract data from. This tends to give users a false sense of signal quality. -- Andy G4JNT www.scrbg.org/g4jnt ------=_Part_7175_29584433.1206267129502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Having just read back through Joe Taylor's  WSJT documentation, my comments last night about how the WSJTA version ought to be 3dB better than the ..B  due to narrower signal bandwidth just aren't true.     The noise / weak signal performance is governed by the FFT bin size which is inextricably linked with the symbol length and remains substantially constant between WSJTa/b/c.  So therefore, to all intents and purposes, there is no major S/N difference between any of the three modes.

The symbol length is 0.372s, and bin size 2.69Hz  (11025 / 4096).  Compare this to WSPR with its symbol rate and signal bandwidth of  12000/8192 = 1.46Hz.   An immediate improvement of 2.6dB in S/N.  Couple this with the processing not having to cope with a spread out signal, less overhead on a sync sequence and able to make more use of the interleaving, and its becoming easier to see why the mode is quite a lot better in practice than JT65a when used on LF.

The wider bandwidth JT65B and C modes are to cope with frequency spreading and the scattering present on VHF/UHF and EME links.   The wider tone spacing is just to help tone separation in the decoder.  It provides no additional advantage when propagation is clean and no frequency spreading occurs - exactly the case at LF

I went back and did some S/N measurements again, using GB3VHF / JT65B with an attenuator in the antenna feed until I got the same S/N reports as last night's tests.  Those S/N reports are below the threshold for decoding rising to just about sitting at the lower end of what can be averaged into a report after three demods.  Based on this new understanding I am now a lot less surprisd that no decodes were achieved.

In a way, it is rather unfortunate that the WSJT Rx algorithm can detect the sync sequence several dB below what is can extract data from.  This tends to give users a false sense of signal quality.


--
Andy  G4JNT
www.scrbg.org/g4jnt
------=_Part_7175_29584433.1206267129502--