Return-Path: Received: from post.thorcom.com (post.thorcom.com [195.171.43.25]) by mtain-dh01.r1000.mx.aol.com (Internet Inbound) with ESMTP id C20373800011A; Sat, 23 Feb 2013 14:10:18 -0500 (EST) Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1U9Jy4-0004ic-3L for rs_out_1@blacksheep.org; Sat, 23 Feb 2013 18:37:04 +0000 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1U9Jy3-0004iT-7B for rsgb_lf_group@blacksheep.org; Sat, 23 Feb 2013 18:37:03 +0000 Received: from imr-da06.mx.aol.com ([205.188.169.203]) by relay1.thorcom.net with esmtp (Exim 4.77) (envelope-from ) id 1U9Jy0-0005Mn-Q5 for rsgb_lf_group@blacksheep.org; Sat, 23 Feb 2013 18:37:02 +0000 Received: from mtaout-mb05.r1000.mx.aol.com (mtaout-mb05.r1000.mx.aol.com [172.29.41.69]) by imr-da06.mx.aol.com (Outbound Mail Relay) with ESMTP id 6ACEC1C000052; Sat, 23 Feb 2013 13:36:37 -0500 (EST) Received: from White (188-194-147-156-dynip.superkabel.de [188.194.147.156]) by mtaout-mb05.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPA id C04B4E000135; Sat, 23 Feb 2013 13:36:33 -0500 (EST) Message-ID: <280BD27C55F446A1B4E6809CE3B88BAE@White> From: "Markus Vester" To: , Date: Sat, 23 Feb 2013 19:36:32 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1361644597; bh=CvjDFFoaWQ4gx3YxGFNHqyetpy89/bkkFkGWBA4GLW8=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=PkXZhrvYU2JRJcl0gKZGy5LZWPF4Tl1hyNcLMaN0/jXRmEH+AdgPvYDTWsJzMGdQg KAcoaNeUP5jS89zsDc0C2hd5t00eBt/haHApY7yfMjO53ULUE2Hy48QHkONzc6g7cS i/PQQaaZsBWmYgIgnYpUj8VvY5nz2OinVl34p6y0= X-AOL-SCOLL-SCORE: 0:2:291526304:93952408 X-AOL-SCOLL-URL_COUNT: 0 X-Spam-Score: -0.7 (/) X-Spam-Report: Spam detection software, running on the system "relay1.thorcom.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Andy, yes I am using the second method. The predefined list of callsigns is converted to prestored Opera 01 sequences, based on the protocol description published by Guido PE1NNZ. For any 35 minute time slot, the received signal is correlated to each of the candidates, and the winning correlation peak is displayed if it exceeds an SNR threshold (14 dB). There is no attempt to decode anything, and the program will never come up with a callsign which was not in the list. In that sense it is really only a detection tool, but it does provide more than one bit due to unique identification (eg. 5 bits worth for 32 candidates), along with precise frequency and time information. [...] Content analysis details: (-0.7 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [205.188.169.203 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (markusvester[at]aol.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.0 HTML_MESSAGE BODY: HTML included in message 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid X-Scan-Signature: 9af9bda535a078107136d2385fe00312 Subject: LF: Re: Op-32 correlation results online Content-Type: multipart/alternative; boundary="----=_NextPart_000_0038_01CE11FD.1550D4A0" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on post.thorcom.com X-Spam-Level: X-Spam-Status: No, hits=0.6 required=5.0 tests=HTML_20_30,HTML_MESSAGE, MISSING_OUTLOOK_NAME 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-AUTHENTICATION: mtain-dh01.r1000.mx.aol.com ; domain : mx.aol.com DKIM : fail X-AOL-OVERRIDE-PIK-REASON: Y x-aol-sid: 3039ac1d41155129141a5008 X-AOL-IP: 195.171.43.25 X-AOL-SPF: domain : blacksheep.org SPF : none Dies ist eine mehrteilige Nachricht im MIME-Format. ------=_NextPart_000_0038_01CE11FD.1550D4A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Andy,=20 yes I am using the second method. The predefined list of callsigns is = converted to prestored Opera 01 sequences, based on the protocol = description published by Guido PE1NNZ. For any 35 minute time slot, the = received signal is correlated to each of the candidates, and the winning = correlation peak is displayed if it exceeds an SNR threshold (14 dB). = There is no attempt to decode anything, and the program will never come = up with a callsign which was not in the list. In that sense it is really = only a detection tool, but it does provide more than one bit due to = unique identification (eg. 5 bits worth for 32 candidates), along with = precise frequency and time information.=20 Experiments with simulated incoherent signals (ie. random phase for each = dash) indicate that the correlation process in itself is about 6 dB more = sensitive than the standard 28 bit decoding. This is more or less paid = for by the reduced information content. For coherent transmissions, = another 5 or 6 db are gained by being able to sum up the real complex = amplitude rather than the power of all dashes. Loosely speaking, this = can reduce the equivalent noise bandwidth from the inverse length of a = single symbol (0.125 Hz), down to something proportional to the inverse = of the whole sequence (0.5 mHz).=20 Best 73, Markus (DF6NM) =20 Re: [rsgb_lf_group] Re: 0p-32 correlation results online=20 What I am not sure about, Markus... In your software do you actually decode the data in some way, therefore = using knowledge of the Opera signal coding OR.... Do you precode a callsign (your "precalculated templates from a limited = list of callsigns") then correlate the received data against the pattern = generated for that callsign. If this latter is the case, then really = you are decoding just one bit of infomration. The presence or absence = of a known call. =20 I suspect many readers hoping for an independent Opera are thinking the = first option; but your description makes me think its the latter. In = which case, its certainly not a generalised data communication protocol, = but a weak signal error corrected path checker. Andy G4JNT Den 22.02.2013 11:55, skrev Markus:=20 Steinar, yes this is an independent development. It's still very experimental, = but I intend to make it public after I have fixed a few more issues. =20 The functional difference is that I don't try to decode individual = bits, but correlate the message as a whole against precalculated = templates from a limited list of callsigns. The benefit is that these = detections can be up to 10 to 12 dB more sensitive than the incoherent = decoding in the original software.=20 =20 Best 73, Markus ------=_NextPart_000_0038_01CE11FD.1550D4A0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Andy,
 
yes I am using the second = method. The=20 predefined list of callsigns is converted to = prestored Opera 01=20 sequences, based on the protocol description published by Guido=20 PE1NNZ. For any 35 minute time slot, the received signal is = correlated to=20 each of the candidates, and the winning correlation peak is displayed if = it=20 exceeds an SNR threshold (14 dB). There is no = attempt to=20 decode anything, and the program will never come up with a = callsign=20 which was not in the list. In that sense it is really only a = detection=20 tool, but it does provide more than one bit due to unique identification = (eg. 5=20 bits worth for 32 candidates), along with precise frequency = and time=20 information. 
 
Experiments with simulated incoherent = signals=20 (ie. random phase for each dash) indicate that the correlation process = in itself=20 is about 6 dB more sensitive than the standard 28 bit decoding. = This is=20 more or less paid for by the reduced information content. For coherent=20 transmissions, another 5 or 6 db are gained by being able = to sum up the real complex amplitude rather = than the=20 power of all dashes. Loosely speaking, this can reduce the = equivalent noise=20 bandwidth from the inverse length of a single symbol (0.125 Hz), down to = something proportional to the inverse of the whole sequence (0.5=20 mHz). 
 
Best 73,
Markus (DF6NM)
 
  
 
Re: [rsgb_lf_group] Re: 0p-32 = correlation results=20 online

What I am not sure about, Markus...
 
In your software do you actually decode the data in some way, = therefore=20 using knowledge of the Opera signal coding OR....
 
Do you precode a callsign (your "precalculated templates from a = limited=20 list of callsigns") then correlate the received data against the pattern = generated for that callsign.    If this latter is the = case, then=20 really you are decoding just one bit of infomration.  The presence = or=20 absence of a known call.  
 
I suspect many readers hoping for an independent Opera are thinking = the=20 first option; but your description makes me think its the latter.  = In which=20 case, its certainly not a generalised data communication protocol, = but a=20 weak signal error corrected path checker.
 
Andy
G4JNT


Den 22.02.2013 11:55, skrev Markus:=20


Steinar,

yes this is an independent = development. It's=20 still very experimental, but I intend to make it public after I have = fixed a=20 few more issues.
 
The functional difference is that I = don't try to=20 decode individual bits, but correlate the message as a whole against=20 precalculated templates from a limited list of callsigns. The benefit = is that=20 these detections can be up to 10 to 12 dB more sensitive than the = incoherent=20 decoding in the original software. 
 
Best=20 = 73,
 Markus
=
------=_NextPart_000_0038_01CE11FD.1550D4A0--