Message-ID: <F6C6BE2D8C2A4AA28D388EB0A4B04103@AGB>
From: "Graham" <g8fzk@g8fzk.fsnet.co.uk>
To: <rsgb_lf_group@blacksheep.org>
References: <006201cce044$06c16f80$0401a8c0@xphd97xgq27nyf> <3A9A60CAE4EB4355A5B0A30CDA0F450A@JimPC> <AE79F5BD0B964D4CBF8E04AD01E73808@JimPC> <4F287B3F.1040109@talktalk.net> <001b01cce0c1$49ec88d0$0401a8c0@xphd97xgq27nyf> <4F290605.80706@talktalk.net> <004301cce0c8$ef41a700$0401a8c0@xphd97xgq27nyf>
In-Reply-To: <004301cce0c8$ef41a700$0401a8c0@xphd97xgq27nyf>
Date: Wed, 1 Feb 2012 17:43:47 -0000
MIME-Version: 1.0
Importance: Normal
Subject: Re: LF: Re: Opera v qrs evaluation
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
X-AOL-SCOLL-URL_COUNT: 0  
x-aol-sid: 3039ac1d410b4f2988b61de3
X-AOL-IP: 195.171.43.25
X-AOL-SPF: domain : blacksheep.org SPF : none


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" <g3kevmal@talktalk.net>
Sent: Wednesday, February 01, 2012 10:04 AM
To: <rsgb_lf_group@blacksheep.org>
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" <qrss@talktalk.net>
> To: <rsgb_lf_group@blacksheep.org>
> 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"<qrss@talktalk.net>
>> > To:<rsgb_lf_group@blacksheep.org>
>> > 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
>> >>
>> >
>> >
>>
>>
>
>