From: "Gary - G4WGT" <g4wgt@tiscali.co.uk>
To: <rsgb_lf_group@blacksheep.org>
References: <3692CCEF55434A78A271B29E8D4BC318@JimPC> <009901c981aa$78dafa10$a402a8c0@Inspiron>
Date: Thu, 29 Jan 2009 10:58:43 -0000
Message-ID: <005501c98200$958c71b0$6401a8c0@asus>
MIME-Version: 1.0
In-Reply-To: <009901c981aa$78dafa10$a402a8c0@Inspiron>
Thread-Index: AcmBo8O3kbY01t4TRp6Ve37CRb637QAAnaKwABZuJSA=
Subject: LF: RE: WSPR - G0NBD vs M0BMU
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org


Hi LF,

Unknowingly at the time I had the same situation. I saw Grahams signal &
started WSPR & the first frame I received decoded OK but on the waterfall
display it showed that it had only read half a frame. Then after that I had
no more decodes until I attenuated the signal down to the noise.

This confirms Jim's & Lee's findings.

Gary - G4WGT.

-----Original Message-----
From: owner-rsgb_lf_group@blacksheep.org
[mailto:owner-rsgb_lf_group@blacksheep.org] On Behalf Of Lee Hudson
Sent: 29 January 2009 00:43
To: rsgb_lf_group@blacksheep.org
Subject: LF: WSPR - G0NBD vs M0BMU

I've just watched Jim and Grahams transmissions both in the same slot for
four periods. And all decoded OK.
At a rough guess Grahams transmission was 1500ms shorter in duration than
Jims.
Thus confirming Jims tedious findings.

This constitues a reasonable bit rate error.

I suppose over a longer period of receiving Grahams signal will tend to
produce more erroneous data and be rejected.
Pulling out the antenna early has limited this accululating error.

The converse is probably true on receive, just how long are stations really
receiving for.
And the net total of both transmission and reception timing errors between
two specific stations yeild this odd outcome where, some stations
combinations receive consistently fine, while others struggle.
Stations that clearly see multiple transmissions, yet fail to decode any are
probably suffering a receive frame timing error.

The questions maybe how much of a timing discrepancy is WSPR prepared to
tolerate.
And/or does it make any attempt to phase lock onto the data stream presented
(if so what's the pull in range).

Just some thoughts for the cooking pot.

73,
Lee M0LMH.




-----Original Message-----
From: owner-rsgb_lf_group@blacksheep.org
[mailto:owner-rsgb_lf_group@blacksheep.org] On Behalf Of James Moritz
Sent: 28 January 2009 23:54
To: rsgb_lf_group@blacksheep.org
Subject: Re: LF: WSPR - G0NBD


Dear Graham, LF Group,

Remembering what I said jokingly to RA3AGC a few days ago about visually 
verifying a spectrogram trace of a WSPR signal, and the discussions of 
merits of WSPR vs QRSS, I thought this ought to work for diagnosis 
purposes - after all, WSPR is measuring the received frequency changes and 
the times at which they change, and in principle the same info is displayed 
by the spectrogram.

So I spent a "hugely exciting" couple of hours studying your signal with 
Spectrum Lab, and comparing it with a locally generated signal from my PC 
(which everyone seems to decode OK), configured with the same beacon message

you have been transmitting. Eventually, I realised that the difference was 
that your transmissions are a few seconds shorter than the locally generated

signals - in the attachment, the locally generated signals have the dark, 
noise free background. This means the transmitted sequence will be a couple 
of symbols out of step by the end of each transmission - I expect that could

mess up the demodulation/decoding processes quite a lot. If you have a noisy

signal, the demodulator/decoder might be using effectively just the least 
noisy fraction of the signal, with less timing error over a shorter part of 
the sequence.

To test this theory, I waited until about 1 minute of your signal had 
appeared on the spectrogram, then unplugged the antenna, so that the 
remaining minute was white noise. The result was successful decodes! I tried

this 3 times, and it worked 3 times. So your signal does not have to be 
noisy in order to decode, there has to be part of it missing in order to 
decode!

So that might be why the signals don't decode - whether this is a problem 
with the soundcard, motherboard, or software is probably a question for 
K1JT! Still, a step in the right direction...

Cheers, Jim Moritz
73 de M0BMU 

No virus found in this incoming message.
Checked by AVG - http://www.avg.com 
Version: 8.0.176 / Virus Database: 270.10.13/1915 - Release Date: 1/28/2009
6:37 AM