Return-Path: Received: from rly-db02.mx.aol.com (rly-db02.mail.aol.com [172.19.130.77]) by air-db04.mail.aol.com (v125.7) with ESMTP id MAILINDB044-aaf4aa2e69014c; Sat, 05 Sep 2009 18:30:57 -0400 Received: from post.thorcom.com (post.thorcom.com [193.82.116.20]) by rly-db02.mx.aol.com (v125.7) with ESMTP id MAILRELAYINDB025-aaf4aa2e69014c; Sat, 05 Sep 2009 18:30:41 -0400 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1Mk3lk-00029W-PT for rs_out_1@blacksheep.org; Sat, 05 Sep 2009 23:30:04 +0100 Received: from [83.244.159.144] (helo=relay3.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1Mk3lk-00029N-84 for rsgb_lf_group@blacksheep.org; Sat, 05 Sep 2009 23:30:04 +0100 Received: from mailout.toya.net.pl ([217.113.224.27] ident=postfix) by relay3.thorcom.net with esmtp (Exim 4.63) (envelope-from ) id 1Mk3lc-0002mu-PE for rsgb_lf_group@blacksheep.org; Sat, 05 Sep 2009 23:29:58 +0100 Received: from mail.toya.net.pl (localhost.localdomain [127.0.0.1]) by mail.toya.net.pl (Postfix) with ESMTP id C024920000618 for ; Sun, 6 Sep 2009 00:29:55 +0200 (CEST) Received: from [10.11.178.152] (unknown [10.11.178.152]) (Authenticated sender: unimlyn) by mail.toya.net.pl (Postfix) with ESMTPSA id A7AA520000609 for ; Sun, 6 Sep 2009 00:29:55 +0200 (CEST) Message-ID: <4AA2E662.5010009@toya.net.pl> Date: Sun, 06 Sep 2009 00:29:54 +0200 From: =?UTF-8?B?UGlvdHIgTcWCeW5hcnNraQ==?= User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en 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> X-AV-Checked: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Spam-Report: autolearn=disabled,none Subject: Re: LF: Re: WSPR beacon Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on post.thorcom.com X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none 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 X-AOL-IP: 193.82.116.20 X-Mailer: Unknown (No Version) 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/