Return-Path: Received: from post.thorcom.com (post.thorcom.com [195.171.43.25]) by mtain-mb05.r1000.mx.aol.com (Internet Inbound) with ESMTP id D678238000097 for ; Wed, 1 Feb 2012 14:02:19 -0500 (EST) Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1RseTo-0002fr-Sb for rs_out_1@blacksheep.org; Wed, 01 Feb 2012 18:00:24 +0000 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1RseTo-0002fi-Bt for rsgb_lf_group@blacksheep.org; Wed, 01 Feb 2012 18:00:24 +0000 Received: from out1.ip09ir2.opaltelecom.net ([62.24.128.245]) by relay1.thorcom.net with esmtp (Exim 4.63) (envelope-from ) id 1RseTm-00048j-TX for rsgb_lf_group@blacksheep.org; Wed, 01 Feb 2012 18:00:24 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgCAId9KU9Olm3V/2dsb2JhbAAMN64Bg3QBAQEBAgEOKi0BBgoCBgcECwkIBAEBAQkWDwkDAgECAT0IEwYCAQGHeLhTiTmBeQEEAgECAgkEAQ0EBgEIDQ6DFhkEAwwDFAVcg2gEjVyaGQ X-IronPort-AV: E=Sophos;i="4.71,603,1320624000"; d="scan'208";a="504324132" Received: from host-78-150-109-213.as13285.net (HELO [192.168.2.5]) ([78.150.109.213]) by out1.ip09ir2.opaltelecom.net with ESMTP; 01 Feb 2012 17:59:58 +0000 Message-ID: <4F297D9C.8030004@talktalk.net> Date: Wed, 01 Feb 2012 17:59:56 +0000 From: qrss User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: rsgb_lf_group@blacksheep.org References: <006201cce044$06c16f80$0401a8c0@xphd97xgq27nyf> <3A9A60CAE4EB4355A5B0A30CDA0F450A@JimPC> <4F287B3F.1040109@talktalk.net> <001b01cce0c1$49ec88d0$0401a8c0@xphd97xgq27nyf> <4F290605.80706@talktalk.net> <004301cce0c8$ef41a700$0401a8c0@xphd97xgq27nyf> In-Reply-To: X-Spam-Score: 1.4 (+) X-Spam-Report: autolearn=disabled,RATWARE_GECKO_BUILD=1.426 Subject: Re: LF: Re: Opera v qrs evaluation Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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=none 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-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:464432384:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d60194f298c3a7d0a X-AOL-IP: 195.171.43.25 X-AOL-SPF: domain : blacksheep.org SPF : none > not too unexpectedly , follows the usual pie fight If you see me joining the fun of the pie fight you know I must be feeling better. > 'you cannot use on/off keying for a data mode' because ..... It will never work (garden fences spring to mind) that's why no one has done it before except for old Sam silly old fool, why didn't I think of it grrrr. E On 01/02/2012 17:43, Graham wrote: > Talking of digging holes , in this case , digging in the noise , > the OP32 mode should provide the best s/n with decode possible > with over 50/55% of the data > > Its possible to run this on 500 , just select 136 and set the > dial frequency as 500 , the web -spots will be showing 136 of > course , if your not cat linked , but the comparison would be > most valid at the lower end of the mode s/n ability .. or on 136 > where there is quite a lot of activity using OP8 , which is > giving quite reliable dx decodes . OP4 seems to be the mode of > choice for 500 , options of 2/8 may be better suited as the > majority of decodes (Ed apart !) are well inside the OP2 limits , > with OP8 perhaps better suited to dx ... one for the 'to try > list' , though development did take place with 2/8 on 500. > > Better would be a high power test on 136 to see the > difference of the systems at range, but to date this has yet to > happen... > > Mal is right , its possible to have the signal showing on the > screen , but no decode , if over 50/55% of the data is lost then, > no decode is possible, that is the balance on the Tx time , > too short and loose s/n . too long and qsb might remove too > much data .. > > Keeping a eye on the longer term aim of a 'data mode' the > beacon is providing useful test data and reliable web linked > s/n measurements, as well as the seemingly unlimited opportunity > to rake over the coals of established 'technical facts' , > > Thanks to Mal for running the tests , as perhaps, not too > unexpectedly , follows the usual pie fight , which has produced > some useful analysis, as usual there's madness in the method on > all sides .. > > Tie braking question :) > > 'you cannot use on/off keying for a data mode' because ........ > > 73 -G.. > > -------------------------------------------------- > From: "mal hamilton" > Sent: Wednesday, February 01, 2012 10:04 AM > To: > Subject: Re: LF: Re: Opera v qrs evaluation > >> I would say your qrs on 500 was heard/seen but no one could be >> bothered to >> report it. >> I personally do not report QRS beacon acty on any band. >> The majority of 500 Beacons are normal CW and I can hear the USA and >> Canada >> frequently and strong enough for a QSO >> I thought a PIC was an implement to dig a hole with !! >> >> >> ----- Original Message ----- >> From: "qrss" >> To: >> Sent: Wednesday, February 01, 2012 9:29 AM >> Subject: Re: LF: Re: Opera v qrs evaluation >> >> >>> Mal >>> >>> Fact. Everyone including G3KEV has missed my QRS3 and QRS10 on 500kHz >>> every time I have had it on, using this same TX, in fact I removed the >>> PIC which sends the QRS and inserted OPERA, viola PA0's at 493km decode >> me. >>> >>> Please be technical not emotional about the subject it doesn't help. >>> >>> 73 Eddie >>> >>> >>> On 01/02/2012 09:10, mal hamilton wrote: >>> > QRSS does NOT get lost or missed in the noise as you suggest and one >> can >>> > always see at least part of the information trace, whereas Opera >>> is all >> or >>> > nothing and I have noticed at times a TRACE but NO DECODE. >>> > I wonder what your next distortion of the facts will be >>> > g3kev >>> > >>> > ----- Original Message ----- >>> > From: "qrss" >>> > To: >>> > Sent: Tuesday, January 31, 2012 11:37 PM >>> > Subject: Re: LF: Re: Opera v qrs evaluation >>> > >>> > >>> >> Dear Jim, Rik, Laurence >>> >> >>> >> Thanks for the information, it does seem from all tests that QRS3 >>> and >>> >> OP4 are about equivalent. >>> >> QRS as we know takes a human to notice its there among noise and can >> get >>> >> missed. With OPERA (and WSPR) if there is an RX on in range it's >> de-coded. >>> >> >>> >> 73 Eddie G3ZJO >>> >> >>> >> >>> >> On 31/01/2012 22:51, James Moritz wrote: >>> >>> Dear Eddie, LF Group, >>> >>> >>> >>> I did a rough and ready comparative test on the "sensitivity" of >>> >>> QRSS3 >>> >>> and Op4 using your back-to-back transmissions. For 500kHz >>> reception, >>> >>> broadband noise from the broadcast stations just east of here is >>> >>> being >>> >>> nulled out using a loop oriented N-S. Rotating the loop out of the >>> >>> null position gives a convenient way of adjusting the SNR on >>> Eddie's >>> >>> signal. So I increased the noise level until I judged Eddie's >>> QRSS >>> was >>> >>> just fully readable (using 0.3Hz FFT resolution), then left >>> >>> everything >>> >>> in the same position for 4 transmissions, during which signal and >>> >>> noise levels stayed nearly constant (see the attachment). Opera >>> >>> reported an SNR of -31dB on Eddie's Op4 signal for all the >>> > transmissions. >>> >>> So, from what Graham said, Op4 may have a small margin in SNR with >>> >>> these conditions. You could argue about what constitutes "readable" >>> >>> QRSS, but there can't be more than a few dB difference between this >>> >>> signal and something indecipherable without prior knowledge. It >>> takes >>> >>> 4 minutes to send a callsign using Op4; you could increase the dot >>> >>> length perhaps to 4s and transmit most callsigns in 4 minutes, >>> which >>> >>> would gain you about 1.2dB. But for practical purposes I think, in >>> >>> this test anyway, the two modes are approximately equivalent in >>> their >>> >>> efficiency in sending callsigns. >>> >>> >>> >>> Cheers, Jim Moritz >>> >>> 73 de M0BMU >>> >> >>> > >>> > >>> >>> >> >> > >