Message-ID: <497274EE.8020709@toya.net.pl>
Date: Sun, 18 Jan 2009 01:16:46 +0100
From: =?UTF-8?B?UGlvdHIgTcWCeW5hcnNraQ==?= <sq7mpj@toya.net.pl>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
MIME-Version: 1.0
To:  rsgb_lf_group@blacksheep.org
References: <F4E8A04C3CBA4C67AE9C3318F2F40C4F@JimPC> <496E6B45.5020100@usa.net> <0F3DBBAC61C545AE85525CD884B642EC@Black> <20090114231729.6b8aea4f@lurcher> <2AD1A31DF27448F495C0CE7FF33CE9DE@Black> <C4F6E432D5814955A1FDD42B0279F472@AGB> <1E6D0A88C4DE49E5A2AF05911187E7A3@Black> <424931F60B3D4F41AB7DCB9E9FCAB3C5@big7368b9a7d3d> <E68E6C5A539A4838ADAC20BE903CBC68@JimPC> <000e01c97703$df2dfcb0$8d01a8c0@JAYDELL> <5E6F6CB3C59741678D3AE19CEA22B373@JimPC> <45AE4BD5B9164F9A929A6A98D89CF1E6@cahal.danet> <008901c9772e$3b16a2f0$8cd9160a@EFREMOV> <49708674.5080009@telia.com> <006701c97814$91b188a0$8cd9160a@EFREMOV> <1F4FBFE39AD245A3B4A2DDAA4361BA7C@Black> <003701c97897$39a3f110$8cd9160a@EFREMOV> <5A4D281B4A044457B3A14F908BAB31DD@JimPC> <E136C648BAE342AA8374AE1AD09C8028@Black> <49726209.2080403@freenet.de>
In-Reply-To: <49726209.2080403@freenet.de>
Subject: Re: LF: Re: WSPR does not work
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org


Wolfgang B=C3=BCscher wrote:

>
>> =20
>
> I do confirm that there is a blocking effect in the WSPR decoder, but=20
> I am not really sure about the details...
> ......
> But drawing any conclusion may be premature - some neighbour may=20
> simply have switched off his local QRM generator.
> My impression is that some processing stages within the WSPR decoder=20
> lack dynamic range, or the FFT has significant leakage, or some part=20
> of the calculation is done with short integer values (instead of=20
> double precision floating point values). The decoder is open source,=20
> but lacking any knowledge of the Fortran programming language, I won't=20
> try to understand the algorithms.
> .......
> 73,
>  Wolf DL4YHF  ...-.-
>
>
Hi Wolfgang, LF
i also can confirm some sort of the "blocking" effect but indeed it is=20
to early to draw serious conclusions .  when i red your mail and you=20
mentioned about the FFT
as a  "side product"  of the ongoing discussion i just  realized why=20
wspr is using  this , say, strange,  12000 Hz sampling rate ( there was=20
also some fuss about this
particular sampling rate due to its non-integer downconverting from=20
hardware established 44100 Hz and therefore  - it is guessing - causing=20
some problems with decoding  the signal properly) . the wspr is using=20
bin size of FFT =3D8192.  In other words , the 162 data  bits are audio=20
sampled 8192 times each and therefore when using 12000 Hz sampling rate=20
the wspr transmission lasts  162*8192/12000  =3D 110.59 seconds  - less =20
than  2 minutes  - it composes nicely into 2 minutes periods of TX/RX=20
etc.. providing also a room for time adjustments  t/r switching  quick=20
decisions  what  # of tx message  to pick up when being in the wsjt/qso=20
mode ..
if  the 11025 sampling rate was used than we have 162*8192/11025 =3D=20
120.37 seconds   i.e. JUST OVER 2 minutes period   with  all the=20
'consequences'  ...

                                                                           =20=
             =20
73, peter, sq7mpj
qth: lodz, poland/jo91rs/