Message-ID: <207B9618B6584028A9FE09F671D05553@AGB>
From: "Graham" <g8fzk@g8fzk.fsnet.co.uk>
To: <rsgb_lf_group@blacksheep.org>
References: <8E070AD22619484C9E2D22046F45C521@JimPC>, <4AA224DE.17607.C34F15@dave.davesergeant.com>, <63ED5A8A7B8148DCB2612F74E8FD3EDE@JimPC> <4AA254EA.3320.17EF153@dave.davesergeant.com>
In-Reply-To: <4AA254EA.3320.17EF153@dave.davesergeant.com>
Date: Sat, 5 Sep 2009 13:57:17 +0100
MIME-Version: 1.0
Importance: Normal
Subject: Re: LF: Re: WSPR beacon
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org


Dave,

I think the  signal level V signal quality may be a major  factor, Gary is 
quite  close to me and  as he mentioned doesn't  always decode my signal, 
contrary and oddly my off line monitor  (ft897 with 20 feet end fed floating 
vertical to the  chimney stack)  produced reliable decodes all night ... 
capturing Gus and Jim in the  quite windows and my signal with a 'huge'  red 
centre  line and 50% of the  window  green ..

But  from last winter, I think it was determined that the  clock speed of 
the  audio card was the  main factor, various posts on the  user  group did 
tend to confirm this, but seems to date there no provision for a correction 
factor.

Following this , it looks like the  'less is more' syndrome applies, with 
missing a percentage of the  sync 'pulses'  resulting in a reliable de-code 
where as a 100% decode may fail, perhaps due to some form of 'quality check' 
in the  package ?

Last night  I ran two separate stations , with  tx/rx  from one pc and the 
off air decode from the  second, the decodes from the  ft897 showed Jim and 
Gus Dt to  be similar to the  reporting  data base , where as my  tx was 
showing 1.5   dt ..  both pc's share the same  radio network and  where 
running the  Dim-4 software, (Note Johns comments re d4)  so with in the 
same qth, same web link there was a displayed error of 1.5

was this  error recorded by other  stations ? , the dt is  not shown on the 
web data base

73- G ..


--------------------------------------------------
From: "Dave Sergeant" <dave@davesergeant.com>
Sent: Saturday, September 05, 2009 1:09 PM
To: <rsgb_lf_group@blacksheep.org>
Subject: LF: Re: WSPR beacon

>
> I have just been doing some more tests on 30m. Clock errors might well
> have been part of the problem. Initially on 30m the few decodes I was
> seeing were showing a DT of over 3s, so I had a play with the dsec
> setting, and setting that to -3.5 brought me rather more spots with DTs
> around 0. I noticed at that time that my computer clock was indeed
> around 3secs out relative to MSF, but that doesn't tie in with when I
> was listening to Jim earlier when it was no further than 0.5s
> different, even after an internet resynch. Surely my PC clock didn't
> drift 3s in a couple of hours....
>
> As to strong signals failing to decode, thanks for the information. I
> am using the built in sound chip on the motherboard, and as you know
> these are always a bit ropey, so it may be the reason. I have another
> problem at the moment, in that I have just fitted a fixed level audio
> output connection to the K2 and I think I have got its level a bit high
> - I have to set the input level in WSPR to virtually zero to get around
> 0dB input. I shall be turning it down a bit next time I have to go
> inside the K2.
>
> It does look as if some aspects of WSPR are a bit finnicky though, not
> too impressed myself but if it means you are spotted in AA1A land it is
> obviously serving a good purpose. But for working Hatfield from
> Bracknell I guess there are quicker ways...
>
> 73 Dave G3YMC
>
> On 5 Sep 2009 at 12:17, James Moritz wrote:
>
>> Dear Daves, LF Group,
>>
>> Thanks for the overnight reports - the beacon was shut down at 0925utc
>> here. I see several spots in the database from AA1A - the first time
>> M0BMU has been copied in the US this season, thanks Dave.
>>
>> In answer to YMC Dave's questions:
>> 1) I don't know of an actual figure for required frequency stability,
>> but more than several Hz drift during a 2 minute period would be a
>> problem. But a drift of 1Hz in 2min is small enough. Some of the HF
>> people have problems with rigs heating and cooling between transmit and
>> receive cycles and the resulting cyclic drift. Using a converter and
>> receiver with seperate oscillators will certainly tend to multiply drift
>> problems.
>>
>> 2) I have not so far had much success with internet based clock
>> synchronisation utilities, so at the moment I am just setting my PC
>> clock against an MSF clock at the start of each session - this is
>> adequate, but my PC does drift a few seconds overnight. Having said
>> that, I was being received OK by a number of other stations this
>> morning. The transmission is supposed to start on each even minute, and
>> have a duration of 110.6 seconds.
>>
>> 3) WSPR seems to have good dynamic range, provided the RX and sound card
>> gains are adjusted so that overload does not occur. Certainly, it is
>> possible to receive rather weak signals giving just a faint trace in the
>> noise on the waterfall display at the same time as strong "red" traces
>> occur - a range of 40dB or more. Even if a strong signal does cause
>> overload, the randomised transmit periods mean that only a fraction of
>> the weak signal time slots will be affected. I have not noticed any
>> problem with decoding strong WSPR signals here, although there are not
>> really any "very" strong signals.
>>
>> The "false decodes" occur from time to time, apparently more when
>> narrow-band QRM is present. If you read W1JT's description of the
>> various JT modes, he has made a trade-off between excluding decoded weak
>> signals that contain a lot of noise but could be correct, and falsely
>> decoding noise that by chance resembles a signal. In practice, they are
>> not really an issue, due to the fact that the callsign is encoded with
>> other information (for WSPR the locator and power output) and these
>> would have to be consistent with the callsign for the signal to be
>> accepted as valid. Even if the falsely decoded callsign is plausible, it
>> is extremely unlikely that the locator would be correct, and
>> astronomically unlikely that the same decode would be generated from
>> noise at multiple receiving stations on multiple occasions. Using these
>> types of criteria, false decodes are periodically stripped out of the
>> WSPR database.
>>
>> A number of people have had problems with strong signals failing to
>> decode, on HF as well as 500kHz. We did some investigation of this last
>> winter; there may be more than one cause, but one issue is that some
>> sound cards/operating systems appear to generate significant timing
>> errors, which over the relatively long transmission period of WSPR
>> accumulate to mess things up. This results in some receivers failing to
>> decode some transmitters. One way to test this is to receive a strong
>> WSPR signal, but then after about 40s or a minute from the start of a
>> transmission disconnect the audio to the PC or turn the gain down to
>> zero. There is enough data in the shortened signal to decode, but less
>> time for timing errors to accumulate. If this results in successful
>> decoding, then a timing error of this sort seems likely, which could be
>> at either TX or RX. Weak signals may decode fine, because parts of the
>> signal are "missing" due to noise and fading. So another possible test
>> is to reduce gain until the strong signal is just a weak trace on the
>> waterfall in the receiver noise, and see if correct decoding occurs
>> then.
>>
>> Cheers, Jim Moritz
>> 73 de M0BMU
>>
>>
>
>
> http://www.davesergeant.com
>
>
>



>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.409 / Virus Database: 270.13.77/2346 - Release Date: 09/04/09 
> 17:51:00
>