Message-ID: <FB2C78B23F9943B8B7A52E40B3F0ABC2@AGB>
From: "Graham" <g8fzk@g8fzk.fsnet.co.uk>
To: <rsgb_lf_group@blacksheep.org>
References: <CAA8k23STzh0z0=AqAXBhz-AEpcT67y-5CSazZny-QT=wuDPhoQ@mail.gmail.com> <2BB40A231A1A4EF8B2DB14786249FA35@AGB> <B52B4B55DF224E24956CAAAF049C6E1A@JimPC>
In-Reply-To: <B52B4B55DF224E24956CAAAF049C6E1A@JimPC>
Date: Tue, 17 Jan 2012 23:25:34 -0000
MIME-Version: 1.0
Importance: Normal
Subject: Re: LF: Opera continuous changes
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=response
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: 3039ac1d404d4f1603a77e96
X-AOL-IP: 195.171.43.25
X-AOL-SPF: domain : blacksheep.org SPF : none


Thanks'  Jim

Looking  at the  spec-plots  for  long  haul  DX on 136  , the  peak  signal 
levels  do  not  appear to  support the  full  call sign when  using  the 
very  long qrss  periods , the  ref  is  often  pinged with post  asking  as 
to  who  xx is  or  zyz  etc  , so  it  followed that  to capture a   full 
call  using  OP , then a decode capability , matching  these, xx  zyz 
times  would  present a  viable  alternative ?

To decode  over  longer  periods would  require a  signal over the 
threshold  for  66% of the  transmission ? ...  however ...

Tnx G.



--------------------------------------------------
From: "James Moritz" <james.moritz@btopenworld.com>
Sent: Tuesday, January 17, 2012 10:58 PM
To: <rsgb_lf_group@blacksheep.org>
Subject: Re: LF: Opera continuous changes

> Dear Graham, LF Group,
>
>
>> It was  felt the  Op50 /64  was  perhaps  too  long  a  capture period 
>> for 136Khz
>> with  max  33% data  loss  this  was still  40mins  , which , was 
>> possibly
>> a little  too  long.
>>
>> OP32  , will  reduce to  20  mins capture  window and is  perhaps more 
>> realistic?
>
> As currently implemented, Opera is purely a beacon mode; as far as I am 
> aware, it transmits only the station ID. It is quite normal to transmit 
> beacon signals using QRSS60 or even slower signalling. At 60s per dot, it 
> takes of the order of 60 minutes to transmit a typical callsign, so quite 
> a similar rate to "Op50" or "Op64".  Most people run their beacon 
> transmitters and/or receivers for hours at a time. If complete station IDs 
> with some sort of signal level assesment can be obtained within that 
> period, I guess most would think one such detection per hour is a 
> satisfactory result and slowness would not be a problem. A very slow 
> beacon signal, accompanied with the information that the SNR is only just 
> adequate for decoding, or good enough to try a faster mode, is certainly 
> more useful than a faster mode that can't be detected!
>
> For a communications mode, it would be pointlessly slow of course. But 
> with beacon signals we are often trying simply to see if anything can be 
> detected at all with the combination of radiated power, propagation path 
> and RX noise level that is available, and if so, how much. I'm sure if 
> there were Op128 or Op256 modes, people would be happy to try using them 
> too... A nice feature of the current Opera is that the receiver can detect 
> signals at whichever speed happens to be in use, so there is nothing to 
> stop people altering their transmission mode to see what will work, 
> without having to re-arrange the test.
>
> Cheers, Jim Moritz
> 73 de M0BMU
>