Return-Path: X-Spam-DCC: paranoid 1481; Body=2 Fuz1=2 Fuz2=2 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on lipkowski.org X-Spam-Level: ** X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00,DNS_FROM_AHBL_RHSBL, FORGED_MUA_OUTLOOK,PLING_QUERY,SPF_PASS autolearn=no version=3.1.3 Received: from post.thorcom.com (post.thorcom.com [195.171.43.25]) by paranoid.lipkowski.org (8.13.7/8.13.7) with ESMTP id uA3JYpAD029330 for ; Thu, 3 Nov 2016 20:34:51 +0100 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1c2NjO-0007aG-CS for rs_out_1@blacksheep.org; Thu, 03 Nov 2016 19:31:22 +0000 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1c2NjN-0007a7-RR for rsgb_lf_group@blacksheep.org; Thu, 03 Nov 2016 19:31:21 +0000 Received: from rgout0404.bt.lon5.cpcloud.co.uk ([65.20.0.217] helo=rgout04.bt.lon5.cpcloud.co.uk) by relay1.thorcom.net with esmtp (Exim 4.87) (envelope-from ) id 1c2NjK-0000db-SI for rsgb_lf_group@blacksheep.org; Thu, 03 Nov 2016 19:31:20 +0000 X-OWM-Source-IP: 86.178.51.135 (GB) X-OWM-Env-Sender: alan.melia@btinternet.com X-Junkmail-Premium-Raw: score=12/50,refid=2.7.2:2016.11.3.191217:17:12.455,ip=,rules=__HAS_MSGID, __SANE_MSGID, MSGID_32HEX_LC, INVALID_MSGID_NO_FQDN, __MSGID_32HEX, __HAS_FROM, __FRAUD_WEBMAIL_FROM, __TO_MALFORMED_2, __TO_NO_NAME, __REFERENCES, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_WITH_PATH, __URI_NO_WWW, __CP_URI_IN_BODY, __SUBJ_ALPHA_NEGATE, __URI_IN_BODY, __FORWARDED_MSG, BODY_SIZE_4000_4999, __MIME_TEXT_P1, __MIME_TEXT_ONLY, __URI_NS, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, __FRAUD_WEBMAIL, __OUTLOOK_MUA, __SINGLE_URI_TEXT, SINGLE_URI_IN_BODY, __PHISH_SPEAR_STRUCTURE_1, __MIME_TEXT_P, FORGED_MUA_OUTLOOK, REFERENCES, BODY_SIZE_7000_LESS, NO_URI_HTTPS, MSG_THREAD, LEGITIMATE_SIGNS, LEGITIMATE_NEGATE Received: from gnat (86.178.51.135) by rgout04.bt.lon5.cpcloud.co.uk (9.0.019.07.01-1) (authenticated as alan.melia@btinternet.com) id 581B462A0008A038 for rsgb_lf_group@blacksheep.org; Thu, 3 Nov 2016 19:31:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btcpcloud; t=1478201478; bh=e1XE+iDC+K2dHeX8CqCBvh+2YDEXAGi1zN65ihh/rs0=; h=Message-ID:From:To:References:Subject:Date:MIME-Version:X-Mailer; b=ND5lI6JHWrmwMAoMwznPSgkEx+M04JXJQEJpktlceLLc0SX8zliop4nVdiIVVp1TDkyLhf1+C+E2svuBEUhOm70ZUi24SHwkm8V1mgYwcT+S42xlJQSIfeGWBYi+0L0RRyVHs5sdFWccTl9PYuDq5D/Nd+z+d9l3aJH1Y6rsZxU= Message-ID: <22185768CF114BE0A22668E235A933A2@gnat> From: "Alan Melia" To: References: <581B3A1F.5060609@posteo.de> <581B83FC.6060600@posteo.de> Date: Thu, 3 Nov 2016 19:24:49 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Scan-Signature: bde53fa3678f346afe39dd99e3e185db Subject: Re: LF: Smart noise cancelling?!? Content-Type: text/plain; format=flowed; charset="ISO-8859-15"; reply-type=response Content-Transfer-Encoding: 7bit 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.56 on 10.1.3.11 Content-Length: 4022 Status: O X-Status: X-Keywords: X-UID: 9384 This is an interesting idea. We often said in the early days of LF that LF "noise" was not Gaussian. I do remember attending a lecture at work by one of the resident maths team. (Pitching for customers) He was considering telecom "noise" not radio. But he demonstrated the standard processes, which assume Gaussian noise were not effective on his example. He then introduced a "new" parameter he called "burstiness". He was using Burst Error Rate as a metric, I think, rather than S/N but the ideas were quite interesting. He was also investigating different error-detection/correction algorithms against the "burstness" index.. I am afraid it was mid 1980s and I dont remember much detail (or even a name to follow for references) A few faces in the audience were quite blank, one or two were leaning forward and some sprawled backward as if to say "What's the problem, if its noisy, close the door" :-)) Alan G3NYK ----- Original Message ----- From: "DK7FC" To: Sent: Thursday, November 03, 2016 6:37 PM Subject: Re: LF: Smart noise cancelling?!? > Hi Peter, > > That sounds interesting and looks convincing. But it only works for > 'compressed' spectra covering several kHz and hours, right? > > As far as i understand this method can't be done for weak signal > detections because you 'need' all the energy available from the weak > signal to fill the bin (one pixel) and just throw away what causes a > reduction of the SNR, so just the stronger QRN bursts are blanked and most > of the signal is coming through whereas your method selects just a small > fraction of the incoming energy (?). > > My idea/question came from the consideration that different kind of QRN > has different optimum blanker settings. > > Am 02.11.2016 21:25, schrieb Paul Nicholson: >> >> Even more aggressive sferic blanking raises >> the decode to Eb/N0 +1.7 dB BER 38.2% >> S/N 16.10 dB in 25.4 uHz. > > So, if propagation changes, the optimal blanker settings will change. So > they vary all the time. If a post-processing of a transmission/recording > taking several hours and night/day changes, it could be useful to > dynamically vary the blanker settings. So these blanker setting levels > would have to be determined/calculated by the incoming signal and then > applied in a next step. > This may be CPU-load intensive, i don't know, it's behind my current > skills. But the idea is there... > > > 73, Stefan > > > Am 03.11.2016 18:55, schrieb Peter: >> Hi Stefan et al., >> >> On 03.11.2016 14:22, DK7FC wrote: >>> ... >>> Last night i thought a bit about noise cancelling on LF/VLF. >> > ... >> >> Running an experimental receiver at VLF/LF for SID-detection (on RPi 3) I >> chose an almost non-parametric procedure running in frequency domain. It >> works as follows: >> Do a windowed FFT, compute the median (by sorting) from the power >> spectrum. Store all spectra and corresponding median values. Next choose >> a time period (let's say 100ms), pick the spectrum with the lowest >> median, plot it, drop all the others. The key is that "Median values" are >> more robust to outliers compared to other averaging procedures. >> >> See what happened when switching from simple averaging to median >> selection algorithm (~16:50 utc): >> http://lf-radio.de/cgi-bin/test/show_wf.cgi?date=16-10-02 >> >> I know that this won't work in case of searching for coherent signal >> detection, or would be hard to implement. But using this method I'm >> detecting such very weak signals from far east like NDI or RTZ on a >> regular basis. >> >> Drawbacks? Yes; it's throwing away a lot of information which may be >> useful. Another pitfall has to be mentioned: using 1 sec. as a selection >> window strong time service transmitters nearly vanished since the >> algorithm will unerringly choose the gaps [^_^]. Therefore I'm using only >> the spectral part between 15 and 50 kHz for computing the median values. >> >> Peter, df3lp >> >