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" <[email protected]>
Sent: Saturday, September 05, 2009 1:09 PM
To: <[email protected]>
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
|
