Return-Path: X-Spam-DCC: paranoid 1102; 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=-0.3 required=5.0 tests=BAYES_00,DNS_FROM_AHBL_RHSBL, HTML_30_40,HTML_MESSAGE,RATWARE_GECKO_BUILD 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 tBVC9ll3023762 for ; Thu, 31 Dec 2015 13:09:47 +0100 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1aEbu7-0008Mk-T5 for rs_out_1@blacksheep.org; Thu, 31 Dec 2015 12:00:27 +0000 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1aEbu7-0008Mb-8G for rsgb_lf_group@blacksheep.org; Thu, 31 Dec 2015 12:00:27 +0000 Received: from smtpout.karoo.kcom.com ([212.50.160.34]) by relay1.thorcom.net with esmtp (Exim 4.86) (envelope-from ) id 1aEbt3-0003mc-43 for rsgb_lf_group@blacksheep.org; Thu, 31 Dec 2015 12:00:26 +0000 X-IronPort-AV: E=Sophos;i="5.20,503,1444690800"; d="scan'208,217";a="86504506" Received: from unknown (HELO [127.0.0.1]) ([82.153.100.162]) by smtpout.karoo.kcom.com with ESMTP; 31 Dec 2015 11:59:04 +0000 Message-ID: <56851886.9050306@lineone.net> Date: Thu, 31 Dec 2015 11:59:02 +0000 From: LineOne User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: rsgb_lf_group@blacksheep.org References: <56843A3A.1000709@lineone.net> In-Reply-To: X-Scan-Signature: 86a33fe05fd4c52b025518dbd249b8c0 Subject: Re: LF: OL9TIT on WSPR?? Content-Type: multipart/alternative; boundary="------------050305080900030101070602" 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.10 Status: RO X-Status: X-Keywords: X-UID: 6024 This is a multi-part message in MIME format. --------------050305080900030101070602 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Thanks Andy, I've saved the PDF file, I don't use Yahoo so don't see all postings and certainly didn't spot the 0 rather than O on a 12" monitor. On 30/12/2015 21:18, Andy Talbot wrote: > This is a well known phenomena - surely you've seen it discussed on > the LF groups over the years. > > All efficient communications schemes first of all remove all > redundancy from a message, before adding in tehe controlled redundancy > for the forward error correction (FEC). One inevitability of this is > that when the very occasional burst of random noise or interference > passes all the requirements of the FEC in the decoder, the resulting > completely random message chucked out looks perfectly valid. > > WSPR compresses callsigns and locators is such as way that any random > version of that compressed bit pattern regerates to something that > looks valid. So any randomly generated message will be a callsign > and a locator. > > See http://www.g4jnt.com/Coding/WSPR_Coding_Process.pdf for a > description of how WSPR encodes callsigns and locators. > > Any strong FEC will most of the time only chuck out correct messages, > or nothing. But just once in a while - bearing in mind that each > reception session with just pure noise / interference present is > actually thorwing thousands of possible solutions at the decoder. So > by the simple laws of probability, you know for certain that > occasionally somethign will get past. > > Of course, what everyone then ignores is that there is a third level > of error correction applied - the intel of teh operator. You look at > the result, and see that 0L9 is not in locator square AA, so you know > its false. I suppose it is possible that the software could > incorporate a lookup table of valid call vs. Loc. but its easier to > just let teh operator filter out those false messages. > > So, the fact the "... software is free .." is nothing to do with the > false decodes. Its a mathematical inevitability of efficicient coding > and heavy FEC. > > BTW, trawling through the WSPR database to try to find what you > reported, it's [zero]L9 not [oscar]L9 > ie 0L9 not OL9 which is an even more unlikely call prefix, not > Czech at all > > > Andy G4JNT > > On 30 December 2015 at 20:10, LineOne > wrote: > > Glancing back at the WSPR reception report list at 1434 today I > noted one from OL9TIT on 137.404 kHz at -32dB s/n. Thinking this > was some sort of Titanic beacon from the Czech Republic and that > was a fair level for the distance I looked at the location and it > indicated about 17,000 km away in Antarctica. I think not! > So who or what is OL9TIT and why did no-one else pick this up? I > know there are a few spurious reports on Opera (it is free after > all so no complaints from me) but spurii using WSPR? > Otherwise the Rx system is working well here. > > Hugh, M0DSZ. > > --------------050305080900030101070602 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Thanks Andy, I've saved the PDF file, I don't use Yahoo so don't see all postings and certainly didn't spot the 0 rather than O on a 12" monitor.

On 30/12/2015 21:18, Andy Talbot wrote:
This is a well known phenomena - surely you've seen it discussed on the LF groups over the years.

All efficient communications schemes first of all remove all redundancy from a message, before adding in tehe controlled redundancy for the forward error correction (FEC).   One inevitability of this is that when the very occasional burst of random noise or interference passes all the requirements of the FEC in the decoder, the resulting completely random message chucked out looks perfectly valid.

WSPR compresses callsigns and locators is such as way that any random version of that compressed bit pattern regerates to something that looks valid.   So any randomly generated message will be a callsign and a locator.

See http://www.g4jnt.com/Coding/WSPR_Coding_Process.pdf for a description of how WSPR encodes callsigns and locators.

Any strong FEC will most of the time only chuck out correct messages, or nothing.  But just once in a while - bearing in mind that each reception session with just pure noise / interference present is actually thorwing thousands of possible solutions at the decoder.  So by the simple laws of probability, you know for certain that occasionally somethign will get past.

Of course, what everyone then ignores is that there is a third level of error correction applied - the intel of teh operator.   You look at the result, and see that 0L9 is not in locator square AA, so you know its false.   I suppose it is possible that the software could incorporate a lookup table of valid call vs. Loc. but its easier to just let teh operator filter out those false messages.

So, the fact the "... software is free .." is nothing to do with the false decodes.  Its a mathematical inevitability of efficicient coding and heavy FEC.

BTW, trawling through the WSPR database to try to find what you reported, it's [zero]L9 not [oscar]L9
ie 0L9 not OL9    which is an even more unlikely call prefix, not Czech at all


Andy  G4JNT

On 30 December 2015 at 20:10, LineOne <dhchurch@lineone.net> wrote:
Glancing back at the WSPR reception report list at 1434 today I noted one  from OL9TIT on 137.404 kHz at -32dB s/n. Thinking this was some sort of Titanic beacon from the Czech Republic and that was a fair level for the distance I looked at the location and it indicated about 17,000 km away in Antarctica. I think not!
So who or what is OL9TIT and why did no-one else pick this up? I know there are a few spurious reports on Opera (it is free after all so no complaints from me) but spurii using WSPR?
Otherwise the Rx system is working well here.

Hugh, M0DSZ.



--------------050305080900030101070602--