Delivered-To: daveyxm@virginmedia.com Received: by 10.50.96.198 with SMTP id du6csp152135igb; Fri, 18 Oct 2013 15:00:07 -0700 (PDT) X-Received: by 10.152.22.97 with SMTP id c1mr3270259laf.31.1382133607133; Fri, 18 Oct 2013 15:00:07 -0700 (PDT) Return-Path: Received: from post.thorcom.com (post.thorcom.com. [195.171.43.25]) by mx.google.com with ESMTP id k4si1633269lah.105.2013.10.18.15.00.06 for ; Fri, 18 Oct 2013 15:00:07 -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 1VXI4c-0000yf-UN for rs_out_1@blacksheep.org; Fri, 18 Oct 2013 22:59:10 +0100 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1VXI4c-0000yW-4S for rsgb_lf_group@blacksheep.org; Fri, 18 Oct 2013 22:59:10 +0100 Received: from relay2.uni-heidelberg.de ([129.206.210.211]) by relay1.thorcom.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1VXI4Z-0001cW-Jc for rsgb_lf_group@blacksheep.org; Fri, 18 Oct 2013 22:59:09 +0100 Received: from freitag.iup.uni-heidelberg.de (freitag.iup.uni-heidelberg.de [129.206.29.204]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id r9ILx6Bb032657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 18 Oct 2013 23:59:07 +0200 Received: from [129.206.22.206] (pc206.iup.uni-heidelberg.de [129.206.22.206]) by freitag.iup.uni-heidelberg.de (8.12.11.20060308/8.11.2) with ESMTP id r9ILx6cZ022867 for ; Fri, 18 Oct 2013 23:59:06 +0200 Message-ID: <5261AF25.30205@iup.uni-heidelberg.de> Date: Fri, 18 Oct 2013 23:59:01 +0200 From: =?UTF-8?B?U3RlZmFuIFNjaMOkZmVy?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: rsgb_lf_group@blacksheep.org References: <001601cecc44$3539dcb0$6d01a8c0@DELL4> <001201cecc49$629c4350$6401a8c0@JAYDELL> In-Reply-To: X-Spam-Score: -2.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: Jay, John, LF, ...so it is another OPDS32 night? Or are you prepared for both, OPDS32 and OPDS8 ? 73, Stefan [...] Content analysis details: (-2.7 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium trust [129.206.210.211 listed in list.dnswl.org] -0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.0 HTML_MESSAGE BODY: HTML included in message X-Scan-Signature: b2d5972cffc09bc55071138bfa4f6e53 Subject: Re: LF: T/A OPDS DK7FC Content-Type: multipart/alternative; boundary="------------020001020804090806050806" 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 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: 3038 This is a multi-part message in MIME format. --------------020001020804090806050806 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by relay2.uni-heidelberg.de id r9ILx6Bb032657 Jay, John, LF, ...so it is another OPDS32 night? Or are you prepared for both, OPDS32=20 and OPDS8 ? 73, Stefan Am 18.10.2013 23:43, schrieb John Andrews: > My setup is running, but I can't check or modify it until Saturday=20 > 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=20 >> ... so my reported SNR numbers should not be considered accurate. The=20 >> issue is now resolved and the setup is running. Hope to catch both=20 >> Stefan and Markus tonight ... maybe VO1NA can be encouraged to join=20 >> in as well. Have only received Joe's OPDS32 on one ocassion several=20 >> 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 sensitivi= ty. >> 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 be tracked faster or even on a dash-by-dash basis, which is >> much less efficient. >> The "dBOp" column is showing SNR according to Jos=C3=A9's Opera sc= ale, >> which is approximately based on average power. It shows 4 dB more >> negative values than the standard WSPR scale, ie. carrier power >> in 2.5 kHz. A marginally decode with WSPR-15 would need -38 dB, >> and an Opera signal with same PEP would then show as -42 dBOp. >> For a coherent signal, the Opds-32 threshold should be around -50 >> dBOp, which in theory is 8 dB better than WSPR-15 and 11 dB >> better than standard Opera-32. >> Please be aware that the SNR figures shown in opds results can >> sometimes be inaccurate. With an incoherent signal, often not all >> of the carrier power is captured during the bandwidth >> measurement, producing a low or invalid SNR reading. The SNR >> measurement also doesn't work well for strong signals (> -20 >> dBOp), eg for DK7FC who should really be plus several dB here. >> 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 stations received Bob well on 74 kHz, little or >> nothing at all apperared on Hartmut's and my 74 kHz grabbers. >> Best 73, >> Markus (DF6NM) >> PS The weather has improved here, so I have put out the TX >> antenna for a possible joint TA session tonight. >> >> *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 >> >> Hi John, Jay, Markus, >> >> OK. Well, it seems to work. But i can't value the results. Why is >> it only 96% 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? >> >> 73, Stefan/DK7FC >> >> Am 18.10.2013 13:05, schrieb John Andrews: >> Stefan, Markus, Jay, >> >> Results from last night: >> >> 2013-10-18 05:09:25 DK7FC 5981km 137560.016Hz 2mHz -42.8dBOp=20 >> 96% 20.6dB >> 2013-10-18 04:29:25 DK7FC 5981km 137560.016Hz 2mHz -44.8dBOp=20 >> 96% 17.8dB >> 2013-10-18 03:49:23 DK7FC 5981km 137560.016Hz 2mHz -44.0dBOp=20 >> 96% 20.3dB >> 2013-10-18 03:09:23 DK7FC 5981km 137560.017Hz 2mHz -43.7dBOp=20 >> 96% 19.0dB >> 2013-10-18 02:29:23 DK7FC 5981km 137560.016Hz 3mHz -47.5dBOp=20 >> 96% 17.9dB >> 2013-10-18 01:49:23 DK7FC 5981km 137560.016Hz 3mHz -46.4dBOp=20 >> 80% 16.8dB >> John, W1TAG >> --------------020001020804090806050806 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by relay2.uni-heidelberg.de id r9ILx6Bb032657 Jay, John, LF,

...so it is another OPDS32 night? Or are you prepared for both, OPDS32 and OPDS8 ?

73, Stefan

Am 18.10.2013 23:43, schrieb John Andrews:
My setup is running, but I can't check or modify it until Saturday afternoon.=C2=A0

John, W1TAG



On Oct 18, 2013, at 5:31 PM, <jrusgrove@comcast.net> wrote:

T/A OPDS enthusiasts
=C2=A0
It appears=C2=A0that I=C2=A0mist= akenly ran with a known=C2=A0setup issue last night ...=C2=A0so my reported SNR=C2=A0= numbers should not be considered accurate. The issue is now resolved and=C2=A0the setup is running.=C2=A0Hope 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.
=C2=A0
Jay W1VD=C2=A0 WD2XNS=C2=A0 WE2X= GR/2=C2=A0 WG2XRS/2=C2=A0=C2=A0
=C2=A0
----- Original Message -----
Sent: Friday, October 18, 2013 11:41 AM
Subject: Re: LF: T/A OPDS DK7FC

Stefan, Jay, John,
=C2=A0
the "96%" number shows the temporal overlap between the receive period (ie the duration of the=C2=A0currently used=C2=A0FFT, about 35 minutes) and the=C2=A0identifi= ed Op sequence (33 minutes). With=C2=A010 minutes spacing between subsequent FF= Ts, the sequence does not always fit completely into one of the=C2=A0slots. s= o it says that 96% of the sequence was included in the evaluation. However the missing part=C2=A0has only neglegible impact on the detection sensitivity.
=C2=A0
Ideally Opera=C2=A0can be trea= ted=C2=A0as 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=C2=A0and phase coherent signals consistently sho= w less than 3 mHz bandwidth. An intermediate width=C2=A0up to about 30 mHz=C2=A0typically indicates a coherent signal=C2=A0but with a slight the= rmal drift. Even higher bandwidth (~ 100 mHz) are mostly=C2=A0due to=C2=A0inco= herent keying, ie random phase dashes caused by stopping the TX oscillator or divider during gaps.
=C2=A0
Opds internally uses an "autofocus" concept similar to synchroneous demodulation, where the central spectral peak is used as a phase reference.=C2=A0Narrower carriers=C2=A0produce=C2=A0better demodulated SNR. For fading or incohere= nt signals, the phase has to be tracked faster or even on a dash-by-dash basis, which is much less efficient.
=C2=A0
The "dBOp" column is showing S= NR according to Jos=C3=A9's Opera scale, which is approximately based on average power. It shows 4 dB more negative values than the standard WSPR scale, ie. carrier power in 2.5 kHz. A marginally decode with WSPR-15 would need -38 dB, and=C2=A0an Opera signal with same PEP would t= hen show as -42 dBOp. For a coherent signal, the Opds-32 threshold should be=C2=A0around -50 dBOp, which in theory is 8 dB better than WSPR-15 and = 11 dB better than standard Opera-32.
=C2=A0
Please be aware that the SNR figures shown in opds results=C2=A0can sometimes be inaccurate. With an incoherent signal,=C2=A0often not all of the carrier power is captured during the bandwidth measurement, producing=C2=A0a low or invalid SNR reading.=C2=A0The=C2=A0SNR measurement also doesn't work well for strong = signals (> -20 dBOp), eg for DK7FC who should really be plus several dB here.<= /font>
=C2=A0
So why was Stefan's TA signal not stronger last night? My guess is that=C2=A0TA propagation just didn't extend=C2=A0into central Europe: While UK and duch stations received Bob well on 74 kHz, little or nothing at all apperared=C2=A0on Hartmut's and = my 74 kHz grabbers.
=C2=A0
Best 73,
Markus (DF6NM)
=C2=A0
PS The weather=C2=A0has=C2=A0i= mproved here, so=C2=A0I have put out the TX antenna for a possible joint TA sessi= on tonight.
=C2=A0

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 value the results. Why is it only 96% 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?

73, Stefan/DK7FC

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

Results from last night:

2013-10-18 05:09:25 DK7FC=C2=A0=C2=A0 5981km 137560.016Hz=C2=A0=C2=A0 2mH= z -42.8dBOp=C2=A0 96% 20.6dB
2013-10-18 04:29:25 DK7FC=C2=A0=C2=A0 5981km 137560.016Hz=C2=A0=C2=A0 2mH= z -44.8dBOp=C2=A0 96%=C2=A017.8dB
2013-10-18 03:49:23 DK7FC=C2=A0=C2=A0 5981km 137560.016Hz=C2=A0=C2=A0 2mH= z -44.0dBOp=C2=A0 96%=C2=A020.3dB
2013-10-18 03:09:23 DK7FC=C2=A0=C2=A0 5981km 137560.017Hz=C2=A0=C2=A0 2mH= z -43.7dBOp=C2=A0 96%=C2=A019.0dB
2013-10-18 02:29:23 DK7FC=C2=A0=C2=A0 5981km 137560.016Hz=C2=A0=C2=A0 3mH= z -47.5dBOp=C2=A0 96%=C2=A017.9dB
2013-10-18 01:49:23 DK7FC=C2=A0=C2=A0 5981km 137560.016Hz=C2=A0=C2=A0 3mH= z -46.4dBOp=C2=A0 80%=C2=A016.8dB
John, W1TAG

--------------020001020804090806050806--