Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lipkowski.org X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,RCVD_IN_DNSWL_MED, RCVD_IN_SORBS_SPAM,SPF_PASS,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.0 X-Spam-DCC: EATSERVER: mailn 1166; Body=2 Fuz1=2 Fuz2=2 Received: from post.thorcom.com (post.thorcom.com [195.171.43.25]) by lipkowski.org (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v2JK2Xi9024208 for ; Sun, 19 Mar 2017 21:02:34 +0100 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1cpgyK-0006ph-4L for rs_out_1@blacksheep.org; Sun, 19 Mar 2017 19:58:36 +0000 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1cpgyJ-0006pY-JM for rsgb_lf_group@blacksheep.org; Sun, 19 Mar 2017 19:58:35 +0000 Received: from omr-m008e.mx.aol.com ([204.29.186.7]) by relay1.thorcom.net with esmtp (Exim 4.89) (envelope-from ) id 1cpgyF-0005oV-Hy for rsgb_lf_group@blacksheep.org; Sun, 19 Mar 2017 19:58:34 +0000 Received: from mtaomg-mac02.mx.aol.com (mtaomg-mac02.mx.aol.com [172.26.222.208]) by omr-m008e.mx.aol.com (Outbound Mail Relay) with ESMTP id BEA213800043 for ; Sun, 19 Mar 2017 15:58:28 -0400 (EDT) Received: from core-ace04g.mail.aol.com (core-ace04.mail.aol.com [172.27.23.4]) by mtaomg-mac02.mx.aol.com (OMAG/Core Interface) with ESMTP id 6F38C38000089 for ; Sun, 19 Mar 2017 15:58:26 -0400 (EDT) Received: from 188.192.95.60 by webprd-m44.mail.aol.com (10.74.56.228) with HTTP (WebMailUI); Sun, 19 Mar 2017 15:58:26 -0400 Date: Sun, 19 Mar 2017 15:58:26 -0400 From: Markus Vester To: rsgb_lf_group@blacksheep.org Message-Id: <15ae8264336-399a-96cd@webprd-m44.mail.aol.com> In-Reply-To: <159b1e28cdd-ccc-4818@webprd-m102.mail.aol.com> MIME-Version: 1.0 X-MB-Message-Source: WebUI X-MB-Message-Type: User X-Mailer: JAS STD X-Originating-IP: [188.192.95.60] x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1489953508; bh=3geQEW0zTZt64EV2Vigg/TReFY8flr5A9ePvEfRZyx0=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=3mnkPEC4+TbJUQivx1W1SFjjb7koeQZItEaQP1ZV8bxiwy6nBshLAX8LLmcyGp1Va eDUIEmbId8jAm9a46tT69TPg+ygO92lNCd9p3DMbEsZLLfySdUL7aUQr5C5q3ozoXI x0aNwveW2GHojlV3mjSrBuvsoXJkUnIlattYV6oI= x-aol-sid: 3039ac1aded058cee2e21661 X-Scan-Signature: fbdd513523001863775249cfaf215eac Subject: Re: LF: New opds version Content-Type: multipart/alternative; boundary="----=_Part_44837_2001844517.1489953506101" 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-Scanned-By: MIMEDefang 2.75 Status: RO X-Status: X-Keywords: X-UID: 10939 ------=_Part_44837_2001844517.1489953506101 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Moving on from opds2h5c to opds2h6 a couple of months ago has indeed signif= icantly reduced the number of false positive detections on my LF opera moni= tor, with no apparent loss of sensitivity: http://www.df6nm.de/opera/opds.h= tm . However with default settings, partial correlations to strong real Ope= ra signals can still occasionally lead to false spots on an adjajent freque= ncy. This can be fixed by adding a line to the opds.ini configuration file: minpeakspacing=3D200 allowing opds to associate any spurious peaks within 200 FFT bins (~ 0.09 H= z at LF) to the original signal. =20 Some opds users are still using Dropbox to upload their results. Due to a r= ecent policy change regarding the Dropbox public folders, these will no lon= ger be uploaded to the web, and any links like dl.dropboxusercontent.com/..= . etc. are now going into digital Nirwana. I have replaced Dropbox by FTP t= o my webspace. The FTP transfer can be automated by adding a line to cleanu= p.bat like @ftp -s:ftp_opds.txt >ftp_log.txt and preparing an ftp.txt command file containing something like =20 open cd opds bin put opds32.txt put c:\spectrum\opds32.png bye Best 73, Markus (DF6NM) -----Urspr=C3=BCngliche Mitteilung-----=20 Von: Markus Vester An: rsgb_lf_group Verschickt: Mi, 18. Jan 2017 15:02 Betreff: LF: New opds version Dear opds users, I have recently discovered a minor bug in opds2h5c which could sometimes pr= oduce systematic false detections from partial correlations after the end o= f a strong Opera signal. This has hopefully been fixed in version 2h6: http://df6nm.de/opera/opds2h6.zip This version should be completely compatible with existing configurations a= nd ini files, so all you have to do is start opds2h6 instead of opds2h5c. Differences are: - potential false partial correlations are cross-checked against detections= on the same frequency during the last 32 minutes,=20 - to further reduce possible false detections triggered by strong non-Opera= signals, the correlation threshold is now raised with signal strength. By = default, it goes up linearly from 15 to 19 dB, starting at SNR -41 dBOp. If= desired, this behavior can be modified by dedicated opds.ini entries, =20 - the bug in the default filename pattern has been corrected, so the "patte= rn=3D*.txt" ini-line is no longer needed, - unused parts of the code have been removed, resulting in a slightly small= er source and executable. BTW For the old 16-bit QuickBasic versions before opds2h5b, I had recommend= ed to prevent CPU-load peaks by running the process at lower priority. This= seems to be no longer necessary.=20 Best 73, Markus (DF6NM) ------=_Part_44837_2001844517.1489953506101 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Moving on from opds2h5c to opds2h6 a coup= le of months ago has indeed significantly reduced the number of false posit= ive detections on my LF opera monitor, with no apparent loss of sensitivity= : http://www.df6nm.de/opera/opds.htm . However with default settings,&= nbsp;partial correlations to strong real Opera signals can still occasional= ly lead to false spots on an adjajent frequency. This can be fixe= d by adding a line to the opds.ini configuration file:
 minpea= kspacing=3D200
allowing opds to associate any spurious peaks within= 200 FFT bins (~ 0.09 Hz at LF) to the original signal.
 
Some o= pds users are still using Dropbox to upload their results. Due to a recent = policy change regarding the Dropbox public folders, these will no long= er be uploaded to the web, and any links like dl.dropboxuserconte= nt.com/... etc. are now going into digital Nirwana. I have replac= ed Dropbox by FTP to my webspace. The FTP transfer can = be automated by adding a line to cleanup.bat like

@ftp -s:ftp_o= pds.txt >ftp_log.txt

and preparing an ftp.txt command file&n= bsp;containing something like
 
open <myftpserver>
<= myaccount>
<mypassword>
cd opds
bin
put opds32.txt
= put c:\spectrum\opds32.png
bye

Best 73,
Markus (DF6NM)

=
-----Urspr=C3=BCngliche Mitteilung-----
Von: Markus Vester <mark= usvester@aol.com>
An: rsgb_lf_group <rsgb_lf_group@blacksheep.org&= gt;
Verschickt: Mi, 18. Jan 2017 15:02
Betreff: LF: New opds version<= br>

Dear opds users,

I have= recently discovered a minor bug in opds2h5c which could sometimes produce = systematic false detections from partial correlations after the end of a st= rong Opera signal. This has hopefully been fixed in version 2h6:

&nbs= p;http://df= 6nm.de/opera/opds2h6.zip

This version should be completely compat= ible with existing configurations and ini files, so all you have to do is s= tart opds2h6 instead of opds2h5c.

Differences are:
- potential fal= se partial correlations are cross-checked against detections on the same fr= equency during the last 32 minutes,
- to further reduce possible false = detections triggered by strong non-Opera signals, the correlation threshold= is now raised with signal strength. By default, it goes up linearly from 1= 5 to 19 dB, starting at SNR -41 dBOp. If desired, this behavior can be modi= fied by dedicated opds.ini entries, 
- the bug in the default file= name pattern has been corrected, so the "pattern=3D*.txt" ini-line is no lo= nger needed,
- unused parts of the code have been removed, resulting in = a slightly smaller source and executable.

BTW For the old 16-bit Quic= kBasic versions before opds2h5b, I had recommended to prevent CPU-load peak= s by running the process at lower priority. This seems to be no longer nece= ssary.

Best 73,
Markus (DF6NM)

------=_Part_44837_2001844517.1489953506101--