Return-Path: Received: from post.thorcom.com (post.thorcom.com [195.171.43.25]) by klubnl.pl (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id vBSHRgEW005870 for ; Thu, 28 Dec 2017 18:27:45 +0100 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1eUbu5-00031a-Vm for rs_out_1@blacksheep.org; Thu, 28 Dec 2017 17:23:37 +0000 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1eUbu5-00031R-Jj for rsgb_lf_group@blacksheep.org; Thu, 28 Dec 2017 17:23:37 +0000 Received: from mout01.posteo.de ([185.67.36.65]) by relay1.thorcom.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eUbu2-0005zm-LW for rsgb_lf_group@blacksheep.org; Thu, 28 Dec 2017 17:23:36 +0000 Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id 2D5C620DFF for ; Thu, 28 Dec 2017 18:23:32 +0100 (CET) X-DKIM-Result: Domain=posteo.de Result=Signature OK DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1514481812; bh=TZZu/hlxY6lUP9Z6Mvxe+km6IOLECkOOLnkEPV4vQaM=; h=Date:From:To:Subject:From; b=BEhw/mO0ZZIIYWHHyu1QnVua7fUQ1haO+xAVRi8ZTVLV3gfOJUIZZKVsw0GXZjQr5 36O511stwJBkz055c2IYszMmt3OXG+E67zvpy6u4kBppZlecN92+JsyUINlhuRHCba zjjVY5OQgKhSnwI8UwjzbA8nqtwSsQPtajbK0N0MlPF0T89NRIksyJUXMMeAMfuNoT N5T58tfYU9JWfKuFLqZb1HWvEB5M89B/VkvXi4WJDqF4r76vjQoOKByTGMYl06/LHS U+8k8lrt4U/9Kcoq0EwrWZEtef4/jvdIsswVaoVBRzy8ybvSWQcuyTs63BdmCMRnDr pAAewQKXpf/Qw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 3z6xQ8461jz9rxc for ; Thu, 28 Dec 2017 18:23:28 +0100 (CET) Message-ID: <5A45288F.50401@posteo.de> Date: Thu, 28 Dec 2017 18:23:27 +0100 From: DK7FC User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: rsgb_lf_group@blacksheep.org References: <1609e1a87d5-57b4-137cc@webjas-vaa011.srv.aolmail.net> In-Reply-To: <1609e1a87d5-57b4-137cc@webjas-vaa011.srv.aolmail.net> X-Spam-Score: 0.0 (/) X-Spam-Report: Spam detection software, running on the system "relay1.thorcom.net", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi Markus, I would agree. The decoder will not put out the correct message just because the man sitting in front of the computer already knows the message. It is like in WSPR: You won't receive/decode a transmitting station with a higher probability just because you know it is active and know the data (call, loc, dBm). All you can do to obtain a valid decode is applying known data, which means here: Tuning to the right frequency, keeping your PC time accurate and selecting the right mode. And maybe applying an individual noise blanker... We are doing nothing more in EbNaut. There are just more parameters since it is a very flexible mode... [...] Content analysis details: (0.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 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: ad9c0e3658f56f4dbb01cd425a6a8031 Subject: Re: LF: 8269.9 kHz EbNaut 27/12/17 Content-Type: multipart/alternative; boundary="------------070602010704030607090001" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on post.thorcom.com X-Spam-Level: * X-Spam-Status: No, hits=1.4 required=5.0 tests=HTML_30_40,HTML_MESSAGE, HTML_TITLE_EMPTY 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 This is a multi-part message in MIME format. --------------070602010704030607090001 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Markus, I would agree. The decoder will not put out the correct message just because the man sitting in front of the computer already knows the message. It is like in WSPR: You won't receive/decode a transmitting station with a higher probability just because you know it is active and know the data (call, loc, dBm). All you can do to obtain a valid decode is applying known data, which means here: Tuning to the right frequency, keeping your PC time accurate and selecting the right mode. And maybe applying an individual noise blanker... We are doing nothing more in EbNaut. There are just more parameters since it is a very flexible mode... 73, Stefan Am 28.12.2017 18:10, schrieb Markus Vester: > Hi Dex, > > correlation processing is relatively cheap, so no harm done ;-) > > > No stacking allowed when message is known. > > I politely disagree. A decode made after stacking blindly with > constant phase and weights (or weights derived solely from noise > level) hasn't made use of a priori information of the correct > result. Correlations are ok, but their output should not be used to > tweak the phases before stacking. As Paul mentioned earlier, stacking > a large enough number of tweaked-phase data sets will eventually > produce any desired decode from pure noise. > > Best 73, > Markus > > iche Mitteilung----- > Von: Dexter McIntyre W4DEX > An: rsgb_lf_group > Verschickt: Do, 28. Dez 2017 14:32 > Betreff: Re: LF: 8269.9 kHz EbNaut 27/12/17 > > The message was changed. No stacking allowed when message is known :) > > Sorry for the confusion and wasted processor time. > > Will repeat tonight WX premitting. > > Dex > > On Wed, Dec 27, 2017 at 4:29 PM, Dexter McIntyre W4DEX > > wrote: > > New message tonight > > 3 chars 16K21A CRC20 > 30 second symbols > Start 22:30 UT > > Dex > > > > -- > "Remember what the dormouse said......." --------------070602010704030607090001 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Markus,

I would agree. The decoder will not put out the correct message just because the man sitting in front of the computer already knows the message.
It is like in WSPR: You won't receive/decode a transmitting station with a higher probability just because you know it is active and know the data (call, loc, dBm). All you can do to obtain a valid decode is applying known data, which means here: Tuning to the right frequency, keeping your PC time accurate and selecting the right mode. And maybe applying an individual noise blanker...
We are doing nothing more in EbNaut. There are just more parameters since it is a very flexible mode...

73, Stefan

Am 28.12.2017 18:10, schrieb Markus Vester:
Hi Dex,

correlation processing is relatively cheap, so no harm done ;-)

> No stacking allowed when message is known.

I politely disagree. A decode made after stacking blindly with constant phase and weights (or weights derived solely from noise level) hasn't made use of a priori information of the correct result. Correlations are ok, but their output should not be used to tweak the phases before stacking. As Paul mentioned earlier, stacking a large enough number of tweaked-phase data sets will eventually produce any desired decode from pure noise. 

Best 73,
Markus

iche Mitteilung-----
Von: Dexter McIntyre W4DEX <dexter.mc@gmail.com>
An: rsgb_lf_group <rsgb_lf_group@blacksheep.org>
Verschickt: Do, 28. Dez 2017 14:32
Betreff: Re: LF: 8269.9 kHz EbNaut 27/12/17

The message was changed.  No stacking allowed when message is known :)  

Sorry for the confusion and wasted processor time.

Will repeat tonight WX premitting.

Dex

On Wed, Dec 27, 2017 at 4:29 PM, Dexter McIntyre W4DEX <dexter.mc@gmail.com> wrote:
New message tonight

3 chars 16K21A CRC20
30 second symbols
Start 22:30 UT

Dex



--
"Remember what the dormouse said......."
--------------070602010704030607090001--