Return-Path: X-Spam-DCC: paranoid 1169; Body=2 Fuz1=2 Fuz2=2 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on lipkowski.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DNS_FROM_AHBL_RHSBL, FORGED_RCVD_HELO autolearn=no version=3.1.3 Received: from post.thorcom.com (post.thorcom.com [195.171.43.25]) by paranoid.lipkowski.org (8.13.7/8.13.7) with ESMTP id t0ALoOpA025552 for ; Sat, 10 Jan 2015 22:50:24 +0100 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1YA3pF-0004NX-Af for rs_out_1@blacksheep.org; Sat, 10 Jan 2015 21:44:05 +0000 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1YA3pE-0004NO-Qr for rsgb_lf_group@blacksheep.org; Sat, 10 Jan 2015 21:44:04 +0000 Received: from out48-ams.mf.surf.net ([145.0.1.48]) by relay1.thorcom.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1YA3pC-0002nn-60 for rsgb_lf_group@blacksheep.org; Sat, 10 Jan 2015 21:44:03 +0000 Received: from smtps.utwente.nl (smtp-o2.utsp.utwente.nl [130.89.2.10]) by outgoing2-ams.mf.surf.net (8.14.4/8.14.4/Debian-4) with ESMTP id t0ALi0Yn024670 for ; Sat, 10 Jan 2015 22:44:01 +0100 Received: from utwks06146.ad.utwente.nl (utwks06146.ad.utwente.nl [130.89.13.213]) by smtps.utwente.nl (8.13.8) with ESMTP id t0ALi0Dh019614 for ; Sat, 10 Jan 2015 22:44:00 +0100 Received: by utwks06146.ad.utwente.nl (Postfix, from userid 17643373) id 57E3B45C0E28; Sat, 10 Jan 2015 22:44:00 +0100 (CET) Date: Sat, 10 Jan 2015 22:44:00 +0100 From: Pieter-Tjerk de Boer To: rsgb_lf_group@blacksheep.org Message-ID: <20150110214400.GO29958@cs.utwente.nl> Mail-Followup-To: rsgb_lf_group@blacksheep.org References: <20150108220755.GA20377@cs.utwente.nl> <54AF0F8C.8030106@virginbroadband.com.au> <54B03993.4090605@abelian.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <54B03993.4090605@abelian.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Bayes-Prob: 0.0001 (Score 0, tokens from: utwente-out:default, base:default, @@RPTN) X-CanIt-Geo: ip=130.89.2.10; country=NL; region=Provincie Overijssel; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default,base:default) X-Canit-Stats-ID: 0vNClI0SP - 52c0679947ad - 20150110 (trained as not-spam) X-Scanned-By: MIMEDefang 2.56 on 10.1.3.10 X-Scanned-By: CanIt (www . roaringpenguin . com) X-Scan-Signature: e6de17d69e46ff4ea8db042ef2cd7e46 Subject: Re: LF: Eb/N0 values for amateur modes Content-Type: text/plain; charset=us-ascii 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 Status: O X-Status: X-Keywords: X-UID: 1938 On Fri, Jan 09, 2015 at 08:26:59PM +0000, Paul Nicholson wrote: > CW by ear scores better than I would have guessed. Indeed, I was surprised to see the number for the three CW cases match so nicely. However, precisely in the CW case, the results should be taken with grains of salt worth several dB. The aural CW results are based on W2RS' paper about the ZRO tests, and there is a considerable difference between different operators, so I had to make a somewhat arbitrary choice. W2RS' paper can be found here: http://web.archive.org/web/20050207235207/http://www.n1bug.net/tech/w2rs/humanear.html > CRC and synchronising bits shouldn't be counted as payload > information so some of the table entries need higher Eb/N0. You're of course right in the practical case of comparing complete modes as given. However, when comparing the underlying modulation and coding schemes, it's less clear-cut. In the case of Opera's CRC bits, I have assumed the CRC is only used as a last check, so usually will be correct. In that case, one could argue those bits have also been transfered almost always correctly and could thus have been used for data. O.t.o.h., if the CRC is used to select among multiple likely outcomes of the decoding of the (outer) code, then of course those bits are coding overhead and not payload. Which of the two is truely the case in Opera, I don't know. As for the synchronising bits in WSPR and WSJT: I would argue those could be left out (or at least be reduced considerably) at the expense of having much harder time searching at the receiving side, or needing to know the precise frequency and time through some other means. The energy in the sync bits doesn't contribute to the actual decoding, once the signal has been found. Regards, Pieter-Tjerk, PA3FWM