Message-ID: <3FB5FEFF1DA94649AE8DB40B4840C658@AGB>
From: "Graham" <g8fzk@g8fzk.fsnet.co.uk>
To: <rsgb_lf_group@blacksheep.org>
References: <569C69EC.7010906@telus.net> <F6DE9D64E261486DA454671269E47857@AGB> <BLU403-EAS21CCB3F52FC303F8BDE058CFC00@phx.gbl>
In-Reply-To: <BLU403-EAS21CCB3F52FC303F8BDE058CFC00@phx.gbl>
Date: Mon, 18 Jan 2016 22:12:17 -0000
MIME-Version: 1.0
Importance: Normal
Subject: Re: LF: Opera decode
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
Status: O

L,

Yes, that's the problem, if the  Tx  site is  'remote'  , well  not a 
problem if  you  fire the  opera  decoder -40 and  above , then you  have a 
data  decode, call sign, s/n,  % fade and frequency  , but if there is  only 
a  single  Rx , and only a dynamic spot then  its  back to  basic's ....may 
be a  TX beacon in the  psk-map data  base .

Simple work around is to  run a  local  decode  [ can  be  audio from the 
app  or  off  air ]  to  give the system a time  stamp, cheap  $10 dongle 
in direct  sample works  fine, just on leakage..

73-G,

--------------------------------------------------
From: "Laurence KL7 L" <hellozerohellozero@hotmail.com>
Sent: Monday, January 18, 2016 9:46 PM
To: <rsgb_lf_group@blacksheep.org>
Subject: Re: LF: Opera decode

> We did the same sort of thing a few days back to validate ja5np decode of 
> xpq - time and exact frequency were good...
>
> L
>
>> On Jan 18, 2016, at 12:40, Graham <g8fzk@g8fzk.fsnet.co.uk> wrote:
>>
>> John,
>>
>> ''Decode from LA4ANA''  -
>>
>> That is the  output from the  dynamic DETECTOR  , ie  pattern matching
>> correlation  detector, provided as a  second lower  s/n  detection 
>> system,
>> should the  Opera DECODER fail  to recover the  transmission.
>> lower limit for op32 ~ -40 dB s/n
>>
>> The Dynamic detector attempts to  'pattern match'  the  Tx  010100 
>> profile
>> ,a primitive  'Painting by numbers' system if you like,  dynamic is  set 
>> to give ~ -6 dB
>> advantage.
>>
>> The issue of  false detection/real call signs is  addressed in the Opera 
>> Dynamic system
>> and the system output, clearly indicates when the  spot is  Opera  or 
>> Dynamic, validated
>> or not.
>>
>> False opera  decode =  call  sign format  'random characters'
>> False  dynamic detection  =  call  sign from  list ,  wrong  time  stamp
>>
>> Deep Search ?? =   Not Validated
>>
>> In the  case of a  non-validation '??'  ,
>>
>> its  to the  users to evaluate the  situation ,
>> was the  station  sending ?
>> is the  frequency  that  of the  detected station ?
>> is the  time  stamp  aligned  with the  expected Tx ?
>>
>> Issues with the  psk-map seem to be a common  theme,  the  system uploads 
>> have not
>> changed , but  map-housekeeping routines  could be  removing  swl markers
>>
>> 73-Graham
>> G0NBD
>>
>>
>>
>>
>>
>>
>>
>> --------------------------------------------------
>> From: "John Gibbs" <jgibbs@telus.net>
>> Sent: Monday, January 18, 2016 4:28 AM
>> To: <rsgb_lf_group@blacksheep.org>
>> Subject: LF: Opera decode
>>
>>> Decode from LA4ANA  just after local sunset here..  was this station 
>>> even
>>> on air at 18_0141 utc ??? Must be bogus.
>>> Anyone know why version of  Opera v1.5.8 on LF or MF  would not show on
>>> PSK map.  Earlier versions used to.
>>>
>>> 03:06    136 WE2XPQ de VE7BDQ Op32 Deep Search ?? 2147 km -43 dB in
>>> SOUTHDELTA BC 1474.1 Hz with 10w + Marconi
>>> 01:41    136 LA4ANA de VE7BDQ Op32 Deep Search ?? -42 dB in SOUTHDELTA 
>>> BC
>>> 1531.3 Hz
>>> ***********  18/01/2016  ***********
>>>
>>> 73  John / VE7BDQ
>>
>