Message-ID: <4AA2E662.5010009@toya.net.pl>
Date: Sun, 06 Sep 2009 00:29:54 +0200
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: <8E070AD22619484C9E2D22046F45C521@JimPC>	 <4AA224DE.17607.C34F15@dave.davesergeant.com>	 <4AA22EDB.2060704@sighthound.demon.co.uk> <1f0624b90909050356s2ff3e23ej283abf0cdaaafb88@mail.gmail.com> <4AA245D1.1050901@sighthound.demon.co.uk>
In-Reply-To: <4AA245D1.1050901@sighthound.demon.co.uk>
Subject: Re: LF: Re: WSPR beacon
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org


John P-G wrote:

>
>
>
> Graham is often difficult here too though, and I think this is related 
> to a soundcard problem at his end. The fact that you're nearer will 
> probably just exacerbate the effect.
>
> In general however it does appear that the mode is very good on weak 
> signals and hit and miss on strong ones and one suspects that it's 
> very intolerant of errors in soundcard sample rate - which is masked 
> with weak signals to some extent.
>
> Cheers,
>
> John
>
>
>
Hello LF Group,
just to add  more points to the ongoing disscussion  about wspr  
problem: to decode or not to decode ... :)
in  my view John, GM4SLV is right  when indicating that the  soundcard 
sample rate  may be responsible for not decoding at all or, in part, 
for  errors.
some time ago i've posted to this reflector  the following observation:
 the wspr is using bin size of  FFT  8192 and  transmits  162 data  bits 
at 12000 Hz  sampling rate so  the wspr transmission lasts  
162*8192/12000  = 110.59 seconds i.e  less  than  2 minutes.  if  the 
11025 sampling rate was used than we would  have 162*8192/11025 = 120.37 
seconds - just over 2 min.
most  of the soundcards have, say, master sapmling rate of 44.1 khz  
therefore when downconverting  this  rate  to the used sampling rate of 
12000 Hz 
some non-integer "offset" appears and how the drivers/chips deal with 
this issue is an open problem
let me now add  few other observations.. when i used wspr for the first 
time (  on HF bands) soon  i  got interested in  its performance  in the 
case of a strong signals so i have asked  another ham (  we live in the 
same city  abt 3 km frm each other)  to TX strong signal  - indeed it 
was red on the display and there was no problem
to properly decode his transmission. in the next 'experiment' i asked 
him to do the same but at the same time i was trying to decode the 
signal from  distant transmitting stations ( i do not remember  exactly 
but i think it was a 7 Mhz band )  again,  i was properly decoding  weak 
stations in a presence of a "red" strip on the waterfall. In some way  , 
the last  issue was also confirmed yesterday when i successfuly decoded  
Jim , M0BMU and Gus, SM6BHZ: (frm MEPT.txt file)
in the same time slot:
090903 2242  22  -9  0.6   0.503956  SM6BHZ JO57 30          0     1    0
090903 2242  12 -19  0.4   0.503981  M0BMU IO91 33           0     1    0
Ok, it is only 10db difference but sure it is possible .
It seems that Jim, M0BMU  has made a point  when  indicating the 
narrow-band  qrm's.  if it is close to the 'signal' there is a false 
decode or no decode at all.
here i have terrible and floating  qrm  on 500 kHz when it gets closer  
to the signal wspr fails.
As for the PC clock synchronization..- again,  i have looked into 
all_mept file and i can see that DT can be as much as  3sec and still 
yield a positive decode
090328 2244  12 -18  3.4   0.505094  DI2AG JN59 27           0   232    
0           (DT=3.4sec)
 
                                                                           
yours, peter, sq7mpj
qth: Lodz /jo91rs/