Return-Path: Received: from post.thorcom.com (post.thorcom.com [195.171.43.25]) by mtain-md04.r1000.mx.aol.com (Internet Inbound) with ESMTP id 6383738000088; Tue, 28 Aug 2012 10:01:11 -0400 (EDT) Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1T6MKx-00031a-Be for rs_out_1@blacksheep.org; Tue, 28 Aug 2012 15:00:11 +0100 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1T6MKw-00031R-M5 for rsgb_lf_group@blacksheep.org; Tue, 28 Aug 2012 15:00:10 +0100 Received: from mail-bk0-f43.google.com ([209.85.214.43]) by relay1.thorcom.net with esmtps (TLSv1:RC4-SHA:128) (Exim 4.77) (envelope-from ) id 1T6MKu-0006Sq-2y for rsgb_lf_group@blacksheep.org; Tue, 28 Aug 2012 15:00:09 +0100 Received: by bkty15 with SMTP id y15so2895403bkt.16 for ; Tue, 28 Aug 2012 07:00:07 -0700 (PDT) X-DKIM-Result: Domain=gmail.com Result=Good and Known Domain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=IlYLsV0It7R/GuD0ipZBTuGF/ZdO7QpGyCyk+iV3+oE=; b=c8FVzaWN4QhWTm4gMC/L/vcdSYKGFektT36KK9+PvlpaMPbIwwf4NvejhlwqW6JU9O hT3JLSaWt7GH/MgjBWJ7pZshdb6wKyO0bat3Eh+mVvDX6yCmwym1RqolpHJjT5UOfHZu D0JL/WLAiMQi0VglO82DeATZTiaTJcswpoVpEWFfZdNJtIbQecz+9vi85lE6xoz4G+yE 99VCIS+jtQGT84rALFu0oj5fHWC4oQBYKJbx+++wjjF4veAas0nBX6cLLusMVFHwE+9W 0D6wMbnATjOaThtlKRHlrUB/2lSanueNA0IsALWMNVrgIAGGReHBvsTi+/t33m6uNktM lSGQ== MIME-Version: 1.0 Received: by 10.205.126.13 with SMTP id gu13mr4917035bkc.79.1346162406912; Tue, 28 Aug 2012 07:00:06 -0700 (PDT) Received: by 10.204.170.136 with HTTP; Tue, 28 Aug 2012 07:00:06 -0700 (PDT) In-Reply-To: <1067FFBBAFB14287AD6D816189F51B78@White> References: <1067FFBBAFB14287AD6D816189F51B78@White> Date: Tue, 28 Aug 2012 15:00:06 +0100 Message-ID: From: Roger Lapthorn To: rsgb_lf_group@blacksheep.org, rsgb_lf_group@yahoogroups.co.uk 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: This is beyond my simple brain Marcus (!) but I'm impressed that such processing could allow even weaker signals to be copied. I think that what you are saying is that with very accurate timing (as in WSPR) it should be possible to identify a callsign in OPERA by correlating it against a known list of possible callsigns stored locally and by this means the process of identifying the call can be achieved with lower S/N, or more quickly, or both? [...] Content analysis details: (-0.7 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.214.43 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rogerlapthorn[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 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: 9cafc73d135491d75f4f47d39ed43841 Subject: Re: LF: WD2XES - Opera detected and identified by correlation Content-Type: multipart/alternative; boundary=00151747b74412f1d404c853dc0b X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on post.thorcom.com X-Spam-Level: X-Spam-Status: No, hits=0.1 required=5.0 tests=HTML_FONTCOLOR_UNSAFE, HTML_MESSAGE 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-sid: 3039ac1d6058503ccf2637b2 X-AOL-IP: 195.171.43.25 X-AOL-SPF: domain : blacksheep.org SPF : none --00151747b74412f1d404c853dc0b Content-Type: text/plain; charset=ISO-8859-1 This is beyond my simple brain Marcus (!) but I'm impressed that such processing could allow even weaker signals to be copied. I think that what you are saying is that with very accurate timing (as in WSPR) it should be possible to identify a callsign in OPERA by correlating it against a known list of possible callsigns stored locally and by this means the process of identifying the call can be achieved with lower S/N, or more quickly, or both? It suggests there are still opportunities to develop yet better weak signal modes that get even closer to the theoretical limits for data transmission. I guess the goal is to be able to exchange a minimal data QSO in a time-frame consistent with the propagation medium remaining "open" i.e. for long DX paths to VK, YV, W etc 73s Roger G3XBM On 27 August 2012 23:22, Markus Vester wrote: > ** > Recently I have been pondering wether it is possible to detect QRSS or > Opera transmissions by signal correlation against a known waveform. This > should far be more sensitive than the conventional incoherent decoding > process. John's stable and phase-coherent Opera transmission last night's > provided a welcome opportunity to test this scheme. > > Using SndInput from DL4YHF, I recorded a long IQ file at 2 samples / > second, ie. 2 Hz wide centered on 137561 Hz. The audio was taken straight > from the Rubidium-locked receiver, with no noise blanking inserted. The > data was then postprocessed using a MathCad spreadsheet. Some results can > be viewed in > http://df6nm.bplaced.net/opera/xes/ , > along with TA grabber screenshots showing both XGJ and a weak trace from > XES in 21 mHz FFT (testTA.jpg). > > First a high resolution spectrogram was generated, at 1.9 mHz per bin > (xes_spectrogram.png). The central carrier component of the transmission > can clearly be seen. Best SNR occured between 3:30 and 4:30 UT (as > indicated by marker ticks), when the peak was 9.0 dB above the noise > (xes_spectrum.png). Scaling noise bandwidth from 2.9 mHz to 2.5 kHz (-49.5 > dB), and adding 6 dB for 50% duty cycle, we get a peak-power SNR of -44.5 > dB. This corresponds to -48.5 dB on the Opera SNR scale, about 9 dB below > the current decoding threshold for Op-32. > > The peak appeared about 0.2 Hz off-center because the 12 kHz samplerate > had not been not calibrated. Once the peak frequency is accurately > identified, the received signal can be correlated against a "prototype" > waveform, which contains the Opera sequence for WD2XES, 16-fold > oversampled. The correlation is efficiently implemented as a multiplication > in Fourier space. > > The result (xes_correlation_wd2xes.png) shows four distinct peaks in time > domain at 2:15, 2:48, 3:21 and 3:54 UT, which should correspond to the > a-priori unknown start times of John's Opera sequences. The repetition > period was apparently 32.92 minutes. As the DC component in the reference > waveform had not been removed, the peaks are riding on a pedestal caused by > the self-correlation of the carrier component. > > To check the ability to identify an unknown station, the correlation to a > different callsign was also plotted (WD2XGJ just as an arbitrary example, > see xes_correlation_wrongcode). In spite of the weak cross-correlation > peaks, we find that a correct selection from a list of potential candidates > would certainly be feasible. > > It would not be too difficult to automate this process and create an > "Opera deep search" software, which should be able to detect and identify > signals reliably down to about 12 dB below the threshold of the current > Opera decoder. This means at same sensitivity we could go 16 times faster! > > To reap this benefit, the following prerequisits need to be fulfilled: > - As we need a carrier component, transmit keying has to be phase > coherent. Thus simple keying schemes which interrupt the oscillator or > divider would not work. > - as we look at phase-sensitive integration over the whole sequence rather > than a single symbol duration, the frequency stability has to be much > tighter. > - As there is no bit-wise decoding involved, we will need to supply a list > of potential candidate callsigns (similar to deep-search in K1JT EME modes). > > Thanks again to John and Warren for the signals! > > Best 73, > > Markus > (DF6NM in JN59NJ) > > -- http://g3xbm-qrp.blogspot.com/ http://www.g3xbm.co.uk https://sites.google.com/site/sub9khz/ http://qss2.blogspot.com/ --00151747b74412f1d404c853dc0b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This is beyond my simple brain Marcus (!) but I'm impressed that such p= rocessing could allow even weaker signals to be copied.

I think tha= t what you are saying is that with very accurate timing (as in WSPR) it sho= uld be possible to identify a callsign in OPERA by correlating it against a= known list of possible callsigns stored locally and by this means the proc= ess of identifying the call can be achieved with lower S/N, or more quickly= , or both?

It suggests there are still opportunities to develop yet better weak si= gnal modes that get even closer to the theoretical limits for data transmis= sion. I guess the goal is to be able to exchange a minimal data QSO in a ti= me-frame consistent with the propagation medium remaining "open" = i.e. for long DX paths to VK, YV, W etc

73s
Roger G3XBM


On 27 August 2= 012 23:22, Markus Vester <markusvester@aol.com> wrote:
Recently I have been pondering wether it is=20 possible to detect QRSS or Opera transmissions by signal correlation agains= t a=20 known waveform. This should far be more sensitive than the conventional=20 incoherent decoding process. John's stable and phase-coherent Opera tra= nsmission=20 last night's provided a welcome opportunity to test this scheme.=
=A0
Using SndInput from DL4YHF, I recorded a long IQ= =20 file at 2 samples / second, ie. 2 Hz wide centered on 137561 Hz. The audio = was=20 taken straight from the Rubidium-locked receiver, with no noise blanking=20 inserted. The data was then postprocessed using a MathCad spreadsheet. Some= =20 results can be viewed in
http://df6nm.bplaced.net/opera/xes/=20 ,
along with TA grabber screenshots showing both XGJ and a weak trace fr= om=20 XES in 21 mHz FFT (testTA.jpg).
=A0
First a high resolution spectrogram was generated= ,=20 at 1.9 mHz per bin (xes_spectrogram.png). The central carrier component of = the=20 transmission can clearly be seen. Best SNR occured between 3:30 and 4:30 UT= (as=20 indicated by marker ticks), when the peak was 9.0 dB above the noise=20 (xes_spectrum.png). Scaling noise bandwidth from 2.9 mHz to 2.5 kHz (-49.5 = dB),=20 and adding 6 dB for 50% duty cycle, we get a peak-power SNR of -44.5 dB. Th= is=20 corresponds to -48.5 dB on the Opera SNR scale, about 9 dB below the curren= t=20 decoding threshold for Op-32.
=A0
The peak appeared about 0.2 Hz off-center because= =20 the 12 kHz samplerate had not been not calibrated. Once the peak frequency = is=20 accurately identified, the received signal can be correlated against a=20 "prototype" waveform, which contains the Opera sequence for WD2XE= S, 16-fold=20 oversampled. The correlation is efficiently implemented as a multiplication= in=20 Fourier space.
=A0
The result (xes_correlation_wd2xes.png) shows fou= r=20 distinct peaks in time domain at 2:15, 2:48, 3:21 and 3:54 UT, which should= =20 correspond to the a-priori unknown start times of John's Opera sequence= s. The=20 repetition period was apparently 32.92 minutes. As the DC component in the= =20 reference waveform had not been removed, the peaks are riding on a pedestal= =20 caused by the self-correlation of the carrier component.
=A0
To check the ability to identify an unknown=20 station, the correlation to a different callsign was also plotted (WD2XGJ j= ust=20 as an arbitrary example, see xes_correlation_wrongcode). In spite of the we= ak=20 cross-correlation peaks, we find that a correct selection from a list of=20 potential candidates would certainly be feasible.
=A0
It would not be too difficult to automate this=20 process and create an "Opera deep search" software, which should = be able to=20 detect and identify signals reliably down to about 12 dB below the threshol= d of=20 the current Opera decoder. This means at same sensitivity=A0 we could go 16= =20 times faster!
=A0
To reap this benefit, the following prerequisits= =20 need to be fulfilled:
- As we need a carrier component, transmit keying = has=20 to be phase coherent. Thus simple keying schemes which interrupt the oscill= ator=20 or divider would not work.
- as we look at phase-sensitive integration o= ver=20 the whole sequence rather than a single symbol duration, the frequency stab= ility=20 has to be much tighter.
- As there is no bit-wise decoding involved, we = will=20 need to supply a list of potential candidate callsigns (similar to deep-sea= rch=20 in K1JT EME modes).
=A0
Thanks again to John and Warren for the=20 signals!
=A0
Best 73,
=A0
Markus
(DF6NM in=20 JN59NJ)
=A0



--
http://g3xbm-qrp.blogspot.com/
http://ww= w.g3xbm.co.uk
https:= //sites.google.com/site/sub9khz/
http://qss2.blogspot.co= m/

--00151747b74412f1d404c853dc0b--