Delivered-To: daveyxm@virginmedia.com Received: by 10.50.96.198 with SMTP id du6csp151973igb; Fri, 18 Oct 2013 14:56:09 -0700 (PDT) X-Received: by 10.180.210.231 with SMTP id mx7mr1085269wic.5.1382133369131; Fri, 18 Oct 2013 14:56:09 -0700 (PDT) Return-Path: Received: from post.thorcom.com (post.thorcom.com. [195.171.43.25]) by mx.google.com with ESMTP id bf10si1258159wjc.69.2013.10.18.14.56.08 for ; Fri, 18 Oct 2013 14:56:09 -0700 (PDT) Received-SPF: neutral (google.com: 195.171.43.25 is neither permitted nor denied by best guess record for domain of owner-rsgb_lf_group@blacksheep.org) client-ip=195.171.43.25; Authentication-Results: mx.google.com; spf=neutral (google.com: 195.171.43.25 is neither permitted nor denied by best guess record for domain of owner-rsgb_lf_group@blacksheep.org) smtp.mail=owner-rsgb_lf_group@blacksheep.org Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1VXHpO-0000kg-Rr for rs_out_1@blacksheep.org; Fri, 18 Oct 2013 22:43:26 +0100 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1VXHpO-0000kX-3r for rsgb_lf_group@blacksheep.org; Fri, 18 Oct 2013 22:43:26 +0100 Received: from mta41.charter.net ([216.33.127.83]) by relay1.thorcom.net with esmtp (Exim 4.77) (envelope-from ) id 1VXHpL-0001XH-HK for rsgb_lf_group@blacksheep.org; Fri, 18 Oct 2013 22:43:25 +0100 Received: from imp11 ([10.20.200.11]) by mta41.charter.net (InterMail vM.8.01.05.02 201-2260-151-103-20110920) with ESMTP id <20131018214322.NMMP10143.mta41.charter.net@imp11> for ; Fri, 18 Oct 2013 17:43:22 -0400 Received: from [97.254.138.97] ([97.254.138.97]) by imp11 with smtp.charter.net id eljL1m00126GP4105ljMZZ; Fri, 18 Oct 2013 17:43:22 -0400 X-Authority-Analysis: v=2.0 cv=KYGKKnkD c=1 sm=1 a=UHaukTKBffJg1JmW3+6sgA==:17 a=yUnIBFQkZM0A:10 a=hOpmn2quAAAA:8 a=tPJ8SdEQLfoA:10 a=C_IRinGWAAAA:8 a=F3M5lZpKAAAA:8 a=TG-S7uPpTbStc5zdOU8A:9 a=QEXdDO2ut3YA:10 a=si9q_4b84H0A:10 a=wk6s2zzMB60A:10 a=cJJkxSS06edbFJ2O:21 a=Wrs1EDa7xWIsow34:21 a=3oc9M9_CAAAA:8 a=lTuRS67mhaqjK8NmWUoA:9 a=_W_S_7VecoQA:10 a=U8Ie8EnqySEA:10 a=CPv2ndZO_48fCI5K:21 a=UHaukTKBffJg1JmW3+6sgA==:117 X-Auth-id: dzF0YWdAY2hhcnRlci5uZXQ= References: <001601cecc44$3539dcb0$6d01a8c0@DELL4> <001201cecc49$629c4350$6401a8c0@JAYDELL> From: John Andrews X-Mailer: iPhone Mail (11A501) In-Reply-To: <001201cecc49$629c4350$6401a8c0@JAYDELL> Message-Id: Date: Fri, 18 Oct 2013 17:43:18 -0400 To: "rsgb_lf_group@blacksheep.org" Mime-Version: 1.0 (1.0) X-Spam-Score: -0.4 (/) 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: My setup is running, but I can't check or modify it until Saturday afternoon. John, W1TAG > On Oct 18, 2013, at 5:31 PM, wrote: > > T/A OPDS enthusiasts > > It appears that I mistakenly ran with a known setup issue last night ... so my reported SNR numbers should not be considered accurate. The issue is now resolved and the setup is running. Hope to catch both Stefan and Markus tonight ... maybe VO1NA can be encouraged to join in as well. Have only received Joe's OPDS32 on one ocassion several weeks back. > > Jay W1VD WD2XNS WE2XGR/2 WG2XRS/2 > > ----- Original Message ----- > From: Markus Vester > To: rsgb_lf_group@blacksheep.org > Sent: Friday, October 18, 2013 11:41 AM > Subject: Re: LF: T/A OPDS DK7FC > > Stefan, Jay, John, > > the "96%" number shows the temporal overlap between the receive period (ie the duration of the currently used FFT, about 35 minutes) and the identified Op sequence (33 minutes). With 10 minutes spacing between subsequent FFTs, the sequence does not always fit completely into one of the slots. so it says that 96% of the sequence was included in the evaluation. However the missing part has only neglegible impact on the detection sensitivity. > > Ideally Opera can be treated as an AM signal, with a central carrier and modulation sidebands around it. The "2mHz" bandwidth figure refers to the bandwidth of the carrier, which should be as small as possible. Opds applies some smoothing to the power spectrum and then tries to measure the -10 dB bandwidth of the central peak. Stable and phase coherent signals consistently show less than 3 mHz bandwidth. An intermediate width up to about 30 mHz typically indicates a coherent signal but with a slight thermal drift. Even higher bandwidth (~ 100 mHz) are mostly due to incoherent keying, ie random phase dashes caused by stopping the TX oscillator or divider during gaps. > > Opds internally uses an "autofocus" concept similar to synchroneous demodulation, where the central spectral peak is used as a phase reference. Narrower carriers produce better demodulated SNR. For fading or incoherent signals, the phase has to [...] Content analysis details: (-0.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [216.33.127.83 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.0 HTML_MESSAGE BODY: HTML included in message 0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars X-Scan-Signature: 48f9f369e416634ea68e1d2c7f17cd5d Subject: Re: LF: T/A OPDS DK7FC Content-Type: multipart/alternative; boundary=Apple-Mail-05B27E16-08C6-4EA7-83FA-76BFFA4E69BE Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on post.thorcom.com X-Spam-Level: X-Spam-Status: No, hits=0.5 required=5.0 tests=HTML_20_30,HTML_MESSAGE, TO_ADDRESS_EQ_REAL 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 Status: O X-Status: X-Keywords: X-UID: 3037 --Apple-Mail-05B27E16-08C6-4EA7-83FA-76BFFA4E69BE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable My setup is running, but I can't check or modify it until Saturday afternoon= .=20 John, W1TAG > On Oct 18, 2013, at 5:31 PM, wrote: >=20 > T/A OPDS enthusiasts > =20 > It appears that I mistakenly ran with a known setup issue last night ... s= o my reported SNR numbers should not be considered accurate. The issue is no= w resolved and the setup is running. Hope to catch both Stefan and Markus to= night ... maybe VO1NA can be encouraged to join in as well. Have only receiv= ed Joe's OPDS32 on one ocassion several weeks back. > =20 > Jay W1VD WD2XNS WE2XGR/2 WG2XRS/2 =20 > =20 > ----- Original Message ----- > From: Markus Vester > To: rsgb_lf_group@blacksheep.org > Sent: Friday, October 18, 2013 11:41 AM > Subject: Re: LF: T/A OPDS DK7FC >=20 > Stefan, Jay, John, > =20 > the "96%" number shows the temporal overlap between the receive period (ie= the duration of the currently used FFT, about 35 minutes) and the identifie= d Op sequence (33 minutes). With 10 minutes spacing between subsequent FFTs,= the sequence does not always fit completely into one of the slots. so it sa= ys that 96% of the sequence was included in the evaluation. However the miss= ing part has only neglegible impact on the detection sensitivity. > =20 > Ideally Opera can be treated as an AM signal, with a central carrier and m= odulation sidebands around it. The "2mHz" bandwidth figure refers to the ban= dwidth of the carrier, which should be as small as possible. Opds applies so= me smoothing to the power spectrum and then tries to measure the -10 dB band= width of the central peak. Stable and phase coherent signals consistently sh= ow less than 3 mHz bandwidth. An intermediate width up to about 30 mHz typic= ally indicates a coherent signal but with a slight thermal drift. Even highe= r bandwidth (~ 100 mHz) are mostly due to incoherent keying, ie random phase= dashes caused by stopping the TX oscillator or divider during gaps. > =20 > Opds internally uses an "autofocus" concept similar to synchroneous demodu= lation, where the central spectral peak is used as a phase reference. Narrow= er carriers produce better demodulated SNR. For fading or incoherent signals= , the phase has to be tracked faster or even on a dash-by-dash basis, which i= s much less efficient. > =20 > The "dBOp" column is showing SNR according to Jos=C3=A9's Opera scale, whi= ch is approximately based on average power. It shows 4 dB more negative valu= es than the standard WSPR scale, ie. carrier power in 2.5 kHz. A marginally d= ecode with WSPR-15 would need -38 dB, and an Opera signal with same PEP woul= d then show as -42 dBOp. For a coherent signal, the Opds-32 threshold sho= uld be around -50 dBOp, which in theory is 8 dB better than WSPR-15 and 11 d= B better than standard Opera-32. > =20 > Please be aware that the SNR figures shown in opds results can sometimes b= e inaccurate. With an incoherent signal, often not all of the carrier power i= s captured during the bandwidth measurement, producing a low or invalid SNR r= eading. The SNR measurement also doesn't work well for strong signals (> -20= dBOp), eg for DK7FC who should really be plus several dB here. > =20 > So why was Stefan's TA signal not stronger last night? My guess is that TA= propagation just didn't extend into central Europe: While UK and duch stati= ons received Bob well on 74 kHz, little or nothing at all apperared on Hartm= ut's and my 74 kHz grabbers. > =20 > Best 73, > Markus (DF6NM) > =20 > PS The weather has improved here, so I have put out the TX antenna for a p= ossible joint TA session tonight. > =20 >=20 > From: Stefan Sch=C3=A4fer > Sent: Friday, October 18, 2013 2:36 PM > To: rsgb_lf_group@blacksheep.org > Subject: Re: LF: T/A OPDS DK7FC >=20 > Hi John, Jay, Markus, >=20 > OK. Well, it seems to work. But i can't value the results. Why is it only 9= 6% and what is the meaning of 2 mHz here? > Seems the S/N is rather low. Condx must have been poor. > Were there other reports from US stns? >=20 > 73, Stefan/DK7FC >=20 > Am 18.10.2013 13:05, schrieb John Andrews: > Stefan, Markus, Jay, >=20 > Results from last night: >=20 > 2013-10-18 05:09:25 DK7FC 5981km 137560.016Hz 2mHz -42.8dBOp 96% 20.6= dB > 2013-10-18 04:29:25 DK7FC 5981km 137560.016Hz 2mHz -44.8dBOp 96% 17.8= dB > 2013-10-18 03:49:23 DK7FC 5981km 137560.016Hz 2mHz -44.0dBOp 96% 20.3= dB > 2013-10-18 03:09:23 DK7FC 5981km 137560.017Hz 2mHz -43.7dBOp 96% 19.0= dB > 2013-10-18 02:29:23 DK7FC 5981km 137560.016Hz 3mHz -47.5dBOp 96% 17.9= dB > 2013-10-18 01:49:23 DK7FC 5981km 137560.016Hz 3mHz -46.4dBOp 80% 16.8= dB > John, W1TAG >=20 --Apple-Mail-05B27E16-08C6-4EA7-83FA-76BFFA4E69BE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
My setup is running, but I can't check= or modify it until Saturday afternoon. 

John,= W1TAG



On Oct 18, 2013, at 5:31 PM, <= ;jrusgrove@comcast.net> wrot= e:

T/A OPDS enthusiasts
 
It appears that I mistakenly r= an with a=20 known setup issue last night ... so my reported SNR numbers=20= should not be considered accurate. The issue is now resolved and the se= tup=20 is running. Hope to catch both Stefan and Markus tonight ... maybe VO1N= A=20 can be encouraged to join in as well. Have only received Joe's OPDS32 on one= =20 ocassion several weeks back.
 
Jay W1VD  WD2XNS  WE2XGR/2&nb= sp;=20 WG2XRS/2  
 
----- Original Message -----
Sent: Friday, October 18, 2013 11:41 AM
Subject: Re: LF: T/A OPDS DK7FC

Stefan, Jay, John,
 
the "96%" number shows the temporal o= verlap=20 between the receive period (ie the duration of the currently=20 used FFT, about 35 minutes) and the identified Op sequence (33=20= minutes). With 10 minutes spacing between subsequent FFTs, the sequen= ce=20 does not always fit completely into one of the slots. so it says that= 96%=20 of the sequence was included in the evaluation. However the missing=20 part has only neglegible impact on the detection=20 sensitivity.
 
Ideally Opera can be treated&nbs= p;as an AM=20 signal, with a central carrier and modulation sidebands around it. The "2m= Hz"=20 bandwidth figure refers to the bandwidth of the carrier, which should be a= s=20 small as possible. Opds applies some smoothing to the power spectrum and t= hen=20 tries to measure the -10 dB bandwidth of the central peak. Stable and= =20 phase coherent signals consistently show less than 3 mHz bandwidth. An=20 intermediate width up to about 30 mHz typically indicates a cohe= rent=20 signal but with a slight thermal drift. Even higher bandwidth (~ 100 m= Hz)=20 are mostly due to incoherent keying, ie random phase dashes caus= ed=20 by stopping the TX oscillator or divider during gaps.
 
Opds internally uses an "autofocus" c= oncept=20 similar to synchroneous demodulation, where the central spectral peak is u= sed=20 as a phase reference. Narrower carriers produce better=20 demodulated SNR. For fading or incoherent signals, the phase has to be tra= cked=20 faster or even on a dash-by-dash basis, which is much less=20 efficient.
 
The "dBOp" column is showing SNR acco= rding to=20 Jos=C3=A9's Opera scale, which is approximately based on average power. It= shows 4=20 dB more negative values than the standard WSPR scale, ie. carrier power in= 2.5=20 kHz. A marginally decode with WSPR-15 would need -38 dB, and an Opera= =20 signal with same PEP would then show as -42 dBOp. For a coherent signal, t= he=20 Opds-32 threshold should be around -50 dBOp, which in theory is 8 dB=20= better than WSPR-15 and 11 dB better than standard Opera-32.
 
Please be aware that the SNR figures s= hown in=20 opds results can sometimes be inaccurate. With an incoherent=20 signal, often not all of the carrier power is captured during the=20 bandwidth measurement, producing a low or invalid SNR=20 reading. The SNR measurement also doesn't work well for strong=20= signals (> -20 dBOp), eg for DK7FC who should really be plus several dB= =20 here.
 
So why was Stefan's TA signal not str= onger last=20 night? My guess is that TA propagation just didn't extend into=20= central Europe: While UK and duch stations received Bob well on 74 kHz, li= ttle=20 or nothing at all apperared on Hartmut's and my 74 kHz=20 grabbers.
 
Best 73,
Markus (DF6NM)
 
PS The weather has improved= here,=20 so I have put out the TX antenna for a possible joint TA session=20 tonight.
 

Sent: Friday, October 18, 2013 2:36 PM
Subject: Re: LF: T/A OPDS DK7FC

Hi John, Jay, Markus,

OK. Well, it seems to work. But i can't=20= value the results. Why is it only 96% and what is the meaning of 2 mHz=20 here?
Seems the S/N is rather low. Condx must have been poor.
Were t= here=20 other reports from US stns?

73, Stefan/DK7FC

Am 18.10.2013=20= 13:05, schrieb John Andrews:
Stefan, Markus, Jay,

Results from l= ast=20 night:

2013-10-18 05:09:25 DK7FC   5981km=20 137560.016Hz   2mHz -42.8dBOp  96% 20.6dB
2013-10-18=20 04:29:25 DK7FC   5981km 137560.016Hz   2mHz=20 -44.8dBOp  96% 17.8dB
2013-10-18 03:49:23 DK7FC  =20= 5981km 137560.016Hz   2mHz -44.0dBOp =20 96% 20.3dB
2013-10-18 03:09:23 DK7FC   5981km=20 137560.017Hz   2mHz -43.7dBOp  96% 19.0dB
2013-10-1= 8=20 02:29:23 DK7FC   5981km 137560.016Hz   3mHz=20 -47.5dBOp  96% 17.9dB
2013-10-18 01:49:23 DK7FC  =20= 5981km 137560.016Hz   3mHz -46.4dBOp  80% 16.8dB
John, W1TAG

= --Apple-Mail-05B27E16-08C6-4EA7-83FA-76BFFA4E69BE--