Delivered-To: daveyxm@virginmedia.com Received: by 10.50.96.198 with SMTP id du6csp133002igb; Fri, 18 Oct 2013 09:32:01 -0700 (PDT) X-Received: by 10.152.30.74 with SMTP id q10mr2500761lah.27.1382113920471; Fri, 18 Oct 2013 09:32:00 -0700 (PDT) Return-Path: Received: from post.thorcom.com (post.thorcom.com. [195.171.43.25]) by mx.google.com with ESMTP id k4si1206851lah.75.2013.10.18.09.31.59 for ; Fri, 18 Oct 2013 09:32:00 -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 1VXCv7-0007Tq-8F for rs_out_1@blacksheep.org; Fri, 18 Oct 2013 17:29:01 +0100 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1VXCv6-0007Th-JB for rsgb_lf_group@blacksheep.org; Fri, 18 Oct 2013 17:29:00 +0100 Received: from smtpout5.wanadoo.co.uk ([80.12.242.80] helo=smtpout.wanadoo.co.uk) by relay1.thorcom.net with esmtp (Exim 4.77) (envelope-from ) id 1VXCv3-0000XJ-Pd for rsgb_lf_group@blacksheep.org; Fri, 18 Oct 2013 17:28:59 +0100 Received: from AGB ([95.145.208.175]) by mwinf5d66 with ME id egUt1m00T3nbvyP03gUt8J; Fri, 18 Oct 2013 18:28:56 +0200 Message-ID: <2A50C7B96485434983B3AFAD5AC1432F@AGB> From: "Graham" To: References: <000701cecb29$d06ee7f0$6401a8c0@JAYDELL> <525FCC72.3080506@iup.uni-heidelberg.de> <002001cecb35$90568ea0$6d01a8c0@DELL4> <525FFA57.1020001@iup.uni-heidelberg.de> <525FFAD3.2000406@iup.uni-heidelberg.de> <005401cecb51$fb859bf0$6d01a8c0@DELL4> <52608759.1070509@iup.uni-heidelberg.de> <526090AA.20402@iup.uni-heidelberg.de> <003101cecbab$78a2e2b0$6401a8c0@JAYDELL> <52611614.7090703@charter.net> <52612B46.4020701@iup.uni-heidelberg.de> In-Reply-To: Date: Fri, 18 Oct 2013 17:23:08 +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: Both ROS Hf/Mf data modes and Opera , s/n measurements use the path-sim simulator as the calibration reference , which is higher than the levels produced by fldigi / wspr etc , ie transmission needs less power to give the same db level [...] 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.80 listed in list.dnswl.org] 0.0 HTML_MESSAGE BODY: HTML included in message X-Scan-Signature: da503d40de1d15ba476c143c8a26a457 Subject: Re: LF: T/A OPDS DK7FC Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CA_01CECC26.B6753040" 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 Status: O X-Status: X-Keywords: X-UID: 3035 This is a multi-part message in MIME format. ------=_NextPart_000_00CA_01CECC26.B6753040 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Both ROS Hf/Mf data modes and Opera , s/n measurements use the = path-sim simulator as the calibration reference , which is higher = than the levels produced by fldigi / wspr etc , ie transmission = needs less power to give the same db level=20 May be Stefan could run OP4 on 136 at 100% duty cycle for one = session , that would give the first 'real' qsb profile of the TA = path with a delta T of 240 seconds ? (but give some warning if it happens !) 73-G,=20 http://www.moetronix.com/ae4jy/pathsim.htm From: Markus Vester=20 Sent: Friday, October 18, 2013 4:41 PM To: rsgb_lf_group@blacksheep.org=20 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.=20 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=E9'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 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=E4fer=20 Sent: Friday, October 18, 2013 2:36 PM To: rsgb_lf_group@blacksheep.org=20 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 96% = 20.6dB 2013-10-18 04:29:25 DK7FC 5981km 137560.016Hz 2mHz -44.8dBOp 96% = 17.8dB 2013-10-18 03:49:23 DK7FC 5981km 137560.016Hz 2mHz -44.0dBOp 96% = 20.3dB 2013-10-18 03:09:23 DK7FC 5981km 137560.017Hz 2mHz -43.7dBOp 96% = 19.0dB 2013-10-18 02:29:23 DK7FC 5981km 137560.016Hz 3mHz -47.5dBOp 96% = 17.9dB 2013-10-18 01:49:23 DK7FC 5981km 137560.016Hz 3mHz -46.4dBOp 80% = 16.8dB John, W1TAG ------=_NextPart_000_00CA_01CECC26.B6753040 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Both ROS   Hf/Mf data  modes and  Opera  , = s/n  measurements  use  the  path-sim  = simulator =20 as  the  calibration  reference , which is  higher = than=20 the  levels  produced  by   fldigi / = wspr etc=20  , ie  transmission  needs  less  power = to  give=20 the  same  db level
 
May  be Stefan  could  run  OP4  = on 136=20 at  100%  duty cycle  for  one  = session ,=20 that  would  give  the  first 'real' qsb  = profile =20 of the  TA  path  with a  delta T of  240  = seconds=20 ?
 
(but  give  some  warning if it happens !)
 
73-G,
 
http://www.moetronix.= com/ae4jy/pathsim.htm
 
 

From: Markus Vester
Sent: Friday, October 18, 2013 4:41 PM
To: rsgb_lf_group@blacksheep.org= =20
Subject: Re: LF: T/A OPDS DK7FC

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

From: Stefan = Sch=E4fer
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=20 the results. Why is it only 96% and what is the meaning of 2 mHz = here?
Seems=20 the S/N is rather low. Condx must have been poor.
Were there other = reports=20 from US stns?

73, Stefan/DK7FC

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

Results from last=20 night:

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

------=_NextPart_000_00CA_01CECC26.B6753040--