Return-Path: Received: from post.thorcom.com (post.thorcom.com [195.171.43.25]) by mtain-mp04.r1000.mx.aol.com (Internet Inbound) with ESMTP id A0BD538092940; Tue, 28 Aug 2012 15:20:28 -0400 (EDT) Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1T6RJY-00044X-DV for rs_out_1@blacksheep.org; Tue, 28 Aug 2012 20:19:04 +0100 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1T6RJX-00044O-3m for rsgb_lf_group@blacksheep.org; Tue, 28 Aug 2012 20:19:03 +0100 Received: from smtpout1.wanadoo.co.uk ([80.12.242.29] helo=smtpout.wanadoo.co.uk) by relay1.thorcom.net with esmtp (Exim 4.77) (envelope-from ) id 1T6RJU-0007ZI-7L for rsgb_lf_group@blacksheep.org; Tue, 28 Aug 2012 20:19:02 +0100 Received: from AGB ([2.26.21.90]) by mwinf5d01 with ME id sKJy1j0071wcuYa03KJyL8; Tue, 28 Aug 2012 21:18:59 +0200 Message-ID: <1E2FDCC0010148D7AEA3B52B1F7AD2FB@AGB> From: "Graham" To: References: <1067FFBBAFB14287AD6D816189F51B78@White> <004d01cd8529$0baa83d0$0501a8c0@xphd97xgq27nyf> <24067C8AEE7D47088C54E354FE436A6E@AGB> <006b01cd8549$66e78c50$0501a8c0@xphd97xgq27nyf> <503D13F1.7020904@iup.uni-heidelberg.de> In-Reply-To: <503D13F1.7020904@iup.uni-heidelberg.de> Date: Tue, 28 Aug 2012 20:18:58 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Spam-Score: 0.0 (/) 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: There you are Mal , we now have 2 members of the CFRD group ! G :-0)) From: Stefan Schäfer Sent: Tuesday, August 28, 2012 7:54 PM To: rsgb_lf_group@blacksheep.org Subject: Re: LF: Re: WD2XES - Opera detected and identified by correlation [...] Content analysis details: (0.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.12.242.29 listed in list.dnswl.org] 0.0 HTML_MESSAGE BODY: HTML included in message X-Scan-Signature: 826f0ea42f5cf3c84a6f3a877245ef10 Subject: Re: LF: Re: WD2XES - Opera detected and identified by correlation Content-Type: multipart/alternative; boundary="----=_NextPart_000_0105_01CD855A.5ACE9010" 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-sid: 3039ac1dc148503d19fb5288 X-AOL-IP: 195.171.43.25 X-AOL-SPF: domain : blacksheep.org SPF : none This is a multi-part message in MIME format. ------=_NextPart_000_0105_01CD855A.5ACE9010 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There you are Mal , we now have 2 members of the CFRD group = ! G :-0)) From: Stefan Sch=E4fer=20 Sent: Tuesday, August 28, 2012 7:54 PM To: rsgb_lf_group@blacksheep.org=20 Subject: Re: LF: Re: WD2XES - Opera detected and identified by = correlation Better let them play the destructive game in the other group. It shows = them what they are. Doubling the number of emails of the last 7 days by = writing 10 emails about their biggest problem. Carefully read about the = ham spirit there. Poor minds. Not worth to support in any way. 73, Stefan/DK7FC Am 28.08.2012 20:17, schrieb mal hamilton:=20 Graham You put out a respectable signal on OPERA and CW so I vote for you. = The loudest BS critics seem to be having teething troubles producing = signals on LF/MF. One very vocal critic about BS is still actually = posting on this reflector, this has got me puzzled.=20 In fact they are all tuned into BS for the latest Information es = Education, something you will not get elswhere about LF/MF. The other reflector is all about picture postcards and publicity = stunts and appearls more to the Appliance Operator g3kev ----- Original Message -----=20 From: Graham=20 To: rsgb_lf_group@blacksheep.org=20 Sent: Tuesday, August 28, 2012 4:47 PM Subject: Re: LF: Re: WD2XES - Opera detected and identified by = correlation Interesting analogy Mal ! may be we should start a CFRD = group , Campaign For Real Data ? you can the 'KEY' person : )=20 G.. From: mal hamilton=20 Sent: Tuesday, August 28, 2012 3:22 PM To: rsgb_lf_group@blacksheep.org=20 Subject: LF: Re: WD2XES - Opera detected and identified by = correlation Markus This is what the CW es QRS operator are already doing. They have a = list of known operators Callisgns and a mental list of what the text is = going to be, like RST, OOO, MMM etc, Names, QRA locator etc. If a = piece of callsign or text fades out in QSB or hit by QRN then it is easy = to insert the missing digit. In other words what is being received is being compared against = already known information should it become necessary to use it. This works on LF because of the few operators on the band but would = not work on HF where there are hundreds of callsigns to pick from. mal/g3kev ----- Original Message -----=20 From: Markus Vester=20 To: rsgb_lf_group@blacksheep.org=20 Sent: Monday, August 27, 2012 10:22 PM Subject: LF: WD2XES - Opera detected and identified by correlation 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=20 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!=20 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=20 (DF6NM in JN59NJ) ------=_NextPart_000_0105_01CD855A.5ACE9010 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
There  you  are  Mal  , we  now =20 have   2  members  of the  CFRD   = group =20 !
 
G  :-0))

From: Stefan = Sch=E4fer
Sent: Tuesday, August 28, 2012 7:54 PM
Subject: Re: LF: Re: WD2XES - Opera detected and identified = by=20 correlation

Better let them play the destructive game in the other = group. It=20 shows them what they are. Doubling the number of emails of the last 7 = days by=20 writing 10 emails about their biggest problem. Carefully read about the = ham=20 spirit there. Poor minds. Not worth to support in any way.

73,=20 Stefan/DK7FC

Am 28.08.2012 20:17, schrieb mal hamilton:=20
Graham
You put out a respectable signal on OPERA and = CW so I=20 vote for you. The loudest BS critics seem to be having teething = troubles=20 producing signals on LF/MF. One very vocal critic about BS is still = actually=20 posting on this reflector, this has got me puzzled.
In fact they are all tuned into BS for the = latest=20 Information es Education, something you will not get elswhere about=20 LF/MF.
The other reflector is all about picture = postcards and=20 publicity stunts and appearls more to the Appliance = Operator
 
 
g3kev
 
-----=20 Original Message ----- From:=20 Graham To:=20 rsgb_lf_group@blacksheep.org Sent:=20 Tuesday, August 28, 2012 4:47 PM Subject:=20 Re: LF: Re: WD2XES - Opera detected and identified by = correlation

Interesting   analogy  Mal !  = may  =20 be  we  should  start  a  CFRD  =20 group , Campaign  For  Real  Data ? you  = can =20 the  'KEY'   person : )
 
G..

From: mal = hamilton=20
Sent: Tuesday, August 28, 2012 3:22 PM
Subject: LF: Re: WD2XES - Opera detected and identified = by=20 correlation

Markus
This is what the CW es QRS operator are = already doing.=20 They have a list of known operators Callisgns and a mental list of = what the=20 text is going to be,   like RST, OOO, MMM etc, = Names, QRA=20 locator etc. If a piece of callsign or text fades out in = QSB or=20 hit by QRN then it is easy to insert the=20 missing digit.
In other words what is being received is = being=20 compared against already known information should it become = necessary=20 to use it.
This works on LF because of the few = operators on the=20 band but would not work on HF where there are hundreds of callsigns = to pick=20 from.
mal/g3kev
 
-----=20 Original Message ----- From:=20 Markus Vester To:=20 rsgb_lf_group@blacksheep.org Sent:=20 Monday, August 27, 2012 10:22 PM Subject:=20 LF: WD2XES - Opera detected and identified by correlation

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