Delivered-To: daveyxm@virginmedia.com Received: by 10.50.57.9 with SMTP id e9csp28128igq; Mon, 24 Jun 2013 02:24:04 -0700 (PDT) X-Received: by 10.194.83.195 with SMTP id s3mr16266541wjy.82.1372065844111; Mon, 24 Jun 2013 02:24:04 -0700 (PDT) Return-Path: Received: from post.thorcom.com (post.thorcom.com. [195.171.43.25]) by mx.google.com with ESMTP id p6si3221640wic.54.2013.06.24.02.24.03 for ; Mon, 24 Jun 2013 02:24:04 -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; dkim=pass header.i=@mx.aol.com Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1Ur2Sb-0007Ps-VH for rs_out_1@blacksheep.org; Mon, 24 Jun 2013 09:49:17 +0100 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1Ur2Sb-0007Ph-9L for rsgb_lf_group@blacksheep.org; Mon, 24 Jun 2013 09:49:17 +0100 Received: from omr-m10.mx.aol.com ([64.12.143.86]) by relay1.thorcom.net with esmtp (Exim 4.77) (envelope-from ) id 1Ur2SW-00009x-An for rsgb_lf_group@blacksheep.org; Mon, 24 Jun 2013 09:49:16 +0100 Received: from mtaout-mb03.r1000.mx.aol.com (mtaout-mb03.r1000.mx.aol.com [172.29.41.67]) by omr-m10.mx.aol.com (Outbound Mail Relay) with ESMTP id CF3F370095983 for ; Mon, 24 Jun 2013 04:49:10 -0400 (EDT) Received: from White (188-195-246-26-dynip.superkabel.de [188.195.246.26]) by mtaout-mb03.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPA id 48AD7E000096 for ; Mon, 24 Jun 2013 04:49:10 -0400 (EDT) Message-ID: <5339ECBB17F5438088CEAB6F0FA9B1EC@White> From: "Markus Vester" To: Date: Mon, 24 Jun 2013 10:49:07 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1372063750; bh=CFgLeqNfyp+tQvyR3SIawBYblYM7kAxWAmKhZ3R3fPo=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=FQySQcpZKvUSPekYvJrlBR4FWXOGtjvjLzzXVCxB6esx+gOT0uvUZGUl6kukZtQB2 s4JiBe11L8x98BlU2NWISq8i7lycWOgSnyrfE6QyB97xMqhH78+id1U8dXJCmkW/Bo 5kTw0iEDsLlwJynHYxS9upur+dWXstu5Lo+1Ap9k= X-AOL-SCOLL-SCORE: 0:2:404509344:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d294351c8080605fb X-AOL-IP: 188.195.246.26 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: Last night the EA5HVK Opera decoder and my opds correlation detector ran side by side here on one machine, fed by the same soundcard. Opera got the full passband (136-138.2 kHz) through SpecLab and VAC without further audio processing, whereas the other SpecLab instance for opds had a 160 Hz bandpass filter, noise blanker and audio AGC inserted before the 0.477 mHz FFT. The QRN background from the southeast was generally lower than the night before. [...] Content analysis details: (0.7 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [64.12.143.86 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (markusvester[at]aol.com) -0.0 SPF_PASS SPF: sender matches SPF record -1.1 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 1.8 URIBL_BLACK Contains an URL listed in the URIBL blacklist [URIs: bplaced.net] 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: 52d17ee6003fa6763aae891a69410baf Subject: Re: LF: VO1NA Opera-32 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01CE70C8.73915EC0" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on post.thorcom.com X-Spam-Level: X-Spam-Status: No, hits=0.9 required=5.0 tests=HTML_30_40,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: 3254 Dies ist eine mehrteilige Nachricht im MIME-Format. ------=_NextPart_000_0010_01CE70C8.73915EC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Last night the EA5HVK Opera decoder and my opds correlation detector ran = side by side here on one machine, fed by the same soundcard. Opera got = the full passband (136-138.2 kHz) through SpecLab and VAC without = further audio processing, whereas the other SpecLab instance for opds = had a 160 Hz bandpass filter, noise blanker and audio AGC inserted = before the 0.477 mHz FFT. The QRN background from the southeast was = generally lower than the night before. Results for both are in=20 df6nm.bplaced.net/opera/Opera_vs_opds_screenshot_130624.jpg and a screenshot df6nm.bplaced.net/opera/Opera_vs_opds_screenshot_130624.jpg Although SNR results shown by Opera were consistently better than those = for opds, Opera achieved two only decodes while opds produced ten hits = (including three from VO1NA). I am wondering whether this difference may have been exacerbated by the = regular splatter from DCF39 which is quite strong in central Europe. = This may also have affected the SNR estimates of either program. Maybe = in this situation dedicated preprocessing might be helpful for Opera as = well? We may perhaps speculate that possible DCF suppression may be part of = the loop advantage observed by DF2JP - Joe could you comment on your = loop's orientation?=20 Best 73, Markus (DF6NM) =20 From: Markus Vester=20 Sent: Sunday, June 23, 2013 1:25 PM To: rsgb_lf_group@blacksheep.org ; rsgb_lf_group@yahoogroups.co.uk=20 Subject: Re: LF: VO1NA Opera-32 I have downloaded Opera v1.4.7 from the rosmodem website. It was easy to = configure and is running smoothly in conjunction with SpecLab and VAC-3, = which is needed here to convert from 135.5 to 136.0 kHz LO. With the = waterfall disabled, average CPU usage on the slow Atom Netbook is an = easy 20% from one of two virtual CPU's (10% shown in task manager).=20 Opds is running in parallel from a separate SpecLab instance. A locally = generated test signal showed up both in Opera (-28 dB) and in opds = (-36.4 dB), which means that the first round goes to Jose ;-) I will let = both run for a while, hoping for some weak signals to compare. Best 73, Markus (DF6NM) ------=_NextPart_000_0010_01CE70C8.73915EC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Last night the EA5HVK Opera decoder and = my opds=20 correlation detector ran side by side here on one machine, fed by the = same=20 soundcard. Opera got the full passband (136-138.2 kHz) through SpecLab = and VAC=20 without further audio processing, whereas the other SpecLab instance for = opds=20 had a 160 Hz bandpass filter, noise blanker and audio AGC inserted = before the=20 0.477 mHz FFT. The QRN background from the southeast was generally lower = than=20 the night before.
 
Results for both are=20 in 
 df6nm.bplaced.net/opera/Opera_vs_opds_screenshot_130624= .jpg
and a=20 screenshot
 df6nm.bplaced.net/opera/Opera_vs_opds_screenshot_1306= 24.jpg
 
Although SNR results shown by Opera = were=20 consistently better than those for opds, Opera achieved two only decodes = while=20 opds produced ten hits (including three from VO1NA).
 
I am wondering whether this difference = may have=20 been exacerbated by the regular splatter from DCF39 which is quite = strong in=20 central Europe. This may also have affected the SNR estimates of either = program.=20 Maybe in this situation dedicated preprocessing might be helpful for = Opera as=20 well?
 
We may perhaps speculate that possible = DCF=20 suppression may be part of the loop advantage observed by DF2JP - Joe = could you=20 comment on your loop's orientation?
 
Best 73,
Markus = (DF6NM)

 
Sent: Sunday, June 23, 2013 1:25 PM
To: rsgb_lf_group@blacksheep.org= ; rsgb_lf_group@yahoogroups= .co.uk=20
Subject: Re: LF: VO1NA Opera-32

I have downloaded Opera v1.4.7 from the = rosmodem=20 website. It was easy to configure and is running smoothly in conjunction = with=20 SpecLab and VAC-3, which is needed here to convert from 135.5 to = 136.0 kHz=20 LO. With the waterfall disabled, average CPU usage on the slow Atom = Netbook=20 is an easy 20% from one of two virtual CPU's (10% shown in = task=20 manager).
 
Opds is running in parallel from a = separate SpecLab=20 instance. A locally = generated test signal=20 showed up both in Opera (-28 dB) and in opds (-36.4 dB), which = means that=20 the first round goes to Jose ;-) I = will let both=20 run for a while, hoping for some weak signals to compare.
 
Best 73,
Markus (DF6NM)
 
------=_NextPart_000_0010_01CE70C8.73915EC0--