DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=btinternet.com;
  h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:In-Reply-To:X-MimeOLE:Thread-Index:Importance;
  b=KJGT6DE8FaIj6bEExTJmJGNByGd1yY/5Bw7xA6zRucCtTvw09jhlLMLz1h+GbOwz/EGfdC8UfLQ74PttWDPVZoC12GjeTnNDt/0ji0v19AZDKOydhYt57J9tbrUxM8YGvqPRI9CLWTRvJDg3ti26AJCR6XtwjsvVJf6zizJMsVk=  ;
From: "Lee Hudson" <hudsonville@btinternet.com>
To: <rsgb_lf_group@blacksheep.org>
Date: Thu, 29 Jan 2009 00:42:32 -0000
Message-ID: <009901c981aa$78dafa10$a402a8c0@Inspiron>
MIME-Version: 1.0
In-Reply-To: <3692CCEF55434A78A271B29E8D4BC318@JimPC>
Thread-Index: AcmBo8O3kbY01t4TRp6Ve37CRb637QAAnaKw
Importance: Normal
DomainKey-Status: good (testing) 
Subject: LF: WSPR - G0NBD vs M0BMU
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org


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=20
verifying a spectrogram trace of a WSPR signal, and the discussions of=20
merits of WSPR vs QRSS, I thought this ought to work for diagnosis=20
purposes - after all, WSPR is measuring the received frequency changes and=20
the times at which they change, and in principle the same info is displayed=20
by the spectrogram.

So I spent a "hugely exciting" couple of hours studying your signal with=20
Spectrum Lab, and comparing it with a locally generated signal from my PC=20
(which everyone seems to decode OK), configured with the same beacon message

you have been transmitting. Eventually, I realised that the difference was=20
that your transmissions are a few seconds shorter than the locally generated

signals - in the attachment, the locally generated signals have the dark,=20
noise free background. This means the transmitted sequence will be a couple=20
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=20
noisy fraction of the signal, with less timing error over a shorter part of=20
the sequence.

To test this theory, I waited until about 1 minute of your signal had=20
appeared on the spectrogram, then unplugged the antenna, so that the=20
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=20
noisy in order to decode, there has to be part of it missing in order to=20
decode!

So that might be why the signals don't decode - whether this is a problem=20
with the soundcard, motherboard, or software is probably a question for=20
K1JT! Still, a step in the right direction...

Cheers, Jim Moritz
73 de M0BMU=20

No virus found in this incoming message.
Checked by AVG - http://www.avg.com=20
Version: 8.0.176 / Virus Database: 270.10.13/1915 - Release Date: 1/28/2009
6:37 AM