DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=btopenworld.com;
  h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:From:To:References:In-Reply-To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MIMEOLE;
  b=itLGcR5R9J2p+lFoLqUxDD+QbbCYWBOUXN2RITudmo1dACT6x+rSYahkdWL1uwp4pADAkGHlDpxCeHEIyaXjFnx1Qik2+YkUXnTELHWDMg36L503O1pYl7+PV8FELawH5ULsrWkXeb/QoON+oJEwIXph0hkwxqaBfkJ6XEuLCyM=  ;
Message-ID: <5A4D281B4A044457B3A14F908BAB31DD@JimPC>
From: "James Moritz" <james.moritz@btopenworld.com>
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>
In-Reply-To: <003701c97897$39a3f110$8cd9160a@EFREMOV>
Date: Sat, 17 Jan 2009 19:57:26 -0000
MIME-Version: 1.0
DomainKey-Status: good (testing) 
Subject: LF: Re: WSPR does not work
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org


Dear Andrey, LF Group,

Here is an observation that might be relevant, (or perhaps not!) to the 
problem of WSPR displaying a clear spectrogram trace of a signal, but 
failing to decode it. I noticed it while looking for OH1LSQ's QRSS earlier, 
and have now checked a bit more carefully.

First, I changed the BW from 250Hz to 2.4kHz so that I would be able to see 
OH1SQ at 800Hz audio frequency (carrier frequency set to 136.000k) using 
Spectrum Lab, and at the same time decode F5WK at around 1500Hz audio. This 
required reducing RF/IF gain to prevent overloading by the DCF39 carrier at 
2.83kHz audio. I could then see OH1LSQ OK, but although there was a good 
trace from F5WK in WSPR, no decoding occured. (Changing the gain does not 
alter the spectrogram appearance much, so presumably it is displaying SNR 
rather than absolute signal level. ).

Reducing the bandwidth to 250Hz, with the gain still reduced, restored 
normal decoding.

Increasing the bandwidth to 2.4kHz again, adjusting the passband shift 
control, and changing the loop orientation to reduce DCF39 and Lakihegy to a 
minimum while maintaining F5WK's signal, with the gain still reduced, also 
gave normal decoding, although there was now assorted additional noise in 
the passband.

It seems to me most likely that the failure to decode was due to the 
presence of the strong tone at high audio frequency from DCF39, although 
this tone was outside the WSPR frequency range, and not saturating the sound 
card A/D converter or overloading the analogue RX channel.

So if there are other tones in your RX passband while receiving WSPR, it 
appears they may prevent decoding occuring, even though a good signal is 
displayed on the WSPR spectrogram.

This seems to be a reproducible case where a strong WSPR signal does not 
decode on a receiving system that is known to work well. If others can 
reproduce this, it may be worth contacting K1JT to see if he is aware of 
this or can shed light on the matter.

Cheers, Jim Moritz
73 de M0BMU