Return-Path: X-Spam-DCC: paranoid 1233; 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=-1.9 required=5.0 tests=BAYES_00,DNS_FROM_AHBL_RHSBL, HTML_40_50,HTML_MESSAGE 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 tAFDqKbc004806 for ; Sun, 15 Nov 2015 14:52:20 +0100 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1Zxxfq-0004H3-2e for rs_out_1@blacksheep.org; Sun, 15 Nov 2015 13:48:54 +0000 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1Zxxfp-0004Gu-M7 for rsgb_lf_group@blacksheep.org; Sun, 15 Nov 2015 13:48:53 +0000 Received: from out1.ip04ir2.opaltelecom.net ([62.24.128.240]) by relay1.thorcom.net with esmtp (Exim 4.86) (envelope-from ) id 1Zxxel-0000ZC-He for rsgb_lf_group@blacksheep.org; Sun, 15 Nov 2015 13:48:52 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AyCgCMi0hWPKyNH1xeGQQLAQIBAQOCPk1Tb65+hkVVAYYchAwhhWkEAgKBIU0BAQEBAQEHAQEBAUABP4Q0AQEBAQMIGzMRDRAFBQMDEQQBASsCAjkKDAgGEwgJiAgDFgmnWJADAQEIAQEBAQEeikyBBoJTgWuDNy+BFQWWSAGBIYN7ii6SW4dGgn+BaD40AYVKAQEB X-IPAS-Result: A2AyCgCMi0hWPKyNH1xeGQQLAQIBAQOCPk1Tb65+hkVVAYYchAwhhWkEAgKBIU0BAQEBAQEHAQEBAUABP4Q0AQEBAQMIGzMRDRAFBQMDEQQBASsCAjkKDAgGEwgJiAgDFgmnWJADAQEIAQEBAQEeikyBBoJTgWuDNy+BFQWWSAGBIYN7ii6SW4dGgn+BaD40AYVKAQEB X-IronPort-AV: E=Sophos;i="5.20,297,1444690800"; d="scan'208,217";a="613457883" Received: from host-92-31-141-172.as13285.net (HELO malcoHP) ([92.31.141.172]) by out1.ip04ir2.opaltelecom.net with SMTP; 15 Nov 2015 13:50:08 +0000 Message-ID: <1169E1EB8885465CA1504850B317B6FB@malcoHP> From: "mal hamilton" To: References: In-Reply-To: Date: Sun, 15 Nov 2015 13:47:30 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3508.1109 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3508.1109 X-Scan-Signature: c96efc14f58f84aa05b44c520f48db32 Subject: LF: Re: WSPR DECODES - and Opera Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01D11FAC.2C03AF50" 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-Scanned-By: MIMEDefang 2.56 on 10.1.3.10 Status: O X-Status: X-Keywords: X-UID: 5093 This is a multi-part message in MIME format. ------=_NextPart_000_000C_01D11FAC.2C03AF50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Markus Regardless of theory and speculation what I have observed in reality is = that weak visible signals showing on the waterfall would be perfectly = readable had the mode been QRSS whereas data modes when they do not = decode they meaningless. I do not necessarily believe everything that someone tells me, in some = cases it is guesswork, speculation and manipulation of figures. The results also depend on the environment where the experiment was = carried out, too many variables to be conclusive. I can only observe what I see in reality. No doubt the argument for and against data modes will continue and are = fun to play with in an amateur context and every Radio Amateur/Appliance = operator has a different of set of circumstances at their QTH. What = works for one does not always work for another de mal=E2=80=99g3kev From: Markus Vester=20 Sent: Sunday, November 15, 2015 11:53 AM To: rsgb_lf_group@blacksheep.org=20 Subject: Re: LF: WSPR DECODES - and Opera QRSS better than WSPR? Almost, but not quite... see Rik's evaluation: http://on7yd.strobbe.eu/QRSS/ The SNR threshold 50% successful WSPR decodes is between -29 and -30 dB = (2.5 kHz), wheras the QRSS messages required a couple of dB more (-27 to = -28 dB). In Rik's challenge, completely random messages were used, and = only completely correct readings were counted as success. Due to the = structure of Morse code (dashes are better visible than dots), partial = "decodes" are often possible at lower SNR, which often allow conducting = a QSO using some a-priori information and guesswork. =20 Rik also looked at Opera versus WSPR, and found a 6 dB deficit for Opera = at same peak power. That was probably still in an early stage of Opera = development, and the decoding abilities have been improved since then. = My own tests with Opera v1.5.6 =20 http://df6nm.bplaced.net/opera/Success_rate.png got 50% successful Op-32 decodes at -40 dB average SNR. This scales to = -28 dB (av) or -25 dB (PEP) at Op-2 speed, i.e. a 1.5 dB improvement = since Rik's blue curve. However, at same average power, Opera-2 is still = 1.5 dB weaker than WSPR-2 (or 4.5 dB weaker at same peak power).=20 Including the volume of conveyed information, WSPR wins another 2.52 dB = (50 bits versus 28 bits), and it is also slightly shorter than Op-2 = (110.6 vs 122.4 s, another 0.44 dB). Thus alltogether the difference is = 4.5 dB at same average power (i.e. Op needs 2.8 times the energy per = bit), or 7.5 dB at same PEP (with a given TX, Opera needs 5.6 times as = long to send the same amount of information). Minimum Eb/N0 values are = about +7.9 dB for WSPR and +12.4 dB for Opera. Regarding correlation detections, my measurements using coherent signals = showed that opds can go about 8 dB lower than the Opera decoder. For = comparison, Opera's Dynamic Deep-Search believably claims to go 5 dB = below the decoder. Sorry for reiterating this topic again... Best 73, Markus (DF6NM) =20 From: mal hamilton=20 Sent: Sunday, November 15, 2015 10:37 AM To: rsgb_lf_group@blacksheep.org=20 Subject: LF: WSPR DECODES MF I have been observing WSPR signals this past couple of days on 474.2 Khz = and although most are Decoding there are a number of weak signals = visible on the waterfall that do not decode. I am in a quiet location = so noise is not a problem. My clock and input are set up as specified. Had these station been using QRSS the copy would be perfect.=20 also the same applies to Opera signals visible on the waterfall but do not = decode, usually weak. QRSS has the advantage that the raw signal observed is immediately = readable on the screen even the barely visible. G3KEV ------=_NextPart_000_000C_01D11FAC.2C03AF50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Markus
Regardless of theory and speculation what I have observed in = reality is=20 that weak visible signals showing on the waterfall would be perfectly = readable=20 had the mode been QRSS whereas data modes when they do not decode they=20 meaningless.
I do not necessarily believe everything that someone tells me, in = some=20 cases it is guesswork, speculation and manipulation of figures.
The results also depend on the environment where the experiment was = carried=20 out, too many variables to be conclusive.
I can only observe what I see in reality.
No doubt the argument for and against data modes will continue and = are fun=20 to play with in an amateur context and every Radio Amateur/Appliance = operator=20 has a different of set of circumstances at their QTH.  What works = for one=20 does not always work for another
de mal=E2=80=99g3kev
 
 
Sent: Sunday, November 15, 2015 11:53 AM
Subject: Re: LF: WSPR DECODES - and Opera
 
QRSS better than WSPR? Almost, but not = quite... see=20 Rik's evaluation:
 http://on7yd.strobbe.eu/QRSS/<= /FONT>
The SNR threshold 50% successful WSPR = decodes is=20 between -29 and -30 dB (2.5 kHz), wheras the QRSS messages required a = couple of=20 dB more (-27 to -28 dB). In Rik's challenge, completely random messages = were=20 used, and only completely correct readings were counted as success. Due = to the=20 structure of Morse code (dashes are better visible than dots), partial = "decodes"=20 are often possible at lower SNR, which often allow conducting a QSO = using some=20 a-priori information and guesswork.   
 
Rik also looked at Opera versus WSPR, = and found a 6=20 dB deficit for Opera at same peak power. That was probably still in an = early=20 stage of Opera development, and the decoding abilities have been = improved since=20 then. My own tests with Opera v1.5.6  
 http://df6nm.bpl= aced.net/opera/Success_rate.png
got=20 50% successful Op-32 decodes at -40 dB average SNR. This scales to -28 = dB (av)=20 or -25 dB (PEP) at Op-2 speed, i.e. a 1.5 dB improvement since Rik's = blue curve.=20 However, at same average power, Opera-2 is still 1.5 dB weaker = than=20 WSPR-2 (or 4.5 dB weaker at same peak power).
 
Including the volume of conveyed = information, WSPR=20 wins another 2.52 dB (50 bits versus 28 bits), and it is also slightly = shorter=20 than Op-2 (110.6 vs 122.4 s, another 0.44 dB). Thus alltogether the = difference=20 is 4.5 dB at same average power (i.e. Op needs 2.8 times the energy per = bit), or=20 7.5 dB at same PEP (with a given TX, Opera needs 5.6 times as long to = send the=20 same amount of information). Minimum Eb/N0 values are about +7.9 dB for = WSPR and=20 +12.4 dB for Opera.
 
Regarding correlation detections, my = measurements=20 using coherent signals showed that opds can go about 8 dB lower than the = Opera=20 decoder. For comparison, Opera's Dynamic Deep-Search believably claims = to go 5=20 dB below the decoder.
 
Sorry for reiterating this topic=20 again...
 
Best 73,
Markus (DF6NM)  =
 
Sent: Sunday, November 15, 2015 10:37 AM
To: rsgb_lf_group@blacksheep.org= =20
Subject: LF: WSPR DECODES
 
MF
I have been observing WSPR signals this past couple of days on = 474.2 Khz=20 and although most are Decoding there are a number of weak signals = visible on=20 the  waterfall that do not decode. I am in a quiet location so = noise is not=20 a problem. My clock and input are set up as specified.
Had these station been using QRSS the copy would be perfect.
also
the same applies to Opera signals visible on the waterfall but do = not=20 decode, usually weak.
QRSS has the advantage that the raw signal observed is immediately = readable=20 on the screen even the barely visible.
 
G3KEV
 
------=_NextPart_000_000C_01D11FAC.2C03AF50--