Return-Path: Received: from rly-dd09.mx.aol.com (rly-dd09.mail.aol.com [172.19.141.156]) by air-dd06.mail.aol.com (v121_r4.4) with ESMTP id MAILINDD064-b99497f29f81f9; Tue, 27 Jan 2009 10:36:54 -0500 Received: from post.thorcom.com (post.thorcom.com [193.82.116.20]) by rly-dd09.mx.aol.com (v121_r4.4) with ESMTP id MAILRELAYINDD093-b99497f29f81f9; Tue, 27 Jan 2009 10:36:27 -0500 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1LRpyw-0005TL-Lf for rs_out_1@blacksheep.org; Tue, 27 Jan 2009 15:36:06 +0000 Received: from [193.82.59.130] (helo=relay2.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1LRpyw-0005TC-1Y for rsgb_lf_group@blacksheep.org; Tue, 27 Jan 2009 15:36:06 +0000 Received: from smtp-out-1.talktalk.net ([62.24.128.231] helo=smtp.talktalk.net) by relay2.thorcom.net with esmtp (Exim 4.63) (envelope-from ) id 1LRpyt-0000ac-5d for rsgb_lf_group@blacksheep.org; Tue, 27 Jan 2009 15:36:05 +0000 X-Path: TTSMTP X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8EADe4fklOlG6B/2dsb2JhbACEXMZFhUw Received: from unknown (HELO mal769a60aa920) ([78.148.110.129]) by smtp.talktalk.net with SMTP; 27 Jan 2009 15:35:56 +0000 Message-ID: <003f01c98094$f29a1870$0301a8c0@mal769a60aa920> From: "mal hamilton" To: References: <20090126225342.5af9e594@lurcher> <459DB6156FCD43509AAB5F5D7282462C@AGB> <20090126232813.551c6bfc@lurcher> <497ECDA6.2060105@telia.com> <009801c98065$18787710$0301a8c0@mal769a60aa920> <497EE52C.4050808@sighthound.demon.co.uk> Date: Tue, 27 Jan 2009 15:35:56 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Spam-Report: autolearn=disabled,AWL=0.069 Subject: Re: LF: G0NBD difficult to decode Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original 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 ----- Original Message ----- From: "John P-G" To: Sent: Tuesday, January 27, 2009 10:42 AM Subject: Re: LF: G0NBD difficult to decode > mal hamilton wrote: >> Johan >> I have mentioned this several times before but noone seems to know why >> strong signals or any visible signals do not DECODE. I get some decodes >> therefore I know my system is working but not sure whether the problem is >> at >> the TX or RX end. To me wspr seems unreliable given the strength of >> signals >> but producing only marginal decoded output. >> 73 de mal/gkev >> > > > Mal, LF, > > In general WSPR is very good at decoding weak signals - that's what it's > all about after all - and can give reliable decodes on signals that are > inaudible and only faintly visible on the waterfall. Occasionally there > seem to be certain strong signals that won't decode, when weaker signals > from the same stations are fine. > > Some discussion has taken place on the WSPR forum over incompatible > soundcard sampling rates, others on HF have seem the same "won't decode > strong signals" problems too. > > In the current case, with G0NBD, I guess the problem, whatever it is, is > at the sending end, as similarly strong signals from others (M0BMU and > G4JNT) decoded fine here, and elsewhere, yet many people had trouble > with G0NBD's signal. > > I see that Chris G3XVL often reports a +13dB s/n ratio for Jim's signal, > which shows that strong signals can decode correctly. > > > The question of brevity in passing information (ie "having a QSO") is > moot - it's not really intended for that purpose. It's point is to allow > monitoring of the path conditions, using low power "weak signals" - WSPR > stands for "Weaks Signal Propagation Reporting". If you want a mode for > conveying information and exchanging reports then there's a whole gamut > - not least among them good old CW. > > WPSR allows the collection, automatically, of data showing the changes > in path conditions over time, with a centralised online database of the > results, allowing others to do whatever number crunching they care to on > the data. For this the mode is perfectly valid, and given low enough > transmit power from the stations involved it shouldn't cause too many > problems for other band users. Last night's results showed that, for > inter-G (even up to Shetland) the ERPs involved were too high. Gary, > with his 5W TX and 2mW ERP is showing the way it should be done - and > that wouldn't cause too much QRM for those seeking CW QSOs elsewhere on > the band. > Over the years I have worked W6 and W7 area and VE7 many times on 160m plus KL7 on normal CW not to mention KH6 and ZL G3KEV > Using WSPR on 160m recently I discovered that I have a regular opening > to N6TTO on the west coast of USA, and I'm often the only Eu station to > receive him. Relying on more traditional modes I'd probably never have > discovered this. It means that perhaps my location is suitable for 160m, > and might be worth some investment in time/effort to get on the band. > Without the research using WSPR I'd have not realised that my location > was special - although my low noise floor has already proved its worth > on 500kHz. > > Just a few thoughts from here. > > Cheers, > > John > GM4SLV > > -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.14/1917 - Release Date: 1/26/2009 6:37 PM